AI-Readiness-Audit: Was vor der Produktion geprüft werden sollte

Ein AI-Readiness-Audit ist ein strukturierter Entscheidungsprozess – kein Zertifikat und kein allgemeiner Reifegrad-Score. Ziel ist eine klare nächste Entscheidung: bauen, Scope verkleinern, ein bestehendes System härten oder auf eine fehlende Voraussetzung warten.

Mit Workflow und Entscheidung beginnen

Beschreibe die Aufgabe, die das System erfüllen soll, die betroffenen Personen, die Auswirkung des Outputs und das Verhalten bei Unsicherheit. Ein Readiness-Review, das mit einem Modellkatalog beginnt, übersieht oft die operative Grenze. Das erste Artefakt sollte eine Workflow-Karte mit Inputs, Transformationen, Freigaben, Seiteneffekten und Rollback-Punkten sein.

Definiere vor dem Testen eine Baseline. Das kann ein manueller Prozess, eine bestehende Regel oder ein kleines verifiziertes Dataset sein. Sie muss nicht perfekt sein, sondern für die Entscheidung beobachtbar und relevant.

Datenzugriff und Qualität

Erfasse Quellsysteme, Owner, Formate, Aktualisierung, Aufbewahrung und Zugriffswege. Prüfe, ob das System Daten verwenden darf – nicht nur, ob eine API sie technisch liefert. Dokumentiere fehlende Felder, widersprüchliche Definitionen, veraltete Datensätze, Einheiten, Sprachvarianten und doppelte IDs.

Bei Retrieval-Systemen gehören Chunking, Metadaten, Berechtigungsfilter, Provenance und das Verhalten bei fehlender Quelle dazu. Bei generierten Berichten werden Zahlen-Grounding und Abstimmung geprüft. Eine gute Abnahmefrage lautet: Kann ein Reviewer einen wichtigen Output zu den Quellrecords zurückverfolgen?

Identität, Security und rechtliche Grenzen

Mappe Nutzer, Service-Identitäten, Tools, Provider, Logs und Drittanbieter-Egress. Prüfe Least Privilege, Secret-Handling, Prompt-Injection-Risiken, Output-Validierung und Redaction, bevor Daten einen Provider oder ein Log erreichen. Teste High-Risk-Tool-Calls mit konkreten Abuse Cases; eine Policy allein beweist keine wirksame Grenze.

Rechtliche Fragen gehören zu den zuständigen Fachstellen. Der technische Review kann Zweck, Datenkategorien, Aufbewahrung, Human Oversight und Provider-Fragen dokumentieren, ist aber keine individuelle Rechtsberatung. Offene Punkte werden als Delivery-Abhängigkeiten festgehalten.

Modelle, Provider und Evaluation

Wähle ein Modell gegen Qualitäts-, Latenz-, Kosten-, Daten- und Betriebsanforderungen. Der Provider ist eine veränderbare Architekturentscheidung, nicht die Produktdefinition. Pinne Versionen, wenn Reproduzierbarkeit wichtig ist, und dokumentiere Fallback-Verhalten.

Ein repräsentatives Eval-Set enthält kritische, normale, mehrdeutige und adversariale Fälle. Kriterien werden vor den Ergebnissen festgelegt. Deterministische Checks für Schema, Berechtigungen, Zahlen und Quellen werden mit menschlicher Prüfung kombiniert. Ein Release-Gate muss benennen, was blockiert und wer Ausnahmen freigibt.

Observability und Betrieb

Definiere Request-IDs, Prompt- und Modellversionen, Token- und Kostendimensionen, Latenz, Validierung, Tool-Calls und menschliche Ergebnisse. Lege fest, was gespeichert und redigiert wird. Ein Incident-Pfad deckt Provider-Fehler, unsichere Outputs, Datenverletzungen, Qualitätsregressionen und Kostensprünge ab.

Das minimale Betriebspaket besteht aus einem Dashboard für bekannte Fragen, Alert-Katalog, Runbook, Rollback-Pfad und Owner. Wenn das System nach der Übergabe niemand betreiben kann, ist Readiness nicht gezeigt.

Go, Scope verkleinern oder No-Go

Go setzt einen begrenzten Workflow, nutzbare Daten, einen verantwortlichen Owner, getestete Controls, eine relevante Baseline und einen Betriebspfad voraus. Verkleinere den Scope bei nur teilweise ausreichender Qualität oder notwendiger menschlicher Prüfung. No-Go ist sinnvoll, wenn Identität, Datenrechte, Quellenqualität oder Incident-Verantwortung offen sind.

Das Ergebnis ist ein priorisierter Maßnahmenplan mit Evidenz, Annahmen, offenen Fragen und Abnahmekriterien. Der Engineering-Service und der Security-Service zeigen die Umsetzung anschließender Maßnahmen.

Evidenz nutzbar machen

Jeder Befund sollte Beobachtung, Auswirkung, Evidenz, Owner und Abschlussbedingung nennen. „Security verbessern“ ist keine Maßnahme; „Tool X besitzt Schreibzugriff ohne Bestätigungsstatus; Berechtigung entfernen oder geprüftes Gate ergänzen“ schon. Annahmen bleiben sichtbar, besonders wenn Quellsystem, Provider-Vertrag oder Aufbewahrungsregel noch nicht geprüft wurden.

Das Audit kann als kurze Folge laufen: Entscheidung klären, Workflow und Daten mappen, kritische Grenzen testen, repräsentative Fälle evaluieren und die Reihenfolge der Umsetzung festlegen. Das Ergebnis ist auch bei No-Go nützlich, weil es zeigt, was vor einer weiteren Investition konkret geändert werden muss.