Kernaussage: Behandeln Sie den KI-Use-Case-Intake als versionierte technische Kontrolle, nicht als Tabellenübung. Bevor ein Team ein Modell beschafft, Daten verbindet oder einen Piloten startet, erfassen Sie Zweck, betroffene Personen, Entscheidungsbefugnis, Modell und Anbieter, Datenflüsse, Prozessintegration und verantwortliche Person. Aus diesen Fakten entsteht ein Anwendbarkeitsgraph. Policy-Regeln liefern dann ein konkretes Kontrollpaket und blockieren Beschaffung oder Deployment, wenn notwendige Evidenz fehlt.
Das ist ein Engineering-Muster für wiederholbare Evidenz, keine rechtliche Klassifizierung. Der EU AI Act ist risikobasiert; Pflichten hängen von System, Zweckbestimmung und Rolle ab. Artikel 3 enthält Begriffe, Artikel 6 und Anhang III sind zentrale Einstiegspunkte für die Prüfung von Hochrisiko-Konstellationen. Der Überblick der Europäischen Kommission erläutert den risikobasierten Rahmen. Die rechtliche Einordnung eines konkreten Falls muss Rechtsberatung leisten.
Warum Inventarlisten scheitern, sobald KI operative Wirkung entfaltet
Eine Zeile wie „Sales Copilot — niedriges Risiko“ beantwortet keine belastbaren Fragen: Welche Modellversion läuft? Speichert der Anbieter Prompts? Welcher Prozess erhält die Ausgabe? Kann sie Beschäftigung, Kredit, Sicherheit oder Zugang zu Leistungen beeinflussen? Wer kann den Einsatz stoppen? Eine flache Liste verliert zudem Beziehungen, wenn ein Anbieter mehrere Modelle liefert oder ein Modell mehrere Workflows mit unterschiedlichen betroffenen Gruppen versorgt.
Sie brauchen dafür kein überdimensioniertes Ontologieprojekt. Beginnen Sie mit einem kleinen versionierten Schema und modellieren Sie Beziehungen explizit. Damit wird die Frage „Welche Use Cases sind von dieser Anbieteränderung betroffen?“ beantwortbar. Das ergänzt den Ansatz strukturierter LLM-Ausgaben als API-Vertrag: KI braucht explizite Verträge sowohl an der Ausgabeschnittstelle als auch an der Governance-Grenze.
Das minimale Intake-Schema
Verwenden Sie unveränderliche IDs und versionieren Sie jede eingereichte Bewertung. Ein praktikables Startschema umfasst sechs Objekte: UseCase, ModelDeployment, Supplier, DataAsset, BusinessProcess und AffectedGroup. Jedes Objekt hat Owner, Lifecycle-Status und Evidenzreferenzen; Kanten tragen fachliche Bedeutung statt nur einen Fremdschlüssel.
UseCase: Zweckbestimmung, Nutzerrolle, Entscheidungs-/Aktionsbefugnis, Region, Lifecycle-Status und Business Owner.
ModelDeployment: Modellfamilie/-version, Hosting-Region, Modalität, Konfiguration, Release-ID und Technical Owner.
Supplier: Vertragspartner, Evidenz zu Dienst/Subprozessoren, Änderungsbenachrichtigung und Procurement Owner.
DataAsset: Klassifizierung, Quelle, Aufbewahrung, Personenbezugs-Flag, Zugriffspolicy und Data Owner.
BusinessProcess: Prozess-Owner, Zielsystem, Reversibilität, menschlicher Freigabepunkt und Ausfall-Workflow.
AffectedGroup: potenziell betroffene Personen, Auswirkungsart, Umfang und Eskalationskontakt.
Referenzfluss: vom Intake zum Deployment-Gate
Diagramm / Lebenszyklus: Antragstellende Person sendet versionierten Intake → Validierungsservice prüft Pflichtfelder und Evidenzlinks → Graph Store löst Kanten zwischen Modell, Anbieter, Daten, Prozess und betroffener Gruppe auf → Policy Engine wertet Zweck und Signale aus → Control-Pack-Service weist Owner und Fristen zu → Procurement- und CI/CD-Gates erlauben, halten oder verwerfen das Deployment → unveränderlicher Assessment-Snapshot und Audit-Event werden gespeichert.
Der Graph ist keine Vorhersage-Engine, sondern ein Traceability-System. Sein Ergebnis muss erklärbar sein: Policy-Version, Eingabefakten, passende Regeln, Evidenzreferenzen, Kontroll-Owner, Ablaufdatum und Entscheidung. Speichern Sie diesen Snapshot append-only. Ändert sich später eine Policy, führen Sie die Prüfung bewusst erneut aus; überschreiben Sie niemals die historische Bewertung.
Policy-as-Code: Regeln müssen Arbeit erzeugen, nicht nur Farben
Eine sinnvolle Regel ist deklarativ und testbar. Beispiel: Wenn ein Use Case ein beschäftigungsbezogenes Zwecksignal, eine betroffene Personengruppe und ein Modell eines externen Anbieters hat, liefert sie ein Paket aus „Legal Review + Datenschutzprüfung + Human-Oversight-Design + Supplier-Evidenz“. Die Regel erklärt das System nicht selbst zum Hochrisikosystem; sie erkennt Fakten, die eine Prüfung erfordern. Eine weitere Regel kann ein Deployment halten, wenn Modellversion oder Evidenz zur Auftragsverarbeitung fehlt.
Trennen Sie Rechtsaussage und Engineering-Status. „Klassifizierung nach Anhang III bestätigt“ ist eine durch Legal verantwortete Aussage mit Quelle, Datum und Scope. „Kein Produktionsrelease ohne Assessment-Snapshot“ ist eine Engineering-Kontrolle. Diese Trennung verhindert Scheinsicherheit durch das Intake-System und macht fehlende Evidenz trotzdem operativ sichtbar.
Entscheidungstabelle: Wann das Gate ein Deployment stoppen muss
| Signal | Policy-Ergebnis | Gate | Kontroll-Owner |
|---|---|---|---|
| Modell oder Anbieter unbekannt | Intake unvollständig | Procurement und CI/CD-Promotion blockieren | Product Owner |
| Zweck betrifft Beschäftigung, wesentliche Leistung oder einen anderen Anhang-III-relevanten Bereich | Klassifizierungsprüfung erforderlich | Produktionsrelease halten | Legal/Compliance Lead |
| Personenbezogene oder sensible Daten mit externer Verarbeitung | Datenschutz-/Security-Prüfung erforderlich | Connector-Credentials blockieren | Datenschutz und Security |
| Aktion kann Geschäftsdaten oder Entscheidung verändern | Autoritätsgrenze erforderlich | Freigabe- und Rollback-Design verlangen | Process Owner |
| Evidenz älter als definierter Re-Assessment-Zeitraum | Bewertung veraltet | wesentliche Modell-/Konfigurationsänderung blockieren | Use-Case Owner |
Setzen Sie Gates dort, wo Änderungen tatsächlich entstehen
Procurement ist das erste Gate: kein Purchase Order, kein Sandbox-Tenant und kein API-Key ohne gültige Use-Case-ID und benannte Supplier-Kante. CI/CD ist das zweite: Deployment-Manifeste referenzieren Assessment-Snapshot, freigegebenes ModelDeployment und aktuellen Kontrollstatus. Runtime ist das dritte: der Service führt Assessment-ID, Modell-Release-ID und Policy-Entscheid in der Telemetrie. Das folgt derselben Logik wie Betriebsgrenzen für vernetzte KI-Workflows: Zugriff und Aktion werden vor der Skalierung begrenzt, nicht erst nach einem Incident rekonstruiert.
Zwingen Sie nicht jedes Experiment durch ein monatelanges Gremium. Arbeiten Sie mit Stufen. Ein lokales Non-Production-Experiment mit synthetischen Daten erhält ein kurzlebiges Sandbox-Paket. Ein System mit personenbezogenen Daten, schreibenden Aktionen oder Auswirkungen auf Personen benötigt mehr Fakten und eine kürzere Gültigkeit. Auch der Fast Path braucht Owner, Scope und automatisches Ablaufdatum.
Ausfallmodi, die Sie vor dem Rollout testen müssen
Scheinvollständigkeit: Pflichtfelder enthalten allgemeine Texte. Gegenmaßnahme: Evidenz typisieren und prüfen; „TBD“ für releasekritische Fakten ablehnen.
Graph Drift: Ein Anbieter ändert Modell oder Verarbeitungsbedingungen, der Use Case zeigt weiter auf einen alten Knoten. Gegenmaßnahme: Supplier-Änderungsereignisse einlesen, verbundene Snapshots als veraltet markieren und Re-Assessment verlangen.
Umgehung über Sandbox: Ein Team erzeugt einen API-Key außerhalb von Procurement. Gegenmaßnahme: Credentials zentralisieren und Assessment-ID in Gateway-Policy verlangen.
Zu breite Regeln: Jeder Intake erhält dasselbe schwere Kontrollpaket. Gegenmaßnahme: Regeln gegen bekannte Fälle testen, Begründung veröffentlichen und False Holds messen.
Snapshot-Mutation: Die Fakten einer Freigabe sind nicht mehr rekonstruierbar. Gegenmaßnahme: append-only Snapshots, Policy-Version-Hashes und unveränderliche Evidenzreferenzen.
Was dieser Ansatz nicht löst
Ein Anwendbarkeitsgraph entscheidet nicht eigenständig über die rechtliche Kategorie eines KI-Systems, ersetzt keine Grundrechtsfolgenabschätzung, löst keine Datenschutz-Compliance und macht kein schwaches Modell sicher. Er verursacht außerdem Pflegeaufwand: Owner müssen Beziehungen aktualisieren, Anbieteränderungen müssen überwacht und Regeln regression-getestet werden. Engineering-seitig sollten Sie diese Kosten transparent machen und die erste Version auf Entscheidungen fokussieren, die heute Verzögerungen oder unkontrollierte Deployments verursachen. Rechtsauslegung und sektorale Pflichten erfordern qualifizierte Rechtsberatung.
Praktischer Start in 30 Tagen
Wählen Sie zehn laufende oder geplante Use Cases. Definieren Sie die sechs Objekte, fünf Kantentypen und drei oben genannten Release-blockierenden Regeln. Importieren Sie nur autoritative Quellnachweise, geben Sie jedem Objekt einen Owner und bauen Sie eine Abfrage: „Welche Produktions-Use-Cases hängen von diesem Modell, Anbieter oder Datenasset ab?“ Verdrahten Sie das Ergebnis anschließend mit Procurement und einer Deployment-Pipeline. Ein kurzer Architekturworkshop kann daraus einen fokussierten Graphen, ein Kontrollpaket und ein Evidenzdesign machen.
Quellen
Verordnung (EU) 2024/1689 (AI Act): Artikel 3 und 6; Anhang III
