How do I send documents with SSNs or PHI to an extraction API?

There are two different minimisations, and conflating them produces privacy claims that do not survive a question from a security reviewer.

Output minimisation is choosing which fields end up in your structured data. It is real and worth doing: if you never store the full Social Security number, it cannot leak from your database. Source minimisation is choosing which documents get sent at all. Only the second one reduces what the processor handles, because OCR and extraction operate on the entire page regardless of how narrow your schema is.

So when someone asks "does it see the SSN?", the honest answer for any document-extraction service is: the page was processed, so yes; whether the number lands in your output depends on your schema, and whether the source file is retained depends on the vendor’s retention practice.

Every other question is a variation on these. Get them from documentation you can link to, not from a sales call.

What is stored: source files, OCR text, extracted values, logs, and for how long each. Who can read it: which staff, which subprocessors, in which countries, and under what access controls. What happens on request: how deletion works, how long it takes, and whether it is self-service or operational.

For Dokyumi specifically, the public answers live on the security page: requests are served over TLS, uploaded files sit in Cloudflare R2 and extracted data in Neon Postgres, both encrypted at rest; document content is not used to train models; API keys are organisation-scoped and can be scoped further to specific schemas. Retention is deliberate rather than automatic — files, schemas and extraction records remain as part of account history unless a deletion request is processed, and self-service deletion is not currently available in the dashboard or API. If your workflow requires automatic or immediate deletion, confirm that operational process before you commit to it.

In the US, health information handled on behalf of a covered entity brings HIPAA into scope, and the de-identification standard at 45 CFR 164.514 defines what it takes for data to stop being protected health information — either an expert determination or the removal of a specified list of identifiers. That list is a good checklist even outside healthcare, because it enumerates exactly which values make a record re-identifiable.

For personally identifiable information more broadly, NIST SP 800-122 provides the confidentiality impact framework most US security teams recognise, and the FTC publishes plain-language guidance on data security expectations for businesses. None of this is legal advice, and the point is not to become a compliance expert — it is to know which questions your own counsel will ask.

Some privacy work is theatre. These four are not, ranked roughly by return.

• Do not send documents you do not need to extract. The largest reduction available is always at intake.
• Store the minimum in your own systems: last four digits instead of a full identifier, a match result instead of a copy of the document.
• Redact before upload when a workflow genuinely only needs part of a page, and confirm the redaction removed the content rather than drawing a black rectangle over it.
• Use scoped keys and separate environments so a test integration cannot read production documents, and rotate keys when people leave.