Wenn die KI der falschen Stimme folgt: Prompt Injection im KMU

Stellen Sie sich vor, Sie lassen drei Lieferantenofferten von einer KI vergleichen. Preise, Leistungen, Ausschlüsse: genau die Vorarbeit, für die ein Assistent nützlich ist. In einer der Dateien steht allerdings nicht nur das Angebot. Sie enthält zusätzlich einen Text, der die KI auffordert, bestimmte Nachteile zu verschweigen und genau diesen Anbieter zu empfehlen.

Für einen Menschen wäre die Sache klar: Der Lieferant darf sein Angebot erklären, aber nicht unsere Bewertungsregeln festlegen. Für ein Sprachmodell ist diese Grenze schwieriger. Es verarbeitet Sprache als Arbeitsauftrag und als Material. Ein Angriff versucht, diese beiden Rollen zu vermischen.

Das Beispiel ist erfunden, der Mechanismus nicht. Er heisst Prompt Injection. Und er wird dort relevant, wo KI fremde Inhalte liest und daraus Empfehlungen oder Handlungen ableitet. Ein KMU braucht dafür kein eigenes KI-Forschungsteam. Es braucht eine klare Antwort darauf, wem die KI zuhören darf – und was sie anschliessend überhaupt tun kann.

Ein Prompt ist eine Eingabe an ein KI-Modell. Von Prompt Injection spricht man, wenn eine Eingabe das System in eine unerwünschte Richtung lenkt. Direkt geschieht das über eine Eingabe an den Assistenten. Indirekt kommt der Versuch über Inhalte herein, die der Assistent für einen legitimen Auftrag verarbeitet: etwa eine Webseite, eine E-Mail oder eine Datei.

OWASP beschreibt beide Varianten und nennt als mögliche Folgen manipulierte Antworten, die Offenlegung sensibler Informationen oder unerlaubte Funktionsaufrufe. Das tatsächliche Risiko hängt davon ab, wie die Anwendung gebaut ist und welche Möglichkeiten sie besitzt. Ein Modell bekommt durch einen manipulierten Satz nicht plötzlich magische Administratorrechte.

Eine KI kann sich auch ohne Angriff irren. Bei Prompt Injection wird dagegen versucht, den Arbeitsauftrag über eine fremde Quelle umzulenken. Beides kann schlecht enden, braucht aber teilweise andere Kontrollen.

OWASP: Prompt Injection und mögliche Auswirkungen

Eine E-Mail darf geschäftliche Informationen enthalten. Sie darf aber nicht automatisch entscheiden, dass der Assistent danach eine andere Datei suchen und weiterleiten soll. Eine Webseite kann eine Produktbeschreibung liefern. Sie ist deshalb noch keine berechtigte Instanz für neue Unternehmensregeln.

Fremde Inhalte sind Arbeitsmaterial. Sie sind keine Freigabe für neue Aufgaben, zusätzliche Zugriffe oder externe Aktionen.

Diese Unterscheidung gilt auch dann, wenn der Text freundlich formuliert ist, nach einer technischen Anweisung aussieht oder angeblich von der IT stammt. Die Herkunft und der ursprüngliche Auftrag zählen mehr als die überzeugende Formulierung.

Das britische NCSC warnt davor, Prompt Injection einfach wie klassische SQL Injection zu behandeln. Bei Sprachmodellen lässt sich die Trennung von Daten und Anweisungen nicht in derselben Weise voraussetzen. Unsere Konsequenz daraus: Planen Sie Schutz auch dafür, dass eine Erkennung einmal scheitert.

NCSC: Warum Prompt Injection keine gewöhnliche SQL Injection ist

Für einen ersten Check hilft eine Einteilung nach Wirkung. Die folgende Tabelle ist unsere praktische Orientierung, keine offizielle Produktklassifizierung und keine Zusage über ein bestimmtes System.

Darum reicht die Frage «Welches Modell nutzen wir?» nicht aus. Entscheidend ist auch: Welche Quellen liest es? Welche Daten sieht es? Welche Werkzeuge kann es aufrufen? Was passiert ohne menschliche Prüfung?

