Cloud- oder On-Device-AI-Security: der Architekturvergleich

Was „cloud-basierte AI-Security" tatsächlich bedeutet

Wenn ein Anbieter „AI-Security" oder ein „AI-Gateway" verkauft, ist die Architektur fast immer dieselbe. Ihr Traffic zu api.openai.com wird zuerst in die Cloud des Anbieters geleitet. Dort wird der Prompt geparst, auf sensible Daten und Prompt Injection geprüft und dann entweder durchgelassen oder blockiert. Die Antwort von OpenAI nimmt denselben Weg zurück: über den Anbieter, dann zu Ihrem Nutzer.

Die Anbieter-Cloud muss den Prompt-Inhalt sehen, um ihn prüfen zu können. Das ist eine harte Anforderung der Architektur, keine optionale Einstellung. Wäre der Prompt gegenüber dem Anbieter verschlüsselt, könnte der Anbieter ihn nicht scannen. Also liegt der Prompt am Prüfpunkt im Klartext vor. Und damit liegt er in den Logs und im Speicher des Anbieters, mindestens für die Dauer des Requests und oft länger, zu forensischen Zwecken und für erneutes Training.

Das ist das Entwurfsmuster im cloud-basierten Segment des Marktes. Lakera, Prompt Security, Robust Intelligence und andere betreiben Varianten davon. Der Kompromiss ist nicht versteckt, er steht in den Architekturdiagrammen. Er wird im Einkauf nur nicht immer ausgesprochen.

Vier Kosten, die mit Cloud-Routing einhergehen

1. Eine zweite Kopie Ihrer Daten, an einem Ort, der Ihnen nicht gehört

Jeder Prompt existiert nun auf mindestens drei Systemen: dem Gerät der Nutzerin, beim LLM-Anbieter und beim Security-Anbieter. Zwei davon liegen außerhalb Ihres Perimeters. Wird der Security-Anbieter kompromittiert, ist jeder geprüfte Prompt Ihrer Organisation offengelegt. Die Vorfälle bei mehreren SaaS-Security-Anbietern im August 2025 haben das konkret gemacht: Kunden stellten fest, dass ausgerechnet die Firmen kompromittiert waren, die die Schlüssel zu ihrer Sicherheit hielten.

Ein häufiges Gegenargument lautet „der Anbieter ist SOC2-zertifiziert". SOC2 bescheinigt Kontrollen, keine Ergebnisse. Zwei SOC2-zertifizierte Security-Anbieter wurden 2025 kompromittiert. Zertifizierung ist notwendig, aber nicht hinreichend.

2. Latenz, die der Nutzer in Echtzeit bezahlt

Der zusätzliche Roundtrip in die Anbieter-Cloud kostet je nach Geografie typischerweise 30 bis 200 Millisekunden. Bei einer Chat-Interaktion ist das lästig. Bei einem interaktiven Coding-Tool wie Cursor, Copilot oder Continue entscheidet es über Akzeptanz oder stilles Abschalten. Engineering-Teams, die diese Latenzsteuer zahlen sollen, schalten das Sicherheitswerkzeug regelmäßig ab, eröffnen ein Ticket beim Security-Team und sind binnen einer Woche zurück bei der direkten Verbindung zum Anbieter.

3. Ein neuer Single Point of Failure

Cloud-geroutete AI-Security schafft eine harte Abhängigkeit. Ist der Anbieter down, ist AI down. Für eine Werkzeugkategorie, die in Engineering, Support, Vertrieb und Analyse zunehmend tragend wird, ist das ein ernstzunehmendes Risiko für die Geschäftskontinuität. Die übliche Abhilfe, das Gateway bei Nichterreichbarkeit zu umgehen, hebt den Sicherheitszweck auf.

4. DSGVO- und Betriebsrats-Reibung in der EU

