Prompt Injection in Rechnungen: Wie KMU ihre KI-Workflows schützen

Eine Rechnung ist für einen KI-Assistenten nicht nur ein Datenträger, sondern potenziell auch eine Quelle fremder Anweisungen. Enthält ein PDF, eine E-Mail oder ein Bild manipulierten Text, kann ein unzureichend abgesichertes Sprachmodell versuchen, diesen Text zu befolgen, statt ihn lediglich auszulesen. Dieses Risiko heißt Prompt Injection. Für KMU ist deshalb nicht die Frage entscheidend, ob ein Modell „intelligent genug“ ist, sondern ob der gesamte Dokumentenworkflow Daten, Anweisungen und erlaubte Aktionen technisch trennt.
Ein sicherer Ansatz behandelt jedes eingehende Dokument als nicht vertrauenswürdige Eingabe. Die KI darf Felder vorschlagen, Zusammenhänge markieren und Rückfragen formulieren. Änderungen an Bankverbindungen, Freigaben, Zahlungen oder Stammdaten müssen dagegen durch feste Regeln, Rollen und menschliche Bestätigung geschützt bleiben. Ein einzelner Systemprompt ist dafür kein ausreichender Schutz.
Was ist Prompt Injection?
Sprachmodelle verarbeiten Anweisungen und Inhalte im selben Kontext. Genau diese Eigenschaft kann ausgenutzt werden: Ein fremder Text versucht, die ursprüngliche Aufgabe des Modells zu verändern. Statt etwa nur Rechnungsnummer, Betrag und Lieferant zu extrahieren, soll das Modell plötzlich eine andere Priorität setzen, Informationen offenlegen oder eine verbundene Funktion aufrufen.
OWASP unterscheidet direkte und indirekte Prompt Injection. Bei einem direkten Angriff gibt eine Person die manipulierende Anweisung unmittelbar in ein KI-System ein. Bei einer indirekten Prompt Injection steckt die Anweisung in einer externen Quelle, die das Modell verarbeitet. Das können Webseiten, E-Mails, Dateien, Dokumentmetadaten oder Bilder sein. Für Rechnungsworkflows ist vor allem die indirekte Variante relevant.
| Variante | Typischer Eingang | Beispiel im Rechnungsprozess |
|---|---|---|
| Direkte Prompt Injection | Chatfeld oder frei eingegebener Auftrag | Eine Person versucht, die Prüfregeln des Assistenten im Dialog zu überschreiben |
| Indirekte Prompt Injection | PDF, Bild, E-Mail, XML, Webseite oder Anhang | Ein Beleg enthält Text, den das Modell fälschlich als Arbeitsanweisung interpretiert |
| Multimodale Injection | Text in Bildern oder kombinierten Dateien | Eine Anweisung ist visuell kaum auffällig, wird aber durch die Bilderkennung erfasst |
Das Bundesamt für Sicherheit in der Informationstechnik bezeichnet indirekte Prompt Injections als intrinsische Schwachstelle anwendungsintegrierter KI-Sprachmodelle. Das Risiko entsteht besonders dann, wenn ungeprüfte Inhalte aus externen Quellen verarbeitet werden und das Ergebnis wiederum andere Anwendungen beeinflussen kann.
Warum Rechnungen ein realistischer Angriffsweg sind
Rechnungen kommen aus vielen Quellen: per E-Mail, Upload, Scan, Kundenportal oder Schnittstelle. Sie enthalten Freitext, Positionsbeschreibungen, Zahlungsinformationen und teilweise eingebettete Anhänge. Ein Mensch erkennt normalerweise, dass ein Satz im Dokument zum Dokument gehört. Ein Sprachmodell kann jedoch nicht von selbst garantieren, dass es fremden Inhalt ausschließlich als Daten behandelt.
Das Risiko steigt mit der Handlungsfähigkeit des Systems. Eine KI, die nur eine Zusammenfassung erstellt, kann falsche Angaben liefern. Ein Agent mit Zugriff auf Kundendaten, E-Mail, Zahlungsfunktionen oder externe Schnittstellen kann im ungünstigsten Fall unerwünschte Aktionen vorbereiten oder auslösen. OWASP spricht hier zusätzlich von übermäßiger Handlungsfreiheit. NIST beschreibt dasselbe Grundproblem als Agent Hijacking: Vertrauenswürdige interne Anweisungen und nicht vertrauenswürdige externe Daten sind nicht klar genug getrennt.
Prompt Injection ist nicht dasselbe wie eine fehlerhafte Texterkennung. OCR kann eine Ziffer falsch lesen, obwohl niemand manipuliert hat. Prompt Injection versucht dagegen, das Verhalten des KI-Systems zu beeinflussen. Beide Risiken können zugleich auftreten und benötigen unterschiedliche Kontrollen.
Zwei Praxisbeispiele aus dem KMU-Alltag
Beispiel 1: Manipulierter Anhang bei einer Lieferantenrechnung
Ein Handelsbetrieb lässt eingehende PDF-Rechnungen durch einen KI-Assistenten vorsortieren. Ein Dokument enthält neben den eigentlichen Rechnungsdaten eine Anweisung, die Prüfregeln zu ignorieren und den Vorgang als bereits genehmigt zu markieren. Die Anweisung kann klein, farblich unauffällig oder in einem zusätzlichen Dokumentbereich platziert sein.
Ein unsicherer Ablauf übergibt den gesamten erkannten Text gemeinsam mit weitreichenden Werkzeugen an dasselbe Modell. Ein robuster Ablauf isoliert die Datei, extrahiert nur definierte Felder in ein festes Schema und behandelt alle übrigen Texte als untrusted content. Der Status „genehmigt“ kann ausschließlich eine berechtigte Person oder eine deterministische Geschäftsregel setzen. Die KI darf höchstens „Prüfung empfohlen“ vorschlagen.
Beispiel 2: Neue Bankverbindung in einer E-Mail
Ein Dienstleistungsunternehmen erhält eine Rechnung mit einer begleitenden Nachricht über eine angeblich neue IBAN. Der KI-Assistent soll E-Mail und Anhang zusammenfassen. Im Text wird versucht, das System zur Änderung der Lieferantenstammdaten und zur sofortigen Zahlungsfreigabe zu bewegen.
Der sichere Prozess trennt drei Entscheidungen. Erstens darf die KI die abweichende Bankverbindung erkennen und als Risiko markieren. Zweitens wird die Änderung der Stammdaten über einen unabhängigen Verifikationskanal geprüft. Drittens bleibt die Zahlungsfreigabe einer berechtigten Rolle vorbehalten. Selbst wenn das Modell die fremde Anweisung befolgen wollte, fehlen ihm die notwendigen Rechte.
Sieben Schutzschichten für KI-Dokumentenworkflows
1. Externe Inhalte ausdrücklich als Daten kennzeichnen
Systemanweisungen, Nutzerauftrag und Dokumentinhalt sollten technisch getrennt übergeben werden. Das Modell muss wissen, dass Text aus Rechnungen, E-Mails und Anhängen keine autorisierte Anweisung ist. Strukturierte Eingabefelder sind besser als eine ungegliederte Verkettung aller Texte. Diese Trennung reduziert das Risiko, beseitigt es laut OWASP aber nicht vollständig.
2. Nur definierte Felder ausgeben lassen
Die KI sollte nicht frei entscheiden, was als Nächstes passiert. Fordern Sie ein begrenztes Ausgabeformat an, etwa Lieferant, Rechnungsnummer, Leistungsdatum, Brutto- und Steuerbetrag, Währung, IBAN, Konfidenz sowie Auffälligkeiten. Anschließend prüft deterministischer Code Datentypen, Pflichtfelder, Summen und zulässige Werte. Freitext bleibt ein Hinweis, keine Buchungsanweisung.
3. Rechte nach dem Prinzip der geringsten Berechtigung vergeben
Ein Modell zur Belegerkennung benötigt keinen direkten Zugriff auf Zahlungen, Benutzerverwaltung oder API-Schlüssel. Wenn ein Werkzeug notwendig ist, erhält es einen eng begrenzten Scope. Lesezugriff und Schreibzugriff sollten getrennt sein. Kritische Funktionen werden nicht allein deshalb verfügbar, weil ein Assistent sie theoretisch aufrufen könnte.
Claribill beschreibt auf der Sicherheitsseite unter anderem verschlüsselte Übertragung, Zugriffskontrollen und Datensicherung. Für KI-Erweiterungen gilt derselbe Grundsatz: vorhandene Sicherheitsgrenzen dürfen durch einen komfortablen Assistenten nicht umgangen werden.
4. Kritische Aktionen immer bestätigen lassen
OWASP empfiehlt menschliche Freigaben für risikoreiche Aktionen. Im Rechnungswesen betrifft das insbesondere Zahlungen, Änderungen von Bankverbindungen, neue Lieferanten, Steuerlogik, Löschungen und den Versand finaler Dokumente. Die Bestätigung muss den konkreten Betrag, Empfänger und Änderungsinhalt zeigen. Ein pauschaler Schalter „KI darf handeln“ ist keine belastbare Freigabe.
Mit klaren Zuständigkeiten und den öffentlich beschriebenen Teamrollen in Claribill lässt sich organisatorisch festlegen, wer Rechnungen bearbeitet und wer sensible Schritte kontrolliert. Eine KI-Empfehlung darf diese Rollenlogik nicht ersetzen.
5. Ein- und Ausgaben unabhängig prüfen
Filter können verdächtige Formulierungen, unsichtbare Zeichen, ungewöhnliche Kodierungen oder unerwartete Dokumentbereiche erkennen. Sie sind eine zusätzliche Schicht, keine Garantie. Auch die Ausgabe muss geprüft werden: Passt die extrahierte IBAN zum Lieferantenstamm? Stimmen Netto, Steuer und Brutto rechnerisch? Enthält der Vorschlag Felder, die im Original gar nicht vorkommen?
Besonders wichtig ist die Quellenbindung. Jede extrahierte Angabe sollte auf eine Seite, Position oder Datenquelle zurückführbar sein. So kann eine prüfende Person schnell unterscheiden, ob die KI einen Wert gelesen, abgeleitet oder erfunden hat.
6. Verdächtige Dokumente isolieren
Ein auffälliger Anhang sollte nicht automatisch in weitere Workflows wandern. Ein Quarantänestatus kann verhindern, dass Inhalte in Wissensspeicher, Vorlagen oder Folgeprozesse übernommen werden. Die ursprüngliche Datei bleibt unverändert erhalten, während eine berechtigte Person den Vorgang prüft. Das unterstützt auch die spätere Ursachenanalyse.
7. Angriffe testen und Entscheidungen protokollieren
NIST betont, dass Bewertungen anpassungsfähig sein müssen und wiederholte Angriffsversuche realistischere Ergebnisse liefern können. KMU müssen dafür kein großes Red-Team aufbauen. Eine kleine Testsuite mit manipulierten Beispieldokumenten kann bereits prüfen, ob das System Anweisungen im Beleg ignoriert, keine unerlaubten Werkzeuge aufruft und kritische Aktionen zuverlässig stoppt.
Protokollieren Sie Modellversion, Aufgabe, Dokument-ID, extrahierte Felder, Warnungen, Freigaben und ausgeführte Aktionen. Sensible Prompts oder vollständige Rechnungsinhalte sollten nicht unkontrolliert in Diagnoseprotokollen landen. Ziel ist ein nachvollziehbarer Prüfpfad, keine zweite Datensammlung.
Was Österreich und Deutschland unterscheidet
Das technische Prompt-Injection-Risiko ist in Österreich und Deutschland gleich: Ein externes Dokument kann ein KI-Modell beeinflussen, unabhängig vom Sitz des Unternehmens. Unterschiede entstehen eher durch Aufsicht, branchenspezifische Vorgaben und die konkrete Umsetzung europäischer Regeln.
Für Deutschland stellt das BSI konkrete Sicherheitsinformationen zu indirekten Prompt Injections und generativen KI-Modellen bereit. Österreichische KMU können diese technischen Empfehlungen ebenfalls nutzen. Die österreichische Datenschutzbehörde weist zugleich darauf hin, dass die DSGVO parallel zur KI-Verordnung anwendbar bleibt, sobald personenbezogene Daten verarbeitet werden. Das betrifft beispielsweise Namen, Kontaktdaten oder Einzelunternehmerdaten in Rechnungen.
Nicht jedes KMU fällt automatisch unter jede Cybersicherheitsregel der EU. Der neue EU-Aktionsplan für Cybersicherheit und KI vom 7. Juli 2026 richtet den Blick jedoch klar auf sichere Nutzung, Evaluierung und Widerstandsfähigkeit. Für die betriebliche Praxis ist die Richtung eindeutig: KI muss innerhalb bestehender Sicherheits- und Datenschutzkontrollen arbeiten, nicht außerhalb davon.
Fehler, die einen guten Systemprompt zunichtemachen
| Fehler | Warum er riskant ist | Bessere Kontrolle |
|---|---|---|
| Dokumenttext und Systemanweisung werden einfach zusammengefügt | Fremde Inhalte erscheinen wie legitime Befehle | Kontexte strukturieren und externe Inhalte kennzeichnen |
| Die KI darf direkt zahlen oder Stammdaten ändern | Eine erfolgreiche Manipulation hat unmittelbare Folgen | Geringste Rechte und menschliche Freigabe |
| Nur bekannte Schlüsselwörter werden blockiert | Angriffe können umformuliert, kodiert oder visuell versteckt sein | Mehrschichtige Filter, feste Schemas und Aktionstrennung |
| Eine hohe Modellkonfidenz gilt als Freigabe | Konfidenz ist kein Sicherheitsnachweis | Geschäftsregeln und unabhängige Prüfung |
| Es gibt keine Angriffs- und Regressionstests | Schutzmaßnahmen können nach Modell- oder Promptwechseln versagen | Wiederholbare Testfälle und Freigabegates |
Checkliste für KMU
- Welche externen Inhalte sieht der KI-Assistent: E-Mails, PDFs, Bilder, XML oder Webseiten?
- Sind Systemanweisungen, Nutzerauftrag und Dokumentdaten technisch getrennt?
- Welche Felder darf die KI vorschlagen, und welche Entscheidungen bleiben deterministisch?
- Hat das Modell nur die minimal notwendigen Lese- und Schreibrechte?
- Benötigen Zahlung, IBAN-Änderung, Versand und Löschung eine konkrete Freigabe?
- Werden Ausgaben gegen Rechnungsdaten, Stammdaten und Rechenregeln geprüft?
- Gibt es einen Quarantänestatus für verdächtige Dokumente?
- Sind Aktionen, Freigaben und Modellversionen nachvollziehbar protokolliert?
- Existieren Tests mit direkten, indirekten und multimodalen Manipulationsversuchen?
- Ist geregelt, wie ein Verdachtsfall gestoppt, untersucht und bereinigt wird?
Für die organisatorische Einbettung helfen der Claribill-Leitfaden zum Vier-Augen-Prinzip im Rechnungsprozess und der Beitrag über begrenzte API-Schlüssel für Rechnungsdaten. Welche Aufgaben KI sinnvoll vorbereiten kann und wo Kontrolle nötig bleibt, ordnet der Beitrag KI in der Rechnungsverarbeitung ein.
Häufige Fragen
Kann ein perfekter Systemprompt Prompt Injection verhindern?
Nein. Klare Systemanweisungen sind sinnvoll, aber OWASP beschreibt keine narrensichere Einzelmaßnahme. Entscheidend ist Defense in Depth: getrennte Kontexte, begrenzte Rechte, validierte Ausgaben, menschliche Freigaben und wiederholte Tests.
Muss jede ungewöhnliche Rechnung blockiert werden?
Nein. Ein Verdacht ist noch kein Angriff. Ein guter Workflow markiert Auffälligkeiten, isoliert risikoreiche Folgeaktionen und ermöglicht eine sachliche Prüfung. Zu aggressive Filter können legitime Dokumente unnötig stoppen.
Ist Prompt Injection nur bei autonomen Agenten relevant?
Nein. Auch ein reiner Extraktions- oder Zusammenfassungsdienst kann manipulierte Ergebnisse liefern. Bei Agenten mit Werkzeugzugriff steigt allerdings die mögliche Auswirkung, weil aus einer falschen Antwort eine unerwünschte Aktion werden kann.
Fazit: Das Dokument darf Daten liefern, aber keine Befehle
Prompt Injection macht KI in Rechnungsworkflows nicht unbrauchbar. Sie verändert jedoch die Sicherheitsarchitektur. Ein eingehender Beleg ist nicht automatisch vertrauenswürdig, nur weil er wie eine normale Rechnung aussieht. Der Assistent darf daraus strukturierte Vorschläge gewinnen, aber keine fremden Anweisungen übernehmen.
Die wirksamste Kontrolle liegt außerhalb des Modells: minimale Rechte, feste Datenformate, unabhängige Prüfregeln, menschliche Freigaben und ein nachvollziehbarer Audit-Pfad. So bleibt KI ein Werkzeug zur Vorbereitung. Verantwortung und kritische Entscheidungen verbleiben im kontrollierten Geschäftsprozess.
Dieser Beitrag bietet eine allgemeine Orientierung und ersetzt keine individuelle Rechts-, Datenschutz- oder Sicherheitsberatung.
Quellen
- Europäische Kommission: EU Action Plan on Cybersecurity and Artificial Intelligence
- BSI: Indirect Prompt Injections in anwendungsintegrierten KI-Sprachmodellen
- BSI: Generative KI-Modelle – Chancen und Risiken für Industrie und Behörden
- OWASP: LLM01:2025 Prompt Injection
- NIST: Strengthening AI Agent Hijacking Evaluations
- NIST: Generative Artificial Intelligence Profile
- Österreichische Datenschutzbehörde: DSGVO und KI-Verordnung
Verwandte Artikel
Kommentare
Noch keine Kommentare. Schreiben Sie den ersten.


