KI absichern und sich gegen KI verteidigen sind zwei völlig verschiedene Probleme

Der Begriff "KI-Sicherheit" wird für zwei Probleme verwendet, die nahezu nichts gemeinsam haben. Das eine ist der Schutz von Systemen, die ein Modell nutzen. Das andere ist die Verteidigung gegen Angreifer, die ein Modell als Werkzeug einsetzen. Die Bedrohungsakteure unterscheiden sich, die Schutzmaßnahmen unterscheiden sich, die Zuständigkeiten unterscheiden sich und zunehmend auch die Budgets. Teams, die beides in einen Topf werfen, kaufen die falschen Lösungen und wundern sich anschließend, warum die Investition keinen Schutz bietet.

Der Rest dieser Artikelserie baut auf genau dieser Unterscheidung auf. Daher lohnt es sich, die beiden Bereiche zunächst präzise voneinander abzugrenzen.

Das Problem

Ein Plattform-Team implementiert einen internen KI-Assistenten. Das System liest Ticket-Warteschlangen, durchsucht das interne Wiki und kann eigenständig Change Requests anlegen. Prompt folgt die berechtigte Frage: Ist das sicher? Die Einkaufsabteilung holt Angebote von drei Anbietern ein. Der erste vertreibt ein Gateway, das Prompts und Modell-Ausgaben inspiziert. Der zweite bietet E-Mail-Sicherheit, die KI-generierte Nachrichten filtert. Der dritte verkauft eine Governance-Plattform, die Modelle mit regulatorischen Vorgaben abgleicht. Alle drei nennen ihr Produkt "KI-Sicherheit", doch nur ein einziges Angebot hat überhaupt etwas mit dem neuen Assistenten zu tun.

Derselbe Trugschluss existiert in umgekehrter Richtung. Eine Finanzabteilung überweist 180,000 US-Dollar an einen Angreifer, der den Schreibstil eines Lieferanten so täuschend echt imitierte, dass niemand die Zahlungsaufforderung hinterfragte. Der anschließende Incident-Report fordert pauschal "Sicherheitskontrollen für KI". Die Kontrollen, die den Schaden verhindert hätten, wären eine saubere Zahlungsverifikation über einen zweiten Kanal und phishing-resistente Authentifizierung gewesen, Maßnahmen, die rein gar nichts mit den intern betriebenen Modellen des Unternehmens zu tun haben.

Warum es bei KI grundlegend anders ist

Die beiden Herausforderungen wirken nur deshalb verwandt, weil in beiden Fällen dieselben Buchstaben auftauchen. Zerlegt man sie in ihre Bestandteile, gibt es praktisch keine Schnittmenge mehr.

KI abzusichern ist ein Anwendungs- und Infrastrukturproblem. Der zu schützende Wert ist ein System, das Sie selbst entwickelt haben oder betreiben. Der Angreifer ist jeder, der dessen Eingaben erreichen kann. In der Praxis ist das zunehmend jeder, der Text vor das Modell bringen kann: Eine Webseite, die zusammengefasst wird; ein Dokument, das verarbeitet wird; die Rückgabe eines Tools, die das Modell einliest. Die OWASP Top 10 for LLM Applications 2026 bilden hierfür die maßgebliche Referenzliste, und ihre Einträge beschreiben Schwachstellen innerhalb Ihres eigenen Stacks: Prompt Injection unter LLM01, Offenlegung sensibler Informationen unter LLM02, übermäßige Handlungsbefugnis unter LLM03 und unbegrenzter Ressourcenverbrauch unter LLM06 [1]. Dies sind Design- und Rechteprobleme, die Sie lösen, indem Sie die Fähigkeiten und Befugnisse Ihres Systems kontrollieren.

KI als Waffe gegen das Unternehmen ist dagegen ein operatives Sicherheitsproblem. Die zu schützenden Werte sind Ihre Mitarbeiter und Ihr Geld. Der Angreifer agiert von außen, und das Modell gehört ihm. Nichts an Ihrer internen Software-Architektur ändert die Fähigkeiten des Angreifers. Was sich grundlegend gewandelt hat, ist die Ökonomie auf Angreiferseite: Das Erstellen überzeugender, individuell maßgeschneiderter Täuschungen verursacht heute praktisch keine nennenswerten Kosten mehr.

