KI-Systeme sind heute in unternehmenskritische Entscheidungen eingebettet. Ihre Absicherung ist keine Option mehr — sie ist eine Frage von Haftung, regulatorischer Exposition und schlicht operativer Hygiene.
Die neue Angriffsfläche
Jedes KI-System, das Sie einsetzen, schafft eine Angriffsfläche, die nicht so aussieht wie jene, die Ihr Sicherheitsteam zu verteidigen gewohnt ist. Klassische Schwachstellen sind im Kern Defekte im Code: ein Buffer Overflow, eine fehlende Authentifizierungsprüfung, ein falsch konfigurierter Cloud-Bucket. Sie haben ein klares Vorher-Nachher, sie lassen sich deterministisch reproduzieren, und einmal gepatcht bleiben sie gepatcht. KI-spezifische Schwachstellen verhalten sich anders. Sie leben im statistischen Verhalten eines Modells, nicht in einer bestimmten Codezeile. Sie können subtil genug sein, dass das System weiterhin normal zu funktionieren scheint und überzeugende Outputs produziert, während es im Stillen seine eigene Policy verletzt. Und — vielleicht am wichtigsten — sie können tausende Entscheidungen beeinflussen, bevor jemand merkt, dass etwas nicht stimmt, denn der Output eines KI-Systems ist konstruktionsbedingt plausibel.
Drei Angriffsvektoren dominieren mittlerweile die praktische Bedrohungslandschaft. Sie sind nicht die einzigen, aber sie sind die, die den Großteil der gemeldeten Vorfälle erzeugen — öffentlich wie unter NDA. Sie tiefer als die Schlagzeilen zu verstehen, ist das Erste, was ein Sicherheitsteam Nützliches tun kann.
Prompt Injection
Ein Sprachmodell, das Inhalte Dritter verarbeitet — eine Webseite, eine Kunden-E-Mail, ein Dokument, eine Tool-Antwort — ist strukturell verwundbar gegenüber Anweisungen, die in diesen Inhalten eingebettet sind, weil das Modell keinen verlässlichen Weg hat, „Daten, die ich lesen sollte" von „Anweisungen, denen ich folgen sollte" zu unterscheiden. Ein vom Nutzer eingereichtes Dokument kann das Modell deshalb anweisen, seinen System-Prompt zu ignorieren, seinen Gesprächsverlauf preiszugeben oder angebundene Werkzeuge in einer Weise aufzurufen, die der Betreiber nie beabsichtigt hat. Das ist in wesentlichen Punkten das SQL-Injection der KI-Ära: eine Vermischung von Daten und Code an der Grenze eines Systems, das beides verarbeitet. Der Unterschied: Anders als SQL hat natürliche Sprache keinen Parser, der die beiden mechanisch trennen kann — weshalb robuste Verteidigung Monitoring und Isolation statt syntaktischer Filterung verlangt. Die meisten Organisationen, die heute LLM-Funktionen produktiv betreiben, haben für diesen Angriff überhaupt keine Erkennung im Einsatz.
Model Poisoning
Während Prompt Injection das laufende System angreift, greift Poisoning die Lieferkette an, die es produziert. Ein Angreifer, der die Daten beeinflussen kann, auf denen ein Modell trainiert wird — oder die Gewichte eines vortrainierten Modells, von dem aus Sie feinjustieren — kann Verhalten einpflanzen, das das resultierende System nur unter bestimmten Auslösebedingungen zeigt. Das vergiftete Modell besteht den Acceptance-Test, weil es sich auf praktisch jeder Eingabe, die den Tester:innen einfällt, korrekt verhält. Es sind die wenigen vom Angreifer gewählten Eingaben — oft mit einer harmlos wirkenden Phrase oder einem Merkmal — die das eingepflanzte Verhalten aktivieren. Die Verteidigung ist nicht signaturbasiert, weil es keine Signatur gibt; sie ist herkunftsbasiert: Sie müssen wissen, woher jede Komponente Ihrer Trainingspipeline stammt, und jede ungeprüfte Eingabe als verdächtig behandeln.
Datenexfiltration durch das Modell
Sprachmodelle, besonders wenn sie auf internen Korpora feinjustiert werden oder zur Inferenz mit sensiblem Kontext versorgt werden, lassen sich dazu bringen, Fragmente dieser Daten wörtlich oder in rekonstruierbarer Form wiederzugeben. Ein Support-Assistent, dem Zugriff auf die Kundendatenbank gegeben wurde, um Routinefragen zu beantworten, kann unter dem richtigen Prompt zum Werkzeug werden, mit dem diese Datenbank aufgezählt wird. Ein auf interner Dokumentation feinjustiertes Modell kann den Inhalt jener Dokumente an jeden offenbaren, der weiß, wie zu fragen ist. Ohne Monitoring der Modell-Outputs gegen Data-Loss-Muster werden Sie nicht erfahren, dass das geschieht — Sie werden die relevanten Daten in einem Forum oder im Pitch-Deck eines Wettbewerbers finden und im Nachhinein rekonstruieren, wie sie dort hingelangt sind.
Geschäftliche Auswirkungen
Wahrscheinlichkeit und Schadenshöhe dieser Fehlerbilder lassen sich bequem tabellarisch fassen, aber es lohnt sich, im Fließtext zu beschreiben, was jede Zeile tatsächlich darstellt. Bußgelder — unter dem AI Act, der DSGVO und einer wachsenden Zahl sektoraler Regime — sind nicht mehr die theoretische Obergrenze, als die sie in früheren Diskussionen über KI-Risiken behandelt wurden. Insbesondere der AI Act sieht Strafen von bis zu fünfunddreißig Millionen Euro oder sieben Prozent des weltweiten Jahresumsatzes vor und betrachtet, anders als viele Regulierungen, ausdrücklich die extraterritoriale Anwendung auf Systeme, deren Outputs innerhalb der Union genutzt werden. Die DSGVO gilt weiter für jedes KI-System, das personenbezogene Daten verarbeitet, und die Aufsichtsbehörden zeigen wachsende Bereitschaft, KI-spezifische Feststellungen zu treffen — etwa zu automatisierter Entscheidungsfindung, Rechtsgrundlagen für Trainingsdaten und Betroffenenrechten gegenüber Modellen.
Reputationsschäden sind schwerer zu modellieren, aber empirisch größer, als die meisten Organisationen erwarten. Ein einziges weithin geteiltes Beispiel eines Chatbots, der verzerrte, halluzinierte oder anstößige Outputs produziert, hat in dokumentierten Fällen messbare Kundenabwanderung verursacht und Entschuldigungszyklen auf Vorstandsebene erfordert, die wochenlang Führungszeit gekostet haben. Datenlecks über LLMs liegen in der unangenehmen Schnittmenge dieser beiden: Sie sind gleichzeitig regulatorisches, reputationsbezogenes und operatives Ereignis, oft zur selben Zeit. Und Betriebsstörungen durch Modellausfälle — ein Forecast-System, das stillschweigend falsch wird, eine Moderationspipeline, die aus dem Tritt gerät, ein automatisiertes Entscheidungssystem, das gültige Anfragen abzulehnen beginnt — produzieren Prozessausfälle, die doppelt schmerzhaft sind, weil das System ja eigentlich die Quelle der Effizienz sein sollte.
Was gute KI-Sicherheit auszeichnet
Sicherheit ist kein Produkt, das man installiert, sondern eine Praxis, die man aufbaut, und die Organisationen, die KI-Sicherheit 2026 gut machen, teilen vier Merkmale, die sich leichter beschreiben als imitieren lassen. Sie betreiben Threat-Modelling vor dem Deployment statt nach dem ersten Vorfall, kartieren Angriffspfade gegen ein ehrliches Verständnis der Datenflüsse und Vertrauensgrenzen ihres Systems und behandeln dieses Threat-Model als lebendes Dokument, das bei jeder materiellen Änderung erneuert wird. Sie investieren in Runtime-Monitoring, das Eingaben und Ausgaben des Modells betrachtet, nicht nur Infrastrukturmetriken — denn die folgenreichsten KI-Versagen sind auf Infrastrukturebene unsichtbar. Sie erhalten menschliche Aufsicht für Entscheidungen mit asymmetrischem Schadenspotenzial — Einstellung, Kredit, medizinische Triage, Content-Moderation in großem Maßstab — und dokumentieren, unter welchen Kriterien menschliche Prüfung verpflichtend statt fakultativ ist. Und sie bewerten ihre KI-Systeme in einer Frequenz neu, die der Veränderungsrate dieser Systeme entspricht — bei einem aktiv weiterentwickelten Produkt also eher vierteljährlich als jährlich.
Erste Schritte
Für eine Organisation, die neu in der KI-Sicherheit ist, ist der erste sinnvolle Schritt fast immer ein Inventar. Bis Sie wissen, welche KI-Systeme existieren, wo sie in Ihren Prozessen sitzen, welche Daten sie berühren und wer von ihren Outputs abhängt, lässt sich keine andere Sicherheitsinvestition sauber priorisieren. Das Inventar legt typischerweise mehr Systeme offen, als die zentrale Funktion vermutet hat, weil Kosten und Reibung beim Deployment von KI-Funktionen so weit gefallen sind, dass die klassische Governance noch nicht aufgeschlossen hat.
Der zweite Schritt ist Risikoklassifizierung, denn nicht jedes KI-System trägt dasselbe Risikoprofil — und alle gleich zu behandeln ist sowohl teuer als auch wirkungslos. Ein Hochrisiko-System unter dem AI Act mit materiellen Auswirkungen auf Personen verdient die volle Wucht von Governance, Monitoring und Dokumentation; ein internes Produktivitätstool mit niedrigem Risiko nicht — und es durch dieselben Kontrollen zu zwingen, produziert Overhead statt Sicherheit.
Der dritte Schritt ist die OWASP LLM Top 10 als Basislinie, nicht als vollständige Antwort. Sie wird nicht alles abfangen, aber sie repräsentiert einen echten Industriekonsens über die häufigsten LLM-spezifischen Schwachstellen, und eine Organisation, die glaubhaft sagen kann, jeden dieser Punkte adressiert zu haben, liegt deutlich über dem Median.
Nächste Schritte
GuCoIA bietet maßgeschneiderte KI-Sicherheitsbewertungen für Organisationen in jeder Phase der KI-Einführung an — von solchen, die ihr erstes Deployment planen, bis zu solchen, die bereits mehrere Dutzend Systeme produktiv betreiben und sie rückwirkend unter Governance bringen müssen.
Kontaktieren Sie uns, um Ihre Situation zu besprechen
Dieser Artikel dient ausschließlich zu Informationszwecken und stellt keine Rechtsberatung dar.