AI agent registry for hospitals: from inventory to accountable decisions

What should a hospital AI agent registry do?

A hospital AI agent registry records each agent's identity, accountable owner, intended use, permitted actions, and lifecycle status. It should connect those facts to review decisions and evidence. A broader AI inventory can also include tools that produce suggestions without taking actions. Neither record, by itself, enforces permissions or stops software.

Use three separate questions: What do we know is in use? What has the hospital approved? What does the deployed configuration actually allow? A useful registry makes discrepancies visible rather than treating a completed row as permission to operate.

The NIST AI RMF 1.0 is voluntary. Its GOVERN 1.6 and 2.1 address inventories and responsibility. The following worksheet approach is an implementation suggestion, not a prescribed NIST form.

Make the workflow your starting unit

Create one record for a defined use, setting, and permission set. The same product drafting internal summaries and sending external messages may need separate records because the consequences and controls differ. Include pilots, embedded features, and internally built agents; do not assume a purchasing list covers them all.

Keep workflow_id stable. Record the product, model or release identifier in vendor_product_model_version; write unknown when the supplier cannot identify it. For multiple deployed agents, maintain linked technical identities in a controlled system. The worksheet does not include that runtime identity mapping.

Start with a workflow whose ownership or access is unclear. Ask its users and integration owner to trace inputs, processing locations, outputs, and downstream actions together. Record disagreements as open gaps.

Complete the fields that change a decision

• Ownership: accountable_owner_role owns the workflow decision; technical_owner_role checks configuration. Resolve role titles to named people and backups in your controlled directory.
• Boundaries: purpose_and_users, excluded_uses, connected_systems, and data_categories_no_phi describe the setting. Record data categories, never their contents.
• Access: separate allowed_actions from prohibited_actions. human_review_point identifies where a person approves an output before a consequential action, not merely who can inspect a log afterward.
• Decision: review_decision, decision_owner_role, decision_date, and decision_rationale_conditions capture the authorized scope. Lifecycle status and approval are different: a testing tool is not automatically approved for production.
• Evidence: evidence_reference_no_phi points to a restricted record; evidence_date and evidence_owner_role show its currency and custodian. State what was tested, not just that a document exists.
• Exceptions: open_gap, next_action, action_owner_role, and action_due_date turn uncertainty into assigned work.

The governance lead can maintain the process without owning every workflow. Involve clinical, privacy, security, procurement, or operations reviewers according to the proposed use. Ask the authorized decision-maker who can accept a remaining gap; do not silently transfer that decision to the spreadsheet maintainer.

Worked example: an approval narrower than the service account

This fictional hospital facilities team is testing a work-order assistant. It proposes drafts from synthetic maintenance requests. No real hospital, vendor, patient, or deployment is represented. The team discovers that its sandbox service account can close tickets, although the proposed workflow only needs to draft them.

The important result is the hold, not a green status label. Successful draft creation would show the allowed path works; a denied closure attempt would test one prohibited path. Neither result would establish every boundary or justify enabling a different action. Keep both observations with the tested version and configuration.

Know when a registry becomes part of a control

A CSV stores statements. Runtime enforcement requires an integration that checks the relevant action against configured policy before allowing it. Ask which identities, tools, and execution paths are covered, and which can bypass that check. Changing a registry status does not necessarily cancel already queued work or revoke separate credentials.

For Skovos, evaluate supported agents and configured controls in the proposed environment. Do not assume universal adapters, discovery of every AI feature, or control of unconnected systems. Request a demonstration of an allowed action, a denied action, and pause behavior for the exact integration under consideration.

A permissions check also does not establish output quality. Keep workflow evaluation and human oversight alongside access controls.

Keep the decision usable after go-live

Set next_review_date according to local risk and policy, then add early_review_triggers such as changed permissions, model updates, new users, or an incident. NIST's GOVERN 1.5 and MANAGE 2.4 address review and authority to disengage systems; they do not prescribe one quarterly schedule for every agent.

Complete pause_trigger, pause_authority_role, pause_and_fallback_reference, escalation_route_role, and restart_authority_role. Rehearse the fallback without relying on the same unavailable tool.

At the next review, ask: Can someone outside the project identify the owner, explain the approval boundary, and find the evidence for it? If not, choose that gap as the next action. This guide supports operational planning, not legal advice or certification.

Keep working