KI-Richtlinie 2026:

Was eine moderne AI Policy für Unternehmen regeln sollte

Von ChatGPT zur autonomen KI: Warum eine KI-Richtlinie heute weit mehr als ein Verbot vertraulicher Daten im Prompt sein muss


Künstliche Intelligenz hat sich in kurzer Zeit grundlegend verändert.

Noch vor wenigen Jahren bestand die typische KI-Nutzung in Unternehmen darin, einen Text mit ChatGPT zu erstellen, eine Präsentation zusammenzufassen oder einen Programmcode generieren zu lassen.

Heute reicht das Spektrum wesentlich weiter:

  • Large Language Models (LLMs)
  • Generative KI
  • RAG-Systeme mit Unternehmenswissen (Retrieval-Augmented Generation)
  • AI Copilots
  • multimodale KI
  • lokale und private KI-Modelle
  • Fine-Tuning
  • AI-as-a-Service
  • KI-gestützte Softwareentwicklung
  • autonome bzw. agentische KI-Systeme
  • AI Agents mit Zugriff auf Unternehmenssysteme
  • Multi-Agent-Systeme
  • KI mit Zugriff auf APIs, Datenbanken und Tools


Damit verändert sich auch das Risiko.

Eine KI kann heute nicht mehr nur Information erzeugen. Sie kann Informationen suchen, interpretieren, Entscheidungen vorbereiten, Software verändern und – bei entsprechendem Zugriff – Aktionen in IT-Systemen ausführen.


Eine moderne KI-Richtlinie muss deshalb drei Fragen beantworten:

Welche KI darf eingesetzt werden?
Unter welchen Bedingungen darf sie eingesetzt werden?
Welche Kontrolle bleibt beim Menschen?

 

1. Warum eine klassische KI-Richtlinie nicht mehr ausreicht

Viele Unternehmen haben inzwischen eine einfache KI-Nutzungsrichtlinie:

„Keine vertraulichen Informationen in ChatGPT eingeben.“

Das ist sinnvoll – aber nicht mehr ausreichend.

Denn moderne KI-Systeme erzeugen neue Risikoklassen.

Beispielsweise kann ein Mitarbeiter heute einen AI Agent mit seinem Microsoft-365-Konto verbinden. Der Agent kann anschließend E-Mails lesen, Dokumente analysieren, Termine verwalten oder andere Systeme über APIs ansprechen.

Das Risiko entsteht damit nicht mehr ausschließlich durch den Prompt.

Es entsteht durch die Kombination aus:

KI-Modell + Daten + Identität + Berechtigungen + Tools + Schnittstellen + Prozess + Mensch.

Das ist ein grundlegender Unterschied.

Eine moderne KI-Richtlinie sollte deshalb nicht nur die Nutzung von Chatbots regeln, sondern den gesamten AI Lifecycle.


2. Das regulatorische Umfeld hat sich erheblich erweitert

Eine KI-Richtlinie steht heute nicht mehr isoliert.

Je nach Unternehmen können unter anderem folgende Regelwerke relevant sein:


Regelwerk / Standard, Bedeutung für KI

  • EU AI Act: Risikoklassifizierung, Verbote, Transparenz, AI Literacy, Anforderungen an bestimmte KI-Systeme
  • DSGVO: Verarbeitung personenbezogener Daten, Betroffenenrechte, Zweckbindung, Datenschutz-Folgenabschätzung
  • NIS2: Cybersecurity, Risikomanagement und Incident Management für betroffene Organisationen
  • DORA: Digitale operationale Resilienz im Finanzsektor
  • Cyber Resilience Act (CRA): Cybersecurity-Anforderungen an Produkte mit digitalen Elementen
  • EU Data Act: Datenzugang, Datennutzung und Datenverarbeitung
  • Produkthaftungsrecht: Haftungsfragen bei Software, KI und digitalen Produkten
  • ISO/IEC 27001: Informationssicherheitsmanagement
  • ISO/IEC 42001: AI Management System
  • ISO/IEC 23894: Risikomanagement für KI
  • ISO/IEC 22989: Begriffe und Konzepte rund um KI
  • OWASP GenAI Security: Technische Risiken von LLM- und GenAI-Anwendungen
  • OWASP Agentic AI: Risiken autonomer, tool-nutzender KI-Agenten


Der EU AI Act ist dabei besonders wichtig. Seit 2. August 2026 sind wesentliche Teile des AI Act anwendbar; die Verbote bestimmter KI-Praktiken und die Anforderungen an AI Literacy gelten bereits seit Februar 2025. Die Regelungen für General-Purpose AI gelten seit August 2025. Für bestimmte Hochrisiko-KI gelten allerdings verlängerte Übergangsfristen.

Für Unternehmen mit digitalen Produkten kommt zusätzlich der Cyber Resilience Act hinzu. Die Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle gelten bereits seit 11. September 2026; die wesentlichen CRA-Anforderungen werden ab Dezember 2027 vollständig anwendbar.

Für Finanzunternehmen ist DORA bereits seit 17. Januar 2025 anzuwenden.

NIS2 gilt ebenfalls bereits im europäischen Rechtsrahmen; die Mitgliedstaaten mussten die Richtlinie grundsätzlich bis Oktober 2024 umsetzen.

