Deine KI-Richtlinie im Unternehmen liegt als PDF herum und dein Agent kann sie nicht lesen

Die These in einem Satz: Eine Richtlinie, die man nicht ausführen kann, ist keine Richtlinie, sondern ein Haftungsausschluss. Sie taugt dazu, sie in einem Audit vorzuzeigen, und sie taugt nicht dazu, zu ändern, was das System am Dienstagnachmittag tut. Der Unterschied zwischen beidem liegt nicht in der Sorgfalt der Formulierung: Er liegt darin, ob jemand jeden Satz in eine Bedingung übersetzt hat, die eine Maschine prüfen kann, bevor sie eine Aktion rauslässt.

Eine KI-Richtlinie im Unternehmen, die man nicht ausführen kann, ist keine Richtlinie

Das Muster wiederholt sich in jedem Unternehmen, das die Begeisterungsphase hinter sich hat. Jemand schreibt die KI-Richtlinie im Unternehmen — sechs Seiten, gut formuliert, von Legal geprüft —, sie wandert ins Intranet, wird per Mail kommuniziert, und das Thema gilt als erledigt. Drei Monate später schreiben Agenten an Kunden, sagen Beträge zu und veröffentlichen Aussagen über das Produkt, und keine dieser Aktionen läuft durch irgendetwas, das dem Dokument auch nur ähnelt. Nicht weil jemand absichtlich dagegen verstößt: weil das Dokument nie mit irgendetwas verbunden wurde.

Die Gattung ist übersättigt mit dem einfachen Teil. Es gibt Vorlagen, Checklisten und Leitfäden dazu, was dokumentiert werden muss: Geltungsbereich, Rollen, verbotene Nutzungen, Risikoklassifizierung, Verantwortliche. Das alles ist nötig, und keiner dieser Texte erklärt den teuren Teil, nämlich diesen: wie aus einem auf Deutsch geschriebenen Satz eine Prüfung wird, die in der Produktion läuft und eine Aktion stoppen kann. Dieser Sprung ist die eigentliche Arbeit, und er wird fast nie gemacht.

Sagen wir es ohne Umschweife, weil Geld im Spiel ist: Eine Richtlinie, die nur als PDF existiert, schützt dich vor nichts — mit Glück vor einem Teil der Haftung. Sie verhindert den Fehler nicht, sie erkennt ihn nicht, und sie hinterlässt keine Spur davon, dass man ihn verhindern wollte. Wenn du willst, dass die KI sich benimmt, musst du das Dokument drei Ebenen runterholen: vom Prinzip zur Regel, von der Regel zur prüfbaren Bedingung, von der Bedingung zum Nachweis.

Schritt 1: die Pflicht in prüfbare Bedingungen zerlegen

Nimm jeden Satz der Richtlinie und stell ihm eine einzige Frage: Was müsste bei einer konkreten Aktion wahr sein, damit dieser Satz erfüllt ist? Ist die Antwort lang, mehrdeutig oder vom Urteil dessen abhängig, der hinschaut, ist der Satz noch keine Regel: Er ist eine Absicht. Man muss ihn so lange zerlegen, bis jedes Stück mit Ja oder Nein prüfbar ist.

Ein typisches Beispiel. „KI wird gegenüber Kunden transparent eingesetzt" ist nicht prüfbar. Zerlegt wird daraus dreierlei, das es sehr wohl ist: In jeder von einem automatischen System gestarteten Konversation erklärt die erste Nachricht, dass es ein automatisches System ist; in jedem Kanal, in dem der Kunde einen Menschen verlangen kann, gibt es dafür einen sichtbaren Weg; und keine Nachricht behauptet oder suggeriert, dass sie von einer bestimmten Person aus dem Team geschrieben wurde. Drei Bedingungen, drei mögliche Prüfungen. Das ursprüngliche Prinzip steht weiterhin da, nur lässt es sich jetzt verdrahten.

