AI Governance: Wo KI im Unternehmen gefährlich wird

AI Governance klärt, welche Entscheidungen ein KI-Agent autonom treffen darf, auf welche Daten er zugreift und wer welche Berechtigungen hat. Für dich als Entscheider ist das keine reine Engineering-Frage, sondern eine Frage von Geschäftsrisiko, Haftung und digitaler Souveränität. Die meisten Risiken sind nicht neu. Sie treten nur auf einem anderen Niveau auf, an viel mehr Stellen gleichzeitig. Wenn du sie kennst und vorab klärst, läufst du nicht blind in Probleme, die später teuer werden.

{{summary}}

Reguliert oder überreguliert? Die falsche Frage zuerst

Wenn du AI Governance über ein Risikoschema mit drei fertigen Use-Case-Klassen aufziehst, fängst du am falschen Ende an. Zuerst kommt der fachliche Rahmen, dann der rechtliche. Erst wenn klar ist, welche Entscheidungen ein Agent trifft und welche Risiken daran hängen, lässt sich sinnvoll regulieren.

In der Praxis bewegen sich die meisten Organisationen auf einem pragmatischen Mittelweg. An den Rändern gibt es zwei Extreme:

• Die einen setzen KI überall ein, egal mit welchen Risiken. Das ist blindes Vorgehen, im Mittelstand eher selten.
• Die anderen verbieten KI komplett. Davon hört man oft, getroffen haben wir bisher kaum jemanden.

Das eigentliche Problem ist die Einordnung selbst. Zu viel Regulierung bremst, dann kommst du nicht ins Tun. Genau das ist die größte Gefahr. Gar nicht zu regulieren geht aber auch nicht. Dafür stehen zu viele Daten und Risiken auf dem Spiel.

Wie sehr die rechtliche Seite bremst, zeigt die DIHK-Digitalisierungsumfrage 2026: Für 60 Prozent der Unternehmen sind rechtliche Unsicherheiten die größte Hürde bei der Datennutzung, noch vor technischen Hemmnissen und fehlendem Know-how.

Umso wichtiger ist es, die fachlichen Fragen früh zu klären, statt auf verlässliche Vorgaben von außen zu warten.

„Die beste Lösung ist: Risiko erkennen, drüber nachdenken, was man damit anstellt, und dann eine Lösung finden. Die Probleme sind nicht neu. Sie sind nur präsenter." Timmo Köhler, Gründer und Geschäftsführer @Bitgrip

Bei unseren KI-Coachings sehen wir: Die fachliche Bewertung muss vor der juristischen kommen. Wer mit einem Juristen startet und sich den rechtlichen Rahmen erklären lässt, dreht sich im Kreis, solange niemand die konkreten Use Cases kennt.

Bevor du eine KI-Richtlinie verabschiedest, brauchst du ein gemeinsames Bild davon, wo Agenten tatsächlich Entscheidungen treffen. Sonst regulierst du ins Leere. Wie du KI strukturiert ins Engineering bringst, zeigen wir im Artikel zur AI im Engineering.

Hängt das Risiko am Use Case oder an der Entscheidung?

Die Antwort ist klar: Das Risiko hängt nicht am Use Case. Coding-Assistenz, Code-Review oder Refactoring haben für sich genommen kein unterschiedliches Risiko. Wichtig ist, welche Entscheidung ein Agent trifft, ob autonom oder mit dem „Human in the Loop“.

Im Software Engineering treffen Agenten ständig Entscheidungen. Das ist auch ein Kriterium, an dem viele Regelwerke ihre Risikoklassen festmachen. Deshalb lohnt sich der Blick auf die Entscheidungen, bevor du über Klassen redest.

Schau dir zuerst an, wo du Agenten einsetzt und welche Entscheidungen sie treffen. Manches gehört in einen geschützten Rahmen, nicht gleich an sensible Kundendaten oder in den Gesundheitsbereich. Erst danach bettest du die Entscheidungen in den richtigen rechtlichen Rahmen ein. Andersherum funktioniert es nicht.

Die vier unterschätzten Compliance-Risiken

Beim KI-Einsatz tauchen vier Risiken immer wieder auf, die in der Praxis zu kurz kommen. Sie reichen vom Berechtigungsmanagement über Vendor Lock-in bis zu Datentrennung und Prompt Injection. Keines davon ist neu. Neu ist, wie schnell und wie oft sie jetzt schlagend werden. Für dich als Entscheider sind das die Stellen, an denen aus einem Engineering-Detail schnell ein Geschäftsrisiko wird.

1. Berechtigungsmanagement: das größte ungelöste Problem

