Das gestufte KI-Intake ist die operative Disziplin, um jede KI-Anfrage an ein Überprüfungsniveau weiterzuleiten, das ihrem Risiko entspricht – typischerweise über vier Stufen von Self-Service bis hin zu „Restricted“ (Eingeschränkt). Es ersetzt den einspurigen Prüfungsprozess, der an dem Punkt scheitert, an dem das Governance-Volumen auf die Geschwindigkeit der Einführung trifft, und ist die tragende Säule eines jeden KI-Governance-Programms auf Unternehmensebene.

Wichtige Erkenntnisse

Das Proportionalitätsprinzip. Jedes wichtige KI-Regelwerk – das EU-KI-Gesetz, ISO/IEC 42001 und das NIST AI RMF – läuft auf dieselbe operative Anforderung hinaus: Die Prüfung eines KI-Systems muss proportional zu dem Risiko sein, das es darstellt. Das gestufte Intake ist die Art und Weise, wie diese Anforderung auf Unternehmensebene operationalisiert wird.

Das Vier-Stufen-Modell. Self-Service / Light Review (Leichte Prüfung) / Full Review (Vollständige Prüfung) / Restricted (Eingeschränkt). Jede Stufe verfügt über ein definiertes Risikoprofil, einen Prüfungsprozess und einen Genehmiger. Die Struktur lässt sich nahtlos auf die vierstufige Risikokategorisierung des EU-KI-Gesetzes und auf die risikobasierten Kontrollen von ISO 42001 übertragen.

Intake als kontinuierliche Disziplin. Das Intake ist für kein System oberhalb von Stufe 1 jemals „abgeschlossen“. Auslöser für wesentliche Änderungen, Modell-Updates von Anbietern und Änderungen am Umfang des Anwendungsfalls erfordern jeweils eine erneute Bewertung. Programme, die das Intake als einmalige Angelegenheit behandeln, scheitern in der Praxis.

Intake: Die tragende Säule eines jeden Governance-Programms

Jede Komponente eines KI-Governance-Programms – das KI-Inventar, die Bewertungsbibliothek, der Überwachungsturnus, die regulatorische Dokumentation, der Audit-Trail – hängt vom Intake ab. Ohne dieses steuert das Programm nur das, wovon es weiß, und das, wovon es weiß, weicht innerhalb eines Quartals von dem ab, was tatsächlich produktiv genutzt wird. Dieses Muster zeigt sich durchgängig bei Unternehmen, die die erste Welle der KI-Einführung hinter sich haben: Der Fehlermodus verläuft selten lautstark. Die Governance wird so langsam, dass sie umgangen wird.

Dieses Muster der langsamen Umgehung äußert sich in zwei verschiedenen Formen. Die erste, der Bottleneck-Fehlermodus, entsteht, wenn ein einziger Prüfungspfad auf jede KI-Anfrage angewendet wird und so Warteschlangen entstehen. Ein Marketing-Team für Konsumgüter, das eine Anfrage für ein KI-Copywriting-Tool stellt, wartet hinter einem Kandidaten-Ranking-System, das berechtigterweise eine mehrwöchige Konformitätsbewertung erfordert. Wenn Geschäftsinhaber diese Verzögerung zum dritten oder vierten Mal erleben, beginnen sie, den Prozess zu umgehen: Es werden persönliche Konten genutzt, kostenlose öffentliche KI-Dienste übernehmen die Arbeit, und integrierte SaaS-Funktionen werden ohne Offenlegung aktiviert. Die Schatten-KI-Oberfläche wächst im umgekehrten Verhältnis zum Durchsatz des Intakes, und das Inventar spiegelt zunehmend wider, was genehmigt wurde, und nicht das, was tatsächlich im Einsatz ist.

Die Schatten-KI-Oberfläche wächst im umgekehrten Verhältnis zum Durchsatz des Intakes.

Die zweite Form ist der Lücken-Fehlermodus. Ein einziger Prüfungspfad, der in der Tiefe arbeitet, die ein System mit hohem Risiko tatsächlich erfordert, wird für Tools mit geringem Risiko zu einem unverhältnismäßigen Mehraufwand. Die Auswahl schrumpft dann auf zwei gleichermaßen schlechte Ergebnisse: Entweder wird die Prüfung so weit verwässert, dass sie den regulatorischen Anforderungen nicht mehr gerecht wird, oder das Programm verliert intern an Glaubwürdigkeit, weil vom Marketing verlangt wird, dieselbe 200-Fragen-Bewertung auszufüllen, die auch für Kredit-Scoring-Modelle verwendet wird. In beiden Fällen ist das Programm weniger effektiv, als es auf dem Papier aussieht.

Das gestufte Intake löst beide Probleme. Das Prinzip wird von allen wichtigen KI-Regulierungssystemen unterstützt: Artikel 6 des EU-KI-Gesetzes,[4] Klausel 6.1.4 der ISO 42001 in Verbindung mit den Klauseln 6.1.2 und 8.2 derselben Norm[2] und der Govern-Funktion des NIST AI RMF.[3] Zudem ist es auf Unternehmensebene operativ umsetzbar.

Das Vier-Stufen-Modell: Die Prüfung an das Risiko anpassen

Abbildung 1: Das vierstufige KI-Governance-Intake-Modell. Die Prüftiefe skaliert mit dem Risiko. Die Verteilung der einzelnen Stufen in einem ausgereiften Programm liegt bei ca. 60–70 % für Stufe 1, 20–25 % für Stufe 2, 5–15 % für Stufe 3 und einem geringen, aber vorhandenen Anteil für Stufe 4.