Eine KI-Richtlinie sollte daher Teil eines übergeordneten Compliance- und Managementsystems sein – nicht als isoliertes Dokument betrachtet werden.


3. AI Governance: Wer ist eigentlich verantwortlich?

Eine der wichtigsten Ergänzungen gegenüber älteren KI-Richtlinien ist die Frage nach der Governance.

Es sollte nicht einfach heißen:

„Die IT ist für KI verantwortlich.“

KI betrifft viele Unternehmensbereiche.

Eine sinnvolle Governance kann beispielsweise folgende Rollen enthalten:

  • Geschäftsführung
  • AI Governance / AI Management
  • Informationssicherheit
  • Datenschutz
  • IT
  • Legal / Compliance
  • Fachabteilungen
  • HR
  • Einkauf
  • Softwareentwicklung
  • Risikomanagement
  • Qualitätsmanagement

Dabei sollte eindeutig geregelt werden:

Wer darf KI genehmigen?
Wer führt die Risikoanalyse durch?
Wer prüft Datenschutz und Informationssicherheit?
Wer genehmigt Hochrisiko-Anwendungen?
Wer überwacht KI-Systeme im Betrieb?
Wer entscheidet über Abschaltung oder Rücknahme?

ISO/IEC 42001 bietet hierfür inzwischen einen eigenen Managementsystem-Ansatz. Der Standard beschreibt ein AI Management System für Organisationen, die KI entwickeln, bereitstellen oder nutzen.


4. KI-Inventar statt nur einer White List

Eine reine White List mit „erlaubten Tools“ reicht nicht mehr aus.

Unternehmen sollten ein KI-Inventar aufbauen.

Für jedes relevante KI-System sollten mindestens folgende Informationen vorhanden sein:

  • Name des Systems
  • Anbieter
  • verwendetes Modell
  • Version
  • Zweck
  • Fachprozess
  • verantwortlicher Owner
  • Benutzergruppen
  • verwendete Daten
  • personenbezogene Daten?
  • vertrauliche Daten?
  • Geschäftsgeheimnisse?
  • Schnittstellen
  • verwendete Tools
  • Berechtigungen
  • Standort / Datenverarbeitung
  • Subprozessoren
  • Modelltraining mit Kundendaten?
  • Risiko-Klasse
  • Human Oversight
  • Protokollierung
  • Notfallverfahren
  • Abschaltmöglichkeit

Damit entsteht aus der KI-Richtlinie ein praktisches AI Asset Management.


5. Risikoklassifizierung: Nicht jede KI ist gleich

Eine moderne KI-Richtlinie sollte verschiedene Risikoklassen unterscheiden.

Klasse 1 – Assistive KI

Beispiele:

  • Textentwürfe
  • Übersetzungen
  • Zusammenfassungen
  • Brainstorming
  • allgemeine Recherche

Risiko: vergleichsweise niedrig.

Klasse 2 – Unternehmensinterne KI

Beispiele:

  • RAG über interne Dokumente (Retrieval-Augmented Generation)
  • interner Wissensassistent
  • KI für Vertragsanalyse
  • KI für Support

Hier werden bereits Unternehmensdaten verarbeitet.

Klasse 3 – Entscheidungsunterstützende KI

Beispiele:

  • Bewerbervorauswahl
  • Kreditbewertung
  • Qualitätsentscheidung
  • Risikoanalyse
  • medizinische Entscheidungsunterstützung

Hier steigen Datenschutz-, Compliance- und Haftungsrisiken erheblich.

Klasse 4 – Hochrisiko-KI

Hier sind die Anforderungen des AI Act zu berücksichtigen.

Klasse 5 – Autonome / agentische KI

Beispiele:

  • Agent darf Tickets selbstständig schließen
  • Agent kann Bestellungen auslösen
  • Agent verändert Daten
  • Agent schreibt und deployed Software
  • Agent kann E-Mails versenden
  • Agent greift auf ERP-, CRM- oder Cloud-Systeme zu

Hier entsteht eine neue Risikodimension:

Was darf die KI selbstständig tun?


6. LLMs verändern das Sicherheitsmodell

Large Language Models bringen neue Angriffsmöglichkeiten mit sich.

Eine moderne KI-Richtlinie sollte deshalb mindestens folgende Risiken berücksichtigen:

  • Prompt Injection
  • Indirect Prompt Injection
  • Jailbreaking
  • Sensitive Information Disclosure
  • Model / Data Poisoning
  • Supply-Chain-Risiken
  • Improper Output Handling
  • System-Prompt Leakage
  • Vector- und Embedding-Risiken
  • Halluzinationen
  • Unbounded Consumption
  • Excessive Agency

Diese Risiken werden beispielsweise im OWASP GenAI Security Project systematisch behandelt. Die OWASP Top 10 für LLM-Anwendungen adressiert unter anderem Prompt Injection, Sensitive Information Disclosure, Supply-Chain-Risiken, Excessive Agency und Vector-/Embedding-Schwachstellen.

Damit sollte eine KI-Richtlinie nicht mehr nur fragen:

„Welche Daten dürfen in die KI eingegeben werden?“

sondern auch:

„Welche Anweisungen darf die KI ausführen und welchen Daten und Systemen darf sie vertrauen?“


7. Agentic AI: Die neue Risikoklasse

Besonders wichtig ist die Entwicklung von AI Agents.

Ein klassischer Chatbot antwortet.

Ein Agent kann dagegen:

  1. ein Ziel erhalten,
  2. Informationen recherchieren,
  3. einen Plan erstellen,
  4. Tools auswählen,
  5. APIs aufrufen,
  6. Ergebnisse bewerten,
  7. weitere Aktionen durchführen.

Damit wird aus einem Informationssystem zunehmend ein handelndes System.

Ein Agent könnte beispielsweise:

„Prüfe alle offenen Kundenreklamationen, analysiere die Ursachen, erstelle Antworten und schließe die Tickets, wenn die Voraussetzungen erfüllt sind.“

Das ist qualitativ etwas anderes als:

„Fasse mir diese Reklamationen zusammen.“

Für Agenten sollte eine Richtlinie deshalb zusätzliche Kontrollen verlangen.

Agent Permissions

Jeder Agent benötigt klar definierte Berechtigungen:

  • Read
  • Create
  • Modify
  • Delete
  • Approve
  • Execute
  • Send
  • Purchase

Das Prinzip sollte lauten:

Least Privilege für AI Agents.

Ein Agent sollte niemals mehr Rechte besitzen als unbedingt erforderlich.


8. Human-in-the-Loop reicht bei Agenten nicht immer aus

Der klassische Begriff Human in the Loop muss präzisiert werden.

Ein Mensch, der nur gelegentlich auf einen „OK“-Button klickt, ist keine ausreichende Kontrolle, wenn die KI bereits umfangreiche Aktionen durchführen kann.

Daher sollte zwischen verschiedenen Kontrollstufen unterschieden werden:

Human-in-the-Loop

Der Mensch muss die Aktion freigeben.

Human-on-the-Loop

Der Mensch überwacht den Prozess und kann eingreifen.

Human-in-Command

Der Mensch kann den Agenten jederzeit stoppen und besitzt die letztendliche Entscheidungshoheit.

Für kritische Aktionen sollte beispielsweise gelten:

Keine autonome Ausführung ohne menschliche Freigabe bei:

  • Geldtransaktionen
  • Vertragsabschluss
  • Personalentscheidungen
  • Löschung wichtiger Daten
  • produktiven Systemänderungen
  • Veröffentlichung externer Kommunikation
  • sicherheitskritischen Änderungen
  • Änderungen an Berechtigungen


9. Identität und Berechtigungen von KI

Ein neues Thema, das in älteren KI-Richtlinien fast vollständig fehlt:

KI benötigt eine digitale Identität.

Wenn ein Agent auf Unternehmenssysteme zugreift, darf er nicht einfach die Identität eines Mitarbeiters übernehmen.

Es sollte nachvollziehbar sein:

  • welcher Benutzer
  • welcher Agent
  • welches Modell
  • welcher Prozess
  • welcher Auftrag
  • welche Berechtigung
  • welche Aktion

eine Änderung durchgeführt hat.

Damit wird AI Identity & Access Management zu einem wichtigen Bestandteil der KI-Governance.


10. RAG und Unternehmenswissen

Viele Unternehmen trainieren heute nicht ihr eigenes LLM.

Stattdessen verwenden sie Retrieval-Augmented Generation (RAG).

Dabei greift ein LLM auf Unternehmensdokumente, Datenbanken oder Wissensbestände zu.

Das bringt neue Risiken:

  • falsche Dokumente werden gefunden
  • Benutzer sehen Dokumente ohne Berechtigung
  • veraltete Informationen werden verwendet
  • manipulierte Dokumente beeinflussen die Antwort
  • vertrauliche Informationen werden in Antworten zusammengeführt

Deshalb muss gelten:

Die Zugriffskontrolle des RAG-Systems muss mindestens so streng sein wie die Zugriffskontrolle der zugrunde liegenden Daten.

Ein Mitarbeiter darf über einen KI-Assistenten nicht plötzlich Dokumente lesen können, auf die er im Originalsystem keinen Zugriff hat.


11. Daten- und Datenschutz-Governance für KI

Der Datenschutzteil der alten Richtlinie sollte ebenfalls erweitert werden.

Nicht nur die Eingabe ist relevant.

Zu betrachten sind:

Input → Verarbeitung → Retrieval → Modell → Output → Speicherung → Logging → Training

Besondere Themen:

  • personenbezogene Daten
  • besondere Kategorien personenbezogener Daten
  • Geschäftsgeheimnisse
  • Kundendaten
  • Mitarbeiterdaten
  • Trainingsdaten
  • Prompts
  • Chatverläufe
  • Embeddings
  • Vektordatenbanken
  • Logs
  • Telemetriedaten

Der EDSA hat inzwischen ausdrücklich Aspekte der Verarbeitung personenbezogener Daten bei Entwicklung und Einsatz von KI-Modellen behandelt. Dazu gehören unter anderem Anonymität, berechtigtes Interesse und die Folgen einer unrechtmäßigen Verarbeitung von Trainingsdaten.

