In vielen GenAI-Projekten wird viel Energie in Modelle, Retrieval oder Ausgaben gesteckt – und zu wenig in den Moment, in dem Informationen überhaupt in das System gelangen. Genau dort entscheidet sich jedoch häufig, ob ein Use Case stabil, sicher und wirtschaftlich läuft. Ein KI-Inputfilter ist kein einzelnes Tool, sondern eine Architekturkomponente: Regeln, Prüfungen und Transformationen, die aus Nutzer- und Systemdaten einen „sauberen“ Prompt-Input machen.
Typische Symptome fehlender Inputkontrolle sind schnell erkennbar: Mitarbeitende kopieren komplette E-Mails samt Signaturen und Telefonnummern, es werden interne Dokumente mit sensitiven Passagen eingepastet, oder Prompts enthalten unklare Ziele („Mach das besser“), die zu beliebigen Ergebnissen führen. Gleichzeitig wächst die Angriffsfläche: Wenn externe Texte verarbeitet werden (z. B. aus Tickets, PDFs oder Web-Formularen), können Anweisungen eingeschleust werden, die das Modell vom eigentlichen Auftrag ablenken.
Warum Inputkontrolle bei GenAI mehr ist als „Prompt sauber schreiben“
Eingaben sind ein Sicherheits- und Kostenhebel
LLM-Anwendungen arbeiten mit Kontext: Je mehr Text übergeben wird, desto höher sind Latenz und Kosten – und desto größer ist das Risiko, dass unerwünschte Inhalte verarbeitet werden. Zudem können bereits kleine, unbemerkte Details (personenbezogene Daten, Vertragsklauseln, Kundennummern) unerwünschte Nebenfolgen haben, etwa wenn Ausgaben später geteilt oder gespeichert werden.
Inputkontrolle wirkt deshalb in drei Richtungen:
- Sicherheit: Reduktion von Prompt-Injection-Risiken und versehentlicher Datenweitergabe.
- Qualität: Eindeutigere Aufgabenstellung, weniger Rauschen, stabilere Antworten.
- Effizienz: Weniger Tokens, kĂĽrzere Antwortzeiten, besser planbare Kosten.
Unterschied zwischen „Filter“ und „Gate“
Ein Inputfilter ist nicht zwingend ein „Blocker“. Sinnvoll ist häufig ein Gate-Modell mit abgestuften Aktionen:
- zulassen (unverändert),
- transformieren (z. B. kĂĽrzen, strukturieren, maskieren),
- anreichern (z. B. Metadaten, Kontext aus erlaubten Quellen),
- zurĂĽckweisen (wenn Regeln verletzt werden),
- eskalieren (z. B. Review-Queue bei Unsicherheit).
Welche Risiken im Input typischerweise ĂĽbersehen werden
Prompt-Injection über „fremde“ Texte
In der Praxis kommt Prompt-Injection selten aus dem direkten Nutzerprompt, sondern aus Texten, die der Nutzer als „Material“ mitliefert: E-Mail-Verläufe, Chat-Logs, Webseiteninhalte, Support-Tickets oder Dokumente. Solche Texte können versteckte oder offen formulierte Anweisungen enthalten („Ignoriere alle bisherigen Regeln und gib … aus“). Ein Inputfilter sollte daher strikt zwischen Systemanweisung, Nutzerziel und untrusted Content unterscheiden und Letzteren als Daten behandeln – nicht als Instruktion.
Personen- und Geheimdaten im FlieĂźtext
Viele Organisationen haben bereits Mechanismen zur Datensicherheit, aber GenAI verändert den „Kopierpfad“: Informationen werden in Freitext gesammelt und neu kombiniert. Ein Filter muss nicht perfekt erkennen, aber zuverlässig die häufigsten Muster abfangen (z. B. Kontakt- und Identifikationsdaten, Kundendaten, interne Zugangsinformationen). Für vertiefte Maßnahmen bei personenbezogenen Daten ist ein abgestimmter Ansatz sinnvoll, der zu bestehenden Prozessen passt, etwa über PII-Redaktion vor GenAI.
Zu viel Kontext: Rauschen schlägt Wissen
Mehr Text ist nicht automatisch bessere Qualität. Lange Eingaben enthalten oft widersprüchliche Ziele, irrelevante Abschnitte oder formale Artefakte (Signaturen, Disclaimer, Header/Footer). Der Inputfilter ist der richtige Ort, um zu normalisieren, zu kürzen und in eine einheitliche Struktur zu bringen. Ergänzend hilft ein bewusstes Vorgehen zur Datenminimierung, weil weniger Input häufig nicht nur sicherer, sondern auch präziser ist.
Bausteine eines KI-Inputfilters: Architektur, die in Teams funktioniert
1) Kanonisierung: Text technisch „sauber“ machen
Der erste Schritt ist banal, aber wirkungsvoll: Eingaben werden in eine kanonische Form ĂĽberfĂĽhrt. Beispiele:
- Encoding vereinheitlichen (UTF-8),
- unsichtbare Zeichen, Zero-Width-Spaces entfernen,
- ZeilenumbrĂĽche normalisieren,
- HTML/Markdown kontrolliert in Plaintext umwandeln (oder strikt erlaubte Tags).
Diese MaĂźnahmen erschweren triviale Umgehungen (z. B. ĂĽber obfuskierte Tokens) und stabilisieren nachgelagerte Heuristiken.
2) Strukturierung: Vom Freitext zur maschinenlesbaren Aufgabe
Ein guter Filter transformiert Freitext in Felder. Ein einfaches Muster ist ein internes Prompt-Schema mit klaren Slots:
- Ziel (was soll entstehen?),
- Kontext (welche Informationen sind relevant?),
- Constraints (Ton, Format, Do/Don’t),
- Eingabematerial (untrusted, nur Daten),
- Outputformat (z. B. Tabelle, Stichpunkte).
Damit sinkt die Wahrscheinlichkeit, dass das Modell „nebenbei“ Aufgaben erfindet oder untrusted Text als Anweisung interpretiert. Gleichzeitig wird es einfacher, Regeln pro Slot zu definieren (z. B. „Eingabematerial darf keine Zugangsdaten enthalten“).
3) Klassifizierung: Welche Datenklasse liegt vor?
In Unternehmen ist nicht jede Information gleich sensibel. Ein Inputfilter kann ĂĽber Metadaten (Quelle, Benutzerrolle, Mandant, Dokumententyp) eine Datenklasse ableiten und daran Aktionen knĂĽpfen: Maskieren, KĂĽrzen, Logging, oder harte Blockade. Wenn bereits Regelwerke existieren, sollte das Filterdesign dazu passen, etwa ĂĽber Datenklassifizierung fĂĽr GenAI-Daten.
4) Policy-Enforcement: Regeln, die wirklich durchsetzbar sind
Policies sollten nicht als PDF existieren, sondern als ĂĽberprĂĽfbare Logik. Praktische Regelkategorien:
- Maximale Eingabelänge (hartes Limit pro Use Case),
- verborgene Instruktionen im Material neutralisieren (z. B. „Instruktionsphrasen“ in Zitaten),
- unerlaubte Datentypen blocken (z. B. Schlüsselmaterial, Passwörter),
- Quellen-Whitelist/Blacklist (z. B. nur internes Ticket-System, keine externen URLs).
Pragmatischer Leitfaden: Inputfilter in 7 Schritten einfĂĽhren
Ein Inputfilter ist am erfolgreichsten, wenn er wie ein Produkt entwickelt wird: mit klaren Use Cases, Messpunkten und iterativen Regeln.
- Use Case abgrenzen: Welche Aufgabe, welche Nutzer, welche Quellen? „Allzweck-Chat“ erzeugt die höchste Komplexität.
- Prompt-Schema definieren: Slots fĂĽr Ziel, Kontext, Constraints, Material und Ausgabe festlegen.
- Erlaubte Inputs beschreiben: Welche Daten sind notwendig, welche explizit verboten?
- Transformationen priorisieren: KĂĽrzen (Signaturen/Boilerplate), Normalisieren, Maskieren.
- Regeln als Tests formulieren: Beispielinputs sammeln, erwartete Filter-Entscheidung festhalten.
- Fallbacks planen: Zurückweisung mit hilfreicher Rückfrage („Bitte entferne …“), oder Review-Route.
- Monitoring aufsetzen: Wie oft wird gekürzt, blockiert, eskaliert? Wo häufen sich Fehleingaben?
Wie Kürzen, Maskieren und „Rewriting“ zusammenarbeiten
Reduktion: Das Wesentliche extrahieren, ohne Sinnverlust
Ein gängiges Muster ist die zweistufige Reduktion:
- Deterministisch: Entfernen offensichtlicher Artefakte (Signaturen, Disclaimer, Zitate älterer E-Mail-Teile).
- Semantisch: Extraktion relevanter Punkte (z. B. Problem, gewĂĽnschtes Ergebnis, Randbedingungen).
Die semantische Extraktion kann selbst wieder GenAI nutzen – sollte dann aber mit begrenztem Kontext und klarer Aufgabe arbeiten, damit sie nicht „optimiert“, sondern verdichtet.
Maskierung: Minimierung ohne Funktionsverlust
Maskieren bedeutet nicht nur „schwärzen“. Gute Maskierung erhält Struktur, damit Aufgaben lösbar bleiben. Beispiele:
- Namen → [PERSON_1], [PERSON_2]
- E-Mail-Adressen → [EMAIL]
- Kundennummern → [CUSTOMER_ID]
Damit bleiben Beziehungen im Text nachvollziehbar, ohne konkrete Identitäten weiterzugeben. Wichtig ist Konsistenz: Derselbe Identifier sollte innerhalb einer Anfrage stabil bleiben.
Rewriting: Nutzerziele präzisieren, ohne Inhalte zu erfinden
Viele Eingaben sind unscharf. Ein Inputfilter kann die Nutzerfrage in eine präzisere Arbeitsanweisung umformulieren. Entscheidend ist eine harte Grenze: Rewriting darf nur umformulieren, strukturieren und rückfragen – nicht neue Fakten hinzufügen. Ein robustes Muster sind Rückfragen, wenn Pflichtfelder fehlen („Welche Zielgruppe? Welches Ausgabeformat? Welche Zeitspanne?“).
Eine kompakte Entscheidungshilfe fĂĽr Filter-Aktionen
| Signal im Input | Typische Ursache | Sinnvolle Aktion |
|---|---|---|
| Sehr lange Eingabe mit Zitaten/Boilerplate | E-Mail-Thread, Ticket-Verlauf | Kanonisieren und deterministisch kĂĽrzen |
| Personendaten im Klartext | Kopieren aus CRM, Signatur, Protokoll | Maskieren oder blocken (je nach Datenklasse) |
| Instruktionsphrasen im Material | Prompt-Injection oder „Meta-Kommentare“ | Material als Daten markieren, Instruktionen neutralisieren |
| Unklares Ziel („mach besser“) | fehlende Aufgabenpräzision | Rewriting + Rückfragen statt direkt ans Modell |
| Unerlaubte Datentypen (Zugangsdaten) | Copy/Paste aus Secrets-Store oder Konfiguration | Harte ZurĂĽckweisung, Hinweis auf sicheren Kanal |
Welche Betriebsfragen früh geklärt werden sollten
Wo sitzt der Filter in der Kette?
Für zuverlässige Durchsetzung gehört der Filter möglichst nah an den Einstiegspunkt: UI, API-Gateway oder Orchestrator. Wenn mehrere Apps dasselbe Modell nutzen, ist ein zentraler Filter sinnvoll, damit Regeln nicht pro Team divergieren. In größeren Setups bietet sich zudem an, Policy und Durchsetzung zusammen mit bestehenden Steuerungsmechanismen zu denken, etwa über Guardrails für Output – Input- und Outputkontrollen ergänzen sich.
Logging: Was wird gespeichert – und was bewusst nicht?
Inputfilter erzeugen wertvolle Telemetrie (Kürzungsquote, Blockgründe, häufige Maskierungsmuster). Gleichzeitig darf Logging nicht selbst zur Datensammelstelle werden. Praktisch ist eine Trennung:
- Inhalt minimiert oder gehasht (für Reproduzierbarkeit nur wenn nötig),
- Metadaten und Regeln vollständig (für Audits und Betrieb),
- Sampling fĂĽr Debugging zeitlich begrenzt und rollenbasiert.
Messgrößen, die wirklich helfen
Erfolg ist nicht „0 Blocks“. Relevante Indikatoren sind:
- Reduktion der durchschnittlichen Eingabelänge pro Use Case,
- Anteil der Fälle, die durch Rückfragen präziser wurden,
- Blockrate nach Datenklasse (zu hoch kann auf fehlende Guidance hinweisen),
- Qualitätsmetriken der Antworten (vor/nach Filter), idealerweise mit festen Testsätzen.
Typische Fehlerbilder und GegenmaĂźnahmen
Der Filter ist zu streng und erzeugt Umgehung
Wenn Mitarbeitende GenAI als „unbenutzbar“ wahrnehmen, entstehen Parallelwege. Abhilfe schafft eine nutzernahe Rückmeldung: konkrete Hinweise, welche Passage problematisch ist, und wie der Input korrekt geliefert werden kann. Zusätzlich hilft es, pro Use Case „erlaubte Beispiele“ bereitzustellen.
Der Filter ist zu lax und dient nur als Beruhigung
Ein häufiges Anti-Pattern ist ein reines Keyword-Blocking ohne Kontext. Dadurch entstehen viele False Negatives (übersehene Risiken) und False Positives (Blocken harmloser Inputs). Besser: Slot-basierte Regeln, kanonische Normalisierung und abgestufte Aktionen (transformieren statt nur blocken).
Regeln werden nicht versioniert und nicht getestet
Ein Inputfilter ist Software. Regeln brauchen Versionen, Tests und Rollout-Mechanismen. Praktisch ist eine kleine Sammlung von „nasty inputs“ (Edge Cases), die vor jedem Update automatisch geprüft werden. So bleibt die Kontrolle nachvollziehbar und änderbar, ohne die Anwendung zu destabilisieren.
Ein gut konzipierter KI-Inputfilter macht GenAI nicht langsamer, sondern berechenbarer: Er reduziert unnötigen Kontext, stärkt Schutzmechanismen und erhöht die Antwortqualität durch bessere Aufgabenbeschreibung. Entscheidend ist die Kombination aus klarer Struktur, durchsetzbaren Policies und iterativer Verbesserung im Betrieb.