Nutzerbezogenes Prompt-Logging bei einem US-Cloud-Anbieter bedeutet in jedem deutschen Unternehmen ein längeres Gespräch mit Datenschutzbeauftragtem und Betriebsrat. Das Gespräch ist führbar, aber Auftragsverarbeitungsvertrag, Transfer Impact Assessment, Löschgarantien und Auditrechte sind echte Einkaufsarbeit. Viele cloud-basierte Einführungen bleiben genau hier hängen. Die Verträge werden geschlossen und die Werkzeuge gekauft, aber der Rollout ins Engineering dauert neun Monate, weil die rechtliche Prüfung nicht fertig wird.

On-Device-AI-Security: die architektonische Alternative

Die andere Grundhaltung besteht darin, die gesamte Prüf-Pipeline auf dem Endpoint laufen zu lassen. Der Agent fängt die AI-Anfrage ab, bevor sie das Gerät verlässt, klassifiziert sie, wendet die Policy an und lässt sie durch, verändert sie oder blockiert sie. Der LLM-Anbieter ist die einzige externe Partei, die den Prompt je zu sehen bekommt.

Die Abwägungsmatrix dreht sich damit um:

Der ehrliche Preis von On-Device-Security ist ein anderer: Sie brauchen einen Agenten auf jedem Gerät, und das ist eine echte Entscheidung im Endpoint-Management. Aber das ist ein einmaliges Deployment-Problem, gelöst über MDM, und anders als beim Cloud-Routing bleibt es reversibel, wenn Sie den Anbieter wechseln.

Wann „wir sind cloud-only" kein Ausschlusskriterium ist, und wann doch

Es gibt reale Workloads, bei denen Cloud-Routing in Ordnung ist: reine Chatbot-Interaktionen, wenig sensible SaaS-Nutzung, Rechtsräume ohne strenge Anforderungen an die Datenlokalisierung. Dafür funktioniert die Architektur.

Die Ausschlusskriterien sind konkret:

• Air-gapped oder souveräne Deployments. Verteidigung, kritische Infrastruktur, Nachrichtendienste. Der Agent steht außerhalb des Netzes, es gibt keine Cloud, durch die geroutet werden könnte. On-Device ist die einzige Option.

• Daten mit gesetzlicher Lokalisierungspflicht. Gesundheitsdaten unter den nationalen Entsprechungen von HIPAA, bestimmte Finanzunterlagen, bestimmte anwaltliche Arbeitsergebnisse. Sie durch eine US-Anbieter-Cloud zu leiten, ist entweder untersagt oder erfordert mehr juristische Arbeit, als der Sicherheitsgewinn wert ist.

• Interaktive Echtzeit-Workflows. Coding-Assistenten, Vertriebswerkzeuge, die live Antworten entwerfen, Analysewerkzeuge auf vertraulichen Tabellen. Das Latenzbudget ist zu knapp für einen Cloud-Roundtrip.

• MCP und agentische Workflows. MCP-Traffic läuft zwischen lokalen Prozessen, noch vor jedem Netzwerk. Ein Cloud-Gateway sieht davon überhaupt nichts, egal wie gut seine Prüfung ist.

• Selbst gehostete lokale LLMs. Ein wachsender Teil der Unternehmens-AI läuft lokal: Ollama, llama.cpp, On-Prem-Deployments. Ein Cloud-Gateway hat da nichts zu prüfen. On-Device sieht das vollständige Bild.

Trifft eines davon zu, ist Cloud-Routing nicht bloß die schlechtere Wahl. Es ist strukturell unzureichend.

Was Sie Anbieter im Einkauf fragen sollten

Fünf Fragen, die die architektonischen Unterschiede schnell sichtbar machen:

• Wo werden Prompt-Inhalte geprüft, und auf wessen Infrastruktur? „Auf dem Endpoint" und „in unserer Cloud" sind die beiden gültigen Antworten. Hybride Behauptungen bedeuten meist Cloud mit dünnem Client.

• Was passiert mit meinen Prompts, wenn Ihr Dienst ausfällt? Die ehrliche Antwort lautet entweder „Ihre AI funktioniert nicht mehr" oder „das Gateway fällt offen und Sie haben während des Ausfalls keine Sicherheit". Beides ist in Ordnung, solange man es vorher weiß.

