AI Governance Policy Template: What to Include and How to Customize It

TL;DR:

• An AI governance policy needs 8 core sections — from scope and risk classification to exception handling and third-party provisions
• The Treasury’s new FS AI RMF (February 2026) gives you 230 control objectives to map your policy against — use it as your compliance backbone
• Don’t write a 50-page aspirational document nobody reads. Write a policy that tells people exactly what to do when they want to deploy an AI model next Tuesday

Your AI Governance Policy Is Probably a Glorified Mission Statement

Here’s the uncomfortable truth: most AI governance policies in financial services right now are two pages of principles stapled to a vague commitment to “responsible AI.” They read like a LinkedIn post — lots of values, zero operational guidance.

That’s a problem, because regulators don’t examine values. They examine evidence. When the OCC examiner asks how you govern AI, “we believe in fairness and transparency” won’t cut it. They want to see the approval workflow, the risk classification criteria, the escalation path when someone deploys an unsanctioned model. They want the policy — and proof you follow it.

The good news: building a real AI governance policy isn’t as hard as it sounds, especially now that the U.S. Treasury’s Financial Services AI Risk Management Framework (FS AI RMF), released February 19, 2026, gives you a concrete control framework to map against. The FS AI RMF introduces 230 control objectives across governance, data, model development, validation, monitoring, third-party risk, and consumer protection — built by more than 100 financial institutions in coordination with the Financial Services Sector Coordinating Council (FSSCC) and the Cyber Risk Institute.

Here’s how to build an AI governance policy section by section, with enough specificity that it actually changes behavior.

Section 1: Purpose, Scope, and Applicability

This section answers two questions: what counts as AI and who does this policy apply to?

Both questions are harder than they sound. The Treasury’s new AI Lexicon (released alongside the FS AI RMF in February 2026) exists precisely because financial institutions were using 15 different definitions of “AI” across business lines. Your policy needs a single, clear definition.

What to include:

• Definition of AI systems covered by the policy. Don’t limit this to machine learning models — include rule-based decision systems, robotic process automation with adaptive logic, generative AI tools, and third-party AI embedded in vendor products. Reference the Treasury AI Lexicon for standardized terminology.
• Scope boundaries. Does this cover only production systems or also sandbox/experimentation environments? What about employee use of commercial AI tools (ChatGPT, Copilot)? Be explicit.
• Applicability matrix. Map which business units, functions, and roles fall under this policy.

Common mistake: Scoping too narrowly. If your policy only covers “machine learning models” and someone deploys a generative AI chatbot that gives investment advice, you’ve got an uncontrolled AI system in production. Scope to the function (automated or augmented decision-making), not the technology.

Section 2: AI Risk Classification Tiers

Risk classification is the engine of your entire governance framework. Everything else — approval requirements, monitoring frequency, documentation depth — flows from how you tier your AI systems.

The NIST AI RMF 1.0 recommends contextual risk assessment tied to potential harms, and the FS AI RMF operationalizes this into adoption stages with mapped control expectations. Your policy should define 3-4 tiers:

Critical detail: Your classification criteria must be specific enough that two independent reviewers would tier the same system the same way. “Significant consumer impact” is ambiguous. “Direct influence on credit approval, account closure, or pricing decisions affecting individual consumers” is not.

Under Colorado SB 24-205 — the Colorado AI Act that took effect February 1, 2026 — deployers of “high-risk AI systems” must use reasonable care to protect consumers from algorithmic discrimination. If your institution operates in Colorado (or serves Colorado residents), your Tier 1 and Tier 2 classifications need to map to SB 205’s high-risk definition: AI systems making or substantially influencing consequential decisions in education, employment, financial services, housing, insurance, or legal services.

Section 3: Roles and Responsibilities

The single biggest failure point in AI governance isn’t technology — it’s accountability. When nobody owns the risk, nobody manages it.

McKinsey’s 2025 Global AI Survey found that AI governance is typically “jointly owned,” with respondents reporting an average of two leaders in charge. In practice, “jointly owned” often means nobody is clearly accountable when something goes wrong.

Your policy needs a RACI matrix for AI lifecycle decisions:

Recommended ownership structure for mid-to-large financial institutions:

• AI Governance Committee — Sets policy, approves Tier 1 deployments, resolves cross-BU disputes. Chaired by CRO or designated AI Risk Officer. Members: CTO/CIO, Chief Data Officer, Head of Compliance, business line leaders, Legal.
• Model Risk Management (MRM) team — Validates models pre-deployment, reviews ongoing performance, maintains model inventory. Reports to CRO.
• First Line (Business Units) — Develops and operates AI systems. Owns use case documentation, initial risk assessment, and ongoing monitoring within thresholds.
• Second Line (Risk/Compliance) — Independent challenge. Reviews risk assessments, validates controls, monitors regulatory changes.
• Third Line (Internal Audit) — Periodic assessment of governance framework effectiveness. Reports to Audit Committee.

This maps directly to the three lines of defense model that SR 11-7 (Federal Reserve/OCC model risk management guidance) expects. The FS AI RMF’s governance control objectives reinforce this: its Risk and Control Matrix includes specific controls for role assignment, escalation paths, and accountability documentation.

For smaller institutions without a dedicated MRM team: The CRO or Chief Compliance Officer typically owns AI risk governance. Consolidate second-line functions but don’t eliminate independent challenge — that’s the capability examiners will ask about first.

Section 4: Approval and Deployment Workflows

