AI Assurance

Wie AI Assurance funktioniert

Bei AI Assurance steht nicht zuerst die Frage:
„Ist diese KI vertrauenswürdig?“
Eine solche Aussage wäre zu allgemein.

Stattdessen muss zunächst geklärt werden:

• Welches System wird betrachtet?
• Für welchen Einsatzzweck?
• Unter welchen Bedingungen?
• Welche Eigenschaften sind relevant?
• Welche Risiken müssen berücksichtigt werden?
• Welche Aussagen sollen über das System getroffen werden?
• Welche Evidenz kann diese Aussagen stützen?

Erst danach lässt sich untersuchen, wie belastbar eine Aussage über das System tatsächlich ist.

Von der Behauptung zur Evidenz

Ein Anbieter könnte beispielsweise behaupten:

Unser KI-System erzeugt zuverlässige technische Dokumentation.

Diese Aussage ist zunächst eine Behauptung.
Für eine Assurance muss geklärt werden, was zuverlässig in diesem Zusammenhang bedeutet.

Daraus könnten konkretere Aussagen entstehen:

Technische Aussagen stimmen mit den angegebenen Quellen überein.
Erzeugte Befehle sind für die angegebene Softwareversion gültig.
Verpflichtende Arbeitsschritte werden nicht ausgelassen.
Unsichere Aussagen werden als solche gekennzeichnet.

Für jede dieser Aussagen kann anschließend gefragt werden:
Welche Evidenz benötigen wir, um sie zu stützen?

Damit entsteht eine Kette:

Anforderung oder Behauptung
        ↓
prüfbare Eigenschaft
        ↓
geeignetes Prüfverfahren
        ↓
Evidenz
        ↓
Bewertung
        ↓
begründbare Aussage

Der letzte Schritt ist wichtig.
Ein Testergebnis sagt nicht automatisch mehr aus, als tatsächlich geprüft wurde.

Evidenz besitzt unterschiedliche Stärke

Nicht jede Information besitzt dieselbe Aussagekraft.
Ein Sprachmodell könnte beispielsweise einen erzeugten Befehl selbst noch einmal überprüfen und zu dem Ergebnis kommen:

Der Befehl ist korrekt.

Das ist Evidenz.
Ihre Aussagekraft ist jedoch begrenzt.
Ein zweites Modell könnte denselben Befehl unabhängig prüfen. Damit entsteht zusätzliche Evidenz.
Eine offizielle Dokumentation könnte bestätigen, dass die verwendete Option existiert.
Ein Test auf dem tatsächlich vorgesehenen Betriebssystem könnte zusätzlich zeigen, dass der Befehl unter dokumentierten Bedingungen funktioniert.
Diese Prüfungen beantworten unterschiedliche Fragen und besitzen unterschiedliche Aussagekraft.
Assurance benötigt deshalb nicht einfach mehr Evidenz.
Sie benötigt geeignete Evidenz für die jeweilige Aussage.

Evidenz ist kein Beweis für alles

Angenommen, ein erzeugter Befehl wurde erfolgreich auf OpenBSD 7.9 getestet.
Daraus lässt sich begründet sagen:

Der Befehl funktionierte unter den dokumentierten Testbedingungen auf dem getesteten OpenBSD-7.9-System.

Daraus folgt nicht automatisch:

Der Befehl funktioniert auf jeder OpenBSD-Version.

Auch nicht:

Der Befehl funktioniert unter jeder möglichen Konfiguration.

Und erst recht nicht:

Alle technischen Aussagen des erzeugten Artikels sind korrekt.

Assurance muss deshalb die Grenze zwischen beobachteter Evidenz und daraus abgeleiteter Aussage erhalten.

Vertrauen und Vertrauenswürdigkeit

AI Assurance soll Vertrauen nicht einfach erzeugen.
Menschen können einem System vertrauen, obwohl dieses Vertrauen unbegründet ist.
Umgekehrt können sie einem gut untersuchten System misstrauen.
Deshalb ist die wichtigere Frage, ob Vertrauen durch geeignete Evidenz begründet werden kann.
Ein System wird nicht dadurch vertrauenswürdig, dass es überzeugend wirkt.
Vertrauenswürdigkeit muss sich auf relevante Eigenschaften des Systems und dessen vorgesehenen Einsatz beziehen.
Assurance versucht, diese Eigenschaften untersuchbar und die entsprechende Evidenz nachvollziehbar zu machen.

Grenzen gehören zum Ergebnis

Ein gutes Assurance-Ergebnis beschreibt nicht nur, was funktioniert.
Es beschreibt auch, was nicht untersucht wurde.

Beispielsweise:

Untersucht:
- OpenBSD 7.9
- amd64
- Standardinstallation
- 120 definierte Referenzfälle

