The AI Governance Field Guide
A complete, standalone guide to building AI governance — wherever you’re starting from
How this guide helps a C-level leader sponsoring AI governance: validate your challenges using the Gut Check, identify the areas of opportunity, and align your teams on the goal.
How this guide helps a product team building AI products day to day: it helps you implement governance from wherever you are in your journey — not just an end-to-end plan, but the specific practices, because that’s where traditional governance actually falls short.
Start with “Why this exists” below. If you’re starting from nothing, go straight to “If you’re starting from zero.” If you already have some governance in place, the seven practices are your working reference.
Why this exists
Most published AI governance guidance today is regulatory-scale: hundreds of control objectives, written for examiners and audit committees, meant to be implemented by a compliance function. That’s necessary — but it isn’t something a product team can run on a Tuesday morning.
This guide is the other half of that picture: seven practices, designed to be owned by the people actually building AI products, not the people auditing them afterward. It’s deliberately proportional — a small team can start with three of these; a large organization can run all seven at scale. Nothing here requires a dedicated compliance department to begin, and nothing here requires an existing governance program to build on. If you have nothing today, this guide gets you from zero to operating.
This doesn’t replace your regulatory obligations — it’s how a product team actually operationalizes them. If you’re required to run something like NIST AI RMF, FS AI RMF, ISO 42001, or the EU AI Act, this guide is the day-to-day layer underneath it: the audit-ready documentation feeds the audit trail those standards require; the vendor and third-party risk assessment built into the shared tooling is what supply-chain risk requirements ask for in practice; the structured alignment sessions are where a governance policy actually gets followed instead of sitting in a binder. Adopting this doesn’t reduce what you’re required to have — it’s what makes what you’re required to have actually work.
Model risk management guidance doesn’t cover this yet — its authors say so directly. Banks running SR-26-2 (the Federal Reserve, OCC, and FDIC’s 2026 interagency model risk management guidance) already have a mature model governance program. But that guidance explicitly states generative and agentic AI models are excluded from its scope, applying only to traditional statistical and quantitative models. That’s not a loophole — it’s the gap this guide is built to fill. If your organization’s model risk framework was built around SR-26-2 or its predecessor, generative and agentic AI systems are very likely running today with no equivalent governance layer above them at all.
Even where regulation is mandatory, it’s brand new and largely untested. The EU AI Act is the one framework here that’s genuinely binding rather than voluntary — but as of August 2026, its most consequential enforcement powers only just activated, and its strictest high-risk system rules don’t take effect until December 2027. NIST AI RMF and FS AI RMF remain voluntary in most jurisdictions today. That gap doesn’t lower the bar — it means the practical, day-to-day layer of governance still has to be built by the organization itself, ahead of enforcement catching up rather than in response to it. In practice, that means three things, starting now, not after the next regulatory update: publish the documentation standard for every live AI system, even if no one’s asking for it yet. Run the design-stage review on anything currently in flight, retroactively if it was skipped. Get the vendor/third-party risk assessment done on every external model or API already in production — don’t wait for a mandate to find out what data you don’t currently control.
If you’re starting from zero
You don’t need a governance function, a budget, or executive sign-off to begin. Here’s the actual sequence, in order, assuming nothing currently exists.
Month 1 — Get one system fully documented and one person accountable. Pick your single highest-risk AI system in production today (use the AI Risk Assessment Tool if you’re not sure which one that is). Write its model card, decision log, data lineage record, and approval trail from scratch — even if it’s retroactive. Name one person, even part-time, as that system’s governance point of contact. That’s it. Two things exist that didn’t before.
Month 2 — Turn what you just did into a repeatable template, and do it again. Take the documentation you wrote in Month 1 and strip it into a blank template — four sections, no content, just the structure. Apply it to your second-highest-risk system. This is the moment “documentation” turns from a one-off exercise into a reusable asset.
Month 3 — Add the checkpoint, before your third system gets built. For the next new AI system entering development, hold one structured design-stage conversation before any code is written: what’s the architecture, how much autonomy does it have, where does a human stay in the loop, what’s the vendor/third-party exposure. Thirty minutes, with whoever’s playing the governance-partner role. This is the first time governance happens before a launch instead of at one.
Month 4 and beyond — Layer in the rest as volume grows. Once you have two or three systems running this way, the remaining practices stop being optional and start being obviously necessary: shared tooling once manually checking vendor risk gets repetitive, model demos once there’s enough in production to periodically re-examine, structured alignment sessions once disagreements between teams start happening often enough to need a standing forum instead of an email thread.
This sequence is deliberately small at the start. The goal in month one isn’t governance maturity — it’s proving the model works at all, on one system, with one person, so month two isn’t a leap of faith.
The 7 Practices
1. Audit-Ready Documentation Standard
What it is: A fixed, minimal set of living documents for every AI product — not a generic “documentation policy,” a specific list:
- Model card (what it does, what it doesn’t, intended use, known limitations)
- Decision log (why this approach, what alternatives were rejected and why)
- Data lineage record (where the data came from, how it was handled)
- Approval trail (who signed off, at what stage)
Why it matters: When a regulator, auditor, or new stakeholder asks “how do you know this is safe,” these four documents are the answer — not a scramble to reconstruct history.
How to start this from zero: Don’t design a template first — document one real system, in full, using this minimal skeleton:
- Model card: system name / purpose / intended use / explicitly out-of-scope use / data sources / known limitations / owner / last reviewed date
- Decision log: the approach chosen / alternatives considered / why they were rejected / date and decision-maker
- Data lineage record: where the data originated / what happened to it before it reached the model / any sensitive fields involved
- Approval trail: who signed off / at what stage / what they were shown when they did
Fill this in for your highest-risk live system this week. The template emerges from that first real example — don’t build the blank form before you have a filled one.
- Team level: one shared folder per product, four templates, updated as the product changes — not written once and forgotten.
- Enterprise level: a central registry aggregating every product’s documentation, version-controlled, searchable across the portfolio.
2. Risk Partner Embedded in the Product Team
What it is: A named person with governance/risk expertise assigned directly to a product team or group — not a shared central function teams have to request time from.
Why it matters: Embedding catches issues at the design stage, when they’re cheap to fix, instead of at the launch gate, when they’re expensive and political.
This only works if the expertise is real, current, and shared. A guide defines where a risk partner sits and when they’re consulted — it doesn’t make them literate in AI-specific threats like prompt injection, adversarial manipulation, or training-data poisoning. That literacy has to be built deliberately: hire for it explicitly when standing up the role, rather than assuming a general risk or security background covers it; build a real onboarding path for existing staff moving into it; and treat ongoing formal training as ongoing, not a one-time step, since AI-specific attack patterns keep evolving.
And this isn’t the risk partner’s job alone to carry. Security and governance are a shared responsibility across the whole product team — data science, engineering, product, business — not something outsourced to one embedded specialist while everyone else stays uninvolved. The risk partner brings the deepest expertise and coordinates the work; recognizing and avoiding the risks is everyone’s job.
How to start this from zero: Don’t hire. Name someone who already exists on or near the team — even at 20% of their time — as the accountable point of contact for one product’s AI governance. The role exists the moment someone owns it, not when headcount is approved.
- Team level: one point of contact who sits in product meetings, not just review meetings.
- Enterprise level: a distributed network of risk partners operating against shared standards, with a lightweight path to escalate anything unusual.
3. Reusable Governance Templates
What it is: A shared library covering the governance work every team repeats: risk assessment, bias/fairness check, third-party AI vendor questionnaire, incident response plan.
Why it matters: Without this, every team reinvents governance from scratch, at different quality levels, at 5x the cost.
How to start this from zero: The first template should come from the second time you do something, not the first. Do the vendor risk assessment or the risk assessment manually once, in full. The second time you’re about to do it, stop — turn what you just did into a fill-in-the-blank version instead of writing it from scratch again.
- Team level: pull a template, fill it in, move on.
- Enterprise level: templates are version-controlled and centrally maintained, with usage tracked so gaps are visible.
4. Common Utility Access
What it is: Shared infrastructure every product team can plug into rather than build themselves — for example, a model registry, a bias/fairness testing tool, a central risk-scoring dashboard, a red-team/prompt-testing sandbox.
Why it matters: This is what turns governance from “a project each team does alone” into “a checkbox each team can hit quickly,” because the hard infrastructure already exists.
This includes vendor and third-party model risk assessment as standard due diligence, not a special case — any time a third-party LLM or API sits inside a workflow, the team should know exactly what data leaves the organization, where it lands, and what the vendor’s own data-handling commitments are before that model goes live.
How to start this from zero: Don’t build a platform. Start with a shared spreadsheet or lightweight tracker listing every AI system, its vendor(s), what data reaches each vendor, and the vendor’s data-handling terms. This single artifact does the job of a “model registry” long before anyone builds real infrastructure — and it’s the thing that eventually justifies building that infrastructure, once it gets too big to manage by hand.
- Team level: self-serve access — no ticket, no waiting on a specialist team.
- Enterprise level: a small platform function maintains and evolves the shared utility stack as needs grow.
5. Design Review as a Governance Checkpoint
What it is: A structured review before build begins — not a rubber stamp after launch. This is where architecture-level risk decisions get made: build vs. buy, how much autonomy the system has, where a human needs to stay in the loop, and how the system resists misuse (data poisoning, prompt injection, an unmonitored third-party model becoming an exit point for sensitive data).
Why it matters: The most expensive governance failures are architectural, decided in week one and discovered in month six. Catching them here is far cheaper than catching them later, once the system is already live and being demoed to a review board. Security has a seat at this table by default — not as an add-on requested after something goes wrong.
How to start this from zero: Before the next new AI system starts development, book one thirty-minute conversation with whoever’s playing the risk-partner role. Four questions are enough to start: what’s the architecture, how autonomous is it, where does a human stay in the loop, and what third-party data exposure does it create. Write down the answers. That’s the review — it doesn’t need a committee or a formal process to be real the first time.
- Team level: a short, checklist-driven session with the embedded risk partner — not a multi-week process.
- Enterprise level: review outcomes logged and pattern-matched across products to catch systemic issues before they repeat.
6. Model Demos, Reviews & Cards
What it is: Before launch, and periodically after, the team presents a live demo alongside the model card to a review group — not paperwork alone.
Why it matters: A ten-minute live demo surfaces things a document never will. It also builds organizational muscle memory — people start to recognize what “good” actually looks like, not just what the policy says it should look like.
This is also the mechanism for re-tiering autonomy over time: what required a human sign-off at launch may not need one six months later, once the track record justifies it. That decision should be made explicitly, here, using accumulated evidence — not left to quietly drift on its own.
How to start this from zero: Once you have even one system in production, put a recurring 30-minute slot on the calendar — monthly is enough at the start — where someone actually runs the system live in front of the risk partner and one other stakeholder. No slide deck. Just the system, running, with someone asking questions in real time.
- Team level: a recurring internal show-and-tell with the risk partner and one senior stakeholder.
- Enterprise level: a rotating review board across product lines; findings feed back into the shared templates and the shared tooling stack so they keep improving.
7. Structured Alignment Sessions
What it is: A fixed-cadence forum — not an ad hoc meeting — bringing product, risk, legal, and engineering together to resolve a specific decision or trade-off.
Why it matters: Most governance breaks down not because people disagree, but because there’s no known place or moment to resolve the disagreement. This replaces a slow, informal escalation chain with a known cadence and known decision rights.
How to start this from zero: You don’t need a standing committee on day one. The first version of this is simply naming, in writing, who has final say when product, risk, and engineering disagree on one specific type of decision — for example, whether a system is autonomous enough to launch. One sentence of clarity here removes most of the ambiguity that later turns into a slow email chain.
- Team level: tied to milestones — design review, pre-launch, quarterly check-in.
- Enterprise level: a standing forum with explicit decision rights and a clear escalation path to leadership when it can’t be resolved at the table.
How the practices fit together
- Documentation, templates, and shared tooling — the foundation. Built once, reused constantly.
- The embedded risk partner — the connective tissue. A person who makes the foundation actually get used.
- The design review and the model demo — the checkpoints. Where risk gets caught before and after launch.
- Structured alignment sessions — the release valve. Where disagreements get resolved instead of stalling quietly.
What this actually costs
- Documentation, an embedded risk partner, and a design-stage review typically start with reassigning existing staff, not new hires — this is the lowest-cost entry point, and the one the zero-to-start sequence above builds first.
- Reusable templates and shared tooling are the real platform investment, and the one that scales with how many product teams you’re supporting — this is where meaningful budget goes, once volume justifies it.
- Model demo reviews and structured alignment sessions cost calendar time and a standing meeting, not new roles.
Stress-tested against real questions
This guide is written to hold up against the specific problems teams actually run into, not just describe a clean process in theory:
| Real question | Answered by |
|---|---|
| Adding more reviewers isn’t fixing the slowdown — why? | An embedded risk partner instead of a shared queue, and a design-stage checkpoint instead of a launch-gate |
| Which decisions can the system make on its own, and who decided that? | Autonomy re-tiering at the model demo stage, backed by explicit decision rights from the structured alignment sessions |
| We keep discovering security issues after launch, not before | Security has a seat at the design-stage review by default |
| We don’t know what data a third-party AI vendor actually has access to | Vendor risk assessment as standard due diligence, built into the shared tooling |
| Nobody knows who’s actually allowed to approve what | Explicit decision rights from the structured alignment sessions, not just a meeting cadence |
| Governance keeps arriving after the product is basically built | A design-stage checkpoint, not a launch-gate rubber stamp |
| Every team is reinventing governance work from scratch | The shared documentation standard, templates, and tooling |
| Our risk/security staff don’t actually understand AI-specific threats | Deliberate literacy-building built into the embedded partner role — hire, train, and ongoing formal development, not assumed |
| Security feels like one person’s job, and everyone else stays uninvolved | Explicit shared-responsibility framing — the embedded partner coordinates, but recognizing and avoiding risk is the whole product team’s job |
| We have nothing today — where do we even start? | The month-by-month build sequence above, starting with one system, one person, one week |
Where a real situation doesn’t map cleanly to a row above, that’s a signal worth treating seriously — either this guide has a genuine gap, or the situation belongs in the org-specific work (capacity redesign, decision-rights politics, live calibration) that sits outside what a published guide can solve on its own.
Where to go next
Start by scoring your specific AI system with the AI Risk Assessment Tool — its High/Medium/Low tier tells you how much of this guide to apply and how rigorously. Run the AI Governance Gut Check to see exactly which of the seven practices you already have. Then start with the Month 1 sequence above — one system, fully documented, one person accountable.