Obligation belongs to the organisation, not to the system
The most damaging sentence in this field says a given approach is compliant. Compliance is not a property of a system the organisation acquires; it is a condition of what the organisation does, and only the organisation can be in it. The useful contribution of engineering is narrower: it produces the controls, the evidence and the data handling that let a compliance function reach a conclusion.
The consequence is a change in who owns the work. The question is not whether a model can be used in a regulated process, but what obligations attach to that process, which of them are affected by introducing automated processing, and what evidence would let the organisation's own reviewers conclude that the affected obligations are still met. Those questions belong to the compliance and legal functions with the business owner.
Sensitive data changes what may be done before it changes how well it is done
Where the data is personal, financial, clinical or commercially confidential, some options are excluded before quality is discussed. The constraints worth writing down early are these.
- Where processing may occur. Which regions, which environments, and whether any part of the work can leave the controlled estate.
- Who may see the data. Whether it can reach a human at all, and if so which named roles, under which approval, with which record.
- How long the data is kept, and what happens to prompts, traces and derived artefacts, which are copies of the data.
- Which third parties are involved. Every supplier in the chain adds a party to the organisation's own obligations.
- Whether the use is disclosed to the people whose data it is.
These constraints determine whether a use case is possible, and they are settled with the compliance function and the data owner, not by the engineering team. Treating them as a late review step is the most common cause of a redesign late in a project.
Deployment constraints come before model choice
A great deal of effort is spent comparing models for a use case that the environment rules out. The efficient order is the reverse: establish where the work may run, what it may touch and what must be recorded, then choose the smallest component that satisfies those constraints, and only then consider how well it performs.
This ordering also reduces the size of the problem. Many use cases in sensitive domains are solved adequately by retrieval over approved sources with a narrow set of operations. Where a model is genuinely required, the constraints determine the deployment pattern: within the controlled estate, with restricted access to the grounding material, with inputs logged, and with outputs inspected before they count.
Validation and evidence are the real deliverable
In a sensitive environment, the artefact that matters is not the demonstration but the evidence. That evidence is specific and it is produced before go-live, not reconstructed afterwards. It includes the test cases the system was measured against and how those cases were drawn, the performance obtained on them, the known failure modes and the limits of the applicable population, and the review points with the criteria applied at each.
Two questions are asked about that evidence more often than any others. How were the test cases selected, and would a reviewer regard them as representative of the population the system will actually face? And who performed the validation, and with what independence from the team that built the system? A validation performed by the builders, on cases they wrote, with no stated population, is not evidence however much work went into it. The mechanics of building these cases are in continuous testing and change management.
Security controls apply to the data, not only to the endpoint
Security work in this area tends to concentrate on the interface: authentication, encryption of the connection, access control on the service. The larger exposure is in the data movement itself, and it is where controls usually stop. Data copied into a prompt, a trace or a log is data the organisation has placed somewhere new, and each of those locations needs an owner, a retention rule and an access policy.
The same applies to evaluation data. Sets built to test a system routinely contain the most sensitive material the organisation has, because that material is what the business works on, and they are often copied into a place with weaker controls than the systems of record.
Sector obligations have to be read, not inferred
Every regulated sector has its own specific requirements, and they differ in ways that matter operationally: retention periods, record kinds, consent and disclosure expectations, the independence of review, and what must be produced to an external party. These cannot be inferred from general principles, and this article does not state them. They have to be read in the source and translated into the obligations that attach to the activity being automated.
The translation is where most of the work is, and it is business work rather than legal work alone. An obligation to produce a record of a decision becomes an engineering requirement about what is captured; an obligation about human oversight becomes a requirement about a review point with criteria.
A sequence for a project touching sensitive data
- List the obligations that attach to the process as it runs today, with the compliance and legal functions, before any technical design.
- Classify the data involved and mark each field as usable, usable with conditions, or excluded, and record who decided.
- Decide where processing may occur and who may see the inputs, and treat both as architecture constraints.
- Write the validation plan: the cases, how they were drawn, the population, the criteria and who performs the review.
- Define the record that will evidence the activity, where it will live and who can read it.
- Agree the review that revisits those conclusions when the process, the data or the obligations change.
The measures that show the work is being done properly are dull and specific: the proportion of the data inventory that is classified rather than assumed, and the number of copies of sensitive data in places without an owner. The deployment discipline for keeping such arrangements in place is set out in enterprise AI deployment.
Where this method stops working
It stops working where obligations conflict with each other, or with the business objective, and where nobody in the organisation is willing to make that trade-off in writing. It also stops working where the data itself is undocumented: if the organisation cannot say what a field means or who owns it, the processing question cannot be answered at all.