Eine wichtige Konsequenz:

„Die Daten stehen im Internet“ bedeutet nicht automatisch „Die Daten dürfen für KI verwendet werden“.


12. KI-Output ist nicht automatisch richtig

Eine KI kann überzeugend falsche Informationen erzeugen.

Deshalb sollte die Richtlinie abhängig vom Risiko unterschiedliche Prüfpflichten definieren.

Niedriges Risiko

Stichprobenartige Kontrolle.

Mittleres Risiko

Fachliche Prüfung vor Verwendung.

Hohes Risiko

Dokumentierte menschliche Freigabe.

Kritische Entscheidungen

Keine alleinige Entscheidung durch KI.

Zu prüfen sind insbesondere:

  • Fakten
  • Quellen
  • Berechnungen
  • rechtliche Aussagen
  • technische Aussagen
  • personenbezogene Aussagen
  • Bias
  • Manipulation
  • Halluzinationen
  • Aktualität


13. KI-gestützte Softwareentwicklung

Ein eigener Abschnitt ist heute zwingend sinnvoll.

Beispiele:

  • GitHub Copilot
  • Coding Agents
  • KI-generierter Quellcode
  • automatisierte Code Reviews
  • KI-generierte Tests
  • KI-generierte Infrastructure-as-Code
  • KI-generierte SQL-Abfragen

Regeln sollten unter anderem festlegen:

  • keine vertraulichen Quellcodes in nicht freigegebenen Systemen
  • Code muss durch Entwickler geprüft werden
  • Security Testing bleibt erforderlich
  • Lizenz- und Open-Source-Risiken prüfen
  • Secrets dürfen nicht in Prompts gelangen
  • generierter Code muss nachvollziehbar geprüft werden
  • KI darf nicht eigenständig produktive Änderungen durchführen, sofern dies nicht ausdrücklich freigegeben ist

Besonders bei Coding Agents wird die Grenze zwischen „Assistenz“ und „autonomer Softwareentwicklung“ zunehmend fließend.


14. AI Supply Chain Management

KI wird häufig von Drittanbietern bezogen.

Damit entsteht ein klassisches Third-Party-Risk-Management.

Zu prüfen sind beispielsweise:

  • Anbieter
  • Modell
  • Subprozessoren
  • Hosting
  • Datenstandort
  • Datenschutz
  • Informationssicherheit
  • Zertifizierungen
  • Vertragsbedingungen
  • Training mit Kundendaten
  • Retention
  • Löschkonzept
  • Incident Management
  • Business Continuity
  • Modelländerungen
  • Abhängigkeit vom Anbieter
  • Exit-Strategie

Besonders wichtig:

Welches Modell wird tatsächlich verwendet?

Ein Anbieter kann seine zugrunde liegenden Modelle ändern, ohne dass sich die Benutzeroberfläche verändert.

Daher gehört Model Change Management in eine moderne KI-Governance.


15. AI Lifecycle Management

Eine KI-Anwendung sollte wie ein IT-System behandelt werden.

Der Lifecycle umfasst:

Idee → Bewertung → Entwicklung → Freigabe → Betrieb → Monitoring → Änderung → Review → Abschaltung

Für jede Phase sollten Verantwortlichkeiten definiert werden.

Besonders wichtig:

Before Go-Live

  • Risikoanalyse
  • Datenschutzprüfung
  • Security Assessment
  • AI-Act-Klassifizierung
  • fachliche Freigabe
  • Test
  • Dokumentation

During Operation

  • Monitoring
  • Incident Management
  • Performance Monitoring
  • Bias Monitoring
  • Security Monitoring
  • Modelländerungen

End of Life

  • Abschaltung
  • Löschung von Daten
  • Entzug von Berechtigungen
  • Archivierung relevanter Nachweise
  • Entfernung von APIs und Credentials


16. AI Security Testing

Klassische Funktionstests reichen bei KI nicht aus.

Zusätzlich erforderlich können sein:

  • Prompt-Injection-Tests
  • Jailbreak-Tests
  • Datenschutztests
  • Halluzinationstests
  • Bias-Tests
  • Robustheitstests
  • Red Teaming
  • Abuse Cases
  • Adversarial Testing
  • Tool- und API-Sicherheit
  • Agent-Hijacking-Tests

Gerade Agenten benötigen neue Testansätze.

NIST hat beispielsweise auf das Risiko des Agent Hijacking hingewiesen: Manipulierte Inhalte können indirekte Prompt Injection verursachen und einen Agenten zu unerwünschten Aktionen bewegen.

OWASP hat deshalb inzwischen einen eigenen Top 10-Ansatz für Agentic Applications veröffentlicht. Dieser adressiert unter anderem Goal Hijacking, Tool Misuse, Identity & Privilege Abuse, Agentic Supply Chain Vulnerabilities und unerwartete Codeausführung.


17. Logging und Audit Trail

Eine moderne KI-Governance benötigt nachvollziehbare Protokollierung.

Je nach Risiko sollten beispielsweise dokumentiert werden:

  • Benutzer
  • KI-System
  • Modell
  • Version
  • Prompt
  • relevante Datenquelle
  • verwendete Tools
  • Agent Actions
  • Entscheidungen
  • Freigaben
  • Output
  • Fehler
  • Sicherheitsereignisse