Anhand eines konkreten Beispiels lässt sich das Modell anschaulich erklären. Ein HR-Team fordert ein KI-gestütztes System zur Einstufung von Bewerbern von einem Drittanbieter an. Der Anwendungsfall fällt unter das EU-KI-Gesetz Anhang III[6] (Beschäftigung), was der Mindestanforderung für Stufe 3 entspricht. Das System trifft folgenschwere Entscheidungen über Personen (Beschäftigung), was die Einstufung in Stufe 3 untermauert. Die Daten sind sensibel (Lebensläufe enthalten personenbezogene Daten, teilweise auch besondere Kategorien von Daten), was die Einstufung ebenfalls bestätigt. Alle Dimensionen laufen hier zusammen; die Anfrage wird an Stufe 3 weitergeleitet und erfordert eine vollständige Bewertung, eine Prüfung durch verschiedene Stakeholder, eine technische Dokumentation gemäß Anhang IV[7] und definierte Auslöser für eine erneute Bewertung bei Modell-Updates des Anbieters.

Vergleichen wir dies mit einem internen Grammatik-Tool, das nur für bereits veröffentlichte Marketingtexte verwendet wird. Keine personenbezogenen Daten, keine folgenschweren Entscheidungen, keine Auswirkungen nach außen. Die Dimensionen führen eindeutig zu Stufe 1. Das Intake besteht aus einem in zwei Minuten ausgefüllten Registrierungsformular; das System erscheint bis zur Mittagspause im Inventar; kein menschlicher Prüfer befasst sich mit der Anfrage, es sei denn, es wird eine Ausnahme gemeldet.

Die Existenz von Stufe 4 ist das, was der gesamten Struktur ihre Glaubwürdigkeit verleiht.

Ohne einen expliziten Ablehnungspfad akzeptiert das Intake implizit jede Anfrage als letztlich steuerbar, und die Bestimmungen über verbotene Praktiken der geltenden Regelwerke würden ignoriert. Ein Eintrag in Stufe 4 sollte im Audit-Trail mit einer dokumentierten Ablehnung erscheinen – dieser Datensatz selbst dient einer Regulierungsbehörde als Nachweis für die Reife der Governance.

Nennenswerte Grenzfälle. Einige Systeme bewegen sich zwischen den Stufen. Ein System der Stufe 2, dessen Anwendungsfall sich wesentlich erweitert (z. B. ein Kundenservice-Chatbot, dessen Aufgabenbereich auf Rückerstattungsentscheidungen ausgeweitet wird), sollte neu bewertet und gegebenenfalls in Stufe 3 hochgestuft werden. Umgekehrt kann ein System der Stufe 3, das seit zwei Jahren mit erheblicher menschlicher Aufsicht betrieben wird und dessen Risikoprofil nachweislich stabil ist, für eine Herabstufung auf Stufe 2 bei kontinuierlicher Überwachung in Frage kommen. Jede Änderung der Stufe sollte eine dokumentierte Entscheidung und kein Standardprozess sein. Die entscheidende Frage lautet: Würde eine Regulierungsbehörde die neue Klassifizierung angesichts der vorliegenden Beweise akzeptieren?

Agentische Systeme sind der Wendepunkt, den dieses Modell bewältigen muss

Das Vier-Stufen-Modell ist nicht neu. Neu ist jedoch die Geschwindigkeit, mit der Systeme der Stufe 3 eingeführt werden – primär angetrieben durch agentische KI, also jene Klasse von Systemen, die die Erlaubnis erhalten, autonom zu handeln, anstatt nur Ergebnisse zu erzeugen, die von einem Menschen geprüft werden. Das Intake für agentische Systeme unterscheidet sich in drei Punkten grundlegend, die das Vier-Stufen-Modell abdecken muss.

Erstens erfordert die Dimension der Autonomie standardmäßig eine Einstufung in Stufe 3, unabhängig vom zugrunde liegenden Anwendungsfall. Eine agentische KI, die interne Spesenabrechnungen bearbeitet, würde laut dem Anwendungsfall in Stufe 2 fallen. Sobald sie jedoch die Erlaubnis erhält, Spesen tatsächlich einzureichen oder Erstattungen zu veranlassen, wechselt sie in Stufe 3. Das Risikoprofil bemisst sich nicht nach der „Art der Entscheidung“, sondern nach der „Art der Handlung“.

Zweitens muss das Intake für agentische Systeme die Grenzen der Befugnisse explizit erfassen. Ein agentisches Intake der Stufe 3 sollte festlegen, welche Tools der Agent aufrufen darf, welche Aktionen er ohne menschliche Bestätigung ausführen kann, welche Eskalationsbedingungen eine Übergabe an den Menschen auslösen und wie das Verhalten zwischen den Bestätigungen überwacht wird. All dies lässt sich nicht mit der Fragebogenstruktur abbilden, die für statische KI-Systeme funktioniert hat; Formulare für agentisches Intake benötigen in der Regel 30–40 % mehr Dimensionen, die sich auf den Handlungsspielraum statt auf die Datenverarbeitung konzentrieren.