• Kann das System Tool-Calls von MCP-Servern prüfen? Wenn der Anbieter nicht weiß, was MCP ist, oder es als „außerhalb des Umfangs" bezeichnet, haben Sie bereits etwas Wichtiges über seine Roadmap gelernt.

• Kann das System ein selbst gehostetes lokales LLM prüfen? Cloud-Gateways können das nicht, On-Device-Werkzeuge schon. Ein nützlicher Filter.

• Welche Latenz pro Anfrage sagen Sie vertraglich zu? Die Zahl verrät die Architektur. Im Submillisekundenbereich heißt On-Device. 50 Millisekunden oder mehr heißt cloud-geroutet, unabhängig von den Marketingaussagen.

Wie Patronus Protect das On-Device-Muster umsetzt

Patronus ist eine AI-Firewall, die auf dem Endpoint läuft.

Die Pipeline ist lokal: abfangen, lokal analysieren, Policy durchsetzen.

AI-Traffic wird in einstelligen Millisekunden identifiziert.

Die Prüfung umfasst App-Traffic, Browser-Sitzungen, IDE-Plugins, MCP-Server und Tool-Calls innerhalb von Anfragen.

PII wird lokal geschwärzt. Policies greifen, bevor die Anfrage das Gerät verlässt.

Prompt-Inhalte werden zu keinem Zeitpunkt in eine Anbieter-Cloud geleitet. Die Compliance-Metadaten, die das Gerät verlassen, sind minimal, strukturiert und für bestehende SIEMs exportierbar (Splunk, Elastic, Datadog).

Diese architektonische Festlegung ist wichtig, weil sie bestimmt, was überhaupt möglich ist. Ein cloud-geroutetes Produkt kann nicht air-gapped werden, ohne neu gebaut zu werden. Ein On-Device-Produkt kann Cloud-Funktionen ergänzen, etwa Dashboards oder Flottenverwaltung, ohne den Datenpfad aufzugeben.

Häufige Fragen

Ist On-Device-AI-Security weniger wirksam als cloud-basierte? Die Erkennungsqualität hängt von den eingesetzten Modellen ab, nicht davon, wo sie laufen. On-Device-Deployments mit modernen Klassifikatoren (BERT, LightGBM-Varianten, kleine feingetunte LLMs) erreichen dieselbe Erkennungsleistung wie cloud-basierte Systeme, für die Bedrohungskategorien, auf die es ankommt: Prompt Injection, PII, Jailbreak-Versuche, Richtlinienverstöße.

Verliere ich mit On-Device die Sichtbarkeit über meine Flotte? Nein, aber der Datenfluss ist ein anderer. Jeder Agent führt ein lokales Audit-Log. Compliance-Metadaten wie Ereigniskategorien, Zählungen und Policy-Entscheidungen fließen auf Wunsch in ein zentrales Dashboard. Prompt-Inhalte bleiben lokal. Das Compliance-Team bekommt dieselbe Antwort auf die Frage „welche AI-Nutzung gab es letzte Woche", ohne dass der Prompt-Korpus die Endpoints verlässt.

Und der Agent selbst, telefoniert der nach Hause? Gut gebaute On-Device-Werkzeuge tun das nur für Lizenzierung, Modell-Updates und den genannten Metadaten-Strom. Die Datenebene, also Prompts, Antworten, Tool-Calls und MCP-Traffic, bleibt lokal.

Ist cloud-basierte AI-Security jemals die richtige Wahl? Ja, wenn der Workload wirklich cloud-only ist, die Daten wirklich wenig sensibel sind und das Team weder air-gapped arbeitet noch lokale LLMs einsetzt. Die Architektur ist in Ordnung, solange ihre Annahmen zutreffen. Das Problem ist, sie für Workloads zu kaufen, bei denen sie nicht zutreffen.

Wie verhält sich das zu meinem bestehenden CASB und DLP? Die On-Device-AI-Firewall ergänzt beide, sie ersetzt sie nicht. CASB sieht die SaaS-Landschaft. DLP sieht strukturierte Datenbewegungen. Die AI-Firewall sieht AI-spezifischen Traffic in einer Granularität, die den beiden entgeht. In der Praxis existieren alle drei nebeneinander.