Supply Chain Sicherheit: Die unsichtbare Achillesferse Ihrer KI-Infrastruktur

In den ersten drei Teilen dieser Serie haben wir uns mit sichtbaren Bedrohungen beschäftigt: Prompt Injection, Jailbreaking, Deepfakes, Social Engineering. Alles Angriffe, die man – mit etwas Training – erkennen kann. Doch heute widmen wir uns einer Dimension der KI-Sicherheit, die fast niemand auf dem Radar hat, obwohl sie möglicherweise das größte Risiko darstellt: Die Supply Chain.

Wenn Sie „KI“ denken, sehen Sie vermutlich das Chat-Interface vor sich. Sie geben Text ein, die KI antwortet. Ein sauberer, abgeschlossener Vorgang. Die Realität sieht radikal anders aus: Hinter diesem simplen Dialog verbirgt sich eine hochkomplexe Infrastruktur aus Dutzenden Komponenten, verteilt über mehrere Kontinente, betrieben von verschiedenen Unternehmen, verbunden durch zahlreiche Schnittstellen.

Jede dieser Komponenten ist ein potenzielles Einfallstor. Jede Schnittstelle eine mögliche Schwachstelle. Jeder Serverstandort eine rechtliche Grauzone. Willkommen in der oft übersehenen, aber kritischen Welt der Supply Chain Security bei KI-Systemen.

Was ist ein KI-System wirklich?

Lassen Sie uns mit einem Missverständnis aufräumen. Wenn OpenAI von „GPT-4“ spricht oder Anthropic von „Claude“, dann ist das keine einzelne Softwarekomponente. Es ist ein hochkomplexes System aus vielen Teilen, die nahtlos zusammenarbeiten.

Die Anatomie eines modernen KI-Systems

1. Die Modell-Ebene

Selbst das, was wir „ein Modell“ nennen, besteht oft aus mehreren spezialisierten Komponenten:

• Textverarbeitung: Das eigentliche Sprachmodell
• Bildverarbeitung: Ein separates Modell für visuelle Inputs (z.B. CLIP oder ähnliche)
• Audioanalyse: Noch ein Modell für Spracherkennung
• Code-Ausführung: Spezialisierte Komponenten für das Interpretieren und Ausführen von Code

Das „O“ in GPT-4o steht für „Omni“ – omnipräsent in verschiedenen Modalitäten. Aber das bedeutet nicht, dass ein einzelnes neuronales Netz alles macht. Es ist eine Orchestrierung verschiedener Modelle, die intelligent miteinander kommunizieren.

2. Die Infrastruktur-Ebene

Über den Modellen liegt eine massive Infrastruktur:

• GPU-Cluster: Hunderte oder Tausende NVIDIA-Grafikkarten (meist H100 oder A100), die parallel arbeiten
• Load Balancer: Verteilen eingehende Anfragen auf verfügbare Ressourcen
• Container-Orchestrierung: Kubernetes oder ähnliche Systeme, die Modell-Instanzen verwalten
• Cache-Layer: Redis oder ähnliche Systeme, die häufige Anfragen beschleunigen
• Datenbanken: Speichern Nutzer-Sessions, Conversation History, Nutzungsstatistiken

3. Die Service-Ebene

Zwischen Ihnen und den Modellen stehen weitere Schichten:

• API-Gateway: Ihre Anfrage kommt hier zuerst an
• Authentifizierung: Wer sind Sie? Haben Sie Zugriff?
• Rate Limiting: Wie viele Anfragen dürfen Sie stellen?
• Logging & Monitoring: Jede Anfrage wird protokolliert
• Content-Filtering: Vor- und Nachfilterung auf problematische Inhalte

4. Die Netzwerk-Ebene

All diese Komponenten kommunizieren:

• Über interne Netzwerke innerhalb von Rechenzentren
• Über WAN-Verbindungen zwischen verschiedenen Standorten
• Über CDNs für schnellere Antworten weltweit
• Über VPNs für verschlüsselte Kommunikation

Das Problem: Jeder dieser Punkte ist angreifbar

Sie sehen: Wenn Sie eine Frage an ChatGPT stellen, durchläuft Ihre Anfrage Dutzende Systeme. Jedes davon hat:

• Software, die Bugs enthalten kann
• Konfigurationen, die falsch sein können
• Zugriffsrechte, die zu weit gefasst sein können
• Logs, die sensible Daten enthalten können

⚠️ Kritischer Punkt: Die Sicherheit Ihrer KI-Nutzung ist nur so stark wie das schwächste Glied in dieser Kette. Selbst wenn das Modell selbst perfekt abgesichert wäre, könnte ein kompromittierter Load Balancer Ihre Daten abfangen.

