JiCoRedact. Approve. Document.
What we do not promise
"Does the gate really detect everything?" — No. And we say so here, in the running text, not in the small print.
Redact · 2026-09-19 · 6 min read
The question every good CISO asks — usually without preamble
There is a particular moment in almost every conversation with a security officer that decides how the rest of it will go. After the demonstration has run, after the placeholders in the model context have been shown, almost always the same question comes: "Does that really detect everything?" How one answers that question says more about a product than any feature list.
The honest answer is uncomfortable, but it is the only one that holds up over time: no. No automated detection of personal data in free text is complete — not JiCo's, and not that of any other vendor who is being honest. Anyone claiming the opposite has either never tested their own detection under realistic conditions, or is firmly counting on the person on the other side of the table not checking. Both are bad business in the long run.
What actually works reliably — and what remains statistical
To draw this boundary honestly, one has to distinguish between two completely different kinds of detection that marketing likes to hide under the same word. Structured patterns with a clear, mathematically verifiable form — Swiss AHV numbers and other social security numbers with a check digit, IBANs, credit card numbers, typical formats of API keys and other secrets — can be detected with very high reliability, because their structure is itself the detection mechanism. The same goes for structural entities that come directly from Jira: assignee, reporter, whoever is mentioned in a comment — JiCo knows these from the ticket's metadata anyway, independently of any text recognition.
Free text is the fundamentally harder case, and here every gate — including this one — works statistically, with the same fundamental limits as any procedure of this kind. A name that appears in a subordinate clause without recognisable context, an unusually spelled first name, an allusion that only someone with insider knowledge would recognise as referring to a person — all of that can slip through. This is not a weakness that could be fixed with the next software update. It is a fundamental property of statistical text recognition, which every comparable system works with, whether it admits so openly or not.
Why the right metric is "how much", not "how well"
This limit is also the reason why JiCo deliberately does not report a particular number: a hit rate, which would suggest that one knows the share of cases actually detected out of all those present. Such a rate would need a gold standard — an independently produced, complete list of the personal data really contained in a given ticket, against which one's own detection could be compared. For free text in real, heterogeneous Jira instances this gold standard does not exist and cannot be improvised in any serious way.
The metric JiCo keeps instead is called K9 and simply counts hits — how many names, telephone numbers, account numbers and similar patterns the gate intercepted in a given period, broken down by type. A number about what is systematically missed would be invented, however convincing and reassuring it might look on a management dashboard. Better a metric that promises less and is correct than one that impresses and falls apart in the first independent review.
The second consequence: what cannot be classified with confidence does not pass
From this limit follows a second, practical consequence that is just as non-negotiable as the first: what the gate cannot classify with sufficient confidence is not passed on. That applies to attachments in particular. An image, a PDF, an office document whose content cannot be checked technically — whether because the necessary tool is missing or because the format is too unusual — is not passed on to the model anyway as "probably safe". It does not go through at all. Full stop.
This fail-closed stance is the actual answer to incomplete detection, not a contradiction of it: where detection reaches its limit, so does what is passed on — not the caution. A system that in case of doubt holds back too much rather than too little behaves structurally differently from one that waves things through when unsure, because waving things through is more convenient and leads less often to complaints from users waiting for their attachment.
What is already available in addition today, and what is still outstanding
Statistical detection in free text is not meant to be the final stage of development. A specialised detection library built for named entity recognition is planned as an extension — as an optional extra that lies dormant without a separate installation, rather than forcing an additional dependency that not every customer already has in use anyway. It is deliberately not connected to the actual detection today, not even where it is already installed — an earlier, overly optimistic formulation on this point was corrected, for exactly the same reason that nothing is promised in this article that has not yet been delivered. Further, even more demanding stages of detection are envisaged as a later expansion, but are explicitly not part of today's product.
This distinction between what actually runs today and what is planned for later but not yet built is deliberately not blurred. A tool that advertises a planned future capability as though it were already part of the product today commits the same error as the exaggerated answer to the question about complete detection described at the start — only a version of it that turns out to be wrong later, when a customer actually looks for the promised capability and does not find it.
Why this limit stands openly in the main text, not in a footnote
A tool whose entire promise is data minimisation loses its credibility at exactly the moment when one of its real limits only comes to light in a dispute — whether in an internal audit or in an enquiry from a supervisory authority. That is why this limit stands here, in the middle of the running text, in a paragraph of its own, and not as a footnote beneath a glossy landing page where nobody reads it before signing.
A product that names its own limits of its own accord, instead of waiting until somebody finds them, makes things easier for the person who later has to answer for it. Not for the sales representative who sold the software, but for the security officer who in a year's time has to explain what actually happened — not what was supposed to happen according to the marketing material.