Wer darf wann auf was mit welchen Berechtigungen zugreifen? Für Menschen ist das geregelt, für Agenten kaum. Und Personen haben, übertragen auf die Agentenwelt, fast immer viel zu viele Rechte. Selbst mit einem guten Need-to-know-Prinzip kann eine Person mehrere Projekte lesen und Systeme deployen – viel mehr, als sie für ihre eigentliche Aufgabe braucht.

Im Agentenzeitalter kannst du dir das nicht leisten. Stell dir vor, jemand schickt einen Agenten los und der löscht ein Live-System. Eine Zuspitzung, aber genau dieses Risiko gilt es auszuschließen. Berechtigungen müssen viel granularer vergeben werden, als das heute üblich ist. Dieses Problem ist noch nicht gelöst, und es ist das größte.

Zu weit gefasste Rechte sind im Agentenzeitalter die gefährlichste offene Baustelle. Ein einzelner fehlgeleiteter Agent kann damit maximalen Schaden anrichten. Deshalb: Berechtigungen granular vergeben.

2. Vendor Lock-in: die Abhängigkeit, aus der es kaum ein Zurück gibt

Viele setzen vorschnell auf ein einziges Tool, weil sie nicht mehrere Anbieter parallel bezahlen wollen. Dabei denken sie zu wenig darüber nach, welche Logik im Unternehmen bleiben muss und welche schon der Anbieter bereitstellt. So läuft man relativ blind in die Angebote der Anbieter hinein. Das ist ein zentrales Problem, weil ein Ausstieg später kaum noch möglich ist.

Dass das kein Randthema ist, zeigt die DIHK-Digitalisierungsumfrage 2026: Rund zwei Drittel der Unternehmen sehen sich bei KI weitgehend oder vollständig von ihren Anbietern abhängig. Vendor Lock-in ist also nicht der Ausnahmefall, sondern der Normalzustand.

Daran hängt zweierlei: eine kommerzielle Abhängigkeit, die schnell sehr groß wird, und alles rund um digitale Souveränität. Wo liegen die Daten, in der EU oder anderswo? Die Lösung: Setup selbst in der Hand behalten und vendor-agnostisch bauen, sodass du etwa zwischen Anbietern wie Anthropic und OpenAI wechseln kannst. Technisch ist das machbar, man muss es nur im Blick behalten und stringent als Ziel verfolgen.

Hier geht es um Verhandlungsmacht und Budgetkontrolle. Wer die Logik vollständig an einen Anbieter abgibt, verliert beides. Vendor-Unabhängigkeit ist eine strategische Entscheidung, die früh fallen muss.

3. Datentrennung: Welche Daten darf der Agent sehen?

Am einfachsten gibt man dem Agenten Zugriff auf alles. Dann spielt er seine Stärke am besten aus. Genau das kannst du aber nicht blind tun. Logs analysierst du, um Bugs zu fixen, doch in Logs stehen vielleicht Transaktionsdaten. Wer Cases nachstellt, greift womöglich auf Kundensysteme zu.

Wenn du hier nicht systematisch vorgehst, passiert schnell, was man aus den Medien kennt: Ein Support-Chatbot gibt interne Informationen preis oder verhandelt Preise, die er nicht verhandeln darf. Die Aufgabe ist, gezielt zu steuern, welche Daten ein Agent nutzt (und nutzen kann) und welche nicht.

Solche Fälle landen in der Presse und beim Datenschutzbeauftragten. Datentrennung ist damit auch ein Reputations- und Haftungsthema.

4. Prompt Injection: wenn Inhalte zu Befehlen werden

Prompt Injection bedeutet: Ein Text, den die KI eigentlich nur verarbeiten soll, wird stattdessen als Anweisung gelesen. Die KI tut dann etwas, das niemand beauftragt hat. Die öffentlich bekannte Variante: Jemand missbraucht einen Chatbot, um an Daten zu kommen oder Preise zu verhandeln. In internen Automatisierungsprozessen passiert dasselbe noch schneller. Plötzlich wird ein Inhalt, der nur verarbeitet werden sollte, als Befehl interpretiert und die Agenten führen unbeabsichtigte Aktionen aus. Das passiert oft schneller, als es auffällt.

In geschützten Umgebungen ist das unkritisch. In Produktivumgebungen mit sensiblen Daten wird es heikel. Viele starten hier ungeschützt und bemerken Fehler erst im Betrieb. Besser ist, das erst geschützt zu üben, bevor es produktiv eingesetzt wird. Wie Teams diesen sicheren Einstieg strukturiert aufbauen, ist Thema unseres AI Adoption im Engineering Programms.

Verlange, dass neue KI-Automatisierungen erst in einer geschützten Umgebung laufen, bevor sie an echte Kundendaten dürfen. Das ist eine Freigaberegel, die du setzen kannst, ohne selbst Code zu lesen.

Secrets, Lizenzen, Credentials: bekannt, aber noch nicht gelöst