Der Serverstandort-Mythos: Warum Frankfurt nicht hilft

Eines der häufigsten Argumente, die ich höre: „Aber unsere Daten liegen doch in Deutschland! Das Rechenzentrum steht in Frankfurt!“

Lassen Sie mich brutal ehrlich sein: Das ist in vielen Fällen irrelevant.

Der Cloud Act: Geographie spielt keine Rolle

Der Clarifying Lawful Overseas Use of Data Act (CLOUD Act) aus dem Jahr 2018 gibt US-Behörden weitreichende Befugnisse. Vereinfacht gesagt:

Wenn ein Unternehmen unter US-Jurisdiktion steht (Hauptsitz in den USA, US-Börsennotierung, etc.), dann müssen sie auf Anforderung Daten herausgeben – unabhängig davon, wo diese physisch gespeichert sind.

Konkrete Beispiele

Microsoft Azure mit Rechenzentrum in Frankfurt:

• Die Server stehen physisch in Deutschland ✓
• Microsoft ist ein US-Unternehmen ✗
• Cloud Act gilt → US-Behörden können Zugriff verlangen

Amazon Web Services (AWS) mit EU-Regionen:

• Die Server stehen in Irland oder Frankfurt ✓
• Amazon ist ein US-Unternehmen ✗
• Cloud Act gilt → US-Behörden können Zugriff verlangen

OpenAI / ChatGPT:

• Nutzt Azure-Infrastruktur (auch in EU-Regionen) ✓
• OpenAI ist ein US-Unternehmen ✗
• Cloud Act gilt → US-Behörden können Zugriff verlangen

Was bedeutet das konkret?

Für die meisten Unternehmen ist das kein akutes Problem. Die US-Regierung interessiert sich nicht für Ihre Power BI-Berichte. Aber:

• Wenn Sie in sensiblen Bereichen arbeiten (Verteidigung, kritische Infrastruktur)
• Wenn Sie mit hochsensiblen Personendaten umgehen (Gesundheit, Finanzen)
• Wenn Sie in Branchen mit strikten Compliance-Anforderungen sind (KRITIS, NIS2)

…dann ist die Frage „Wo steht der Server?“ zu kurz gedacht. Die richtige Frage ist: „Wer kontrolliert das Unternehmen, das den Service betreibt?“

Die Ausnahmen: Echte europäische Alternativen

Es gibt sie, aber sie sind deutlich weniger bekannt:

• Aleph Alpha (Deutschland): Entwickelt eigene Sprachmodelle, deutsche Infrastruktur, deutsches Unternehmen
• Mistral AI (Frankreich): Französisches Unternehmen, europäische Werte
• OVHcloud (Frankreich): Europäischer Cloud-Anbieter ohne US-Bindung

Diese Anbieter sind vom Cloud Act nicht betroffen. Ob sie technologisch mit OpenAI/Anthropic/Google mithalten können, ist eine andere Frage.

💡 Best Practice: Führen Sie eine Data Classification durch. Nicht alle Daten sind gleich sensibel. Vielleicht können Sie US-Anbieter für unkritische Workflows nutzen und europäische Lösungen für sensible Daten.

Man-in-the-Middle: Die unsichtbare Manipulation

Zurück zur technischen Ebene. Ihre Anfrage an ein KI-System durchläuft mehrere Stationen:

Ihr Browser → Internet → Load Balancer → API Gateway → Authentication Service → Model Server → Response zurück

An jedem dieser Übergänge könnte theoretisch jemand mithören oder manipulieren.

Wo sind die Risiken?

1. Ihr lokales Netzwerk Wenn Sie in einem Firmennetzwerk sind und jemand hat Zugriff auf Ihren Router oder Switch, könnten Anfragen abgefangen werden.

2. Internet Service Provider Ihr ISP sieht, dass Sie mit ChatGPT kommunizieren (verschlüsselt, aber die Metadaten sind sichtbar).

3. Zwischen-Rechenzentren Wenn Teile des KI-Systems auf verschiedene Rechenzentren verteilt sind, kommunizieren sie über Netzwerke. Diese Verbindungen könnten kompromittiert sein.

4. Innerhalb des Rechenzentrums Selbst innerhalb eines sicheren Rechenzentrums gibt es interne Netzwerke. Ein kompromittierter Server könnte Traffic abfangen.

Ein hypothetisches, aber technisch mögliches Szenario

Ein Angreifer verschafft sich Zugriff auf einen Load Balancer (z.B. durch eine ungepatchte Schwachstelle). Jetzt kann er:

