KI-Leitplanken: Governance, Technik und Regeln für sichere KI

1. Was sind KI-Leitplanken? Definition, Beispiele und warum jede KI sie braucht

KI-Leitplanken (englisch „Guardrails“) sind strukturierte Kontrollen und Grenzen, die ein KI-System innerhalb sicherer, rechtlich zulässiger und beabsichtigter Grenzen halten.^[2] Sie umfassen drei Dinge zugleich: Richtlinien (was ist erlaubt), technische Kontrollen (was wird geprüft und blockiert) und laufende Überwachung (was passiert gerade). Eine Leitplanke ist also stets ein Zusammenspiel aus Regeln, Technik und Beobachtung, kein einzelnes Werkzeug.

Der Begriff beschreibt eine klare Grenze für den Betrieb. Manche Prüfungen greifen vor einer Anfrage, andere während der Verarbeitung oder vor der Ausgabe. Hinzu kommen Vorgaben für Datenzugriffe, Modelltests und den Betrieb der Infrastruktur. Ihre Bedeutung ergibt sich aus dem jeweiligen Risiko; das Bild der Straße ersetzt diese Einstufung nicht.

Braucht wirklich jede KI Leitplanken?

Jede produktiv genutzte KI braucht Vorgaben, deren Umfang zum Risiko passt. Ein KI-Chatbot mit frei zugänglichen Antworten benötigt andere Sicherheitsvorkehrungen als ein internes Werkzeug ohne personenbezogene Daten. Öffentlich zugängliche Assistenten wie ChatGPT, Claude oder Gemini bringen bereits Schutzmechanismen mit. Unternehmen müssen trotzdem prüfen, ob diese zur eigenen Nutzung, zu den Daten und zu den Anforderungen des Fachprozesses passen.

Offene oder schwach konfigurierte Modelle können ohne zusätzliche Schutzmaßnahmen unerwünschte Inhalte erzeugen oder Daten offenlegen. Ein Eingabefilter kann eine klar unzulässige Anfrage wie „Nennen Sie Methoden, um Sicherheitsfilter zu umgehen“ anhand der Nutzungsrichtlinie blockieren. Raffinierte Angriffe lassen sich damit jedoch nicht zuverlässig ausschließen. Deshalb gehören Tests, eingeschränkte Berechtigungen, Protokollierung und eine Prüfung der Ergebnisse zum Schutzkonzept.

Leitplanken können einzelne Anfragen stoppen oder zusätzliche Prüfungen auslösen. Das ist eine bewusste Abwägung: Die Anwendung soll ihren Zweck erfüllen, ohne unvertretbare Risiken für Nutzer, Kunden und Organisation zu erzeugen. Umfang und Strenge der Schutzmechanismen müssen mit diesem Zweck und dem ermittelten Risiko im Einklang stehen.

2. KI-Governance: Wer im Unternehmen entscheidet, was die KI darf

KI-Governance regelt, wer im Unternehmen über KI entscheidet und wie diese Entscheidungen dokumentiert werden. Sie bildet die Klammer über Daten, Modell, Anwendung und Infrastruktur.^[2] Ein praxistaugliches Governance-Framework benennt Betreiber und Entscheider, definiert Verantwortlichkeiten und verankert Freigaben für Einführung, Nutzung und wesentliche Änderungen. Fachbereich, IT-Sicherheit, Recht und Datenschutz übernehmen ihre jeweilige Rolle in der Prüfung. So entsteht ein gemeinsames Verständnis darüber, was die KI leisten darf und wie ihre Einhaltung geprüft wird.

Ohne geklärten Zweck, Zuständigkeiten und Abnahmekriterien bleibt selbst gute Technik schwer steuerbar. Legen Sie daher vor dem Produktivstart fest, welche Prozesse das System unterstützt, welche Daten es verarbeitet und anhand welcher Werte seine Ergebnisse geprüft werden. Wie Sie diesen Rahmen aufsetzen, zeigt unser Artikel zur KI-Strategie im Detail.