Nicht untersucht:
- OpenBSD 7.8
- arm64
- kundenspezifische Kerneländerungen
- unbekannte zukünftige Konfigurationen

Diese Einschränkungen schwächen die Untersuchung nicht.
Sie machen sichtbar, welche Aussage die vorhandene Evidenz tatsächlich trägt.
Eine Assurance, die ihre Grenzen verschweigt, erzeugt möglicherweise mehr Vertrauen, aber nicht besser begründetes Vertrauen.

KI-Evaluation liefert Evidenz

KI-Evaluation ist ein wichtiger Bestandteil von AI Assurance.
Eine Evaluation kann beispielsweise zeigen:

97 von 100 Testfällen erfüllten Kriterium A.

Das ist ein Ergebnis.
Für Assurance müssen anschließend weitere Fragen gestellt werden:

Sind diese 100 Testfälle repräsentativ?
Welche Fälle fehlen?
Wie wurden die Ergebnisse bewertet?
Welche Unsicherheit besitzt die Messung?
Welche Folgen besitzen die drei Fehler?
Unter welchen Bedingungen wurde getestet?

Evaluation erzeugt damit Evidenz.
Assurance betrachtet, welche Aussagen sich mit dieser Evidenz begründen lassen.

Ein bestandener Benchmark ist keine allgemeine Assurance

Benchmarks können wichtige Informationen über ein Modell liefern.
Ein Modell kann beispielsweise bei einem Testbestand sehr gute Ergebnisse erzielen.
Das bedeutet jedoch nicht automatisch, dass es für einen konkreten Anwendungsfall geeignet ist.
Ein Benchmark kann andere Aufgaben, Daten oder Risiken untersuchen als die tatsächliche Anwendung.
Deshalb muss Assurance immer den vorgesehenen Einsatz berücksichtigen.
Die Frage lautet nicht nur: „Wie gut ist dieses Modell?“
Sondern: „Welche Evidenz haben wir dafür, dass dieses System für diese Aufgabe unter diesen Bedingungen geeignet ist?“

Assurance betrifft das System, nicht nur das Modell

Ein KI-Modell ist häufig nur eine Komponente eines größeren Systems.
Eine Anwendung kann zusätzlich verwenden:

• System-Prompts
• Context Engineering
• Retrieval-Systeme
• Datenbanken
• externe Werkzeuge
• APIs
• Regelwerke
• Filter
• menschliche Freigaben
• nachgelagerte Verarbeitung

Ein sehr leistungsfähiges Modell kann in einem schlecht gestalteten Gesamtsystem unzuverlässige Ergebnisse erzeugen.
Umgekehrt können geeignete Kontrollen und Prüfungen bestimmte Schwächen eines Modells begrenzen.
AI Assurance sollte deshalb den für den Anwendungsfall relevanten Systemzusammenhang betrachten.

Assurance ist keine einmalige Untersuchung

KI-Systeme können sich verändern.
Ein Anbieter kann ein Modell aktualisieren.
Eine Wissensquelle kann verändert werden.
Ein System-Prompt kann angepasst werden.
Neue Werkzeuge können hinzukommen.
Ein Retrieval-System kann andere Dokumente liefern.
Der vorgesehene Einsatz kann sich verändern.
Damit kann auch vorhandene Evidenz ihre Aussagekraft verlieren.
Assurance muss deshalb berücksichtigen, unter welchen Bedingungen die Evidenz erzeugt wurde und welche Veränderungen eine erneute Prüfung notwendig machen.

Unabhängigkeit verändert die Aussagekraft

Eine Organisation kann ihr eigenes KI-System untersuchen.
Das ist wertvoll und häufig notwendig.
Für bestimmte Aussagen kann jedoch eine unabhängige Prüfung zusätzliche Aussagekraft besitzen.
Dabei ist Unabhängigkeit kein binärer Zustand.
Ein externer Prüfer kann beispielsweise unabhängig vom Entwicklungsteam sein, aber dieselben Referenzdaten verwenden.
Zwei Sprachmodelle unterschiedlicher Anbieter können unabhängig erscheinen und trotzdem ähnliche Fehler aufgrund vergleichbarer Trainingsdaten oder Bewertungsmuster erzeugen.

Deshalb sollte nicht nur gefragt werden: „Wer hat geprüft?“

Sondern auch: „Wie unabhängig sind die verwendeten Informations- und Prüfgrundlagen tatsächlich?“

Assurance umfasst mehr als technische Korrektheit

Abhängig vom Einsatz können neben technischer Leistungsfähigkeit weitere Eigenschaften relevant sein.

Dazu können beispielsweise gehören:

