Ihre KI hat die QA bestanden. In der Produktion wird sie trotzdem versagen.

Wie validieren wir LLM-Outputs vor dem Produktiv-Deployment?

Die Produktionsvalidierung erfordert drei Schichten, die die meisten Teams überspringen. Erstens domänenspezifische Test-Suiten: keine generischen Toxizitäts- oder Halluzinationsprüfungen, sondern Tests, die aus Ihren tatsächlichen Geschäftsregeln aufgebaut sind. Wenn Ihre KI Versicherungsschäden bearbeitet, verifiziert die Test-Suite die Genauigkeit der ICD-10-Codes, den Abgleich von Policenausschlüssen und die Korrektheit der Rückstellungsberechnung gegen Ihre Underwriting-Richtlinien.

Zweitens adversariales Stresstesting: Wir lassen Ihr System gegen Grenzfälle laufen, die Ihre Trainingsdaten nie abgedeckt haben. Was passiert, wenn ein Kunde einen Schaden in zwei Währungen einreicht? Wenn ein Vertrag auf ein Gesetz verweist, das letzten Monat geändert wurde? Wenn ein Agent versucht, eine Transaktion zu verarbeiten, die zwei Genehmigungen erfordert, aber nur eine vorliegt?

Drittens die Shadow-Mode-Implementierung: Die KI läuft 4–8 Wochen lang parallel zu Ihrem menschlichen Team und verarbeitet dieselben Eingaben. Wir messen Übereinstimmungsraten, markieren Abweichungen und erstellen ein statistisches Konfidenzprofil, bevor ein Mensch aus dem Prozess genommen wird. Der bei jeder Phase erstellte Validierungsbericht folgt den SR-11-7-Dokumentationsstandards, sodass Sie, wenn Ihre Aufsichtsbehörde fragt, wie Sie das Modell validiert haben, ihnen den Bericht übergeben, anstatt ihn im Nachhinein hektisch zu rekonstruieren.

Was verlangt die EU-AI-Act-Compliance tatsächlich von Enterprise-KI-Systemen bis August 2026?

Die Frist am 2. August 2026 aktiviert Anforderungen für Hochrisiko-KI-Systeme nach Artikel 6 und Transparenzpflichten nach Artikel 50. Wenn Ihr KI-System Kreditentscheidungen, Versicherungs-Underwriting, Beschäftigungs-Screening oder eine sicherheitskritische Funktion gemäß Anhang III beeinflusst, ist es ein Hochrisikosystem.

Hochrisikosysteme müssen ein Risikomanagementsystem unterhalten, das über den gesamten KI-Lebenszyklus läuft, nicht nur bei der Implementierung. Sie benötigen technische Dokumentation, die die Herkunft der Trainingsdaten, die Entscheidungen zur Modellarchitektur und die Validierungsmethodik abdeckt. Sie benötigen Mechanismen zur menschlichen Aufsicht, die es Betreibern ermöglichen, das System zu übersteuern oder abzuschalten. Sie benötigen eine automatische Protokollierung, die jede Entscheidung mit ausreichend Detailtiefe für eine nachträgliche Prüfung erfasst.

Transparenzpflichten verlangen, dass KI-Chatbots ihre künstliche Natur offenlegen, Emotionserkennungssysteme die Nutzer benachrichtigen und Deepfake-Inhalte maschinenlesbare Wasserzeichen tragen. Die Strafen bei Nichteinhaltung erreichen 35 Millionen EUR oder 7 % des weltweiten Jahresumsatzes bei verbotenen Praktiken und 15 Millionen EUR oder 3 % bei Verstößen gegen Hochrisikosysteme.

Finnland wurde im Januar 2026 der erste Mitgliedstaat mit voll funktionsfähigen Durchsetzungsbefugnissen, und andere nationale Behörden bauen jetzt Durchsetzungsteams auf. Die praktische Lücke, der die meisten Unternehmen gegenüberstehen, besteht nicht im Verständnis der Regeln, sondern in der Erbringung der technischen Nachweise. Ihr Risikomanagementsystem muss prüfbare Artefakte erzeugen, nicht nur Richtliniendokumente, die in SharePoint liegen.

