Privacy decisions made after the architecture is built are expensive to reverse and usually get downgraded to disclaimers. The questions below belong in your first design session, not your compliance review.
This is the checklist I use.
Before you write code
- What's the minimum data this feature needs? Not what's available — what's necessary. Every additional field is a liability you're choosing to carry.
- Where will this data live, physically? Data residency is a hard requirement in a growing number of markets. Retrofitting regional hosting is a rebuild, not a config change.
- Does the model provider train on our inputs? Read the actual terms, not the marketing page. Confirm the setting, and confirm it in writing.
- What's the retention period, and who enforces it? "We keep logs" without a deletion policy means you keep everything forever.
- Can we delete one user's data completely? Including from vector stores, caches, logs, and fine-tuning sets. This is where most deletion promises quietly fail.
During the build
- Is PII stripped before it reaches the model? Redaction at the boundary is cheaper than explaining a leak.
- Are prompts versioned and logged? You need to reconstruct what the system was told when it produced a given output. This is an audit requirement and a debugging necessity.
- Is every AI action attributable? Who triggered it, on what data, at what time, with what output.
- Are high-stakes actions gated? Anything irreversible or externally visible should wait for a person.
- Can an administrator switch the AI off without breaking the product? If AI is load-bearing with no fallback, you've built a single point of failure with regulatory exposure.
Before you ship
- Can you explain a specific decision to a specific user? In plain language, referencing their actual data.
- Is there a documented data flow diagram? Every enterprise security review will ask. Having one ready shortens the sales cycle considerably.
- What's the breach response plan for AI-specific failures? Model leakage and prompt injection aren't covered by a standard incident playbook.
- Have you tested prompt injection? If your system ingests user-supplied or third-party content, assume someone will try to hijack it.
- Does the exit path work? Customers should be able to export their data and leave. Being able to say so honestly is a sales asset.
The principle underneath
Privacy isn't a constraint on AI products. It's the thing that makes them deployable.
Every enterprise deal I've watched stall has stalled at security review, not at the demo. The products that clear that review quickly weren't the ones with better privacy documentation — they were the ones where privacy was a build constraint from the start, so the documentation just described what already existed.
At Xwits, this is codified: client data stays in the client's region, we don't train on it, every action is auditable, and the client can export and leave at any time. Those aren't compliance features. They're the reason the conversation gets to a contract.
Where teams go wrong
They treat privacy as a legal deliverable rather than an engineering one. Legal writes a policy describing what the team promises to do. Nobody checks whether the architecture makes it possible.
The gap between the policy and the system is where breaches and failed audits live.
FAQ
What is privacy by design for AI products? Making privacy decisions — data minimization, residency, retention, deletion, auditability — architectural constraints during the design phase rather than adding controls after the system is built.
Does the model provider train on our data? It depends on the provider and plan. Check the actual contractual terms, confirm the setting in your account, and get it in writing before sending sensitive data.
What's the hardest privacy requirement to retrofit? Complete deletion. Once user data has propagated into vector stores, caches, logs, and training sets, guaranteeing full removal is difficult without an architecture designed for it.
Why do enterprise AI deals stall at security review? Because privacy was treated as documentation rather than architecture. The policy promises things the system can't actually do.
I'm Ravi Jadav, Chief Product Officer and Co-Founder at Sunbots Innovations and Co-Founder at Xwits Developers. If you're building AI on sensitive data, get in touch.