KI-Sicherheit ist 2026 keine Spezialfrage mehr für Forschungslabore. Künstliche Intelligenz ist operative Infrastruktur: Unternehmen automatisieren Prozesse, integrieren Agenten in produktive Systeme und lassen Modelle Daten interpretieren, Entscheidungen vorbereiten oder Code ausführen. Damit entsteht eine Risikolandschaft, die klassische Cybersecurity erweitert, aber nicht ersetzt.
Der International AI Safety Report 2026 unter Leitung von Yoshua Bengio beschreibt diese Lage nüchtern: Die Fähigkeiten der Systeme steigen, die Einsatzbreite wächst, und die Sicherheitspraktiken halten nicht überall Schritt. Für Unternehmen ist daraus keine Panik abzuleiten. Wohl aber eine klare Pflicht: KI-Systeme brauchen eigene Bedrohungsmodelle, eigene Kontrollpunkte und eine Governance, die technische, rechtliche und organisatorische Risiken zusammenführt.
Die drei Risikokategorien für KI-Sicherheit
Der Report ordnet KI-Risiken in drei Gruppen, die in der Praxis oft ineinandergreifen.
Missbräuchliche Nutzung umfasst den bewussten Einsatz von KI für schädliche Zwecke: synthetische Desinformation, Phishing, Fraud, Code-Varianten, Zielauswahl und Unterstützung bei einzelnen Angriffsschritten. Im Cyberalltag ist das weniger Science-Fiction als Beschleuniger. LLMs machen schlechte Akteure nicht automatisch genial, aber sie senken Einstiegshürden und erhöhen die Skalierung. Was davon bereits real ist und was noch AI-Theater bleibt, ordnet der Deep Dive zu KI in Malware und LLM-gestützten Cyberangriffen ein.
Fehlfunktionen betreffen die Unzuverlässigkeit der Systeme selbst. Modelle erzeugen plausible, aber falsche Aussagen, reagieren empfindlich auf kleine Eingabeänderungen oder verhalten sich in ungewohnten Situationen anders als erwartet. Ein konkreter Teil dieser Klasse sind KI-Halluzinationen: falsche oder unbelegte Aussagen mit hoher sprachlicher Autorität. In regulierten oder sicherheitskritischen Anwendungen sind sie ein Betriebsrisiko.
Systemische Risiken sind schwerer zu messen: Abhängigkeit von wenigen Cloud- und Modellanbietern, Konzentration von KI-Fähigkeiten, Kontrollverlust durch tiefe Delegation, Arbeitsmarktverschiebungen und geopolitische Effekte. Diese Risiken zeigen sich nicht zwingend in einem einzelnen Incident. Sie entstehen, wenn viele Organisationen ähnliche technische Abhängigkeiten aufbauen und ihre Kontrollfähigkeit dabei überschätzen.
Der gemeinsame Nenner: KI-Sicherheit lässt sich nicht mit einem einzelnen Modelltest erledigen. Es braucht technische Kontrollen, Prozessgrenzen, Auditierbarkeit und Verantwortlichkeit.
Agentic AI: Die neue Angriffsfläche handelt selbst
Agentische Systeme verändern die Bedrohungslage, weil sie handeln. Ein Agent liest Dateien, ruft Tools auf, schreibt Daten, startet Workflows oder verändert Code. Damit wächst die Angriffsfläche proportional zu den Rechten, die er erhält.
Prompt Injection ist in diesem Kontext ein Architekturproblem. Wenn ein Agent externe Inhalte liest und gleichzeitig Tools nutzen darf, kann eine eingeschleuste Instruktion reale Aktionen auslösen. Klassische LLM-Guardrails reichen dafür nicht. Sie können Verhalten dämpfen, aber sie ersetzen keine Rechtebegrenzung, keine Sandbox und keinen unabhängigen Verifikationsschritt. Die Analyse zu fragilen LLM-Guardrails zeigt, warum genau diese Schutzschicht überschätzt wird.
Besonders riskant sind Tool- und Protokollschichten. MCP-Server, Browser-Agenten, Code-Ausführung, Dateizugriff, RAG-Systeme und interne APIs schaffen neue Übergänge zwischen Text und Handlung. Jeder Übergang braucht ein eigenes Sicherheitsmodell: Welche Inhalte gelten als Daten, welche als Instruktion? Welche Tools darf der Agent in welchem Kontext aufrufen? Welche Aktionen brauchen Bestätigung? Welche Logs beweisen später, was passiert ist?
Die wichtigste Praxisregel lautet: Agentenrechte müssen enger sein als Benutzerrechte. Ein Mensch darf vielleicht ein Repository ändern, Kundendaten lesen oder Tickets schliessen. Daraus folgt nicht, dass ein Agent dieselben Rechte ohne Laufzeitgrenzen bekommen sollte. Agenten brauchen Least Privilege, explizite Tool-Scopes und klare Abbruchbedingungen.
Die KI-Supply-Chain bleibt fragil
Wer ein KI-Modell einsetzt, übernimmt eine Supply-Chain. Dazu gehören Trainingsdaten, Modellgewichte, Fine-Tunes, Quantisierungen, Container, Dependencies, Prompt-Templates, RAG-Indizes und Serving-Frameworks. In vielen Organisationen wird diese Kette schlechter dokumentiert als klassische Software.
Daten-Poisoning ist ein naheliegendes Risiko: Manipulierte Trainings- oder RAG-Daten können Modellverhalten in bestimmten Situationen verschieben. Das muss nicht spektakulär sein. Schon ein falsch priorisiertes internes Dokument kann dazu führen, dass ein RAG-System eine veraltete Richtlinie als aktuelle Wahrheit behandelt.
Modell-Provenance ist der zweite Punkt. Woher stammt ein Modell? Welche Lizenz gilt? Welche Sicherheitsannahmen gelten für den Checkpoint? Wurde das Artefakt verändert? Gibt es eine dokumentierte Freigabe? Bei offenen Modellen, quantisierten Varianten und Community-Releases ist diese Kette oft schwer nachvollziehbar.
Ausführbare Modellartefakte und unsichere Serialisierungsformate bleiben ein klassischer Supply-Chain-Vektor. Wer beliebige Modellpakete lädt, lädt neben Gewichten potenziell Code und Dependencies. Für Security-Teams ist das keine neue Welt. Es ist dieselbe Supply-Chain-Logik, nur mit neuen Artefakten.
Der WEF Global Cybersecurity Outlook 2026 betont zusätzlich Konzentrations- und Abhängigkeitsrisiken. Unternehmen, die KI-Infrastruktur vollständig an einen Cloud-Stack, ein Modell oder einen Anbieter binden, gewinnen Geschwindigkeit und verlieren Ausweichfähigkeit. Aus Security-Sicht ist das ein Architekturthema, kein Einkaufsthema.
Signal der Woche abonnieren
Eine Nachricht. Eine Analyse. Jeden Freitag im Newsletter.
Kostenlos als Member. Gratis abonnieren
Geopolitik und Cyber-Inequity
KI verändert Unternehmensprozesse und staatliche Machtprojektion. Nachrichtendienstliche Analyse, Informationsoperationen, Exploit-Entwicklung, Zielauswahl und militärische Entscheidungszyklen werden durch KI beschleunigt. Für Unternehmen in kritischen Sektoren verschwimmt damit die Grenze zwischen gewöhnlicher Cyberkriminalität und staatlich gestützter Aktivität weiter.
Ein zweiter Effekt betrifft Cyber-Inequity: Die Schere zwischen gut geschützten Grossunternehmen und kleineren Organisationen wächst. Grosse Unternehmen bauen AI-Security-Teams, modellieren Bedrohungen und kaufen spezialisierte Tools. KMU übernehmen dieselben KI-Funktionen oft über SaaS-Produkte, ohne vergleichbare Sicherheitsressourcen. In der DACH-Region ist das besonders relevant, weil der Mittelstand wirtschaftlich zentral ist und gleichzeitig selten eigene KI-Security-Teams betreibt.
Das Risiko liegt weniger darin, dass jedes kleinere Unternehmen sofort Ziel eines hochentwickelten KI-Angriffs wird. Das Risiko liegt in der Asymmetrie: Angreifer können Automatisierung skalieren, während Verteidiger ihre Sicherheitskompetenz langsamer aufbauen. Diese Lücke wird durch bessere Sicherheitsprozesse geschlossen.
Was Unternehmen für KI-Sicherheit konkret tun können
Der erste Schritt ist ein eigenes KI-Bedrohungsmodell. Welche KI-Systeme sind produktiv? Welche Daten sehen sie? Welche Tools dürfen sie aufrufen? Welche Entscheidungen beeinflussen sie? Welche Logs existieren? Ohne diese Inventur bleibt KI-Sicherheit abstrakt.
Zu dieser Inventur gehört eine unbequeme Kategorie: informelle Nutzung. Viele Risiken entstehen in Schattenprozessen. Mitarbeitende laden Dokumente in externe Tools, Teams bauen kleine Automationen ohne Security-Review, Fachbereiche verbinden SaaS-Produkte mit internen Daten. Eine KI-Sicherheitsstrategie muss diese Realität aufnehmen, statt nur die zentral beschafften Plattformen zu prüfen.
Der zweite Schritt ist Defense-in-Depth für Agentensysteme. Dazu gehören Sandboxing, minimale Rechte, getrennte Ausführungsumgebungen, Netzwerkgrenzen, Secret-Handling und Monitoring auf ungewöhnliche Tool-Nutzung. Für Agenten, die Code ausführen, ist Isolation besonders wichtig. Der Artikel zu sicherer Code-Ausführung für KI-Agenten erklärt, warum eine Sandbox eine notwendige Schutzschicht ist, aber allein nicht genügt.
Der dritte Schritt ist Provenance-Kontrolle. Modelle, Datensätze, Fine-Tunes und RAG-Quellen brauchen Freigabeprozesse. Unternehmen sollten wissen, welche Modellversion produktiv läuft, welche Lizenz gilt, welche Datenquellen angeschlossen sind und wie ein Modellwechsel geprüft wird. Das klingt nach Bürokratie, ist aber normale Software-Governance mit KI-Artefakten.
Der vierte Schritt ist Evaluation mit Fehlermodi. Agenten sollten nicht nur auf Erfolgsscores geprüft werden. Es muss sichtbar werden, ob sie bei Planung, Tool-Nutzung oder Verifikation scheitern. Die Analyse zu KI-Agenten im Unternehmenseinsatz zeigt, warum Failure-Mode-Diagnose für produktive Agenten wichtiger ist als ein einzelner Benchmark-Wert.
Der fünfte Schritt ist ein KI-spezifischer Incident-Prozess. Was passiert, wenn ein Agent Daten exfiltriert, falsche Aktionen auslöst, ein Modell unerwartet antwortet oder ein RAG-System veraltete Richtlinien ausgibt? Wer entscheidet über Abschaltung, Kommunikation und Ursachenanalyse? Ohne diese Rollen bleibt der erste Vorfall improvisiert.
Der sechste Schritt ist Schulung mit konkreten Fehlermodi. Allgemeine KI-Awareness reicht nicht. Teams müssen wissen, wie Prompt Injection aussieht, warum RAG-Quellen falsch sein können, weshalb Modellantworten nicht automatisch Evidenz sind und wie ein Agentenlauf dokumentiert werden muss. Gute Schulung spricht nicht über KI als abstrakte Magie, sondern über konkrete Entscheidungspunkte im eigenen Arbeitsprozess.
Der siebte Schritt ist regelmässiger Red-Team-Betrieb. KI-Systeme verändern sich mit Modellversionen, Prompts, angeschlossenen Datenquellen und Tool-Rechten. Ein einmaliger Test vor dem Launch reicht nicht aus. Sinnvoll sind kleine, wiederholbare Angriffsszenarien gegen Prompt Injection, Datenabfluss, falsche RAG-Quellen und Agentenrechte. So wird KI-Sicherheit zur Routine und nicht zum Sonderprojekt nach dem ersten Vorfall.
Wichtig ist dabei ein messbarer Rhythmus: Welche Tests laufen bei jedem Prompt- oder Modellwechsel, welche monatlich, und welche erst vor produktiven Releases?
Die grösste Schwachstelle in vielen KI-Sicherheitsstrategien ist nicht fehlendes Modellwissen. Es ist fehlende Zuständigkeit. Sobald ein Agent handeln darf, braucht er dieselbe Ernsthaftigkeit wie ein produktiver Service: Owner, Rechte, Logs, Runbook und Abschaltknopf.
Fazit: Adoption ohne Readiness bleibt riskant
KI-Sicherheit 2026 ist kein Randthema für Spezialisten. Sie betrifft jedes Unternehmen, das KI produktiv einsetzt. Die Bedrohungslandschaft hat sich erweitert: Angriffe werden automatisierter, Agenten handeln mit eigenen Rechten, Supply-Chains werden komplexer und geopolitische Risiken wirken direkt in Unternehmenssysteme hinein.
Die gute Nachricht: Viele Schutzmechanismen sind bekannt. Least Privilege, Sandboxing, Provenance, Monitoring, Incident Response und klare Ownership sind keine exotischen Konzepte. Sie müssen nur auf KI-Systeme angewandt werden, statt KI als Sonderfall ausserhalb normaler Sicherheitsarbeit zu behandeln.
Der zentrale Befund bleibt: Adoption und Readiness klaffen auseinander. Unternehmen, die diese Lücke früh schliessen, gewinnen nicht nur Sicherheit. Sie gewinnen Handlungsfähigkeit. Wer KI schneller einführt als er sie kontrollieren kann, baut technische Schulden mit Sicherheitsfolgen.
Was ist der wichtigste Unterschied zwischen klassischer Cybersecurity und KI-Sicherheit?
KI-Sicherheit ergänzt klassische Security um Modellverhalten, Datenkontext, Agentenrechte und Verifikation. Die alten Kontrollen bleiben nötig, reichen aber bei handelnden Agenten nicht aus.
Warum sind KI-Agenten besonders riskant?
Weil sie Tools nutzen, Dateien lesen, APIs aufrufen oder Code ausführen können. Damit wird aus einer falschen Antwort schnell eine falsche Aktion.
Was sollten Unternehmen zuerst tun?
Eine Inventur: Welche KI-Systeme laufen produktiv, welche Daten sehen sie, welche Tools dürfen sie nutzen, wer besitzt sie und welche Logs existieren? Ohne diese Übersicht bleibt KI-Sicherheit blind.