Wie gehen wir mit Shadow-AI-Risiken um, wenn Mitarbeiter ChatGPT und Claude ohne IT-Genehmigung nutzen?

Shadow AI ist inzwischen die häufigste Quelle für Enterprise-KI-Risiken. Gartner fand heraus, dass 69 % der Organisationen vermuten, dass Mitarbeiter verbotene öffentliche GenAI-Tools nutzen, und 77 % der Mitarbeiter geben zu, sensible oder geschützte Informationen mit ChatGPT zu teilen. Samsung und Amazon entdeckten beide proprietären Code, der in öffentliche KI-Dienste hochgeladen wurde. Die Kosten sind nicht hypothetisch: Shadow-AI-Datenpannen kosten durchschnittlich 4,63 Millionen US-Dollar, rund 670.000 US-Dollar mehr als Datenpannen bei Organisationen mit kontrollierter KI-Nutzung.

Discovery ist der erste Schritt. Wir kartieren die KI-Nutzung in der gesamten Organisation durch Netzwerkverkehrsanalyse, Audits von Browser-Erweiterungen, SSO/OAuth-Token-Analyse und Erkennung von API-Aufrufmustern. Dies erzeugt ein vollständiges Inventar jedes KI-Berührungspunkts, einschließlich Diensten, auf die über persönliche Geräte und Konten zugegriffen wird, die das Unternehmens-VPN umgehen.

Das Inventar fließt in eine risikobewertete Klassifizierung ein: welche Tools sensible Daten verarbeiten, welche über Richtlinien zur akzeptablen Nutzung verfügen, welche blockiert werden müssen und welche unter Governance mit Unternehmenslizenzierung und Data-Loss-Prevention-Kontrollen gebracht werden sollten.

Das schwierigere Problem besteht darin, eine sanktionierte Alternative zu schaffen, die Mitarbeiter den Shadow-Tools tatsächlich vorziehen. Wenn Ihre genehmigte KI-Lösung drei Genehmigungsformulare und eine zweiwöchige Wartezeit erfordert, werden die Leute weiterhin ChatGPT auf ihren Handys nutzen. Wir helfen, einen gesteuerten KI-Zugang zu gestalten, der schnell genug ist, um mit den Shadow-Alternativen zu konkurrieren.

Was ist der Unterschied zwischen KI-Governance-Plattformen und tatsächlicher KI-Validierung?

Die meisten KI-Governance-Plattformen (Credo AI, IBM watsonx.governance, ModelOp) konzentrieren sich auf das Policy-Management: das Definieren von Governance-Richtlinien, deren Zuordnung zu Vorschriften, das Verfolgen des Compliance-Status über KI-Initiativen hinweg und das Erstellen von Berichten. Dies ist notwendige Arbeit, aber sie beantwortet nicht die Frage, die am meisten zählt: Gibt die KI für Ihren spezifischen Anwendungsfall tatsächlich korrekte Antworten?

Governance sagt Ihnen, dass Sie eine Richtlinie haben, die 95 % Genauigkeit bei der Schadenbearbeitung verlangt. Validierung sagt Ihnen, ob Sie tatsächlich 95 % erreichen und bei welchen Schadenarten Sie auf 70 % fallen. Die Lücke ist analog zum Unterschied zwischen dem Besitz einer ISO-27001-Zertifizierung und tatsächlicher Sicherheit. Die Zertifizierung beweist, dass Sie Prozesse haben. Penetrationstests beweisen, dass die Prozesse funktionieren.

In unserer Erfahrung beim Bauen von Validierungssystemen ist der gefährlichste Zustand das, was wir Governance-Theater nennen: ein gut organisiertes Dashboard, das grüne Häkchen zeigt, während die darunterliegende KI Policennummern halluziniert, Rückstellungen falsch berechnet oder Gesetze zitiert, die vor zwei Jahren aufgehoben wurden.

