Classifying documents and hiding the personal data in them

The problem

Edoclink handles large volumes of incoming documents for organisations that have to keep them, find them again, and share them without leaking anyone's personal data. Two jobs in that pipeline were still manual and both scale badly with volume. Deciding what a document is, and deciding what inside it must not be shown.

API one, classification

The first API takes a document and returns what kind of document it is, so it can be routed and filed without a person reading it first. That turns an inbox someone has to triage into something the system can sort on arrival.

API two, GDPR obfuscation

The second finds personal data inside a document and obfuscates it, so the document can be circulated, archived or handed to a third party without breaching GDPR. The interesting part is that the requirement is asymmetric. Missing a name is a data breach, while masking one word too many is merely annoying. That shapes every decision about where to set the threshold.

Working on something already live

Both had to integrate with a system that already had users, which meant the interface mattered as much as the logic. Predictable inputs and outputs, and failure modes that degrade instead of corrupting a document. It was my first time building against a codebase I did not own and could not reshape to suit me.

What I took from it

• Privacy requirements are engineering constraints, not paperwork bolted on at the end.
• An API into a live platform is a contract, and you get one chance to design it honestly.
• When the cost of the two error types differs this much, say so explicitly and tune for it.

This work is covered by the client's confidentiality, so there is no code or screenshot to show here. Happy to talk through the approach in detail, get in touch.