KI-Governance: ein Rahmenwerk für ERP, CRM und KI-Agenten

Montagmorgen, 8:12 Uhr. Die externe Prüferin sitzt bereits im Besprechungsraum, die ERP-Verantwortliche sucht in drei Ordnern nach Nachweisen, und der Fachbereich sagt, der KI-Agent habe die Mahnungen „einfach so“ verschickt. So entsteht die typische Lücke: Ein System wächst, Zugriffe werden verteilt, Automatisierungen kommen dazu, und am Ende weiß niemand mehr sauber, wer was freigegeben hat und wer die Kontrolle beweisen kann.

KI-Governance schließt diese Lücke. Gemeint ist das Regelwerk dafür, wer über KI-Systeme und Agenten entscheidet, was sie dürfen, wie Risiken bewertet werden und woran die Organisation beweist, dass Kontrollen wirklich laufen. Für Unternehmen, die KI in ERP, CRM und Finanzprozesse einbetten, ist das kein Zusatzprojekt, sondern die Erweiterung ihrer bestehenden Security Governance. Dieser Beitrag zeigt, wie ein solcher Rahmen aufgebaut ist, welche Pflichten aus EU AI Act, NIS2 und DSGVO hineingehören und wie Sie Risiken von KI-Connectoren bewerten.

Wenn die Prüfung kommt und niemand zuständig ist

Ein Audit scheitert selten an einer fehlenden Firewall. Es scheitert daran, dass ein ERP-Zugriff historisch gewachsen ist, ein CRM-Plugin noch vom letzten Projekt hängt und ein KI-Agent inzwischen in Slack und E-Mail mitarbeitet, ohne dass jemand die Freigabekette kennt. Dann zeigt sich, dass die Organisation zwar Tools gekauft hat, aber keine belastbare Verantwortungskette.

Häufig verwaltet die IT die Accounts, der Fachbereich definiert Prozesse, ein Dienstleister baut Integrationen, und die Nachweise liegen irgendwo zwischen Ticketsystem, E-Mail und einem halb gepflegten Wiki. Das ist kein Governance-System, sondern eine Sammlung.

Seit die DSGVO am 25. Mai 2018 anwendbar wurde, ist fehlende Steuerung bei personenbezogenen Daten kein Schönheitsfehler mehr, sondern ein Rechts- und Finanzrisiko: Rechenschaftspflicht, Nachweise und Sanktionen sind verbindlich geregelt. Mit dem EU AI Act und dem österreichischen NISG 2026 kommen weitere Pflichten dazu.

Praktische Regel: Wenn Sie für einen Zugriff, eine Automatisierung oder eine Datenfreigabe keinen Owner benennen können, haben Sie dort kein kontrolliertes System, sondern nur eine Duldung.

Warum KI das Problem nicht kleiner macht

KI-Agenten verschärfen die Lage, weil sie nicht nur lesen, sondern handeln. Sobald ein Agent Rechnungen vorbereitet, Kunden anschreibt oder Daten aus einem ERP zieht, braucht er klare Grenzen, klare Rechte und klare Nachweise. Sonst wird aus „Automatisierung“ schnell eine nicht nachvollziehbare Abkürzung.

Viele Unternehmen bauen erst den Agenten und suchen danach eine Governance-Geschichte. Das funktioniert nicht. Die Steuerung muss vorher stehen, sonst prüft die Revision am Ende nur noch, wie viel Risiko ohne kontrollierten Betrieb akzeptiert wurde.

Was ein KI-Governance-Rahmen wirklich ist

Ein Governance-Rahmen ist kein Sicherheitskonzept im PDF-Format. Es ist das operative Regelwerk dafür, wer entscheiden darf, was erlaubt ist, wie Risiken bewertet werden und woran die Organisation beweist, dass Kontrollen laufen. Firewalls, MFA und SIEM sind wichtig, aber sie sind Werkzeuge. Governance ist die übergeordnete Steuerung.

Fünf Bausteine, die tragen

1. Rollen: Jedes kritische System, ob SAP, Dynamics 365, BMD oder ein KI-Agent, braucht eine benannte fachliche und technische Verantwortung.
2. Richtlinien: Sie legen fest, was erlaubt ist, was ausgeschlossen ist und was nur nach Freigabe geht. Eine Richtlinie ohne Durchsetzung ist internes Marketing.
3. Risikomanagement: Hier wird entschieden, welche Risiken akzeptiert, reduziert oder eskaliert werden. Wie das für KI-Connectoren aussieht, beschreibt der Abschnitt zur Risikobewertung weiter unten.
4. Kontrollen: Das sind die messbaren Maßnahmen, also Zugriffsbeschränkungen, Vier-Augen-Prinzip, Logging, Freigabe-Workflows und Review-Zyklen. Die ENISA beschreibt Governance-Rahmen als Grundlage dafür, dass Verantwortung überhaupt rechenschaftsfähig wird.
5. Reporting: Wer Kontrollen nicht regelmäßig berichtet, kennt ihren Zustand nicht. Ohne Kennzahlen und Prüfnachweise wird jedes Policy-Dokument im Ernstfall unverteidigbar.

