Praktische KI-Governance: Ein 7‑Schritte‑Plan für Vorstand und Compliance

Viele Unternehmen starten mit KI pragmatisch: ein Pilot hier, ein Assistenz-Tool dort, erste Automatisierungen in Service und Fachbereich. Das ist nachvollziehbar – und gleichzeitig der Moment, in dem praktische KI-Governance von „nice to have“ zu einer Betriebs- und Haftungsfrage wird. Denn KI verändert nicht nur Oberflächen, sondern Datenflüsse, Entscheidungswege, Verantwortlichkeiten und den Nachweis gegenüber Prüfern. Ohne Governance entstehen typische Muster: Shadow AI (inoffizielle KI-Nutzung), ungeklärte Datenübermittlungen an Dritte, schwer erklärbare Ergebnisse und fehlende Audit-Evidenz.

Dieser Beitrag liefert einen 7‑Schritte‑Plan, der für Vorstand, Compliance, IT-Leitung und Security gemeinsam funktioniert. Der Fokus liegt auf Umsetzbarkeit: Welche Entscheidungen müssen früh fallen? Welche Kontrollen lohnen sich wirklich? Wie bleibt der Betrieb handhabbar, ohne jede Idee totzuregulieren? Wo brauchen Sie Vorlagen, Checklisten und klare Verantwortlichkeiten?

Warum KI-Governance anders ist als klassische IT-Governance

Klassische IT-Governance steuert vor allem Systeme, Änderungen und Zugriffe. KI-Governance muss zusätzlich steuern, wie Ergebnisse zustande kommen und wie sie verwendet werden. Drei Unterschiede sind in der Praxis entscheidend:

• Probabilistische Outputs: KI-Modelle liefern Ergebnisse mit Unsicherheit. Das ist kein Bug, sondern Eigenschaft. Governance muss festlegen, wann menschliche Freigabe zwingend ist und wie Fehlentscheidungen abgefangen werden.
• Daten- und Kontextabhängigkeit: Qualität und Risiken hängen stark von Eingabedaten, Prompting, Kontextfenstern und nachgelagerten Regeln ab. Damit rücken Datenklassifizierung, Protokollierung und Zweckbindung (z. B. DSGVO) ins Zentrum.
• Lieferketten und Abhängigkeiten: Viele KI-Funktionen basieren auf externen APIs, Managed Services oder eingebetteten Modellen. Vendor Risk Management (Drittanbieter-Risikomanagement) wird zur Pflichtdisziplin, inklusive Nachweisen zu Unterauftragsverarbeitern und Datenverarbeitung.

Wer Governance hier wie bei „normaler“ Software behandelt, bekommt zwei typische Fehlsteuerungen: entweder zu wenig Kontrolle (Risiko- und Prüfungsprobleme) oder zu viel Formalismus (Innovation wandert in Schattenprozesse). Der 7‑Schritte‑Plan zielt auf das praktikable Mittel: klare Leitplanken, messbare Kontrollen, schlanke Freigaben.

Der 7‑Schritte‑Plan für praktische KI-Governance

Die Schritte sind bewusst so angelegt, dass Sie innerhalb von 6 bis 12 Wochen einen belastbaren Governance-Grundrahmen schaffen können – und anschließend iterativ vertiefen, statt monatelang ein Papiergebäude zu bauen.

Schritt 1: Scope und Ziele festlegen – inklusive „No‑Go“-Zonen

Starten Sie nicht mit Tools, sondern mit Anwendungsfällen und Risikogrenzen. Der Vorstand braucht eine klare Aussage, welche KI-Nutzungen gewollt sind, welche nur unter Bedingungen und welche vorerst ausgeschlossen werden. Das reduziert Streitfälle in Projekten und verhindert, dass Teams aus Unsicherheit inoffizielle Lösungen nutzen.

Praktische Ergebnisse aus Schritt 1:

