Dynamic AI Asset Governance

Idea one

Capital equipment for the knowledge workspace

In a conventional office the capital equipment was easy to point at: buildings, servers, production systems, licensed software. It appeared on inventories, budgets, depreciation schedules and maintenance plans. It had owners and service histories. It was patched, upgraded and retired on a recognisable lifecycle.

The agentic equivalent is harder to see: foundation-model access arrangements, fine-tuned models, specialised agents, prompt libraries, retrieval pipelines, vector databases, tool integrations, agent identities, workflow definitions, policy-as-code controls, evaluation suites, knowledge graphs, and the proprietary data relationships that let an agent do useful work in this organisation.

A service-resolution agent is not a chat interface with a pleasant tone. It is an operational asset made of interdependent parts — the prompt instructions, the policy hierarchy it can retrieve, the integrity of account and contract data, the rules deciding which sources are authoritative, the validators that challenge its conclusions, the tools it may invoke, the credentials it uses, and the gates preventing it from turning uncertainty into an unauthorised commitment. If any one of those degrades, the agent may remain technically available while becoming operationally unreliable.

So governance starts with a change in perception. Prompts, models, retrieval systems and agentic workflows are not disposable experiments or informal productivity aids. They are capital equipment for the knowledge workspace. They create value, consume resources, shape decisions, expose risk, and require disciplined stewardship.

Idea two

A critical asset that is invisible cannot be maintained

An organisation that would never let an employee bolt unapproved machinery onto a production line will often let them connect unapproved AI tools to sensitive information, load internal documents into personal accounts, or build small autonomous workflows with access to business applications.

This gets called shadow AI, and the phrase makes it sound marginal or illicit by definition. In reality it usually emerges because employees are trying to solve genuine problems faster than formal governance can respond. A specialist writes a private prompt template for customer histories. An analyst uploads reports to an external assistant to speed up variance explanations. An engineer connects an agent to a repository to generate documentation. Each action looks small. Together they create an unmanaged estate of models, prompts, data flows and autonomous capabilities.

Data leakage is a real risk and it is not the deepest one. The deeper problem is that the organisation loses visibility into what its productive intelligence actually consists of. It may not know which prompt library is shaping customer communications, which retrieval corpus holds obsolete policy, which agent can reach a sensitive tool, or which informal workflow has quietly become essential to a team's day.

A critical asset that is invisible cannot be maintained. The principle is straight from TPM: a machine with no owner, no schedule, no operating standard and no record of modifications will eventually be a source of breakdown. The same holds here. An unmanaged prompt drifts from current policy. A vector database keeps documents whose authority has expired. A workflow built for low-risk internal drafting is gradually repurposed for external commitments without anyone redefining its authority.

And the agent may still seem useful throughout — may even become more trusted as people grow accustomed to it. But apparent usefulness is not the same as maintained capability.

Idea three

Asset-level visibility, or every defect is "the AI"

The remedy is an inventory that is more than a list of software subscriptions — a living map of the enterprise's agentic capital equipment. For each material asset: purpose, owner, users, models involved, data sources, retrieval relationships, tools, permissions, policy constraints, evaluation status, risk classification, version history, dependencies, and retirement conditions. Also whether it is a recommendation tool, a supervised execution system, or an autonomous proxy operating within bounded authority — and which human roles are responsible when it fails, drifts, or must be restricted.

Take the service workflow. Intake, policy, contract, validator, communication and execution agents are separate but connected assets, each with distinct dependencies. The policy agent depends on an approved corpus and an ontology separating standard guidance from local procedure. The contract agent depends on correctly indexed amendments and effective-date logic. The execution agent depends on narrow credentials and a rules-based authorisation check.

Now a new contract template appears and ambiguity starts showing up in the exception queue. With asset-level visibility you can ask which asset needs attention: a missing relationship in the knowledge graph, a retrieval failure, a prompt that never told the contract agent to distinguish amendment types, a validator threshold set too weak, a policy-as-code rule not updated for the new template. Without asset-level visibility, every defect looks like a general failure of "the AI." With it, maintenance becomes possible.

Which is also why provenance matters. The valuable asset is not only the model — it is the history that makes the asset accountable: where its information came from, who approved its instructions, which evaluations it passed, what has changed, which incidents affected it, and under what conditions its outputs may be trusted.

Idea four

Prompts become operational logic without being recognised as such

Prompt provenance deserves separate attention, because a prompt library quietly turns into business logic while everyone still thinks of it as text.

A carefully developed prompt may encode the organisation's preferred service tone, a sequence of policy checks, a source hierarchy, escalation conditions, or an implicit interpretation of a regulatory obligation. When that prompt is copied, modified or reused in another context, its original assumptions may travel with it invisibly.

Three failures follow directly. A prompt appropriate for preparing an internal case summary may be dangerously inadequate when reused to generate an external customer commitment. A prompt that worked before a policy revision may silently preserve an obsolete decision rule. A prompt that appears to improve efficiency may be encouraging an agent to infer missing facts rather than ask for clarification.

So material prompts should be treated more like controlled procedures than casual instructions: versioning, designated ownership, testing, change records, and retirement when their assumptions no longer hold. The same applies to retrieval configurations, agent skills and workflow templates. These assets may be intangible, but they determine how the enterprise perceives, reasons, and acts.

Idea five

An inventory establishes awareness. It does not establish control.

Knowing you possess a policy agent and a prompt library does not answer the urgent questions. What is the agent doing right now? Which sources is it using? Has its behaviour changed since the last validated release? Is it attempting an action consistent with its purpose? Is it being manipulated by untrusted content? These are runtime questions, and they cannot be answered by a one-time approval process.

Conventional software governance was built around predictable applications whose intended behaviour was bounded in advance. An agent encounters novel language, generates plans, selects among tools and reinterprets requests — which is the source of its value and the reason an agent can pass every test in a controlled environment and later behave differently when it meets an unfamiliar document, a changed data source or malicious content in a file it was asked to read.

The governing principle is least privilege, translated: no agent should possess more authority than is necessary for the specific action it is currently authorised to perform. A service agent gets the relevant record classes, for a defined purpose, for a limited period, through an identity that can be audited — not unrestricted access to all customer records because it might need one. Authority must be granular, contextual, and revocable, and each agent operates through a distinct identity rather than borrowing an employee's credentials or sharing a generic automation account.

Which produces the distinction to carry out of this lesson. An instruction tells an agent not to disclose confidential contract information. A guardrail enforces it through access boundaries, data classification, tool permissions, output controls and policy-as-code. The instruction is still useful — it guides reasoning — but it cannot be the final defence, because a probabilistic system may misunderstand, overlook, or be manipulated into reinterpreting it. The guardrail remains stable even when the agent's language changes.

That is the difference between an instruction and a guardrail, and it is worth stating as plainly as the chapter does. The control does not depend on the agent deciding to behave responsibly. It makes irresponsible action unavailable.