Warum 2026 das Jahr der KI-spezifischen Angriffe ist
Bis vor Kurzem waren die meisten Sicherheitsvorfälle rund um KI eher akademisch. Das hat sich gedreht. Sobald Unternehmen im DACH-Raum Chatbots, Copiloten und Agenten mit Zugriff auf echte Systeme ausrollen, entsteht eine neue Angriffsfläche, die klassische Firewalls und WAF-Regeln schlicht nicht sehen. Ein Sprachmodell unterscheidet nicht von sich aus zwischen einer legitimen Anweisung Ihres Entwicklers und einer bösartigen Anweisung, die in einem PDF, einer E-Mail oder einer Webseite versteckt ist.
Gleichzeitig zieht die Regulierung an. Die verbotenen Praktiken des EU AI Act gelten seit Februar 2025, die Pflichten für General-Purpose-KI seit August 2025, und die Hochrisiko-Anforderungen greifen ab August 2026. Parallel verlangt NIS2 von deutlich mehr Unternehmen ein belastbares Risikomanagement inklusive Lieferkette, und DORA bindet den Finanzsektor an strenge Vorgaben für ICT-Drittparteien. Wer KI in Produktion betreibt, muss Sicherheit, Nachvollziehbarkeit und Lieferketten-Kontrolle zusammendenken - nicht als drei getrennte Projekte.
Prompt Injection: die Schwachstelle Nummer eins
Prompt Injection steht nicht ohne Grund an der Spitze der OWASP-Liste für LLM-Anwendungen. Das Grundproblem: Modelle vermischen Instruktionen und Daten in einem einzigen Textstrom. Sobald Ihr Assistent externe Inhalte liest - eine Support-Mail, ein Dokument im RAG-Index, eine Produktbeschreibung - kann darin ein Befehl stecken, der das Modell umsteuert.
Zwei Varianten sind besonders relevant:
- ▸Direkte Injection: Der Nutzer schreibt Anweisungen, die Ihre Systemvorgaben aushebeln sollen ("Ignoriere alle vorherigen Regeln").
- ▸Indirekte Injection: Der Angreifer platziert die Anweisung in Daten, die das Modell später verarbeitet. Der eigentliche Nutzer ahnt nichts. Genau das wird gefährlich, wenn der Agent Werkzeuge bedienen darf - E-Mails senden, Datensätze ändern, Zahlungen anstoßen.
Die harte Wahrheit für 2026: Es gibt keinen einzelnen Prompt, der das Problem löst. Wirksam ist nur Verteidigung in der Tiefe - strikte Trennung von Instruktions- und Datenkanälen, minimale Werkzeugrechte, menschliche Freigabe bei riskanten Aktionen und eine unabhängige Prüfschicht, die Ein- und Ausgaben bewertet, bevor sie wirken.
Deepfakes: wenn Stimme und Gesicht kein Beweis mehr sind
Der zweite Trend trifft Prozesse, nicht Server. Synthetische Stimmen und Videos sind 2026 in Echtzeit und in überzeugender Qualität verfügbar. Der klassische CEO-Fraud bekommt damit ein neues Gesicht: Ein Angreifer klont die Stimme eines Vorstands aus einem Konferenzmitschnitt und weist die Buchhaltung per Anruf zur Eilüberweisung an. Bewerbungsgespräche, KYC-Verfahren und Support-Hotlines lassen sich mit synthetischen Identitäten unterwandern.
Technische Deepfake-Erkennung hilft, ist aber ein Wettrüsten. Nachhaltiger sind prozessuale Kontrollen, die nicht auf "Ich habe die Stimme erkannt" vertrauen: Vier-Augen-Prinzip für Zahlungen ab einer Schwelle, Rückruf über verifizierte Kanäle, Freigabe-Codewörter für Finanztransaktionen und eine Kultur, in der Nachfragen ausdrücklich erwünscht ist. Der EU AI Act verlangt zudem ab August 2026 die Kennzeichnung KI-generierter Inhalte - ein Baustein, aber kein Ersatz für interne Verifikation.
Model Supply-Chain: das Risiko, das Sie herunterladen
Jedes offene Modell, jedes Fine-Tuning-Dataset und jede KI-Abhängigkeit aus einem öffentlichen Hub ist Teil Ihrer Lieferkette - und damit NIS2- und DORA-relevant. Die Angriffsvektoren sind real:
- ▸Manipulierte Gewichte und Backdoors: Ein Modell verhält sich normal, bis ein Trigger eine versteckte Reaktion auslöst.
- ▸Unsichere Serialisierung: Ältere Modellformate können beim Laden Code ausführen. Bevorzugen Sie sichere Formate und laden Sie niemals ungeprüfte Artefakte in Produktion.
- ▸Data Poisoning: Vergiftete Trainings- oder RAG-Daten verschieben das Verhalten subtil, etwa um bestimmte Betrugsmuster durchzuwinken.
- ▸Typosquatting bei Paketen: Bösartige Bibliotheken mit Namen, die echten KI-Paketen ähneln.
Der Gegenmittel-Ansatz ist derselbe wie bei klassischer Software-Lieferkette, nur konsequenter: eine Stückliste für KI-Komponenten (AI-BOM), Herkunftsnachweise und Signaturprüfung für Modelle, Pinning fester Versionen, gescannte und selbst gehostete Artefakte statt Live-Downloads sowie ein Bewertungslauf, der ein Modell vor dem Rollout auf Sicherheit und Verhalten prüft.
Checkliste: KI-Funktionen absichern, bevor sie live gehen
Nutzen Sie diese Schritte als Freigabe-Gate für jedes KI-Feature:
- ▸Bedrohungen modellieren: Definieren Sie, welche Werkzeuge der Agent aufrufen darf und welchen Schaden der schlimmste Fall anrichtet.
- ▸Rechte minimieren: Jedes Werkzeug bekommt nur die minimal nötigen Berechtigungen; riskante Aktionen erfordern menschliche Freigabe.
- ▸Eingaben und Daten trennen: Behandeln Sie alle externen Inhalte als nicht vertrauenswürdig und markieren Sie sie klar gegenüber Ihren Systemvorgaben.
- ▸Aus- und Eingaben filtern: Eine unabhängige Prüfschicht bewertet Prompts und Antworten auf Injection, Datenabfluss und Policy-Verstöße.
- ▸Sensible Daten schützen: Kein Klartext-Geheimnis im Prompt, PII-Redaktion vor der Verarbeitung, EU-Datenresidenz sicherstellen.
- ▸Lieferkette prüfen: AI-BOM führen, Modelle signieren und versionieren, Abhängigkeiten scannen, sichere Ladeformate erzwingen.
- ▸Missbrauch begrenzen: Rate Limits, Anomalieerkennung und Kostenobergrenzen gegen automatisierte Angriffe und Denial-of-Wallet.
- ▸Alles protokollieren: Vollständige, manipulationssichere Logs über Prompts, Werkzeugaufrufe und Entscheidungen - Grundlage für Audit und Incident Response.
- ▸Rot testen: Regelmäßiges Red-Teaming mit gezielten Injection- und Jailbreak-Versuchen vor jedem größeren Release.
- ▸Konformität dokumentieren: EU AI Act, NIS2 und - im Finanzumfeld - DORA von Anfang an mitdenken, nicht nachträglich aufsetzen.
Wie TuniCyberLabs sichere KI-Systeme baut
Genau an dieser Schnittstelle - KI-Nutzen liefern, ohne neue Risiken zu öffnen - arbeitet TuniCyberLabs. Wir sind ein EU-verankertes Nearshore-Engineering-Team: Muttergesellschaft in Estland (Tallinn), Büro in Zypern (Limassol), Entwicklung in Tunesien (Sousse). Für DACH-Kunden heißt das dieselbe Zeitzone wie Mitteleuropa, Verträge und Datenschutz nach EU- und DSGVO-Standard über die estnische Gesellschaft, Kommunikation auf Deutsch, Englisch und Französisch - und Produktionsqualität zu Nearshore-Konditionen.
Unser Vorgehen ist bewusst schrittweise, weil Sicherheit nicht am Ende dazukommt:
- ▸Verstehen: Wir erfassen Ihre Use Cases, Datenflüsse und regulatorischen Pflichten und modellieren die konkrete KI-Bedrohungslage - nicht generisch, sondern für Ihr System.
- ▸Entwerfen: Wir konzipieren die Architektur mit sauberer Trennung von Instruktions- und Datenkanälen, minimalen Werkzeugrechten, Prüfschichten und einer nachvollziehbaren Lieferkette für Modelle und Daten.
- ▸Bauen und sicher deployen: Wir setzen produktionsreife Systeme um - mit AI-BOM, signierten Artefakten, EU-Datenresidenz, vollständigem Logging und Red-Teaming vor dem Go-live.
- ▸Betreiben und weiterentwickeln: Wir überwachen, patchen und passen Kontrollen an, wenn neue Angriffstechniken und Fristen - etwa die Hochrisiko-Pflichten des EU AI Act ab August 2026 - greifen.
Der Kern unserer Überzeugung für 2026: KI-Funktionen sind kein Add-on, das man aus einem Baukasten klickt, sondern sicherheitskritische Software. Custom Engineering bedeutet, dass Guardrails, Rechtekonzept und Nachweisbarkeit in Ihr System eingebaut sind - nicht als Kompromiss einer Standardplattform, deren Sicherheitsmodell Sie nicht kontrollieren. Wenn Sie eine KI-Funktion planen oder eine bestehende härten wollen, hilft Ihnen ein nearshore aufgestelltes, EU-konformes Team dabei, Innovation und Compliance in derselben Codebasis zu vereinen.