Dabei muss allerdings gleichzeitig der Datenschutz berücksichtigt werden.

Es gilt daher nicht:

„Alles speichern.“

Sondern:

So viel protokollieren wie für Sicherheit, Nachvollziehbarkeit und Compliance erforderlich – und so wenig wie möglich personenbezogene Daten speichern.

 

18. Incident Management für KI

Eine KI-Richtlinie sollte einen eigenen AI-Incident-Prozess definieren.

Beispiele:

  • vertrauliche Daten wurden an ein KI-System übermittelt
  • KI erzeugt falsche kritische Informationen
  • Agent führt unerlaubte Aktion aus
  • Prompt Injection erfolgreich
  • personenbezogene Daten werden ausgegeben
  • Modell wird manipuliert
  • Trainingsdaten sind kompromittiert
  • API-Key eines Agenten wurde missbraucht
  • KI-System fällt aus
  • Anbieter ändert Modell unerwartet

Dabei muss die KI-Richtlinie mit bestehenden Prozessen verbunden werden:

**Information Security Incident Management

  • Datenschutzverletzung
  • Business Continuity
  • Crisis Management
  • Supplier Incident Management**

Bei Produkten mit digitalen Elementen kommt zusätzlich der CRA hinzu. Seit September 2026 bestehen für Hersteller bereits spezifische Meldepflichten für aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle.

 

19. AI Literacy und Schulung

Schulung bedeutet heute mehr als:

„Bitte keine vertraulichen Daten in ChatGPT eingeben.“

Mitarbeiter sollten mindestens verstehen:

  • Was ist ein LLM?
  • Was ist Generative AI?
  • Was ist RAG?
  • Was ist ein AI Agent?
  • Was ist Prompt Injection?
  • Was ist eine Halluzination?
  • Welche Daten dürfen verwendet werden?
  • Wie überprüfe ich KI-Ergebnisse?
  • Wann muss ein Mensch entscheiden?
  • Wann muss ein KI-Einsatz gemeldet werden?
  • Welche KI-Tools sind freigegeben?

Der AI Act enthält ausdrücklich Anforderungen zur AI Literacy; diese gelten bereits seit Februar 2025.

Für unterschiedliche Zielgruppen sollten unterschiedliche Schulungen vorgesehen werden:


Zielgruppe: Schwerpunkte

  • Mitarbeiter: sichere KI-Nutzung
  • Führungskräfte: Governance und Verantwortung
  • Entwickler: AI Security / Secure AI Coding
  • Administratoren: Identity, Access, Logging
  • Datenschutz: DSGVO und KI
  • Informationssicherheit: AI Threats
  • Einkauf: AI Supplier Risk
  • Auditoren: Nachweise und Wirksamkeit
  • Management: Risiko, Haftung und Governance


20. Transparenz und Kennzeichnung

Seit August 2026 sind bestimmte Transparenzpflichten des AI Act anwendbar. Dazu gehören unter anderem Anforderungen im Zusammenhang mit der Information von Personen, wenn sie mit bestimmten KI-Systemen interagieren, sowie Vorgaben für bestimmte synthetische Inhalte. Die Europäische Kommission hat hierzu 2026 eigene Leitlinien veröffentlicht.

Eine KI-Richtlinie sollte deshalb definieren:

  • Wann muss auf KI hingewiesen werden?
  • Wann müssen Inhalte gekennzeichnet werden?
  • Wie werden KI-generierte Bilder gekennzeichnet?
  • Wie werden Deepfakes behandelt?
  • Wie werden Chatbots kenntlich gemacht?
  • Wie werden KI-generierte Dokumente behandelt?

 

21. Urheberrecht und geistiges Eigentum

Auch dieser Punkt sollte erweitert werden.

Zu betrachten sind:

  • Trainingsdaten
  • Copyright
  • Lizenzbedingungen
  • Open Source
  • Softwarelizenzen
  • Unternehmenswissen
  • Geschäftsgeheimnisse
  • KI-generierte Inhalte
  • Rechte Dritter

Besonders für Softwareentwickler ist wichtig:

KI-generierter Code darf nicht ungeprüft übernommen werden.

Es müssen weiterhin die üblichen Prozesse für Lizenzprüfung, Security Review und Qualitätssicherung gelten.

 

22. Business Continuity und Exit Strategy

Was passiert, wenn der KI-Anbieter morgen nicht verfügbar ist?

Oder:

  • API fällt aus
  • Modell wird geändert
  • Anbieter erhöht Preise
  • Datenstandort ändert sich
  • Service wird eingestellt
  • Modell wird schlechter
  • Unternehmen verliert den Zugang

Für kritische KI-Systeme sollte deshalb eine Exit-Strategie existieren.

Beispiele:

  • alternatives Modell
  • alternativer Provider
  • lokales Modell
  • manueller Prozess
  • Fallback-System
  • Datenexport
  • Wiederanlaufverfahren

Damit wird KI auch zu einem Thema für Business Continuity Management.

 

23. KI und bestehende Managementsysteme verbinden

Eine der größten Chancen liegt darin, KI nicht als isoliertes Compliance-Projekt aufzubauen.