Für KI kommt ein sechster Baustein dazu: ein Register aller KI-Systeme und Agenten mit Zweck, Datenquellen, erlaubten Aktionen, Owner und Risikoklasse. Ohne dieses Register lässt sich weder die Einstufung nach dem EU AI Act noch eine sinnvolle Kontrolle begründen.

Governance ist kein Regelstapel. Es ist ein Organigramm der Verantwortung mit angeschlossenen Kontrollen.

Rollen, Richtlinien und Nachweise

Governance muss an Entscheidungen hängen, nicht an Absichtserklärungen. Wenn ein KI-Agent eine Mahnung verschickt oder ein CRM-Feld überschreibt, braucht es eine dokumentierte Zuständigkeit, eine erlaubte Aktion, ein Protokoll und einen Review-Punkt. Ohne diese vier Dinge bleibt das Ganze lose gekoppelt und damit prüfungsanfällig. Wie sich Zuständigkeiten sauber trennen lassen, beschreibt unser Beitrag zur Funktionstrennung in KI-gestützten Prozessen.

Der regulatorische Rahmen: EU AI Act, NIS2 und DSGVO

Ein Governance-Rahmen für KI muss die geltenden Pflichten abbilden. Drei Regelwerke sind für Unternehmen in Österreich zentral.

EU AI Act

Der EU AI Act (Verordnung (EU) 2024/1689) ist seit 1. August 2024 in Kraft und gilt gestaffelt:

• Seit 2. Februar 2025 gelten die Verbote bestimmter KI-Praktiken (Art. 5) und die Pflicht zur KI-Kompetenz (Art. 4). Mit der Verordnung (EU) 2026/1744, dem „Digital Omnibus“, wurde Art. 4 abgeschwächt: Anbieter und Betreiber müssen seit 27. Juli 2026 Maßnahmen ergreifen, um die Entwicklung von KI-Kompetenz ihres Personals zu fördern, ein bestimmtes Kompetenzniveau wird aber nicht mehr garantiert verlangt.
• Seit 2. August 2025 gelten die Pflichten für Anbieter von KI-Modellen mit allgemeinem Verwendungszweck (GPAI).
• Ab 2. Dezember 2027 gelten nach der Änderung durch die Verordnung (EU) 2026/1744 die Pflichten für Hochrisiko-Systeme nach Anhang III, etwa für KI im Personalbereich oder bei der Kreditwürdigkeitsprüfung natürlicher Personen. Für Hochrisiko-KI in regulierten Produkten nach Anhang I gilt der 2. August 2028.

Die meisten Unternehmen sind dabei Betreiber (Deployer), nicht Anbieter. Für Betreiber von Hochrisiko-Systemen regelt Art. 26 unter anderem: Nutzung gemäß Betriebsanleitung, menschliche Aufsicht durch Personen mit der nötigen Kompetenz, Schulung und Befugnis (Abs. 2), Überwachung des Betriebs und Aufbewahrung der automatisch erzeugten Logs für mindestens sechs Monate, soweit sie unter ihrer Kontrolle stehen (Abs. 6). Vor dem Einsatz am Arbeitsplatz sind Arbeitnehmervertretung und betroffene Beschäftigte zu informieren (Abs. 7).

Agenten in ERP-, CRM- und Buchhaltungsprozessen sind in der Regel keine Hochrisiko-Systeme. Die Einstufung muss aber dokumentiert sein, und sie ändert sich, sobald ein Agent etwa Bewerbungen vorsortiert oder Kreditentscheidungen über Privatpersonen vorbereitet.

NIS2 und NISG 2026

Österreich setzt die NIS2-Richtlinie mit dem Netz- und Informationssystemsicherheitsgesetz 2026 um. Der Nationalrat hat das NISG 2026 am 12. Dezember 2025 beschlossen, kundgemacht wurde es als BGBl. I Nr. 94/2025. Es tritt am 1. Oktober 2026 in Kraft und löst das NISG 2018 ab.