• KI-Geltungsbereich: Welche Bereiche sind betroffen (z. B. Kundenservice, HR, Finanzprozesse, Entwicklung, IT-Betrieb)?
• Erlaubte KI-Kategorien: z. B. Textzusammenfassung interner Dokumente, Assistenz im Ticketing, Klassifikation von E-Mails, Knowledge-Base-Suche.
• No‑Go‑Zonen: z. B. vollautomatische Ablehnung von Krediten/Anträgen ohne menschliche Prüfung, automatisierte HR-Entscheidungen mit personenbezogenen Daten, Nutzung nicht genehmigter Public-KI mit vertraulichen Informationen.
• Messziele: nicht „KI einführen“, sondern z. B. Durchlaufzeit im Support senken, Recherchezeit reduzieren, Qualitätskennzahlen verbessern – mit klarer Verantwortung für Nebenwirkungen (Fehlklassifikationen, Eskalationen).

Audit-Perspektive: Prüfer fragen früh, ob es eine nachvollziehbare Management-Entscheidung gibt, in welchen Prozessen KI überhaupt eingesetzt werden darf. Wenn das fehlt, wird jedes Projekt zum Einzelfall mit hohem Nachweisdruck.

Schritt 2: Rollen, Verantwortlichkeiten und Eskalationswege definieren (RACI)

KI-Governance scheitert selten an Technik, sondern an unklarer Zuständigkeit. Sie brauchen mindestens vier Rollencluster, die in einer RACI-Matrix (Responsible, Accountable, Consulted, Informed) abgebildet werden:

• Business Owner: fachlich verantwortlich für Nutzen, Prozessintegration, Akzeptanz und KPIs.
• IT/Plattformverantwortliche: verantwortlich für Betrieb, Schnittstellen, Identity & Access Management (IAM), Protokollierung und Kostenkontrolle.
• Security & Datenschutz: verantwortlich für Schutzbedarf, Datenflüsse, technische und organisatorische Maßnahmen, DSGVO-Konformität.
• Compliance/Risikomanagement: verantwortlich für Policy-Set, Risikoklassifizierung, Kontrollnachweise und Audit-Trails.

Wichtig ist ein klarer Eskalationsweg: Wer entscheidet bei Konflikten zwischen Nutzen und Risiko? In der Praxis bewährt sich ein kleines KI-Governance-Gremium mit fester Taktung (z. B. alle zwei Wochen) und einem Notfallpfad für dringende Änderungen.

Wenn Sie bereits einen Change-Approval-Prozess für kritische Systeme haben, können Sie KI-Änderungen (Model-Update, Prompt-Policy, neue Datenquelle, neuer Provider) daran anlehnen – allerdings mit KI-spezifischen Prüfpunkten (siehe Schritt 5 und 6).

Schritt 3: KI-Use-Cases inventarisieren und in Risikoklassen einteilen

Ohne Inventar gibt es keine Steuerung. Ihr Ziel ist ein KI-Register, das mindestens alle produktiven und pilotierten KI-Anwendungsfälle abbildet, inklusive Schattennutzung, soweit auffindbar. Der Aufwand lohnt sich, weil Sie damit Prioritäten setzen: hohe Risiken zuerst, niedrige Risiken mit Standardkontrollen.

Eine praxistaugliche Risikoklassifizierung arbeitet mit wenigen Kriterien, die sowohl IT als auch Compliance bewerten können:

• Impact: Kann das Ergebnis finanzielle Schäden, Rechtsfolgen, Sicherheitsprobleme oder Reputationsschäden auslösen?
• Automation: Ist der Output entscheidungswirksam (z. B. automatische Freigabe/ Ablehnung) oder nur unterstützend?
• Datenkategorie: öffentlich, intern, vertraulich, streng vertraulich; zusätzlich personenbezogene Daten (DSGVO) und besondere Kategorien.
• Externe Abhängigkeit: On-Prem/Private Cloud vs. externer KI-Service; Unterauftragsverarbeiter, Datenresidenz, Telemetrie.
• Erklärbarkeit/ Nachvollziehbarkeit: Können Sie im Nachhinein begründen, warum eine Empfehlung entstand, inklusive Eingaben, Versionen, Regeln?