• Anfragen lesen (und damit sensible Informationen sammeln)
• Antworten modifizieren (die KI sagt „A“, aber Sie erhalten „B“)
• Selektiv Anfragen blocken oder verzögern (gezielter Denial of Service)

Sie würden es nicht merken. Die Kommunikation läuft über HTTPS, sieht verschlüsselt und legitim aus. Aber zwischen Ihnen und dem eigentlichen Modell sitzt jemand.

🔐 Technische Absicherung: End-to-End-Verschlüsselung klingt gut, ist bei KI-Systemen aber komplex. Das Modell muss die Anfrage im Klartext sehen, um sie zu verarbeiten. Vollständige E2E-Encryption gibt es hier (noch) nicht.

Authentifizierung und Session-Management: Unterschätzte Risiken

Lassen Sie uns über etwas sprechen, das selten Aufmerksamkeit bekommt: Wie weiß das KI-System, wer Sie sind?

Das Session-Problem

Wenn Sie sich bei ChatGPT anmelden, erhalten Sie ein Session-Token (z.B. ein Cookie). Dieses Token identifiziert Sie bei jeder Anfrage. Wenn jemand dieses Token stiehlt, kann er:

• Ihre Conversation History einsehen
• In Ihrem Namen Anfragen stellen
• Bei Business-Accounts: Auf Unternehmensdaten zugreifen

Wo werden diese Tokens gespeichert?

• In Ihrem Browser (Cookies, LocalStorage)
• In einer Datenbank auf Server-Seite
• In einem Redis-Cache für schnellen Zugriff

Jede dieser Speicherorte kann kompromittiert werden.

Das Logging-Problem

Fast jedes KI-System protokolliert:

• Wer hat wann was gefragt?
• Welche Antworten wurden gegeben?
• Wie lange hat die Verarbeitung gedauert?
• Welche Fehler sind aufgetreten?

Diese Logs sind wertvoll für Debugging und Optimierung. Aber sie enthalten auch:

• Möglicherweise sensible Informationen aus Ihren Prompts
• Unternehmens-interna
• Personenbezogene Daten

Die Frage: Wer hat Zugriff auf diese Logs? Wie lange werden sie gespeichert? Wo liegen sie?

⚠️ Realer Fall: Als die New York Times OpenAI verklagte, ordnete ein Richter an, dass OpenAI alle Chat-Verläufe aufbewahren muss, um Beweise nicht zu vernichten. Das bedeutet: Daten, die vielleicht gelöscht worden wären, bleiben nun langfristig gespeichert.

Was Sie konkret tun können

Nach all der Theorie: die praktischen Schutzmaßnahmen.

1. Vendor Assessment: Kennen Sie Ihre Lieferanten

Bevor Sie ein KI-System produktiv einsetzen, stellen Sie diese Fragen:

Infrastruktur:

• Wo werden Daten physisch gespeichert?
• Welche Sub-Contractor sind involviert? (Oft nutzt ein Anbieter wiederum Cloud-Services)
• Welche Verschlüsselungsmethoden werden verwendet?

Compliance:

• Ist der Anbieter DSGVO-konform?
• Gibt es Standard Contractual Clauses (SCCs)?
• Wie verhält es sich mit dem Cloud Act?
• Gibt es Zertifizierungen (ISO 27001, SOC 2, etc.)?

Datenverarbeitung:

• Werden Ihre Eingaben zum Training verwendet? (Opt-out möglich?)
• Wie lange werden Logs gespeichert?
• Wer hat Zugriff auf Ihre Daten?

2. Netzwerk-Segmentierung

Wenn Sie KI-Systeme selbst hosten oder on-premise betreiben:

• Isolieren Sie KI-Workloads in separate Netzwerk-Segmente
• Beschränken Sie Zugriffe auf das absolute Minimum (Least Privilege)
• Monitoren Sie Netzwerk-Traffic zwischen Komponenten auf Anomalien
• Nutzen Sie Service Meshes (z.B. Istio) für verschlüsselte interne Kommunikation

3. API-Security

Wenn Sie KI-APIs nutzen oder bereitstellen:

Rate Limiting:

• Begrenzen Sie Anfragen pro User/API-Key
• Schützt vor Missbrauch und hilft, Anomalien zu erkennen

API-Key Rotation:

• Wechseln Sie Keys regelmäßig
• Wenn ein Key kompromittiert wird, ist der Schaden zeitlich begrenzt

Monitoring:

• Überwachen Sie ungewöhnliche Nutzungsmuster
• Alerts bei plötzlich vielen Anfragen oder ungewöhnlichen Uhrzeiten