Für wesentliche und wichtige Einrichtungen bedeutet das: Risikomanagementmaßnahmen für die Cybersicherheit, Meldung erheblicher Sicherheitsvorfälle und die Berücksichtigung von Lieferkettenrisiken. Die NIS2-Richtlinie verlangt außerdem, dass die Leitungsorgane die Maßnahmen billigen, ihre Umsetzung überwachen und an Schulungen teilnehmen (Art. 20). Für KI-Agenten mit Zugriff auf Kernsysteme heißt das: Sie gehören in das Asset-Inventar, in die Risikoanalyse und in die Lieferkettenbewertung, wenn externe Modelle oder Plattformen beteiligt sind. Ob Ihr Unternehmen in den Anwendungsbereich fällt, hängt von Sektor und Größe ab und sollte ausdrücklich geprüft werden.

DSGVO

Sobald Agenten personenbezogene Daten verarbeiten, gelten Rechtsgrundlage, Zweckbindung, Datenminimierung, Verzeichnis der Verarbeitungstätigkeiten und gegebenenfalls eine Datenschutz-Folgenabschätzung. In der Praxis ist die DSGVO oft der erste Prüfstein für KI-Projekte, lange bevor der AI Act greift.

Komponenten, die in ERP-, CRM- und KI-Architekturen zählen

In ERP-, CRM- und Finanzumgebungen zählt nicht, wie sauber ein Framework auf der Folie aussieht. Entscheidend ist, ob die Kontrolle im Betrieb greift. Das NIST Cybersecurity Framework 2.0 ordnet Cybersicherheit in sechs Funktionen: Govern, Identify, Protect, Detect, Respond und Recover. Govern wurde mit Version 2.0 als eigene Funktion ergänzt und umfasst Risikostrategie, Rollen, Richtlinien und die Aufsicht über die übrigen Funktionen.

Die Funktionen in echte Kontrollen übersetzen

Govern legt Risikotoleranz, Rollen, Verantwortlichkeiten und Befugnisse fest, etabliert eine unternehmensweite Richtlinie und nutzt die Ergebnisse des Risikomanagements zur Strategieanpassung. Für KI heißt das: schriftlich festgelegt, welche Aktionen ein Agent autonom ausführen darf, welche eine Freigabe brauchen und wer Ausnahmen genehmigt.

Identify heißt: Welche Systeme, Daten und Agenten gibt es überhaupt? Für ERP und CRM bedeutet das, alle produktiven Instanzen, Integrationen, Servicekonten und Automatisierungen zu erfassen. Bei KI-Agenten und Low-Code-Workflows gehören Auslöser, Datenquellen und Rückschreibungen dazu.

Protect ist der Bereich der harten Schranken: Rollenmodelle, Berechtigungsgruppen, MFA, Verschlüsselung und Freigaberegeln. Für Rechnungsfreigaben braucht es das Vier-Augen-Prinzip, nicht eine freundliche Erinnerung im Posteingang. Wenn Fachbereiche eigene Automatisierungen bauen, gelten dieselben Schranken wie für klassische IT-Prozesse.

Detect braucht klare Signale. Wenn ein KI-Agent plötzlich mehr Datensätze zieht als üblich, auf andere Systeme zugreift oder Workflows außerhalb der vorgesehenen Kette startet, muss das sichtbar werden. Logging ohne Auswertung ist nur Datensammlung; die Details beschreibt unser Beitrag zum Audit-Log-Management.

Respond braucht vorbereitete Reaktionsmuster. Wer einen Agenten abschalten, eine Session sperren oder einen Freigabepfad unterbrechen will, braucht definierte Zuständigkeiten und einen getesteten Kill-Switch. Unter dem NISG 2026 kommen Meldepflichten für erhebliche Vorfälle dazu.

Recover bedeutet Wiederanlauf, Rückabwicklung und Nachvollziehbarkeit. Für ERP und CRM heißt das, Rückfallpläne, Datenkorrekturen und Wiederfreigaben so vorzuhalten, dass Buchungen, Kundenstammdaten und Integrationen nach einem Zwischenfall wieder konsistent sind.

Merksatz: Wenn Sie eine Automatisierung nicht mit einem klaren Owner, einem klaren Scope und einem klaren Eskalationspfad beschreiben können, ist sie nicht produktionsreif.

Risikobewertung für KI-Connectoren

Ein typischer Fall: Ein Team hängt einen KI-Connector an das ERP, damit Rechnungen, Buchungen oder Freigaben schneller laufen. Die Frage, wer die Datenqualität prüft, wer bei Fehlbuchungen stoppt und wer den Schaden trägt, kommt erst nach dem Start. Eine strukturierte Risikobewertung dreht diese Reihenfolge um.