This is where your policy prevents shadow AI. If people can deploy models without going through a defined process, your governance framework is decorative.

Pre-deployment approval workflow (Tier 1 example):

For Tier 3-4 systems: Compress this into a 2-week process with business line approval and standard documentation. Don’t make people wait 100 days to deploy an internal FAQ bot — that’s how you get shadow AI.

Mandatory gate: No AI system enters production without (a) registration in the centralized AI inventory, (b) completed risk classification, and (c) approval at the appropriate level. No exceptions without the formal exception process (see Section 7).

Section 5: Ongoing Monitoring and Validation

Deployment isn’t the finish line — it’s where governance actually starts. Models degrade. Data drifts. The assumptions you validated in month one may not hold in month six.

Monitoring requirements by tier:

What triggers an unscheduled review:

• Performance metrics breach defined thresholds (specify: accuracy drop >X%, false positive increase >Y%)
• Regulatory guidance changes affecting the model’s domain
• Material changes to input data sources or populations
• Consumer complaints or fair lending concerns related to model outputs
• Business strategy changes altering the model’s use case

The FS AI RMF Control Objective Reference Guide — a 400+ page document released by the Cyber Risk Institute — provides specific evidence examples for each monitoring control. If your examiners ask “how do you know this model still works?”, the answer should be documented, dated, and traceable.

Section 6: Documentation Standards

Documentation is governance’s proof of life. If it isn’t written down, it didn’t happen — at least as far as examiners are concerned.

Required documentation artifacts for every AI system:

1. Model card / AI system card — Purpose, intended use, limitations, training data summary, performance metrics, known biases, owner, approval date
2. Risk assessment — Tier classification with rationale, mapped regulatory requirements, identified risks and mitigations
3. Validation report (Tier 1-2) — Conceptual soundness review, data quality assessment, performance testing results, limitations analysis
4. Monitoring records — Ongoing performance tracking, drift reports, revalidation outcomes, incident logs
5. Change log — Version history, material changes, re-approval documentation
6. Exception documentation — Any deviations from standard policy, approver, expiration date, compensating controls

Version control is non-negotiable. Every model iteration gets version-controlled. Every validation gets timestamped. Every approval gets signed. SR 11-7 has expected this for traditional models since 2011 — the same standard applies to AI.

Pro tip: Build documentation templates into your development pipeline, not as an afterthought. If data scientists have to fill out a 30-page Word document after they’ve already deployed, it won’t happen. Integrate model cards into your CI/CD process.

Section 7: Exception and Escalation Procedures

Every policy needs a pressure valve. The goal isn’t zero exceptions — it’s documented, time-bound, approved exceptions with compensating controls.

Exception process:

1. Request. Business line submits exception request specifying: which policy requirement, why it can’t be met, proposed compensating controls, and requested duration.
2. Risk assessment. Second-line risk function evaluates the residual risk with compensating controls in place.
3. Approval. Exceptions to Tier 1 requirements require Governance Committee approval. Tier 2-3 exceptions require senior management (one level above the model owner). All exceptions documented in the exception register.
4. Time limit. Maximum 12 months. No perpetual exceptions. Renewal requires fresh justification and approval.
5. Monitoring. Exception effectiveness reviewed at each regular monitoring cycle. Compensating controls tested.

Escalation path for policy violations:

• Unregistered AI system discovered → Immediate cease-use order pending registration and risk assessment. Escalate to CRO within 24 hours.
• Model deployed without required approval → Production rollback within 48 hours unless safety risk requires immediate action. Incident documented.
• Monitoring threshold breach → Automated alert to model owner and MRM. Tier 1 breaches escalate to Governance Committee within 72 hours.

Section 8: Third-Party AI Provisions

This is the section most policies miss entirely — and it’s increasingly where the risk lives. When your fraud detection vendor updates their model, or your cloud provider embeds generative AI into your document processing, you’re consuming AI you didn’t build, validate, or monitor.

What your policy should require for third-party AI:

• Inventory. All third-party AI systems registered in the same centralized inventory as internal models. No shadow vendor AI.
• Due diligence. Before procurement, assess: vendor’s own AI governance practices, model documentation availability, update notification process, explainability capabilities, bias testing approach.
• Contractual requirements. Mandate model change notification, right to audit, performance data access, and incident notification. Include these in vendor agreements, not just side letters.
• Ongoing monitoring. Monitor third-party AI outputs the same way you monitor internal models. You can outsource the model; you can’t outsource the regulatory accountability.

The FS AI RMF explicitly includes third-party risk among its 230 control objectives. Regulators have made clear through interagency guidance on third-party risk management that outsourcing an activity doesn’t outsource the associated risk management obligations.

Putting It Together: Your 90-Day Implementation Roadmap

So What? Why This Can’t Wait

The FS AI RMF is voluntary today. But as Lowenstein Sandler noted in their analysis, “while federal government oversight may be less aggressive, state regulators look to guidance like this to understand emerging best practices.” Colorado’s AI Act is already enforceable. More states are following.

The institutions that build governance infrastructure now — while the framework is still non-binding — will be ahead when examination expectations harden. The ones that wait will be scrambling to retrofit governance onto AI systems that have been running ungoverned in production for years.

That retrofit is exponentially harder and more expensive than building it right from the start.

Need a head start? Our AI Risk Assessment Template gives you pre-built risk classification frameworks, assessment templates, and documentation structures that map to NIST AI RMF and the new FS AI RMF control objectives — so you’re not starting from a blank page.