Who Owns AI Governance? A RACI Worksheet for Four Teams

An agent-authored pull request touches billing/charge.go. It passed CI. The automated reviewer left four comments, two useful. The platform lead says security owns AI risk. Security says this is a code acceptance question, so engineering owns it. Legal was looped in because the change pulled a new dependency with an ambiguous license. Product wants it shipped before the Thursday release. Five days later, nothing has merged and nobody has written down a decision.

Here is the short answer to "who owns AI governance": no single team does, and that is not the problem. The problem is that most AI governance documents assign ownership to teams rather than to decisions. Assign exactly one accountable owner per decision, split tool approval from code acceptance from merge enforcement, and write the escalation default before the first conflict.

This article gives you the worksheet: a decision inventory, a RACI table across platform, security, legal, and product, escalation paths with time bounds and defaults, the pipeline checkpoints that make decision rights enforceable, and a charter skeleton you can fill in this week.

The Meeting Where Nobody Decides

The stall above is not a people failure. It is a decision-rights failure with three conflated questions sitting on top of each other.

Approving a tool is a procurement and data-handling decision. It asks whether this agent, with these permission scopes, sending this code to this model provider, is acceptable. Accepting a change is an engineering judgment about whether this specific diff is correct, maintainable, and owned. Enforcing a merge gate is a platform configuration decision about which checks and approvals are mandatory on which branches. Teams that write one AI policy covering all three end up with a document nobody can execute against.

The ambiguity gets worse because automated review output and merge eligibility are not the same thing. GitHub documents that Copilot code review comments are suggestions and do not satisfy required-review rules the way a human approval does ^[4], while merge eligibility is determined by the branch ruleset you configured ^[5]. If your charter does not say so explicitly, developers will assume an AI review "counted," and reviewers will assume someone else looked harder.

So start with the decisions, not the org chart.

The Decision Inventory That Needs an Owner

Before you assign a single letter, list the decisions. The test for a real decision is simple: it has a possible "no," it has a cost of delay, and it produces a record someone could audit later. If a line item fails all three, it is a guideline, not a decision, and it does not belong in a RACI.

A working inventory for an organization running coding agents usually includes: tool procurement and renewal, agent permission scopes and write access, the AI disclosure convention on pull requests, generated-code boundaries (which paths agents may author in), dependency acceptance, license posture for third-party and training-data questions, data egress to model providers, exception grants against merge gates, and incident attribution when an agent-authored change causes an outage.

Run this as one working session with all four functions in the room. Write the list first. Assign owners second. Mixing the two turns the session into a negotiation before anyone agrees on what is being negotiated.

Note what is missing from the right-hand column: "the AI governance committee." Committees are good at being Consulted. They are structurally incapable of being Accountable, because accountability that is shared is accountability that is deferred.

The RACI Worksheet for Platform, Security, Legal, and Product

Define the four letters in operational terms before you fill the grid, or people will argue about semantics instead of ownership.

- Responsible does the work and can be shared across two functions.

- Accountable is exactly one named person per row who signs the decision and owns the consequence.

- Consulted must respond inside a stated time bound, after which the Accountable owner proceeds.

- Informed receives a notification. Informed is not a veto, and treating it as one is the most common way these grids collapse.

Three assignments trip teams up repeatedly. First, making security Accountable for code acceptance: security should define the criteria and be Consulted, but the person who owns the service owns whether the diff is good. Second, making legal Consulted on every pull request: legal should set standing rules for license categories so that only genuine ambiguity escalates. Third, leaving product merely Informed on risk tradeoffs: if product owns the deadline, product should sign the exception.

One practical constraint keeps the grid usable. If a row needs more than two Consulted parties, the decision is too coarse. Split it. "AI governance" is not a row. "Whether an agent may hold write access to infra/" is.

Escalation Paths That Resolve Instead of Stall

Most escalation paths fail because they name a destination but not a deadline or a default. Write three tiers: the reviewer level, the Accountable owner level, and an executive tiebreaker. Each tier gets a named role, a time bound, and a default action if nobody responds.

The default-action rule is the part teams skip, and it is the part that matters. Every tier must state what happens on silence: hold the merge, revert the change, or ship with a recorded exception. Silence is a decision whether you plan it or not.

Two of the triggers below come directly from risk categories in the OWASP Top 10 for LLM Applications, which covers prompt injection and insecure output handling ^[9]. These are live concerns when an agent consumes repository content, issue text, or fetched pages that could carry injected instructions.

Review Checkpoints Wired Into the Delivery Path