Beantworten Sie vor dem Produktivstart drei Fragen: Wer schlägt eine Änderung vor? Wer trifft die interne Entscheidung? Wer prüft fachlich, ob Datenschutz, Informationssicherheit und Prozessanforderungen eingehalten sind? Legen Sie die Zuständigkeiten mit Funktionen und benannten Inhabern fest. Die folgende Matrix zeigt ein vereinfachtes Muster:

Beispielhaftes Muster für interne Zuständigkeiten. Der Datenschutzbeauftragte berät und überwacht die Einhaltung; er übernimmt nicht die Entscheidung oder datenschutzrechtliche Verantwortung. Die Organisation erfüllt ihre Pflichten in ihrer jeweiligen Rolle als Verantwortlicher oder Auftragsverarbeiter.^[6]

Diese Rollen klären die interne Verantwortung, ersetzen aber keine Prüfung des Einzelfalls. Ein Governance-Framework braucht einen festen Platz in Beschaffung, Entwicklung, Freigabe und Betrieb. Ein allgemeingültiges Verhältnis zwischen Organisation und Technik gibt es dabei nicht. Die Gewichtung hängt von Zweck, Risikostufe, Daten und Betriebsmodell ab. Organisatorische Vorgaben müssen in technische Maßnahmen und überprüfbare Prozesse übersetzt werden.

3. EU AI Act und DSGVO: Der rechtliche Rahmen als Leitplanke

Der EU AI Act (die KI-Verordnung der EU) ist das erste umfassende Regelwerk für KI weltweit.^[3] Seine Vorschriften folgen einem risikobasierten Ansatz: Die Kommissionsübersicht unterscheidet vier Stufen von „minimalem oder keinem Risiko“ (kaum Auflagen) bis „inakzeptablem Risiko“ (verboten). Dazwischen liegen das „Transparenzrisiko“, in älteren Übersichten auch „begrenztes Risiko“ genannt, und „hohes Risiko“ mit strengen Anforderungen an Kontrolle und Dokumentation. Der erste praktische Schritt ist deshalb immer die Bewertung der eigenen Anwendung: Welcher Stufe gehört sie an?

Die Verordnung ist am 1. August 2024 in Kraft getreten. Verbotene Praktiken und die Pflicht zur KI-Kompetenz gelten seit Februar 2025, die Governance-Regeln und Pflichten für allgemeine KI-Modelle seit August 2025. Die allgemeine Anwendung und die Transparenzpflichten folgen im August 2026.^[3] Für Hochrisiko-Systeme nennt die politische Einigung vom 7. Mai 2026 einen gestaffelten Zeitplan: bestimmte Hochrisiko-Bereiche ab 2. Dezember 2027, in regulierte Produkte integrierte Systeme ab 2. August 2028. Die zeitliche Staffelung soll sicherstellen, dass technische Standards und weitere Hilfsmittel für die Umsetzung bereitstehen. Das ist der aktuelle Einigungsstand des Gesetzgebungsverfahrens. Prüfen Sie deshalb bei der Umsetzung, ob sich der förmliche Rechtsstand geändert hat. Einzelheiten erläutert unser Beitrag zum EU AI Act.

Parallel gelten die Vorschriften der DSGVO, sobald personenbezogene Daten verarbeitet werden. Solche Daten sind in KI-Systemen nicht pauschal verboten. Die Verarbeitung braucht unter anderem eine Rechtsgrundlage, einen festgelegten Zweck und Datenminimierung. Bei einem externen Anbieter sind außerdem dessen Rolle, ein erforderlicher Auftragsverarbeitungsvertrag, mögliche Drittlandtransfers und geeignete technische sowie organisatorische Schutzmaßnahmen zu prüfen.^[6]

