AI Software Engineering jenseits der Modelldemo

Systemvertrag

Verhalten dort spezifizieren, wo klassische Anforderungen enden

Klassische Software lässt sich oft gegen exakte Ausgaben prüfen. Eine KI-Komponente kann mehrere vertretbare Antworten liefern, während eine plausible Antwort dennoch falsch sein kann. Die Spezifikation braucht deshalb Beispiele, Bewertungsrubriken und Toleranzen, die an der Nutzerentscheidung hängen. Legen Sie fest, was enthalten sein muss, was nie erscheinen darf, wann Quellen nötig sind und wann das System nicht fortfahren soll. Unterschiedliche Formulierungen sind etwas anderes als Fehler bei Fakten, Berechtigung oder Aktion.

Der Vertrag gilt an der Systemgrenze. Eine richtige Modellklassifikation ist kein Erfolg, wenn die Anwendung den falschen Kundendatensatz verknüpft oder ein Betroffener den Entscheid nicht anfechten kann. Nehmen Sie Datenqualität, Oberfläche, menschliche Prüfung und Ersatzverhalten auf. Das AI Risk Management Framework von NIST strukturiert Arbeit in Govern, Map, Measure und Manage. Es erinnert daran, dass technische Treffergenauigkeit nur eine Eigenschaft eines vertrauenswürdigen Einsatzes ist.

• Zweck, Kontext, Nutzer und verbotene Nutzungen festlegen.
• Fehler nach Folge statt nur Häufigkeit ordnen.
• Beleg-, Unsicherheits- und Eskalationsverhalten definieren.
• Die vollständige Reise durch Nutzer und Folgesystem testen.
• Abnahmekriterien vor der Implementierung beobachtbar machen.

Architektur

Eine deterministische Kontrollebene um probabilistische Fähigkeit bauen

Ein Modell ist nicht die Quelle der Wahrheit für Identität, Rechte, Prozesszustand oder Freigabe. Anwendungscode authentifiziert den Nutzer, filtert Material vor dem Retrieval und prüft strukturierte Ergebnisse gegen Typen und fachliche Invarianten. Ein Tool-Aufruf bleibt ein Vorschlag, bis serverseitige Berechtigung Akteur, Ressource und Parameter akzeptiert. Wirkungsvolle Operationen benötigen Idempotenz, Bestätigung und ein dauerhaftes Ergebnis aus dem Zielsystem. Die Behauptung des Modells ist kein Ausführungsnachweis.

Reproduzierbarkeit verlangt mehr als einen Git-Commit. Halten Sie Anwendungsversion, Modellkennung, Anbieterkonfiguration, Prompt, Retrieval-Index, Datensnapshot oder Feature-Pipeline, Richtlinienpaket und Tool-Schema zusammen fest. Erstellen Sie ein angemessenes Verzeichnis von Softwarebestandteilen und Lieferanten. Das Secure Software Development Framework von NIST integriert Sicherheitspraktiken in den Lebenszyklus. KI-Abhängigkeiten ergänzen Artefakte und Änderungskanäle, ersetzen aber weder geschützte Umgebungen noch geprüfte Änderungen und Schwachstellenbehebung.

Auslieferung

Evaluationsevidenz zum Freigabeartefakt machen

Unit-Tests bleiben für Parser, Rechte, Transformationen und Integrationen notwendig, bestimmen aber nicht das gesamte Verhaltensfeld eines modellabhängigen Systems. Pflegen Sie Evaluationsmengen für normalen Verkehr, schwierige Eingaben, fehlende Evidenz, Randverteilungen, mehrere Sprachen und Angriffe. Bewerten Sie Eigenschaften getrennt: faktische Stützung, Vollständigkeit, Aktionssicherheit, Formatgültigkeit, Kalibrierung und Nutzerergebnis. Ein gewichteter Durchschnitt darf einen kritischen Sicherheitsfehler niemals ausgleichen.

Verbinden Sie jede Freigabekandidatin mit Evaluationsbericht, Grenzen, Genehmigung und Ausrollplan. Vergleichen Sie mit der aktuellen Produktionsversion statt mit einem Eindruck. Schattenevaluation eignet sich für rein lesende Pfade, ein kleiner Canary für nötige Interaktion. Definieren Sie automatische Stopps für schwere Signale und einen menschlichen Eigentümer für mehrdeutige Befunde. Prompts, Retrieval-Richtlinien und Modellkonfiguration gehören in denselben kontrollierten Pfad wie Code, weil alle das beobachtbare Verhalten ändern.

• Einen geschützten Holdout für ehrliche Vergleiche behalten.
• Leistung nach Risikoklasse, Fallgruppe und Sprache berichten.
• Für definierte kritische Fehler Nulltoleranz setzen.
• Jede Änderung mit Evaluation und Freigabe verbinden.
• Mit begrenzter Exposition und geprüftem Rollback ausrollen.

Betrieb

Aus Produktion lernen, ohne Kontrolle abzugeben

Produktionsbeobachtung beginnt beim Nutzerergebnis. Messen Sie, ob die Aufgabe abgeschlossen wurde, ob eine Person korrigierte oder übersteuerte, ob Belege gültig waren und ob eine externe Aktion bestätigt wurde. Ergänzen Sie Modell- und Infrastruktursignale wie Tokenverbrauch, Retrieval-Qualität, Laufzeit, Tool-Fehler und Ablehnungsrate. Segmentieren Sie nach Version und Fallfamilie, damit ein stabiler Mittelwert keine konzentrierte Regression versteckt. Erfassen Sie nur Inhalte, die der erklärte Diagnosezweck benötigt, mit passenden Zugriffs- und Aufbewahrungsregeln.

Bei einem Vorfall wird zuerst die Exposition begrenzt: Tool abschalten, Fälle in manuelle Prüfung leiten, Modell zurücksetzen oder Funktion stoppen. Bewahren Sie Versions- und Ereignisevidenz und reproduzieren Sie das Verhalten mit einem minimierten Fall. Ordnen Sie den Defekt Daten, Prompt, Modell, Retrieval, Richtlinie, Integration, Oberfläche oder Betriebsprozess zu. Eine Reparatur in der falschen Schicht erzeugt brüchige Pflaster. Ergänzen Sie einen genehmigten Regressionstest, dokumentieren Sie den Entscheid und prüfen Sie die Erholung.

• Abgeschlossene Ergebnisse statt nur Modellantworten beobachten.
• Trends segmentieren, damit lokaler Schaden sichtbar bleibt.
• Sensible Telemetrie minimieren und befristet aufbewahren.
• Einen aktiven Vorfall vor der Diagnose begrenzen.
• Bestätigte Fehler in dauerhafte Regressionsevidenz verwandeln.