AI agent registry for hospitals: what it must contain, with a template
What is an AI agent registry?
An AI agent registry is the hospital's system of record for every AI agent it runs: who each agent is, who owns it, what it is allowed to do, and what state it is in. It differs from a general AI inventory because agents take actions, so the registry must record permissions and a stop status, not just a description. Every other control, from permission checks to audit and recall, reads from the registry.
Why hospitals need one now
Most AI in a health system did not arrive through an AI purchase. It came in through EHR updates, departmental tools, in-house builds and individual model API keys. In a CHIME Foundation and Censinet survey of 51 healthcare organizations, about half found AI through informal ad hoc discovery and about half relied on vendor release notes to track it.
Accreditors now look for this list. The Joint Commission's Responsible Use of AI in Healthcare certification, launched in June 2026, covers governance and monitoring, and surveyors at the first certified system checked its AI inventory. OCR's Section 1557 rule also requires covered providers to identify patient care decision support tools that use protected traits. Neither is possible without a current registry.
What a registry must contain
A useful registry answers five questions for each agent: Who is it? What may it touch? What did it do? Can we prove it? Can we stop it? The fields below cover those questions.
Identity
- Agent ID: a unique, permanent identifier.
- Name and version: the version matters when you need to show which build was running.
- Vendor or builder: vendor name, or "internal" with the building team.
- Underlying model and host: which model, hosted by whom. "Unknown" is a finding.
Accountability
- Accountable owner: a named person, not a department.
- Clinical or business sponsor.
- Who may stop it: named roles allowed to recall the agent.
Purpose and risk
- Purpose: one sentence.
- Category: clinical decision support, documentation, revenue cycle, patient communication, operations or research.
- Risk tier: for example, tier 1 for agents that write to a system of record or contact patients.
- Uses protected traits: yes, no or unknown, for Section 1557 review.
Permissions
- Scopes: each permission written as an action and a resource, such as `read:chart` or `draft:orders`.
- Data classes: PHI, PII, financial, de-identified or none.
- Human review required for: actions that need approval before they run.
Status and lifecycle
- Status: proposed, pilot, production, restricted, recalled or retired.
- Approval record: who approved it, when and with what conditions.
- BAA coverage: whether a business associate agreement covers this AI function, including the model provider behind the vendor.
- Last attested and next attestation date.
Evidence
- Audit trail location and whether it is tamper-evident.
- Monitoring: what is measured and where alerts go.
- Fallback workflow: how the work gets done if the agent is stopped.
The template
Copy this table into your registry tool, or use it to check the one you have.
| Field | Example | Required |
|---|---|---|
| Agent ID | AGT-0042 | Yes |
| Name and version | Prior Auth Agent v2.3 | Yes |
| Vendor or builder | Internal, Revenue Cycle Analytics | Yes |
| Model and host | Model name, hosted by provider | Yes |
| Accountable owner | Named director, Revenue Cycle | Yes |
| Sponsor | VP Revenue Cycle | Yes |
| Who may stop it | Owner, AI governance lead, on-call informatics | Yes |
| Purpose | Drafts and submits prior authorization requests | Yes |
| Category | Revenue cycle | Yes |
| Risk tier | Tier 1 (submits to payers) | Yes |
| Uses protected traits | No | Yes |
| Scopes | read:chart, draft:prior_auth, submit:payer_portal | Yes |
| Data classes | PHI | Yes |
| Human review required for | Submissions over a set dollar amount | If tier 1 |
| Status | Production | Yes |
| Approval record | AI committee, 2026-08-14, with conditions | Yes |
| BAA coverage | Signed, covers model provider | Yes |
| Last attested / next due | 2026-09-01 / 2026-12-01 | Yes |
| Audit trail | Hash-chained, hospital-owned | Yes |
| Monitoring | Denial rate, override rate, weekly review | Yes |
| Fallback workflow | Manual submission by PA team | Yes |
Every empty field is a governance finding. Rank the gaps by risk tier and close tier 1 first.
Why a spreadsheet is not enough
A spreadsheet is a fine place to start and a poor place to stay. It goes stale as soon as a vendor ships an update, it cannot enforce the permissions it lists, and it cannot stop an agent. The registry becomes a control only when the permission check reads from it, so an agent listed as read-only is actually denied when it tries to write, and a recall in the registry stops the agent everywhere.
How Skovos implements the registry
In Skovos, registering an agent gives it an identity, an accountable owner, a role and scoped permissions written as action and resource pairs. Every action the agent attempts is checked against those scopes and the decision is written to a hash-chained audit trail the hospital owns. Recalling an agent in the registry stops it immediately, and signed evidence of the registry and its controls can be exported for auditors. Governance staff can also list agents, check a permission or run a recall from Claude or ChatGPT through the Skovos connector. Skovos governs agents that are connected to it, so discovery of unconnected AI is still part of the work.
Frequently asked questions
What is the difference between an AI inventory and an AI agent registry?
An inventory lists AI systems and describes them. A registry of agents also holds each agent's permissions and status, so it can drive permission checks and recall.
What is the minimum a hospital AI registry should include?
An ID, a named owner, purpose, risk tier, permissions, data classes, status, approval record and who may stop the agent.
Does Joint Commission require an AI inventory?
Joint Commission's Responsible Use of AI in Healthcare certification is voluntary. Surveyors at the first certified system reviewed its AI inventory, so a current registry is strong preparation.
How often should a registry be updated?
Continuously for status and permissions, and through owner attestation at least quarterly for tier 1 agents.
Who should own the AI agent registry?
Usually the AI governance lead under the CIO, with clinical informatics, quality and compliance contributing and each agent owner keeping their entry current.
Related reading
- AI agent inventory for health systems
- What is AI governance in healthcare?
- AI governance frameworks for hospitals
- HIPAA-compliant AI deployment for health systems
- Building an enterprise AI governance program
Sources
- Censinet and CHIME Foundation AI adoption survey (Dec 2025): https://www.censinet.com/blog/ai-adoption-survey-reveals-healthcares-governance-gap-and-drive-toward-agentic-usage
- Joint Commission RUAIH certification, Healthcare Dive (June 18, 2026): https://www.healthcaredive.com/news/joint-commission-adaptable-ai-blueprint-certification-ken-grubbs-william-walders/823201/
- Hackensack Meridian certification, TechTarget (Sept 22, 2026): https://www.techtarget.com/healthtechanalytics/feature/Inside-Hackensack-Meridians-first-in-nation-Joint-Commission-AI-certification
- Section 1557 decision support tools, McDermott Will & Schulte: https://www.mcdermottlaw.com/insights/section-1557-patient-care-decision-support-tools-anti-discrimination-compliance-12-things-to-consider/
- Skovos connector documentation: https://mcp.skovos.ai/docs