Drittens wird der Begriff der „wesentlichen Änderung“ hier anders ausgelegt. Bei einem statischen KI-System sind Modell-Updates die primären Auslöser für eine erneute Bewertung. Bei einem agentischen System ist die Erweiterung der Freigabeliste für Aktionen (z. B. dem Agenten erlauben, eine neue API aufzurufen, in ein neues System zu schreiben oder Geldtransfers in einer neuen Kategorie zu tätigen) eine wesentliche Änderung. Diese kann den Rahmen der ursprünglichen Bewertung vollständig sprengen und ist im Modell selbst möglicherweise nicht sichtbar. Der Intake-Prozess für agentische Systeme der Stufe 3 sollte eine explizite Registrierung der Freigabeliste bei der Bereitstellung sowie eine erneute Einbeziehung des Intakes bei jeder Änderung dieser Liste erfordern.

Bei agentischen Systemen lautet die Frage nicht „Welche Art von Entscheidung“, sondern „Welche Art von Handlung“.

Systeme konsistent klassifizieren: Die sieben Dimensionen

Die Zuweisung zu einer Stufe muss für dasselbe Risikoprofil immer zum selben Ergebnis führen, unabhängig davon, welcher Prüfer die Anfrage bearbeitet. Ein schlecht konzipierter Klassifizierungsprozess führt zu Abweichungen; ein gut konzipierter Prozess wendet auf jede Anfrage dieselbe Reihe von Dimensionen an und leitet diese deterministisch weiter. Ein solches Intake-Formular stellt fünf bis acht Fragen zu den unten aufgeführten Dimensionen und nutzt die Antworten für eine deterministische Weiterleitung. Manuelle Überschreibungen gibt es nur in echten Grenzfällen; eine rein manuelle Klassifizierung als Standard führt unweigerlich zu Abweichungen.

Speziell für regulierte Finanzdienstleistungsunternehmen ist die Dimension des Risikomanagements von Modellen mehr als nur eine einfache Einstufungshilfe; sie löst einen parallelen Lebenszyklus aus (Modellvalidierung, kontinuierliche Überwachung, regelmäßige Rezertifizierung), den das Intake an die bestehende MRM-Funktion übergeben sollte, anstatt ihn erneut auszuführen. Der Intake-Datensatz für ein KI-System, das in den MRM-Bereich fällt, sollte auf die entsprechende MRM-ID verweisen und den MRM-Workflow nicht duplizieren.

Wenn Dimensionen im Konflikt stehen. Die Dimensionen deuten meist in dieselbe Richtung; gelegentlich ist dies jedoch nicht der Fall. Ein System zur vorausschauenden Wartung in einer Produktionsanlage verarbeitet möglicherweise minimale personenbezogene Daten, trifft keine folgenschweren Entscheidungen über Personen und ist vollständig reversibel. Dennoch kann es Teil eines Produkts im Sinne des Anhangs I (Maschinen) sein, dessen KI-Integration gemäß Artikel 6 Absatz 1 des EU-KI-Gesetzes als hochriskant eingestuft wird.[4] Allein die Kategorie des Anwendungsfalls erzwingt hier Stufe 3, unabhängig von den anderen Dimensionen. Die Regel lautet: Wählen Sie die höchste durch eine einzelne Dimension angezeigte Stufe und dokumentieren Sie die Begründung.

Die Ausnahme nach Artikel 6 Absatz 3. Das EU-KI-Gesetz erlaubt es einem Anbieter, selbst zu bestimmen, dass ein in Anhang III genanntes System nicht hochriskant ist, wenn es lediglich eine rein administrative oder vorbereitende Aufgabe erfüllt oder das Ergebnis einer zuvor abgeschlossenen menschlichen Tätigkeit verbessert, ohne die endgültige Entscheidung zu beeinflussen. Diese Ausnahme ist eng gefasst.[13] Ein KI-Tool, das Lebensläufe für einen menschlichen Prüfer in ein standardisiertes Format bringt, kann darunter fallen. Ein KI-Tool, das dieselben Lebensläufe nach ihrer prognostizierten Eignung sortiert, hingegen nicht – selbst wenn ein Mensch die endgültige Einstellungsentscheidung trifft. Die Sortierung beeinflusst die Entscheidung in einer Weise, die der Gesetzgeber als wesentlich erachtet. Jede missbräuchliche Nutzung der Ausnahme nach Absatz 3 stellt ein regulatorisches Risiko dar. Der Klassifizierungsprozess sollte Feststellungen nach Absatz 3 als dokumentierte Ergebnisse behandeln, die einer klaren Begründung bedürfen, und nicht als reine Abkürzung im Prozess.

Transparenz nach Artikel 50 und warum sie eine eigene Dimension verdient. Artikel 50 des EU-KI-Gesetzes[15] erlegt KI-Systemen Offenlegungspflichten auf, die mit Menschen interagieren, synthetische Inhalte generieren oder Deepfakes erstellen – unabhängig vom zugrunde liegenden Anwendungsfall oder Sektor. Ein Support-Chatbot der Stufe 2 fällt in den Anwendungsbereich von Artikel 50, sobald ein Kunde ihn ohne explizite Offenlegung nicht mehr von einem menschlichen Mitarbeiter unterscheiden kann. Das Intake-Formular sollte direkt auf Artikel-50-Auslöser prüfen. Wenn diese Dimension erst spät im Rahmen einer Konformitätsbewertung nach Anhang III betrachtet wird, führt dies zu Lücken in der Beweisführung, die bei einem Audit auffallen. Ab dem 2. August 2026 ist dies eine strikte Verpflichtung für Anbieter und Betreiber betroffener Systeme und muss im Entscheidungsprotokoll des Intakes dokumentiert sein.

