Sichere KI-Agenten: Warum Standard-API-Integrationen ein Risiko sind

Die meisten Unternehmen bauen heute KI-Agenten, die auf den ersten Blick perfekt funktionieren. Doch unter der Oberfläche leckt es massiv an Daten. Der Grund: Viele setzen auf eine Architektur, die sensible Unternehmensdaten über unsichere Pfade nach außen trägt.

Als selbstständiger Systemarchitekt habe ich in den letzten drei Jahren für Unternehmen in San Francisco und der Bay Area gearbeitet. Mein Fokus liegt darauf, Datenflüsse zu analysieren, kritische Schwachstellen in der Architektur zu identifizieren und Kunden schonungslos auf Risiken hinzuweisen – selbst wenn die Wahrheit unangenehm ist.

Die harte Realität lautet: Die größte Sicherheitslücke in den meisten Unternehmens-IT-Stacks ist nicht SQL-Injection, schwache Verschlüsselung oder falsch konfigurierte IAM-Richtlinien. Es ist die Art und Weise, wie Unternehmen ihre internen KI-Agenten aufbauen.

Lassen Sie mich erklären, warum.

Die „Standard-Methode“ und ihre fatale Schwachstelle

Unternehmen sehnen sich nach einem internen KI-Assistenten. Die Idee klingt verlockend: Verbinden Sie Ihre Wissensdatenbank mit einem Orchestrierungs-Framework, vektorisieren Sie die Daten und ermöglichen Sie Mitarbeitenden einen natürlichen Dialog mit Systemen wie Jira, Confluence, CRM oder rechtlichen Dokumenten.

Typischerweise sieht die Umsetzung so aus:

• Auswahl eines Orchestrierungs-Frameworks (z. B. LangChain, LlamaIndex, AutoGen)
• Einrichtung einer Vektordatenbank (z. B. Pinecone, Weaviate, Chroma)
• Einspeisung interner Daten in den Vektor-Speicher
• Verbindung mit einer externen LLM-API (z. B. OpenAI, Anthropic, Cohere)
• Veröffentlichung des Agents

Funktionell mag das funktionieren – ich habe beeindruckende Demos gesehen. Doch aus Sicht der Datensicherheit und des globalen geistigen Eigentumsschutzes handelt es sich um eine tickende Zeitbombe. Und die meisten Entwicklungsteams realisieren das erst, wenn es zu spät ist.

Der RAG-Prozess: Wohin Ihre Daten tatsächlich fließen

Lassen Sie uns den vollständigen Datenfluss eines typischen Retrieval-Augmented-Generation(RAG)-Prozesses in einem Unternehmen nachverfolgen. Hier geht es um Details – denn genau dort verstecken sich die größten Risiken.

Schritt 1 – Mitarbeiteranfrage Ein Mitarbeitender stellt dem internen KI-Agenten die Frage: „Welche Alleinstellungsmerkmale präsentieren wir im laufenden Quartal den EMEA-Kunden?“

Schritt 2 – Abfrage interner Quellen Die Orchestrierungsschicht führt eine semantische Suche in der Vektordatenbank durch und holt die relevantesten Textabschnitte aus internen Dokumenten ab – etwa aus der Q3-Verkaufsstrategie, dem Preismodell, der Wettbewerbsanalyse oder den CRM-Deal-Notizen.

Schritt 3 – Prompt-Zusammensetzung Die Middleware erstellt einen neuen Prompt, der nun aus zwei Bestandteilen besteht: der ursprünglichen Frage des Mitarbeitenden plus den abgerufenen sensiblen Dokumentenfragmenten. Dieser kombinierte Payload liegt im Arbeitsspeicher des Orchestrierungsservers.

Schritt 4 – Externer API-Aufruf Der zusammengesetzte Prompt – also die Frage des Mitarbeitenden samt vertraulichen Unternehmensdaten – wird per HTTPS an einen externen LLM-Anbieter gesendet.

Haben Sie das erkannt? Sie haben gerade vertrauliche Unternehmensdaten über Ihre kontrollierte Sicherheitsgrenze hinaus transferiert. Das ist kein theoretisches Szenario, sondern Realität in vielen Unternehmen.

„Aber wir haben einen Enterprise-Vertrag!“

Diese Antwort höre ich regelmäßig. „Wir haben einen Enterprise-Vertrag unterzeichnet. Der Anbieter garantiert, dass unsere Daten nicht für das Training genutzt werden.“

Doch die Architektur ändert sich nicht durch vertragliche Zusagen. Hier sind die Fakten, die vertragliche Vereinbarungen nicht ausgleichen können:

• Ihre Daten durchqueren fremde Netzwerkinfrastrukturen. Selbst wenn der Anbieter Ihre Daten nicht für das Training verwendet, passieren sie Netzwerkbereiche, die Sie nicht kontrollieren. TLS-Verschlüsselung ist das absolute Minimum – aber keine Sicherheitsarchitektur.

• Sie vertrauen einem schwarzen Kasten. Sie haben keine Einblicke, wie der Anbieter Ihre Daten während der Inferenz verarbeitet – in Load Balancern, Logging-Pipelines, Caching-Schichten oder im Incident-Response-Prozess. Die Zusage „kein Training“ ist eine Trainingsrichtlinie, kein umfassender Schutz.