Arthur AI und Galileo bieten Drift-Erkennung und Monitoring, was näher an der Validierung liegt, aber sie arbeiten auf der Ebene der Modellmetriken (Genauigkeit, Latenz, Token-Verteilung) statt auf der Ebene der Domänenwahrheit (ist diese Versicherungsrückstellungsberechnung angesichts der Deckungsbedingungen dieses spezifischen Versicherungsnehmers korrekt).

Wie bauen wir SR-11-7-konforme Modellvalidierungsdokumentation für LLM-basierte Systeme auf?

SR 11-7 verlangt eine unabhängige Validierung, umfassende Dokumentation, laufende Überwachung und Governance-Aufsicht für jedes Modell, das in geschäftlichen Entscheidungen verwendet wird. Die Anwendung auf LLMs bringt drei Komplikationen mit sich, die die traditionelle Modellvalidierung nicht adressiert.

Erstens die Intransparenz des Anbieters: Wenn Sie OpenAI- oder Anthropic-APIs nutzen, wird der Modellanbieter keine Architekturdetails, keine Zusammensetzung der Trainingsdaten und keine Gewichts-Updates teilen. Ihre Validierung muss output-basiert sein und das Modell als Black Box gegen Ihre Domänenanforderungen testen. Das bedeutet, Challenger-Test-Suiten aufzubauen, die Ihre spezifischen Anwendungsfälle abdecken, und sich nicht auf die veröffentlichten Benchmarks des Anbieters zu verlassen.

Zweitens die Nicht-Stationarität: LLM-Anbieter aktualisieren Modelle ohne Vorankündigung. Das Verhalten von GPT-4 änderte sich zwischen März und Juni 2023 in mehreren Benchmarks messbar. Ihre Validierungsdokumentation muss eine kontinuierliche Überwachung enthalten, die erkennt, wann sich das Modellverhalten verschiebt, und Ihr Governance-Rahmenwerk muss definieren, welche Verschiebungsgröße eine Revalidierung auslöst.

Drittens die Prompt-Sensitivität: Kleine Änderungen an Prompts können dramatisch unterschiedliche Outputs erzeugen. Ihre Dokumentation muss die Prompt-Versionierung, das A/B-Testing von Prompt-Änderungen und Regressionstests über Ihre gesamte Test-Suite abdecken, bevor eine Prompt-Modifikation die Produktion erreicht.

Wir erstellen Validierungspakete, die eine Bewertung der konzeptionellen Solidität, eine Ergebnisanalyse gegen Holdout-Datensätze, Spezifikationen für laufende Überwachung mit Drift-Schwellenwerten und die Eskalationsverfahren der Governance enthalten, die Aufsichtsbehörden zu sehen erwarten. Die Dokumentation folgt dem Format, das OCC-Prüfer zu prüfen geschult sind.

Wie sollten wir KI-Agenten steuern, die autonome Handlungen ausführen, nicht nur Text erzeugen?

Agentic AI verlagert das Risiko von falschen Outputs zu falschen Handlungen. Wenn ein KI-Agent eine Datenbank verändern, eine Finanztransaktion ausführen, eine Kundenkommunikation versenden oder einen Workflow genehmigen kann, ist der Fehlermodus nicht mehr eine schlechte Antwort, die ein Mensch abfangen kann. Es ist eine irreversible Handlung, die gegen Richtlinien, Vorschriften oder den gesunden Menschenverstand verstoßen kann.

Nur etwa ein Drittel der Organisationen berichtet laut McKinseys Assessment von 2026 über Reifegrad 3 oder höher in der Governance von agentic AI. Die Lücke ist struktureller Natur: Die meisten Governance-Rahmenwerke wurden für traditionelle Modelle gebaut, die bewerten oder klassifizieren, nicht für Agenten, die planen und handeln.