Zwei Warnungen zu diesem Schritt. Erstens: In der Zerlegung fallen die schwierigen Entscheidungen, nicht beim Formulieren des Prinzips. „Transparent" klingt, als wären sich alle einig; „die erste Nachricht erklärt, dass es ein automatisches System ist" eröffnet eine echte Diskussion über Marketing, Conversion und Tonfall. Diese Diskussion muss geführt werden, und sie hier zu führen ist viel billiger, als sie nach einem Vorfall zu führen. Zweitens: Lässt sich eine Pflicht nicht in prüfbare Bedingungen zerlegen, schreib auch das auf. Es gibt Pflichten, die nur mit menschlichem Urteil erfüllt werden, und sie als solche zu markieren ist nützliche Information, kein Scheitern.

Schritt 2: entscheiden, mit welchem Nachweis jede Bedingung geprüft wird

Eine Bedingung ohne zugewiesenen Nachweis ist eine Bedingung, die niemand prüft. Und hier taucht der Bias auf, der die meisten Versuche ruiniert: Wählt derjenige den Nachweis aus, der ihn implementieren muss, wird er den leicht verfügbaren wählen und nicht den, der die Erfüllung wirklich belegt. Das ist menschlich und vorhersehbar, also korrigiert man es per Design.

Für jede Bedingung sind drei Dinge festzulegen: welche Angabe sie belegt, zu welchem Zeitpunkt man hinschaut und wer antwortet, wenn sie fehlt. Der Nachweis darf sehr simpel sein — der Text der ersten gesendeten Nachricht, der Betrag im Feld des Vorgangs, die Liste der Quellen, die das System zum Formulieren benutzt hat —, und je simpler, desto besser: Eine Prüfung, die nur funktioniert, wenn die ganze Pipeline gesund ist, ist keine Prüfung, sondern eine Hoffnung.

Der Zeitpunkt zählt genauso viel wie die Angabe. Vor der Ausführung zu prüfen — das System stoppt, und nichts passiert — ist nicht dasselbe wie danach zu prüfen — das System handelt, und du erfährst es. Beides ist legitim, und beides kostet Unterschiedliches. Die Faustregel: Alles Unumkehrbare oder für den Kunden Sichtbare wird vorher geprüft; der Rest darf danach geprüft werden, solange jemand ins Protokoll schaut und eine geschriebene Frist dafür existiert. Die Mechanik, die das möglich macht — Protokoll, eingegrenzte Rechte, Handbremse und Audit —, ist ausgearbeitet in Governance und Kontrolle der KI-Automatisierung; was wir hier ergänzen, ist die Etage darüber: was geprüft wird und warum, nicht womit.

Schritt 3: festlegen, was passiert, wenn es scheitert

Das ist der Schritt, den fast niemand aufschreibt, und der einzige, der entscheidet, ob die Kontrolle wirklich existiert. Eine Prüfung ohne definierte Konsequenz endet immer am selben Ort: als Hinweis in einem Dashboard, das niemand öffnet. Für jede Bedingung muss im Voraus eine von vier Antworten festgelegt werden: Die Aktion wird blockiert, sie wird mit fertig aufbereitetem Fall an einen Menschen eskaliert, sie wird protokolliert und durchgelassen, oder sie wird auf eine konservativere Version derselben Aktion heruntergestuft.

Für alles „blockieren" zu wählen ist genauso schlechtes Design wie für alles „protokollieren". Alles zu blockieren macht das System unbrauchbar, und die Organisation lernt blitzschnell, es zu umgehen; alles zu protokollieren produziert ein perfektes Archiv von Verstößen, das niemand gelesen hat. Die Frage, die die Wahl ordnet, ist die übliche: Was kostet der Fehler, und wie lange dauert es, bis man ihn sieht. Teurer und sichtbarer Fehler: eskalieren. Teurer und unsichtbarer Fehler: blockieren. Billiger und sichtbarer Fehler: protokollieren. Und eine Zusatzbedingung, die gern vergessen wird: Die Antwort „eskalieren" ist nur legitim, wenn es echte menschliche Kapazität für dieses Volumen gibt. Eskalierst du mehr Fälle, als dein Team anschauen kann, wird die Warteschlange im Block ohne Lektüre freigegeben — schlimmer als gar keine Kontrolle, weil zusätzlich ein falsches Prüfprotokoll entsteht. Genau dieses Problem behandelt die menschliche Aufsicht über KI im großen Maßstab.

