Production requirement · 03
Data boundaries
Clear rules on what leaves your environment, what is logged, who can see it and for how long — written down before the first model call.
AI systems touch more data than the feature they power: prompts, retrieved documents, traces, evaluation sets, reviewer notes. A boundary is the agreed answer to where each of those may live, who can read it and when it is deleted.
What it means to us
- A diagram before a deployment. Every engagement produces a data-flow diagram that names each store, each external call and each copy. If a hosted model is involved, the diagram shows what reaches it and under which contractual terms.
- Your cloud, by default. We build inside the customer’s cloud account with private endpoints wherever the provider offers them. When data must cross a boundary, the crossing is explicit, minimal and logged.
- Logs are data too. Traces are invaluable for debugging and dangerous when they contain the documents they describe. We separate operational metadata from content, redact where needed and set retention per store.
- Least privilege for people and agents. Tool permissions, service accounts and reviewer roles are scoped to the task. An agent that reads invoices cannot also send email unless the design says so.
- Retention is a decision, not a default. Each store has an owner and a deletion schedule agreed with the customer’s security and legal teams, and we verify the schedule runs.
What we deliver
The data-flow diagram; infrastructure code that enforces the boundaries (private networking, encryption, IAM policies); a retention and redaction policy; and a walkthrough for your security team.
What it is not
A boundary document is not a compliance certification. We work to your security team’s standards and produce the evidence they need; we do not certify against a framework ourselves.