Building with regulated data: what actually changes

Why the pilot worked and the real thing stalled

The prototype ran on an extract. Someone pulled a sample to a laptop, or generated synthetic records, or used a public dataset that looked close enough. It worked well enough to get funded. Then the project pointed at the real system of record and stopped — not for a week, for a quarter — inside a security review nobody put on the schedule.

The usual diagnosis is that compliance slowed the project down. That is almost always the wrong read. What actually happened is that four decisions got made implicitly during the prototype, by default, by whoever was moving fastest: where data is processed, how long each copy lives, where access is enforced, and what the system writes down. Choosing any of those deliberately at the start costs an afternoon. Changing any of them after data is loaded and copies have been derived costs a rebuild. Regulation did not slow the project. Deferred architecture did.

The four constraints look like paperwork and behave like architecture: residency, retention, access control, and audit trail. Which statute names them depends on whose data you hold — HIPAA for health information, the FTC Safeguards Rule for consumer financial information, the Privacy Act and NIST guidance for government data — but the engineering consequences converge to roughly the same short list.

Residency: where the inference actually happens

Most teams answer "where does our data live" by naming a cloud region and stopping. Once a hosted model sits in the request path, that answer is incomplete, because inference is a second processing location — and it is frequently selected from a dropdown that nobody treated as a policy decision.

A concrete, documented example. Microsoft's data, privacy, and security documentation for Foundry Models sold by Azure describes deployment types labeled "Global" and "DataZone." For a Global deployment, prompts and responses "may be processed in any geography where the relevant model sold by Azure is deployed." For a DataZone deployment, processing is confined to geographies within the specified data zone. Data stored at rest remains in the customer-designated geography in both cases. That is a clear and honest description from the vendor — and it means an engineer who picks Global for capacity or latency has made a residency decision inside a deployment configuration, probably without telling the privacy office.

The second, less obvious point: the vendor's own safety pipeline is a processing activity too. The same documentation explains that abuse monitoring may select a sample of prompts and completions for review, stored in a data store logically separated by customer resource and reachable by authorized Microsoft employees through just-in-time approval — unless the customer has been approved for modified abuse monitoring, in which case that storage and human review is not performed. Microsoft states separately that prompts and completions are not used to train or improve the base models.

None of that is alarming; it is ordinary, documented cloud processing, and other vendors publish comparable terms. The discipline is to read them, record the result in the privacy impact assessment, and make the control mechanical: pin the region and deployment type in infrastructure-as-code and assert it in CI, rather than writing "data remains in region X" into a document a config change can silently falsify.

What goes wrong: the residency claim in the assessment and the residency behavior of the running system drift apart, and nobody notices until an auditor reads both in the same week. For workloads where the answer has to be "nowhere but here," the design conversation moves to air-gapped and disconnected deployment, which is a different cost structure entirely.

Retention: three clocks that disagree

Retention reads like a policy question until you notice that several regimes can run different clocks over the same system, and some of them point in opposite directions.

