Unsichtbare Spuren in KI-Texten: Wasserzeichen, versteckte Zeichen und andere Artefakte

erstellt am: 10.02.2026 | | Schlagworte: KI

Viele gehen heute davon aus: KI erzeugt Text, ich kopiere ihn, fertig. Das merkt doch niemand.
In der Praxis ist das oft ein Trugschluss. Den langen Bildestrich kennt mittlerweile fast keder, aber Texte können auch unauffällige, manchmal sogar unsichtbare Hinweise tragen: eingebaute Wasserzeichen auf Token-Ebene, Steuerzeichen aus Unicode, Zeichen, die beim Anzeigen umsortieren, oder Daten, die nur wie “komische Buchstabenfolgen” wirken, aber in Wahrheit Tracking oder eingebettete Payloads sind. Manche Spuren entstehen absichtlich, manche unabsichtlich – aber in beiden Fällen können sie dazu führen, dass Text auffällt, technisch anders ist als er aussieht oder sogar Sicherheitsprobleme auslöst.

Dieser Artikel erklärt die wichtigsten Methoden verständlich, mit Beispielen. Danach folgt kurz ein Überblick über ein Scanner-Tool, das genau solche Artefakte sichtbar machen kann.

Was ist überhaupt eine “Spur” in Text?

Wenn von “Wasserzeichen” oder “Markern” die Rede ist, meinen viele ein sichtbares Logo. Bei Text ist es anders. Es gibt grob drei Klassen:

Unsichtbare oder schwer erkennbare Zeichen im Text selbst
Zum Beispiel Zero-Width-Zeichen, BiDi-Steuerzeichen, ungewöhnliche Leerzeichen oder Mischschriften.
Struktur- oder Kodierungsartefakte
Zum Beispiel Base64-Blöcke, Prozentkodierung, Escape-Sequenzen oder komprimierte Daten, die “nur wie Müll” aussehen, aber Inhalt transportieren.
Statistische Wasserzeichen (ohne zusätzliche Sonderzeichen)
Das ist das Feld, an dem viele Anbieter arbeiten: Der Text sieht völlig normal aus, aber die Auswahl von Wörtern und Token folgt subtilen Mustern, die ein Detektor probabilistisch erkennen kann. Ein konkretes, öffentlich dokumentiertes Beispiel dafür ist SynthID Text.

2) Unsichtbare Unicode-Zeichen: Wenn “gleich” nicht gleich ist

Idee

Unicode enthält Zeichen, die man nicht (oder kaum) sieht: Zero-Width Space, Word Joiner, BOM, Non-Breaking Space und viele mehr. Sie sind für bestimmte typografische oder technische Zwecke gedacht – werden aber auch genutzt, um Text zu markieren oder zu verschleiern. Unicode beschreibt solche Kategorien und Eigenschaften sehr detailliert.

Beispiel: Suche findet nichts

Stell dir vor, jemand schreibt:

Sichtbar: HalloUli
Tatsächlich: HalloUli (zwischen o und U steckt ein Zero-Width Space U+200B)

Im Alltag passiert dann Folgendes:

Die Volltextsuche oder ein Filter findet den Begriff nicht.
Kopieren, Vergleich, Hashing oder Signaturen liefern andere Ergebnisse.
Moderations- oder Security-Regeln können umgangen werden, wenn sie “nur sichtbaren Text” erwarten.

So macht man es sichtbar (Darstellung mit Markern):
Hallo[U+200B]Uli

3) BiDi-Steuerzeichen und “Trojan Source”: Wenn Anzeige und Code auseinanderlaufen

Idee

Bestimmte Unicode-Steuerzeichen beeinflussen die Schreibrichtung (links-nach-rechts, rechts-nach-links) und können Teile einer Zeile visuell umsortieren. Das ist nicht nur ein Kuriosum, sondern ein ernstes Sicherheitsproblem: Angreifer können Code so darstellen lassen, dass er harmlos wirkt, während der Compiler etwas anderes interpretiert. Genau darauf zielt die bekannte “Trojan Source”-Attacke.

Beispiel (vereinfacht, mit Escapes statt unsichtbaren Zeichen)

Angenommen, in einer Codezeile verstecken sich Richtungssteuerzeichen wie u202E (RLO) und u202C (PDF). Dann kann eine Zeile beim Lesen anders aussehen als sie logisch aufgebaut ist.

Warum das gefährlich ist:

Code-Review übersieht “unsichtbare” Umstellungen.
Sicherheitsrelevante Logik kann versteckt werden.
Debugging wird extrem schwer, weil Editor, Diff und Laufzeitverhalten nicht zusammenpassen.