Das Internet Crime Complaint Center des FBI dokumentierte diesen Wandel für 2025 mit bemerkenswerter Klarheit. Die gemeldeten Phishing- und Spoofing-Fälle gingen leicht zurück, von 193,407 auf 191,561 Meldungen. Die gemeldeten Schadenssummen aus derselben Kategorie stiegen im gleichen Zeitraum von 70,013,036 US-Dollar auf 215,843,126 US-Dollar an [2]. Das entspricht rund einem Prozent weniger Beschwerden bei etwa dreimal so hohem finanziellem Gesamtschaden. Business Email Compromise verursachte laut demselben Bericht einen Schaden von 3,046,598,558 US-Dollar verteilt auf 24,768 Fälle, ein Durchschnitt von nahezu 123,000 US-Dollar pro Vorfall [2].

Das reine Nachrichtenvolumen hat als Risikomaßstab ausgedient. Wenn Ihr Sicherheitsreporting weiterhin nur abgewehrte E-Mails zählt, misst es den Faktor, der für Angreifer billiger geworden ist, und übersieht die Entwicklung, die sich dramatisch verschärft hat.

Beachten Sie, was das zweite Problem gerade nicht erfordert: Es ist kein einziges internes Modell von Ihnen beteiligt. Sie könnten sämtliche KI-Projekte stoppen, jeden Assistenten im Haus verbieten und Ihr Risiko bei Angriffen von außen bliebe absolut unverändert.

Was wirklich funktioniert

Hören Sie auf, das Thema als eine einzige Budgetposition zu behandeln, und weisen Sie jeden Bereich dem Team zu, das operativ darauf reagieren kann.

Beim Absichern von KI greifen bewährte Kontrollmechanismen angewandt auf eine neue Komponente: Begrenzen Sie die Berechtigungen, die Werkzeuge des Modells besitzen; isolieren Sie die Umgebungen, in denen Inferenzen laufen; setzen Sie Quotas für den Ressourcenverbrauch und führen Sie ein lückenloses Audit-Protokoll aller Aktionen. Die meisten dieser Mechanismen sind deterministisch und auf Infrastrukturebene erzwingbar. Wenige Maßnahmen, wie das probabilistische Einstufen eines Prompts als bösartig, sind fehleranfällig und gehören hierarchisch hinter die deterministischen Barrieren.

Bei KI-gestützten Angriffen liegen die wirksamen Hebel bei Identitäten und Prozessen. Phishing-resistente Authentifizierung entzieht dem Angreifer das Passwort als Angriffsziel. Eine Out-of-Band-Verifikation von Zahlungsfreigaben und Kontodaten entzieht dem Betrug das Geld als leichtes Ziel. Beide Maßnahmen sind deterministisch und greifen völlig unabhängig davon, wie geschliffen die Texte des Angreifers formuliert sind. Erkennungssysteme, die eingehende E-Mails auf manipulative Absichten oder Stilabweichungen prüfen, sind eine sinnvolle Ergänzung, gehören jedoch an die letzte Stelle der Kette: Sie sind die einzige Schutzschicht, die mit jeder Verbesserung der Angreifermodelle unbemerkt an Wirksamkeit verliert. Beide Anforderungslisten teilen so gut wie keine gemeinsamen Maßnahmen, weshalb sie zwingend getrennte Verantwortliche benötigen.

Die Zuständigkeit folgt derselben Trennung, und diese schriftlich festzuhalten, ist meist die produktivste Arbeitsstunde des Monats. Systeme, die mit Modellen arbeiten, gehören in den Zuständigkeitsbereich von Application Security, während das Infrastruktur-Team definiert, wo sie ausgeführt werden und welche Netze sie erreichen dürfen. Eingehende KI-gestützte Angriffe fallen in die Verantwortung von Security Operations und des Teams, das die E-Mail-Systeme betreibt. Governance und Compliance begleiten beide Bereiche übergreifend, ohne die operative Führung zu übernehmen. In den meisten Organisationen sind dies unterschiedliche Teams mit separaten Werkzeugen und getrennten Rufbereitschaften. Genau deshalb führt eine pauschale Sammelposition "KI-Sicherheit" im Budget fast immer dazu, dass ein Teilbereich finanziert wird, während der andere leer ausgeht.

Es gibt eine reale Überschneidung: Beide Seiten werden durch die menschliche Gewohnheit verwundbar, Aktionen durchzuwinken, weil sie plausibel wirken und über einen vertrauten Kanal eintreffen. Beim ersten Problem ist es ein Werkzeugaufruf, den das Modell ausführen durfte. Beim zweiten Problem ist es eine Freigabe, um die ein Mitarbeiter gebeten wurde. Der wirksame Schutz besteht in beiden Fällen aus einem Verifikationsschritt, der nicht darauf vertraut, dass etwas verdächtig aussieht.

