TL;DR

• 44% of financial firms using AI tools have no formal testing or validation — which means compliance teams are approving deployments without a consistent question set to anchor the review.
• The compliance team’s role in AI approval isn’t to re-run technical testing. It’s to confirm nine governance conditions are met before go-live: use case, customer impact, data sensitivity, explainability, vendor review, bias testing, monitoring, issue ownership, evidence.
• Three categories require escalation before approval — not just documentation: adverse customer impact without explainability, bias testing not completed for consequential decisions, and vendor AI with no due diligence performed.
• NIST AI RMF’s MAP function and the Treasury FS AI RMF both require documented use case context before deployment — this checklist is the compliance operationalization of that requirement.

Engineering tells you the AI tool is deploying in three weeks. What do you ask?

This is the scenario every compliance team at a bank or fintech has faced in the past 18 months. The product team found a vendor tool they want to use for customer onboarding screening. Or the engineering team built a model that recommends loan terms. Or the CTO approved a GenAI integration in the customer service chatbot. You hear about it two weeks before it goes live.

The question isn’t whether to ask anything — it’s whether you have a consistent set of questions ready, or whether you’re improvising each time and hoping you don’t miss something an examiner will ask about later.

According to NContracts research on AI adoption at investment advisory firms, 44% of firms that have implemented AI tools internally have no formal testing or validation of their outputs. That’s the governance gap compliance is being asked to close — and closing it requires a structured pre-approval question set, not a judgment call made under deadline pressure.

Why Compliance Needs Its Own Checklist

The technical team validates whether the model works. Compliance validates whether the deployment is permissible — whether the regulatory conditions for go-live have been met, the governance ownership is documented, and the evidence exists to defend the decision in an exam.

These are different questions. The data scientist confirms the model’s accuracy, robustness, and performance metrics. Compliance confirms:

• The use case is within the scope approved at the product level
• Customer impact has been assessed and documented
• Regulatory obligations triggered by the use case have been identified
• Adverse action and explainability requirements have been addressed
• Bias/fairness testing has occurred where required
• Monitoring ownership and escalation triggers are defined

Without a consistent checklist, compliance teams rely on practitioner memory — which means the questions depend on who happens to be in the room and what they happen to think of. That’s not governance; it’s luck dressed as process.

The NIST AI Risk Management Framework’s MAP function establishes that organizations should establish AI system context — including use case, affected parties, impact categories, and applicable requirements — before deployment. The Treasury FS AI RMF, released March 2026 with 230 control objectives, maps specific pre-deployment requirements across GOVERN, MAP, MEASURE, and MANAGE functions. Neither framework tells you what questions to ask in practice. The checklist below operationalizes both.

The Nine Pre-Approval Question Categories

1. Use Case Scope

The most common AI approval mistake: approving a use case based on a general description, then discovering the tool is being used in a context that changes the risk profile entirely.

Key questions:

• What specific decision, recommendation, or output does this tool produce?
• What workflow does it plug into — and could that workflow change without triggering re-review?
• Is this use case the only intended application, or is the tool being deployed across multiple use cases simultaneously?
• If this is a vendor tool: does the vendor’s permitted use policy cover this specific use case?

Red flag: “We’re using it for AI-assisted customer communications” is too vague. “We’re using it to draft initial responses to customer complaints before a human reviews them” is an approved scope.

2. Customer Impact

The single most consequential question for regulatory exposure. Any AI output that touches a customer-facing decision, recommendation, or experience opens regulatory obligations.

Key questions:

• Does any output from this tool directly affect a customer?
• Does the output determine, recommend, or influence any customer-facing decision — approval, denial, pricing, service level, support routing?
• Could a customer be financially harmed, denied a benefit, or treated differently if the output is wrong?
• Is there a consumer-facing product or service that depends on this output without human review between the model output and the customer outcome?

Red flag: “The model is advisory — a human reviews the output” is not a safe answer if the human review is pro forma and the model output is almost never overridden. Effective automation triggers regulatory obligations regardless of nominal human-in-the-loop.

3. Data Sensitivity

Regulators and bank partners increasingly ask not just what the AI does, but what data you’re feeding into it — especially when that data includes customer PII processed by a third-party vendor’s model.

Key questions:

• What customer data is input into the tool?
• Does the input include PII, financial data, health data, immigration status, or protected class indicators?
• Where is input data stored during and after processing — on-premise, vendor cloud, third-party API?
• Does the vendor have access to the data, and is that access within your data sharing agreements and GLBA/privacy policies?
• If this is a GenAI tool: are employees entering customer data into prompts, and does the tool retain that data for model training?

Red flag: Employees using a public LLM API and entering customer account information into prompts without a data processing agreement in place. This is a GLBA Safeguards Rule violation in addition to an AI governance gap.

4. Explainability and Adverse Action

For any AI tool that influences decisions affecting customers — credit, account access, service eligibility, pricing — explainability is a legal requirement under ECOA and FCRA, not a best practice.

Key questions:

• If the AI output is negative or adverse for a customer, can the reason be explained in plain language?
• Has adverse action notice language been reviewed by legal/compliance for this use case?
• Can the model’s output be explained to a regulator or in litigation?
• Is there a human reviewer with enough model understanding to defend the decision independently, or does the AI function as a black box?
• For credit decisions: does the adverse action notice template capture the reason codes this model produces?

Red flag: Any use case that results in a customer being denied, restricted, or differently priced where the only response compliance can give to “why” is “the model said so.” That is not a defensible adverse action process under ECOA.