Die Beschaffung eines Kundenservice-Chatbots eines Drittanbieters durch eine Bank verdeutlicht das Zusammenspiel der Dimensionen. Der Anbieter vermarktet das System als „begrenztes Risiko“, da die Interaktionen dialogbasiert sind und menschliche Mitarbeiter die Eskalationen übernehmen. Der Intake-Prozess der Bank wendet die Dimensionen an: Kategorie des Anwendungsfalls (kundenorientiert, kein Anhang-III-Mindestniveau); Datensensibilität (Transkripte können Kontoinformationen enthalten – erhöht die Stufe); Auswirkung der Entscheidung (nur informativ – keine Erhöhung); Reversibilität (Antworten können zurückgenommen werden – keine Erhöhung); Grad der Autonomie (antwortet ohne menschliche Prüfung jeder einzelnen Nachricht – erhöht die Stufe in Richtung agentischer Systeme); Transparenzanforderungen (Artikel 50 greift – Offenlegung des Chatbots erforderlich); Sektorspezifische Anforderungen (Finanzdienstleistungskontext – erhöht weiter); MRM-Auslöser (kein zugrunde liegendes Modell, das für einen Chatbot eines Drittanbieters direkt unter die Finanzregulierung fällt – rein informativ); Quelle (Beschaffung durch Drittanbieter – neues Intake erforderlich). Damit landet das System im oberen Bereich von Stufe 2, je nach Bewertung der Datensensibilität eventuell auch in Stufe 3.

Die Einstufung des Anbieters als „begrenztes Risiko“ ist irrelevant; entscheidend ist die eigene Klassifizierung des betreibenden Unternehmens.

Für das umfassendere Risikomanagement im Umgang mit Drittanbietern, das dieses Intake begleitet, lesen Sie unseren Leitfaden zur Risikobewertung von KI-Drittanbietern.

Der Fünf-Schritte-Workflow, skaliert je nach Stufe

Der Intake-Prozess folgt unabhängig von der Stufe einem bewährten Fünf-Schritte-Modell. Die jeweilige Stufe bestimmt, wie intensiv der Prozess in jedem Schritt ausfällt.

Diagramm des fünfstufigen KI-Governance-Intake-Workflows: Schritt 1 Anwendungsfall identifizieren, Schritt 2 Inventar prüfen, Schritt 3 Risikobewertung, Schritt 4 Prüfung, Schritt 5 Entscheidung. Die Struktur bleibt auf jeder Stufe gleich; die Tiefe der einzelnen Schritte skaliert mit der jeweiligen Stufenklassifizierung.

Die fünf Schritte bleiben über alle Stufen hinweg gleich. Was sich ändert, ist die Tiefe des Prozesses in jedem einzelnen Schritt. Eine Anfrage der Stufe 1 kann in zwanzig Minuten komplett durchlaufen werden; eine Anfrage der Stufe 3 benötigt in der Regel vier bis sechs Wochen allein für die Bewertung, gefolgt von weiteren zwei Wochen für die Prüfung und Freigabe. Die Rollen sollten je nach Stufe klar zugewiesen sein: Bei Stufe 1 fungiert der Antragsteller als verantwortlicher Eigentümer und das System wird automatisch im Inventar erfasst. Bei Stufe 2 liegt die Entscheidungskompetenz beim benannten Genehmiger in der Rechts- oder Risikoabteilung, während der Antragsteller für den laufenden Betrieb verantwortlich bleibt. Bei Stufe 3 hält der fachübergreifende Prüfungsausschuss die Entscheidungsrechte, ein zugewiesener unabhängiger Prüfer verantwortet die Überprüfung der technischen Dokumentation, und der Geschäftsinhaber bleibt für die inhaltliche Nutzung verantwortlich.

Wesentliche Änderungen sind der Auslöser, der den Prozess zurück zu Schritt 3 führt. Artikel 3 Nummer 23 des EU-KI-Gesetzes definiert eine wesentliche Änderung als eine Änderung an einem KI-System nach dessen Inverkehrbringen, die Auswirkungen auf seine Konformität oder seinen Verwendungszweck hat.[14] Analoge Regelungen finden sich in ISO 42001 (wo wesentliche Änderungen eine erneute Bewertung innerhalb des KI-Managementsystems auslösen) und im NIST AI RMF (wo wesentliche Änderungen eine Neukartierung der Risiken erfordern). Praktische Beispiele: Ein Anbieter führt ein Update des Basismodells durch, das das Verhalten des Tools verändert; die Freigabeliste für Aktionen eines agentischen Systems wird um eine neue API erweitert; der Aufgabenbereich eines Support-Chatbots wird auf Rückerstattungsentscheidungen ausgeweitet; die Trainingsdaten für ein feingetuntes Modell werden mit neuen Quellen aktualisiert. Jeder dieser Fälle ist ein Kandidat für eine wesentliche Änderung. Das Intake sollte dann auf der entsprechenden Stufe neu aufgerollt werden – nicht als bürokratischer Selbstzweck, sondern weil die vorherige Risikobewertung möglicherweise nicht mehr zutrifft.

Betrachten wir einen Gesundheitsdienstleister, der 2025 nach einer Prüfung der Stufe 3 eine KI-gestützte Diagnosehilfe eingeführt hat. Die ursprüngliche Bewertung basierte auf einer spezifischen Modellversion, die mit einem bestimmten Datensatz trainiert wurde. Im April 2026 kündigt der Anbieter ein Modell-Update mit neuen Trainingsdaten und einer optimierten Pipeline an. Gemäß den Regeln für wesentliche Änderungen muss der Intake-Prozess des Dienstleisters erneut aktiviert werden, da die Bewertung aus dem Vorjahr das neue Verhalten des aktualisierten Modells möglicherweise nicht abdeckt. Die Neubewertung kann zwar zu dem Ergebnis führen, dass keine Anpassungen erforderlich sind, dies muss jedoch eine dokumentierte Entscheidung sein und darf nicht stillschweigend geschehen.