Decision rights only hold where they are enforced. A wiki page describing who approves what has no effect on a merge button. Map each row of your RACI to a checkpoint that exists in the delivery path.

CODEOWNERS maps paths to owning users or teams and, combined with a rule requiring review from code owners, makes approval by the right party a precondition for merge ^[3]. Rulesets define the required pull request, approval count, stale-approval dismissal, and required status checks per branch ^[5], and ruleset insights let you confirm rules are evaluating as intended before you treat them as evidence of control. Merge queues validate each candidate against the latest target-branch state ^[6]. On the release side, artifact attestations tie a published artifact to the workflow and commit that produced it ^[11], and SLSA levels describe how strong that provenance claim is ^[12].

# CODEOWNERS
/billing/            @payments-team @security-reviewers
/infra/              @platform-eng
/.github/            @platform-eng
AGENTS.md            @platform-eng @eng-managers
*.instructions.md    @platform-eng

# Branch ruleset requirements for main
#   require pull request before merge
#   required approvals: 2
#   require review from code owners
#   dismiss stale approvals on new commits
#   required status checks: build, unit, sast, dependency-review
#   merge queue: enabled

Native controls handle the gate. What they do not handle is whether a review understood your conventions, or whether the decision behind a rule is written anywhere an agent will read it. That is where context-aware review and durable decision records fit alongside the platform rather than replacing it: Guardian merge gates record exceptions with an owner and an audit trail on top of your rulesets, SlopBuster reviews pull requests against repository and organizational intent instead of generic diff rules, and Genie institutional memory holds the policies and decision records that reviewers and agents both consult.

Keep the governance text in one place. The AGENTS.md convention supports nested files where the closest file to the working path wins ^[1], and GitHub documents path-specific custom instruction files applied automatically to generation and review requests ^[2]. The same decision record that tells a human reviewer the rule can steer agent behavior, so you are not maintaining two versions of the truth.

Anchor Your Controls to a Named Framework, Not a Memo

Local policy prose ages badly and defends poorly. Use the NIST Secure Software Development Framework as your control backbone and record which existing practices (threat modeling, dependency review, code review, vulnerability response) already cover AI-assisted changes ^[7]. Most of your coverage already exists; you just have not mapped it.

Then overlay NIST SP 800-218A, the community profile that augments the SSDF with practices for generative AI and dual-use foundation models ^[8]. This is how you find the gaps that are specific to model use rather than to software development in general. CISA's Secure by Design material gives you the framing for the conversation with executives: security properties built into the product rather than added afterward ^[10].

Framework mapping changes the RACI in a useful way. Security becomes Accountable for the mapping itself, platform becomes Responsible for implementing each mapped control, and legal becomes Accountable for how the mapping is represented externally to customers and auditors. The artifact is modest: a one-page control mapping stored in the repository next to your instruction files, re-checked whenever an agent is added or its permissions expand. Teams building this out often pair it with a broader AI code governance framework so the mapping sits inside a wider control set.

A Charter Template You Can Tailor This Week

Use this skeleton. It fits on two pages if you resist the urge to add rationale.

1. Scope: named repositories, branches, and change types. Not "all AI usage."

2. Decision inventory: the list from your working session.

3. RACI table: one A per row, named people, not teams.

4. Escalation tiers: trigger, responder, time bound, default action.

5. Review checkpoints: which ruleset, which CODEOWNERS paths, which required checks.

6. Exception process: who grants, what gets recorded, when it expires.

7. Framework mapping: SSDF and SP 800-218A practice references.

8. Revision cadence: a date and a trigger condition.

Write clauses as imperative rules, not intent. Compare "we aim to ensure appropriate oversight of AI-assisted contributions" with these two:

> Agent-authored pull requests touching paths listed in CODEOWNERS under /billing/ require two human approvals, one from @security-reviewers.

> Any merge gate exception expires 14 days after grant and is recorded with the granting owner's name in the exception log. Expired exceptions revert to the default gate automatically.

Each Accountable owner signs the charter by name. Unsigned rows are treated as unowned, and unowned rows are not enforced, because enforcing a rule nobody signed produces resentment and workarounds rather than compliance.

Two charter failures recur. The first is scope so broad it covers all software, which makes every change an AI governance question. The second is leaving revision cadence undefined, which turns the charter into an artifact nobody updates after the agent fleet changes.

The Signals That Tell You Ownership Is Working

Start tracking one signal this week: the share of escalations resolved by the named Accountable owner rather than by an ad-hoc meeting. If that number is low, your grid is decorative.