Aus dieser Einteilung leiten Sie ab, welche Use Cases ein „leichtes“ Verfahren bekommen (Standardfreigabe) und welche ein „strenges“ Verfahren (Risikoanalyse, Freigabe durch Governance-Gremium, zusätzliche Tests und Monitoring).

Schritt 4: Daten- und Zugriffsregeln definieren: Was darf in KI hinein – und was kommt heraus?

Der häufigste reale Governance-Vorfall ist nicht das Modell selbst, sondern ein Datenabfluss: Mitarbeitende kopieren vertrauliche Inhalte in ein Public-Tool, oder ein interner Assistent zieht Informationen aus Quellen, die nicht für den Empfängerkreis gedacht sind. Deshalb braucht KI-Governance eine explizite Daten- und Output-Schicht.

Kernbausteine:

• Datenklassifizierung mit KI-Regeln: Für jede Schutzklasse definieren Sie, ob und unter welchen Bedingungen KI-Nutzung erlaubt ist (z. B. nur in genehmigten Mandanten, mit Verschlüsselung, ohne Speicherung beim Provider).
• IAM und Least Privilege: KI-Services bekommen nur die minimal nötigen Zugriffe. Das betrifft API-Keys, Service Accounts und Zugriff auf Wissensdatenbanken, Tickets, Dokumentenmanagement.
• Output-Kontrollen: Regeln gegen Datenleckage im Output (z. B. keine vollständigen personenbezogenen Datensätze in Antworten; Maskierung/Redaktion), plus klare Benutzerhinweise, wann Ergebnisse überprüft werden müssen.
• Protokollierung (Audit-Trail): Für risikoreiche Use Cases müssen Eingaben/Outputs und Versionsstände nachvollziehbar sein – datenschutzgerecht, mit Aufbewahrungsfristen, und geschützt vor Manipulation.

Technisch bedeutet das häufig: Trennung von „Chat für Allgemeines“ und „Assistent mit Unternehmensdaten“, zentrale Authentisierung (SSO), DLP-Maßnahmen (Data Loss Prevention) und ein klarer Mechanismus, wie Inhalte in Retrieval-Systeme (z. B. Vektorindex) übernommen werden dürfen.

Schritt 5: Policy-Set erstellen – kompakt, durchsetzbar, auditfähig

Viele KI-Richtlinien scheitern, weil sie entweder zu abstrakt sind oder zu lang, um im Alltag beachtet zu werden. Ein gutes KI-Policy-Set besteht aus wenigen, klar versionierten Dokumenten, die Sie technisch stützen können. Bewährt hat sich eine Dreiteilung:

• KI-Nutzungsrichtlinie: Regeln für Mitarbeitende (zulässige Tools, Datenklassen, Umgang mit Ergebnissen, Pflicht zur Kennzeichnung, Verbot von Copy-Paste sensibler Inhalte in nicht genehmigte Dienste).
• KI-Engineering-/Betriebsstandard: Regeln für IT und Projektteams (Logging, Zugriffskontrolle, Testanforderungen, Change-Management, Notfallabschaltung, Kostenkontrolle, Patch-/Update-Strategie für Modelle/Abhängigkeiten).
• Third-Party-/Vendor-Standard für KI: Mindestanforderungen an Anbieter (Vertragsklauseln, Datenschutz, Subprozessoren, Sicherheitsnachweise, Datenresidenz, Support, Exit-Optionen).

Damit Policies „leben“, brauchen sie einen Lifecycle: Versionierung, Review-Termine, Ausnahmeprozess und Nachweis, dass die Regeln kommuniziert wurden. Für Audit-Reife zählt nicht nur das Dokument, sondern die Durchsetzung.

Als kopierbare Vorlage kann eine kompakte Policy-Struktur so aussehen:

KI-Governance Policy Set (Kurzstruktur)