• Compliance-Rahmenwerke machen keine Ausnahmen. SOC 2 Type II, ISO 27001, HIPAA oder GDPR kennen keine Sonderregelung für „Enterprise-Verträge“. Sobald Ihre Daten das Unternehmen verlassen, ist das ein Compliance-Vorfall. Besonders in Branchen wie Gesundheitswesen, Finanzen oder Recht ist dies kein hypothetisches Risiko, sondern ein Audit-Fund.

• Geistiges Eigentum lässt sich nicht zurückholen. Handelsgeheimnisse, unveröffentlichte Produktroadmaps, Due-Diligence-Unterlagen oder proprietäre Preisgestaltung: Sobald solche Daten exfiltriert wurden, gibt es kein Zurück. Keine SLAs der Welt können das ungeschehen machen.

Die Angriffsflächen, die fast niemand bedenkt

Bei Architektur-Reviews konzentrieren sich Teams meist auf offensichtliche Bedrohungen wie SQL-Injection, Broken Authentication oder exponierte Geheimnisse in Umgebungsvariablen.

Doch fast niemand hat die KI-Datenpipeline selbst als Angriffsvektor modelliert. Hier sind die Risiken, die regelmäßig übersehen werden:

• Prompt Injection über manipulierte Dokumente

Wenn ein Angreifer Inhalte in einem Dokument platzieren kann, das später in Ihrer Vektordatenbank landet – etwa in einer manipulierten Confluence-Seite oder einem gefälschten Support-Ticket – kann er das Verhalten Ihres KI-Agenten über die abgerufenen Kontextdaten steuern. Besonders kritisch wird es, wenn externe APIs im Spiel sind, über die Sie keine Kontrolle über die Zwischenverarbeitung haben.

• LLM-Inferenz-Endpunkt als Daten-Exfiltrationsweg

Wenn Ihr Orchestrierungsserver kompromittiert wird, stellt jeder zusammengesetzte Prompt ein strukturiertes Paket sensibler Unternehmensdaten dar – perfekt für Angreifer vorbereitet und bereit zur Exfiltration.

• Latenz als Seitenkanal

Weniger offensichtlich, aber architektonisch relevant: Die variable Antwortzeit externer Inferenz-Endpunkte kann von sophistizierten Angreifern genutzt werden, um Systemaktivitäten zu inferieren. In hochsicheren Umgebungen spielt dies eine Rolle.

• Vorfälle beim Anbieter

2023 meldete OpenAI einen Bug, der bei einigen Nutzern Gesprächsverläufe und Zahlungsinformationen preisgab. Anbieter sind nicht immun gegen Vorfälle. Wenn Ihre proprietären Daten Teil ihrer Pipeline sind, werden deren Probleme zu Ihren Problemen.

So sollte eine sichere Architektur aussehen

Das Prinzip ist einfach: Der KI-Agent und die Daten, mit denen er arbeitet, müssen innerhalb derselben isolierten Sicherheitsgrenze betrieben werden.

Für Unternehmen mit strengen Compliance-Anforderungen oder sensiblen Daten bedeutet das konkret:

• Lokale Inferenz mit Open-Source-Modellen

Nutzen Sie schlankere, lokal laufende Sprachmodelle wie Llama 3, Mistral 7B oder kleinere Varianten von Mixtral. Diese Modelle können auf dedizierten, abgeschotteten Servern betrieben werden, die vollständig unter Ihrer Kontrolle stehen.

• Eingeschränkte Datenweitergabe

Vermeiden Sie es, vollständige Dokumenteninhalte an externe LLMs zu senden. Stattdessen können Sie:

• Nur Metadaten oder Zusammenfassungen der relevanten Abschnitte weitergeben
• Eine lokale „Miniatur-Vektordatenbank“ nutzen, die nur ausgewählte, bereinigte Inhalte enthält
• Die Antworten des Modells streng auf maximale Vertraulichkeit und minimale Datenweitergabe prüfen

• Isolierte Netzwerkzonen

Betreiben Sie Ihre KI-Pipeline in einer separaten, hochsicheren Netzwerkzone mit strenger Zugriffskontrolle. Nutzen Sie Mikrosegmentierung, um Bewegungen zwischen Systemen zu überwachen und zu beschränken.

• Richtlinienbasierte Datenfilterung

Implementieren Sie automatische Filter, die sensible Daten – etwa personenbezogene Informationen, Finanzkennzahlen oder geistiges Eigentum – aus den Prompts entfernen, bevor sie an das Modell gesendet werden.

• Regelmäßige Penetrationstests

Testen Sie Ihre KI-Pipeline gezielt auf Schwachstellen wie Prompt Injection, Datenlecks oder Missbrauchsszenarien. Tools wie LangSmith oder Promptfoo können dabei helfen.

Die Zukunft der Unternehmens-KI liegt nicht in der Nutzung externer LLMs, sondern in der intelligenten Kombination aus lokalen Modellen, streng kontrollierten Datenflüssen und kontinuierlicher Überwachung. Unternehmen, die diesen Weg gehen, schützen nicht nur ihre Daten, sondern auch ihr geistiges Eigentum – und vermeiden teure Compliance-Vorfälle.

Es ist Zeit, die Architektur Ihrer KI-Agenten zu hinterfragen – bevor es zu spät ist.