5. Vendor Reliance

Third-party AI tools require the same scrutiny as internally built models — with the added complexity that you can’t audit the underlying training data or model architecture directly.

Key questions:

• Is this a third-party tool? If so, has an AI due diligence questionnaire been sent and returned?
• Does the vendor’s SOC 2 or equivalent certification cover the specific AI features being used?
• Does the vendor contract include: audit rights, incident notification timelines, data handling provisions, and a requirement to notify you of material model changes?
• What is the vendor’s process for notifying customers (you) when they update the underlying model?
• Does the vendor offer a model card or transparency documentation?

Red flag: Deploying a third-party AI tool that processes customer data without a data processing agreement, or without contract language covering model version change notification. The full AI vendor due diligence framework covers what these contracts should require.

6. Bias and Fairness

For any AI use case that affects protected class members — which includes most consumer-facing financial decisions — bias testing is not optional.

Key questions:

• Has the tool been tested for disparate impact on protected classes (race, gender, age, national origin, disability)?
• Who performed the bias testing — the vendor, the internal model risk team, or an independent third party?
• Has the testing been documented in a form that could be produced to a regulator?
• If disparate impact was identified, was it remediated before deployment — or is deployment proceeding with known disparate impact pending remediation?
• Are there ongoing monitoring KRIs that will detect demographic outcome shifts post-deployment?

Red flag: Any tool used in credit underwriting, insurance pricing, fraud scoring, or employment with no bias testing documentation. Colorado’s AI Act (effective June 2026) and CFPB’s Reg B disparate impact provisions (effective July 21, 2026) make this legally required for high-impact decisions. The Massachusetts AG’s $2.5M settlement with a student loan company in July 2025 — requiring a fair lending governance program for AI — is the template for what state enforcement looks like.

7. Monitoring

Pre-deployment approval without post-deployment monitoring is governance theater. The approval should include confirmation that monitoring is in place before the tool goes live.

Key questions:

• What KRIs exist for this AI use case post-deployment?
• Who reviews those KRIs, how often, and in what forum?
• Is there a re-assessment trigger list — the conditions that would require a formal re-review rather than waiting for the annual review cycle?
• What is the escalation path if a monitoring KRI hits amber or red?
• For vendor AI: will compliance receive notification from the vendor if the underlying model is materially updated?

Minimum monitoring triggers should include: vendor model version change, output accuracy falling below a defined threshold, first customer complaint referencing an AI output, demographic outcome shift flagged in monitoring data, and expansion of the use case beyond the approved scope.

8. Issue Ownership

When an AI output causes customer harm, there should be no ambiguity about who owns the incident response. In most programs, there is.

Key questions:

• If this tool produces an output error that causes customer harm, who is the designated incident owner?
• Is AI-related harm covered by your existing incident response playbook, or does it require a separate escalation path?
• Who can override the AI’s output — and is there a documented override process with an audit trail?
• If a customer files a complaint about an AI-driven decision, who owns the investigation and response?

9. Evidence Retained

The pre-approval review is only valuable if someone can prove it happened — in six months, during an exam, or when the tool produces an adverse outcome that leads to a regulatory inquiry.

Minimum evidence artifacts:

• Completed compliance pre-approval checklist with date and reviewer name
• Risk tiering classification (high/medium/low) with rationale
• Issue tracker entry or governance system record reflecting approval decision
• For high-risk use cases: named management approver sign-off
• Documentation of any open items identified in the review and the plan for resolution

The Full Pre-Approval Checklist Structure

Red flags in the Explainability, Bias/Fairness, or Vendor columns require escalation before approval — not just documentation.

The Regulatory Context in 2026

Three frameworks are converging to make this checklist a regulatory expectation rather than a best practice.

SR 26-02 and OCC Bulletin 2026-13 require pre-deployment validation for traditional models at banks over $30B, but explicitly exclude generative AI. NIST AI RMF and the Treasury’s FS AI RMF fill that gap — and both require documented use case context before deployment. The EU AI Act (August 2, 2026 for high-risk systems) requires conformity assessments before deployment for high-risk AI in financial services. Colorado’s AI Act (effective June 2026) requires documented risk assessments for high-impact automated decisions.

The pattern: every major framework requires documented pre-deployment review. What none of them give you is a specific question set. The nine categories above operationalize that requirement into something a compliance team can run in a meeting.

If you’re building this process from scratch, the AI Risk Assessment Template & Guide includes the full pre-deployment checklist, use case tiering logic, vendor due diligence questionnaire, and eight worked examples across the AI use cases most common in financial services. The checklist above covers the compliance pre-approval gate; the template covers the full lifecycle from inventory through post-launch monitoring.

So What?

The compliance function’s role in AI governance isn’t to become a model validator. It’s to be the governance gate — ensuring that the questions that create regulatory liability have been answered, ownership has been assigned, and the documentation exists to defend the decision in an exam or in litigation.

The tool that goes live without those nine question categories answered isn’t ungoverned because nobody cared. It’s ungoverned because the process to ask the questions didn’t exist when the deployment was on a three-week timeline. That process starts with a checklist, built in advance, that compliance runs every time — not just when the use case is obviously high-risk.

The hardest AI deployment to catch is the one that seems low-stakes. The customer service chatbot that turns out to be making account restriction recommendations. The workflow automation that turns out to be the decision layer nobody reviewed. The nine-category checklist catches those cases before they’re on an examiner’s list of findings.

Equip your team with the right questions, and run them consistently. The AI Risk Assessment Template & Guide gives you the operational toolkit to get there.