Industries

Azure and AI for regulated industries

Every sector page here exists for one reason: something outside the technology has already decided part of the architecture. A regulator, a production calendar, a fiscal year that ends in March, a client's 200-line security questionnaire. Name that constraint first and the Azure design mostly follows from it.

The constraint is written before the architecture

Most industry pages on a consulting site are market segments. The same reference architecture, a different photograph, a paragraph about digital transformation. These five exist for the opposite reason: in each of them, something that is not a technology decision has already fixed part of the design, and pretending otherwise is what makes a project expensive.

In healthcare it is where patient data may rest and who may reach it. On a plant floor it is a machine commissioned years before the cloud existed, running a control system nobody is allowed to patch during a production run. In a public body it is a budget that expires on a fixed date and a team of four who will operate the result for the next decade. In a law firm it is that a document surfacing to the wrong matter is an ethical event, not a support ticket.

None of those are preferences. Each one decides concrete things: the subscription boundary, the region list policy will allow, the retention on the log workspace, whether a workload may reach the public internet at all, and how administrative access is requested rather than held. Written down in week one, they determine most of the architecture and cost nothing. Discovered in month three, they mean the foundation is rebuilt, which is the most expensive possible way to read a regulation.

Why these five and not fifteen

A sector page goes up here when two things are true: the constraint genuinely changes the build, and we have architecture-level experience of it rather than a commercial interest in appearing to. Where neither is true, the honest answer is that the service pages already describe exactly what we would do, and a sector page would be a landing page wearing a costume.

That is also why the five read differently from each other. Healthcare is about the data. Manufacturing is about the machines and the single site link. Financial services is about the examiner and the audit trail. Public sector is about procurement and who operates the result. Professional services is about confidentiality inside one tenant. Four of the five would fail if we applied the fifth one’s assumptions.

The five sectors

Healthcare carries the sharpest version of the problem. The data is the most sensitive category there is, the team holding it is usually smaller than the risk it carries, and the blocker is rarely a regulator: it is the first hospital or payer that sends a security questionnaire before signing. Answering that well is a revenue event.

Industrial and manufacturing is where cloud architecture meets equipment that predates it. Read this one if you have OT and IT on the same flat network, a site with a single internet link, and a patch window measured against a production calendar rather than a maintenance policy.

Financial services is not slow out of caution. It is slow because every decision has to survive an examiner, an institutional client’s due diligence questionnaire and an internal audit that will read the change log. The architecture either produces those answers on demand or somebody assembles them by hand for six weeks a year.

Public sector projects fail for reasons that are rarely technical: the person who buys is not the person who uses, the money expires, and whatever is delivered has to be operated for a decade by a small team. Read this one if you need an estate your own people can still run after the contract ends.

Professional services firms sell billable time and hold client confidence, which makes every tool decision unusually sharp. This is the sector where Microsoft 365 Copilot is most tempting and most dangerous, because the permission estate inside a single tenant is exactly where matter confidentiality quietly broke years ago.

What does not change between the five

The substrate is the same everywhere: a management group hierarchy with Azure Policy assigned above the subscriptions, Entra ID as the control point with time-bound administrative access, private endpoints on data services, logging with a stated retention, and every change arriving through a pipeline with an author and a reviewer. That is the Azure landing zone, and it looks much the same in a clinic and in a foundry.

Framework detail lives one cluster over. SOC 2, HIPAA, ISO 27001, Loi 25, GDPR and HDS are each translated into Azure configuration on the compliance pages, and the engagement that does the translating is compliance architecture. Where the question stops being “which control” and becomes “which jurisdiction, whose keys, and how long would it take us to leave”, that is sovereignty work and it is published as Novarque by Entrazure: the same team and the same standard, a different question. The build itself stays Entrazure work, whether it is a landing zone, a data platform or an agent.

Where a sector engagement starts

Almost always with the two-week assessment, because a sector constraint is only useful once it is checked against the estate you actually have rather than the one on the diagram. The output is a ranked backlog, and it is yours whether or not we do the remediation.

If the foundation is the gap, the four-week landing zone build is the next shape. If the pressure is a specific problem rather than a sector, the solutions pages are filed that way instead: an unexplained bill, a stalled AI pilot, a VMware renewal with a date on it.

If your constraint is not on this page, tell us what it is and we will say plainly whether it is work we should take.

Questions we get

Our sector is not one of the five. Does that mean you will not work with us?

It means the binding constraint in your sector is usually one the service pages already describe, and a sector page would add a photograph rather than an argument. Bring us the constraint you actually have. If it changes the architecture the way these five do, the page will eventually exist; if it does not, you are better served reading the landing zone and compliance pages directly.

Do you build the same landing zone everywhere and change the labels?

The substrate is the same and the parameters are not, which is the whole point. Management groups, policy, identity, private networking and change-as-code look alike in a hospital and a foundry. What differs is the allowed region list, the retention period, which services are permitted, how administrative access is granted, and what the pipeline has to prove. Those are the expensive decisions, and they come from the sector.

Who is accountable for the regulatory reading?

You are, and we make that easier rather than pretending otherwise. We design and build; we do not audit, certify or issue opinions on your compliance. Our architects hold information security certifications including CISM, and every framework interpretation is written down with the reason attached, so your auditor, your regulator or your client can disagree with one line instead of with a general claim.

Bring us the workload. We bring the architecture.

Thirty minutes, one architect, no deck. Come with a problem and leave with an opinion you can act on.