The AI Governance Operating Model: Freedom Inside Guardrails

Last month an executive asked me a question I have now heard, in one form or another, from a dozen leadership teams: "How do I give my people full agency to build with AI without one of them quietly breaking something mission-critical?" It is the right question, and most companies answer it badly in one of two directions. They either lock everything down behind an approval committee, which kills the energy and drives usage into personal accounts, or they let a thousand flowers bloom and discover six months later that the quoting process runs on a spreadsheet automation nobody owns.

There is a better answer, and it is not complicated. You run two lanes.

What Does a Two-Lane AI Governance Operating Model Look Like?

Lane one is the sandbox: anyone in the business can build anything for themselves and their immediate team. Skills, artifacts, personal automations, prompt libraries, little internal tools. No permission forms, no committee. The blast radius is limited by scoped access, not by paperwork. If a coordinator's automation only touches her own drafts folder and a read-only view of the calendar, the worst thing she can break is her own morning.

Lane two is production: the moment anything is depended on by people who did not build it, it crosses a gate. Crossing the gate means four things, every time. A named owner. A review by someone who did not write it. Monitoring, so you find out it broke before your customer does. And a rollback path, so a bad change costs you an hour, not a week.

That is the whole model. Everything else in this post is the detail of how you apply it, because the questions we keep getting from the field ("should I allow skill creation?", "who gets Claude Code?", "who owns a build after it ships?") all resolve inside that frame.

One reason I am confident recommending this now, rather than two years ago, is that the guardrail tooling finally exists off the shelf. Anthropic's government product ships with department-level admin, spend and model limits, and hash-chained audit logs; if that control surface is considered fit for public agencies, your finance team can inherit it rather than build it. You no longer need a bespoke platform team to enforce scoped access. You need to decide where the gate sits.

How Do You Give Employees Full Agency Without Risking Mission-Critical Systems?

You separate agency from access, and you are generous with the first and stingy with the second. Full agency to create means anyone can open the tools and build. It does not mean everyone's build can see the production database, the payment platform, or the CRM's delete permissions. In the sandbox lane, tools connect to personal workspaces, read-only copies, and test data. That single design decision does more for safety than any acceptable-use policy you will ever write, because it makes the safe path the default path rather than the enforced one.

The failure mode to avoid is governing by imagination: writing rules for what people might do instead of constraining what their tools can reach. A policy that says "do not connect AI to client data" gets ignored the first time someone is under deadline pressure. A workspace where the AI simply cannot reach client data does not rely on anyone's memory or virtue.

Direction matters as much as guardrails, though. A sandbox with no direction produces forty duplicate expense-report tools. Give the front line a published list of the processes you actually want attacked (the manual reconciliations, the report assembly, the proposal drafting) and let them pick their targets from it. The best builds we see come from operators solving their own irritations inside a frame leadership set deliberately.

Should You Allow Skill and Artifact Creation?

Yes to both, in lane one, without hesitation. Skills are the new SOPs. A skill is a written, executable version of "how we do this here", which is exactly what your standard operating procedures were always meant to be, except skills actually get followed because the AI reads them every time. Blocking skill creation is blocking your staff from documenting their own work in the one format that now compounds.

Artifacts are even lower risk: they are outputs, documents, dashboards, small interactive tools. If someone builds an artifact that misleads, you correct it the way you would correct a bad spreadsheet. Neither needs a gate until other people start depending on it.

What skill creation does need is management, and this answers a question we hear from every multi-unit business: how do different departments edit and distribute their own skills? The pattern that works is a skill registry per business unit with a named maintainer. Sales owns the sales skills, operations owns the ops skills, and one accountable person in each unit curates what is in the official set. Distribution is an internal library with versioning: when the proposal skill improves, everyone gets the new version, and when it regresses, you roll back. Treat the library the way you treat your policy handbook, with one difference: contributions come from everywhere, curation comes from the maintainer.

The moment a skill crosses units (the pricing skill that sales, finance and delivery all invoke), it has crossed into lane two. Named owner, review, versioning, rollback. Same gate as everything else.

Who Should Get Access to Claude Code or Codex?

