On-premise or API for document masking?

When document masking reaches a security review, the reflex is on-premise. Nothing leaves the perimeter, nothing to explain in the risk register, no vendor in the data path. It feels obviously safer.

Sometimes it is. Often the reflex is answering a question nobody asked precisely, and it turns out to cost more than the risk it removes. We sell the API, so treat the framing with appropriate suspicion — but the questions below are the ones that decide it, and two of them can go against us.

Question 1: what are you actually protecting against?

"Documents leaving our network" is a shape of concern, not a threat. Made specific, it usually resolves into one of these:

The real concern	Does on-premise address it?
A vendor retains our documents and is breached	Yes — but so does a vendor that stores nothing. Verify the claim rather than assume it (see below).
Documents cross an international border	Yes — and so does any vendor processing in-country. Ask which region, and get it in writing.
A regulator requires in-perimeter processing	Yes, and this is the one case that genuinely settles the question. If it applies, stop reading.
Interception in transit	No better than TLS does. This concern is usually about storage wearing a transit costume.
Vendor employees viewing documents	Yes — but if the vendor never writes documents to disk, there is nothing to view.

Only the third row is decisive on its own. The rest are answerable by a hosted service that is built correctly, and the way to find out is to ask specific questions rather than to accept a category judgement.

Question 2: what does on-premise actually cost you?

This is the part that tends to be under-counted, because the cost is not licensing.

• OCR is not a dependency you install and forget. Detection quality on real Indian documents — laminated cards under glare, phone photos at an angle, twenty-year-old scans — is the whole product. It is tuned continuously.
• The failure modes are subtle. A masker that misses a rotated card does not error; it returns the document unchanged with a success status. Nobody notices until an audit.
• You own the identifier catalogue. New identifier formats, changed printing conventions, the VID that half of in-house implementations still do not know about — all yours.
• Someone must own it in year three. The person who built it will have moved teams. Internal tools with no owner are how a masking step silently stops working.
• Capacity is yours. OCR is CPU-hungry and bursty. Provision for the month-end peak and idle the rest of the time.

Against a hosted call, that is a genuine engineering commitment. Institutions that make it deliberately, with an owner and a budget, do fine. Institutions that make it reflexively in a security review usually end up with an unmaintained script and an unwarranted sense of safety.

Question 3: what does the hosted option actually do with your documents?

This is where the decision should be made, and it is the question most reviews skip in favour of the category judgement. Ask for specifics:

• Is the document written to disk at any point? Not "do you retain it" — retention policies describe deletion. Ask whether a file is ever created.
• What exactly is logged per request? Ask for the field list. A vendor who cannot produce one on request does not know.
• Which region processes it? Name the region, not the country.
• Are extracted values ever returned in headers or logs? A response header carrying the identifier just redacted puts it into every proxy log between you.
• Is the redaction reversible? If PDFs are not rasterised, the text layer survives and the whole exercise is decorative.
• Can access be scoped? If your plan covers masking, can the credential reach an extraction endpoint that returns the number in the clear? It should not, and it should be enforced rather than promised.

The hybrid nobody considers

The choice is usually posed as all-or-nothing, and it need not be. Document processing splits cleanly:

• Masking and redaction transform a document and hand it straight back. Nothing needs to persist, so a correctly built hosted service holds no state at all.
• Extraction returns identifier values, which is a genuinely different sensitivity. Some institutions are comfortable with the first and not the second.

If your API access can be scoped per endpoint, you can buy masking without buying extraction and keep any identifier-returning step inside your own perimeter. That gets you the maintained detection where it is hardest, and keeps the part your security team actually objects to at home. It is worth asking for even where it is not advertised.

What actually settles it

If a regulator or a contractual obligation requires in-perimeter processing, that decides it and no vendor answer changes it.

Otherwise, the honest comparison is between a hosted service that never writes your documents down and processes them in your own jurisdiction, and an in-house implementation whose detection quality you now own forever. Framed that way, the answer differs by institution — and either answer is defensible when it was reached by asking the six questions above rather than by category reflex.