Ein Assistent, der einen Antwortentwurf erstellt, ist oft bereits sehr nützlich. Ihm zusätzlich das automatische Versenden zu erlauben, ist eine eigene Entscheidung mit einem anderen Risikoprofil. Diese Erweiterung sollte einen nachweisbaren Nutzen haben, statt aus Bequemlichkeit mitaktiviert zu werden.

Microsoft beschreibt Prompt Shields als Erkennung für manipulative Eingaben und Dokumentinhalte. Bei einer eigenen Anwendung auf Azure AI Content Safety liefert die API Erkennungsergebnisse; die Anwendung muss selbst festlegen, wie sie damit umgeht. Eine Erkennung ist also nicht automatisch eine wirksame Sperre.

Die am 19. Oktober 2026 geprüfte Dokumentation unterscheidet zwischen Schutzarten und Integrationswegen. Funktionen für Dokumentangriffe, Benutzerangriffe und unterstützte Agenten-Werkzeuge sind nicht einfach überall identisch aktiv. Einzelne Eingriffspunkte sind als Preview bezeichnet. Daraus lässt sich kein pauschaler Schutzstatus für jeden Copilot oder jede Eigenentwicklung ableiten.

Fragen Sie Ihren Anbieter konkret: Werden die tatsächlich verwendeten Dokumente und Werkzeugantworten geprüft? Wird ein Treffer blockiert oder nur protokolliert? Was passiert bei einem technischen Fehler? Und welche Sprache wurde getestet? Microsoft weist darauf hin, dass die Leistung der Erkennung je nach Sprache variieren kann.

Ein «Wir verwenden Azure» beantwortet diese Fragen nicht. Ebenso wenig beweist ein eingeschalteter Filter, dass das Modell die richtigen Fakten liefert. Erkennung manipulativer Anweisungen und fachliche Richtigkeit sind unterschiedliche Aufgaben.

Microsoft: Prompt Shields, Grenzen und Integrationsverhalten

Eine klare Systemanweisung kann helfen: Fremde Inhalte sollen als Daten behandelt werden, nicht als neue Befehle. Auch die getrennte Kennzeichnung von Auftrag und Quellen ist sinnvoll. OWASP empfiehlt jedoch mehrere Schutzschichten, darunter die Prüfung von Ausgaben und Werkzeugaufrufen. Ein einzelner Satz im Prompt ersetzt keine Berechtigungen.

Unsere Empfehlung: Beginnen Sie bei den Folgen. Ein Rechercheassistent braucht normalerweise keine Möglichkeit, Benutzerkonten zu verändern. Ein Offertenvergleich braucht keinen Zugriff auf die gesamte Personalablage. Ein Entwurf für eine Kundenantwort muss nicht eigenständig an beliebige Empfänger versendet werden können.

Diese Grenzen gehören in die Anwendung und ihre angeschlossenen Dienste. Wenn das Modell eine unerlaubte Aktion vorschlägt, sollte sie technisch scheitern oder eine echte Freigabe verlangen. Es genügt nicht, das Modell freundlich zu bitten, sich an eine Liste zu halten.

Microsoft empfiehlt ebenfalls einen mehrschichtigen Ansatz mit minimalen Rechten und menschlicher Prüfung riskanter Aktionen. Für uns ist das der pragmatische Kern: Nicht voraussetzen, dass jede Antwort sicher ist, sondern die möglichen Folgen eines Fehlers begrenzen.

OWASP: Schutzschichten und technische Prüfungen · Microsoft: Schutz vor indirekter Prompt Injection

Wenn vor jeder Kleinigkeit ein Bestätigungsfenster erscheint, klicken Menschen irgendwann routiniert weiter. Das ist keine gute Sicherheitskontrolle. Eine Freigabe sollte dort liegen, wo aus einem Vorschlag eine geschäftlich relevante Wirkung wird.

Vor dem Versand einer Nachricht wollen wir Empfänger, Betreff, Inhalt und Anhänge sehen. Vor einer Änderung den betroffenen Datensatz und den neuen Wert. Vor einer Freigabe den Empfängerkreis. Wenn diese Informationen fehlen, kann die Person die Entscheidung kaum sinnvoll prüfen.

