The scanned document in the attachment

The blind spot many filters have

A personal data detection that only looks at plain text seems complete at first glance — until a ticket turns up with a scanned contract, a photograph of a copied identity document or an exported PDF invoice as an attachment. For a system that searches plain text, the content of such a document simply does not exist: from its point of view it is an opaque block of data, not searchable text. Yet in practice it is precisely these attachments that often hold the most sensitive information of all — a payslip, a passport photograph, a handwritten and signed agreement.

An AI assistant that reads a ticket together with its attachment might well process that content anyway — after all, a modern model can perfectly well interpret images and documents too. That is exactly the moment at which a redaction that only looks at text comes to nothing.

The basic rule: not checkable means not passed on

JiCo's basic stance towards attachments is deliberately stricter than towards plain ticket text: an attachment that cannot be checked reliably is not passed on to a model in the first place — regardless of how harmless it may in fact be in the individual case. This is the same fail-closed logic that applies to unknown tools: in case of doubt, hold back rather than let through.

For the three most common forms of attachment there is a separate checking route in each case. Plain text is put through the PII gate like the ticket content itself. PDF documents are first checked for an existing, searchable text layer; if there is none — for instance because it is a pure scan — local text recognition (Tesseract) is used, which turns the image content into checkable text before the actual redaction can even begin. Images pass through a locally operated vision model, which likewise works without any cloud connection.

When an attachment is blocked completely

Even after successful detection there are cases in which JiCo would rather hold an attachment back entirely than pass it on redacted. A detected secret — an access token, a password — blocks the whole attachment, because a single overlooked remnant of it weighs more heavily than the benefit of the rest of the content. The same rule applies when the detection itself is uncertain: if detection confidence is below seventy per cent, the attachment is likewise not passed on, rather than presenting an uncertain redaction as supposedly safe.

A third category is particularly notable: if the local vision model recognises handwriting, a signature or an identity document in an image, the attachment is blocked as well — regardless of whether classic personal data such as names or telephone numbers would be recognisable anywhere else in the image. A signature or a passport photograph can in itself be attributed to a person so unambiguously that it deserves its own, stricter treatment than running text with a name hidden in it.

What eventually arrives at the model

If an attachment passes all these checks, what arrives at the model is not the original document but a version with the findings blacked out — including the people already known from the surrounding ticket, so that the same person is not pseudonymised in the ticket text while being visible in plain text in the attachment. This consistency between ticket and attachment is not a side effect but a deliberate aim: a redaction that was stricter in some parts of the same matter than in others could easily be circumvented by simply moving the same information into the part that is supposedly checked less thoroughly.

If the technical prerequisites for a check are missing altogether — for instance because a required tool is not installed on the machine in question — JiCo reports that openly as "not checkable", rather than quietly performing a weaker check and not making that visible. Which helper tools are present in each case, and what is blocked without them, can be looked up at any time in the built-in configuration check.

A stricter rule for a kind of data that deserves it

In the end there is a simple observation: an attachment is, in case of doubt, riskier than the ticket text itself, because it more often contains precisely the kind of document one would never want to pass on unchecked — a signature, an identity document, a payslip. A rule that therefore treats attachments deliberately more strictly than plain running text is not excessive caution, but the appropriate response to a kind of data that in practice disproportionately often contains exactly what the whole rest of the gate is meant to protect against.