Das ist ein Beispiel für eine Spur, die nicht “KI-spezifisch” ist, aber sehr gut zeigt, warum ein Artefakt-Scan sinnvoll sein kann.

4) Normalisierung: Ein “é” ist nicht immer dasselbe “é”

Idee

Unicode erlaubt mehrere Darstellungen desselben sichtbaren Zeichens. Ein klassisches Beispiel:

NFC: é als ein Codepoint (U+00E9)
NFD: e (U+0065) + kombinierender Akzent (U+0301)

Optisch identisch, technisch verschieden. Normalisierungsformen wie NFC/NFKC sind standardisiert.

Was bringt das in der Praxis?

Ein Text kann “gleich aussehen”, aber bei Hashes, Signaturen oder exakten Vergleichen scheitern.
Systeme, die normalisieren, können andere Ergebnisse liefern als Systeme, die es nicht tun.
Manche “Konfusions”- oder Umgehungstricks basieren genau darauf.

5) Homoglyphen und Mischschriften: “paypal” ist nicht immer “paypal”

Idee

Viele Schriften enthalten Zeichen, die sich extrem ähnlich sehen. Besonders bekannt sind Mischungen aus Latein, Kyrillisch und Griechisch. Unicode behandelt das Thema unter “confusables” und Spoofing-Abwehr sehr ausführlich.

Beispiel

Das lateinische a (U+0061) sieht fast gleich aus wie das kyrillische а (U+0430).
Damit kann man:

Domains fälschen,
Variablennamen im Code “normal” aussehen lassen,
oder Text so gestalten, dass er für Menschen plausibel ist, für Maschinen aber anders.

In normalem Fließtext ist das oft nur ein Hinweis, im Code ist es deutlich kritischer.

6) Whitespace-Kanäle: Tabs, Leerzeichen, Zeilenenden als Träger

Idee

Whitespace ist Information. Schon einfache Dinge können auffallen:

Trailing Spaces am Zeilenende,
gemischte Einrückung (Tabs + Spaces),
ungewöhnliche Muster in Leerzeichenlängen.

Das kann harmlos sein (schlechte Formatierung) oder bewusst eingesetzt werden, um Bits zu kodieren (Text-Steganografie).

Mini-Beispiel (sichtbar gemacht)

Angenommen, ein Text kodiert “0” als ein Leerzeichen und “1” als Tab am Zeilenende. Visuell kaum zu sehen – technisch eindeutig messbar.

7) Links und Tracking: Die sichtbarste Spur, die trotzdem oft übersehen wird

Idee

Viele Texte enthalten URLs mit Parametern wie utm_source, gclid, fbclid usw. Das ist kein KI-Wasserzeichen, aber es ist ein starker Provenienz-Hinweis: Woher kommt ein Link, über welche Kampagne wurde er geteilt, welche Plattform war beteiligt?

Beispiel:
https://example.org/artikel?utm_source=newsletter&utm_campaign=mai

In redaktionellen Workflows ist das relevant, weil:

Tracking ungewollt Daten abfließen lassen kann,
Links “aufgebläht” werden,
Inhalte beim Teilen auf Plattformen automatisch markiert werden.

8) Kodierte Payloads: Prozentkodierung, Base64, Escape-Sequenzen, Kompression

Hier geht es um Textteile, die aussehen wie Zufall, aber oft Daten sind.

8.1 Prozentkodierung (URL-Encoding)

In URLs oder Logs sieht man häufig Sequenzen wie %7B%22a%22%3A1%7D. Das ist schlicht eine Darstellung von Bytes. Die Regeln dazu sind im URL-Standard beschrieben.

Beispiel
%7B%22user%22%3A%22Uli%22%7D → {"user":"Uli"}

8.2 Base64

Base64 ist ein Standard, um Binärdaten in ASCII zu packen.

Beispiel
eyJ1c2VyIjoiVWxpIn0= → {"user":"Uli"}

Spannend wird es, wenn Base64 nach dem Decoding mit Magic Bytes beginnt, z.B. gzip (1F 8B). Dann ist der Inhalt oft komprimiert und erst nach dem Entpacken lesbar.

8.3 Hex- und Escape-Sequenzen

Sequenzen wie xNN, uNNNN oder sehr lange Hex-Blöcke sind oft ein Hinweis auf eingebettete Daten (Konfiguration, Tracking, Obfuskation, manchmal Malware-Loader in anderen Kontexten).

9) Statistische Wasserzeichen: Markierung ohne Sonderzeichen

Das ist die Klasse, an die viele zuerst denken, wenn “KI-Wasserzeichen” gesagt wird.

Grundprinzip