Viele Unternehmen verfügen bereits über:

  • ISO 9001
  • ISO 27001
  • ISO 22301
  • ISO 31000
  • ISO 13485
  • IT Service Management
  • Datenschutzmanagement
  • Compliance Management

KI kann in diese Systeme integriert werden.

Besonders interessant ist die Kombination:

ISO/IEC 27001 + ISO/IEC 42001 + ISO/IEC 23894

ISO/IEC 42001 stellt das Managementsystem für KI bereit, während ISO/IEC 23894 konkrete Orientierung für das Management KI-spezifischer Risiken gibt.

Damit kann beispielsweise ein bestehendes ISMS um AI Governance erweitert werden.

 

24. Die KI-Richtlinie als praktisches Regelwerk

Eine moderne KI-Richtlinie sollte deshalb mindestens folgende Kapitel enthalten:

1. Zweck und Geltungsbereich

2. Begriffe und Definitionen

3. AI Governance und Verantwortlichkeiten

4. KI-Inventar

5. Klassifizierung von KI-Systemen

6. EU AI Act und regulatorische Anforderungen

7. Zulässige und verbotene Anwendungen

8. Datenschutz und personenbezogene Daten

9. Informationsklassifizierung

10. LLM-Nutzung

11. RAG und Unternehmenswissen

12. AI Agents und autonome Systeme

13. Identitäten und Berechtigungen

14. Human Oversight

15. KI-Output und Qualitätssicherung

16. KI-gestützte Softwareentwicklung

17. AI Security

18. AI Supply Chain

19. Beschaffung und Third-Party Risk

20. AI Lifecycle Management

21. Testing und Red Teaming

22. Logging und Audit Trail

23. Incident Management

24. Business Continuity und Exit

25. Schulung und AI Literacy

26. Transparenz und Kennzeichnung

27. Urheberrecht und geistiges Eigentum

28. Monitoring und Audit

29. Kennzahlen und Management Review

30. Sanktionen und Verstöße

31. Revision und kontinuierliche Verbesserung

 

25. Ein praktischer Freigabeprozess

In der Praxis sollte ein Unternehmen nicht für jede KI-Anwendung einen mehrwöchigen Freigabeprozess benötigen.

Sinnvoll ist ein risikobasierter Ansatz.

Beispielsweise:

KI-Idee

↓

Was soll die KI tun?

↓

Welche Daten verwendet sie?

↓

Greift sie auf Unternehmenssysteme zu?

↓

Kann sie selbstständig Aktionen durchführen?

↓

Welche Personen oder Produkte sind betroffen?

↓

AI-Act-Klassifizierung

↓

Datenschutzprüfung

↓

Security Risk Assessment

↓

Supplier Assessment

↓

Test

↓

Freigabe

↓

Betrieb und Monitoring

↓

Regelmäßige Neubewertung

 

 

Fazit

Eine KI-Richtlinie für 2026 sollte nicht mehr ausschließlich eine „Do-not-do-Liste für ChatGPT“ sein.

Die eigentliche Herausforderung besteht darin, KI kontrolliert in bestehende Geschäftsprozesse zu integrieren.

Dabei sollte ein Unternehmen vier Ebenen unterscheiden:

1. Mensch
Wer darf KI verwenden und wer trägt Verantwortung?

2. Daten
Welche Informationen darf die KI sehen und verarbeiten?

3. Modell
Welches Modell wird verwendet, wie wurde es entwickelt und welchen Risiken unterliegt es?

4. Agent / Handlung
Was darf die KI selbstständig tun?

Gerade die vierte Ebene wird in den kommenden Jahren entscheidend.

Denn der Schritt von

„KI beantwortet meine Frage“

zu

„KI erledigt die Aufgabe für mich“

verändert das Risikomodell fundamental.

Eine moderne AI Governance muss deshalb nicht nur KI-Nutzung, sondern KI-Verhalten kontrollieren.

Das Ziel sollte dabei nicht sein, KI möglichst stark einzuschränken.

Das Ziel ist vielmehr:

KI dort ermöglichen, wo sie Nutzen schafft – und dort kontrollieren, wo sie Risiken erzeugt.

So wird aus einer KI-Richtlinie ein praktischer Bestandteil von Informationssicherheit, Risikomanagement, Compliance, Datenschutz, Qualitätsmanagement und Resilienzmanagement.

KI Governance ist damit nicht mehr nur ein IT-Thema. Sie wird zu einer Managementaufgabe.


P.S.

Im Rahmen eines ISMS gemäß ISO/IEC 27001:2022, könnten folgende Kapitel als Basis dienen, einzelne Themen konkret und detaillierter zu verankern, und zu auditieren, z.B.


