Von der Quelle bis zum Betrieb: KI-Projekte sicher umsetzen mit Data Governance und Zero Trust

In KI-Projekten entstehen von der Planung bis zum aktiven Betrieb Risiken, die es bei klassischen Softwareprojekten so nicht gibt: manipulierte oder voreingenommene Trainings- und Grounding-Daten, kompromittierte Vortrainingsquellen, unsichere Abhängigkeiten in Build-Pipelines oder unzureichend getestete agentenbasierte Systeme. Gleichzeitig erhöhen regulatorische Rahmen wie der europäische AI Act sowie Sicherheitsrahmen wie die Leitlinien des Open Web Application Security Project (OWASP) den Druck, Risiken früh zu erkennen und durchgängig zu managen.

Dieser Blog-Beitrag zeigt, wie sich Data Governance und Zero Trust entlang der gesamten Supply Chain verankern lassen – von der Zieldefinition über die Datenaufnahme und -validierung bis hin zu Training, Deployment und Betrieb.

Risiken in der KI-Supply-Chain

KI-Projekte unterscheiden sich grundlegend von klassischen Softwarevorhaben, da nicht nur der Code, sondern vor allem die Daten, Modelle und Pipelines die Sicherheitslage bestimmen. Entlang der gesamten Lieferkette entstehen neue Angriffsflächen: von intransparenten Trainings- und Grounding-Daten über vortrainierte Modelle bis hin zu Build- und Bereitstellungsprozessen. Ohne durchgängige Data Governance, klare Herkunftsnachweise (Provenance) und Identitätsschutz wird jede KI schnell zum Risiko. Genau hier setzen Data Governance und Zero Trust an. Ihr kontrolliert jede Identität, jeden Zugriff und jeden Datenfluss und macht sie nachweisbar.

Data Governance & Lifecycle Management: Von der Quelle bis zur Archivierung

Der Lebenszyklus deiner Daten bildet die Grundlage für deren Absicherung: von der Aufnahme über die Validierung, Speicherung und Versionierung bis hin zur Nutzung in Training und Betrieb sowie Archivierung und Löschung. Für jede Phase sind Verantwortlichkeiten, Richtlinien und technische Kontrollen erforderlich. Dabei ist Data Lineage, also die lückenlose Nachvollziehbarkeit, welche Daten wann, wo und wofür genutzt wurden, entscheidend. Genauso wichtig ist die Versionierung von Daten, Modellen und Pipelines, damit ihr Änderungen prüfen, reproduzieren und bei Bedarf zurückrollen könnt. Auf Zugriffsebene kombiniert ihr rollenbasierte (Role-Based Access Control, RBAC) und attributbasierte (Attribute-Based Access Control, ABAC) Zugriffskontrollen, um das „Need-to-know“-Prinzip konsequent umzusetzen.

Sichere Datenaufnahme und -validierung: Provenance, Zugriff, Anomalien

Beginnen wir an der Quelle: Bei der Datenaufnahme treffen interne Systeme auf Partnerdaten, Open Data, externe Programmierschnittstellen (APIs) und manuelle Annotationen. Für jede Quelle sind eine Herkunftsvalidierung und klare Vertrauensanker erforderlich, um manipulierte Datensätze und Data Poisoning zu verhindern. Gleichzeitig müssen Identitäten und Dienstkonten stark authentifiziert und minimal berechtigt sein. In der Validierungsphase sichern Schema-Prüfungen, Signaturen oder Hash-Prüfsummen sowie Bias-Analysen die Qualität und Integrität der Daten. Data Contracts, also verbindliche Vereinbarungen über Struktur und Qualität von Daten sowie Anomalieerkennung stellen sicher, dass nur erwartete und geprüfte Datenflüsse in die Pipeline gelangen.

Schutz im Transit und bei Speicherung: Verschlüsselung, Audit, Compliance

Sobald Daten transportiert oder gespeichert werden, greift ein mehrschichtiger Schutz. Im Transit setzt du auf gesicherte Tunnel und Transportverschlüsselung sowie nach Möglichkeit auf beidseitige Authentifizierung (Mutual Auth), flankiert von vollständigem Audit-Logging. Bei der Speicherung kommen Verschlüsselung im Ruhezustand, unveränderbare Speicher (Immutable Storage), Hash-Verifikation nach Transfers und Zugriffe strikt über RBAC/ABAC zum Einsatz. Auf der Compliance-Seite helfen automatisierte Scans für personenbezogene Daten (Personally Identifiable Information, PII), Richtlinien für die Datenschutz-Grundverordnung (DSGVO) und Data Loss Prevention (DLP), damit Governance nicht nur dokumentiert, sondern auch technisch durchgesetzt wird.

Machine Learning sicher gestalten: Trainingsmethoden und Supply-Chain-Risiken

