I keep hearing some version of “We have artificial intelligence (AI) governance now,” which usually means an organization has published a policy, assembled a committee, or decided which AI tools employees can use. These are reasonable things to do. But I’m interested in less impressive questions:
- How many AI agents are actually running in the organization right now?
- Can you name them?
- Who owns them?
- Does your current revenue depend on them?
If answering these requires a solid amount of Slack archaeology (whether for IT service management (ITSM) or wider use cases), we have found an AI governance issue that no policy document will solve.
As we know, AI is a force multiplier: it will scale good operations, but it will also scale bad data, inconsistent processes, and organizational mess with impressive efficiency. AI governance has the same dependency. You can have sophisticated AI rules and still operate with a surprisingly fuzzy picture of what is actually happening in your environment.
This is becoming harder to get away with because what we need to govern changes as scale grows.
Our definition of an IT asset is starting to show its age
IT has traditionally had an understandable picture of the estate: laptops, servers, network devices, applications, databases, cloud services, and the other technology organizations have spent decades learning to inventory and manage.
Then there is everything that has accumulated around them. An old script written years ago now runs an important production task; an automation workflow becomes part of a business process. An AI agent gets deployed for one purpose and, six months later, has access to three more systems than it did on day one.
These things do not always look like assets in the traditional IT asset management (ITAM) sense, so we manage them unevenly. Some end up in spreadsheets or wikis. Some are documented only inside the tool where they were created. Some exist mainly in the memory of the person who built them.
AI makes this weakness more consequential. An AI agent can interpret information, communicate with users, make recommendations, invoke tools, or coordinate activity between systems. As these capabilities expand, relying on informal knowledge about what’s running and who owns it becomes harder to justify.
ITIL’s AI guidance makes a useful distinction
The new ITIL AI Governance (Version 5) guidance does something useful by refusing to treat every use of AI as equivalent. Its AI Capability Model groups capabilities into six areas:
- Creation
- Curation
- Clarification
- Cognition
- Communication
- Coordination.
An AI capability summarizing a ticket presents a very different risk from an AI agent coordinating actions across production systems. Calling both “AI” tells us very little about how either one should be governed.
PeopleCert’s guidance also emphasizes assessing existing governance, adapting it where AI exposes gaps as risks, and adapting these controls effectively as circumstances change.
This is a healthier starting point than building a separate bureaucratic universe called “AI governance” and hoping everything that can broadly be described as “AI” stays inside it.
IT organizations already know how to think about ownership, risk, access, change, services, suppliers, and configuration. The harder question is whether these disciplines can still see everything that matters and whether they offer the same value as the operating model expands beyond IT.
Give it a name and an owner
Suppose Finance has an AI agent in use. Before getting anywhere near a grand AI governance framework, I want to know what the AI agent is for, where it runs, who owns it, what systems it connects to, and when somebody is expected to review it again. These are extremely boring questions. They’re supposed to be.
Service management and asset management have spent years dealing with boring questions because boring questions become fascinating during outages and audits. Who owns this? What depends on it? When did it change? Why?
This is where our idea of the configuration item (CI) needs to stretch. We can treat AI agents as CIs with ownership and lifecycle information. So can automation workflows, operational scripts, and certificates. Their technologies are different, but each can become operationally important while remaining uniquely easy to lose track of.
Digital Assets
This is the problem we’re exploring at InvGate with Digital Assets: representing certificates, AI agents, automation workflows, and scripts as first-class CIs alongside the technology organizations already manage. For an AI agent, this can mean keeping information about its owner, purpose, connected systems, deployment environment, and review date in one place.
This information is useful input to AI governance. It does not decide whether an AI agent is appropriate, determine risk appetite, establish ethical standards, or make compliance decisions. Humans still have to do the uncomfortable parts.
Ownership itself deserves some suspicion. “We have an AI team” is not a sufficient answer to who owns the AI agent that can access your financial system. AI governance has to follow accountability down to the thing capable of creating the consequence.
Then someone changes it
Knowing that something exists is only the beginning because digital assets have the annoying habit of changing.
Imagine an automation workflow used in a regulated process. It was tested, reviewed, and approved. Six months later, an auditor wants evidence that the workflow currently running is still the workflow the organization thinks it approved. You need history. When did it change? Who changed it?
This is where I would separate inventory from change governance. An inventory gives us the object and its current state. Change governance gives us attributable evidence of what happened to that object over time.
An important point is hidden here: a lot of governance is ultimately an evidence problem. Policies describe what should happen. Audit trails help us establish what did happen.
Automation that stands the test of time, with validated controls, maintenance records and audit history, is easy to trust, repair, and blame when it fails.
The same will not necessarily be true of AI agents. Two AI agents built on the same model can carry wildly different risks depending on their access, purpose, and autonomy. A checkbox labeled “approved AI” doesn’t tell us much.
And people in business don’t usually do well with “I don’t know why…”
Governance has to be strengthened and adapted through daily contact
One weakness in traditional governance is that approval creates a comforting sense of completion. We reviewed the system, documented the decision, and moved on. Unfortunately, the system moved on too.
Maybe an AI agent gained another integration, maybe its owner changed roles, maybe a workflow was modified. The original approval can still be sitting there looking official while describing a version of reality that no longer exists.
That is why current ITIL AI Governance guidance emphasizes keeping governance effective over time. For IT teams, this makes governance feel less like an annual paperwork event and more like ordinary operational hygiene: review dates, ownership checks, change evidence, dependency visibility, and retirement when something no longer serves a purpose.
None of this is as exciting as talking about autonomous agents. But it will matter enormously once autonomous agents are more commonplace.
Having a controlled process to change these elements is just part of the story. There has to be an incentive to report, discover, and map these AI agents in the first place.
Before building more governance, do a proper count
If somebody asked me where to start improving AI governance tomorrow, I would resist the temptation to begin with another policy. I would try to build a reasonably honest inventory of the AI agents already operating in the organization. For each one, I would establish:
- Why it exists
- Who owns it
- What it can access
- What it can do
- When it was last reviewed
- Whether we can reconstruct meaningful changes to it.
Then I would review automation workflows, scripts, certificates, and other digital assets that have quietly become important enough to create risk. There will probably be gaps. Good. These gaps tell you where governance currently depends on memory, assumptions, and knowing who to ask.
AI governance will keep getting more complicated. Regulation will evolve. AI agents will gain more autonomy. Organizations will have to make difficult decisions about access, data, risk, ethics, human oversight, and accountability.
IT still gets to start somewhere much more familiar:
- Know what you have
- Know who owns it
- Understand what it touches
- Keep a reliable record of what changes.
We already know how important these basics are. AI is simply making the consequences of ignoring them much more interesting.
AI Governance FAQs
AI governance is the approach organizations use to oversee their use of artificial intelligence, including ownership, risk, access, change, accountability, and ongoing reviews. Effective AI governance requires visibility of the AI capabilities operating across the organization and the ability to keep governance controls relevant as circumstances change.
Clear ownership establishes who is accountable for an AI agent, what it is used for, which systems it connects to, and when it should be reviewed. Without this information, organizations risk losing track of AI agents and the consequences of their actions.
Treating AI agents as configuration items (CIs) makes it possible to record their ownership, purpose, connected systems, deployment environment, and review dates. This provides IT teams with better visibility of AI agents alongside the technology assets they already manage.
The ITIL AI Capability Model groups AI capabilities into six areas:
– Creation
– Curation
– Clarification
– Cognition
– Communication
– Coordination
These distinctions help organizations recognize that different AI capabilities present different governance requirements and risks.
Digital assets include items such as AI agents, automation workflows, operational scripts, and certificates. These assets can become operationally important but are not always managed consistently through traditional IT asset management approaches.
An inventory records the existence and current state of an asset, including its ownership and other relevant information. Change governance provides attributable evidence of what happened to that asset over time, including when it changed and who made the change.
Audit trails provide evidence of what actually happened to an AI agent or automation workflow. They help organizations establish when something changed, who changed it, and whether the current configuration still reflects what was reviewed and approved.
Organizations can start by building an inventory of their existing AI agents and documenting:
– Why each AI agent exists
– Who owns it
– What it can access
– What it can do
– When it was last reviewed
– Whether meaningful changes can be reconstructed.
They should also review automation workflows, scripts, certificates, and other digital assets that could create operational risks.
A policy describes what should happen, but it doesn’t necessarily provide visibility of the AI agents operating in an organization, who owns them, what they can access, or how they have changed. Effective governance also requires ongoing ownership checks, dependency visibility, change evidence, and regular reviews.
IT asset management can help organizations identify and track AI agents and other digital assets as first-class configuration items. Recording ownership, purpose, connected systems, deployment environments, and review dates provides useful information for AI governance, although human oversight and decision-making remain essential.
Matt Beran
Matt Beran is an IT Industry Analyst and Expert who is currently the Product Marketing Specialist at InvGate. He also hosts the extremely popular Ticket Volume Podcast.