• Consumer financial data. The FTC's Safeguards Rule requires covered financial institutions to develop and maintain procedures for secure disposal of customer information "no later than two years after the last date the information is used" in connection with the product or service — subject to exceptions for legitimate business purposes, other legal retention requirements, and cases where targeted disposal is not reasonably feasible (16 CFR 314.4(c)(6)).
• Government records about individuals. The Privacy Act requires agencies to keep an accounting of certain disclosures for five years or the life of the record, whichever is longer (5 U.S.C. 552a(c); see the Justice Department's overview of that subsection). Notice the shape of that requirement: the log about the record can be obligated to outlive parts of what it describes.
• Government records generally. Under 44 U.S.C. 3301, recorded information created or stored in digital or electronic form can be a federal record, which means it needs an approved disposition schedule (see the National Archives on disposal of records). You are not free to simply delete it, and you are not free to simply keep it.
• Health data held by a vendor. A business associate agreement must require the business associate to return or destroy all protected health information at termination where feasible — 45 CFR 164.504(e)(2)(ii)(J), per HHS's business associates guidance.

Set aside which clock applies to you. The engineering consequence is the same in every case: deletion has to be a real operation, and it has to reach derived data.

That second clause is where AI systems break. A record deleted from the system of record leaves descendants — an embedding in a vector index, a row in a fine-tuning set, a cached retrieval result, an evaluation fixture, a prompt-and-completion pair in an observability tool, a nightly export somebody scheduled and forgot. If you cannot trace a subject or record forward to every artifact derived from it, you cannot honor a deletion request, a disposition schedule, or a return-or-destroy clause. You can only assert that you did, which is a different thing and reads as such in an audit.

The inexpensive version of the fix costs almost nothing at the start: carry a stable source identifier and source-system reference into every derived artifact — vector metadata, training rows, eval fixtures, cache keys. The expensive version is backfilling identifiers into an index you already built at scale, which in practice means rebuilding it.

What goes wrong: the vector store gets treated as a cache. It is not a cache. It is a copy, and it inherits the obligations of whatever it copied.

Access control: enforce at the data, not in the app

Retrieval systems make an old mistake newly dangerous. If a retriever builds its filter in application code and runs every query under a shared service account, then the confidentiality of each regulated row depends on that filter being correct in every code path — including the code paths shaped by user input. Putting a model in the loop widens the blast radius, because retrieved text sits close to instructions; a filter bug and a prompt injection produce the same outcome.

The pattern that holds up is to enforce below the application: row- and column-level policies evaluated by the query engine or the governance catalog — warehouse row-access policies, attribute-based rules in a catalog, policy-as-code at the query boundary — with retrieval executing under the end user's identity rather than a service principal. Then "could this user have seen that row" is a property of the platform, answerable without reading your prompt-assembly code.

HIPAA's technical safeguards point the same direction. 45 CFR 164.312(a) requires access control including unique user identification. A retrieval service that queries everything as svc_rag does technically have a unique identity — it just is not the identity of the person who received the answer, and that second identity is the one an investigator will ask about.

The trade-off is real. Per-user retrieval defeats a shared cache, raises tail latency, complicates prefetching, and makes evaluation harder to reproduce. Teams take the service-account shortcut because it is faster, not because they are careless. The point is to take it knowingly, in a system where the data cannot hurt anyone — not to discover in month six that unwinding it means re-architecting retrieval under deadline.

If the data in question is controlled unclassified information, NIST SP 800-171 Revision 3, published May 14, 2024, is the requirement set for nonfederal systems and is structured to align directly with SP 800-53 Rev. 5 controls. It is worth reading before the access model is designed rather than during the assessment. Defense programs layer their own environment rules on top; our companion piece on DoD impact levels covers where those bite.

Audit trails: log references, not payloads

The HIPAA audit-controls standard is a single sentence, and the verbs carry the weight: "Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information" (45 CFR 164.312(b)). Record and examine. A log that nobody can query is not an audit trail; it is storage with good intentions.

AI systems create a specific and avoidable failure here. The instinct when debugging an LLM feature is to log everything — the assembled prompt, the retrieved chunks, the completion. Do that in a regulated system and your observability platform now holds a copy of regulated content, under different retention rules, different access controls, and frequently a different vendor agreement than the database it came from. That is not an improved audit posture. It is a second system of record with weaker governance than the first, created by a well-meant pull request.

The discipline that survives review is to log references, not payloads. Record the requesting identity, the policy decision and which rule permitted it, the identifiers of the documents or rows retrieved, the model and version, the prompt-template version, and the outcome. That is enough to reconstruct who saw what, under what authority, and why the system produced what it produced — without duplicating the content. When payload capture is genuinely necessary, during an incident or for a targeted evaluation, treat that store as inheriting the classification of its source: same access rules, same retention clock, same deletion path.

The vendor boundary is inside your boundary

One piece of HHS guidance settles a surprising number of internal arguments: a cloud service provider that stores only encrypted electronic PHI, and does not hold the decryption key, still meets the definition of a business associate. Encryption reduces risk. It does not remove a party from the compliance perimeter. HHS's broader cloud computing guidance works through the rest of that analysis.

Apply the principle to a current AI stack and the list of parties gets long: the model provider, the vector database, the tracing vendor, the evaluation platform, the error-reporting SDK, the feature-flag service that receives user attributes. Every component touching regulated data in the request path needs a paper answer — a business associate agreement, a data processing agreement, a place inside an authorization boundary — and the paper is usually the long pole, so it starts in parallel with the build, not after it.

What goes wrong: the model provider gets a signed agreement because it is the obvious one, and the tracing vendor gets added with a package install because it is not.

What to decide in the first two weeks

None of this requires a governance committee before the first commit. It requires five decisions made explicitly and written down where an engineer will actually see them:

1. Classify the fields before you design the schema. Which columns are regulated, under which regime, with what disposition. An afternoon at a whiteboard that constrains every decision downstream.
2. Pin the processing geography — region and model deployment type — in infrastructure-as-code, and assert it in CI so a config change cannot silently move it.
3. Carry a stable record identifier into every derived artifact, including embeddings, evaluation sets, and caches, so deletion remains possible later.
4. Pick one enforcement point for access, put it below the application layer, and make the application incapable of bypassing it.
5. Choose references-not-payloads for logging, and decide in advance what an incident-time exception looks like and how long it lives.

And a boundary in the other direction, because over-correction is its own failure. Classifying everything at the highest sensitivity does not make a system safer. It makes the data unusable, and unusable data pushes competent people toward laptop extracts, personal drives, and shadow copies — precisely the outcome the controls exist to prevent. Governance that engineers route around has negative value. The target is a system where the compliant path is also the shortest path, which is an engineering problem more than a policy one.

Sources: Microsoft Learn — Data, privacy, and security for Foundry Models sold by Azure; FTC — Safeguards Rule and 16 CFR 314.4; 5 U.S.C. 552a and DOJ Office of Privacy and Civil Liberties — Accounting of Certain Disclosures; 44 U.S.C. 3301 and National Archives — Disposal of Records; 45 CFR 164.312; HHS — Business Associates, HHS FAQ 2076, and HHS — Guidance on HIPAA & Cloud Computing; NIST SP 800-171 Rev. 3. Confirm the current text of any statute, rule, or vendor term against the primary source before acting on it. Analysis and framing by Precision AI Academy; this article is engineering guidance, not legal advice.

Common questions

What changes when an AI system moves from sample data to regulated data? Four decisions stop being implementation details and become architecture: where processing physically happens, how long every copy may live, where access is enforced, and what the system can prove after the fact. Each is inexpensive to choose deliberately at the start and expensive to change once data has been loaded and copies have been derived.

Why is a vector index a retention problem? Because it is a copy, not a cache. Embeddings, fine-tuning sets, cached retrieval results, evaluation fixtures, and logged prompt-completion pairs all descend from the source record and inherit its obligations. If you cannot trace a record forward to every artifact derived from it, you cannot honor a deletion request, a records disposition schedule, or a return-or-destroy clause.

Should a retrieval system query under the end user's identity or a service account? Under the end user's identity where regulated data is involved, with row- and column-level policy enforced by the query engine or catalog rather than by application code. Service-account retrieval is faster and cache-friendly, but it makes every regulated row depend on an application filter being correct in every code path, and it means the audit log records the service rather than the person who saw the answer.

Should you log full prompts and completions in a regulated system? As a default, no. Logging full payloads creates a second copy of regulated content inside an observability platform that usually carries different retention rules, different access controls, and a different vendor agreement. Log references instead — request identity, policy decision, retrieved document identifiers, model and version, outcome. If payload capture is genuinely needed, that store inherits the classification of the source.