AI workloads change the data governance requirement most sharply
Hosting asks where data sits. AI asks what reached it, what was sent, and whether that can be evidenced eighteen months later.
Azure · Healthcare
Building for AI on regulated infrastructure
An estate designed for hosting usually needs rework before it can support AI workloads safely. This paper sets out what changes and why designing for it now is cheaper.
Abstract
Building for AI on regulated infrastructure
Summary
Most healthcare Azure estates were designed for hosting: move the workload, keep it running, keep it compliant. AI workloads change the requirements underneath in ways that are cheap to design for and expensive to retrofit.
This paper examines what specifically changes — network, identity, data governance, residency and evidence — and argues that organizations with AI anywhere on a three-year plan should be making these decisions now, in the ordinary course of estate design, rather than as a separate programme later.
Key findings
Four things this paper argues
If you read nothing else, read these. The analysis that follows sets out the evidence for each.
Private networking is materially cheaper to design than to retrofit
Retrofitting private endpoints onto a workload built with public access touches every connection string in every component.
Evidence has to be enforced by policy, not configured by hand
Manual diagnostic settings cover what existed on the day somebody applied them and nothing created since, which is the resource that will matter.
Customer-managed keys are frequently assumed rather than required
They add genuine operational burden including a recovery position most teams have not worked through. Confirm the obligation in writing.
Analysis
The argument in full
What actually changes
A hosting estate answers a stable set of questions: is the workload available, is the data encrypted, is access controlled. An AI-supporting estate answers a moving set: what data did the model reach, what left the boundary, who authorised the connection, and can any of that be reconstructed later.
In a healthcare setting the last question is the one that determines whether the programme is defensible. Microsoft's data security posture management for AI exists precisely because organizations could not answer it, and its presence in the platform is an argument for designing the evidence layer deliberately rather than assuming it.
The practical consequences are network isolation, identity design that supports segregation of duties, data classification applied before AI reaches the content, and diagnostic logging enforced by policy with retention matched to the regulatory window rather than to the default.
- Private endpoints with resolved private DNS, and public network access denied by policy
- Managed identities rather than stored credentials in application configuration
- Data classification applied before AI workloads reach the content, not afterwards
- Diagnostic settings enforced by policy, capturing data-plane as well as management-plane activity
- Log retention matched to the regulatory window and query-tested at its far edge
The residency question, raised early
Data residency requirements should be documented per workload rather than organization-wide. A blanket position produces either over-restriction — ruling out services the organization could have used — or an assurance that does not hold for a specific data type.
This should be raised in the first design conversation rather than at contract stage. It is far cheaper to design for than to retrofit, and it occasionally changes which services are viable at all, which is information you want before an architecture is committed.
Why now rather than later
The argument is not that every healthcare organization should deploy AI. It is that the estate decisions which make AI safe are the same decisions that make a regulated estate defensible generally, and they are being made anyway.
An organization choosing private networking, policy-enforced logging and proper classification today gets a better estate whether or not the AI programme proceeds. An organization deferring those choices and later deciding to proceed pays for the same decisions under time pressure, with workloads already in place.
That asymmetry is the whole argument of this paper.
Framework
Something you can apply without us
Every paper in this series ends with a framework you can run internally. We would rather you used it and reached your own conclusion than took ours on trust.
Framework
Designing for what comes next
Five design decisions that pay whether or not the AI programme proceeds.
1
Isolate
Private endpoints and private DNS from the start; public access denied by policy.
2
Identify
Managed identities and just-in-time privileged elevation rather than standing access.
3
Classify
Sensitivity applied to content before any AI workload reaches it.
4
Evidence
Diagnostic settings by policy, data-plane included, retention matched to the regulatory window.
5
Map
A control-to-configuration document linking each obligation to the setting implementing it.
Implications
What this means, depending on your seat
The same argument lands differently across an executive team. These are the three versions worth separating.
References
Where to check this for yourself
Microsoft's own documentation for the product behaviour described above. We would rather you verified the basis than accepted our summary of it.
01
Azure Private Link and private endpoints
02
Managed identities for Azure resources
03
Azure Policy effects
04
Azure Monitor diagnostic settings
05
Microsoft Purview data security posture management for AI
On these references: each entry names a Microsoft Learn article or documentation area by title, because deep links change while titles are stable. Searching the title on learn.microsoft.com will reach the current version. Where we have cited a figure or a product behaviour, it is Microsoft's statement rather than ours; where we have given a number of our own it is labelled as such in the text.
Recognise the situation?
We will map your control obligations to a target Azure design and produce the evidence structure alongside it, before any AI workload is built.
Discuss this paper Run the related checklist We reply to every message within one business day.
Keep reading
Related papers
Information governance as an AI prerequisite
An examination of why AI deployments in provider organizations pause, and what the sequencing should be instead.
July 19, 2026 · 16 pages · 17 min readRead
Service line economics and the allocation problem
The annual service line dispute is not an arithmetic problem. It is a participation problem, and it has a structural solution.
May 3, 2026 · 15 pages · 16 min readRead
Clinical continuity and the recovery objective
The question is not how long until systems are restored. It is how long the organization can deliver safe care without them.
November 30, 2025 · 14 pages · 15 min readRead