Trace one document through the system
Start with a representative workflow, such as turning a client file into a reviewed chronology. Draw every place its content can go: upload storage, OCR, extracted text, embeddings, search index, prompt, answer, logs, and export.
For each store, record its owner, location, permitted readers, retention period, encryption key owner, and deletion mechanism. Include crash reports, support bundles, temporary files, and backups. These are easy places to lose the boundary.
An embedding is a derived representation, not proof of anonymization. A local model does not make a hosted OCR service or an external tracing endpoint local. Each component needs its own decision.
Enforce identity before retrieval
Authenticate the user at the application boundary and carry the authorized tenant or matter scope through every query. Apply document permissions before retrieval results enter the prompt.
Instructions to the model are not an access-control mechanism.
Use separate credentials for ingestion, retrieval, inference, and administration where practical. A worker that reads approved documents should not automatically have permission to export every record or alter retention settings.
Test with two synthetic matters and two users. Give each matter a unique marker. A request from one user must not retrieve the other marker through search, direct identifiers, conversation history, or cached results.
Test network egress under normal and failed conditions
Install the approved models and dependencies, then run the workflow with external egress blocked. Record allowed local dependencies explicitly: a database or identity service inside the boundary is still a dependency.
Exercise startup, document parsing, inference, export, retries, and a forced error. Check network observations for unexpected DNS lookups and outbound connections. Error reporting deserves the same attention as the successful path.
Some workflows intentionally use email, a hosted EHR, or an external API. Specify the exact payload, destination, authorization, and review step for each exception. A failed external step should not silently switch to a different provider.
Deletion is a sequence of operations
Deleting the uploaded PDF may leave extracted text, vector entries, cached prompts, generated answers, and restored backups. Define the deletion sequence for every derived store and record when each operation completes.
Use a synthetic record to test the sequence. After deletion, search by identifier and content, retry an old conversation, and inspect retained copies according to policy.
Restore a backup in isolation and verify how deletion records are reapplied.
Encryption protects stored bytes only within its threat model. Key destruction also depends on key copies, recovery arrangements, and snapshots. Apple Platform Security is a platform reference, not a certification of the assembled workflow.
Make the boundary an acceptance test
Keep the data-flow map, access matrix, egress exceptions, retention schedule, and test results with the deployment. Assign an owner to approve changes in models, integrations, support access, and backup destinations.
Repeat the tests when those components change. The deliverable is a boundary the team can demonstrate: where the data went, who could read it, what remained afterward, and how the system behaved when a dependency failed.
Frequently asked questions
Is blocking internet access enough?
No. It tests external egress but does not establish internal access isolation, safe logs, deletion, backup handling, or correct outputs.
Can a private workflow use external integrations?
Yes, if each transfer is explicitly scoped and approved. Describe the actual boundary rather than claiming the entire workflow is offline.