(The following scenario is a composite illustration drawn from common patterns at regulated institutions; it does not describe a specific bank or event.) At 7:15 a.m. on the second Tuesday of April 2026, the Chief Risk Officer of a $9 billion regional bank received a message from the bank's chief compliance officer with a subject line that read: "Which policy covers the GenAI tool the commercial team started using last month?" The CRO did not know the answer. The bank had an information security policy, a model risk policy, a vendor management policy, and a fair-lending policy. It had a social media acceptable-use policy. It did not have an enterprise AI policy that addressed what happens when a commercial lending team member uses a generative AI tool to draft credit memos, summarize financial statements, and suggest loan structures. The tool was already influencing credit decisions. No policy covered it. No committee had reviewed it. No model owner had been assigned. The bank was a good bank, run by careful people. It simply had not confronted the fact that AI adoption had outpaced its governance infrastructure. That morning began a four-month policy sprint that this lesson is designed to compress into a document the board can approve and the exam team can defend.

Why an Enterprise AI Policy Is Not the Same as a Collection of Existing Policies

The instinct of many compliance and risk leaders, when confronting a governance gap in AI, is to point to existing policies and argue that the coverage is already there. The model risk policy covers AI models. The vendor management policy covers AI vendors. The fair-lending policy covers credit decisions, including those touched by AI. The information security policy covers data handling. Taken together, the argument goes, the institution is covered.

That argument fails in three ways that matter to examiners under OCC Bulletin 2026-13 (the April 2026 interagency model-risk update issued jointly by the OCC (Office of the Comptroller of the Currency), the Federal Reserve, and the FDIC (Federal Deposit Insurance Corporation), which superseded OCC 2011-12 and pulled AI and generative AI under a unified governance framework).

First, the argument assumes that every AI tool used at the institution is covered by the model risk policy, which requires that the tool have been identified, inventoried, and assigned a model owner. For many institutions in 2026, the inventory gap is the gap. Tools are in use that no one has registered. The enterprise AI policy's first function is to establish the scope: every use of AI across every business line and function is in scope, and the policy defines the intake process that catches a commercial lending team's new GenAI tool before it becomes a governance finding.

Second, the argument assumes coordination among the separate policies that does not automatically exist. When a credit officer uses a vendor-supplied AI summarization tool to review a borrower's financial statements, the interaction implicates the model risk policy (if the tool influences a credit decision), the vendor management policy (the vendor's data-handling obligations), the fair-lending policy (if the summary affects the adverse action reasons), and the information security policy (the borrower's financial data is non-public personal information (NPPI), the term used under GLBA for customer financial data held by financial institutions, also referred to more broadly as personally identifiable information (PII)). No individual policy governs the intersection. The enterprise AI policy creates a cross-cutting governance layer that assigns responsibility for the intersection rather than assuming each policy's owner will coordinate spontaneously.

Third, the argument about coverage through existing policies does not address generative AI tools specifically. OCC 2026-13 distinguishes between traditional quantitative models, which were governed under OCC 2011-12, and AI and GenAI tools, which have different risk characteristics: hallucination risk (the model produces plausible but incorrect output), confidentiality risk (input data may be processed by external servers), auditability risk (the chain from input to output is not always inspectable), and scope-creep risk (tools acquired for one purpose used in decision processes they were not reviewed for). An enterprise AI policy addresses these characteristics explicitly; a patchwork of pre-existing policies that predate the GenAI era does not.

The Architecture of a Defensible Enterprise AI Policy

A defensible enterprise AI policy, meaning one that satisfies OCC 2026-13's governance expectations and can be defended in an examination, has seven structural elements. Each element addresses a specific governance obligation, and the absence of any one of them creates a gap that an examiner will identify.

Element one: scope statement. The policy must define, precisely, what counts as AI for purposes of its coverage. The definition must capture: traditional quantitative credit models; machine learning (ML) and gradient-boosted models used in credit scoring, fraud detection, or BSA/AML (Bank Secrecy Act / Anti-Money Laundering) alert triage; GenAI tools used for drafting, summarizing, or extracting information from documents; third-party AI components embedded in vendor platforms (such as the AI pre-scoring embedded in a loan origination system (LOS) platform); and AI agents or automated workflow tools that take action based on AI outputs. The scope must also address what is not in scope: basic automation that follows deterministic rules without any learning or predictive component, standard statistical tools that do not meet the definition of a model under the model risk policy, and individually operated productivity tools with no connection to customer or transaction data. A scope statement that is too narrow misses the tools creating the most risk; one that is too broad buries the governance program in low-stakes oversight.

Element two: governance authority and ownership structure. The policy must name the governance body responsible for AI oversight at the enterprise level. For most regulated banks, this is an AI governance committee (or an expanded model risk committee with AI-specific scope) that reports to the board's risk committee. The policy must define the committee's composition (which typically includes the Chief Risk Officer, the Chief Compliance Officer, the Chief Information Officer, and a designated model risk lead), its meeting cadence, its quorum and approval requirements, and its escalation path to the full board. The policy must also define the role of the AI governance function at the operating level: the model risk management (MRM) team (model risk management is the institutional function responsible for validating, monitoring, and governing AI and quantitative models), which conducts or commissions independent validation; the fair-lending compliance function, which conducts disparate-impact testing; and the business line AI champion or model owner, who is the named institutional employee accountable for each AI tool's governance.

Element three: intake and approval process. Before any AI tool is deployed in a business function, the tool must complete a defined intake process. The intake process must include: a use-case description (what the tool does, what data it uses, what outputs it produces, how those outputs influence decisions); a risk classification (low, medium, high) based on the potential for harm, the materiality of the decisions the tool influences, and the regulatory exposure the tool creates; a governance pathway appropriate to the risk classification (low-risk tools may proceed with documented review and monitoring, medium-risk tools require model risk review, high-risk tools require independent validation and board approval); and an inventory registration confirming the tool is in the model inventory before deployment. The intake process is the mechanism that prevents the scenario that opened this lesson: a tool in active use with no governance record.

Element four: use standards, which are the rules that govern AI use across lending, deposits, and operations. The use standards section is the most operationally detailed part of the policy, and it is where the policy's cross-cutting function is most visible. The use standards must address: the human accountability rule (AI outputs inform human decisions; the human who acts on the output owns the decision and its regulatory consequences; "the model said no" is never a legally sufficient adverse action reason under the Equal Credit Opportunity Act (ECOA) and Regulation B (12 CFR Part 1002, issued by the CFPB), which implements ECOA and governs adverse action notice requirements and the prohibition on discrimination in credit transactions based on protected characteristics); the verification obligation (any AI-generated number, summary, date, or legal reference that will influence a decision or appear in a customer-facing document must be independently verified against the source document before use); the adverse action protection rule (in any credit function, the adverse action reasons provided to an applicant must be human-determined and must not be delegated to an AI tool's output without independent review); and the data classification rule (AI tools may not be used with non-public personal information (NPPI), also called PII, except through tools that have been reviewed and approved under the information security and vendor management programs).

