AI Policy – Mindestinhalt, Struktur und typische Fehler

Unternehmen setzen KI-Tools oft schneller ein, als die interne Governance mitwächst. Eine AI Policy (oft auch KI-Richtlinie oder Leitlinie genannt) soll diesen Wildwuchs strukturieren: Sie legt fest, welche Tools erlaubt sind, wie mit KI-Input und KI-Output umzugehen ist und was im Umgang mit den KI-Tools beachtet werden muss. Klingt simpel. In der Praxis scheitern viele AI Policies jedoch an diesem Anspruch: Sie sind zu abstrakt (und passen damit nicht auf den konkreten Fall), zu kompliziert (und werden daher schon gar nicht gelesen oder jedenfalls nicht verstanden), nicht dynamisch (und so schon im Zeitpunkt der Veröffentlichung veraltet) oder lückenhaft (und verfehlen so ihre Eigenschaft als taugliches Governance-Instrument).

Aitava hat über 100 AI Policies erstellt, überarbeitet und geprüft. Dieser Beitrag zeigt, was eine AI Policy mindestens enthalten muss – und welche Stolpersteine es zu vermeiden gilt.

Warum jedes Unternehmen eine AI Policy braucht

Eine AI Policy ist kein Nice-to-have. Eine AI Policy soll KI-Wildwuchs, Vertraulichkeitslücken, Urheberrechtsverstößen, Datenschutzverletzungen und Haftungsrisiken vorbeugen und dient als Compliance-Maßnahme zur Enthaftung des Managements.

Eine AI Policy ist kein Vertrag, sondern eine Arbeitsanweisung an die Beschäftigten auf Grundlage von § 106 GewO. Wer KI nutzt, braucht Regeln – schriftlich, verbindlich, und für alle verständlich.

Der Mindestinhalt: Was eine AI Policy abdecken muss

Eine belastbare AI Policy sollte mindestens die folgenden Bereiche regeln:

• Geltungsbereich: Für wen gilt die Policy – alle Beschäftigten, bestimmte Abteilungen, externe Dienstleister?
• Erlaubte KI-Tools: Welche KI-Tools dürfen genutzt werden? Eine Whitelist zugelassener Anwendungen hat sich zum de-facto-Standard entwickelt und ist erst die Basis für eine sinnvolle KI-Compliance. Best Practice: Dynamische Liste freigegebener KI-Tools im Intranet, auf die die AI Policy verweist.
• KI-Input: Welche Daten dürfen in KI-Tools eingegeben werden? Personenbezogene, vertrauliche oder geschäftskritische Daten benötigen explizite Regelungen, die oft von dem konkreten KI-Tool abhängen. Best Practice: Verbot von personenbezogenen und vertraulichen Daten als KI-Input, solange nicht in der Whitelist solche Daten für ein KI-Tool explizit freigegeben sind.
• Nutzungszweck: Einhaltung der Zweckbestimmung des Anbieters – fehlt diese, sollte eine eigene enge Zweckbestimmung vorgegeben werden. Wer ein KI-Tool außerhalb der Zweckbestimmung nutzt, kann schnell selbst zum Quasi-Anbieter und damit zum Verantwortlichen für viele Pflichten unter dem AI Act werden. Best Practice: Die für Ihre Organisation relevantesten Hochrisiko-Bereiche aus dem AI Act (z.B. Prüfung von Bewerbungsunterlagen) auflisten und die Nutzung von KI-Tools in dem Bereich ausschließen, soweit nicht in der Whitelist explizit freigegeben.
• Qualitätssicherung und menschliche Kontrolle: KI-Outputs müssen vor der Verwendung geprüft werden – erst recht bei rechtlich, finanziell oder kommunikativ relevanten Inhalten.
• AI Act: Einhaltung der Pflichten aus dem AI Act – insbesondere verbotene KI-Praktiken, Transparenzpflichten und Schulungspflicht. Best Practice: Hochrisiko-Bereiche ausschließen, solange nicht explizit freigegeben.
• Duplikatsrisiken: Maßnahmen zur Vermeidung der Verletzung Rechte Dritter in KI-Output durch Memorization. Best Practice: Sensibilisierung und angemessene rechtliche, technische und organisatorische Maßnahmen. Spezielle Maßnahmen in separaten Policies, z.B. für die Softwareentwicklung mit KI.
• Aufzeichnung nur mit Einverständnis: Transkription und Aufzeichnung von Meetings nur mit Einverständnis aller Teilnehmer. Best Practice: Sensibilisierung von Beschäftigten, zusätzlich technische Maßnahmen, z.B. Aktivierung der Teilnehmervereinbarung für Transkription und Aufzeichnung in Microsoft Teams
• Schulung und Awareness: Wer wird wie über die Policy informiert, und wie wird sichergestellt, dass sie bekannt und verstanden ist?
• Konsequenzen bei Verstößen: Meldepflichten und Sanktionen.

Typische Fehler – und wie man sie vermeidet

Fehler Nr. 1: Die Policy ist zu allgemein. Sätze wie „KI darf nur verantwortungsbewusst eingesetzt werden“ sind wertlos, weil nicht operationalisierbar. Eine gute Policy nennt konkrete Anweisungen und Standards.

Fehler Nr. 2: Die Policy ist zu lang oder enthält zu viele Vorgaben, die für die meisten Beschäftigten gar nicht relevant sind. Die beste Policy ist wertlos, wenn sie nicht gelesen oder beachtet wird. Spezialregelungen (z.B. Vorgaben für Entwickler) sollten in Spezialdokumente ausgelagert werden und nicht allen Beschäftigten vorgelegt werden.

Fehler Nr. 3: Die Policy wird einmal erstellt und nie aktualisiert. Die KI-Landschaft verändert sich rasant. Eine Policy, die sich nicht mit ihr entwickelt, verliert schnell ihre Relevanz. Empfehlenswert ist mindestens ein jährlicher Review-Zyklus – besser anlassbezogen bei neuen Tools oder regulatorischen Entwicklungen.

Fehler Nr. 4: Die IT und Fachbereiche werden nicht eingebunden. Eine Policy, die am grünen Tisch entsteht, ohne die tatsächlichen Tools und Use Cases zu kennen, wird im Alltag ignoriert oder umgangen. Praxisnahe Entwicklung – etwa durch Interviews mit Fachabteilungen – erhöht Akzeptanz und Treffsicherheit.

Fehler Nr. 5: Fehlende Verbindung zu bestehenden Richtlinien. Eine AI Policy existiert nicht im Vakuum. Sie muss konsistent sein mit der IT-Sicherheitsrichtlinie, der Datenschutz-Dokumentation, dem Code of Conduct und ggf. dem Betriebsvereinbarungsrahmen. Für den Bereich Softwareentwicklung mit KI hat sich die Einführung einer separaten AI Coding Policy bewährt, die spezifisch diesen Bereich beleuchtet.

Empfohlene Struktur auf einen Blick

Eine bewährte Grundstruktur umfasst: Präambel mit Zielen und Grundhaltung, Geltungsbereich, Begriffsbestimmungen, erlaubte und nicht erlaubte Nutzung, Datenschutz- und Vertraulichkeitsregeln, Verantwortlichkeiten und Eskalationswege, Qualitätssicherung und menschliche Prüfpflicht, Schulung und Kommunikation sowie Versionierung und Review-Prozess. Der Umfang sollte pragmatisch sein: lieber eine knappe, gelebte Policy als ein 30-seitiges Dokument, das niemand liest.