Drei konkrete und billige Beispiele für den Anfang

Du musst nicht die ganze Richtlinie verdrahten, damit die Übung sich lohnt. Drei gut gewählte Kontrollen decken den größten Teil des realen Risikos eines Unternehmens am Anfang ab, und alle drei sind in Tagen implementiert, nicht in Quartalen.

• Kenntlich machen, dass es KI ist. Bedingung: Jede von einem automatischen System gestartete oder geführte Konversation erklärt das in der ersten Nachricht. Nachweis: der gesendete Text. Zeitpunkt: vor dem Senden. Bei Scheitern: Versand blockiert. Abgesehen davon, dass es schlicht richtig ist, gilt seit dem 2. August 2026 eine europäische Transparenzpflicht für Systeme, die für die direkte Interaktion mit Menschen bestimmt sind: Sie müssen so gestaltet sein, dass die Person weiß, dass sie mit einer KI interagiert, es sei denn, das ist offensichtlich. Quelle: Europäische Kommission, Transparency obligations under Article 50 of the AI Act (Verordnung (EU) 2024/1689), abgerufen am 14. September 2026. Schau es dir mit deiner Rechtsberatung an: Der Anwendungsbereich und die Rolle, die auf dich zutrifft — Anbieter oder Betreiber —, hängen von deinem Fall ab, und das hier ist keine Rechtsberatung.
• Betragsgrenze, die ein Agent zusagen darf. Bedingung: Keine Aktion, die Geld bindet, überschreitet die festgelegte Schwelle pro Vorgang und pro Tag. Nachweis: der Betrag im Feld plus ein Tagesakkumulat. Zeitpunkt: vor der Ausführung. Bei Scheitern: Eskalation an einen Menschen mit fertig aufbereitetem Fall. Das ist die billigste Kontrolle von allen und die, die die meisten Leute zu spät entdecken — normalerweise nach dem ersten Schreck.
• Aussagen, die eine freigegebene Quelle verlangen. Bedingung: Jede Kundennachricht, die eine Angabe zu Produkt, Preis, Frist oder Konditionen enthält, stützt sich auf eine Quelle aus einer freigegebenen Liste. Nachweis: die Quellen, die das System zum Formulieren abgerufen hat. Zeitpunkt: vor dem Senden. Bei Scheitern: herunterstufen — das System schickt eine Antwort ohne diese Angabe und bietet die Übergabe an — statt zu blockieren, was hier übertrieben wäre.

Beachte, was die drei gemeinsam haben: Alle drei passen in eine Zeile, alle drei haben einen offensichtlichen Nachweis, und alle drei haben eine andere Konsequenz. Diese Asymmetrie ist das Zeichen, dass die Übung gut gemacht wurde. Enden alle drei bei „blockieren", hat sich niemand hingesetzt und über die Kosten des jeweiligen Fehlers nachgedacht. Der Umfang dessen, was der Agent für den Anfang anfassen darf, ist eine weitere Entscheidung aus derselben Übung, und sie steht in welche Berechtigungen ein KI-Agent bekommen soll.

Der teure Fehler: die Richtlinie allein von der Technik schreiben lassen

Wird die Übersetzung von Richtlinie zu Kontrolle komplett ans technische Team delegiert, passiert etwas vollkommen Nachvollziehbares und vollkommen Falsches: Am Ende wird geprüft, was leicht zu prüfen ist, und nicht das, wozu die Richtlinie verpflichtet. Das Ergebnis sieht gut aus — es gibt Regeln, es gibt Protokolle, es gibt Dashboards — und lässt genau das weg, was am meisten zählt, denn was am meisten zählt, ist fast nie das am besten Messbare.