Für nicht freigegebene öffentliche KI-Dienste gilt eine strengere betriebliche Regel: Geben Sie dort keine personenbezogenen Daten, Kundeninterna oder Geschäftsgeheimnisse ein. Freigegebene Lösungen können solche Daten verarbeiten, wenn Zweck, Rechtsgrundlage, Verträge, Berechtigungen und Schutzmaßnahmen dokumentiert sind. Maskierung oder Pseudonymisierung, kurze Speicherfristen und Protokolle unterstützen die Einhaltung. So bringen Sie die Nutzung von KI und Datenschutz in Einklang.

4. Vom Risiko zum Betrieb: Welche Vorteile Leitplanken im Alltag bringen

Klare Leitplanken verkürzen interne Abstimmungen. Ein Fachbereich kennt die freigegebenen Werkzeuge, zulässigen Daten und erforderlichen Prüfungen. Die IT muss dadurch nicht jede Anfrage neu einstufen, während Recht und Datenschutz früh eingebunden werden. Das beschleunigt wiederkehrende Freigaben und macht ihre Anforderungen nachvollziehbar. Auf diese Weise wächst auch das Vertrauen in den Prozess.

Im Betrieb schaffen Abnahmekriterien und Stichproben eine verlässliche Grundlage für Qualität. Teams können Fehlerraten, unerwünschtes Verhalten und Ausnahmen messen, statt nur einzelne Ergebnisse zu diskutieren. Werden Quellen, Modellversionen und Freigaben protokolliert, lassen sich Probleme schneller eingrenzen. Wiederkehrende Probleme werden sichtbar, das Vertrauen in die Messwerte steigt und die Nacharbeit sinkt.

Auch gegenüber Kunden und Partnern helfen überprüfbare Nachweise mehr als allgemeine Versprechen. Ein dokumentierter Zweck, benannte Verantwortung, getestete Sicherheitsvorkehrungen und ein Verfahren für Beschwerden oder Bedenken schaffen Vertrauen. In Bereichen mit hohen Anforderungen, etwa Finanzen, Gesundheit oder Kundenservice, verbessern diese Maßnahmen zudem die Betriebsstabilität: Fehler werden früher erkannt, Zuständigkeiten sind klar und ein Notfallplan begrenzt die Auswirkungen.

5. So funktionieren Leitplanken technisch: Eingabefilter, Ausgabekontrolle, Laufzeitüberwachung

Auf der Anwendungsebene lassen sich vier häufige Kontrollen unterscheiden. Jede setzt an einem anderen Punkt an. Zusammen reduzieren sie Risiken, decken aber nicht jede Fehlerart vollständig ab.

Der Eingabe-Guard sitzt vor dem Modell. Er gleicht Anfragen gegen Richtlinien ab und kann bekannte Angriffsmuster oder unzulässige Inhalte blockieren. Der Ausgabe-Guard prüft Antworten vor der Auslieferung, zum Beispiel auf personenbezogene Daten, toxische Sprache oder eine unerlaubte Struktur. Beide Kontrollen arbeiten mit Regeln, Klassifikatoren oder zusätzlichen Modellen. Sie können Fehlalarme erzeugen und raffinierte Angriffe übersehen. Die Bedeutung eines Filtertreffers hängt vom Kontext ab; schlecht gewählte Schwellenwerte schaffen neue Probleme. Insbesondere lässt sich eine Halluzination nicht allein deshalb zuverlässig erkennen, weil eine Aussage plausibel klingt.

Für die Implementierung gibt es fertige Lösungen. Regeln können in Konfigurationsdateien oder über APIs in die bestehende KI-Pipeline eingebunden und versioniert werden. Strukturierte Ausgaben von LLMs mit fest definierten Feldern erleichtern automatische Prüfungen: Pflichtfelder, Datentypen und zulässige Werte lassen sich validieren. Inhaltliche Fehler verhindert das Format nicht. Dafür brauchen Sie je nach Anwendung Quellenabgleich, Plausibilitätsregeln oder eine menschliche Freigabe.