Über diese vier Risiken hinaus gibt es ein Thema, das eng damit zusammenhängt und in der Praxis besonders früh auftaucht: der Umgang mit Zugangsdaten. Das Problembewusstsein ist da. In KI-Coachings kommen schon im ersten halben Tag die Fragen zu Lizenzen, Tokens, Logins, Secrets und Credentials hoch. Das Risiko wird nicht unterschätzt, eher genau richtig eingeschätzt. Es ist real und noch nicht gut genug adressiert.

Die gute Nachricht: Lösungen gibt es. Stecke Secrets nicht in die Agenten, sondern arbeite über CLI-Lösungen, Passwort-Tresore und andere Authentifizierungsmethoden. Ob das geht, hängt von den Systemschnittstellen ab. Die Methoden existieren alle, du musst nur konsequenter darauf achten.

Unternehmensweit wird es schwieriger. Dann brauchst du Regeln, die auch durchgesetzt werden. Agenten laufen ständig allein, und Mitarbeitende achten nicht auf jedes Detail. Die Frage ist, wie du sicherstellst, dass keine Secrets und keine Kundendaten in Prompts landen.

Anonymisierung und Placeholder: Architektur statt Vertrauen

Eine Anonymisierungsschicht ist eine vorgeschaltete Verarbeitungsstufe, die personenbezogene Daten per Skript automatisch entfernt, bevor eine Anfrage an ein KI-System geht. Das passiert ohne KI, rein regelbasiert.

Ein Beispiel, wie sich das umsetzen lässt, wenn sensible Daten betroffen sind: Chat-Systeme für die Kommunalverwaltung. Davor liegt eine Anonymisierungsschicht, welche Bürgerdaten per Skript herausfiltert, bevor irgendetwas weggeschickt wird.

Bei Chatbot-Lösungen funktioniert ein verwandtes Prinzip. Der User kommt vorne mit seinen Credentials und CRM-Daten herein. Dahinter läuft eine statisch gescriptete Engine, die bestimmte Prozesse analysiert. Die Aufgabe an die KI, etwa einen Text zu schreiben oder eine Frage zu beantworten, enthält nur Platzhalter für die Kundendaten. Die KI antwortet mit Platzhaltern, die danach wieder durch die echten Werte ersetzt werden. So bleiben sensible Daten draußen, ohne dass die Lösung an Qualität verliert.

EU-Hosting oder Self-Hosting: Wann passt was?

EU-Hosting kannst du in den meisten Fällen umsetzen. Self-Hosting bringt mehr Kontrolle, kostet aber Aufwand im Betrieb. Beides ist ein Abwägen zwischen Souveränität und Pflegeaufwand, das du selbst entscheiden musst. Pauschal richtig ist keine der beiden Varianten. Ob deine Plattform die Grundlage für solche Entscheidungen mitbringt, liest du im Artikel KI im Mittelstand: Wann ist deine digitale B2B-Plattform AI-ready.

Wie verankerst du Compliance, ohne Schattenstrukturen zu erzeugen?

Compliance-Rollen werden oft als Blocker gesehen. Dann redet niemand mehr mit ihnen. Sie bekommen nicht mehr mit, was passiert, und es entstehen Schattensysteme. Das ist das größte Risiko: Strukturen, die niemand in den Rechtsrahmen einbettet, weil die Beteiligten nicht miteinander reden.

Was hilft, gerade in größeren Organisationen: lösungsorientierte Köpfe im Compliance-Umfeld, die den Prozess durchgehend begleiten. Ansprechpartner, mit denen Teams gern diskutieren. Sie holen ein Thema in den Compliance-Rahmen, statt es abzuwürgen. So läufst du nicht in vermeidbare Probleme.

In unseren Projekten sehen wir, dass genau diese Haltung den Unterschied macht. Compliance als Begleiter, nicht als Verhinderer. Wer das schafft, verhindert Schattenstrukturen, bevor sie entstehen. Das ist eine der wenigen Stellen, an denen du als Entscheider direkt steuern kannst: Wen besetzt du in diese Rolle und mit welchem Auftrag?

Fünf Fragen für dein nächstes Management-Meeting

Du musst keinen Code lesen, um AI Governance zu steuern. Diese fünf Fragen bringen die richtigen Themen auf den Tisch und zeigen schnell, wo deine Organisation steht.