Scope auf drei Ebenen festlegen

Legen Sie in einem Workshop mit Fachbereich, IT, Compliance und Revision zuerst Zielgebiet, Zeithorizont und Systemgrenzen fest. Sonst bewertet jede Gruppe etwas anderes. Bewährt hat sich ein Zuschnitt auf drei Ebenen:

• Technisch: Schnittstellen, Berechtigungen, Datenflüsse, Modellanbieter.
• Organisatorisch: Verantwortlichkeiten, Freigaben, Eskalationswege.
• Fachlich: Risiken für Buchung, Reporting, Servicequalität und Compliance.

Für KI-Connectoren sind Datenintegrität, Datenschutz, Prozessunterbrechung und Modellverhalten die naheliegenden Risikokategorien. Ergänzen Sie die Einstufung nach dem EU AI Act: verbotene Praxis, Hochrisiko nach Art. 6 und Anhang III, Transparenzpflicht oder geringes Risiko.

Definieren Sie den Scope so, dass er prüfbar bleibt. Wenn eine Prüferin die Grenze nicht in zwei Minuten versteht, ist sie zu unscharf.

Qualitativ und quantitativ kombinieren

Eine Risikomatrix ist nützlich für den ersten Überblick, ersetzt aber keine quantitative Betrachtung der wichtigsten Risiken. Der Prozess aus NIST SP 800-30 strukturiert Vorbereitung, Durchführung, Kommunikation und Pflege einer Risikobewertung. Für die Top-Risiken hilft die klassische Verlustlogik: Die Single Loss Expectancy (SLE) ergibt sich aus Asset-Wert mal Exposure-Faktor, die Annualized Loss Expectancy (ALE) aus SLE mal erwarteter jährlicher Häufigkeit.

Die Gegenmaßnahmen müssen konkret sein: Datenqualitätsprüfungen verhindern, dass schlechte Stammdaten in den Prozess laufen. Zugriffsbeschränkungen reduzieren ungewollte Änderungen. Freigabeschritte stoppen riskante Automatisierungen, bevor sie in produktive Daten schreiben. Und bei jedem Agenten sollte dokumentiert sein, ob er nur Vorschläge macht oder tatsächlich Aktionen auslösen darf.

Neubewertung auslösen

Eine Bewertung, die vor sechs Monaten korrekt war, kann heute falsch sein. Legen Sie fest, welche Ereignisse eine Neubewertung auslösen: ein neuer Datenfluss, ein neues Modell oder ein Modellwechsel beim Anbieter, zusätzliche Schreibrechte, neue regulatorische Vorgaben oder ein Vorfall. Die alte Bewertung wird dabei nicht überschrieben, sondern ersetzt und archiviert, damit der Vergleich erhalten bleibt.

Implementierungsfahrplan für Mittelstand und Enterprise

Governance wird nicht als Big-Bang-Projekt eingeführt. Der richtige Weg ist klein, technisch, nachvollziehbar und eng an den wichtigsten Systemen gestartet.

1. Scoping und Inventur. ERP, CRM, Finanzsysteme, Datenflüsse und KI-Agenten werden erfasst, inklusive KI-Register und AI-Act-Einstufung. Ohne Inventur gibt es keinen Schutz und keine Priorisierung.
2. Gremium und Owner. Im Mittelstand reicht meist ein schlankes Governance-Gremium mit benannten System- und Prozess-Ownern. Große Organisationen trennen sauber zwischen CISO-Stab, Fachbereichsverantwortlichen und interner Revision.
3. Pilot mit einem Connector. Nehmen Sie den kleinsten, unkritischsten Connector zuerst. Der Pilot muss Logging, Fehlerbehandlung und Freigaben abdecken. In dieser Phase zählt Beobachtbarkeit, nicht Umfang.
4. Richtlinien und Kontrollen verbindlich machen. Berechtigungen, Freigaben, Logging, Review-Zyklen und Ausnahmeregeln werden umgesetzt. Für KI-Agenten und Low-Code-Flows braucht es eigene Regeln.
5. Erweitern, prüfen, berichten. Weitere Systeme kommen erst dazu, wenn der Pilot stabil läuft. Monatliche Berichte, Review-Termine und dokumentierte Korrekturen machen sichtbar, ob Kontrollen wirken.