Vom manuellen zum automatisierten Prozess: Die Plattform-Entscheidung am Wendepunkt

Von vier Stunden pro Anwendungsfall auf unter eine Stunde. Mit demselben Team. Unter Einhaltung derselben regulatorischen Vorgaben. Innerhalb von sechs Monaten.

Das ist die operative Realität bei einem Konsumgüterhersteller, der seinen manuellen Intake-Prozess – basierend auf E-Mails und Google Forms – durch einen automatisierten, gestuften Workflow ersetzt hat. Die verkürzte Bearbeitungszeit ist dabei nur die sichtbare Metrik; die strukturelle Veränderung ist weitaus bedeutender. Vor der Umstellung war das Risikoteam der Flaschenhals für jede KI-Anfrage, unabhängig vom Risikoprofil. Nach der Umstellung konkurrieren risikoarme Anfragen nicht mehr mit Hochrisiko-Projekten um Aufmerksamkeit. Die fachübergreifenden Prüfungsausschüsse können sich auf die Systeme konzentrieren, die dies wirklich erfordern, und der Audit-Trail ist standardmäßig bereit für aufsichtsrechtliche Prüfungen.

Ein gestufter Intake-Prozess lässt sich anfangs manuell betreiben. Die meisten Programme starten so: E-Mail-Formulare, gemeinsame Tabellen und regelmäßige Abstimmungsrunden. Für die ersten ein bis zwei Dutzend KI-Anfragen funktioniert dieses Modell meist gut.

Ab einem bestimmten Volumen wird der Übergang zur Automatisierung jedoch unumgänglich. Die Symptome sind vorhersehbar. Die manuelle Klassifizierung weicht je nach Prüfer ab – dasselbe System erhält unterschiedliche Stufenzuweisungen, je nachdem, wer gerade Dienst hat. Audit-Trails über E-Mail-Verläufe fragmentieren über Teammitglieder, Projektkanäle und gemeinsame Laufwerke hinweg, ohne dass es eine zentrale Informationsquelle gibt, die einer Regulierungsbehörde vorgelegt werden könnte. Auslöser für erneute Bewertungen werden übersehen, weil sie bei einer hohen Anzahl an Systemen nicht mehr manuell nachverfolgt werden können. Anfragen der Stufe 1, die eigentlich automatisiert ablaufen sollten, landen in derselben Warteschlange wie Stufe 3, weil die Routing-Logik nur in den Köpfen einzelner Mitarbeiter existiert und diese sich im Urlaub befinden.

Die benötigten Kernfunktionen sind nicht komplex: ein zentrales Inventar, das mehrere Teams sicher bearbeiten können; eine deterministische Einstufung der Risikostufen anhand der Antworten im Formular; die gezielte Weiterleitung von Anfragen an die zuständigen Prüfer; die automatisierte Erstellung von Dokumenten gemäß regulatorischen Vorgaben und ein manipulationssicherer Audit-Trail, der auch organisatorische Veränderungen überdauert.

Die Entscheidung zwischen manuellem und automatisiertem Intake ist letztlich eine Entscheidung darüber, wie viel Governance-Overhead die Organisation bei der Skalierung der KI-Einführung in Kauf nehmen möchte. Ein gestufter Prozess verzögert diesen Wendepunkt zwar, hebt ihn aber nicht auf. Organisationen, die frühzeitig auf Automatisierung setzen, betrachten die Investition in eine Plattform als strukturelle Voraussetzung für die Skalierung der KI-Nutzung – noch vor Erreichen des kritischen Wendepunkts. Wer wartet, bis bestehende Prozesse bereits unter der Last zusammenbrechen, muss diese Entscheidung meist unter erheblichem Zeitdruck und Kompromissen treffen.

Wie sich das Intake in die bestehende GRC-Landschaft einfügt

Ein Intake-Prozess funktioniert dann am besten, wenn er als zentrales Eingangsportal für bereits etablierte GRC-Prozesse (Governance, Risk, Compliance) wie Lieferantenrisikobewertung, Beschaffung, Sicherheitsüberprüfung und Datenschutzprüfungen dient – und nicht als konkurrierender Parallelpfad. Ein isolierter Intake-Prozess, der neben bestehenden Prüffunktionen läuft, führt zu Doppelarbeit und widersprüchlichen Datenquellen.

Das Ergebnis des Intakes sollte ein einziger Datensatz sein, auf den Beschaffung, Rechtsabteilung, IT-Sicherheit und Datenschutz für ihre jeweiligen Verpflichtungen zugreifen können:

• Das Lieferantenrisikomanagement nutzt den Intake-Datensatz, um vertragliche Bestimmungen zur KI-Nutzung festzulegen (z. B. Fristen für Änderungsmitteilungen, Audit-Rechte, Offenlegungspflichten für Model Cards).

• Die Beschaffung gleicht die Vertragsstruktur mit der Risikoklassifizierung und dem Verwendungszweck des Systems ab. In der Praxis ist die Übergabe an die Beschaffung oft die größte Hürde: Bestehende TPRM-Plattformen (wie OneTrust, ServiceNow Vendor Risk Management oder ProcessUnity) verwalten die Vertragsvorlagen. KI-spezifische Vertragsklauseln müssen direkt in diese Workflows integriert werden, statt sie getrennt zu führen.