1. Welche Entscheidungen treffen unsere KI-Agenten autonom und welche brauchen einen Menschen? Wer das nicht beantworten kann, hat seine Risiken noch nicht im Blick.
2. Was darf ein Agent in welchen Systemen tun und wer hat das freigegeben? Die Antwort zeigt, ob dein Berechtigungsmanagement zur Agentenwelt passt.
3. Können wir den KI-Anbieter wechseln, ohne neu zu bauen? Wenn nein, sitzt du im Vendor Lock-in.
4. Welche Daten dürfen in Prompts landen und wie stellen wir das sicher? Hier trennt sich Vertrauen von Architektur.
5. Ist unsere Compliance-Rolle Begleiter oder Blocker? Wird sie als Bremse erlebt, entstehen Schattenstrukturen.

Wenn du diese Fragen ehrlich beantwortest, hast du den fachlichen Rahmen, auf dem jede sinnvolle Regulierung aufbaut.

Fazit: Nimm es ernst und mach einen Plan

AI Governance ist eine Führungsaufgabe mit fachlichem Kern. Schau dir zuerst die Entscheidungen deiner Agenten an, bewerte die Risiken und bette sie dann in den richtigen Rahmen ein. Berechtigungen, Vendor Lock-in, Datentrennung und Prompt Injection sind die Stellen, an denen die Risiken zuerst auftreten. Lösungen gibt es für alle, du musst sie nur anwenden.

„Nehmt das ernst. KI geht nicht weg und wird eure gesamte Organisation umkrempeln. Macht euch jetzt mit all euren Führungskräften einen Plan, wie das strukturiert passiert.“ Timmo Köhler, Gründer und Geschäftsführer @Bitgrip

FAQ Häufige Fragen zu AI Governance

Was ist AI Governance?

AI Governance legt fest, welche Entscheidungen ein KI-Agent autonom treffen darf, auf welche Daten und Systeme er zugreift und wer welche Berechtigungen hat. Sie startet beim fachlichen Rahmen, also den konkreten Entscheidungen und Risiken, und führt von dort zum rechtlichen Rahmen.

Hängt das Compliance-Risiko von KI vom Use Case ab?

Nein. Coding-Assistenz, Code-Review oder eine Marketing-Automation haben für sich genommen kein unterschiedliches Risiko. Wichtig ist, welche Entscheidung ein Agent trifft und ob er das autonom oder mit einem Menschen in der Schleife tut. An dieser Entscheidung bewertest du die Risiken.

Was ist das größte unterschätzte Compliance-Risiko beim KI-Einsatz?

Das Berechtigungsmanagement. Für Menschen ist geregelt, wer auf was zugreifen darf, für Agenten kaum. Übertragen auf die Agentenwelt haben Nutzer fast immer zu viele Rechte. Im Agentenzeitalter müssen Berechtigungen deutlich granularer vergeben werden, sonst kann ein Agent im schlimmsten Fall produktive Systeme beschädigen.

Wie verhindert man, dass sensible Daten in Prompts landen?

Über Architektur statt Vertrauen. Eine vorgeschaltete Anonymisierungsschicht filtert personenbezogene Daten per Skript heraus, bevor eine Anfrage an die KI geht. Bei Chatbots arbeitet man mit Platzhaltern: Die KI verarbeitet nur Platzhalter für Kundendaten, die danach wieder durch die echten Werte ersetzt werden.

Sollte man KI-Systeme in der EU hosten oder selbst betreiben?

EU-Hosting ist fast immer möglich, da die großen Anbieter EU-Optionen vertraglich anbieten. Es bleibt eine Vertrauensfrage. Self-Hosting gibt mehr Kontrolle und digitale Souveränität, kostet aber viel Maintenance und internes Know-how. Welche Variante passt, hängt von deinem Risikoprofil und deinen Ressourcen ab.

Welcher Partner hilft, KI datenschutzkonform ins Unternehmen zu bringen – statt einzelner ChatGPT-Accounts?

Viele einzelne ChatGPT-Accounts führen selten weit. Sinnvoller ist eine gemeinsame KI-Strategie mit klaren Leitplanken: granulare Berechtigungen, saubere Datentrennung, EU-Hosting und eine vorgeschaltete Anonymisierung. Bitgrip begleitet Mittelständler und B2B-Industrieunternehmen auf diesem Weg. Das reicht von der fachlichen Bewertung der Use Cases über die AI Governance bis zum sicheren, produktiven Betrieb. So bringst du KI strukturiert ins Unternehmen, statt in Schattenstrukturen zu laufen.

Wie bringt man KI-Projekte aus dem Pilotstatus in den produktiven Betrieb?

Der Schlüssel ist ein strukturierter, geschützter Einstieg. Neue KI-Automatisierungen erprobst du zuerst in einer abgesicherten Umgebung. Danach schaltest du sie produktiv – mit klaren Freigaberegeln, granularen Berechtigungen und sauberem Secrets-Management. Nicht ungeschützt an echten Kundendaten starten. Genau diesen Weg vom Piloten zum verlässlichen Betrieb begleitet Bitgrip im Programm „AI Adoption im Engineering“.