Auditreferenzen ISO / IEC 27001:

  • Richtlinien: A.5.1
  • Regulatorisches / Compliance / Transparenz / Kennzeichnung: A.5.31, A.5.34
  • AI Governance, Verantwortungen, Rollen A.5.2, A.5.4
  • KI Inventar: A.5.9
  • KI Risikobewertung, und Schutzbedarfsklassifizierung: 6.1.2, 6.1.3, A.5.12
  • Eigene Entwicklungen von LLM oder Agents: A.8.25 ff, und A.8.8
  • Agent Permissions: A.5.15 ff, A.8.3, A.8.12 (DLP)
  • AI Lieferanten / Cloud Dienste A.5.23
  • Änderungen A.8.32
  • Logging / Audit Trail / Monitoring: A.8.15 A:.8.16
  • AI Related Incident Mgmt: A:5.24 ff
  • BCM : A.5.29 ff
  • KI Kompetenz, Awareness: A.6.3
  • Urheberrecht / Intelectual Property: A.8.32
  • KVP / Reporting / Überwachung: A.5.36


Ihr Konstantin Ziouras

Konstantin Ziouras Blog Artikel

von Konstantin Ziouras • 5. Oktober 2026
Wenn die Kennzahl zum Ziel wird – eine kleine Parabel über KPI und Wirksamkeit
von Konstantin Ziouras • 5. Oktober 2026
ISMS-Wirksamkeit messen – Ein Mindestmaß an Zielen, KPI und Metriken
von Konstantin Ziouras • 22. September 2026
Software Testing und Test Management nach ISTQB - International Software Testing Qualifications Board
von Konstantin Ziouras • 22. September 2026
Anforderungsmanagement nach IREB - International Requirements Engineering Board
von Konstantin Ziouras • 22. September 2026
Requirements Engineering als Qualitäts- und Sicherheitsfaktor
von Konstantin Ziouras • 18. Mai 2026
Unterschiede zwischen EULA, SLA und AVV
von Konstantin Ziouras • 18. Mai 2026
Unterschiede und Parallelen bezüglich Bewertungen, bezüglich Lieferanten, Software, Cloud Dienstleistern
von Konstantin Ziouras • 10. Mai 2026
Risiken bezüglich Lieferanten
von Konstantin Ziouras • 10. Mai 2026
Lieferanten, Auswahl und Bewertung
von Konstantin Ziouras • 15. April 2026
Endpoint Security bedeutet: Schutz aller Endgeräte, die mit IT Systemen verbunden sind – also Laptops, Desktops, Smartphones, Tablets, Server, virtuelle Maschinen, Container Hosts, OT HMI Rechner etc. Bildlich: Jedes Gerät ist eine Tür ins Unternehmen. Endpoint Security sorgt dafür, dass diese Türen: • nicht offenstehen • nicht mit gestohlenen Schlüsseln geöffnet werden • und im Idealfall einen Alarm auslösen, wenn jemand versucht einzubrechen. Warum das Thema heute wichtig ist 1. Angriffe starten fast immer am Endpoint • Phishing Mails → Klick → Malware auf dem Laptop • Ransomware → Verschlüsselung startet am Endpoint • Initial Access Broker → kompromittierte Endgeräte werden verkauft 2. Arbeitswelt hat sich verändert • Homeoffice, Remote Work, BYOD • Cloud Zugriffe von überall • Mehr Endgeräte, weniger klarer Perimeter 3. Business Relevanz • Ein kompromittierter Endpoint kann: o Zugang zu AD / Identitäten geben o Ransomware ins gesamte Netz bringen o Datenabfluss ermöglichen • Direkte Auswirkungen: Ausfall, Lösegeld, Reputationsschäden, NIS2 Sanktionen. Technische Grundlagen Kernidee: Endpoint Security kombiniert Schutz, Erkennung und Reaktion direkt auf dem Gerät. Wichtige Bausteine: • Antivirus / Anti Malware: Signatur und verhaltensbasierter Schutz • Host Firewall: Filtert eingehenden/ausgehenden Traffic • Endpoint Detection & Response (EDR): Erkennung verdächtigen Verhaltens, Forensik, Response • Extended Detection & Response (XDR): Korrelation von Endpoint Daten mit Netzwerk, Cloud, Identitäten • Hardening: Konfiguration, die Angriffsfläche reduziert (z. B. Deaktivierung unnötiger Dienste) • Patch Management: Schließen von Schwachstellen Stand der Technik / Best Practices 1. Von klassischem AV zu EDR/XDR • Klassischer Virenscanner allein ist nicht mehr ausreichend. • Stand der Technik: EDR/XDR Lösungen, die Verhalten analysieren, Prozesse korrelieren und Angriffe in frühen Phasen erkennen. 2. Zero Trust am Endpoint • Endpoint wird nicht automatisch vertraut, nur weil er „im Netz“ ist. • Kombination aus: o Gerätestatus (Compliance) o Identität (User) o Kontext (Ort, Zeit, Risiko) 3. Harter Fokus auf Identitäten • Endpoint Security ist eng mit Identity & Access Management verknüpft. • Kompromittierter Endpoint → kompromittierte Identität → lateral movement. 4. Standardisierte Baselines • CIS Benchmarks, BSI Empfehlungen, Hardening Guides • Standardisierte Konfigurationen für Windows, macOS, Linux, Mobile, OT Systeme. Typische Risiken & Fehler in der Praxis • Nur Antivirus, kein EDR/XDR • Kein zentrales Management der Endpoints • Ungepatchte Systeme (insbesondere Drittsoftware wie Browser, Java, Office Plugins) • Lokale Adminrechte für Benutzer • Kein Application Whitelisting (alles darf laufen) • Shadow IT (private Geräte, nicht verwaltete Systeme) • OT Endpoints ohne Schutz, weil „Produktionssysteme darf man nicht anfassen“ • Fehlende Integration in SIEM/SOC – Alarme bleiben unbemerkt Moderne Lösungsansätze & Technologien • EDR/XDR Plattformen o Sammeln Telemetrie (Prozesse, Registry, Netzwerk, Dateien) o Erkennen verdächtige Muster (z. B. Ransomware Verhalten) o Unterstützen Incident Response (Isolieren von Endpoints, Forensik) • Zero Trust Network Access (ZTNA) o Zugriff auf Anwendungen nur, wenn Endpoint „gesund“ ist (Compliance Check) • Mobile Device Management (MDM) / Unified Endpoint Management (UEM) o Verwaltung von Laptops, Smartphones, Tablets, teilweise auch IoT/OT o Erzwingung von Policies (Verschlüsselung, PIN, Jailbreak Erkennung) • Application Control / Whitelisting o Nur erlaubte Anwendungen dürfen laufen o Sehr wirksam gegen Malware und Ransomware • Hardware basierte Sicherheit o TPM, Secure Boot, Device Guard, Plattferverschlüsselung (BitLocker, FileVault) Relevanz für Informationssicherheit & Compliance NIS2 • Verlangt „Stand der Technik“ bei technischen und organisatorischen Maßnahmen. • Endpoint Security ist zentral für: o Schutz vor Ransomware o Incident Detection & Response o Nachweis von Maßnahmen gegenüber Aufsichtsbehörden. ISO 27001:2022 • Relevante Controls u. a.: o A.5.15: Access control o A.5.23: Information security for use of mobile devices o A.8.7: Protection against malware o A.8.8: Management of technical vulnerabilities o A.8.9: Configuration management IEC 62443 (für OT) • Endpoint ähnliche Systeme (Engineering Stationen, HMI, Server) müssen: o gehärtet sein o nur notwendige Dienste bereitstellen o überwacht werden o in Zonen/Conduits eingebettet sein. Endpoint Security ist damit ein Pflichtbaustein für jede ernsthafte Umsetzung von NIS2, ISO 27001 und IEC 62443. Empfehlungen für Unternehmen (konkret, priorisiert) Priorität 1 – Basis schaffen • Zentrales Endpoint Management einführen (Windows, macOS, Linux, Mobile) • EDR Lösung ausrollen (mindestens auf kritischen Systemen) • Patch Management etablieren (inkl. Drittsoftware) • Plattferverschlüsselung aktivieren (Laptops, mobile Geräte) • Lokale Adminrechte abschaffen (Role Based Access, Just in Time Admin) Priorität 2 – Reifegrad erhöhen • Application Whitelisting für besonders kritische Systeme • Zero Trust Policies: Zugriff nur bei „gesundem“ Endpoint • Integration in SIEM/SOC: Alarme zentral auswerten • Standardisierte Hardening Baselines (CIS, BSI) Priorität 3 – OT & Spezialumgebungen • OT Endpoints inventarisieren (Engineering Stationen, HMI, SCADA Server) • Schutzkonzept definieren: o Hardening o Segmentierung o Monitoring (passiv, wo aktiv nicht möglich) • Remote Zugriffe auf OT nur über kontrollierte Jump Hosts mit starker Authentifizierung und Session Recording. CTO Checkliste: Die 3 entscheidenden Fragen 1) „Wie erkennen und stoppen wir heute einen Angriff auf einen Endpoint, der keine bekannte Malware Signatur hat?“ Diese Frage trennt klassischen Antivirus von echtem EDR/XDR. Eine moderne Antwort muss enthalten: • verhaltensbasierte Erkennung • Prozess und Speicheranalyse • Telemetrie Korrelation • automatische Isolation des Endpoints • Integration ins SOC/SIEM Wenn die Antwort nur „Antivirus“ oder „Signaturen“ enthält → nicht modern. 2) „Wie stellen wir sicher, dass alle Endgeräte (inkl. Homeoffice, mobile Geräte, Admin Laptops, OT Engineering Stationen) vollständig verwaltet, gepatcht und gehärtet sind?“ Diese Frage deckt Management Reifegrad, Patch Prozesse und Hardening auf. Eine moderne Antwort muss enthalten: • zentrales Endpoint Management (UEM/MDM) • automatisiertes Patch Management (inkl. Drittsoftware) • CIS/BSI Hardening Baselines • Compliance Checks vor Zugriff (Zero Trust) Wenn die Antwort „Wir patchen regelmäßig“ lautet → nicht ausreichend. 3) „Wie schnell können wir einen kompromittierten Endpoint identifizieren, isolieren und forensisch analysieren – und wer macht das konkret?“ Diese Frage prüft Incident Response Fähigkeit und operative Realität. Eine moderne Antwort muss enthalten: • EDR gestützte Isolation per Klick • klare Rollen (SOC, IT Ops, Dienstleister) • forensische Daten (Prozesse, Registry, Netzwerk, Timeline) • definierte Reaktionszeiten • Playbooks Wenn die Antwort unklar ist oder niemand zuständig ist → kritische Lücke.