JiCoSchwärzen. Freigeben. Belegen.
Was wir nicht versprechen
„Erkennt die Schleuse wirklich alles?" — Nein. Und wir sagen es hier, im Fliesstext, nicht im Kleingedruckten.
Schwärzen · 2026-09-19 · 6 Min.
Die Frage, die jeder gute CISO stellt — meistens ohne Umschweife
Es gibt einen bestimmten Moment in fast jedem Gespräch mit einer Sicherheitsverantwortlichen, der über den weiteren Verlauf entscheidet. Nachdem die Demo gelaufen ist, nachdem die Platzhalter im Modellkontext gezeigt wurden, kommt fast immer dieselbe Frage: „Erkennt das wirklich alles?" Wie man auf diese Frage antwortet, sagt mehr über ein Produkt aus als jede Feature-Liste.
Die ehrliche Antwort ist unbequem, aber sie ist die einzige, die auf Dauer trägt: Nein. Keine automatisierte Erkennung von Personendaten in Freitext ist vollständig — nicht bei JiCo, nicht bei irgendeinem anderen Anbieter, der ehrlich ist. Wer das Gegenteil behauptet, hat entweder die eigene Erkennung nie unter realistischen Bedingungen getestet, oder er rechnet fest damit, dass die Person auf der anderen Seite des Tisches nicht nachprüft. Beides ist auf lange Sicht ein schlechtes Geschäft.
Was tatsächlich zuverlässig funktioniert — und was statistisch bleibt
Um diese Grenze ehrlich zu ziehen, muss man zwischen zwei völlig unterschiedlichen Arten von Erkennung unterscheiden, die im Marketing gerne unter demselben Wort verschwinden. Strukturierte Muster mit einer klaren, mathematisch überprüfbaren Form — AHV-Nummern und andere Sozialversicherungsnummern mit Prüfziffer, IBAN, Kreditkartennummern, typische Formate von API-Schlüsseln und anderen Secrets — lassen sich mit sehr hoher Zuverlässigkeit erkennen, weil ihre Struktur selbst schon der Erkennungsmechanismus ist. Dasselbe gilt für strukturelle Entitäten, die direkt aus Jira kommen: Bearbeiter, Melder, wer in einem Kommentar erwähnt wird — diese kennt JiCo ohnehin aus den Metadaten des Tickets, unabhängig von einer Texterkennung.
Freitext ist der grundsätzlich schwerere Fall, und hier arbeitet jede Schleuse — auch diese — statistisch, mit denselben grundsätzlichen Grenzen wie jedes Verfahren dieser Art. Ein Name, der in einem Nebensatz ohne erkennbaren Kontext auftaucht, ein ungewöhnlich geschriebener Vorname, eine Anspielung, die nur jemand mit Insiderwissen als Personenbezug erkennen würde — all das kann durchrutschen. Das ist keine Schwäche, die sich mit dem nächsten Software-Update beheben liesse. Es ist eine grundsätzliche Eigenschaft von statistischer Texterkennung, mit der jedes vergleichbare System arbeitet, ob es das offen zugibt oder nicht.
Warum die richtige Kennzahl „wie viel", nicht „wie gut" ist
Diese Grenze ist auch der Grund, warum JiCo bewusst eine bestimmte Zahl nicht ausweist: eine Trefferquote, die suggerieren würde, man kenne den Anteil der tatsächlich erkannten Fälle an allen vorhandenen. Eine solche Quote bräuchte einen Goldstandard — eine unabhängig erstellte, vollständige Liste dessen, was in einem gegebenen Ticket wirklich an Personendaten steckt, gegen die man die eigene Erkennung abgleichen könnte. Für Freitext in echten, heterogenen Jira-Instanzen existiert dieser Goldstandard nicht und lässt sich auch nicht seriös improvisieren.
Die Kennzahl, die JiCo stattdessen führt, heisst K9 und zählt schlicht Treffer — wie viele Namen, Telefonnummern, Kontonummern und ähnliche Muster die Schleuse in einem bestimmten Zeitraum abgefangen hat, aufgeschlüsselt nach Typ. Eine Zahl über das systematisch Übersehene wäre erfunden, so überzeugend und beruhigend sie auf einem Management-Dashboard auch aussehen würde. Lieber eine Kennzahl, die weniger verspricht und dafür stimmt, als eine, die beeindruckt und in der ersten unabhängigen Prüfung auseinanderfällt.
Die zweite Konsequenz: Was nicht sicher eingeordnet werden kann, geht nicht durch
Aus dieser Grenze folgt eine zweite, praktische Konsequenz, die genauso wenig verhandelbar ist wie die erste: Was die Schleuse nicht mit ausreichender Sicherheit einordnen kann, wird nicht durchgereicht. Das gilt besonders für Anhänge. Ein Bild, ein PDF, ein Office-Dokument, dessen Inhalt sich technisch nicht prüfen lässt — sei es, weil das nötige Werkzeug fehlt, sei es, weil das Format zu ungewöhnlich ist —, wird nicht „meistens sicher" trotzdem an das Modell weitergereicht. Es geht gar nicht durch. Punkt.
Diese fail-closed-Haltung ist die eigentliche Antwort auf die unvollständige Erkennung, nicht ein Widerspruch dazu: Wo Erkennung an ihre Grenze stösst, endet auch die Weitergabe — nicht die Vorsicht. Ein System, das bei Unsicherheit lieber zu viel zurückhält als zu wenig, verhält sich strukturell anders als eines, das im Zweifel durchwinkt, weil Durchwinken bequemer ist und seltener zu Beschwerden von Anwendern führt, die auf ihren Anhang warten.
Was heute schon ergänzend zur Verfügung steht, und was noch aussteht
Die statistische Erkennung in Freitext ist nicht als letzte Ausbaustufe gedacht. Eine spezialisierte, auf Named-Entity-Recognition ausgelegte Erkennungsbibliothek ist als Erweiterung vorgesehen — als optionales Extra, das ohne separate Installation ruht, statt eine zusätzliche Abhängigkeit zu erzwingen, die nicht jeder Kunde ohnehin schon im Einsatz hat. Sie ist heute bewusst noch nicht an die eigentliche Erkennung angebunden, auch dort, wo sie bereits installiert ist — eine frühere, zu optimistische Formulierung dazu wurde korrigiert, genau aus demselben Grund, aus dem in diesem Beitrag insgesamt nichts versprochen wird, was noch nicht eingelöst ist. Weitere, noch anspruchsvollere Erkennungsstufen sind als Ausbaustufe angedacht, aber ausdrücklich noch nicht Teil des heutigen Produkts.
Diese Unterscheidung zwischen dem, was heute tatsächlich läuft, und dem, was für später vorgesehen, aber noch nicht gebaut ist, wird bewusst nicht verwischt. Ein Werkzeug, das eine geplante zukünftige Fähigkeit so bewirbt, als wäre sie bereits heute Teil des Produkts, begeht denselben Fehler wie die eingangs beschriebene übertriebene Antwort auf die Frage nach vollständiger Erkennung — nur eine Version davon, die sich erst später als falsch herausstellt, wenn ein Kunde die versprochene Fähigkeit tatsächlich sucht und nicht findet.
Warum diese Grenze offen im Haupttext steht, nicht in einer Fussnote
Ein Werkzeug, dessen gesamtes Versprechen Datensparsamkeit lautet, verliert seine Glaubwürdigkeit in genau dem Moment, in dem eine seiner tatsächlichen Grenzen erst in einem Streitfall auffällt — sei es bei einem internen Audit, sei es bei einer Anfrage einer Aufsichtsbehörde. Deshalb steht diese Grenze hier, mitten im Fliesstext, in einem eigenen Absatz, und nicht als Fussnote unter einer glänzenden Landingpage, wo sie niemand liest, bevor er unterschreibt.
Ein Produkt, das seine eigenen Grenzen von sich aus benennt, statt zu warten, bis jemand sie findet, macht es demjenigen leichter, der es später verantworten muss. Nicht der Vertriebsmitarbeiterin, die die Software verkauft hat, sondern der Sicherheitsverantwortlichen, die in einem Jahr erklären soll, was tatsächlich passiert ist — nicht, was laut Werbematerial hätte passieren sollen.