1. Zweck und Geltungsbereich
2. Begriffe (KI-Service, LLM, Prompt, Output, personenbezogene Daten, Schutzklassen)
3. Zulässige Nutzung (Tool-Liste, Use-Case-Kategorien)
4. Verbotene Nutzung (No-Go-Zonen)
5. Datenregeln (Schutzklassen, Speicherung, Übermittlung, Maskierung)
6. Rollen & Verantwortlichkeiten (RACI, Eskalationen)
7. Freigabeprozess (Risikoklasse → erforderliche Checks)
8. Logging & Audit-Trail (Inhalte, Aufbewahrung, Zugriff)
9. Security-Anforderungen (IAM, Schlüssel, Netz, Isolation, Monitoring)
10. Vendor-Anforderungen (DPA/AVV, Subprozessoren, Exit)
11. Incident Response (Meldeschwellen, Abschaltung, Kommunikation)
12. Ausnahmen und Sanktionen
13. Review-Zyklus

Schritt 6: Kontroll- und Nachweisschicht bauen: Tests, Monitoring, Audit-Evidenz

Governance ohne Kontrollen ist Absichtserklärung. Für den Betrieb zählt, dass Sie Risiken erkennen und nachweisen können, dass Sie sie steuern. Das ist besonders wichtig, wenn KI in prozessnahen Softwarelösungen Entscheidungen vorbereitet oder automatisiert.

Ein praxistaugliches Kontrolldesign lässt sich in drei Ebenen gliedern:

• Vor Inbetriebnahme: Risikoanalyse, Datenflussdiagramm, Freigabe, technische Mindestchecks (IAM, Logging, DLP), definierte Akzeptanzkriterien.
• Im Betrieb: Monitoring von Qualität und Sicherheit, Drift-Erkennung (Änderung der Eingabedaten oder Ergebnisverteilung), Kostenmonitoring (Token/Calls), Anomalien (ungewöhnliche Zugriffsmuster), Rate-Limits.
• Nach Änderungen/Vorfällen: Change- und Incident-Dokumentation, Root-Cause-Analyse, Wirksamkeitsnachweise der Gegenmaßnahmen.

Für Audit-Evidenz helfen standardisierte Artefakte, die jedes KI-Projekt ablegt. Beispiele, die Prüfer typischerweise sehen wollen:

• KI-Use-Case-Steckbrief (Zweck, Nutzerkreis, Impact, Datenklassen, Provider, Schnittstellen)
• Datenfluss und Systemgrenzen (wohin gehen Eingaben, wo werden Logs gespeichert, wer hat Zugriff)
• Freigabeprotokoll inkl. Risikoentscheidung und Kompensationsmaßnahmen
• Test- und Abnahmeprotokoll (auch für Prompt-/Policy-Änderungen)
• Monitoring-Berichte und Incident-Records

Wichtig: Nicht alles loggen. Loggen Sie das, was Sie für Nachvollziehbarkeit und Forensik brauchen, und schützen Sie diese Logs als besonders sensible Daten. Für viele Organisationen ist das ein eigener Schutzbedarf (Manipulationsschutz, restriktive Zugriffe, definierte Aufbewahrung).

Schritt 7: Incident Response und „Kill Switch“: Wenn KI falsch liegt oder Daten abfließen

KI-Vorfälle sehen oft anders aus als klassische Incidents. Neben Verfügbarkeit und Performance kommen neue Kategorien hinzu: Datenexfiltration über Prompts, unbeabsichtigte Offenlegung im Output, falsche Empfehlungen mit Prozesswirkung oder die Nutzung eines nicht genehmigten Services. Deshalb braucht KI-Governance ein Incident-Playbook, das Security, Datenschutz, IT-Betrieb und Fachbereich verbindet.

Mindestelemente:

• Meldeschwellen: Was ist ein meldepflichtiger Datenschutzvorfall, was ein Security Incident, was ein Qualitätsvorfall?
• Kill Switch: Technischer Mechanismus, um KI-Funktionen schnell zu deaktivieren oder auf einen „Read-only/Assist“-Modus zurückzuschalten.
• Forensikfähigkeit: Logs, Versionen (Modell, Prompt-Policy, Datenquellen), betroffene Nutzer, betroffene Datensätze.
• Kommunikationsplan: intern (Betrieb, Management), ggf. extern (Aufsichtsbehörde, Kunden), abgestimmt mit Legal/Datenschutz.

