--- title: "The AMA Says Clinical Authority Is Earned. That Is an Infrastructure Bill." slug: "ama-agentic-ai-governance-framework-clinical-authority-evidence" author: "ibl.ai Engineering" date: "2026-10-19 12:00:00" category: "Premium" topics: "AMA agentic AI framework, healthcare AI governance, clinical AI oversight, patient safety, HIPAA audit trail, agent permissions, evaluation pipelines, self-hosted healthcare AI" summary: "The American Medical Association published a governance framework for agentic AI on 13 October 2026, built on the principle that clinical authority is earned through evidence and maintained through demonstrated performance. Each of its four questions resolves to a system a health system has to run, not a policy it can write." banner: "" thumbnail: "" linkedin: | On 13 October 2026 the American Medical Association published a governance framework for agentic AI taking on clinical functions. Its organizing principle is one sentence, and it is the part worth arguing about: clinical authority should be earned through evidence and maintained through demonstrated performance. Read that twice. Not approved once. Maintained. Authority that can be revoked when the evidence stops supporting it. The framework then asks four questions. Function: what clinical function is the AI performing. Evidence and risk: what demonstrates it can perform that function, and what happens if it fails. Authority and oversight: what should it be permitted to do, and under what conditions. Accountability: who is responsible for the risks and outcomes. Every one of those reads like a policy question. Every one of them resolves to a running system. "Maintained through demonstrated performance" is a monitoring pipeline. "Under what conditions" is a conditional permission model tied to your identity provider, not an admin/user toggle. "Who is responsible" is an audit trail complete enough to reconstruct an interaction months later, which in healthcare means the log itself is protected health information. This is a framework from the AMA's digital health work, not adopted policy and not regulation. Nobody is enforcing it this quarter. That is precisely why it is useful now: it describes the shape of the capability before anyone is grading you on it. The gap it exposes is not a policy gap. Most health systems can write the policy this week. They cannot produce the evidence, because evidence is a thing a platform emits. #iblai #HealthcareAI #AIGovernance #PatientSafety #ClinicalAI --- ## The Short Answer **The American Medical Association published a governance framework for agentic AI on 13 October 2026, organized around the principle that clinical authority is earned through evidence and maintained through demonstrated performance. Its four questions each resolve to infrastructure rather than policy. On ibl.ai you own all the code and the data, so the evidence and the audit trail stay inside the health system.** Most coverage led with the four questions. The four questions are the visible part. The load-bearing part is the word *maintained*, and almost nothing deployed in healthcare today can satisfy it. ## What did the AMA actually publish on 13 October 2026? A governance framework for AI agents assuming clinical functions, produced by the AMA's Center for Digital Health and AI rather than adopted as policy by the House of Delegates. The [framework](https://www.ama-assn.org/practice-management/digital-health/governance-framework-agentic-ai-assuming-clinical-functions) was released on **13 October 2026** and [reported](https://www.healthcaredive.com/news/ama-releases-governance-framework-for-agentic-ai-in-healthcare/833120/) two days later. [Fierce Healthcare](https://www.fiercehealthcare.com/regulatory/american-medical-association-rolls-out-governance-framework-agentic-ai-solutions) names the Center as its author. That provenance is worth noting rather than glossing. The AMA House of Delegates has adopted AI policy before, including its November 2024 policy on augmented intelligence development, deployment and use. This is a different kind of document from the same organization. The distinction between a framework and a rule matters, and it cuts in a more interesting direction than it first appears. This is not regulation. It carries no enforcement, no penalty and no compliance deadline, and anyone selling it as a mandate is overselling it. The AMA is a professional association publishing guidance, not an agency issuing a rule. What it is instead is the clearest available statement of what the profession thinks it will want to see. That makes it a useful specification precisely because nobody is grading against it yet. Its stated principle is the organizing idea: clinical authority should be earned through evidence and maintained through demonstrated performance, with authority and oversight evolving as evidence, performance, risk or the technology itself changes. The context it is written against is autonomous multi-step operation. An agent that triages, summarizes, routes a referral and updates a record can cause harm across several steps before a clinician sees any of it. A chatbot that answers one question wrong is a different risk shape than an agent that acts four times. ## What are the four questions in the AMA agentic AI framework? Function, evidence and risk, authority and oversight, and accountability. In the AMA's own phrasing:
QuestionThe AMA asksWhat it resolves to in practice
FunctionWhat clinical function is the AI performing?A bounded, enforced scope per agent — which data it reads, which actions it takes
Evidence + riskWhat demonstrates that it can perform that function, and what happens if it fails?An evaluation suite with expected outputs, plus a defined failure path
Authority + oversightWhat should the AI be permitted to do, and under what conditions?Conditional, role-aware permissions rather than a static capability list
AccountabilityWho is responsible for the risks and outcomes?A reconstructable record of every interaction
Read the right-hand column as a purchase order. Each of these reads like something a committee decides and writes down. Each is actually something a platform either emits or does not. ## What does "clinical authority earned through evidence" require a health system to build? An evaluation pipeline that runs before deployment and keeps running after it, which is the requirement most pilots quietly skip. "Earned through evidence" is the easier half. It means an agent runs against a benchmark of representative cases with expected outputs, scored and reviewed by people qualified to judge the clinical content, before it touches a patient workflow. "Maintained through demonstrated performance" is the half that breaks current practice. It means the evidence has an expiry. A model that was validated in March is not validated in October if the underlying model version changed, the prompt changed, the retrieval corpus changed, or the case mix drifted. Any of those four can change without anyone filing a ticket. The software engineering parallel is exact and worth stating plainly: no team ships code without a test suite, and no team treats a green test run from seven months ago as current. Clinical AI has somehow been held to the weaker standard. The practical requirement is the ability to write test cases, run agents against them on a schedule, score the results with both a judge model and a human reviewer, watch for degradation, and export the whole trace for review. ibl.ai ships that as [Evaluations](https://ibl.ai/docs/os/agent-settings/evals), with LLM-as-judge scoring, human annotation and export. There is a second clause in the same question that gets less attention: *and what happens if it fails*. Every agent fails eventually. The framework is asking for a designed failure mode, which means a clean handoff to a clinician, a logged record of the failed interaction, and no silent partial action left behind. ## Who is accountable when a clinical AI agent fails, and what does that require? Nobody can be held accountable for an outcome that cannot be reconstructed, so accountability is a logging requirement before it is an organizational one. This is the question with the sharpest infrastructure consequence. Assigning responsibility requires knowing what actually happened: the input, the output, the model version, the data accessed, the permissions in force at that moment, and the timestamp. Not a usage dashboard. A record complete enough to answer a question asked by a malpractice attorney eighteen months later. Healthcare adds a complication that general enterprise AI does not face. An audit trail of clinical agent activity contains protected health information, which means **the log is PHI** and inherits every storage, transmission and access control that applies to the clinical data it references. That single fact resolves a lot of architecture debate. A compliance record that lives in a vendor's multi-tenant logging system is a PHI disclosure to that vendor, governed by a business associate agreement and by the vendor's retention policy rather than by yours. Where the agent runs inside the health system's own perimeter, this stops being a contractual promise and becomes a property of the deployment. [Audit](https://ibl.ai/docs/os/analytics/audit) and [transcripts](https://ibl.ai/docs/os/analytics/transcripts) sit in infrastructure the health system operates. The same logic governs the third question's conditional permissions. An agent might be permitted to flag a possible medication interaction during a supervised review and not permitted to dismiss one, ever. That is not a capability toggle; it is a rule that depends on context, clinical role and workflow state, which is why [roles](https://ibl.ai/docs/os/organization-settings/roles) tied to the organization's identity provider do work that an admin/user split cannot. This is the same accountability gap we traced through [Oracle Health's clinical agent](/blog/oracle-health-clinical-agent-who-audits-the-flowsheet) and through [prior authorization automation](/blog/prior-authorization-ai-agents-time-to-patient-bottleneck), where the question was never whether the agent was accurate but who could prove it afterwards. ## How does ibl.ai support AMA-aligned agent governance in healthcare? By making each of the four questions answerable from systems the health system runs itself. On ibl.ai **you own all the code and the data**, running **model-agnostic** across any LLM with **no per-seat pricing**, so you can **deploy anywhere** — your cloud, on-premise, GovCloud, or a fully air-gapped network. Mapped to the framework: per-agent scope and dataset binding answer *function*; Evaluations with judge scoring, human annotation and export answer *evidence*; identity-provider-bound roles with conditional permissions and PII filtering answer *authority and oversight*; and a complete, exportable audit trail inside your own perimeter answers *accountability*. Air-gapped deployment is the version of this that needs no trust at all. If no data leaves the network, data minimization stops being a policy anyone has to audit and becomes a fact about the topology. ibl.ai is family-owned and operated from New York, NY — a U.S.-headquartered, domestically-owned long-term partner, not a vendor that sells licenses and moves on. 1.6M+ users across 400+ organizations run the platform this way, including NVIDIA, MIT, and Syracuse University. ## The Takeaway The AMA's four questions are not a form to complete once. They describe a system that has to keep producing answers while the agent is running. A health system can write the policy this week. It cannot produce the evidence unless something underneath it is generating evidence continuously, and it cannot assign accountability unless the record is complete and in its possession. That is the actual gap, and it closes with infrastructure rather than with a document. ## Why does owning the AI stack matter? **ibl.ai is the agentic AI platform where you own all the code and the data. You self-host the entire stack inside your own perimeter, run it model-agnostic across any LLM and switch anytime, and pay by usage with no per-seat pricing — so you can deploy anywhere: your cloud, on-premise, GovCloud, or fully air-gapped.** - **You own all the code and the data.** Full source code under a perpetual license, running on your infrastructure. Not API access to someone else's platform — the stack itself is yours. - **Model-agnostic.** Run any LLM — Claude, GPT, Gemini, Llama, Command, or your own fine-tune — and switch providers without rewriting the platform. - **No per-seat pricing.** Usage-based billing against a budget cap you set. Cost tracks what your organization actually uses, not how many people you employ. - **Deploy anywhere.** Your cloud, your VPC, on-premise, GovCloud, or a fully air-gapped network with no outbound connectivity. 1.6M+ users across 400+ organizations run the platform this way, including NVIDIA, MIT, and Syracuse University. ibl.ai is family-owned and operated from New York, NY — a U.S.-headquartered, domestically-owned long-term partner, not a vendor that sells licenses and moves on.