

Designing document AI before the model could run locally
DocRobot was an enterprise workspace for teams whose documents are confidential enough that legal will not let them near a hosted model. So it started from a rule rather than a feature: nothing leaves the machine unredacted. Every other decision followed from that one.
In practice it meant redaction was the first step in the flow rather than a setting somewhere in preferences. In the working POC that was manual search-and-redact, which is slow and unglamorous and was the reason a security review could pass at all. Later iterations detected names, dates and account numbers automatically. The document stayed on screen throughout and answers were grounded in it, so a team could trace any response back to the page it came from.
The whole shape of the product was a workaround. The model was somewhere else, so the content had to be cleaned before it could go there.
That constraint has since dissolved. A capable model now runs on the machine, and the rule that organised the entire design โ the model must never see this โ no longer applies.
The obvious conclusion is that the redaction work becomes unnecessary. That turns out to be wrong, and it's the part worth writing down.
The risk was never that a model saw the content. It was that the content crossed a boundary. When inference happens on the user's machine, the boundary stops being the network call and becomes the export: what gets copied out, pasted into a ticket, attached to an email, shared with a colleague who isn't cleared for it. So the redaction craft doesn't disappear when local inference arrives. It moves to the export step. Same work, different position in the flow.
What genuinely changes is scope. When the model can only see what you have manually cleaned, the unit of work is one document. When it runs locally against everything, the unit becomes the whole corpus โ and that, rather than convenience, is what local inference actually unlocks. The product stops being a way to ask questions about a file and becomes a way to ask questions about everything you have.
I should be clear that the second half is a design proposition rather than something shipped. The POC and its results were real; the corpus version is a rebuild I've drawn and not delivered.
The transferable part is smaller than the story. When a technical limitation lifts, the thing it was protecting doesn't stop needing protection โ so the useful question isn't what you can now remove, it's where the boundary went. Most of the time it has just moved somewhere less obvious, and the design that used to guard it is now guarding nothing.
Related: design the failure state first, and how I work.