• Sicherheit
• Datenschutz
• Robustheit
• Fairness
• Transparenz
• Nachvollziehbarkeit
• rechtliche Anforderungen
• organisatorische Verantwortlichkeiten

Welche davon betrachtet werden müssen, hängt vom konkreten System und seinem Einsatzbereich ab.
AI Assurance ist deshalb kein einzelnes universelles Prüfverfahren.
Es ist ein Rahmen für die Frage, welche Eigenschaften begründet beurteilt werden müssen und welche Evidenz dafür erforderlich ist.

Warum AI Assurance praktische Auswirkungen hat

• Behauptungen werden prüfbar: Aus allgemeinen Aussagen entstehen konkrete Eigenschaften.
• Evidenz wird zugeordnet: Es wird sichtbar, welche Prüfung welche Aussage tatsächlich unterstützt.
• Grenzen bleiben erhalten: Nicht untersuchte Bereiche werden nicht stillschweigend als geprüft behandelt.
• Evaluation erhält einen Kontext: Testergebnisse werden zusammen mit Bedingungen und Risiken betrachtet.
• Veränderungen werden relevant: Modell-, Kontext- oder Systemänderungen können eine erneute Untersuchung notwendig machen.
• Unterschiedliche Prüfverfahren können kombiniert werden: Technische Tests, Dokumentation und menschliche Bewertungen können verschiedene Evidenz liefern.
• Vertrauen kann besser begründet werden: Entscheidend ist nicht, ob ein System überzeugend wirkt, sondern welche nachvollziehbare Evidenz vorhanden ist.

Typisches Beispiel

Ein Unternehmen möchte ein Sprachmodell verwenden, um Änderungen an Serverkonfigurationen vorzuschlagen.

Die Behauptung:

Das System erzeugt sichere Konfigurationen.

ist für eine Assurance zu allgemein.
Stattdessen werden konkrete Eigenschaften definiert.

Beispielsweise:

Vorgeschlagene Optionen existieren in der verwendeten Softwareversion.
Bestehende projektspezifische Sicherheitsregeln werden eingehalten.
Änderungen werden nicht automatisch produktiv ausgeführt.
Unsichere oder nicht überprüfbare Annahmen werden sichtbar gemacht.

Für diese Eigenschaften werden unterschiedliche Prüfungen eingesetzt.
Konfigurationsoptionen werden gegen Dokumentation und Testsysteme geprüft.
Regeln werden automatisiert kontrolliert.
Bekannte Problemfälle werden als wiederholbare Evaluationen verwendet.
Änderungen mit hoher Auswirkung benötigen eine menschliche Freigabe.
Die Ergebnisse werden zusammen mit Modellversion, Kontext, Testbedingungen und bekannten Einschränkungen dokumentiert.

Das Ergebnis lautet dann nicht:

Die KI ist sicher.

Sondern beispielsweise:

Unter den beschriebenen Bedingungen wurden die definierten Eigenschaften mit den dokumentierten Verfahren untersucht.
Für die untersuchten Fälle liegt die beschriebene Evidenz vor.
Für nicht untersuchte Konfigurationen kann daraus keine entsprechende Aussage abgeleitet werden.

Das ist weniger spektakulär.
Aber erheblich belastbarer.

Abgrenzung

• AI Assurance beschäftigt sich mit der Erzeugung, Bewertung und Kommunikation von Evidenz, aus der begründete Aussagen über relevante Eigenschaften und den Einsatz eines KI-Systems abgeleitet werden können.
• KI-Evaluation ist ein wichtiger Bestandteil davon. Sie untersucht das Verhalten und die Ergebnisse eines KI-Systems anhand definierter Kriterien.
• Verifikation und Validierung liefern allgemeinere Konzepte zur Prüfung, ob Anforderungen erfüllt werden und ein System für seinen vorgesehenen Zweck geeignet ist.
• AI Governance umfasst organisatorische Regeln, Verantwortlichkeiten, Richtlinien und Entscheidungsstrukturen rund um KI. Assurance kann Governance unterstützen, ist aber nicht mit ihr identisch.
• AI Safety beschäftigt sich mit der Vermeidung und Begrenzung von Schäden durch KI-Systeme. Sicherheit kann eine Eigenschaft sein, für die im Rahmen von AI Assurance Evidenz benötigt wird.
• Compliance betrachtet die Einhaltung bestimmter rechtlicher, regulatorischer oder normativer Anforderungen. Die Prüfung und Dokumentation von Compliance kann Bestandteil einer Assurance sein, deckt aber nicht automatisch sämtliche für einen Anwendungsfall relevanten Eigenschaften ab.

Weiterführend

Verwandte Begriffe

→ KI-Evaluation
→ Verifikation und Validierung
→ Probabilistisch
→ Context Engineering
→ Beobachtbarkeit
→ Resilienz