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 • 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.
von Konstantin Ziouras • 14. April 2026
1. Was ist eine Firewall? Stell dir dein Netzwerk wie ein Gebäude vor. Eine Firewall ist: • Der Türsteher: Prüft, wer rein darf. • Der Sicherheitszaun: Hält unerwünschte Besucher draußen. • Die Schleuse: Kontrolliert jeden, der das Gelände betreten oder verlassen will. Sie entscheidet basierend auf Regeln: Wer darf mit wem worüber sprechen? 2. Was ist ein Gateway? Ein Gateway ist wie ein Grenzübergang zwischen zwei Bereichen: • zwischen internem Netzwerk und Internet • zwischen IT und OT • zwischen Cloud und On Premises • zwischen verschiedenen Sicherheitszonen Es kontrolliert: • welche Daten passieren dürfen • wie sie geprüft werden • ob sie sicher sind 3. Warum braucht man Firewalls und Gateways? Weil Netzwerke ohne sie offene Häuser wären. Sie schützen vor: • Hackern • Malware • Ransomware • Datenklau • unbefugten Zugriffen • Angriffen auf OT Systeme Ohne Firewalls wäre jedes Gerät direkt aus dem Internet erreichbar — ein Albtraum. 4. Welche Arten von Firewalls gibt es? 1) Klassische Firewalls • prüfen IP Adressen und Ports • wie ein Türsteher, der nur auf die Eintrittskarte schaut 2) Next Generation Firewalls (NGFW) • prüfen Inhalte • erkennen Angriffe • filtern Apps (z. B. „erlaube nur Teams, blockiere Torrent“) • wie ein Türsteher, der auch Taschen kontrolliert 3) Web Application Firewalls (WAF) • schützen Webseiten und APIs • blockieren SQL Injection, XSS, Bots 4) OT Firewalls • verstehen industrielle Protokolle (Modbus, OPC UA) • blockieren gefährliche Befehle • schützen Produktionsanlagen 5) Cloud Firewalls • steuern Traffic in AWS, Azure, GCP • sind Teil moderner Cloud Architekturen 5. Wie schützen Firewalls uns? Sie: • blockieren Angriffe • verhindern unbefugte Zugriffe • segmentieren Netzwerke • überwachen Datenverkehr • erkennen Anomalien • stoppen Malware • schützen kritische Systeme 6. Typische Fehler (die in der Praxis noch vorkommen) • „Allow ANY ANY“ (alles erlaubt) • keine Segmentierung (Flat Network) • keine Dokumentation • veraltete Regeln • keine Überwachung • keine TLS Inspection → Blindflug • OT Netze ohne Protokollfilter 7. Was bedeutet das für Unternehmen? Sie brauchen: • klare Netzwerkzonen • moderne Firewalls • regelmäßige Regelwerks Reviews • Monitoring & Logging • Zero Trust Prinzipien • OT spezifische Schutzmaßnahmen • Cloud Firewalls für moderne Umgebungen 8. Verbindung zu Standards • NIS2 verlangt „angemessene technische Maßnahmen“ → Firewalls sind Pflicht • ISO 27001 verlangt Netzwerksegmentierung und Zugriffskontrollen • IEC 62443 verlangt Zonen/Conduits und OT Firewalls • ISO 22301 verlangt Schutz kritischer Systeme Kurz gesagt Firewall und Gateway Sicherheit bedeutet: • Netzwerke in sichere Bereiche aufteilen • nur erlaubten Verkehr zulassen • Angriffe erkennen und blockieren • OT und Cloud Systeme speziell schützen • Regeln regelmäßig prüfen • Monitoring aktiv betreiben Es ist die Grundlage jeder modernen Sicherheitsarchitektur. Checkliste für Firewall und Gateway Sicherheit 1. Architektur & Netzwerkdesign • Netzwerk in Sicherheitszonen segmentiert (z. B. IT, OT, DMZ, Cloud) • Klare Trust Boundaries definiert • Firewalls an allen Übergängen zwischen Zonen platziert • Redundante Firewall Cluster vorhanden • Zero Trust Prinzipien berücksichtigt • OT Netze strikt von IT getrennt • Remote Zugänge nur über gesicherte Gateways 2. Regelwerk & Policies • „Deny by default“ als Grundprinzip • Nur explizit erlaubte Verbindungen freigeschaltet • Keine ANY Regeln (Any Source, Any Destination, Any Service) • Identity-based Rules (Regeln basieren auf User-Gruppen, nicht nur IPs) • Regeln nach Least Privilege Prinzip • Regelwerk dokumentiert und versioniert • Regelwerk regelmäßig überprüft (mind. quartalsweise) • Alte oder ungenutzte Regeln entfernt • Regeln nach Zonen, Services und Verantwortlichkeiten strukturiert 3. Traffic Analyse & Inspektion • Deep Packet Inspection (DPI) aktiviert • TLS Inspection für relevante Verbindungen aktiviert • Intrusion Prevention System (IPS) aktiv • Virtual Patching (WAF/IPS schützt vor Lücken, für die es noch kein Software-Update gibt). • Malware Scanning aktiviert • Bot und Anomalie Erkennung aktiv • Geo Blocking (falls sinnvoll) • Rate Limiting für kritische Services 4. Web , API und Cloud Gateways • Web Application Firewall (WAF) für Web Anwendungen aktiv • API Gateway mit Auth, Rate Limit, Input Validation • Schutz vor OWASP API Top 10 • Cloud Firewalls (AWS/Azure/GCP) korrekt konfiguriert • Keine offenen Cloud Security Groups • CDN /Edge Security integriert (falls genutzt) 5. OT /ICS spezifische Firewall Sicherheit • OT Firewalls verstehen industrielle Protokolle (Modbus, OPC UA, S7) • Protokoll Whitelisting aktiv • Unidirektionale Gateways (Data Diodes) für kritische Systeme • Engineering Ports nur temporär freigeschaltet • Keine direkten Verbindungen zwischen IT und OT • OT Zonen nach IEC 62443 modelliert 6. Zugriffskontrolle & Administration • Administrationszugänge nur über Jump Server • MFA für alle Admin Zugänge • RBAC für Firewall Management • Änderungen nur über Change Management • Konfigurations Backups vorhanden • Firmware aktuell und signiert • Admin Sessions geloggt 7. Logging, Monitoring & SIEM • Zentrales Logging aller Firewall Events • Logs werden mindestens 12 Monate aufbewahrt • SIEM Integration vorhanden • Alerts für kritische Ereignisse (z. B. Port Scans, Blocked Traffic) • Anomalie Erkennung aktiv • Regelmäßige Auswertung der Logs • Forensik Daten vollständig 8. Tests & Qualitätssicherung • Regelmäßige Penetrationstests • Firewall Regelwerk wird automatisiert geprüft • Konfigurations Drift Erkennung aktiv • Notfall Szenarien getestet (Failover, Cluster Switch) • Testumgebung für Regeländerungen vorhanden • Regelmäßige Überprüfung der TLS Inspection 9. Dokumentation & Compliance • Vollständige Dokumentation der Firewall Topologie • Regelwerk dokumentiert und nachvollziehbar • Verantwortlichkeiten definiert • Audit Trails vorhanden • Konformität zu Standards geprüft, z.B. o NIS2 o ISO 27001 (A.8.20, A.8.16, A.5.17/18) o IEC 62443 (Zonen/Conduits, SR 3.x, SR 5.x, SR 7.x) o ISO 22301 (Schutz kritischer Systeme) 10. Typische Fehler, die vermieden werden müssen • Keine ANY Regeln • Keine offenen Ports „zur Sicherheit“ • Keine unüberwachten Remote Zugänge • Keine veralteten Firewall Versionen • Keine ungenutzten Regeln • Keine direkte IT ↔OT Kommunikation • Keine / fehlende TLS Inspection
von Konstantin Ziouras • 14. April 2026
Docker ist eine Technologie, mit der Software in Container verpackt wird. Ein Container ist wie eine kleine, abgeschlossene Box, in der alles drin ist, was ein Programm zum Laufen braucht: die Anwendung selbst Bibliotheken Konfigurationen Systemabhängigkeiten Dadurch läuft die Software überall gleich, egal ob: auf einem Laptop in der Cloud auf einem Server in einem Rechenzentrum Docker löst das klassische Problem „Bei mir läuft’s, bei dir nicht“ vollständig. Warum Container? Weil klassische Software oft abhängig ist von: • bestimmten Versionen von Bibliotheken • bestimmten Betriebssystemen • bestimmten Konfigurationen Container isolieren diese Abhängigkeiten — wie ein eigenes Mini System. Wie funktioniert Docker technisch? Docker nutzt Containerisierung, nicht Virtualisierung. Virtual Machine (VM) enthält ein komplettes Betriebssystem braucht viel Speicher startet langsam Docker Container nutzt das Host Betriebssystem mit ist extrem leichtgewichtig startet in Sekundenbruchteilen Technisch basiert Docker auf: Namespaces (Isolation) cgroups (Ressourcenbegrenzung) Union File Systems (schichtbasierte Images) Woraus besteht Docker? 1. Docker Image Ein Image ist eine Bauvorlage für Container. Beispiel: „Webserver Image“, „Python App Image“. 2. Docker Container Ein laufendes Exemplar eines Images. Beispiel: „Webserver Container läuft jetzt auf Port 80“. 3. Dockerfile Eine Textdatei, die beschreibt, wie ein Image gebaut wird. 4. Docker Engine Die Software, die Container startet und verwaltet. 5. Docker Hub Eine Art „App Store“ für fertige Images. Wofür wird Docker genutzt? 1. Softwareentwicklung Entwickler können identische Umgebungen nutzen. 2. DevOps & CI/CD Automatisierte Builds, Tests und Deployments. Ein Entwickler kann per Knopfdruck eine komplexe Datenbank-Umgebung starten, ohne sie lokal installieren zu müssen. Automatisches Testen von Code in einer sauberen Umgebung. 3. Microservices Jeder Service läuft in seinem eigenen Container. Statt einer riesigen, schweren Software nutzt man 20 kleine Container, die miteinander kommunizieren. 4. Cloud Betrieb Container sind perfekt für AWS, Azure, GCP. 5. Skalierung Container können automatisch hoch und runtergefahren werden. Sicherheitsaspekte (für Nicht Admins) Container sind isoliert, aber teilen sich den Kernel. Das bedeutet: • sie sind sicherer als klassische Apps • aber weniger isoliert als VMs Wichtige Sicherheitsmechanismen: Signierte Images Trusted Registries Schwachstellenscans (z.B. mit Trivy, Clair) Least Privilege (keine Root Container)