Technische Leitplanken sitzen außerdem auf der Daten-, Modell- und Infrastrukturebene.^[2] Beispiele sind getrennte Datenbestände, Modelltests, eingeschränkte Werkzeugrechte, Netzwerkgrenzen, Verschlüsselung und Protokollierung. Auch das Modell selbst kann durch Training oder Feintuning auf bestimmtes Verhalten ausgerichtet werden. Ein- und Ausgabefilter bleiben wichtig, ersetzen diese Ebenen aber nicht.

6. KI-Angriffe abwehren: Prompt Injection, Jailbreaks, Halluzinationen und die Frameworks dagegen

Die häufigsten Angriffe auf KI zielen auf die Sprache selbst; eine Lücke im Code brauchen sie gar nicht. Eine Prompt Injection (versteckte Anweisungen in einer scheinbar harmlosen Eingabe) schmuggelt fremde Befehle ein. Ein Jailbreak (eine Eingabe, die die KI zum Ignorieren ihrer eigenen Regeln überredet) setzt die Schutzregeln außer Kraft. Das Ergebnis ist in beiden Fällen dasselbe: Das System liefert Ausgaben, die eigentlich gesperrt sind, von verbotenen Inhalten bis zur Preisgabe interner Daten.

Eine Ausgabeprüfung kann bekannte Muster personenbezogener Daten und andere sensible Inhalte erkennen. Sie findet jedoch nicht jedes Geheimnis und versteht nicht zuverlässig, ob eine Information im jeweiligen Kontext freigegeben ist. Begrenzen Sie deshalb bereits die Daten und Werkzeuge, auf die das Modell zugreifen darf. Prüfen Sie Autorisierungen bei jeder Aktion erneut und behandeln Sie Modellausgaben nicht als vertrauenswürdige Befehle.

Gegen Halluzinationen kann RAG helfen. Dabei erhält das Modell passende Inhalte aus festgelegten Quellen, statt ausschließlich aus seinem Modellwissen zu antworten. Das kann erfundene Aussagen reduzieren, garantiert aber keine korrekten Ergebnisse. Quellen müssen auffindbar, aktuell und zur Antwort passend sein. Externe Dokumente können zudem indirekte Prompt Injections enthalten. Trennen Sie deshalb Anweisungen von Quelldaten, beschränken Sie Werkzeugrechte und testen Sie, wie das System mit manipulierten Dokumenten umgeht.^[5]

Zwei etablierte Orientierungshilfen unterstützen die systematische Prüfung: MITRE ATLAS dokumentiert Taktiken und Techniken von Angreifern gegen KI-Systeme.^[4] Die OWASP Top 10 for LLM Applications 2025 beschreibt zehn zentrale Risiken und passende Gegenmaßnahmen für Anwendungen mit großen Sprachmodellen.^[5] Ordnen Sie Datenquellen, Eingaben, Werkzeuge und Antworten diesen Kategorien zu. So werden auch Angriffsflächen sichtbar, die nicht im direkten Eingabefeld liegen.

7. Was fehlende Leitplanken kosten: Breach-Zahlen, Shadow AI und die Rote Liste

Der IBM Cost of a Data Breach Report 2025 liefert Vergleichswerte für untersuchte Datenpannen. Die Zahlen beschreiben Stichproben und Zusammenhänge; sie belegen keine einzelne Ursache:

Quelle: IBM, Cost of a Data Breach Report 2025.^[1] Der globale Durchschnitt lag bei 4,44 Mio. USD; die USA bilden mit 10,22 Mio. USD die Spitze.