Element five: vendor and third-party AI governance requirements. The policy must define what the institution requires of any vendor supplying an AI tool, consistent with the OCC 2026-13 TPRM (third-party risk management, the institutional program governing vendor selection, contracting, oversight, and termination) framework. The vendor requirements must include: the contract terms required for AI vendors (material change notification, examination cooperation, data governance, liability allocation); the due diligence standard for AI vendors (including AI-specific elements beyond the standard financial and security review); and the institution's right to conduct independent validation and fair-lending testing of vendor AI tools using the institution's own data. The policy must also address the concentration risk created when the institution relies on a small number of AI vendors for critical functions, and must require that the institution's AI vendor landscape be reviewed annually for concentration exposure.

Element six: ongoing monitoring and reporting obligations. For every AI tool in the inventory, the policy must require ongoing monitoring at a frequency and depth appropriate to the tool's risk classification. High-risk AI tools in credit functions require monthly or quarterly monitoring of score distributions, approval and denial rates, and fair-lending disparity metrics. Medium-risk tools require semi-annual monitoring. Low-risk tools require annual review. All monitoring results must be reported through the governance chain: model owner to the MRM team to the AI governance committee to the board risk committee. Material findings (including a triggered disparity threshold, a model performance degradation, or a governance gap discovered in a vendor audit) must be escalated within a defined timeframe rather than held for the next reporting cycle.

Element seven: incident response and model recall procedures. The policy must define the process for identifying, escalating, and responding to AI-related incidents, which are events in which an AI tool produced incorrect, discriminatory, or harmful output that affected a customer decision. The incident response procedures must include: a detection mechanism (monitoring thresholds and audit log review); an escalation path that reaches the AI governance committee and the board within a defined timeframe for material incidents; a remediation process (suspending the tool, notifying affected customers, correcting decisions where possible, and documenting the remediation); and a post-incident review that identifies the governance failure that allowed the incident to occur and updates the policy or procedures to prevent recurrence. A bank without defined AI incident response procedures discovered in an examination is a bank with an incomplete governance framework under OCC 2026-13.

How the Policy Applies Across Lending, Deposits, and Operations

The enterprise AI policy's value is precisely its cross-cutting scope. Separate policies for lending AI, deposits AI, and operations AI would create three governance programs with potential gaps at their intersections and no mechanism for enterprise-level visibility into cumulative AI risk. The enterprise AI policy applies uniformly across functions, while the use standards section acknowledges that the regulatory exposure is different across functions.

