How to identify every AI agent currently touching your clinical systems
Start from system access logs, not vendor documentation — agents are frequently deployed by clinical teams or embedded in vendor tools without formal IT sign-off.
Pull authentication and API access logs from your electronic health record system and any clinical decision support tools for the last 90 days. Look for service accounts, API keys, and non-human identities that are not tied to a named staff member.
Cross-reference this list against your procurement and vendor register. Any AI agent that appears in access logs but not in procurement records is an unmanaged agent and should be treated as the highest priority.
Teams often stop at the vendor contract list, missing agents embedded inside already-approved tools that were enabled by a feature update rather than a new purchase.
How to classify each AI agent by the data it can access
Classify every agent by whether it can read, write, or make automated decisions using identifiable patient data, not just whether it touches clinical systems generally.
Use a simple three-tier classification: read-only access to de-identified data, read access to identifiable patient data, and write or decision-making access to identifiable patient data. The third tier carries the highest governance burden under the Privacy Act.
Classifying by system rather than by data access hides agents that have broader access than the system's primary purpose would suggest.
How to assign an accountable owner to each agent
Every agent needs a named accountable owner, not just a technical administrator, who can answer for its behaviour to the board or a regulator.
This is the step Lumaris most often runs as a facilitated workshop with clinical, IT, and privacy leads in the room together, because ownership questions surface disagreements about who actually decided to deploy a given tool.
Document the owner, the business justification, and the review cadence for each agent in the same inventory record.
Assigning ownership to 'IT' as a department rather than a named individual means no one is accountable when something goes wrong.
AI agent inventory: minimum fields
| Field | Why it matters | Example | |
|---|---|---|---|
| 01 | Agent name | Uniquely identifies the tool or service account | Ambient scribe assistant |
| 02 | Data tier | Drives the governance controls required | Tier 2 — identifiable read access |
| 03 | Accountable owner | Who answers for this agent's behaviour | Head of Clinical Informatics |
| 04 | Review cadence | How often the entry is revalidated | Quarterly |
Common pitfalls
An AI agent inventory decays quickly as clinical teams adopt new tools. Without a standing review cadence, the inventory is out of date within a quarter.
Many vendors add AI-powered features to existing products without triggering a new procurement review, which means the agent exists in your environment with no governance sign-off at all.
Frequently asked questions
Most organisations with 500 to 2,000 staff can complete an initial inventory in two to four weeks, including the ownership workshop, though ongoing maintenance is a standing process rather than a fixed end date.
Yes. Vendor-supplied AI agents still access your data and still need an accountable owner and a documented risk tier, even though you are not the one who built the tool.
Treat it as the highest-priority item in the inventory. Suspend access if practical while the accountable owner and business justification are established.
Martin Barnier is Principal and Consulting Director at Lumaris, an Australian-owned, vendor-neutral advisory firm specialising in AI governance and identity architecture for regulated healthcare providers.
View LinkedIn profile