Then add two more. Unowned changed paths per release, measured against CODEOWNERS coverage, tells you whether changes can still reach production without a qualified reviewer ^[3]. Exceptions granted with a recorded owner and expiry versus exceptions granted informally tells you whether your process survives deadline pressure. DORA's research positions delivery and reliability outcomes as the frame for evaluating capability changes ^[13], so pair these governance signals with your existing delivery metrics rather than reporting them in isolation.

The payoff is that audit requests stop being reconstruction projects. Ownership maps, merge records, check results, and artifact attestations are each queryable configuration plus generated records ^[11][12], which means a release evidence bundle becomes an export. Teams preparing for SOC 2 or sector-specific review will find the same artifacts cover most of the compliance evidence they currently assemble by screenshot.

Now go back to the stalled payment PR. With the charter in place, the license question hits legal's standing dependency rules rather than a fresh escalation. The /billing/ path requires a security reviewer approval by CODEOWNERS, so the "who looks at this" question is already answered. The Thursday deadline becomes an exception request that the named release owner either grants with a recorded expiry or declines. One named decision, one record, no five-day silence.

Frequently Asked Questions

Should one team own AI governance end to end?

No. Ownership belongs to decisions, not functions. One accountable owner per decision, with platform, security, legal, and product each holding different rows.

Can an AI code review satisfy a required review?

Not on GitHub. Copilot code review comments are documented as suggestions that do not satisfy required-review rules the way a human approval does ^[4]. Merge eligibility comes from your ruleset configuration ^[5]. Say this explicitly in the charter so nobody assumes otherwise.

Do we need a separate AI governance committee?

A committee is a reasonable Consulted body and a poor Accountable one. Use it to review the charter quarterly, not to approve individual changes.

Which framework should we map to first?

Start with NIST SSDF for the baseline practices ^[7], then overlay SP 800-218A for the generative-AI specific augmentations ^[8]. That order prevents you from rewriting controls you already have.

How do we keep agents from ignoring the charter?

Put the operative rules in instruction files the agents are specified to read, scoped per directory using nested files ^[1][2], and link out to longer rationale rather than duplicating it.

What to Do Next

Book a 90-minute session with one representative each from platform, security, legal, and product. Spend the first half writing the decision inventory with no letters attached. Spend the second half assigning exactly one A per row and naming the person, not the team. Anything you cannot assign goes on a parking list with a date.

Before that session, run one command's worth of preparation: check your CODEOWNERS file for unowned directories. Every gap you find is a row in the inventory you would otherwise have missed, and it takes about half an hour.

The signal to start tracking this week is escalations resolved by the named owner. Count them for one sprint. If most of your conflicts still end in a meeting, the problem is not that your teams disagree. It is that no row in your charter says who decides.

References

[1] AGENTS.md, "AGENTS.md: an open format for guiding coding agents," 2025. https://agents.md/

[2] GitHub Docs, "Adding repository custom instructions for GitHub Copilot," 2025. https://docs.github.com/en/copilot/how-tos/configure-custom-instructions/add-repository-instructions

[3] GitHub Docs, "About code owners," 2025. https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners

[4] GitHub Docs, "Using GitHub Copilot code review," 2025. https://docs.github.com/en/copilot/how-tos/use-copilot-for-common-tasks/request-a-code-review/use-code-review

[5] GitHub Docs, "About rulesets," 2025. https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets

[6] GitHub Docs, "Managing a merge queue," 2025. https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-a-merge-queue

[7] NIST, "SP 800-218: Secure Software Development Framework (SSDF) Version 1.1," 2022. https://csrc.nist.gov/pubs/sp/800/218/final

[8] NIST, "SP 800-218A: Secure Software Development Practices for Generative AI and Dual-Use Foundation Models," 2024. https://csrc.nist.gov/pubs/sp/800/218/a/final

[9] OWASP, "Top 10 for Large Language Model Applications," 2025. https://owasp.org/www-project-top-10-for-large-language-model-applications/

[10] CISA, "Secure by Design," 2025. https://www.cisa.gov/securebydesign

[11] GitHub Docs, "Using artifact attestations to establish provenance for builds," 2025. https://docs.github.com/en/actions/security-for-github-actions/using-artifact-attestations/using-artifact-attestations-to-establish-provenance-for-builds

[12] SLSA, "Security levels specification v1.0," 2025. https://slsa.dev/spec/v1.0/levels

[13] DORA, "Research and DevOps capability guidance," 2025. https://dora.dev/research/