Aus Betriebssicht ist der Kill Switch entscheidend: Wenn KI in Workflows eingebettet ist, muss ein Fallback existieren (manuelle Bearbeitung, Regelwerk, klassische Suche), sonst wird das Abschalten politisch unmöglich – und genau dann fehlt Ihnen im Ernstfall die Handlungsfähigkeit.

Regulatorische Einordnung: DSGVO, EU AI Act und interne Kontrollsysteme

In vielen Organisationen läuft die Diskussion zu KI ausschließlich über „EU AI Act“ oder ausschließlich über „DSGVO“. Praktisch brauchen Sie beides – plus Anschluss an bestehende Kontrollsysteme (ISMS nach ISO 27001, interne Kontrollsysteme, Risikomanagement, Change-Management).

DSGVO wird relevant, sobald personenbezogene Daten verarbeitet werden (direkt oder indirekt). Typische Governance-Fragen sind: Rechtsgrundlage, Zweckbindung, Datenminimierung, Speicherbegrenzung, Betroffenenrechte, Auftragsverarbeitung (AVV), Drittlandtransfer und technische/organisatorische Maßnahmen.

EU AI Act (Risikoklassen, Pflichten für Anbieter und Betreiber) beeinflusst vor allem, wie Sie KI-Systeme in bestimmten Kontexten bewerten und dokumentieren. Für Unternehmen zählt: früh erkennen, ob ein Use Case potenziell als hochriskant einzuordnen ist und welche Nachweise dann erforderlich werden. Auch wenn Details je nach finaler Auslegung variieren: Mit dem 7‑Schritte‑Plan bauen Sie genau die Artefakte auf, die typischerweise gefordert sind (Risikomanagement, Daten-Governance, Monitoring, Dokumentation, menschliche Aufsicht).

Wichtig für Vorstände: Regulierung ist selten das eigentliche Kostenproblem. Teuer wird es, wenn Governance erst nach dem Rollout „nachgezogen“ werden muss: dann müssen Datenflüsse umgebaut, Provider gewechselt, Logs nachgerüstet und Prozesse neu abgestimmt werden.

Kosten- und Betriebsfolgen realistisch bewerten

KI-Governance wird oft als „zusätzlicher Overhead“ betrachtet. In der Praxis entstehen Kosten vor allem durch fehlende Standardisierung: Jedes Team baut seine eigene Anbindung, sein eigenes Logging, seine eigene Tool-Auswahl. Der 7‑Schritte‑Plan spart Geld, weil er Wiederverwendung erzwingt.

Relevante Kostenblöcke, die Sie in die Planung aufnehmen sollten:

• Plattformkosten: API-Nutzung, Modelle, Vektor-Datenbanken, Observability. Ohne Budget-Grenzen und Quoten entstehen unvorhersehbare Kosten.
• Integrationskosten: SSO, Rollenmodelle, Berechtigungen auf Datenquellen, Proxy/Netzsegmentierung, DLP.
• Kontrollkosten: Risikoanalyse, Tests, Monitoring, Audit-Artefakte. Diese Kosten sinken stark, wenn Sie Standardvorlagen und wiederkehrende Checks haben.
• Incident-Kosten: forensische Aufarbeitung, Kommunikationsaufwand, ggf. regulatorische Folgen. Ein Kill Switch und saubere Logs sind hier der Unterschied zwischen Stunden und Wochen.

Für IT-Leitung ist wichtig: KI braucht betrieblich eine Eigentümerschaft wie jede kritische Business-Software. „Das macht der Fachbereich“ endet zuverlässig bei ungeklärter Verantwortung für Logs, Zugriff, Updates, Providerwechsel und Notfälle.

Praktische Checklisten: Was Sie in den ersten 30 Tagen liefern sollten

Wenn Sie jetzt starten oder aufräumen müssen, hilft ein klarer 30‑Tage‑Plan. Ziel ist nicht Perfektion, sondern eine erste auditfähige Basis.

