Fachbereich
Die Maßstäbe der Domäne werden explizit. Du wirst zum Co-Owner des Verhaltens, nicht zum nachgelagerten Tester.
AI Systems Architecture
Wenn KI nicht mehr nur antwortet, sondern handelt, reicht ein guter Prompt nicht mehr. Damit aus probabilistischen Modellen verantwortbare Produktbestandteile werden, braucht es eine eigene Architekturdisziplin.
Agentische KI verändert, was Software im Unternehmen tun kann. Sie liest Eingaben, beschafft Kontext, klassifiziert Fälle, bereitet Entscheidungen vor und löst über Werkzeuge Aktionen aus. Was früher Routinearbeit war, wird plötzlich automatisierbar.
Genau dort entsteht der Bruch. Ein Chatbot, der falsch antwortet, erzeugt ein Kommunikationsproblem. Ein Agent, der falsch klassifiziert, eine falsche Freigabe vorbereitet oder ein System falsch beschreibt, verändert den Zustand des Unternehmens.
Das Risiko liegt nicht nur in Halluzinationen, also erfundenen Inhalten. AI-Features können technisch gültig und fachlich falsch sein. Ein JSON ist valide, aber die Entscheidung dahinter falsch. Eine Aktion ist erfolgreich ausgeführt, aber hätte nie ausgelöst werden dürfen. Ein Modell bleibt erreichbar, aber sein Verhalten driftet.
Viele Unternehmen bleiben deshalb beim Chatbot stehen. Nicht weil die Modelle zu schwach wären, sondern weil der Sprung in produktive Verantwortung eine Architekturfrage ist.
AI Systems Architecture ist die Disziplin für diesen Sprung. Sie verbindet Modell, Prompt, Kontext, Schema, Werkzeuge, Evaluation, Human-in-the-Loop, Observability und Governance zu einem System, dessen Verhalten gemessen, begrenzt und betrieben werden kann.
Arbeitsdefinition
Fünf Fragen, die AI Systems Architecture beantwortet.
Wer ein AI-Feature produktiv setzt, muss alle fünf beantworten können. Lücken sind keine offenen Punkte. Sie sind Risiko.
- 01
Was darf das Modell entscheiden?
- 02
Auf welcher fachlichen Grundlage entscheidet es?
- 03
In welchem Format übergibt es Ergebnisse an die Software?
- 04
Welche Aktionen darf es in welchen Systemen auslösen?
- 05
Wie werden Qualität, Risiko und Betrieb nachgewiesen?
Für wen das relevant ist
Vier Rollen, eine gemeinsame Disziplin.
AI Systems Architecture funktioniert nicht in einer Abteilung allein. Sie spannt vier Perspektiven zusammen, deren Arbeit sich gegenseitig trägt.
Engineering
Modellverhalten wird versionierbar, testbar, betreibbar. AI-Features bekommen die gleiche Sorgfalt wie der Rest deiner Produktionssysteme.
Führung
AI-Features werden steuerbar statt unsichtbar. Risiko, Kosten und Wertbeitrag werden sichtbar, bevor sie zur Eskalation werden.
Betrieb
Fehler, Kosten und Drift werden beobachtbar. Vorfälle haben einen Pfad, nicht nur einen Anruf um drei Uhr morgens.
Charakteristika
Sechs Eigenschaften unterscheiden AI-Features von klassischer Software.
Die Unterschiede sind nicht kosmetisch. Sie verändern, wie man baut, testet, freigibt und betreibt.
01
Probabilistisch im Kern
AI-Features sind keine Funktionen mit determiniertem Output. Sie verteilen sich über ein Spektrum von Antworten.
02
Vertraglich gebunden
Ein Schema beschreibt, was hineingeht und was herauskommt. Das macht die Übergabe zwischen Modell und Software prüfbar.
03
Messbar vor Freigabe
Qualität wird auf einem Eval-Set gemessen, nicht im Chat. Automatisiert in der Pipeline, mit Verlauf.
04
Sichtbar im Betrieb
Modellversion, Schema-Fehlerrate, Kosten, Korrekturquote. Was nicht beobachtet wird, fällt erst auf, wenn jemand sich beschwert.
05
Begrenzt in der Wirkung
Lesen und Schreiben werden bewusst getrennt. Was das Feature darf, steht im Contract.
06
Eingebettet in eine Organisation
Ein Feature ist ein Werkzeug. Acht Features sind ein Portfolio, das Sichtbarkeit, Ownership und einen Eskalationspfad braucht.
Was hier neu ist
Warum klassische Softwaredenke nicht reicht und wo das Modell entscheidet.
01
Eine neue Klasse von Software
Was ist hier eigentlich neu?
Klassische Software ist eine Funktion. Agentische KI nicht: Sie nimmt Eingaben in beliebiger Form, antwortet bei gleicher Frage aber unterschiedlich. Diese Flexibilität ist Stärke und Schwierigkeit zugleich.
Mehr zeigen Weniger zeigen
Klassische Software ist eine Funktion: gleiche Eingabe, gleiche Ausgabe, wiederholbar. Agentische KI ist anders. Sie nimmt Eingaben in beliebiger Form, also Freitext, PDF, Foto, Tonprotokoll. Diese Offenheit gegenüber unstrukturierten Daten ist ihre Stärke. Klassische Software kann das nicht.
Bei gleicher Eingabe antwortet das Modell aber mal so, mal so. Diese Flexibilität macht es schwer beherrschbar. Viele Prototypen scheitern hier. Sie überleben den Sprung in den echten Betrieb nicht.
02
Warum plausibel nicht reicht
Warum ist ein LLM kein normales Softwaremodul?
Ein LLM erzeugt plausible Ausgaben unter Unsicherheit. Es kennt die Welt, nicht dein Unternehmen. Daraus entsteht eine neue Fehlerklasse: technisch gültig, fachlich falsch.
Mehr zeigen Weniger zeigen
Token-Stream mit Prozentwerten, daneben Modell mit Aktionspfeilen in mehrere Systeme
Ein LLM sagt das nächste Token voraus, Wort für Wort, Stück für Stück, basierend auf Wahrscheinlichkeiten. Es hat kein Verstehen, sondern eine sehr gute Statistik. Genau diese Statistik wird zur agentischen KI, sobald das Modell Werkzeuge bedient und Aufgaben übernimmt. Was es tut, klingt plausibel. Ob es richtig war, fällt oft erst spät auf.
Großer Weltwissens-Kreis, kleiner Unternehmens-Kreis abseits
Das Modell hat ein riesiges allgemeines Weltwissen. Über das eigene Unternehmen weiß es nichts: nicht die Prozesse, nicht die Bewertungsmaßstäbe, nicht die Tonalität im Haus. Was im Modell als richtig gilt, ist nicht, was in deiner Domäne als richtig gilt.
JSON-Block: grünes Schema-Häkchen, rotes Inhalts-Kreuz
Daraus folgt eine neue Klasse von Fehlern: technisch gültig, fachlich falsch. Der Output erfüllt das Format, hält aber die Domäne nicht ein.
Wie man Verhalten bindet
Vom Prompt zum Agent Contract: Anweisung, Kontext, Werkzeuge, Schema.
03
Prompt als Deployment
Warum ist ein Prompt kein Textbaustein?
Der Prompt ist die Arbeitsanweisung an die KI, meist mehrschichtig. Wer ihn ändert, deployt unsichtbar. Beim Modellwechsel beginnt die Übung neu.
Mehr zeigen Weniger zeigen
Drei gestapelte Prompt-Schichten, fliessen ins Modell
Der Prompt ist meist mehrschichtig: ein System-Prompt mit dauerhaften Regeln, ein Developer-Prompt mit dem konkreten Auftrag, dazu die Eingabe des Nutzers. Alle drei zusammen ergeben das Verhalten in einer Anfrage.
Zwei fast identische Prompts, deutlich unterschiedliche Outputs, daneben Prompt-Karte mit Versions-Etikett
Eine Prompt-Änderung verändert das Verhalten in Produktion. Sie ist ein unsichtbares Deployment, das niemand auf der Liste hatte. Prompts gehören deshalb in die Versionierung. Reviewt, freigegeben, wiederherstellbar. Sonst läuft die Qualität still nach unten.
Zwei Modell-Wolken in unterschiedlicher Färbung
Was ein guter Prompt ist, hängt vom Modell ab. Beim Anbieterwechsel beginnt die Übung neu. Der Prompt, der für Modell A funktioniert, scheitert oft an Modell B.
04
Kontext statt Weltwissen
Warum reicht das Modellwissen nicht?
Das Modell weiß viel über die Welt, nichts über dein Unternehmen. Grounding holt den Kontext zur Anfrage. Die Qualität der Antwort hängt jetzt an der Sucharchitektur.
Mehr zeigen Weniger zeigen
Modell-Wolke ohne Verbindung zu Unternehmens-Daten
Das Modell hat keine Verbindung zu deinen aktuellen Daten. Es kennt die Kundenakte nicht, die heute neu geschrieben wurde. Es kennt nicht die Tarifänderung von gestern. Was es nicht im Training gesehen hat, kennt es nicht.
Datenquellen → Suche → Prompt → Modell
Grounding ändert das. Vor jeder Anfrage werden relevante Daten aus dem Unternehmen herausgesucht und dem Prompt mitgegeben. Retrieval-Augmented Generation, kurz RAG, ist der bekannteste Ansatz dafür.
Suche mit Treffern in Datenbank, Pfeil in Modell
Die Qualität der Antwort hängt jetzt an der Sucharchitektur. Wer falsche oder veraltete Quellen liefert, bekommt falsche oder veraltete Antworten. Das Modell glaubt, was man ihm gibt.
05
Werkzeuge machen aus Antwort Handlung
Wann wird aus Modelloutput produktives Risiko?
Werkzeuge geben dem Modell Hand und Fuß. Lesen kann Daten offenlegen, Schreiben verändert die Welt. Jedes Werkzeug ist ein Vertrag mit Owner und Risikoklasse.
Mehr zeigen Weniger zeigen
Modell-Wolke mit ausgestreckten Tool-Boxen
Ein Werkzeug ist eine Funktion, die das Modell aufrufen kann. Damit liest es in einer Datenbank, schreibt einen Datensatz, verschickt eine Mail, steuert ein anderes System an. Aus dem Sprachmodell wird ein Akteur, der die Welt verändert.
Zwei Tool-Boxen: offen (read), mit Schloss (write)
Werkzeuge zerfallen in zwei Klassen: lesend und schreibend. Lesen verändert keinen Zustand, kann aber Daten offenlegen. Schreiben verändert zusätzlich die Welt. Diese Trennung ist die Grundlage aller Sicherheit.
Tool-Box mit aufgeklappter Schema-Beschreibung, Owner-Etikett und Risikoklasse
Jede Werkzeug-Definition ist ein Vertrag: was es kann, was es braucht, was es zurückgibt. Und sie gehört jemandem. Ein Owner, eine Risikoklasse, ein klarer Pfad zum Abschalten. Sonst weiß bei einem Vorfall niemand, wer eingreifen darf.
06
Schema bindet Form, nicht Wahrheit
Wie wird aus Sprache Produktlogik?
Ein Schema bindet die Form der Antwort, nicht den Inhalt. Valides JSON kann fachlich Unsinn enthalten. Was die Bausteine zusammenhält, ist das eigentliche Artefakt der Disziplin.
Mehr zeigen Weniger zeigen
Die Antwort des Modells muss in eine maschinenlesbare Struktur gebracht werden, meistens JSON. Ein Schema beschreibt diese Struktur: Felder, Enums, Pflichtangaben. Der Output wird darauf festgelegt und automatisch validiert.
Schema-Hex mit gelbem Warnsymbol an einem Feld
Schema-konformer Output schützt die Form. Nicht den Inhalt. Valides JSON kann fachlich Unsinn enthalten. Wieder gilt: technisch gültig, fachlich falsch.
Schema-Hex und Tool-Boxen verbinden sich zu einer Contract-Karte
Damit sind Form, Aktion und Kontext gebunden. Vier Bausteine, die das Verhalten festlegen. Wer einen davon allein verändert, verändert das Ganze, ohne es zu sehen. Was die Bausteine zusammenhält, ist das eigentliche Artefakt der Disziplin.
Das zentrale Artefakt
Der Agent Contract.
Ein Team passt den Prompt an. Schema, Modell und Software bleiben gleich. Trotzdem verschiebt sich das Verhalten in Produktion. War das ein fachlicher Change oder ein technischer? Wer hätte freigeben müssen? Solange Prompt, Schema, Werkzeuge, Modell und Evals einzeln verändert werden können, gibt es darauf keine Antwort.
Output-Schema, Prompt, Tool-Uses, Modell- und Provider-Wahl, Eval-Set: sie gehören fest zusammen. Jeder Teil verschiebt das Verhalten der anderen. Wer eines davon allein verändert, verändert das Ganze, ohne es zu sehen.
Deshalb wird der Agent Contract als Paket versioniert. Eine neue Version umfasst immer alle fünf Bestandteile. Was zur einen Version freigegeben war, bleibt nachvollziehbar. Was sich ändert, ändert sich gemeinsam.
Und der Contract gehört in die Domäne der Fachexperten, nicht in die Infrastruktur. Welche Kategorien ein Fall annimmt, welche Eskalation eine Eingabe auslöst, welche Tonalität in der Ausgabe steht: das entscheidet die Fachseite. Das Engineering bringt die Form, die Fachseite den Inhalt. Beide gemeinsam halten das Artefakt.
Wie man Verantwortung herstellt
Messen, freigeben, beobachten, begrenzen.
07
Qualität misst man nicht im Chat
Wie beweist man, dass ein AI-Feature funktioniert?
Im Chat ausprobieren ist kein Test. Ein Eval-Set aus echten Beispielen mit Fachlabels misst Verhalten automatisiert, bei jeder Änderung an Prompt, Schema oder Modell.
Mehr zeigen Weniger zeigen
Person am Bildschirm mit Häkchen, daneben Fragezeichen
Im Chat ausprobieren ist kein Test. Es ist die Hoffnung, dass es im echten Betrieb genauso laufen wird.
Karten-Stapel: Eingabe-Block mit Pfeil zu Label-Block
Ein Eval-Set ist eine Sammlung echter Beispiele. Was ist hineingegangen, wie hätte die KI antworten sollen. Ein paar Dutzend gut gewählte Fälle fangen die groben Fehler. Für Freigabe und Betrieb wächst das Set mit jeder neuen Fehlerklasse mit.
Quellen-Symbole (E-Mail, PDF, Bild) fliessen in das Eval-Set
Sources sind die Eingaben. Echte Anfragen, echte Dokumente, echte Transkripte. Fachexperten stellen sie zusammen. Nur sie wissen, was im Alltag tatsächlich ankommt.
Source-Karte mit Label-Tag, daneben Person-Symbol
Labels sind die erwarteten Antworten. Fachexperten markieren, wie die KI auf jede Source reagieren sollte. Diese Maßgabe ist die Grundlage, gegen die alles gemessen wird.
Pipeline-Symbol mit Eval-Schritt grün und rot
Die Bewertung läuft automatisiert, bei jedem Prompt-, Modell- oder Schemawechsel. Eine neue Version des Agent Contracts geht erst dann live, wenn das Eval-Set sie freigibt.
Drei Durchläufe desselben Eval-Sets, gemittelt
Weil dasselbe Modell auf dieselbe Eingabe nicht immer gleich antwortet, reicht ein einzelner Testlauf nicht. Das Eval-Set wird mehrfach durchlaufen. Erst dann lassen sich Glücksfälle von echten Erfolgen unterscheiden.
08
Der Mensch ist Teil der Architektur
Wann darf KI allein handeln?
Nicht jede Aktion darf der Agent allein. Human-in-the-Loop ist eine UX-Frage: schnelle Freigabe, sichtbare Konfidenz, klare Eskalation.
Mehr zeigen Weniger zeigen
Spektrum von autonom nach mit Freigabe
Agentische KI lässt sich nicht überall vollautomatisch betreiben. Manche Aktionen brauchen Augen davor. Vor allem Entscheidungen, die sich nicht zurückrollen lassen.
Vier Kategorien als Icons mit Häkchen
Hier braucht es Human-in-the-Loop: irreversible Aktionen, gesetzliche Vorgaben, hohes Risiko, niedrige Modell-Konfidenz.
Bildschirm-Mockup mit AI-Vorschlag, Freigeben-Knopf und Korrekturfeld
Human-in-the-Loop ist eine UX-Frage. Welche Belege sieht der Prüfer, wie schnell kommt er an einen Korrekturpfad, und sieht er, wo das Modell unsicher war?
Zwei Stoppuhren: schnell und langsam
Ein guter Human-in-the-Loop-Schritt beschleunigt mehr, als er bremst. Ein schlechter macht die agentische KI langsamer als die manuelle Variante.
Person mit Pfeil zu einer zweiten Person
Kein Human-in-the-Loop ohne klare Eskalation. Wer entscheidet, wenn der Prüfer unsicher ist?
09
Betrieb braucht Signale
Wie merkt man, dass ein AI-Feature schlechter wird?
Agentische KI scheitert leise. Modellversion, Schema-Fehlerrate, Korrekturquote, Latenz und Kosten müssen beobachtbar sein. Alarme reagieren auf Drift, nicht auf Einzelfehler.
Mehr zeigen Weniger zeigen
Liniendiagramm mit langsam sinkender Trefferquote, ohne Deployment-Marker
Eine agentische KI kann schlechter werden, ohne dass sich eine Zeile Code ändert. Ein stilles Modell-Update, ein Drift in den Eingaben, eine veränderte Tool-Antwort.
Dashboard-Skizze mit fünf Kacheln
Was beobachtet werden muss: Modellversion, Schema-Fehlerrate, Korrekturquote, Latenz, Token-Kosten.
Span-Wasserfall mit drei Ebenen
Spans dokumentieren den Verlauf jedes Aufrufs. Events markieren Wechsel. OpenTelemetry hat dafür GenAI-Konventionen.
Verlaufskurve mit Bandbreite, Alarm bei Ausschlag
Alarme reagieren auf statistische Auffälligkeiten, nicht auf einzelne Fehler. Sonst wird das Monitoring abgestumpft.
Dunkler Bildschirm mit der Beschriftung No signal
Wer keine Beobachtung hat, hat keine Disziplin. Nur Hoffnung.
10
Kosten sind Architektur
Warum sind Token-Kosten mehr als Abrechnung?
Token-Kosten sind eine Architekturdimension. Welches Modell reicht für welchen Fall? Schleifen brauchen Budget-Limits, Kosten gehören an Features statt an Teams.
Mehr zeigen Weniger zeigen
Token-Counter mit Geldbetrag
Jeder Aufruf kostet. Eingabe, Ausgabe, Tool-Calls, alle erzeugen Token-Kosten.
Zwei Modell-Wolken: gross und teuer, klein und günstig
Größere Modelle können Qualität steigern. Sie erhöhen Latenz und Kosten, oft überproportional. Die Architekturfrage lautet daher selten ‚welches Modell ist am besten‘. Häufiger: welches reicht für diesen Fall?
Schleifen-Pfeil mit auflaufendem Counter
Agenten in Schleifen können fünfstellige Tagesrechnungen erzeugen. Budget-Limits sind ein Schutz, kein Komfortfeature.
Kosten-Tag an einer Feature-Karte
Kosten gehören zu Features, nicht zu Teams. Wer baut, sieht, was er verursacht.
Drei Pfade zu drei verschieden grossen Modellen
Kostenoptimierung verändert die Architektur. Kleinere Modelle, Caching, Routing nach Komplexität.
11
Jeder Modellaufruf ist ein Datenfluss
Welche Daten verlassen das Unternehmen?
Jeder Modell-Aufruf ist ein Datentransfer. Klassifizierung, Anonymisierung, Rechtsraum und dokumentierte Flüsse sind Architekturentscheidungen, vom EU AI Act verlangt.
Mehr zeigen Weniger zeigen
Datenpaket mit Pfeil aus dem Unternehmens-Rahmen heraus
Jeder Modell-Aufruf ist ein Datentransfer. Was geht raus, was bleibt drin, wer hat Zugriff?
Vier Datenpakete mit verschiedenen Klassifikations-Etiketten
Daten lassen sich klassifizieren. Public, internal, confidential, restricted. Jede Klasse hat eigene Regeln.
Datenpaket läuft durch einen Filter, kommt anonymisiert heraus
Personenbezogene Daten dürfen nicht ungefiltert in den Prompt. Davor kommt ein Filter oder eine Pseudonymisierung, im Code, vor dem Modell-Aufruf.
Landkarten-Symbol mit drei Knotenpunkten
Anbieter sitzen in verschiedenen Rechtsräumen. EU, USA, On-Prem. Auch das ist eine Architekturentscheidung.
Daten-Schema-Diagramm mit Klassen-Labels
Datenflüsse werden dokumentiert. Was die Organisation verlässt, muss bekannt sein. Der EU AI Act macht diese Transparenz für viele Systeme verbindlich, unabhängig vom genauen Stichtag.
12
Aktionen brauchen Sicherungen
Wie verhindert man produktive Schäden?
Werkzeuge sind die Hände der KI. Sandbox vor Live, Approvals für mutierende Aktionen, Filter gegen Prompt Injection, Idempotenz gegen Folgeschäden.
Mehr zeigen Weniger zeigen
Modell-Wolke mit ausgestreckten Tool-Händen
Werkzeuge sind die Hände des Modells. Was sie tun können, definiert das Schadenspotenzial.
Drei Stadien: Sandbox, Shadow, Live
Sandbox vor Live. Neue Modellversionen laufen erst gegen historische Fälle, dann im Schatten, dann produktiv.
Tool-Aufruf mit Pause, Person mit Freigabe-Häkchen
Approvals für mutierende Aktionen, mindestens für die mit hohem Risiko. Audit-Trail dazu.
Eingabe mit verstecktem Befehl prallt am Außenfilter ab
Prompt Injection ist real. Das Modell ist keine Sicherheitsgrenze. Rechte und Filter leben außerhalb.
Tool mit Retry-Schleife und Stopper
Idempotenz und saubere Fehlerpfade. Wer aus einer fehlgeschlagenen Aktion nicht rauskommt, baut den nächsten Vorfall vor.
Wie das in der Organisation skaliert
Vom Feature zum Portfolio, von der Praxis zur Disziplin.
13
Ein Feature ist ein Anfang. Acht sind ein Portfolio.
Was passiert, wenn AI-Features nicht mehr Experimente sind?
Ein Feature ist ein Werkzeug. Acht sind ein Portfolio. Es braucht ein Register, Risikoklassen, einen Incident-Pfad und eine Governance, die nicht ausbremst.
Mehr zeigen Weniger zeigen
Eine Feature-Karte, daneben acht Feature-Karten in lockerem Verbund
Eine einzelne agentische KI ist überschaubar. Acht in einem Unternehmen sind ein Portfolio.
Acht Feature-Karten, drei davon mit Schatten markiert
Niemand baut allein. Aber niemand inventarisiert von selbst. Shadow AI entsteht, wenn keine Sichtbarkeit existiert.
Tabellen-Skizze mit Spalten
Ein Register listet alle aktiven AI-Features. Owner, Provider, Eval-Stand, Datenflüsse. Selbstpflege durch Teams, zentrale Einsicht.
Drei Klassen-Etiketten an Feature-Karten
Risikoklassen entscheiden über Freigabewege. Ein interner Summarizer ist nicht dasselbe wie ein Agent mit Schreibzugriff auf das CRM.
Eskalationspfad mit drei Person-Symbolen
Incidents brauchen einen Pfad. Wer wird gerufen, wer entscheidet über Rollback, wer kommuniziert. Vor dem ersten Vorfall.
Mehrere Feature-Karten in gemeinsamem Rahmen, der Autonomie zulässt
Governance ermöglicht dezentralen Teams, in der Breite zu skalieren. Wer das als Bremse erlebt, hat zu schwere Prozesse gebaut.
14
Daraus entsteht eine Disziplin
Was ist AI Systems Architecture?
AI Systems Architecture ergänzt Softwarearchitektur um die Praktiken, die probabilistisches, agentisches Verhalten produktionsreif machen.
Mehr zeigen Weniger zeigen
Komplexe Komposition: Modell, Schema, Tools, Eval, Observability, Action Safety, Portfolio
AI Systems Architecture hat eigene Fehlerklassen, eigene Artefakte, eigene Metriken, eigene Rollen und eigene Betriebspraktiken. Sie macht das Kernproblem dieser Seite beherrschbar: Outputs, die technisch gültig und fachlich falsch sein können. Genau deshalb ist sie mehr als Prompt Engineering.
Zwei nebeneinanderliegende Pipelines: KI als Werkzeug vs. KI als Produktbestandteil
Sie ist nicht Agentic Software Engineering. Dort hilft KI beim Bauen von Software. Hier wird KI selbst Teil der Produktlogik.
Entwicklungslinie mit offenen Markern
Die Disziplin ist nicht abgeschlossen. Modelle, Provider und Tooling verändern sich. Die Architekturprinzipien müssen mitwachsen.
Zwei überlappende Disziplin-Kreise
Sie ersetzt Softwarearchitektur nicht. Sie ergänzt sie dort, wo Verhalten nicht mehr vollständig durch deterministischen Code entsteht.
Weiterlesen
Die Argumente in voller Länge.
Michael Seel
AI Systems Architecture
Warum AI-Features in Produktion mehr brauchen als gute Prompts.
Michael Seel
Qualitätsmerkmale für AI-Systeme
ISO 25010 angewandt auf AI-Features, mit den Trade-offs jeder Entscheidung.
Michael Seel
Governance für AI-Features
Shadow AI, Mitarbeiter ohne Organigramm, und wie Organisationen ihre AI-Systeme steuern lernen.
Ruben Vitt
AI Systems Architecture beginnt dort, wo Modelloutput Teil der Produktlogik wird
Drei Prinzipien für den Sprung vom Prompt zur Produktintegration.
Ruben Vitt
Evals in der CI
Wann AI-Features aufhören, Prompts zu sein, und wie automatisierte Auswertung in die Pipeline wandert.