Home Build for the Model You’ll Replace: Governance Over Model Choice

Build for the Model You’ll Replace: Governance Over Model Choice

Aug 28, 2026
Shifthappens Build for the Model Youll Replace 5 Featured Image 690x387

Every few months, the model rankings reshuffle, and many organizations respond by convening a strategy meeting to decide which one to standardize on. That meeting keeps happening because it feels like a consequential decision. In most cases, it isnt.

The decision that actually determines whether an AI deployment holds up is whether youll know what your systems are doing once they start taking action on your behalf. Models are becoming easier to substitute at a speed nobody planned for. The harnesses around them are differentiating just as quickly. The layer that governs access, data, and behavior is what youll still be living with three years from now.

The Swap Cost Nobody Prices In

The practical version of the problem looks like this. An organization picks a model, builds agents within that vendors framework, and lets the permissions, logging, and data boundaries live wherever the framework places them. It works. Then the pricing changes, or a competitors model gets meaningfully better at the specific task, or a compliance requirement rules something out.

At that point, the swap becomes a rebuild because governance was never separate from the agent framework. Every permission mapping, every audit trail, every data boundary has to be recreated inside a new vendors model of how those things work. Teams discover this at the worst possible moment, which is after the business has already decided to move.

The test worth applying is simple. If you replaced the model under your highest-value agent next quarter, what would remain unchanged? Some prompt logic may survive. Orchestration, tools, skills, and the user experience are often tied to the harness. The parts that tend not to survive are the ones that matter most under scrutiny: who the agent is allowed to be, what its allowed to reach, and the record of what it did.

The Harness Is Part of the Product

Its worth being precise about what youre actually choosing, because the model is only one layer of it. Claude Code is a useful illustration. Its value isnt just the underlying model. The agent loop, the tooling, the repository context, MCP support, and skills are all part of the product. Running the same model through Foundry doesnt recreate that experience.

This means heterogeneous AI will be standard, not a transitional state — Copilot for broad productivity, Claude Code for developers, and n8n stitching workflows across models. Models and harnesses will vary by workload and change over time, and thats the correct outcome rather than a problem to solve.

What cant vary are identity, access, data policy, and auditability. Each production agent still needs a distinct identity. The trouble starts when each harness brings its own identity architecture, permission model, data policies, and audit process. At that point, every new AI capability becomes a governance rebuild, and the organization slowly accumulates as many governance models as it has tools.

Microsoft-first doesnt have to mean Microsoft-only. Entra, Purview, and Agent 365 can provide shared controls, while each workload uses whichever harness best fits it. The requirement is simply that every harness answers to the same control plane.

What the Governing Layer Needs to Handle

The thing that makes agentic AI architecturally different from previous integrations is that the workload acts. A traditional application reads and writes on behalf of a user who initiated the request. An agent takes a goal and decides on its own sequence of steps, which means the questions your architecture has to answer change shape.

Identity is the first one, and its the least solved. An agent operating under a service account inherits permissions scoped for a very different kind of consumer. Attribution is the second: when an action lands in a log, the record needs to show which agent took it, under whose authority, and toward what goal. Then theres containment, meaning the ability to stop a specific agent without taking down the platform it runs on.

Those are all properties of the environment in which the model operates; as such, coupling them to a model is a design error rather than a shortcut.

AI Governance Is ITs Gluten-Free Steak

Assessments tend to turn up the same thing. More often than not, the AI piece isnt the blocker. What surfaces is the foundational work IT teams have been trying to get funded for years.

Theres a story about a restaurant that found significant success with a new gluten-free steak. Customers happily paid extra for something healthier, more organic, somehow less synthetic. Of course, steak has always been gluten-free.

AI governance is ITs gluten-free steak. Persona-based identity, data governance, endpoint management, and MAM/BYOD controls were always the right work to do. AI gave that work a shiny new label, executive attention, and finally a budget.

A recent customer example makes the point. They had invested in Microsoft 365 E5 and were doing yeomans work in Purview and Defender for Endpoint. The gap wasnt another AI product. They hadnt connected those capabilities via Defender for Cloud Apps to build a more complete view of the user, device, application, and data involved.

That connection changes the question from “should we block AI” to “what is actually happening.” Do I care if someone opens an unmanaged AI app on a corporate device to generate a harmless image?? Probably not. Do I care if that same user starts uploading documents containing sensitive customer information? Absolutely. The policy should know the difference.

Thats the real readiness test. AI governance doesnt live inside a single Microsoft SKU. It lives in the seams between identity, applications, endpoints, and data. Most customers already own much of the answer across Entra, Intune, Defender, and Purview. The challenge is to bring those controls together into a cohesive operating model, so that adding the next model or harness doesn’t mean building governance from scratch.  

The Bottom Line

Model choice is a real decision with real consequences, and it deserves the attention it gets. It just shouldnt be load-bearing. Neither should the harness be around it. An architecture in which changing models is a configuration change rather than a program of work can absorb whatever the next 18 months produce. Getting there means treating identity, attribution, and containment as your own responsibility rather than features you inherit from whichever vendor you picked this year.

Working through the model question right now?

Join AvePoints AI Virtual Summit, Analog Insights. AI Trust, on September 10, 2026, for the session on choosing the right AI for your business, covering Copilot, Gemini, and general-purpose LLMs, and what it takes to make that choice a reversible one.

Register now 

AvePoint logo

#shifthappens is powered by AvePoint, the global leader in modern data protection, unifying data security, governance, and resilience to provide a trusted foundation for AI.