The average large US health system now runs 150 to 250 AI applications, up from fewer than 25 a decade ago (Elion AI Governance Playbook), and states introduced more than 280 bills on AI in health care in the first seven months of 2026 (Manatt Health AI Policy Tracker). Each application was approved on a risk assessment written for one version of the system, under the rules in force that day. When the model is retrained, the use case grows or a new law takes effect, that assessment describes a system that no longer exists.
Whether you run AI at a health system, a payer or a pharma company, you can govern it at this scale only if the analysis itself is automated and your people review what the software proposes. You can’t afford an expert in AI risk, regulation and implementation to re-review every system each time one of those inputs changes. Pacific AI is built on that premise, and this post shows how continuous risk assessment works, and the design rules behind it, so you can apply them to your own governance process.
Today’s Reality: Two staff and fewer than 3 decisions a month
Elion’s State of AI Governance report, based on interviews with leaders at more than 20 large US health systems, describes the capacity problem in four numbers:
AI project submissions outpace committee decisions nearly 3 to 2.
Most systems receive 4 to 6 new AI submissions a month, and half finalize fewer than 3 decisions.
Over 75% run the program day to day with two or fewer dedicated full-time staff.
More than 60% call their governance resources insufficient, especially for ongoing monitoring.
The queue runs into the hundreds. Brenton Hill, head of operations and general counsel at the Coalition for Health AI (CHAI), described some large health systems as reportedly holding 200 to 500 AI solutions in their procurement queue at once (Clearwater, July 2026). Clearing one takes two weeks to two months at most institutions in CHAI’s AI Intake Working Group, mostly spent chasing missing documentation (CHAI, October 2026). Payers reviewing prior authorization models, and pharma companies running AI in drug safety and trials, face the same queue. And all of these numbers count first assessments only.
Five changes that make an approved assessment out of date
An assessment ages because it covers one version of the system, at one point in time, under one set of rules – but all three keep changing. Five kinds of change call for a new review:
A new or amended law. On September 30, 2026 alone, California’s governor signed 13 more bills in the state’s AI package, including two on AI in health care, AB 1979 and SB 503. The AI Policy Suite, the open source library of AI laws, standards and frameworks that Pacific AI updates every quarter, grew from 250+ to 619 in the six months to September.
A change to internal policy, such as a new bias threshold for every clinical model.
A change to the system: a new architecture, data source, model or action.
A vendor update: a new model version, revised documentation or new AI disclosures.
A new use case, when a model approved for one department or population is deployed to another.
Today’s Challenge: 600 reassessments a year for 150 systems
An assessment is approved once, and the policy library behind it updates four times a year. As an illustration (the numbers are hypothetical), a health system with 150 AI systems and a policy library updated quarterly, with nothing else changing, needs 600 reassessments a year. A program that finalizes fewer than 3 decisions a month, as half of Elion’s health systems do, completes fewer than 36.
Most of those 600 checks would find nothing new, and someone still has to confirm that for each one. So the reassessment doesn’t happen, and the risk register (the list of each AI system’s risks, scores and controls) goes out of date one change at a time. Hiring more reviewers won’t close a gap of 600 against 36. Once building AI software got cheap, proving it works became the job, and reassessment is the part of that proof that repeats with every change.
Three practices that make continuous reassessment practical
Governor, the AI registry and risk assessment module of the Pacific AI platform, automates three practices: starting a reassessment from every change that can move a risk, reassessing only what changed, and showing you what moved.
Two triggers for every kind of change
A documentation trigger: uploading a new version of a system’s design document, functional description or code base queues a reassessment of that system.
A policy trigger: changing a policy, internal or from a quarterly Policy Suite update, queues a reassessment of every system the policy applies to. One policy change reaches every system it touches, so this trigger saves the most review time.
If a system already has a draft or a review in progress, the new run is skipped, so automation never collides with work a person has started.
Only the changed sections reassessed
The reassessment compares the new version with the previous one, finds the chapters or policy sections that changed, and evaluates only those. It proposes new risks, new scores where likelihood or impact changed, and mitigations, both technical and procedural, which you can edit and attach evidence to.
Six unacceptable risks down to three
Take a medical scribe, an AI system that drafts the clinical note from a doctor’s conversation with a patient. Governor scores each risk on a matrix of impact against likelihood, and the cell decides whether the risk is unacceptable, manageable, or needs an external auditor. Of the 15 risks in its register, six are unacceptable. After you upload a new architecture, the reassessment proposes three, and you see both matrices side by side. It also lists one newly found risk for you to approve or reject: the drafted note could contain hallucinated clinical statements that fall unevenly on some patient groups, and a 24-hour automatic filing job raises the chance that an unreviewed draft reaches the chart.
Three outcomes for each risk across versions
A reassessment that starts from scratch makes you repeat every decision you already made. Governor links each new version to its parent, the way a code repository links commits, so each risk keeps its history:
An approved risk gets re-scored. In the scribe example, biased triage output and unsafe escalation guidance both moved with the new configuration. Each kept its approval, title, description and controls, which the model can’t edit, and gained a “changed since review” flag while staying approved.
A rejected risk stays rejected. Patient subgroup underperformance was rejected as not applicable in version 3, so it’s left out of the LLM’s prompt and isn’t proposed again.
A new risk, the hallucinated note, arrives as a draft for you to approve or reject.
Every version records its trigger, and every change is marked as made by a person or by the system, so you can answer an auditor’s first question: who decided what, when, and for which version of the system.
Real-World Example: Two impersonation laws and the tasks they created
California AB 489, in force since January 1, 2026, bars developers and deployers of AI from using terms or letters that falsely indicate the AI holds a healthcare license. Delaware HB 191, signed April 23, 2026, bars an AI agent from using titles such as Doctor, Nurse, MD or RN.
When the Policy Suite added these requirements on its quarterly cycle, Governor reassessed every system they apply to, such as a patient-facing assistant or a scribe that drafts messages to patients. Each affected system received two tasks:
Test the LLM against the requirement before release in Gatekeeper, Pacific AI’s pre-release testing module, with the test suite built in.
Monitor for the same behavior in production with Guardian.
In a Pacific AI benchmark of AI impersonation from August, four frontier models answered 380 adversarial test cases drawn from 11 US laws, and none scored above 0.64, where 1.0 means every case handled correctly. You review and approve each new risk and task, on drafts from software that has read the current policy library.
Four design rules for auditable LLM drafts
Four design rules keep the drafts auditable, and they apply to any system like this one:
Patch only what changed: diff the new version against the old one.
Keep every human decision, stored with the version it applies to.
Use the LLM for judgment and deterministic code (code that gives the same answer every time) for rules, split as in the table below. No model output reaches the database unchecked: an answer that names an unknown risk or chapter is dropped, which costs a little recall and keeps the audit trail clean.
Run each reassessment once: the same parent and the same inputs make the same job, so a duplicate trigger can’t start a second run.
The model decides: which chapters changed; the severity and likelihood of a new risk; the text of the short summary; proposed controls for new risks. Code decides: the risk level, from the severity and likelihood matrix; which risks the model may touch (approved ones only); the facts in the summary: what changed, before and after; titles and controls of existing risks, which never change.
Reassessment does for AI what vulnerability scanning does for cybersecurity
When the last state law that applies to your AI took effect, how many of your systems were reassessed against it, and how long did that take?
When a vendor shipped a new model version, did your risk assessment of that product change?
For one system, can you show an auditor every change to its risks, who made it and when?
If the answer to the first is months, or none, your risk register describes systems that no longer exist. Without automated reassessment, a team of two that finalizes fewer than 3 decisions a month has almost no way to reassess most of its AI systems continuously, or even once a year. Every retrained model, vendor release and new law widens the gap between what was approved and what is running, so your risk goes up by the week:
Clinical risk from a model that now behaves differently with patients.
Financial risk from claims and payments built on outputs nobody rechecked.
Legal risk from requirements that took effect after approval and were never tested.
Reputational risk from an assistant that tells a patient it’s a nurse.
When a new software vulnerability is published, a security team’s scanners find every affected system and open a patch ticket for each one. Continuous risk assessment does the same for AI, which makes it a business requirement for any organization running AI at this scale: a new law becomes a short list of review tasks for each affected system, and nobody has to launch an enterprise project to find and test the systems it applies to. You can watch the workflow on screen in the Applied AI Summit session recording, and the Continuous Risk Assessment page has the product details.
Frequently asked questions
What is continuous AI risk assessment?
It updates an AI system’s risk assessment whenever something it depends on changes: a law, an internal policy, the system’s documentation or code, a vendor’s model, or the use case. Each change queues a reassessment of only the affected sections, and a person approves the result.
Does automated risk reassessment remove the human reviewer?
No. The software drafts new risks, scores and mitigation tasks, and a person accepts, edits or rejects each one. Earlier decisions are kept, so the reviewer sees only what moved.
How does one new law reach every affected AI system?
When a quarterly Policy Suite update adds a requirement, such as California AB 489, Governor reassesses every system the requirement applies to and assigns tasks such as testing the LLM in Gatekeeper and monitoring it in Guardian.
Do system documents and risk data leave my environment?
Governor installs in your own AWS or Azure environment, and documents, risk data and audit trails stay there. You can use an LLM hosted in the same environment, and airgap deployment is supported.
Does an updated risk assessment mean my AI system complies with AB 489 or HB 191?
No. A risk assessment and its test results are evidence for your compliance program and don’t determine compliance with any law. Consult your own compliance counsel.
Not legal advice. This post describes what two state laws say and how a governance platform can track them; organizations subject to these laws should consult their own compliance counsel. I’m CEO of Pacific AI, which built Governor and the continuous risk assessment described here.
The point that an approved assessment describes a system that no longer exists once the model is retrained is the part I'd expect most committees haven't faced yet. With new submissions already outpacing decisions nearly 3 to 2, re-reviewing the old ones by hand was never going to happen.
The new-population case is the one that slips past a calendar review. If the assessment is keyed only to the model name, pointing that same endpoint at another department looks like no change at all. Keying it to the serving route and the population filter puts that config edit in the reassessment queue before the new traffic starts.