Ein Modell kann bei der Textgenerierung bestimmte Token minimal bevorzugen, nach einem Schlüssel (Key) und einem Muster. Der Text bleibt gut lesbar, aber die Wahl der Token trägt eine Signatur. Detektion ist dann probabilistisch, nicht absolut.

Konkretes Beispiel: SynthID Text

SynthID Text ist als “logits processor” beschrieben, der nach Top-K/Top-P die Token-Wahrscheinlichkeiten so verändert, dass ein Wasserzeichen codiert wird. Es ist dokumentiert, open-sourced und inklusive Detektor-Ansatz beschrieben – inklusive Grenzen (z.B. starkes Umschreiben oder Übersetzen senkt die Erkennbarkeit).

Wichtig: Solche Watermarks sind kein Allheilmittel. Sie helfen bei Attribution und Plattform-Policies, aber sie sind nicht dafür gedacht, “motivierte Angreifer” sicher zu stoppen.

Zusätzliche wissenschaftliche Perspektive liefert auch die Forschung zu Wasserzeichen für LLM-Ausgaben, z.B. “A Watermark for Large Language Model Outputs”.

10) Heuristiken: Akrostichon, Entropie, Wiederholungen

Das sind keine “Beweise”, aber nützliche Hinweise vor allem, wenn man nach versteckten Botschaften oder technischen Artefakten sucht.

Akrostichon (Acrostic)

Ein Akrostichon ist eine Botschaft in den Anfangsbuchstaben, z.B. zeilenweise:

Heute schreibe ich einen Text.
Im zweiten Absatz folgt mehr.
Dann kommt noch ein Beispiel.
Ende.

Die Anfangsbuchstaben ergeben HIDE. Das ist Literaturtechnik, kann aber auch für versteckte Signale genutzt werden.

Entropie

Sehr “zufällige” Zeichenfolgen (hohe Entropie) deuten häufig auf kodierte Daten hin (Tokens, Keys, Hashes, komprimierte Inhalte). Das ist nur ein Hinweis, kein Urteil.

Wiederholungen

Gleichförmige Muster oder häufige Wiederholungen können auf Templates, Copy-Paste oder maschinelle Produktion hindeuten aber genauso auf ganz normale Formulare, Protokolle oder juristische Texte.

11) Was ist heute bereits im Einsatz – und was ist eher geplant oder experimentell?

Sehr verbreitet (Alltag, Plattformen, Security):

Unsichtbare Unicode-Zeichen und Sonder-Leerzeichen (absichtlich oder via Copy/Paste).
BiDi-Steuerzeichen als Sicherheitsrisiko (Trojan Source).
Mischschriften/Confusables (Phishing, Täuschung, Code).
Tracking-Parameter in Links (Marketing, Plattformtracking).
Base64/Prozentkodierung/komprimierte Payloads (legitim in Technik, aber auch missbrauchbar).

Im Aufbau, je nach Anbieter und Ökosystem:

Statistische Wasserzeichen für Text, inklusive Detektoren (z.B. SynthID Text, mit klar beschriebenen Grenzen).

Eher “Framework-/Ökosystem-Thema” (nicht nur Text, oft dateibasiert):

Signierte Provenienz-Standards wie C2PA/Content Credentials: stark im Bereich Medien (Bilder/Video), perspektivisch auch für andere Inhalte denkbar, aber abhängig von Tooling und Plattformunterstützung.

Kurz vorgestellt: Ein Artefakt-Scanner für Text und Code

https://ulrischa.github.io/AIWatermarkDetector/

Das Tool aus dem Beitrag ist als “AI Markers & Watermark Artifact Scanner” konzipiert. Es arbeitet bewusst mit Evidenzstufen:

PROOF: sicher nachweisbare Artefakte (z.B. konkrete Unicode-Steuerzeichen, BiDi-Controls)
STRONG: validierte Decodes (z.B. Base64 → lesbarer Text/JSON, ggf. nach Dekompression)
MEDIUM / HINT: konservative Indikatoren und Heuristiken

Was es konkret prüft (Auszug):

Unicode-Invisibles und Controls, inkl. BiDi/Trojan-Source-Muster
Normalisierungshinweise (NFC/NFKC)
Confusables/Mischschriften (im Code konservativ)
Whitespace-Kanäle (Trailing Spaces, gemischte Indents)
URL-Tracking-Parameter
Payloads: Prozentkodierung, Base64 (inkl. Magic-Bytes + optional Dekompression), Hex/Escapes
Heuristiken: Entropie, Akrostichon, Wiederholungen

Zusätzlich kann optional eine PHP-API zugeschaltet werden, um serverseitig (z.B. mit ICU/IntlChar und Spoofchecker) robuste Checks zu fahren – besonders praktisch, wenn Browser-APIs (z.B. Dekompression) nicht verfügbar sind.