Microsoft moves AI governance from paper to runtime

Microsoft published an AI governance architecture that shifts control from policy documents to runtime enforcement, with continuous evaluation, observability, and evidence generation for audits as organizations put AI applications and agents into production. The information was reported by InfoQ, based on a publication from Microsoft itself.

The core idea is summarized by Anthony Bartolo, Principal Cloud Advocate at Microsoft, in a LinkedIn post cited by the report: "Your AI policy isn't governance until production can prove it". In other words, having a document that says what the model can or cannot do means nothing if the production environment doesn't prevent, log, and prove that behavior.

What changes compared to the previous model

Until now, much of AI governance at companies lived in documents: acceptable use policies, risk classifications, compliance checklists. The problem is that none of this is verifiable in real time when an agent calls an API or a model generates a response.

Microsoft's proposal treats governance as a continuous operational loop, divided into four functions:

• Policy: defines requirements and risk classifications;
• Control: translates policy into access rules and runtime rules;
• Visibility (observability): captures system behavior;
• Proof (audit): converts operational telemetry into evidence for compliance and incident investigation.

Manasa T. Ramalinga, Cloud Solution Architect at Microsoft, sums up the motivation in another post cited by InfoQ: organizations moving AI workloads to production are re-architecting their fundamental structures instead of treating governance as an afterthought. The phrase Microsoft places at the center of the material: "you can't scale what you can't control".

The nine domains and the AI Gateway

The architecture defines nine governance domains: policy, data governance, model governance, observability, evaluations (evals), security, identity and access, audit and compliance, and agent governance.

In practice, it combines Microsoft Foundry with services already familiar from the Azure ecosystem:

• Microsoft Purview for data governance;
• Microsoft Entra ID for identity and access;
• Defender for security;
• Azure API Management for traffic control.

The point most relevant to developers is the Foundry AI Gateway, presented as a runtime boundary for authentication, token limits, quotas, and policy enforcement. According to Microsoft's documentation, the gateway also governs tools exposed via MCP (Model Context Protocol), offering centralized authentication, rate limiting, IP restriction, and audit logging without modifying the MCP servers or the agent's code.

This last detail matters: it means you can add a control layer over an existing agent without rewriting its logic, by intercepting traffic at the gateway.

Evals before and after deployment

Another important shift is where evaluations sit. Instead of testing the model only before it goes live, Foundry supports evaluating applications and agents against datasets using built-in and custom evaluators, both during the pre-deploy phase and while monitoring behavior in production.

In practice, it's the difference between "passed the tests once" and "keeps within quality and safety limits while running," capturing regressions and unwanted behaviors that only appear under real traffic.

Agent governance: checkpoints and human approval

The agent governance layer adds controls over identity, access, activity, and workflow checkpoints for autonomous agents. Microsoft maintains an open-source Agent Governance Toolkit that provides runtime security capabilities, including policy enforcement and interception points.

The architecture also describes the Agent Control Specification, a checkpoint mechanism spanning an agent's cycle: inputs, model calls, tool execution, and outputs. Higher-impact actions can be configured to require human approval before executing, the "human-in-the-loop" pattern applied at specific points rather than across the entire flow.

It's not just an Azure thing

The report is careful to note that the approach is broader than a proprietary control plane. The NIST AI Risk Management Framework and its Generative AI Profile offer a vendor-neutral framework for managing AI risk throughout the lifecycle, covering governance, measurement, evaluation, and risk mitigation. What Microsoft does is map these generic concerns into concrete platform controls and operational telemetry.

What this means for the Brazilian developer

For those building software in Brazil using Copilot, Azure OpenAI APIs, or assembling agents with MCP, the message is that AI governance is shifting from a compliance task to an architecture and runtime problem, in other words, something that lands on the desk of whoever writes and operates the system.

Some practical points that emerge:

• Rate limiting, quotas, and token limits stop being just a cost concern and become a security control mechanism, enforced at the gateway;
• Audit trails become a design requirement from the start, not something to improvise when the client or regulator asks for it;
• For companies subject to LGPD (Brazil's data protection law), having operational evidence of how sensitive data flowed through an agent or model can be the difference between demonstrating control and being in the dark during an incident. The combination with Purview and Entra ID targets exactly that kind of data and identity tracking.

What remains open

The source describes the architecture and the tools, but doesn't provide adoption numbers, production gateway overhead benchmarks, or concrete Brazilian cases. It also doesn't detail how much of this governance depends on being locked into the Foundry/Azure ecosystem versus what's replicable in mixed stacks. It remains to be seen whether the "runtime proof" model that Microsoft (and, along a similar path, Cloudflare) has been pushing actually becomes a market standard or stays a platform differentiator.