Das Training birgt eigene Risiken: Bei überwachten Verfahren drohen manipulierbare Labeling-Prozesse oder verzerrte externe Datensätze. Beim Fine-Tuning mit vortrainierten Modellen besteht die Gefahr kompromittierter Quellen und unkontrollierter Dateneinbringung. Beim Reinforcement Learning from Human Feedback (RLHF) können manipulierte Feedback-Kanäle zu Fehlleitungen führen, während Simulationen Fehlverhalten verstärken, wenn die Umgebung nicht sauber kontrolliert ist. Dem könnt ihr mit verifizierten Quellen, Integritätsprüfungen über Signaturen und Hashes für Modelle, Datensätze und Container, reproduzierbaren Trainingspipelines mit deterministischen Builds sowie isolierten, internetlosen Trainingsumgebungen mit kontrollierten Abhängigkeiten entgegenwirken. Ergänzend helfen regelmäßige Software-Stücklisten (Software Bill of Materials, SBOM) für Container und Modellartefakte, um Abhängigkeiten und Schwachstellen transparent zu halten.

Secure Development & Testing: Best Practices und Microsoft-Tools

Sichere Entwicklung und Tests runden den Prozess ab. Threat Modeling für KI, also das systematische Identifizieren von Bedrohungen entlang des Datenflusses, des Modellpfads und der Drittkomponenten, ist bereits in der Planungsphase zu berücksichtigen. In den Phasen Build und Deployment setzt du auf signierte Artefakte, Policy-as-Code, das konsequente Vier-Augen-Prinzip und Secrets-Scanning. Im Betrieb beobachtet ihr Drift, leitet aus Telemetrie klare Alarme ab und haltet Rollback-Strategien bereit. Für Notebook-Workflows und Developer Workspaces gelten die gleichen Sicherheitsprinzipien wie für klassische integrierte Entwicklungsumgebungen. Netzisolation, reproduzierbare Umgebungen und Tools wie NB Defense zur Härtung. Für agentenbasierte Systeme hat sich eine kaskadierende Teststrategie in der MLOps-Pipeline bewährt: vom Unit- und Prompt-Test über Tool-Use-Checks bis hin zum Red-Teaming vor dem

Wir stellen fest: Ein sicheres KI-Projekt braucht beide Dimensionen, Technologie und Mensch.

Nur wenn technische Schutzmaßnahmen mit Governance, Schulung, Kommunikation und klaren Verantwortlichkeiten zusammenspielen, entsteht echte Vertrauenswürdigkeit. Das zeigt auch das adesso-Modell „Trustworthy AI“, das technologische, menschliche und regulatorische Aspekte systematisch vereint (siehe folgende Abbildung).

Durch die Kombination regulatorischer Perspektiven (Rico Komenda) mit tiefem technischem Know-how im Bereich Cloud- und Identitätssicherheit (Marc Iridon) zeigt der Beitrag anhand konkreter Praxis- und Forschungsbeispiele, wie Organisationen KI-getriebene Systeme sicher entwickeln und betreiben können. Im Fokus stehen praxistaugliche Strategien zur Absicherung entlang der gesamten KI-Wertschöpfungskette, von der Modellintegrität über Herkunftsnachweise bis hin zu Microsoft-basierten Schutzmechanismen für produktive, oft sicherheitskritische Umgebungen.

Praxisbeispiel: Supply-Chain-Security mit Microsoft

In Microsoft-Umgebungen lassen sich viele der vorgestellten Prinzipien direkt umsetzen. Microsoft Purview ermöglicht Datenklassifizierung, Lineage, Richtlinienkontrolle und schafft domain-übergreifende Governance. Microsoft Entra regelt Identitäten, Multi-Faktor-Authentifizierung und Zugriffssteuerung, auch für Service-Accounts in MLOps-Pipelines. Microsoft Defender for Cloud liefert kontinuierliche Schwachstellenanalysen, Härtung von Containerketten und Compliance-Empfehlungen. Sentinel kann zur Sicherheitsanalyse entlang der Daten- und Modellstrecke eingesetzt werden.

Ein konkretes Projektbeispiel zeigt: Heterogene Datenquellen wurden mit Purview katalogisiert und ihre Herkunft dokumentiert, Zugriffe mit Entra abgesichert, Build-Strecken mit Defender for Cloud gehärtet. Ergebnis: weniger Schatten-IT, nachvollziehbare Trainingsläufe, Audit-Sicherheit und eine stabile Grundlage für AI-Compliance.

Fazit

Sichere KI entsteht durch eine durchgängige Kette aus Data Governance und Zero Trust, von der Datenquelle über Training bis zum Betrieb. Wenn Herkunft, Zugriffe und Versionen nachvollziehbar sind, sinkt das Risiko für Manipulationen, Compliance-Verstöße und Betriebsstörungen. Das zahlt direkt auf Anforderungen wie den europäischen AI Act, Leitlinien aus dem OWASP-Umfeld ein.