Keine Secrets im Code:

• API-Keys gehören nicht in Git-Repositories
• Nutzen Sie Secret Management Tools (HashiCorp Vault, AWS Secrets Manager)

4. Data Loss Prevention (DLP)

Verhindern Sie, dass sensible Daten überhaupt an KI-Systeme gelangen:

Input-Filtering:

• Scannen Sie Anfragen auf Kreditkartennummern, Sozialversicherungsnummern, etc.
• Blocken Sie oder anonymisieren Sie diese automatisch

Output-Scanning:

• Prüfen Sie KI-Antworten auf ungewollte Datenlecks
• Besonders wichtig bei RAG-Systemen (Retrieval Augmented Generation)

User Education:

• Schulen Sie Mitarbeiter, was sie NICHT in öffentliche KI-Tools eingeben sollten
• Stellen Sie sichere Alternativen bereit (z.B. selbst gehostete Lösungen für sensible Daten)

5. Für sensible Anwendungen: On-Premise oder Private Cloud

Wenn die Risiken zu hoch sind:

Self-Hosting:

• Nutzen Sie Open-Source-Modelle (LLaMA, Mistral, etc.)
• Betreiben Sie diese in Ihrer eigenen Infrastruktur
• Volle Kontrolle, aber auch volle Verantwortung

Private Deployments:

• Viele Anbieter bieten „Bring Your Own Cloud“-Optionen
• Das Modell läuft in Ihrer AWS/Azure-Umgebung
• Sie kontrollieren Netzwerk, Zugriffe und Logs

Hybrid-Ansätze:

• Unkritische Workflows über öffentliche APIs
• Sensible Daten nur über private Instanzen

Fazit: Supply Chain Security ist kein Luxus

Die Supply Chain ist die vergessene Dimension der KI-Sicherheit. Während alle über Prompt Injection und Deepfakes reden, lauern die vielleicht größten Risiken in der Infrastruktur – unsichtbar, komplex und oft unterschätzt.

Die wichtigsten Erkenntnisse:

• KI ist ein System aus vielen Komponenten – jede ein potenzielles Risiko
• Serverstandorte sind oft irrelevant – der Cloud Act reicht weiter als physische Grenzen
• Man-in-the-Middle ist real – komplexe Netzwerke bieten Angriffsflächen
• Logging und Sessions enthalten sensible Daten und müssen geschützt werden
• Vendor Assessment ist Pflicht – kennen Sie Ihre Supply Chain

Im letzten Teil dieser Serie kommen alle Fäden zusammen: Best Practices für sichere KI-Implementation, systematische Risiken beim Training und eine praktische Checkliste für Unternehmen. Von der Strategie zur Umsetzung.

🔗 Die komplette KI-Sicherheitsserie:

Teil 1: KI-Sicherheit Überblick: Die 4 kritischen Risikobereiche

Teil 2: Adversarial Attacks: Wie Angreifer KI-Modelle austricksen

Teil 3: KI-Missbrauch: Von Deepfakes bis Social Engineering

Teil 4: Supply Chain Security (dieser Artikel)

Teil 5: Best Practices: So sichern Sie KI-Systeme im Unternehmen

Ihre Infrastruktur ist gefragt!

Haben Sie bereits ein Vendor Assessment für Ihre KI-Anbieter durchgeführt? Setzen Sie auf US-amerikanische Dienste oder europäische Alternativen? Wie gehen Sie mit dem Cloud Act um? Teilen Sie Ihre Strategie in den Kommentaren!

📧 Bleiben Sie auf dem Laufenden: Folgen Sie mir auf LinkedIn, um keine Folge dieser KI-Sicherheitsserie zu verpassen und weitere Insights zu erhalten.

🔗 Weiterführend: Erfahren Sie mehr über Power BI REST API Sicherheit und sichere Automatisierung in kritischen Systemen.

🌐 Quellen:

• LLMRisks Archive | OWASP Gen AI Security Project
• Sicherer Serverstandort in Deutschland? Datensouveränität in der Cloud: Warum der Serverstandort Deutschland nicht ausreicht! | xpert.digital
• EU-Boundary nichts wert? Microsoft kann US-Zugriff auf EU-Cloud nicht verhindern | Mauß Datenschutz
• Gerichtliche Anordnung für OpenAI – Datenschutzbedenken – Der Datenschutzbeauftragte | Ruhr-Universität Bochum
• How we’re responding to The New York Times’ data demands in order to protect user privacy | OpenAI
• Supply Chain Attacks: vergiftete KI | it-sa
• BSI-Chefin: Cyberschutz-Verpflichtung für Firmen ab 2026 | heise online