Regulated environments do not make AI impossible. They make ambiguity expensive. Unclear data boundaries, authority or action evidence can create review risks; actual findings depend on the system and applicable assessment. The work is to remove ambiguity before an assessor finds it.
Start with the boundary, not the feature
Before designing the AI capability, define the enclave: which data classes exist, where each is allowed to live, and which processing may occur outside it. For environments subject to NIST SP 800-171 or CMMC, sending controlled information outside the defined processing boundary may affect assessment scope; confirm applicable requirements with the responsible assessor.
Evidence is a first-class output
Agree purpose-limited evidence for each AI-touched workflow: safe references, model and configuration version metadata, review and disposition. Redact or exclude sensitive inputs, prompts and outputs; define access and policy-based retention. Evidence exports may support review but do not guarantee assessor acceptance.
Access control belongs in the database
Correctly configured and tested row-level policies can constrain ordinary client access across surfaces. Privileged services may bypass those policies: protect their credentials and verify actor, tenant and operation before each effect. Test all applicable paths rather than assuming a database policy proves universal isolation.
Constrain autonomy to what you can prove
In regulated work, AI-enabled with recorded human approval is an option to evaluate, not an automatic staging post. The approval step is not friction; it is the control that makes the workflow defensible, and it produces the evidence the next assessment consumes.
Be honest about scope limits
- Name the data classes the system will never process, and enforce it in schema and policy rather than in documentation.
- State model provider terms explicitly — training, retention, region — and keep the statement versioned with the system.
- Treat any capability you cannot evidence as out of scope until it can be evidenced.
In regulated systems, the evidence trail is not documentation of the architecture. It is the architecture.
Further reading
Primary references for relevant design principles, not evidence of DeftSpan deployment, certification or measured outcomes. Read these in context: general safety guidance cannot remove all risks, and privacy-risk guidance is not certification.