Die Vorschau muss zur tatsächlich ausgeführten Aktion passen. Eine Anwendung sollte nicht nach der Zustimmung andere Anhänge wählen oder den Empfänger verändern können, ohne erneut zu fragen. Das ist eine Anforderung an die Umsetzung, nicht eine Fähigkeit, die jedes KI-Produkt automatisch mitbringt.

Bei höherem Risiko empfehlen wir getrennte Schritte: erst auswerten, dann einen kontrollierten Entwurf erzeugen, danach freigeben und ausführen. Im Betrieb ist ein nachvollziehbarer Prozess häufig wertvoller als eine beeindruckende Demonstration.

Wählen Sie eine einzige vorgesehene Anwendung, etwa die Zusammenfassung eingehender Lieferantenunterlagen. Erstellen Sie künstliche Dokumente und Testkonten ohne produktive Daten und ohne echte Versand- oder Änderungsrechte. Legen Sie vorab fest, was der Assistent tun soll und was ausserhalb seines Auftrags liegt.

Ein harmloser Test kann in einer Datei den Versuch enthalten, statt der verlangten Zusammenfassung eine sachfremde Werbeaussage auszugeben. Prüfen Sie, ob das System beim Auftrag bleibt. Testen Sie zusätzlich die technische Grenze: Ein vorgeschlagener nicht erlaubter Werkzeugaufruf darf nicht ausgeführt werden. Beauftragen Sie dafür die verantwortliche IT oder Entwicklung, statt mit einem produktiven Agenten zu experimentieren.

Notieren Sie Eingabe, erwartetes Verhalten, tatsächliches Ergebnis und die wirksame Schutzschicht. Wiederholen Sie relevante Tests nach Änderungen an Modell, Quellen oder Werkzeugen. Ein gelungener Versuch beweist nicht, dass alle Varianten sicher abgewehrt werden.

Testen Sie mit den tatsächlich eingesetzten Sprachen und Dokumenttypen. Ein kurzer englischer Beispielsatz ist keine ausreichende Abnahme für deutschsprachige PDF-Offerten und französische Kundenmails.

Im Team braucht es keine Schulung zu jedem Angriffsmuster. Eine kurze Regel ist hilfreicher: Wenn die KI plötzlich etwas anderes tun will als beauftragt, zusätzliche Daten anfordert oder eine unerwartete externe Aktion vorschlägt, nicht einfach bestätigen. Auftrag, Quelle und Vorschlag gemeinsam prüfen lassen.

Legen Sie dafür eine erreichbare Ansprechperson fest. Ein verdächtiger Verlauf sollte gemeldet werden können, ohne dass Mitarbeitende zuerst einen Angriff beweisen müssen. Wenn bereits eine unerwartete Aktion passiert ist, gehören die Integration und die tatsächlich ausgeführten Schritte rasch mit der IT geprüft. Protokolle können dabei helfen, enthalten aber unter Umständen selbst vertrauliche Informationen.

Auch der gewöhnliche Datenschutz bleibt wichtig. Das Schweizer BACS erinnert in seinen aktuellen Hinweisen zum KI-Einsatz im Berufsalltag daran, Arbeitsdaten nicht gedankenlos in KI-Werkzeuge zu übernehmen. Prompt Injection ist ein zusätzliches Thema; sie ersetzt nicht die Entscheidung, welche Daten in welchem freigegebenen Dienst verarbeitet werden dürfen.

BACS: KI im Berufsalltag – Chancen nutzen, Daten schützen

Ein KI-Assistent darf eine Offerte lesen, ohne dem Anbieter unsere Bewertungsregeln zu überlassen. Er darf eine E-Mail zusammenfassen, ohne deren Absender zum Auftraggeber weiterer Aktionen zu machen. Diese Grenze klingt selbstverständlich. In einer KI-Anwendung muss sie bewusst gestaltet werden.

Nehmen Sie diese Woche einen konkreten Ablauf unter die Lupe. Begrenzen Sie seine Daten und Werkzeuge, trennen Sie Entwurf und Ausführung und testen Sie einen harmlosen Umlenkungsversuch. Damit wird das Risiko nicht null. Aber Sie erkennen, wo ein Fehler bloss einen korrigierbaren Text erzeugt – und wo er bereits etwas im Unternehmen verändert.