Bei 16 Prozent der untersuchten Datenpannen nutzten Angreifer KI, vor allem für Phishing oder Deepfake-Imitation.^[1] Separat berichteten 13 Prozent der untersuchten Organisationen eine Kompromittierung von KI-Modellen oder Anwendungen. Von dieser Teilgruppe hatten 97 Prozent keine angemessenen KI-Zugriffskontrollen. Daraus folgt nicht, dass fehlende Zugriffskontrollen 97 Prozent aller KI-Vorfälle verursacht haben. Der Befund zeigt vielmehr eine verbreitete Governance- und Kontrolllücke bei den gemeldeten Fällen.

Shadow AI: Nutzung ohne Freigabe erschwert die Kontrolle

Shadow AI bezeichnet KI-Werkzeuge, die Mitarbeiter ohne offizielle Freigabe oder Aufsicht nutzen. Im IBM-Vergleich lagen die durchschnittlichen Breach-Kosten bei Organisationen mit hoher Shadow-AI-Nutzung um 670.000 USD über denen mit geringer oder keiner Nutzung.^[1] Das ist ein Zusammenhang und kein Beleg dafür, dass Shadow AI allein die Mehrkosten verursacht hat. Betriebliche Risiken entstehen etwa dann, wenn eine E-Mail-Adresse, ein Vertragsentwurf oder interne Daten in unbekannte Systeme gelangen.

Eine Regel im Wiki genügt nicht. Erfassen Sie genutzte Werkzeuge, sperren Sie nicht freigegebene Dienste, definieren Sie Berechtigungen und stellen Sie geeignete interne Lösungen bereit. Schulungen sollten erklären, welche Daten in welchem System zulässig sind und an wen sich Mitarbeiter mit Fragen wenden. Zugriffskontrollen sind dabei eine wichtige Maßnahme, aber nur ein Teil des Schutzkonzepts.

8. Leitplanken einführen: Der 4-Ebenen-Fahrplan von Daten bis Infrastruktur

Aus der Theorie wird ein Fahrplan, sobald man die vier Ebenen der Reihe nach absichert. Jede Ebene hat eigene Anforderungen und einen praktischen ersten Schritt. Das Thema betrifft damit mehrere Rollen und Abläufe im Unternehmen.

Auf der Datenebene klären Sie Zweck, Herkunft, Qualität und Zugriffsrechte. Personenbezogene Informationen werden je nach Zweck minimiert, pseudonymisiert oder aus dem Datensatz entfernt. Tests auf Verzerrungen helfen, problematische Muster früh zu erkennen. Auf der Modellebene prüfen Sie das Verhalten vor und während des Betriebs. Geeignete Werte können Latenz, Toxizität, Genauigkeit und Robustheit sein. Welche Messgrößen zählen, hängt von der Anwendung ab. Modelltests und Quellenabgleiche reduzieren Fehler, liefern aber keine Garantie für richtige Ergebnisse.

Auf der Anwendungsebene werden aus allgemeinen Regeln verbindliche Prüfungen und Sperren. Die Anwendung begrenzt erlaubte Aktionen, validiert Ein- und Ausgaben und fordert bei folgenreichen Entscheidungen eine menschliche Freigabe an. Die Infrastrukturebene schützt den Betrieb mit Zugriffskontrollen, Verschlüsselung, Netzwerkgrenzen, Monitoring und Logging. Zusammen erleichtern diese Maßnahmen die Untersuchung von Problemen und die Wiederherstellung nach einem Vorfall.

Wenn Sie heute bei null starten, beginnen Sie mit zwei Fragen. Erstens: Wer entscheidet und wer prüft fachlich? Zweitens: Wer darf welches System mit welchen Daten nutzen? Dokumentieren Sie danach den Anwendungsfall, stufen Sie sein Risiko ein und wählen Sie Maßnahmen für alle betroffenen Ebenen. Prüfen Sie außerdem, welche Standards Ihrer Branche für den Einsatz gelten. Tests und klare Abnahmekriterien zeigen die Wirkung der Maßnahmen. Die Implementierung wird so zu einem wiederholbaren Prozess statt zu einer Sammlung einzelner Werkzeuge.