Wir schaffen agentische Verantwortlichkeit durch vier Mechanismen. Begrenzte Autonomie: Jeder Agent hat eine explizite Allowlist von Tools, die er aufrufen kann, mit Transaktionslimits und Genehmigungsschwellen, die pro Handlungstyp definiert sind. Ein Agent zur Schadenbearbeitung kann Policendetails autonom nachschlagen, aber Zahlungen über 5.000 US-Dollar nicht ohne menschliche Bestätigung genehmigen. Audit-Trails für Handlungen: Jeder Tool-Aufruf wird mit der Argumentationskette des Agenten, dem Eingabekontext, der ergriffenen Handlung und dem beobachteten Ergebnis protokolliert. Dies ist keine Anwendungsprotokollierung. Es ist eine strukturierte Entscheidungsaufzeichnung, die ein Compliance-Beauftragter Wochen später rekonstruieren kann.

Rollback-Fähigkeit: Für jede Handlung, die der Agent ausführt, definieren wir vor der Implementierung das Umkehrverfahren. Wenn ein Agent eine fehlerhafte Kundenbenachrichtigung versendet, muss das System in der Lage sein, automatisch eine Korrektur auszustellen. Circuit Breaker: Ratenbegrenzungen, Anomalieerkennung bei Handlungsmustern und automatische Aussetzung, wenn das Verhalten des Agenten von seinem Baseline-Profil abweicht.

Was umfasst Enterprise-KI-Red-Teaming tatsächlich über das Jailbreak-Testing hinaus?

Die meisten Red-Teaming-Tools (Garak, PyRIT, Promptfoo) konzentrieren sich auf Sicherheitslücken: Prompt Injection, Jailbreaking, Datenextraktion und Verstöße gegen Inhaltsrichtlinien. Dies ist wichtig, aber für regulierte Unternehmen unzureichend. Sicherheits-Red-Teaming beantwortet die Frage „Kann jemand die KI dazu bringen, etwas Schlechtes zu tun?“ Business-Red-Teaming beantwortet die Frage „Tut die KI das Richtige, wenn die Situation kompliziert ist?“

Wir führen domänenspezifische adversariale Kampagnen durch, die die Entscheidungskorrektheit unter Grenzfällen testen. Für eine Kreditvergabe-KI bedeutet das, mit Antragstellern zu testen, die ungewöhnliche Einkommensstrukturen haben (Saisonarbeiter, Gig Economy, Ausschüttungen aus Treuhandfonds), widersprüchliche Bonitätssignale (hohes Einkommen mit kürzlicher Insolvenz) oder regulatorische Grenzfälle (SCRA-berechtigte Kreditnehmer, Verpflichtungen zur Reinvestition in die Gemeinschaft). Für eine Schadenbearbeitungs-KI testen wir mit Schäden mehrerer Parteien, Regress-Szenarien, Mehrdeutigkeiten bei Policenausschlüssen und Schäden, die Gerichtsbarkeitsgrenzen überschreiten.

Die Testmethodik folgt einem Gray-Box-Ansatz: Wir kennen das beabsichtigte Verhalten und die Geschäftsregeln des Systems, greifen die Implementierung aber über dieselben Schnittstellen an, denen ein realer Nutzer begegnen würde. Jede Testkampagne erzeugt einen strukturierten Befundbericht mit Schweregrad-Klassifizierung (kritisch, hoch, mittel, niedrig), Reproduktionsschritten, der geschäftlichen Auswirkung des Fehlers und einer empfohlenen Behebung. Anschließend testen wir nach den Behebungen erneut, um zu bestätigen, dass der Fehlermodus behoben ist.

Die Kadenz zählt ebenso sehr wie die Tiefe. Das LLM-Verhalten ändert sich mit jedem Modell-Update, jeder Prompt-Modifikation und jedem Fine-Tuning-Lauf. Wir bauen kontinuierliche adversariale Abdeckung in Ihre CI/CD-Pipeline ein, sodass Red-Team-Tests automatisch gegen jeden Deployment-Kandidaten laufen.