Checkliste A: Mindest-Governance (Management-fähig)

• Benennung eines KI-Governance-Owners und eines kleinen Steuerkreises
• Scope und No‑Go‑Zonen schriftlich beschlossen
• Erstes KI-Use-Case-Register (auch Piloten) mit Risikoklasse
• Liste genehmigter KI-Tools/Provider und klare Regeln für Ausnahmen

Checkliste B: Mindest-Kontrollen (IT-/Security-fähig)

• SSO/IAM für genehmigte KI-Tools, Abschaltung anonymer Nutzung
• Datenklassifizierung mit KI-spezifischen Regeln (mindestens „intern/vertraulich“)
• Logging-Konzept inkl. Aufbewahrung, Zugriffsschutz und Verantwortlichkeit
• Incident-Playbook inkl. Kill Switch und Fallback-Prozess

Checkliste C: Mindest-Vendor-Set (Compliance-fähig)

• AVV/DPA und Klarheit zu Subprozessoren
• Regelung zur Datenverwendung (kein Training auf Kundendaten, falls gefordert)
• Datenresidenz und Löschkonzept
• Exit-Optionen (Datenexport, Fristen, Support im Providerwechsel)

Typische Fallstricke – und wie Sie sie vermeiden

1) „Wir machen erst mal Piloten ohne Governance“

Piloten sind wertvoll, aber sie erzeugen Fakten: Daten werden bewegt, Nutzer gewöhnen sich an Ergebnisse, Prozesse ändern sich. Governance muss nicht schwer sein, aber sie muss vor dem Pilotstart die No‑Go‑Zonen, Datenregeln und den Incident-Pfad klären.

2) Policies ohne technische Durchsetzung

Wenn die Richtlinie sagt „keine vertraulichen Daten in Public-KI“, aber das Unternehmen keine genehmigte Alternative anbietet und keine DLP-/Proxy-Kontrollen hat, bleibt nur Appellpolitik. Praktische KI-Governance koppelt Regeln an Umsetzbarkeit: genehmigte Tools, klare Schutzklassen, einfache Wege.

3) Unklare Verantwortung für Prompt-/Policy-Änderungen

Bei KI können kleine Änderungen große Wirkung haben: ein neuer Prompt, eine andere Datenquelle, ein Modellwechsel. Diese Änderungen brauchen ein Change-Verfahren, das leichtgewichtig ist, aber Versionierung und Tests erzwingt – sonst verlieren Sie Reproduzierbarkeit und Audit-Fähigkeit.

4) Keine Sicht auf Shadow AI

Shadow AI ist selten „böswillig“, eher ein Produktivitätsreflex. Sie reduzieren Shadow AI, indem Sie (a) nutzbare, genehmigte Alternativen bereitstellen, (b) klare, faire Regeln definieren, und (c) Risiken erklären: Datenabfluss, Vertragsrisiken, falsche Entscheidungen. Ergänzend helfen technische Erkennungsmechanismen (Proxy-Logs, CASB/DLP), abhängig von Ihrer Umgebung.

Fazit: Praktische KI-Governance ist vor allem Betriebsdisziplin

Die zentrale Management-Entscheidung ist nicht „KI ja oder nein“, sondern: Unter welchen Bedingungen wird KI in Unternehmensprozessen erlaubt, und wie bleibt sie steuerbar? Der 7‑Schritte‑Plan bringt KI aus der Pilotzone in einen kontrollierten Betrieb: mit klaren Rollen, einem Use-Case-Register, Daten- und Zugriffsregeln, kompakten Policies, belastbaren Kontrollen und einem Incident-Playbook inklusive Kill Switch.

Wenn Sie den Rahmen schlank halten und technisch stützen, gewinnen Sie gleich doppelt: Sie reduzieren Risiko und Audit-Stress – und Sie beschleunigen Projekte, weil Teams nicht jedes Mal bei Null anfangen müssen.

Für dieses Thema sind auch Ki-Risikomanagement und Ai Governance wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.