AI Policy erstellen: Von der Vorlage zur gelebten Richtlinie
8 Kern-Komponenten einer AI Acceptable Use Policy. Mit praxiserprobten Templates und Rollout-Strategie für Enterprise.
Eine AI Policy im Intranet, die niemand liest, ist wertlos. Eine AI Policy, die Mitarbeiter verstehen und befolgen, ist Governance in der Praxis.
Der Unterschied liegt nicht in der Vollständigkeit – sondern in Klarheit, Kommunikation und konsequenter Umsetzung. Laut CSA scheitern 42% der AI-Initiativen 2025 bereits vor dem Produktiveinsatz – oft wegen fehlender Governance.
Warum Policy allein nicht reicht
| Ohne Policy | Mit gelebter Policy |
|---|---|
| Shadow AI floriert (59% nutzen KI ohne IT-Freigabe) | Klare Grenzen für alle |
| Jeder entscheidet selbst, was "okay" ist | Enablement statt Verbot |
| Bei Incidents: "Das wusste ich nicht" | Schutz für Mitarbeiter und Unternehmen |
| Keine Grundlage für Konsequenzen | Basis für Accountability |
Das Problem: 38% der Mitarbeiter geben zu, sensible Daten in KI-Tools einzugeben. Ohne Policy haben Sie keine Handhabe.
Die 8 Kern-Komponenten
1. Scope: Für wen gilt diese Policy?
| Geltungsbereich | Empfehlung |
|---|---|
| Alle Mitarbeiter | Ja – unabhängig von Standort oder Abteilung |
| Externe (Contractors, Freelancer) | Ja – bei Zugang zu Unternehmensdaten |
| Private Geräte | Ja – wenn für berufliche Zwecke genutzt |
| Kostenlose Tools | Ja – explizit erwähnen (oft vergessen) |
Template-Formulierung:
"Diese Policy gilt für alle Mitarbeiter der Firma, externe Dienstleister mit Datenzugang, sowie die Nutzung auf privaten Geräten für berufliche Zwecke. Sie umfasst alle KI-Tools unabhängig vom Anbieter – kostenlose und kostenpflichtige Versionen."
2. Approved Tools: Was ist erlaubt?
Prinzip: Verbote ohne Alternativen führen zu Shadow AI.
| Kategorie | Beispiele | Status |
|---|---|---|
| Enterprise (alle) | Microsoft Copilot, ChatGPT Enterprise, GitHub Copilot | Freigegeben mit AVV |
| Abteilungsspezifisch | Jasper (Marketing), Harvey (Legal) | Nach Genehmigung |
| Nicht freigegeben | ChatGPT Free/Plus, Claude Free, Perplexity | Keine Unternehmensdaten |
Der kritische Punkt: Consumer-Versionen (ChatGPT Free, Claude Free) haben keine Enterprise-Sicherheit und können Daten für Training verwenden. Diese müssen explizit ausgeschlossen werden.
Freigabe-Prozess für neue Tools:
| Schritt | Verantwortlich | Dauer |
|---|---|---|
| Use Case + Datentyp dokumentieren | Antragsteller | — |
| IT-Security-Prüfung | Security Team | 5 AT |
| Datenschutz-Prüfung | DSB | 3 AT |
| Entscheidung + Kommunikation | AI Governance Board | — |
3. Prohibited Use: Was ist verboten?
Keine Ausnahmen – klare Formulierung:
| Kategorie | Verboten |
|---|---|
| Datentypen | Kundendaten, Personaldaten, Finanzdaten, Gesundheitsdaten, Credentials, unveröffentlichte Produkte, Verträge, Quellcode mit Geschäftsgeheimnissen |
| Use Cases | Automatisierte Entscheidungen über Menschen ohne Review, Deepfakes/Fake-Content, Umgehung von Sicherheitsmaßnahmen, Mitarbeiter-Analyse ohne Einwilligung |
4. Data Classification: Was darf in welche Tools?
Alle freigegebenen Tools
- Öffentlich verfügbare Informationen
- Allgemeine Fragen ohne Unternehmensbezug
- Marketing-Texte (nach Veröffentlichung)
Beispiel:
"Erkläre mir Machine Learning"Nur Enterprise-Tools mit AVV
- Interne Prozessdokumente
- Allgemeine Geschäftskorrespondenz
- Eigene Textentwürfe ohne Kundendaten
Beispiel:
"Verbessere diese interne Präsentation"Nur genehmigte Enterprise-Tools
- Strategische Dokumente
- Unveröffentlichte Projekte
- Aggregierte Geschäftszahlen
Beispiel:
"Analysiere diesen Marktbericht" (nach Freigabe)KEINE KI-Verarbeitung
- Personenbezogene Daten
- Kundendaten
- Finanzdaten im Detail
- Geschäftsgeheimnisse
Beispiel:
Keine KI – egal welches ToolSchnelltest: "Wäre es okay, wenn das morgen im Internet steht?" → Nein? Dann nicht in KI-Tools eingeben.
5. Roles & Responsibilities
| Rolle | Verantwortung | Eskalation |
|---|---|---|
| AI Governance Board | Tool-Freigaben, Policy-Änderungen | — |
| CISO / IT-Security | Technische Freigabe, Security-Bewertung | Security-Incidents |
| DSB | DSGVO-Konformität, DSFA | Datenschutz-Verstöße |
| Führungskräfte | Einhaltung im Team | Wiederholte Verstöße |
| Mitarbeiter | Eigene Compliance | Unklarheiten → Vorgesetzte/IT |
Governance Board Zusammensetzung: CISO, CDO/CTO, Legal, HR, Business-Vertreter. Frequenz: Monatlich.
6. Security Requirements
| Bereich | Anforderung |
|---|---|
| Authentifizierung | SSO für alle Enterprise-Tools, MFA aktiviert, persönliche Accounts |
| Netzwerk | Nur Firmennetzwerk oder VPN, keine öffentlichen WLANs ohne VPN |
| Logging | Alle Interaktionen protokolliert, 90 Tage Retention, nur für Audits/Incidents |
| Output-Handling | Review vor Veröffentlichung, keine Auto-Weiterleitung, 4-Augen bei sensiblen Outputs |
7. Consequences: Abgestuft und fair
| Stufe | Auslöser | Konsequenz |
|---|---|---|
| 1 | Unbeabsichtigt, erstmalig | Gespräch + Nachschulung |
| 2 | Wiederholt oder leicht fahrlässig | Schriftliche Ermahnung + Dokumentation |
| 3 | Grob fahrlässig oder vorsätzlich | Abmahnung + temporärer Entzug von KI-Zugängen |
| 4 | Schwerwiegend (Datenleck, Compliance-Bruch) | Arbeitsrechtliche Konsequenzen bis Kündigung |
Wichtig dokumentieren:
- Versehentliche Verstöße → Schulung, nicht Bestrafung
- Selbstmeldung → Wird positiv berücksichtigt
- Ziel ist Compliance, nicht Bestrafung
8. Review Process
| Frequenz | Scope | Verantwortlich |
|---|---|---|
| Quartalsweise | Neue Tools, neue Risiken, Mitarbeiter-Feedback | AI Governance Board |
| Jährlich | Vollständige Policy-Überprüfung, Industrie-Benchmark | CISO + Legal |
| Anlassbezogen | Nach Incidents, bei neuen Regulierungen | Governance Board/CISO |
Versionierung: Jede Änderung dokumentiert (Datum, Grund, Verantwortlicher). Alte Versionen archiviert.
Kurzfassung für Mitarbeiter
Die vollständige Policy ist wichtig – aber niemand liest 20 Seiten. Ein 1-Seiter für alle:
| Kategorie | Inhalt |
|---|---|
| Das darfst du | Freigegebene Tools nutzen, öffentliche Infos bearbeiten, Code-Hilfe (ohne Secrets), E-Mail-Entwürfe (ohne Kundendaten) |
| Das ist verboten | Kundendaten eingeben, Personaldaten verarbeiten, nicht freigegebene Tools nutzen, Credentials eingeben |
| Bei Unsicherheit | 1) "Wäre es okay im Internet?" 2) Datenklassifizierung prüfen 3) IT-Security fragen |
| Bei Problemen | Selbst-Meldung (keine Bestrafung bei Ehrlichkeit), IT-Helpdesk |
Rollout-Strategie
Eine Policy schreiben ist 20% der Arbeit. Sie zum Leben erwecken ist 80%.
Phase 1: Vorbereitung
| Aktivität | Beteiligte |
|---|---|
| Legal-Review der Formulierungen | Legal |
| Betriebsrat-Einbindung (falls vorhanden) | HR + BR |
| Führungskräfte-Briefing | Management |
| Training-Materialien erstellen | L&D + Security |
Phase 2: Führungskräfte zuerst
Führungskräfte sind Multiplikatoren. Sie müssen die Policy verstehen und erklären können.
Minimum: 2-Stunden-Workshop mit Q&A. Klären Sie Eskalationswege: Wer entscheidet bei Grenzfällen?
Phase 3: Unternehmensweiter Rollout
| Aktivität | Details |
|---|---|
| All-Hands Ankündigung | CEO oder CISO – Signal ist wichtig |
| E-Learning | 30 Minuten, verpflichtend |
| Team-Meetings | Abteilungsspezifische Fragen |
| FAQ im Intranet | Laufend aktualisiert |
| Helpdesk vorbereiten | Initialer Ansturm erwartet |
Phase 4: Operationalisierung
| Zeitraum | Aktivität |
|---|---|
| Woche 1 | Tägliches Review von Incidents und Fragen |
| Monat 1 | Wöchentliche Reviews |
| Danach | Quartalsweise Reviews |
Ohne diesen Feedback-Loop veraltet jede Policy schnell.
Die 5 häufigsten Fehler
| Fehler | Problem | Lösung |
|---|---|---|
| Zu restriktiv | Alles verboten → Shadow AI explodiert | Für jedes Verbot eine Alternative |
| Zu vage | "Sensible Daten" – was ist das? | Konkrete Beispiele, Datenklassifizierung |
| Keine Konsequenzen | Policy existiert, niemand setzt durch | Klare Stufen + konsequente Umsetzung |
| Einmal und fertig | Policy 2023 passt nicht zu Tools 2025 | Quartalsweise Reviews |
| Top-Down ohne Einbindung | Management schreibt, Mitarbeiter ignorieren | Feedback einholen, Champions einbinden |
Alignment mit Frameworks
Laut ISACA sollte Ihre AI Policy mit etablierten Frameworks aligned sein:
| Framework | Relevanz für Policy |
|---|---|
| NIST AI RMF | Risikomanagement-Struktur |
| ISO/IEC 42001:2023 | AI Management System Standard |
| EU AI Act | Compliance-Anforderungen für High-Risk |
| DSGVO | Datenschutz-Anforderungen |
Die Frage für Ihr nächstes Board-Meeting
"Wenn morgen ein Mitarbeiter Kundendaten in ChatGPT eingibt: Haben wir eine Policy, die das verbietet, wurde er geschult, und können wir es nachweisen?"
Wenn die Antwort nicht dreimal "Ja" ist, haben Sie eine Governance-Lücke.
Weiterführend
- Shadow AI bekämpfen – Warum Policy allein nicht reicht
- AI Risk Assessment – Basis für Policy-Entscheidungen
- DSGVO und LLMs – Datenschutz-Anforderungen im Detail
- EU AI Act – Regulatorische Anforderungen
AI Security Insights
Einmal im Monat. Kein Spam.
Was passiert in der Welt der KI-Security? Welche Risiken sollten Sie kennen? Ich fasse das Wichtigste zusammen - verständlich, pragmatisch, ohne Buzzwords.