Private AI guide
What is a private AI document workflow?
A private AI document workflow is an operating process that uses AI to read, compare, extract, draft, or route sensitive documents while keeping an explicit data boundary, approval path, and evidence record. Privacy is not defined only by the model: it also depends on storage, retrieval, tools, logs, reviewers, and where each component runs.
In practice: Use this framework to structure architecture and risk review around the actual workflow, data, and operating environment.
01
The workflow, not the chatbot, is the unit of design
A useful system starts with a bounded job: assemble a disclosure package, compare contract versions, prepare a quotation, classify an intake file, or populate a controlled form. The design should name the input, allowed sources, permitted tools, expected output, reviewer, release condition, and exception path before a model is selected.
That makes the system inspectable. A reviewer can distinguish source facts from generated proposals and can see why an item was blocked, escalated, or released.
- Defined input and source set
- Explicit extraction or drafting task
- Permitted tools and model routes
- Human approval and release authority
- Evidence and retention rules
- Fallback for missing or contradictory evidence
02
Seven stages of a controlled document flow
The exact implementation varies, but a production workflow commonly separates these stages so that each boundary can be tested and owned.
| Stage | Purpose | Evidence to retain |
|---|---|---|
| 1. Intake | Accept files from an approved channel and preserve originals. | File identity, source, time, hash, case owner |
| 2. Classification | Identify document type, sensitivity, language, and processing route. | Classifier version, result, confidence, override |
| 3. Retrieval | Select only the source material allowed for this job. | Query, source identifiers, access decision |
| 4. AI action | Extract, compare, summarize, or draft within the allowed scope. | Model route, configuration, prompt fingerprint, output |
| 5. Validation | Run deterministic checks and compare output with source evidence. | Rules, failed checks, citations, uncertainty |
| 6. Human review | Resolve exceptions and approve, edit, or reject the proposal. | Reviewer, decision, changes, reason |
| 7. Release | Export to the target system only after release conditions pass. | Released artifact, destination, time, approval chain |
03
What “private” should answer
A buyer should be able to get a concrete answer for every component: where documents are stored, whether retrieval text crosses the network boundary, which provider receives a prompt, where logs live, who can inspect them, and which service accounts can write to downstream systems. “On premises” answers only part of that question.
- Does the original file leave the customer-controlled environment?
- Can retrieved passages or prompts reach a hosted model?
- Are logs and reviewer notes customer-controlled?
- Can a provider retain or train on submitted content?
- Who operates keys, identity, updates, and backups?
- Can release occur without a named human or policy decision?
04
A practical pilot boundary
Start with one document family and one release decision. Use a representative but approved test set, define success and failure examples, and measure extraction quality, exception rate, reviewer time, and unsupported-claim rate. The pilot should produce a deployment diagram, evaluation set, exception catalogue, evidence sample, and go/no-go decision—not just a demo.
05
Sources
Primary references and technical material used in this guide.
- [1] NIST AI Risk Management Framework ↗
Risk ownership, measurement, governance, and lifecycle framing.
- [2] GDPR, Article 25 ↗
Official text on data protection by design and by default.
- [3] Cynsta AAP specification ↗
First-party open format for portable AI action evidence.
Continue reading