AI Use Case Inventar und Governance - Portfolio, Rollen, Pflichten

Wissen wir überhaupt, welche AI- und Analytics-Use-Cases wir betreiben, wer dafür verantwortlich ist und welche Pflichten daraus folgen?

Wenn diese Steuerung fehlt, passieren typischerweise zwei Dinge. Use-Cases wachsen unbemerkt in sensible Prozesse hinein. Und Compliance wird zum Einzelfallprojekt. Beides skaliert nicht.

Hinweis: Keine Rechtsberatung, sondern eine technische, praxisorientierte Einordnung.

Inventar zuerst

AI-Use-Cases sind selten ein sauberer Produktkatalog. Es sind Dashboards mit eingebetteter Logik, Notebook-Prototypen, Assistenten, Scoring-Modelle in Workflows oder Automatisierungsschritte, die erst später als „AI“ erkannt werden. Ohne Inventar wird es schwierig, konsistent zu priorisieren und wiederholbar zu entscheiden.

Ausdem inics-Alltag:

‍Wir sehen häufig viele kleine Anwendungen, die niemand als „System“ zählt, bis eine davon in einen sensiblen Prozess rutscht. Dann beginnt die Aufholjagd.

Owner, Zweck, Datenwege, Versionen und Risikologik müssen nachträglich zusammengetragen werden.
‍

Was der EU AI Act organisatorisch praktisch macht

Sobald ein Use-Case voraussichtlich als High-Risk einzuordnen ist, wird Governance operativ. Die Klassifizierung hängt am konkreten Use-Case und Kontext, nicht an der Existenz einer Datenplattform. Dann braucht es Risikomanagement über den Lebenszyklus und klar definierte Verantwortlichkeiten entlang der Wertschöpfungskette.

Damit das im Alltag funktioniert, müssen die Rollen klar sein. Im EU AI Act bedeutet:
‍
Provider: ein AI-System wird bereitgestellt oder in Verkehr gebracht. 
Deployer: ein AI-System wird im Betrieb eingesetzt.

Wichtig ist außerdem: Unter bestimmten Bedingungen kann ein Deployer faktisch in Provider-Pflichten rutschen, zum Beispiel bei Re-Branding oder wesentlichen Änderungen.

Für viele Organisationen ist das weniger eine Papierfrage als eine Steuerungsfrage:
Wer klassifiziert, wer betreibt und wer liefert die Nachweise.

Und vor allem: Wer handelt als Provider, wer als Deployer und welche Pflichten folgen daraus.

Die technische Umsetzung von Evidence (Lineage, Versionierung, Logging) haben wir in Teil 2:Traceability by Design beschrieben; hier geht es darum, für welche Use Cases Evidence gebraucht wird und wer sie verantwortet.
‍

Zielbild: Ein AI- und Analytics-Portfolio, das Entscheidungen trägt

Das Ziel ist kein perfektes Register - ein arbeitsfähiges Portfolio, das drei Dinge ermöglicht:

1. Triage
‍Ist das überhauptein AI-System, und wenn ja, in welcher Risikoklasse bewegen wir uns. Als pragmatische Orientierung helfen die Kommissions-Guidelines zur Definitioneines „AI-Systems“.

2. Ownership
‍Wer ist entlang der Wertschöpfungskette wofür verantwortlich, und wo können Rollen in Richtung Provider wechseln. (🔗)

3. Pfad
‍Welche Mindestanforderungen greifen für den konkreten Use-Case, insbesondere wenn er High-Risk ist, und wie werden sie im Betrieb nachgehalten.  
‍‍

Das Kernartefakt: Use-Case Card statt Monster-Register

Wir empfehlen als inics-Muster keine „Governance-Datenbank“, sondern eine Use-Case Card pro relevanter Anwendung. Sie ist kurz, aber vollständig genug, um Entscheidungen zu tragen. Und sie lässt sich gut an bestehende Data- oder Produktkataloge andocken.

Minimaler Inhalt, der sich bewährt:

· Zweck und Prozessbezug:
Wo wirkt das Ergebnis, welche Entscheidungen werden beeinflusst

·  Owner und Rollen:
Wer verantwortet Fachlichkeit, Betrieb und Änderungen, inklusive Eskalationsweg

·  Einordnung:
AI-System ja oder nein, Risikoklasse, kurze Begründung, inklusive Trigger wie Zweckänderung

· Schnittstellen und Abhängigkeiten:
Welche Daten und Systeme sind angebunden, auf dem Level, das Reviews ermöglicht

·  Betriebsanforderungals Verweis:
Welche Nachweise sind erforderlich und wo liegen sie, zum Beispiel EvidencePack aus Teil 2.
‍‍

Tipp von unserem AI-Profi Thomas:
Cards anheften statt Parallelwelt bauen senkt Reibung und erhöht Adoption.

‍

Wenn es High-Risk wird: Drei Punkte, die Teams oft unterschätzen

1. FRIA als Praxishebel
Für bestimmte Deployers und bestimmte High-Risk-Einsätze ist vor der ersten Nutzung eine Fundamental Rights Impact Assessment vorgesehen und bei Änderungen zu aktualisieren. In der Praxis ist das ein guter Rahmen, um Zweck, betroffene Gruppen, Human Oversight und Mitigations strukturiert zu klären.

2. Deployer-Pflichten sind Betrieb, nicht Papier
Deployers haben operative Pflichten. Dazu zählen Nutzung nach Instructions, Human Oversight, Monitoring, Umgang mit Input-Daten und Aufbewahrungautomatisch erzeugter Logs unter ihrer Kontrolle.

Das ist die Stelle, an der Plattform- und Data-Teams in der Realität fast immerinvolviert sind, auch wenn sie nicht fachlicher Owner sind.

3. Registrierung und Incident-Wege brauchen klare Zuständigkeit
Für bestimmte High-Risk-Systeme gibt es Registrierungsanforderungen in der EU-Datenbank. Incident-Wege sollten mitgedacht werden. Deployers müssen Risiken und Incidents adressieren und Provider oder Behörden informieren. Providers müssen serious incidents an Marktüberwachungsbehörden melden (🔗).
‍

Pragmatiker-Start ohne Governance-Großprojekt

So starten wir das in Projekten häufig, ohne ein neues Programm zu erzeugen:

·  Portfolio herstellen:
Top-Use-Cases sammeln, clustern, Scope klären, inklusive versteckter AI inDashboards und Workflows

·  Owner festlegen:
Pro Use-Case eine verantwortliche Person plus klarer Eskalationsweg

·  Klassenpfadedefinieren:
Pro Risikoklasse ein Minimalset an Anforderungen plus Verweis, wie Nachweisegeliefert werden, etwa über das Evidence Pack aus Teil 2

inics-Alltag, typischer Verlauf:

Ein HR-Dashboard wird erst zur Ranking-Logik und später zur Vorauswahl. Spätestens dann muss sauber begründet werden, wie der Use-Case klassifiziertist, welche Oversight greift und wer welche Pflichten übernimmt. Annex III als Orientierung für mögliche High-Risk-Bereiche.

‍

Fazit

Der Druck entsteht selten am Gesetzestext.

Er entsteht, wenn ein Use-Case in einen sensiblen Prozess rutscht und plötzlich Fragen nach Verantwortung, Klassifizierung und Nachweisen im Raum stehen. Mit Portfolio, Use-Case Cards und klaren Rollen wird das planbar. Dann bleibt Governance leichtgewichtig und tragfähig im Alltag.

‍