• Die IT-Sicherheit prüft anhand der Daten die Anforderungen an die Zugriffskontrolle, die erforderlichen Datenflüsse und das entsprechende Bedrohungsmodell.

• Der Datenschutz nutzt die Angaben für Datenschutz-Folgenabschätzungen (DSFA) oder berechtigte Interessenbewertungen sowie zur Prüfung von Betroffenenrechten und internationalen Datentransfers.

Die Kosten für den Betrieb zweier paralleler Governance-Systeme sind struktureller, nicht inkrementeller Natur.

Der Intake-Datensatz bildet das Fundament für alle nachgelagerten Schritte. Das bedeutet in der Praxis, dass der Intake-Prozess von Anfang an mit Schnittstellen zur bestehenden GRC-Infrastruktur konzipiert werden muss. Weichen die Datenbestände beider Systeme im Laufe der Zeit voneinander ab, steigen die Kosten und der Pflegeaufwand drastisch an.

Das Zusammenspiel zeigt sich am Beispiel des Prozesses für einen KI-Drittanbieter bei einer Bank. Das Intake stößt automatisch die nachgelagerten Prozesse an: Das Lieferantenrisikomanagement erhält den Datensatz und wendet die Standardprüfungen mit KI-spezifischen Erweiterungen an; die Rechtsabteilung prüft den Vertrag im Hinblick auf Ankündigungsfristen und Audit-Rechte; die IT-Sicherheit erhält die Spezifikationen zum Datenfluss für das Bedrohungsmodell; der Datenschutz führt die DSFA auf Basis der im Intake erhobenen Datenklassifizierungen durch. Kein Team muss dieselben Informationen erneut abfragen – alle greifen auf denselben Datensatz zu. Für den Anbieter entsteht so ein konsistentes Anforderungsprofil anstelle von vier parallelen, sich überschneidenden Prüfprozessen.

Fehlermuster beim gestuften Intake (und wie man sie behebt)

Das gestufte Intake scheitert meist an sieben typischen Mustern. Die ersten fünf treten in der Regel innerhalb der ersten 18 Monate auf; die letzten beiden zeigen sich oft erst im zweiten oder dritten Jahr und bringen Programme, die die Anfangsphase überstanden haben, schleichend zu Fall. Jedes dieser Muster verfügt über ein klares Warnsignal, das sich in Governance-Prüfungen identifizieren lässt, sowie über eine strukturelle Lösung.

Details zum häufigsten Fehler in der Anfangsphase. Das Intake als einmaliges Ereignis zu betrachten, ist das Fehlermuster, in das die meisten Unternehmen zuerst geraten. Es verursacht langfristig die höchsten Kosten. Das Signal: Eine quartalsweise Inventarprüfung deckt drei oder vier Systeme auf, die sich seit ihrer letzten Bewertung wesentlich verändert haben (z. B. durch ein Update des Anbieters, einen erweiterten Anwendungsfall oder neue Datenquellen), ohne dass ein neues Intake durchgeführt wurde. Nach zwölf Monaten sind die Risikoklassifizierungen im Inventar veraltet; nach achtzehn Monaten spiegelt der Audit-Trail nicht mehr wider, was die produktiven Systeme tun. Die Lösung ist struktureller Natur: Jedes System oberhalb von Stufe 1 benötigt einen festen Turnus für die jährliche (Stufe 2) bzw. halbjährliche (Stufe 3) Neubewertung sowie eine klare Liste von Ereignissen, die eine sofortige Neubewertung erzwingen. Beide Vorgaben müssen direkt bei der ersten Freigabe im System hinterlegt werden.

Warum die Fehler ab dem zweiten Jahr schwerwiegender sind. Der Verlust der Unterstützung durch das Management und das Verkommen von Gremien zu reinen Formalitäten sind die Faktoren, die etablierte Programme scheitern lassen. Beide Prozesse verlaufen meist unbemerkt. Sie treten erst dann zutage, wenn ein Vorfall das Unternehmen zwingt, nachzuweisen, dass seine Governance zum Zeitpunkt der Systemgenehmigung robust und belastbar war. Die strukturellen Gegenmaßnahmen (wie quantifizierte Risikokennzahlen im Vorstand, die Rotation von Prüfern und die Dokumentation von Gegenmeinungen) sind operativer Natur. Sie müssen im Programm verankert sein, bevor ein Vorfall eintritt. Eine nachträgliche Implementierung wird von Regulierungsbehörden meist als reine Alibi-Governance gewertet.

Für das umfassendere Management von Inventaren, das diese Prozesse unterstützt, lesen Sie unseren Leitfaden zum Aufbau eines Inventars für KI-Systeme.

Benchmarks für das erste Jahr: So sieht ein erfolgreicher Prozess aus

Die folgenden Kennzahlen zeigen die typische Entwicklung eines gestuften Intake-Programms in den ersten 12 bis 18 Monaten sowie den Reifegrad, den die meisten Organisationen bis zum dritten Jahr erreichen. Die Zielwerte basieren auf den Erfahrungen aus den Kundenprojekten von Enzai.[16] Die tatsächlichen Werte können je nach Ausgangslage, Branche und Automatisierungsgrad variieren. Programme, die nach zwölf Monaten deutlich unter den Werten für das erste Jahr liegen, weisen meist eines der oben beschriebenen Defizite auf.

