Back to blog
GOVERNANCE June 9, 2026 ยท 11 min read

The Engineering Leader's Guide to AI Governance Frameworks

Every CTO and Head of AI is being asked the same two questions this quarter: "is our AI investment paying off?" and "how do we know it isn't being misused?" Most engineering orgs cannot answer either with confidence. The tools shipped faster than the governance did.

An AI governance framework is the answer. Not a 200-page policy PDF that nobody reads, but a practical operating model that gives leadership real visibility into how Claude, Cursor, Copilot, and ChatGPT are being used across the team - and what that usage is actually producing.

This guide walks through the framework we recommend for engineering organizations adopting AI coding assistants at scale. It is built for VPs of Engineering, Heads of AI, and CTOs who need to govern AI tool adoption without strangling the productivity gains that made the investment worth it in the first place.

What an AI governance framework actually covers

A workable AI governance framework for engineering organizations covers five layers. Each layer answers a specific question leadership will eventually have to answer to the board, to finance, or to a security review.

1. Access and provisioning. Who is allowed to use which AI tools, on which seats, against which data?

2. Usage attribution. What is each seat actually being used for? Which repos, which projects, which engineers?

3. Quality and safety. Are AI outputs being reviewed? Are hallucinations and failures being caught before they ship?

4. Cost attribution. Where is LLM spend going? Which teams, projects, and individuals are driving it?

5. ROI measurement. Is the AI investment producing measurable business outcomes - shipped features, reduced cycle time, fewer bugs?

Most organizations have a policy for layer 1 and nothing for the other four. That is the gap a real governance framework closes.

Layer 1: Access and provisioning

Start here because it is the cheapest layer to get right and the most expensive layer to get wrong. The governance question at this layer is simple: who has access to what, and is that access reviewed?

Practical controls:

  • Centralize seat provisioning through SSO. No personal email signups on company-paid Claude, Cursor, or Copilot seats.
  • Maintain a single source of truth for which engineers are entitled to which tools, tied to role and team.
  • Run a quarterly access review. Engineers who have not used a seat in 60 days should lose it.
  • Document which data classes each tool is approved for. Production customer data, source code, internal docs, and public information all carry different risk profiles.

This layer is necessary but nowhere near sufficient. A clean access list tells you who could be using a seat. It tells you nothing about what they are doing with it.

Layer 2: Usage attribution

This is where most governance frameworks fall apart, because vendor dashboards do not give you the data you need. Anthropic, Cursor, and GitHub will tell you a seat was active. They will not tell you which repo it touched, which project it served, or whether the work mapped to a sprint ticket.

The governance question at this layer: for any given seat in the last 30 days, can you say what percentage of activity was on company work versus personal or side projects?

If you cannot answer that question, the seat is effectively unmonitored. Not because anyone is being negligent - because the visibility was never built into the tool.

What good attribution looks like:

  • Prompts attributed to the repository they referenced, not just the user who typed them.
  • Token spend split by repo, project, and engineer - in that order of usefulness.
  • Time-of-day and day-of-week patterns visible per seat, so off-hours moonlighting becomes a chart, not a rumor.
  • Model selection per task, so you can see when Opus is being used for problems Haiku would handle.

This is the layer where Tommbo does the most work. The product correlates every AI session with the engineer, repo, and project it touched, then surfaces side-project and personal-repo usage on company seats with full context - not just a flag.

Layer 3: Quality and safety

AI coding assistants ship code that compiles. That is not the same as code that is correct, safe, or aligned with your architecture. A governance framework needs a layer that catches the difference before it reaches production.

Practical controls:

  • Treat AI-generated PRs the same as human PRs for review. No special fast lane.
  • Track AI failure modes that matter: hallucinated APIs, deprecated patterns, security regressions, broken tests dismissed instead of fixed.
  • Set up failure alerts so spikes in AI-generated bugs surface within hours, not after the retro.
  • Measure AI output quality per engineer over time. An engineer whose AI-generated PRs get rejected at 3x the team rate is a coaching opportunity, not a mystery.

The governance question here: when AI breaks, do you find out from a dashboard or from a customer?

Layer 4: Cost attribution

LLM spend grows quietly. A single team experimenting with Opus on every task can double the monthly bill before finance notices. Governance at this layer is the difference between defending the AI budget and apologizing for it.

What good cost attribution looks like:

  • Spend broken down by team, project, and individual engineer - not just by seat.
  • Per-task model right-sizing recommendations: which prompts are running on a more expensive model than they need?
  • Trend lines that show whether spend is tracking with output or decoupling from it.
  • Budget guardrails per team, with alerts before limits are hit.

Tommbo analyzes the complexity of each task and recommends the cheapest model that can handle it well, typically cutting LLM spend 40-70% with no quality loss. That kind of recommendation only works when cost is attributed at the task level, not the seat level.

Layer 5: ROI measurement

This is the layer the CFO and the board actually care about. Every other layer feeds into it. The governance question: is the AI investment producing measurable outcomes that justify the spend?

What good ROI measurement looks like:

  • Productivity scores per engineer that combine prompts sent, lines of code accepted, tokens spent, and time taken - so engineers using AI well are visible, and engineers using AI poorly are too.
  • Outcome metrics that connect AI usage to shipped features, reduced cycle time, and reduced bug rates.
  • Cost-per-shipped-feature trends that show whether AI is actually compressing delivery cost.
  • A single scoreboard that leadership can open without asking IT for a custom report.

This is the layer most engineering orgs skip because it requires honest numbers. It is also the layer that decides whether the AI budget gets cut next quarter or doubled.

How to roll out an AI governance framework without slowing engineers down

The fastest way to kill an AI governance program is to make it feel like surveillance. Engineers will route around any system that adds friction to their day. A good framework is invisible to engineers doing the right thing and only surfaces when something is genuinely off.

Three rollout principles:

1. Measure before you mandate. Spend the first 30 days collecting baseline data on how AI tools are actually being used. Do not write policy in a vacuum.

2. Make the dashboard the policy. A single shared scoreboard that everyone can see does more than a 50-page policy document. Visibility is the lightest-weight governance there is.

3. Action only on outliers. Do not chase every anomaly. Set thresholds and alerts that surface the seats that genuinely matter - moonlighting, runaway cost, repeated quality failures.

A governance framework that engineers respect is one that catches real problems and ignores noise. That balance is the entire job.

Where Tommbo fits

Tommbo is built to be the operational layer for the governance framework described in this guide. It handles layers 2 through 5 - usage attribution, quality and safety, cost attribution, and ROI measurement - across Claude, Cursor, Copilot, and ChatGPT, on Mac, with setup in minutes.

Layer 1 stays in your identity provider. Everything downstream of provisioning is what Tommbo measures, attributes, and surfaces on a single scoreboard built for CEOs, CTOs, and Heads of AI.

If your org is adopting AI coding tools at scale and the governance question is starting to come up in board meetings, the right next step is to see your own data on a real dashboard. [Sign up now](https://agentwatch.tommbo.com/login) and have a working AI governance scoreboard in under ten minutes.