Man sieht es an kleinen Details. Geprüft wird, dass die Nachricht eine Länge nicht überschreitet, und nicht, dass sie keine Frist verspricht, die du nicht halten kannst. Geprüft wird, dass die Antwort eine Quelle zitiert, und nicht, dass diese Quelle freigegeben ist. Geprüft wird, dass der Vorgang einen Betrag hat, und nicht, dass dieser Betrag das Limit respektiert, das jemand in einem Gremium beschlossen hat. Jede dieser Prüfungen ist korrekt, und keine ist die, die die Richtlinie verlangt hat.

Das Gegenmittel ist Prozess, nicht Technologie: Die Zerlegung aus Schritt 1 macht, wer Eigentümer der Pflicht ist — Business, Legal, Operations —, und der Nachweis aus Schritt 2 wird zwischen dieser Person und derjenigen ausgehandelt, die ihn implementieren wird. Die Technik hat ein Vetorecht über das Unmögliche und keines über das Unbequeme. Und das finale Dokument wird von beiden Seiten unterschrieben, mit Datum. Ohne diese doppelte Unterschrift ist das, was da liegt, keine ausführbare Richtlinie: Es ist eine Liste dessen, was bequem zu messen war.

Es gibt noch eine Nuance in der Reihenfolge, die ebenfalls zählt, und sie widerspricht dem, was offensichtlich wirkt: Die Richtlinie wird nicht zuerst geschrieben. Sie wird geschrieben, wenn du schon weißt, was du regulierst, und das findest du heraus, indem du anschaust, was deine Leute ohne zu fragen bereits mit KI machen — die vollständige Argumentation steht in warum das Verbot von Shadow AI nicht funktioniert. Eine vor dieser Inventur verfasste Richtlinie reguliert ein imaginäres Unternehmen.

Wie eine ausführbare Richtlinie aussieht, wenn sie fertig ist

Sie sieht nicht aus wie ein juristisches Dokument. Sie sieht aus wie eine Tabelle und passt auf eine Seite pro Bereich. Jede Zeile hat sechs Spalten: die Pflicht, aus der sie stammt, die prüfbare Bedingung, den Nachweis, den Zeitpunkt, zu dem hingeschaut wird, was bei Scheitern passiert und wer antwortet. Darunter eine separate Liste mit den Pflichten, die du als nicht automatisierbar eingestuft hast und die deshalb an einer Person hängen — mit Namen und Prüfrhythmus.

Diese Tabelle hat eine Eigenschaft, die das PDF nicht hat: Man kann sie gegen die Realität auditieren. Du nimmst eine Zeile, nimmst einen Fall aus der letzten Woche und prüfst, ob die Bedingung ausgewertet wurde, mit welchem Nachweis und was dann passierte. Entweder das Protokoll kommt raus, oder die Zeile ist gelogen. Das ist ein Fünf-Minuten-Test und die einzige ehrliche Art herauszufinden, ob deine KI-Richtlinie im Unternehmen lebt oder Dekoration ist.

Und sie hat noch eine: Sie altert sichtbar. Ändert sich eine Pflicht, ändert sich eine Zeile, und man sieht, welche Kontrollen angefasst werden müssen. Ändert sich das PDF, ändert sich nichts, weil es mit nichts verbunden war. Deshalb ist das Ergebnis, das wir bei KI-Einführung in Teams hinterlassen, nicht das Dokument: Es ist diese Tabelle, mit Eigentümer und Revisionsdatum, und die Kontrollen des ersten Abschnitts bereits gebaut. Das Dokument braucht es weiterhin — man muss es vorzeigen können —, aber es ist die Folge der Arbeit, nicht die Arbeit.