Im ersten Artikel zu AI Product Engineering habe ich beschrieben, warum AI-Features in Produktion mehr brauchen als gute Prompts. Agent Contract, Evaluation, Observability und Action Safety bilden den Rahmen. Aber ein Rahmen beantwortet noch nicht: Woran muss man eigentlich alles denken?
AI Product Engineering ist mehr als Softwarearchitektur mit LLMs. Dazu gehören auch Inferenz-Infrastruktur, Prozesse und Governance. Vor allem aber Fachwissen: Ob ein AI-Feature richtig arbeitet, können Entwickler und Architekten allein nicht beurteilen. Solche Systeme entstehen in enger Zusammenarbeit mit Fachexperten. Trotzdem fangen wir nicht bei null an. Die Qualitätsattribute der ISO 25010 (Functional Suitability, Reliability, Security und die anderen) sind ein guter Kompass für dieses neue Feld.
Die Qualitätsattribute bleiben, aber die Bewertungslogik dahinter kippt: Korrektheit wird zur statistischen Größe, Reliability meint mehr als Uptime, Performance wird zur Budgetfrage, und Security braucht Grenzen außerhalb des Modells.
Qualitätsmodell nach ISO 25010:2011. Grafik: Gernot Starke, Shortcomings of ISO 25010
Qualitätsattribute von AI-Features
1. Functional Suitability: Korrekt ist nicht mehr binär
In klassischer Software gibt es einen Test, und der ist grün oder rot. Bei vielen AI-Features ist “korrekt” ein Spektrum: Eine Zusammenfassung kann vollständig sein, halb richtig oder plausibel klingen und trotzdem das Entscheidende weglassen. Selbst ein Klassifikator, dessen Ergebnis sich pro Fall noch einfach prüfen lässt, ist nur über viele Fälle zu bewerten. 95 Prozent richtig zugeordnete Tickets klingen gut. Bis man feststellt, dass in den restlichen fünf Prozent fast alle Beschwerden stecken, die als einfache Anfragen durchgehen. Funktionale Korrektheit wird zur statistischen Größe. Die Frage “Funktioniert das Feature?” wird zu: “Wie oft, und was passiert, wenn nicht?” Entscheidend ist nicht die Durchschnittsqualität, sondern welche Fehlerklassen in welchen Fällen auftreten und welchen Schaden sie anrichten.
2. Reliability: Degradation ohne Deployment
Ein AI-System kann schlechter werden, ohne dass sich eine Zeile Code ändert: durch ein stilles Modell-Update beim Provider, wenn die Modellversion nicht im Agent Contract festgeschrieben ist, oder durch eine Drift in den Daten. Dazu kommt: Weil wir jetzt unstrukturierte Eingaben verarbeiten (Freitext, Bilder, emotionale Kunden-E-Mails), hängt die Output-Qualität stark vom Input ab. Bei einer REST-API mit festem Schema weiß ich, in welcher Form etwas reinkommt. Bei einer Schadensmeldung per E-Mail weiß ich nicht einmal das.
Reliability bedeutet bei AI-Systemen deshalb zweierlei: technische Zuverlässigkeit (läuft der Service, antwortet er schnell genug, was passiert bei Provider-Ausfall oder Timeout?) und stabile fachliche Qualität (liefert das Modell weiterhin brauchbare Ergebnisse?). Das Zweite ist schwerer zu messen, und wenn es nachlässt, merkt man es später. In beiden Fällen muss das System kontrolliert degradieren können, statt still Unsinn zu produzieren.
3. Maintainability: Unsichtbare Kopplung
Das ist die Eigenschaft, die mich am meisten beschäftigt. Ein AI-System hat viele verhaltensbestimmende Artefakte: Prompt, System Instructions, Modellwahl, Retrieval-Konfiguration, Schema, Tool-Policies. Keines davon ist im klassischen Sinne Code, aber jedes beeinflusst den Output. In Multi-Agent-Systemen multipliziert sich das. Eine Prompt-Änderung bei Agent A verändert dessen Output, Agent B verarbeitet ihn weiter, Agent C reagiert plötzlich anders, und niemand weiß, warum, weil diese Abhängigkeit in keiner Schnittstelle steht.
Die Flexibilität von Sprachmodellen ist ihre größte Stärke. Und gleichzeitig das, was Wartbarkeit so schwierig macht.
Ohne Agent Contract ist eine Prompt-Änderung ein unsichtbares Deployment. Wer prüft sie? Wer testet die Auswirkungen auf nachgelagerte Agenten? Mit Agent Contract ist sie eine neue Version des Vertrags und läuft gegen das Eval-Set, bevor sie live geht. In Multi-Agent-Systemen reicht das allein nicht, weil nachgelagerte Agenten auf jede Nuance im Output reagieren. Deshalb bekommt jeder Agent seinen eigenen Vertrag, und die Kette als Ganzes braucht ein eigenes Eval-Set.
4. Security: Neue Angriffsvektoren, alte Verantwortung
Prompt Injection erinnert an SQL Injection, mit einem entscheidenden Unterschied: Anweisungen und Daten lassen sich nicht sauber trennen. Ein Nutzer oder ein manipuliertes Dokument kann das Verhalten eines Modells umlenken, ohne dass es eine Lücke im Code gibt, die man schließen könnte. Das Modell ist keine Sicherheitsgrenze. Rechte, Freigaben und Guardrails müssen außerhalb des Modells durchgesetzt werden.
Daneben steht Datenschutz, in Europa ein Dauerthema: Welche Daten fließen an externe Provider, und was passiert mit personenbezogenen Daten in der Verarbeitung? Und dann Action Safety aus dem ersten Teil: Lese- und Schreibzugriff bleiben getrennt. Ein System, das nur klassifiziert, hat ein anderes Risikoprofil als eines, das eigenständig handelt.
5. Performance Efficiency: Kosten als Architektur-Dimension
Bei klassischer Software fallen die Kosten pro Request kaum ins Gewicht. Bei LLM-Inferenz schon. Jeder Aufruf kostet Token, und die Kosten skalieren mit Input-Länge, Output-Länge und Modellgröße. Wenn ein Agent in eine Endlosschleife gerät, verbrennt er nicht CPU-Zyklen, sondern Token, und die kosten echtes Geld. Ohne Budgetgrenzen kann so eine Schleife über Nacht teuer werden.
Wer lokale Modelle betreibt, handelt sich andere Kosten ein: GPU-Hardware, Stromverbrauch, Betriebskomplexität. Und die Hardware bestimmt, welche Modelle überhaupt laufen. Latenz verhält sich ebenfalls anders als bei klassischen Services. Ein LLM braucht oft Sekunden statt Millisekunden. Das verändert UX-Patterns und Architektur-Entscheidungen.
6. Compatibility: Verträge statt Hoffnung
Modell-Output muss vom Rest der Software gelesen werden können. Sobald das Modell Freitext produziert und die nachgelagerte Fachlogik ein definiertes Schema erwartet, ist das keine Selbstverständlichkeit. Das Schema im Agent Contract ist die Schnittstelle zwischen probabilistischer und deterministischer Welt. Ohne Schema ist jede Integration ein Glücksspiel. Valides JSON ist aber noch keine fachlich korrekte Antwort: Ein Feld kann eine erfundene Vertragsnummer enthalten. Ob es sie gibt, prüft die Fachlogik. Wie oft so etwas passiert, zeigt das Eval-Set.
Jeder Modellwechsel, jedes Prompt-Update ist eine neue Version des Agent Contract und erfordert eine erneute Validierung. Schema-Versionierung, Migrationspfade, Abwärtskompatibilität: dieselben Fragen wie bei jeder API. Mit dem Unterschied, dass sich der “Service” hinter der Schnittstelle bei jedem Aufruf anders verhalten kann.
7. Portability: Abhängigkeit mit Exit-Strategie
Prompts sind nicht 1:1 zwischen Modellen portierbar. Was bei Claude funktioniert, liefert bei GPT andere Ergebnisse. Ein Provider-Wechsel ist keine Konfigurationsänderung, sondern eine Migration mit erneuter Evaluation gegen das Eval-Set.
Trotzdem lohnt es sich, Portabilität von Anfang an mitzudenken. Kostenoptimierung bedeutet oft, von großen Foundation-Modellen auf kleinere, spezialisierte Modelle zu wechseln. Datensouveränität kann Inferenz im eigenen Rechenzentrum erzwingen. Abhängigkeit von einem Provider ist nicht per se falsch. Gefährlich wird sie, wenn sie unbewusst eingegangen wird und es keine Exit-Strategie gibt.
8. Usability: Vertrauen als UX-Problem
Bei Enterprise-AI ist Usability vor allem die Frage, wie menschliche Aufsicht praktisch funktioniert. Welche Belege sieht der Prüfer? Wie schnell kann er korrigieren? Wie wird Unsicherheit kommuniziert? Und: Ein System, das perfekt klassifiziert, dessen Prüfung aber wieder dreißig Minuten pro Fall kostet, wird niemand nutzen.
Eine einzige offensichtlich falsche Antwort kann das Vertrauen in ein Feature zerstören, und bei probabilistischen Systemen bleibt die Frage, ob das wieder passiert. Deshalb muss der Prüfer sehen, wie sich das System verhält und braucht eine Oberfläche, die Unsicherheiten sichtbar macht.
Die Trade-offs
Qualitätsattribute stehen nicht isoliert nebeneinander. Wer eines maximiert, zahlt meist bei einem anderen.
Qualität vs. Kosten. Ein größeres Modell liefert oft bessere Ergebnisse, kostet aber mehr und antwortet langsamer. Wann reicht das kleinere Modell?
Safety vs. Automatisierung. Mehr Freigaben und menschliche Prüfung reduzieren das Risiko, senken aber den Durchsatz. Irgendwann ist das AI-Feature langsamer als der manuelle Prozess, den es ersetzen soll.
Portabilität vs. Provider-Optimierung. Abstraktion reduziert Lock-in, kostet aber oft Leistung und Entwicklungsgeschwindigkeit.
Observability vs. Datenschutz. Mehr Logs und Traces helfen beim Betrieb, erhöhen aber den Compliance-Druck. Wer alles loggt, hat ein Datenschutzproblem. Wer nichts loggt, hat ein Qualitätsproblem.
Architektur ist die Disziplin, diese Abwägungen bewusst zu treffen, und das immer wieder.
Die Review-Fragen
Wer AI-Features in Produktion betreibt oder plant, sollte diese Fragen beantworten können:
- Welche fachliche Fehlerrate ist akzeptabel, und wie wird sie gemessen?
- Wie erkennen wir Modelldrift, bevor es Nutzern auffällt?
- Wie läuft eine Änderung am Agent Contract (Prompt, Modell, Schema, Tools) durch Review und Eval-Set, und wie rollen wir sie zurück?
- Welche Aktionen darf das System autonom ausführen, welche brauchen menschliche Freigabe?
- Welche Budgetgrenzen gelten für Inferenzkosten, und was passiert bei Provider-Ausfall oder Timeout?
- Was kostet uns ein Modell- oder Provider-Wechsel, und woran erkennen wir, dass er fällig ist?
- Welche Daten verlassen die Organisation, und an wen?
Eine Ebene höher stellt sich eine andere Frage: Wer in der Organisation hat den Überblick, welche AI-Systeme aktiv sind, was sie kosten und wer dafür verantwortlich ist? Dazu mehr im nächsten Teil dieser Serie.
Reihe AI Product Engineering
- AI Product Engineering: Einführung
- AI Product Engineering: Qualitätsmerkmale (dieser Artikel)
- AI Product Engineering: Governance (erscheint demnächst)
Weiterlesen:
Dr. Gernot Starke beschreibt in Quality-Driven Software Architecture den Qualitätsrahmen, von dem dieser Artikel inspiriert ist.
Ruben Vitt beschreibt in AI Systems Architecture beginnt dort, wo Modelloutput Teil der Produktlogik wird und Evals in der CI, wie Contracts, Eval-Frameworks und Observability in der Praxis aussehen.