Know where the information goes. Know who is responsible.
A private workflow needs an explicit account of data handling. “Private” should describe concrete accounts, processors, access paths, retention and responsibilities—not a general assurance or an unverified certification.
Written by the Fundamental View editorial team. Updated 28 October 2026. This page is an implementation checklist, not an independent security assessment, legal opinion or universal security guarantee.
Map operational information end to end
The described workflow includes intake through a personal interface or manually, anonymised document recognition, human review, Google Drive evidence storage and a structured Google Sheets register in the client's own Workspace. SQL migration or any additional processor requires a separately agreed design.
| Step | Facts to confirm | Responsible owner |
|---|---|---|
| Website enquiry | Form fields, CRM delivery, retention and privacy version | Client and website operator as agreed |
| Document intake | Accepted formats, account, original-file access and upload events | Named operational owner |
| Anonymisation | Fields masked, inspection method and treatment of metadata | Implementation and client reviewers |
| AI recognition | Provider, exact service, region, retention and input payload | Implementation lead; client approval |
| Human confirmation | Reviewer role, correction path and saved status | Client operations team |
| Evidence and register | Workspace ownership, sharing, export and support access | Client account owner |
| Exit and deletion | Export completeness, retention, deletion and residual logs | Agreed before operational use |
Anonymise before AI processing—and test the result
Names, account numbers and other identifiers are masked before a document reaches the recognition model. The intended model input contains figures, dates and structure rather than direct identifiers. Confirm the actual payload, including hidden text and metadata. Masking reduces exposure but does not prove that re-identification is impossible from unusual combinations of facts.
Agree account and access ownership
- Who owns the interface, storage and register accounts?
- Who can view, edit, export or share each class of record?
- What access does the implementation or support provider retain?
- How are staff departures, lost devices and access reviews handled?
- Can an authorised reviewer retrieve evidence without creating a public link?
Role definitions in a proposal must match controls in the configured tools. Document-level restrictions, activity history and approval logs should not be promised unless verified. Periodically test both permitted and denied access.
Define retention, recovery and exit
Identify records to retain, who sets retention periods and how deletion requests are handled. Agree backup responsibility, recovery procedures and limitations of third-party histories. Cover originals, extracted fields, prompts, outputs and operational logs separately where applicable.
An exit test should establish that record identifiers and evidence relationships survive export. A folder of documents without its register, or a spreadsheet without working source references, is not a complete handover.
Separate website enquiries from operational documents
The website form is for arranging a discussion, not document intake. Do not submit confidential records, passwords, wallet keys or financial evidence through it. The privacy notice covers website enquiry handling; operational documents require their own agreed scope and terms.
Procurement questions that require factual answers
- What is the contracted operator identity and who owns each account?
- Which model, hosting and support providers touch which data?
- Which regions and retention terms apply to the exact configuration?
- What support access exists, and how is it granted and revoked?
- Who is the incident contact, and what communication process is agreed?
- How are export, deletion and handover tested?
Do not infer SOC 2, ISO certification, legal compliance or an independent assessment from this page. No such claim is made here. Request evidence specific to the proposed implementation.
Related guides
- Review AI document confidentiality
- Inspect the document-to-record workflow
- Assign implementation and acceptance owners
- Define confirmation and exception states
Discuss your workflow
Describe the record-keeping problem you want to solve. Please do not include confidential financial information or documents in the enquiry.
Discuss implementation