Ein Programm, das keinerlei Anfragen auf Stufe 4 verzeichnet, übersieht vermutlich die kritischsten Fälle. Ein Programm, bei dem fast jede Anfrage auf Stufe 3 landet, hat den Klassifizierungsprozess aufgegeben und betreibt eine defensive Überregulierung auf Kosten der operativen Geschwindigkeit. Beide Zustände zeigen, dass die Klassifizierungslogik überprüft werden muss.

Das Proportionalitätsprinzip in der Praxis

Das gestufte Intake ist die operative Umsetzung des Proportionalitätsprinzips, das mittlerweile in jedem wichtigen KI-Regelwerk verankert ist: Das Vier-Stufen-Modell liefert die Struktur, die Risikodimensionen liefern die Routing-Logik, der Fünf-Schritte-Workflow bildet den Prozessrahmen für jede Stufe und die Benchmarks dienen der Qualitätskontrolle.

Ein gestuftes Intake schafft jene Transparenz, die eine rein dokumentenbasierte Governance nicht leisten kann. Mit einem funktionierenden Prozess kann die KI-Nutzung skalieren, ohne dass das Steuerungsteam den Fokus auf die kritischen Bereiche verliert: Riskante Fälle werden sofort beim Intake identifiziert, unkritische Anwendungen können ohne Verzögerung ausgerollt werden und der Audit-Trail entsteht automatisch als Nebenprodukt des Prozesses.

Der entscheidende Aspekt, den es zu beachten gilt und auf den auch Regulierungsbehörden achten, ist Folgender: Dokumentation darf nicht mit echter Governance verwechselt werden. Ein Programm mit detaillierten Prüfberichten, in dem jedoch niemals eine Anwendung abgelehnt wird (Stufe 4), ist Papiertheater. Das Proportionalitätsprinzip funktioniert nur dann, wenn eine konsequente Ablehnung ebenso Teil der gelebten Praxis ist wie eine angemessene Prüfung.

Für tiefergehende Fragen zu Kontrollmechanismen für agentische Systeme, die vor allem auf den höheren Risikostufen relevant sind, lesen Sie unseren Leitfaden zur Governance agentischer KI.

Häufig gestellte Fragen

Was versteht man unter einem gestuften Intake für die KI-Governance?

Das gestufte Intake ist die operative Praxis, jede KI-Anfrage einer Prüfung zuzuführen, die ihrem spezifischen Risiko entspricht. Die meisten Unternehmen wählen dafür ein Modell aus vier Stufen (Self-Service, Light Review, Full Review, Restricted). Jede Stufe definiert eigene Anforderungen an den Prüfprozess, die Genehmiger, die Dokumentationstiefe und die Intervalle für Folgebewertungen. Dieses Modell löst starre, einspurige Prüfprozesse ab.

Wie viele Stufen sollte ein KI-Governance-Programm im Unternehmen umfassen?

Vier Stufen haben sich in der Praxis als Maximum bewährt. Unternehmen, die weniger als einige hundert KI-Systeme verwalten, können oft mit drei Stufen arbeiten (indem sie Light und Full Review zusammenfassen und die Tiefe über die Fragebögen steuern). Mehr als vier Stufen führen meist zu unnötiger Komplexität, Unklarheiten an den Grenzen der Stufen und einem hohen Abstimmungsaufwand, ohne das Risiko nennenswert besser abzusichern.

Welche KI-Systeme fallen automatisch in Stufe 3?

Jedes System, das unter Anhang III des EU-KI-Gesetzes fällt, Systeme für folgenschwere Entscheidungen über Personen (wie Beschäftigung, Kreditwürdigkeit, Versicherungen, Wohnraum, Gesundheit) sowie agentische Systeme mit autonomer Handlungsfähigkeit, unabhängig von deren konkretem Anwendungsbereich. Es gilt die Regel: Die anspruchsvollste ermittelte Dimension bestimmt die Gesamtstufe.

Wie behandelt das gestufte Intake agentische KI?

Agentische Systeme werden aufgrund ihrer operativen Autonomie standardmäßig in Stufe 3 eingestuft. Das Intake muss hierbei die konkreten Befugnisse (Freigabelisten für Aktionen), die Bedingungen für eine Übergabe an menschliche Bediener sowie die Kontrollmechanismen zwischen diesen Schritten explizit erfassen. Eine Erweiterung der Befugnisse stellt eine wesentliche Änderung dar und erfordert eine erneute Bewertung.

Was löst eine erneute Bewertung eines bereits genehmigten KI-Systems aus?

Jegliche wesentliche Änderung – definiert nach Artikel 3 Nummer 23 des EU-KI-Gesetzes als Änderung nach dem Inverkehrbringen, die die Konformität oder den Zweck des Systems beeinflusst. Dazu gehören Modell-Updates der Anbieter, Erweiterungen der Befugnisse bei Agenten, Anpassungen des Anwendungsbereichs, neue Trainingsdaten oder eine signifikante Erhöhung der Nutzerzahlen. Systeme der Stufe 2 werden meist jährlich, Systeme der Stufe 3 halbjährlich sowie anlassbezogen geprüft.

Wie lange dauert der Aufbau eines gestuften Intake-Prozesses?

In der Regel drei bis sechs Monate für den Aufbau eines manuellen Prozesses für die ersten Anfragen. Neun bis fünfzehn Monate für das Erreichen der Benchmarks des ersten Jahres und achtzehn bis vierundzwanzig Monate für ein voll ausgereiftes Programm. Der Schritt zur Automatisierung wird ab einem Volumen von ca. 50 bis 200 Systemen im Inventar meist unvermeidbar.

Ersetzt das gestufte KI-Intake bestehende GRC-Prozesse?

