An AI Governance Framework for Engineering Teams

AI governance for an engineering team does not need a committee or a long policy. It needs six things: an inventory of AI systems, risk tiers that decide how much control each system gets, named approvals, evaluation gates in CI, an incident process with a working kill switch, and a regular review. Start small, tie controls to risk so low-risk work is not slowed, and make every control something you can check rather than something you hope people remember. This is engineering guidance, not legal advice.

Governance has a bad reputation because it is often imagined as a gate that stops work. The useful version is the opposite: a short, shared set of rules that lets teams say yes quickly because the safeguards already exist.

This framework builds on the layers in Enterprise AI guardrails and fits the sequencing in the 90-day adoption playbook. Those posts explain the technical controls; this one explains how a team organises itself around them.

You cannot govern what you cannot list. Keep one inventory of every system that calls a model or runs an agent, including prototypes and tools individuals adopted on their own. Keep each entry short and require it to be filled in before launch.

- name: support-assistant
  owner: "a named person"
  purpose: "Answers customer billing questions from our help documents"
  models: ["approved model list entry"]
  data: ["customer account data"]        # what it can read
  actions: ["draft_reply"]               # what it can do
  autonomy: "human approves before send"
  tier: 2
  last_reviewed: "2026-10-11"

Treat this as the answer to "where is the list of everything that calls a model". An unlisted system is a finding in itself.

Not every system carries the same risk. Tiers let you apply heavy controls only where they matter. Base them on two things: how sensitive the data is, and how much the system can do without a person.

These tiers are an illustration. Define your own, write down what each requires, and keep the scale small enough that people remember it. The approval patterns in when should an AI agent ask permission show how the highest tier works in practice.

Decide who approves what, by name. For each tier, write down the approver and the few questions they check. Short beats thorough: a one-page review that always happens is worth more than a long one that people skip.

• Tier 1: the owner confirms the entry and the data.
• Tier 2: the owner plus a second engineer reviews the evaluation results and the data handling.
• Tier 3: a security reviewer and the business owner approve the identity, the permissions, the approval rules and the kill switch test.
• Tier 4: legal, risk and compliance are involved before any build starts.

Record each approval with a date and a name in the inventory. The review checklist for a new use case can be this short:

New AI use case checklist
[ ] Entered in the inventory with a named owner
[ ] Data it can read is listed and approved for the model in use
[ ] Actions it can take are listed; irreversible ones need human approval
[ ] Uses its own identity with least-privilege access
[ ] Has an evaluation set and passes it in CI
[ ] Logging records who or what did what, without storing more than needed
[ ] Kill switch exists and has been tested
[ ] Tier and approver recorded

Controls that depend on people remembering are weak. Put the important ones in CI so a change that makes the system worse or riskier cannot merge unnoticed.

LLM evaluation fundamentals and how to evaluate AI agents explain how to build the sets these gates run.

AI systems fail in ways that surprise: a wrong answer repeated to many users, an agent acting on a hidden instruction, a cost spike. Decide in advance what happens.

Test the kill switch on a non-production system on a schedule. Not every incident implies a new permanent rule, and a short written review should decide which lessons generalise.

Governance decays when nobody looks. Put a recurring review in the calendar.

Resist the urge to cover everything at once. A framework that covers your highest-risk system well is better than a framework that covers every system badly.

This post is engineering guidance for organising a team. It is not legal advice, and it does not claim to meet any specific law, regulation or standard. If your systems fall under such requirements, involve your legal, risk and compliance teams and read the primary texts that apply to you. The tier 4 row exists to make that handoff explicit.

What is an AI governance framework for engineering teams? A small set of checkable controls that let a team build and run AI systems safely: an inventory, risk tiers, named approvals, evaluation gates in CI, an incident process with a kill switch and a regular review. It is organised around risk so low-risk work stays fast.

Do we need a governance committee? Not for most use cases. A short checklist sized to risk, with named approvers, is usually enough. Reserve escalation to legal, risk and compliance for high-stakes systems, such as those that make regulated decisions about people.

How do I start AI governance with limited time? Build the inventory first, define three or four risk tiers with their controls, and put a quality regression gate and a red-team set into CI for your highest-risk system. Then write the incident process and test the kill switch.

What goes in an AI inventory? For each system: a named owner, its purpose, the models it uses, the data it can read, the actions it can take, its level of autonomy, its risk tier and the date it was last reviewed. Include prototypes and tools individuals adopted on their own.

How should risk tiers be defined? Base them on how sensitive the data is and how much the system can do without a person. A read-only internal tool needs light controls, while a system that acts alone or touches money, identity or access needs approval gates, a least-privilege identity and a tested kill switch.

Is this framework legal or compliance advice? No. It is engineering guidance and does not claim to satisfy any specific law, regulation or standard. If your systems fall under such requirements, involve your legal, risk and compliance teams.

How often should governance be reviewed? Check each new use case before launch, skim the inventory monthly, review tiers, approvers and the model catalogue quarterly, and run a written review after any incident.

• Enterprise AI guardrails: a ten-layer defense in depth
• The 90-day enterprise AI adoption playbook
• How to Deploy AI Agents in the Enterprise: A 2026 Governance Playbook
• AI leadership and strategy topic hub
• AI Engineering Leader roadmap