Was nicht funktioniert

Der erste Kardinalfehler besteht darin, ein Produkt zu kaufen und zu glauben, man habe beide Flanken abgedeckt. Ein Gateway, das Prompts eines Assistenten filtert, verhindert keinen Rechnungsbetrug durch kompromittierte Lieferanten. Und eine Mail-Filterung hilft nicht gegen einen Agenten mit Schreibrechten auf Produktionsdatenbanken. Beide Produkte mögen hervorragend sein, decken jedoch jeweils nur ein Teilproblem ab.

Ein weiterer Fehler ist es, Awareness-Schulungen als Allheilmittel gegen KI-gestützte Angriffe zu begreifen. Trainings, die Mitarbeitern beibringen, auf Grammatikfehler, generische Anreden und auffällige Links zu achten, vermitteln Kriterien, die moderne Sprachmodelle mühelos und kostenlos eliminieren. Eine Schulung beizubehalten, bloß weil sie als Maßnahme bereits existiert, macht sie nicht wirksam.

Ebenso scheitert der Versuch, beide Problemfelder der Abteilung zuzuschustern, die das letzte KI-Projekt betreut hat. Die Entwickler, die Modelle in Anwendungen integrieren, und die Sicherheitsanalysten, die den Mail-Eingang verteidigen, arbeiten in unterschiedlichen Welten mit eigenen Werkzeugen. Weist man beiden Problemen denselben Verantwortlichen zu, wird garantiert eine Hälfte vernachlässigt.

Auch das Warten darauf, dass Sicherheits-Frameworks irgendwann zu einem einheitlichen Standard verschmelzen, führt in eine Sackgasse. Sie werden nicht verschmelzen, weil sie grundverschiedene Sachverhalte abbilden. Der OWASP-Katalog systematisiert Risiken in selbst gebauten Systemen, während Bedrohungsanalysen zu KI-gestütztem Betrug beschreiben, was Angreifer Ihnen von außen antun. Beide Perspektiven sind nützlich, keine ersetzt die andere.

Wo Sie anfangen sollten

• Benennen Sie die Verantwortlichen für beide Bereiche schriftlich: Application Security und Infrastruktur für interne Systeme, die mit Modellen arbeiten; Security Operations für eingehende KI-unterstützte Angriffe. Lautet die Antwort für beide Rollen auf dieselbe Person, ist das bereits Ihr wichtigstes Prüfungsergebnis.
• Fragen Sie jeden Sicherheitsanbieter direkt, welchen der beiden Bereiche seine Lösung abdeckt. Seriöse Anbieter antworten präzise und unmittelbar. Weicht ein Verkaufsgespräch dieser Differenzierung aus, wissen Sie Bescheid.
• Überprüfen Sie Ihre Phishing-Kennzahlen. Wenn Ihre Berichte nur abgewehrte E-Mail-Mengen zählen, ergänzen Sie eine Metrik für den durchschnittlichen Schaden pro Vorfall. Die FBI-IC3-Diskrepanz [2] liefert das stichhaltige Argument dafür.
• Erfassen Sie detailliert, worauf Ihre internen Modelle zugreifen können; das ist wichtiger als das, was sie ausgeben. Zugangsdaten, ausgehende Netzwerkverbindungen und Schreibberechtigungen sind die Hebel, die die Infrastruktur tatsächlich kontrollieren kann, und genau diese sind selten sauber dokumentiert.
• Verifizieren Sie finanzielle Transaktionen über einen zweiten, unabhängigen Kanal, gesteuert über Prozesse, die nicht darauf angewiesen sind, dass ein Mitarbeiter eine sprachliche Anomalie bemerkt.

Die weiteren Beiträge dieser Serie folgen exakt dieser Zweiteilung. Einige Artikel widmen sich dem Schutz von Systemen, die Sie selbst entwickeln und betreiben; andere behandeln Bedrohungen, die in Ihrem Postfach landen. Zu wissen, welcher Kategorie ein Thema angehört und für welchen Bereich Sie über Budget verfügen, bildet das eigentliche Fundament erfolgreicher Sicherheitsarbeit.

Quellen

1. OWASP Top 10 for LLM Applications 2026, OWASP GenAI Security Project, veröffentlicht am 3. August 2026: https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/
2. 2025 Internet Crime Report, FBI Internet Crime Complaint Center: https://www.ic3.gov/AnnualReport/Reports/2025_IC3Report.pdf