Nein, es ist diesen vorgeschaltet. Der Intake-Datensatz dient als zentrale Informationsquelle für alle GRC-Beteiligten (Einkauf, IT-Sicherheit, Datenschutz, Lieferantenrisiko), sodass redundante Abfragen vermieden werden. Das separate Betreiben von KI-Intake und klassischen GRC-Prozessen ist einer der häufigsten Fehler; das Intake sollte stattdessen als zentrales Eingangsportal fungieren.

Wie fügt sich Enzai in Plattformen wie ServiceNow oder OneTrust ein?

Enzai fungiert als die KI-spezifische Governance-Ebene, die den klassischen GRC-Systemen vorgeschaltet ist und sich nahtlos in diese integrieren lässt. Die in Enzai erfassten Daten speisen die Workflows der bestehenden Plattformen, während die tiefe KI-Risikobewertung und die Abdeckung der gesetzlichen Anforderungen in Enzai verbleiben. Die meisten Unternehmen nutzen Enzai als spezialisierte Ergänzung zu ihrer GRC-Infrastruktur.

Wie Enzai Sie unterstützt

Dieser Leitfaden beschreibt die methodischen Grundlagen. Enzai bietet die Plattform, um diesen Prozess in die Praxis umzusetzen – vom Vier-Stufen-Modell über die automatisierte Risikoeinstufung bis hin zum revisionssicheren Audit-Trail. Wenn Sie vor der Herausforderung stehen, Ihr Programm zu skalieren, und Ihre Prozesse an den Benchmarks dieses Leitfadens ausrichten möchten, kontaktieren Sie uns. Wir analysieren gerne einen Ihrer aktuellen Anwendungsfälle gemeinsam mit Ihnen im System.

Den vollständigen Leitfaden lesen: Unser Handbuch The Essential Guide to AI Governance – From Policy to Practice behandelt das gestufte Intake im Kontext von Richtlinienentwicklung, Compliance-Vorgaben, Inventarverwaltung und kontinuierlicher Überwachung. Leitfaden herunterladen.

Enzai ist die führende Plattform für KI-Governance in Unternehmen. Sie wurde entwickelt, um abstrakte Richtlinien in überprüfbare Prozesse zu überführen. Unsere Lösung bietet die spezialisierte Infrastruktur für die Steuerung agentischer KI, den Aufbau lückenloser Inventare und die Einhaltung des EU-KI-Gesetzes. Durch die Automatisierung komplexer Abläufe ermöglicht Enzai es Unternehmen, KI-Technologien schnell und konform nach Standards wie ISO 42001 und NIST einzuführen.

Referenzen

1. Verordnung (EU) 2024/1689 des Europäischen Parlaments und des Rates zur Festlegung harmonisierter Vorschriften für künstliche Intelligenz (Gesetz über künstliche Intelligenz). Amtsblatt der Europäischen Union, Juli 2024. eur-lex.europa.eu/eli/reg/2024/1689/oj

2. ISO/IEC 42001:2023, Informationstechnik – Künstliche Intelligenz – Managementsystem. Internationale Organisation für Normung, Dezember 2023. iso.org/standard/81230.html

3. NIST, Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1. National Institute of Standards and Technology, Januar 2023. nist.gov/itl/ai-risk-management-framework

4. Verordnung (EU) 2024/1689, Artikel 6 – Einstufungsregeln für KI-Systeme mit hohem Risiko.

5. Verordnung (EU) 2024/1689, Artikel 5 – Verbotene Praktiken im Bereich der künstlichen Intelligenz.

6. Verordnung (EU) 2024/1689, Anhang III – Hochrisiko-KI-Systeme gemäß Artikel 6 Absatz 2.

7. Verordnung (EU) 2024/1689, Anhang IV – Technische Dokumentation gemäß Artikel 11 Absatz 1.

8. Colorado SB 24-205, Concerning Consumer Protections for Artificial Intelligence, unterzeichnet im Mai 2024. leg.colorado.gov/bills/sb24-205

9. Bank of England Prudential Regulation Authority, Supervisory Statement SS1/23, „Model risk management principles for banks“, Mai 2023. bankofengland.co.uk

10. Board of Governors of the Federal Reserve System, SR Letter 11-7, „Supervisory Guidance on Model Risk Management“, April 2011. federalreserve.gov

11. New York City Local Law 144 of 2021, Automated Employment Decision Tools. nyc.gov/site/dca/about/automated-employment-decision-tools.page

12. California Privacy Protection Agency, Proposed Regulations on Automated Decisionmaking Technology (ADMT). cppa.ca.gov/regulations/

13. Verordnung (EU) 2024/1689, Artikel 6 Absatz 3 – Ausnahme für Systeme des Anhangs III ohne nennenswertes Risiko.

14. Verordnung (EU) 2024/1689, Artikel 3 Nummer 23 – Definition der wesentlichen Änderung.

15. Verordnung (EU) 2024/1689, Artikel 50 – Transparenzpflichten für Anbieter und Betreiber bestimmter KI-Systeme.

16. Die in diesem Abschnitt genannten Zielwerte für Erfassungsrate, Stufenverteilung und Bearbeitungszeiten basieren auf aggregierten Daten aus den KI-Governance-Programmen von Enzai-Kunden, die seit mindestens 12 Monaten ein gestuftes Intake betreiben. Die tatsächlichen Verläufe hängen von der Ausgangslage, der Branche und dem Automatisierungsgrad ab; die Zahlen beschreiben ein typisches Betriebsprofil und stellen keine zugesicherte Eigenschaft dar.