Die typischen Stolpersteine in den ersten 90 Tagen: ein zu breiter Scope, ein Gremium ohne Entscheidungsrecht und KI-Agenten, die als Nebenthema behandelt werden. Wer früh eine saubere Registrierungs-, Freigabe- und Monitoring-Logik baut, spart sich später einen teuren Kontrollnachlauf. Wie Sie Governance mit der Automatisierungs-Roadmap verzahnen, beschreibt unser Beitrag zur KI-Strategie.

Kennzahlen, Reporting und typische Prüfungsfallen

Governance ohne Kennzahlen ist Selbsttäuschung. Die Kennzahlen müssen nicht schön sein, sondern belastbar. Starten Sie mit wenigen Werten, die Sie monatlich belegen können:

Erst wenn eine Kennzahl, ein Owner und ein Prüfbeleg zusammenkommen, entsteht ein echtes Steuerungssignal.

Häufige Prüfungsfallen sind dokumentierte, aber nicht gelebte Richtlinien; Kontrollen ohne Evidenz (kein Log, kein Review, kein Protokoll); produktive Agenten ohne Ownership, Änderungsnachweis und Monitoring; und unklare Rollen zwischen IT, Fachbereich und externen Dienstleistern.

Prüfbarkeit heißt nicht, dass alles perfekt läuft. Sie heißt, dass Sie jede Kontrolle belegen können.

Zwei typische Szenarien

Die folgenden Szenarien sind illustrativ und beschreiben Muster, die in ERP- und CRM-Landschaften immer wieder auftreten.

Szenario 1: manipulierte Lieferantenstammdaten. Eine geänderte Bankverbindung im Lieferantenstamm löst eine falsche Überweisung aus, weil das System technisch funktioniert, aber keine Kontrollkette zwischen Änderung, Freigabe und Zahlung hat. Die Abhilfe: ein genehmigter Workflow für Stammdatenänderungen, ein striktes Rollenmodell und automatisches Logging. Entscheidend ist, dass der Stammdatenfluss als Governance-Thema behandelt wird und nicht als IT-Detail.

Szenario 2: ein Agent mit zu viel Freiheit. Ein KI-Agent verschickt in Slack und per E-Mail Inhalte und löst Folgeaktionen aus, ohne dass es eine Governance-Domäne für Agenten gibt. Die Abhilfe: ein Agenten-Register, Freigabeprozesse für ausgehende Aktionen und Monitoring. Wer solche Assistenten baut, sollte die Governance von Anfang an mitdenken; mehr dazu in unserem Beitrag zur Chatbot-Entwicklung.

Beide Fälle zeigen dasselbe: Werkzeuge sind nicht das Problem. Das Problem ist unklare Verantwortung bei wirksamen Aktionen. Gute Governance verhindert nicht die Nutzung, sondern die unkontrollierte Nutzung.

Checkliste für die ersten 30 Tage

• Systeme und Agenten inventarisieren: ERP, CRM, Finance, Schnittstellen und alle KI-Agenten mit Produktivbezug erfassen.
• KI-Register anlegen: Zweck, Datenquellen, erlaubte Aktionen, Owner und AI-Act-Einstufung je System dokumentieren.
• Owner je System benennen: Jeder kritische Baustein braucht eine fachliche und eine technische Verantwortung.
• Schlankes Governance-Gremium festlegen: Fachbereich, IT, Security und Revision, mit Entscheidungsrecht.
• Risikotoleranz schriftlich festhalten: Ohne klare Entscheidungsregeln bleibt jede Ausnahme eine Einzelfalldebatte.
• NISG-2026-Betroffenheit prüfen: Klären Sie, ob Ihr Unternehmen als wesentliche oder wichtige Einrichtung gilt.
• KI-Kompetenz fördern: Dokumentieren Sie, welche Schulungs- und Unterstützungsmaßnahmen nach Art. 4 AI Act bestehen.
• Drei bis fünf Kennzahlen auswählen und das erste Management-Review terminieren.
• ERP- und CRM-Rechte trennen: Fach- und Administratorrechte dürfen nicht vermischt werden.
• Audit-Logs aktivieren und prüfen: Wenn ein System etwas ändern darf, muss es auch protokollieren.

Wenn Sie den Reifegrad Ihrer Organisation einordnen wollen, bietet das KI-Reifegradmodell einen Rahmen; eine Bestandsaufnahme genutzter KI-Tools, Datenrisiken und der AI-Act-Einordnung bietet unser KI-Audit.

Sprechen Sie mit uns

Wenn Sie KI-Governance nicht als Papier, sondern direkt in Ihren ERP-, CRM- und Agenten-Integrationen umsetzen möchten, sprechen Sie mit uns.