Governing AI Agents in Practice — Article 02

When several teams start building AI agents, each team will face some of the same questions. What needs to be checked before release? When should security be involved? Where should ownership be recorded?

If every team works this out separately, the organisation can end up with different standards for similar risks. Asking a central team to approve every decision creates another problem: work queues up, even when teams could safely proceed themselves.

This is where I would give the central AI Centre of Excellence a clear remit: establish shared standards, help teams apply them and maintain oversight of how agents are being used.

Each business owner remains accountable for their agent’s purpose and outcomes. The CoE is accountable for making the shared governance arrangements clear, usable and subject to review.

Set a minimum that teams can use

I would start with a short set of requirements for agents entering business use. These should cover accepted ownership, a proportionate risk assessment and the evidence needed for release.

The assessment should consider the information an agent uses, the people affected and the actions it can take. Release requirements should include testing, support arrangements and a way to stop or recover the service.

The CoE should develop these requirements with the teams that already hold relevant authority. Security retains responsibility for security policy and security exceptions. IT retains its agreed platform administration and service management responsibilities. Risk and compliance teams retain their assessment and approval responsibilities.

The CoE brings those requirements into a usable process. Teams should know who sets each requirement, who checks it and who can authorise an exception.

They also need help meeting the standard. Reusable ownership records, assessment prompts, test examples and patterns for human review can save repeated work. Advice sessions can help resolve questions early. The CoE should maintain this guidance as teams learn what works.

Keep visibility and make specialist review clear

The CoE should maintain a shared view of agents in business use: their purpose, accountable owner, risk level, operational contact and review status.

Exceptions belong in that view, with a reason, an authorised decision-maker and an expiry or review date. Teams should update the record when ownership, scope or capabilities change. The CoE can then follow up on missing owners, overdue reviews and unresolved exceptions.

Specialist review needs clear triggers. New access to sensitive information should involve security and the relevant data owner, with privacy specialists where needed. Permission to change business records should involve IT and the process owner. Actions with significant financial, legal or personal consequences should involve the relevant risk or compliance specialist.

Complexity matters too. Several connected systems or a sequence of dependent actions can make an agent harder to test, support and recover. That may justify technical review. A simple agent can still carry significant risk: the assessment needs to consider both the likelihood of harm and its consequences.

These are review criteria I would agree locally with the specialists. Teams should identify review needs early and revisit them when the agent changes. The CoE should provide a clear contact when teams are unsure which requirements apply.

Think about:

Imagine a hypothetical purchasing agent that answers staff questions using approved guidance.

Procurement uses the CoE’s assessment and testing templates, accepts business ownership and validates the answers. IT and security apply the relevant controls. The agent is recorded and follows the agreed release route.

Later, the team proposes allowing it to create purchase orders.

That change triggers further review. Procurement defines spending authority and human approval requirements. Security reviews access. IT reviews the integration and recovery arrangements. Risk specialists become involved according to the agreed criteria.

The CoE helps coordinate the review and updates the shared record. Procurement remains accountable for the purchasing outcomes.

For teams using Copilot Studio, Microsoft documents how administrators can use Power Platform data policies to restrict connectors and publishing channels. My recommendation is to use those controls to support the agreed standards, alongside business checks and named decision-makers.

Keep central review proportionate

The trade-off is between oversight and the central team’s capacity. Requiring a CoE meeting for every routine release creates a queue.

I would let teams proceed within agreed limits when the required evidence is recorded, with periodic checks by the CoE. Higher-risk changes and exceptions would receive specialist attention before release. This depends on teams understanding the limits and keeping records current.

How central and business teams organise that work is the subject of the next article, including the hub-and-spoke model. First, they need agreement on what the CoE owns and which decisions remain elsewhere.

Further reading

• NIST: AI Risk Management Framework — See GOVERN for responsibilities, inventories and proportionate oversight, and MEASURE 1.3 for specialist assessment.
• UK Government: AI Playbook — See Building the team and Risk management for multidisciplinary expertise and clear escalation routes.
• Microsoft: Configure data policies for agents — Practical documentation on controlling connectors, knowledge sources and publishing channels in Copilot Studio.