Regulated AI is AI used where the workflow touches regulated data, regulated decisions, regulated records, or regulated professional duties. The label is less about the model and more about the operating context: what information enters the system, what action the AI influences, what record must be retained, and who must be able to prove the control later.

A chatbot answering generic questions is usually not regulated AI. The same model reviewing patient records, summarizing a broker-dealer file, drafting privileged legal work, triaging an insurance claim, supporting an IEP, or reconciling a payment record can become regulated AI because the workflow around it carries obligations.

Four ways AI becomes regulated

Teams often ask whether a specific model is “regulated.” The more useful question is whether the use case enters one of four zones:

If any one of those is true, the AI workflow needs controls. If more than one is true, it likely needs a formal governance path before production.

Examples by industry

Regulated AI shows up differently across sectors, but the pattern is consistent:

The common thread is not one statute. It is the need to show who did what, with which data, under which controls, and with what approval.

Regulated AI does not always mean forbidden AI

A regulated workflow is not automatically a blocked workflow. It means the bar changes. The organization needs to know which data is allowed, how the data is protected, who reviews the output, what record is retained, and how the control will be verified.

That is the difference between a pilot and a production system. A pilot can be manually supervised by a small team. A production workflow has to survive turnover, audit, incident review, vendor changes, and ordinary operational messiness. The controls must be part of the system, not remembered by the person who ran the demo.

How regulated AI maps to governance frameworks

Different frameworks use different vocabulary. HIPAA asks about safeguards and PHI. SEC Reg S-P asks about customer information. FERPA asks about education records. The EU AI Act asks about risk categories and obligations. NIST AI RMF asks organizations to govern, map, measure, and manage AI risk. ISO 42001 formalizes the AI management system.

The operational translation is simpler: define the use case, classify the risk, protect the data, approve the consequential step, monitor the system, and retain evidence. AI governance is the program that makes those steps repeatable.

Why evidence is the bottleneck

In regulated AI, the hardest question is often not whether the model can produce a useful answer. It is whether the organization can prove what happened after the answer exists. What data entered the path? Was sensitive data protected? Which policy applied? Who approved the result? Can the organization reconstruct the event later without relying on a vendor dashboard or someone's memory?

That is why a regulated AI architecture needs an evidence layer. Policies and dashboards can describe control. Evidence shows the control at the level of a specific request, workflow, or session.

What to ask before production

Before moving a regulated AI workflow toward production, ask five concrete questions:

If those questions have clear answers, the workflow may be governable. If they do not, the risk is not that the model is too weak. The risk is that the organization cannot stand behind the system after it works.


Frequently asked

No. A regulated company can use AI for low-risk internal work that does not touch regulated data, decisions, records, or duties. The use case matters more than the company label.
Not always. The more important questions are what data is sent, what agreement governs the provider, what controls protect the data, and what evidence proves the workflow behaved as approved. A private model can reduce some risks, but it does not replace governance.
Sometimes, if the workflow, data handling, provider route, contractual terms, approval gates, and evidence meet the organization's obligations. The model name alone does not answer the compliance question.
Start with the boundary around sensitive data and the approval gate before any consequential action. Those two controls determine whether the workflow can be tested safely and whether the organization can explain its operating posture.