Grant access by capability tier, not job title. The question that matters is not "is this person an engineer?" but "can this person read what the agent did and judge whether it is right?" Plenty of analysts, operations managers and finance leads can verify an agent's output in their own domain better than a junior developer could. Plenty of people with technical titles cannot review work outside their patch.

So start with the people who can read the work, whatever their title, and widen the circle as your review tooling matures. The vendors are moving the same direction: Codex now ships multi-agent delegation controls and rollout token budgets, and Claude Code's recent updates hardened its auto-mode rules and added workflow sizing that matches agent count to task size. Those controls exist precisely so that access can be broad while autonomy stays proportionate to trust. Someone in tier one runs agents in a sandboxed repo with every action reviewed. Tier two gets auto-mode inside scoped projects with budgets. Tier three ships to production through the gate like anyone else.

We wrote up the full permission architecture, including what to lock down on day one, in our guide to rolling out Claude Code and Cowork securely. The short version: the tools now carry enterprise controls; your job is deciding the tiers, not building the enforcement.

Who Owns a Build After It Is Deployed?

The team that runs the process owns the build, and the owner is named before launch, never after. "Whoever built it" is not an ownership model, it is a bus-factor problem with a delay on it. The person who built the invoicing automation might be brilliant, and might also resign in March. If ownership defaults to the builder, every departure is a small outage waiting to be discovered.

So the rule at the lane-two gate is simple: nothing ships until a maintainer is named, and the maintainer sits in the team whose process it is. Finance owns the finance builds, whoever wrote them. The builder hands over a one-page runbook (what it does, what it touches, how to turn it off) as the price of admission to production.

This also answers the question of how non-technical people iterate on apps they did not build, which used to be the hard part and mostly is not any more. Agentic tools have made "read the build, describe the change, review the diff" a workflow an operations manager can run: they open the project, tell the agent what should be different, and review the result in plain language before it goes anywhere. The runbook plus a capable agent means the maintainer does not need to be the author. What they need is judgement about the process itself, and they have more of that than the builder did.

Who Should Own AI Internally?

A small enabling council should own the guardrails; the business units should own the outcomes. The council needs three kinds of people and not many of them: an executive sponsor who can spend money and settle disputes, someone from security or IT who owns the access and audit architecture, and one operator from each major unit who knows where the real work happens. Five to eight people in a mid-market firm. They meet fortnightly, and their job is to set the lane-two gate, maintain the guardrails, and unblock builders fast. Their job is explicitly not to build everything themselves or to approve every experiment.

What you must not do is create an AI department that does AI to people. Centralised build teams produce a queue, the queue produces workarounds, and within a year the shadow tools you were trying to prevent are back, except now they are hidden. The council enables; the units execute and are accountable for results.

What Does the Operating Model Look Like With Your Direct Reports?

Every leader owns AI results in their own function, full stop. Your head of sales owns what AI does to sales productivity, your head of finance owns the close-cycle automations, and both of them report on it the way they report on headcount and budget: as part of running their function, with numbers. The moment AI results live with a specialist team instead of the line, your leaders learn to treat adoption as someone else's KPI, and it stalls.

In practice that means three changes to how you run your leadership team. AI goes on the same scorecard as everything else, one line per function, measured in hours returned or cycle time cut, never in "number of tools launched". Each direct report names their unit's skill maintainer and their council operator. And capability building becomes a management duty rather than an HR programme; we covered the staged path in taking a team from AI-literate to AI-first, and the pattern holds: leaders who use the tools themselves get teams who use the tools.

It is worth being clear-eyed about where the value shows up, because it shapes who needs the most attention. Anthropic's own usage data across 1.2 million Cowork sessions shows 33.4% of usage is business-process operations (reporting, checklists, reconciliation) against only 8.7% software development (source). The centre of gravity is your operations staff, not your developers. Govern accordingly.

Where to Start This Quarter

Do four things in the next 90 days. Publish the two-lane rule in one page, so everyone knows the sandbox is open and where the gate sits. Stand up the council and name a skill maintainer per unit. Pick your Claude Code tier-one cohort by who can review, not by title. And put one line on every leader's scorecard.

If you would rather compress that into a fortnight than feel it out over a quarter, our Automation Audit maps your processes, your risk boundaries, and a governance model sized to your team, so you know exactly where your gate belongs before anyone builds a thing.