In lending, the regulatory exposure is the highest. Every AI tool that influences a credit decision, from the pre-screening algorithm that determines whether an application is eligible to apply to the underwriting support tool that drafts the credit memo, is a tool that can generate adverse action liability under ECOA and Regulation B, disparate impact liability under the fair-lending laws, and model-risk governance findings under OCC 2026-13. The lending use standards must reflect this exposure: the human accountability rule is non-negotiable, the verification obligation applies to every AI-generated number in a credit file, and the adverse action protection rule requires that adverse action reasons be determined by a human reviewer who has independently assessed the file, not delegated to the AI tool's summary or output.

In deposit operations, the regulatory exposure is different but not absent. AI tools used in deposit account opening, fraud detection for deposit transactions, and dispute resolution for deposit errors may involve less direct credit-decision liability, but they still create UDAAP (Unfair, Deceptive, or Abusive Acts or Practices, the consumer protection standard enforced by the CFPB and federal banking regulators) exposure if AI tools produce systematically unfair outcomes for protected groups, and they still create privacy exposure if GLBA (Gramm-Leach-Bliley Act, the federal law governing financial institutions' obligations to protect customer financial information) obligations for customer financial data are not met in the AI tool's data handling. The deposit use standards emphasize the UDAAP review obligation and the data governance requirement.

In operations broadly, including back-office functions like payments processing, BSA/AML alert triage, and servicing correspondence generation, AI tools reduce operational cost and cycle time at scale. The enterprise AI policy must ensure that the governance program for operational AI is proportionate: high-volume operational AI tools that affect individual customer outcomes at scale (a BSA/AML alert triage model that generates roughly 90 to 95% false-positive rates in the industry) still require monitoring and governance, but the governance intensity may differ from an underwriting support tool. The operations use standards emphasize the proportionality principle: governance intensity should match risk, with the model risk classification driving the depth of review.

Board Approval and the Governance Chain

OCC 2026-13 is explicit about board-level AI governance: the board of directors is responsible for understanding the institution's AI risk posture and for setting the risk appetite within which the AI program operates. This is not a delegation to management. The board must receive periodic reporting on the AI program's risk profile, the model inventory's status, material findings from monitoring and examinations, and the institution's cumulative AI risk exposure. A board that has delegated all AI oversight to the management's AI governance committee without any direct board-level visibility does not satisfy the bulletin's board governance requirements.

The enterprise AI policy formalizes the governance chain from the model owner at the working level to the board. The chain typically runs: model owner reports to the MRM team lead; the MRM team lead reports to the AI governance committee quarterly; the AI governance committee reports to the board risk committee at each regular meeting; and the board risk committee escalates material issues to the full board. Material issues that bypass the normal reporting cycle and go directly to the board risk committee include: a fair-lending disparity above the threshold that triggers regulatory notification, a model recall affecting a high-volume credit product, an examination finding at a "Needs Improvement" or higher severity level, and any AI incident that has affected a customer decision and may require consumer remediation.

The board approval process for the enterprise AI policy itself follows the institution's standard policy governance process: management drafts the policy, legal and compliance review it, the AI governance committee approves the draft for board submission, the board risk committee reviews and recommends, and the full board approves. The policy should be reviewed and re-approved at least annually, with a mid-cycle review triggered by any of the following: a material change in the institution's AI vendor landscape, a new regulatory guidance that updates the governance expectations, a material examination finding affecting AI governance, or a significant expansion or reduction in the institution's AI use.

The board approval is not ceremonial. Under OCC 2026-13, the board's approval of the enterprise AI policy constitutes a governance record demonstrating that the board has reviewed and accepted the institution's AI risk framework. An examination finding that the board was not aware of significant AI tools in use at the institution, or that the board had not approved a policy governing their use, is a board governance finding that typically accompanies a request for a remediation plan with board-level ownership and a specific timeline.

The Policy Document: What It Must Contain and What It Should Not

The enterprise AI policy is a governance document, not an operational manual. It should be written at a level of specificity that allows an examiner to assess whether the institution has a functioning governance framework, without being so operationally specific that every system change or vendor update requires a policy revision. The distinction between policy (what the institution requires and why) and procedure (how the institution implements the requirement in a specific process) is the distinction between a document the board can own and a document that becomes outdated before the board approves it.

The policy must contain: the scope statement; the governance authority structure; the intake and approval process at the design level (who approves, what must be documented, what risk classification determines the pathway); the use standards applicable across all functions; the vendor requirements; the monitoring and reporting obligations; and the incident response framework. Each element should be stated with enough specificity to create a clear obligation but enough flexibility to accommodate the different AI tools and functions the institution operates.

The policy should not contain: specific vendor names (vendor relationships change); specific model names or version numbers (models change); detailed step-by-step procedures for conducting validation or fair-lending testing (these belong in the MRM team's procedures); specific software tool requirements (technology evolves); or specific dollar thresholds for budget approval of AI tools (these belong in the authority matrix).

A common error in enterprise AI policy drafting is the inclusion of a technology section that describes how specific AI tools work at the architecture level. This section is typically inserted by a technology team member who is uncomfortable with the policy's lack of technical specificity, but it creates a policy document that is technically detailed in some areas and governance-focused in others, confuses the document's audience (the board, not the IT department), and requires technical updates every time the institution's AI tools evolve. The policy should describe what AI does and what governance the institution requires, not how specific implementations achieve those goals.

Length and format matter. A policy that is too short (under five pages) signals a governance framework that has not been thought through; a policy that is too long (over thirty pages) signals a document that was written by a committee without a clear sense of what the board needs to own versus what management needs to operate. The right length for an enterprise AI policy for a community or regional bank is typically eight to fifteen pages of substantive policy text, with appendices for the risk classification matrix, the intake checklist, and cross-references to related policies.

Operationalizing the Policy: From Paper to Practice

A policy that exists on paper but is not consistently applied creates a specific examination problem: the documentation suggests a governance framework that does not match the institution's actual behavior. This mismatch is sometimes more damaging than an admitted gap, because it raises questions about whether the institution's governance was designed to look compliant rather than to be compliant. The operationalization of the enterprise AI policy must close the gap between the written commitment and the daily practice.

The first operationalization challenge is the AI inventory. The policy's scope statement covers all AI tools across all business lines. The inventory must reflect that scope. In most institutions, the initial inventory exercise reveals tools in use that were never formally reviewed: AI features embedded in third-party LOS platforms, AI-powered credit bureau data augmentation products, AI summarization tools adopted by individual lending officers using personal accounts on commercial AI platforms. Each of these tools must be evaluated under the intake and approval process. The practical approach is to conduct an institution-wide AI discovery audit within ninety days of policy adoption, with a formal findings report to the AI governance committee. Tools identified in the audit that do not pass the intake process must be either remediated or discontinued.

The second operationalization challenge is training. The use standards are only enforceable if the staff subject to them understand them. The enterprise AI policy requires a training program: at minimum, a mandatory annual training for all staff using AI tools in any customer-facing or decision-influencing function, covering the human accountability rule, the verification obligation, the data classification rule, and the adverse action protection rule. Specialized training for lending staff should address the specific application of these rules to credit file work, including how to structure a credit memo that uses AI-assisted drafting while satisfying the documentation requirements of OCC 2026-13.

The third operationalization challenge is the monitoring program. A policy that requires quarterly monitoring of high-risk AI tools creates an obligation that must be staffed. If the MRM team does not have the capacity to conduct the required monitoring at the required frequency, the monitoring obligation exists on paper but not in practice. The capacity assessment for AI governance is a planning obligation: before the policy is finalized, the institution should assess whether the MRM team, the fair-lending compliance function, and the business line model owners have the time, skills, and tools to meet the monitoring requirements. Gaps in governance capacity identified before the policy is adopted are planning problems; gaps identified in an examination are findings.

Key Takeaways

• An enterprise AI policy is not a collection of existing policies: it provides the cross-cutting governance layer that coordinates scope, authority, use standards, vendor requirements, monitoring, and incident response across all AI tools and all business lines in a single document the board can approve and an examiner can assess.
• OCC Bulletin 2026-13 requires board-level AI governance: the board must approve the enterprise AI policy, receive periodic reporting on the AI program's risk profile, and be informed of material findings. A board that has delegated all AI oversight to management without direct board visibility does not satisfy the bulletin's requirements.
• The seven structural elements of a defensible enterprise AI policy are: scope statement, governance authority structure, intake and approval process, use standards across lending and deposits and operations, vendor and third-party AI governance requirements, ongoing monitoring and reporting obligations, and incident response and model recall procedures.
• The human accountability rule is the non-negotiable core of the use standards: AI outputs inform human decisions, and the human who acts on the output owns the decision and its regulatory consequences. "The model said no" is never a legally sufficient adverse action reason under ECOA and Regulation B.
• The intake and approval process is the mechanism that closes the governance gap revealed by the scenario that opened this lesson: every AI tool must complete intake before deployment, and tools already in use that have not completed intake must be identified in the initial inventory audit and remediated within a defined timeline.
• Policy and procedure are distinct documents: the enterprise AI policy states what the institution requires and why, at a level of specificity the board can own; operational procedures describe how the MRM team, fair-lending function, and model owners implement those requirements in practice. Conflating the two produces a document that is neither a governance instrument nor an operational guide.
• Operationalizing the policy requires three things beyond the document itself: a complete and current AI inventory, a training program that reaches every staff member using AI tools, and a governance capacity assessment confirming the MRM team and compliance functions have the resources to meet the monitoring obligations the policy creates.