Your AI policy is a document. Can you produce the log?

Microsoft just rewrote the rules it governs its own AI by. The change is not in the policy language. It is in what the company now has to be able to show afterwards.

What happened

Microsoft published its 2026 Responsible AI Transparency Report and, alongside it, a revised Responsible AI Standard. The report is the visible part. The standard is the part worth reading.

Oversight used to point at the model. Test it, document it, sign it off, ship it. The revision moves the unit of governance up a level, to the interactions between models, agents, tools, data and people. The new controls name three things directly: agent identities, tool permissions, and monitoring of the actions an agent takes.

The supporting detail matters as much as the wording. Microsoft trained thousands of engineers and product managers on agentic threat modelling and prompt injection defence. It applied stricter risk management to AI used in security-sensitive work. It took ISO 42001 certification for Microsoft 365 Copilot and GitHub Copilot. And governance now runs across a product's whole life rather than sitting as a gate before launch.

None of that is a turning point. It is a large vendor writing down what its own incidents taught it, which is exactly why it is worth reading.

Why this matters to your business

Big-vendor internal controls have a habit of becoming everybody else's questionnaire. An ISO standard for AI management gives procurement teams something to point at, and once one enterprise buyer asks the question, the rest copy it. "We have an AI policy" stops being an answer at that moment.

What they will actually ask is narrower and harder. Which agent took this action. On whose authority. With access to what. Show me.

Most companies running an AI pilot cannot answer that today. Not through carelessness: the pilot was built to prove the idea worked, and nobody asked it to keep a record. The credentials came from whichever account was handy. The tool list grew because adding one was easier than arguing about it. The transcripts live wherever the vendor puts them, for however long the vendor keeps them.

That gap costs you twice. Deals slow while somebody assembles evidence by hand out of screenshots and Slack threads. And when something does go wrong, having no log turns one contained mistake into an open question about everything that agent has ever done. You end up defending the whole system because you cannot isolate the incident.

Why this is a CX-Builder use case

A governable agent is not a different kind of agent. It is the same agent built somewhere the boundaries are explicit and the record falls out as a by-product instead of a retrofit.

In CX-Builder each agent is a flow you can look at. The tools it can call are the ones you attached, which makes tool permission a decision you made at build time rather than a hope about how the model will behave. Credentials live in the platform with their own scope instead of being pasted into a prompt, so an agent acts as a named thing you can point to. Human-in-the-loop gates hold the decisions that should not happen unattended.

The part that decides the procurement conversation is where all of it runs. CX-Builder is self-hosted, so conversation history and execution traces sit in your own database under your retention rules. When a customer, an insurer or an auditor asks what happened on a given Tuesday, you are running a query rather than filing a support ticket with a vendor.

What this looks like if you build it

Start with credentials. Give each agent its own connection to each system, scoped to the narrowest thing that still lets it finish the job, rather than a shared service account with broad rights that three other teams also use. Then narrow the tools. An agent handling refund questions should not be able to reach the tool that changes account ownership, and the cheapest way to enforce that is to never attach it.

Put an approval step in front of anything you cannot undo. Turn execution traces on and keep them long enough to satisfy your contracts, not just long enough to debug last week's release. Before a customer finds the weak spot, spend an afternoon attacking your own agent with the prompts you would use if you were trying to make it misbehave.

All of that is configuration and habit. None of it needs a better model, and together it is the difference between a policy you wrote and a record you can hand over.