FFIEC AI Compliance Checklist for Financial Institutions
This FFIEC AI compliance checklist turns technology-neutral examination themes into eight gradable checks for AI governance, inventory, risk, lifecycle controls, access, logging, providers, and assurance. Each check names an accountable owner, pass criteria, retained evidence, and the condition that sends the item to remediation.

A committee deck marks AI inventory complete in green while provider invoices show two tools missing from the register. This FFIEC AI compliance checklist fails that row. Grade each check pass, out of scope, or remediate. Then attach an owner and due date. Include the source record. A green box should mean the stated pass criteria worked on a selected system during the review period.
TL;DR
- Grade eight checks with an owner and test date. Record the source evidence and open action, then add the retest result.
- Reconcile AI inventory to provider and identity records. Check network and deployment records, along with payment records, before accepting coverage.
- Test an approved case and a blocked or failed case. Policy text alone does not prove operation.
- FFIEC's cited booklets are technology-neutral; this checklist applies their examination themes to AI.
Check 1: assign governance and decision rights
Owner: the board-designated management function. Enterprise risk and business owners provide support.
Pass criteria: the institution identifies who approves an AI use and owns its business outcome. It records who accepts residual risk and operates the system. It also identifies who tests controls and reports material issues. Policies cover internal and acquired AI. They also cover third-party AI. Committee charters and escalation thresholds align with the institution's risk appetite. Board reporting shows decisions and credible challenge for material uses.
Evidence: approved policy and role matrix. Include the committee charter and meeting minutes. Retain the risk-acceptance record and training record, along with a current management report. The FFIEC Architecture, Infrastructure, and Operations booklet asks examiners to evaluate defined responsibilities and accountability. It also covers policies and independent review. Examiners assess communications and resources, along with board reporting.
Remediate when: one general AI owner field hides separate business, risk, security, and operational responsibilities, or an exception has no authorized acceptor.
Check 2: reconcile the AI and data inventory
Owner: IT asset management. Enterprise architecture and data governance provide support.
Pass criteria: the inventory covers production and pilot AI. It includes internal and vendor-embedded AI, along with local and hosted AI. Each row identifies the business process and owner. It records the application and provider. It also names the model or service and status. The row includes data sources and data classification. It documents integrations and criticality, along with the route and lifecycle phase. A dated reconciliation compares the register with provider bills and procurement records. It checks single sign-on and API telemetry, along with cloud assets and deployment records.
Evidence: frozen inventory export and data dictionary. Include architecture and data-flow diagrams. Retain reconciliation results and discrepancy tickets, along with approval. AIO examination procedures call for comprehensive information and technology inventories and regular validation. They require current environment representations and attention to shadow IT. They also ask about data analytics sources and design parameters. Access controls and activity monitoring are examined as well.
Remediate when: the system name is present but its embedded model, provider route, data source, or production version remains unknown. Use AI data lineage for audit to connect sources to deployed uses.
Check 3: document risk and acceptance before use
Owner: enterprise risk with the business owner. Information security and privacy provide support, along with legal and compliance.
Pass criteria: each material AI use has a dated risk assessment tied to its actual purpose and data. The assessment identifies users and the provider. It documents the architecture and downstream action, along with failure modes. Mitigation and acceptance decisions name an owner and approval authority. Reviews recur at a risk-based interval and on material change. Unmitigated or transferred risks follow a controlled acceptance process.
Evidence: inherent and residual risk assessment and threat model. Include the data classification and control plan. Retain the legal or compliance analysis and accepted-risk record. Add the review trigger and management report. The Development, Acquisition, and Maintenance booklet asks examiners to review continuous risk management and documented metrics. Its procedures also address lifecycle assessments and formal acceptance. They cover emerging reports and stakeholder involvement.
Remediate when: the assessment says generative AI risk without naming the data, action, route, or loss scenario for the selected use.
Check 4: control development, acquisition, and release
Owner: the product or application owner. Change management and information security provide support.
Pass criteria: approved requirements and acceptance criteria precede release. Testing covers function and integration. It also covers security and resilience. Misuse and relevant data-quality or model-performance conditions are tested as well. Every material model and prompt change has impact analysis. The same applies to retrieval and policy changes, along with API and configuration changes. Each change has approval and version control. Retain the test output and implementation evidence. Include rollback planning and post-implementation review.
Evidence: requirements and risk-linked test plan. Include executed results and unresolved-defect disposition. Retain the signed release manifest and change request. Add the deployment log and rollback record, along with closure. The Development, Acquisition, and Maintenance work program reviews project records and QA reports. It examines activity logs and testing. It also covers controls throughout lifecycle phases and auditable change records. Its examination objective states that risk mitigation should apply regardless of technology type.
Remediate when: a moving provider alias reaches production without a resolution record, impact assessment, or approved acceptance result.
Check 5: restrict identity and access
Owner: identity and access management. The application and data owners provide support.
Pass criteria: named human and service identities receive least-privilege access through approved roles. Agent identities follow the same requirement. Privileged access and production changes are segregated. Joiner and mover events update access promptly. Leaver events do as well. Service credentials are scoped and rotated. Access reviews include AI applications and provider consoles. They cover data stores and model registries. Prompt repositories and logs are included, along with policy administration.
Evidence: role design and access requests with approvals. Include the account inventory and privileged-session records. Retain recertification output and service-account ownership. Add denied events and the revocation test. The FFIEC Information Security booklet addresses authorization and privileged access. It covers segregation of duties and account monitoring. Its controls extend across applications and databases, along with networks and supporting systems.
Remediate when: a shared service credential is the only identity attached to a customer-facing request and the application cannot identify the user or agent that initiated it.
Check 6: collect and protect operating records
Owner: security operations. Records management and application engineering provide support.
Pass criteria: the institution records material AI activity with synchronized time and the system version. It retains principal context and destination. The record includes applicable policy and decision, along with the outcome. Retention follows approved legal and operational requirements. Access is restricted and collection gaps are monitored. Sensitive fields are protected and historical records can be retrieved. Integrity tests detect alteration or deletion attempts.
Evidence: logging standard and schema. Include the retention approval and store permissions. Retain sample events and gap alerts. Add the integrity test and deletion rejection, along with archive retrieval and independent review. The Information Security booklet's log-management section calls for processes to collect and aggregate security information. It also requires analysis and correlation. The section discusses retention and integrity. It covers restricted access and capacity, along with backup and monitoring. Independent review is also addressed.
Remediate when: the dashboard shows current volume but cannot reproduce the policy version and model destination for an older selected event. Tamper-evident audit logs for AI covers a separate evidence write path.
Check 7: oversee AI providers and embedded services
Owner: third-party risk management with procurement. The business owner and security provide support, along with legal.
Pass criteria: due diligence and contracting cover the actual AI service and data use. They address access and subcontractors. The review includes security and availability. It covers incident handling and change notice. Audit or assurance rights and record access are documented. Termination and data disposition are covered as well. Ongoing monitoring compares performance and issues with contract terms. Material provider changes return to risk and change review.
Evidence: due-diligence file and contract with service levels. Include the provider inventory and data-flow record. Retain assurance reports and exception analysis. Add performance reports and the issue register, along with the change notice and exit test. AIO procedures ask examiners to assess provider roles and contract risks. They cover data destruction and independent assurance. Issues and board reporting are also examined. The Development, Acquisition, and Maintenance booklet adds acquisition and supply-chain lifecycle controls.
Remediate when: procurement reviewed the corporate vendor while the application uses a different model service, subprocessor, region, or retention setting.
Check 8: test assurance and close findings
Owner: internal audit or another independent assurance function, with control owners responsible for remediation.
Pass criteria: a risk-based plan defines scope and methods. It sets frequency and independence, along with acceptance criteria. Testers select from complete populations and cover design and operation. Reports identify root cause and priority. They name the owner and due date, along with repeat findings. Corrective action receives independent retesting before closure. Material results reach authorized management and the board.
Evidence: assurance plan and tester qualifications with independence. Include frozen populations and sample rationale. Retain workpapers and raw outputs. Add findings and action plans. Keep retests and closure approvals, along with reporting. The Information Security booklet distinguishes control design from operation and calls for testing and evaluation with appropriate coverage and depth. It also calls for appropriate independence. AIO procedures begin with prior reports and outstanding issues. They examine corrective action and root cause, along with retesting.
Remediate when: the control owner selects only successful examples and performs the test. The owner then closes the resulting issue without independent challenge.
DeepInspect
DeepInspect sits between an authenticated application or agent and an LLM endpoint on routed HTTP traffic. It evaluates application-supplied identity and workflow context. It applies destination and content policy. It inspects the response and writes a signed, tamper-evident decision record with the policy version and timestamp.
That boundary can support checks for routed request policy and event evidence. It can also support historical retrieval. IAM owns identity proofing. Business and risk owners keep their decisions and evidence. The same applies to model and data owners. Third-party and legal owners retain their records, along with compliance and audit owners. Embedded and local inference remain outside the route. Book a technical deep dive at deepinspect.ai.
Frequently asked questions
- Is this an official FFIEC AI checklist?
It is an operational application of the cited FFIEC IT Examination Handbook booklets to AI systems. The FFIEC sources are technology-risk guidance and examination procedures; they do not present these eight checks as a dedicated AI rule.
- Does every check apply to every AI tool?
Scope and depth should reflect the institution's size and complexity. They should also reflect the business and data, along with the architecture and risk. Mark a check out of scope only with a dated rationale and approver. Convenience is not a scope reason.
- Can a policy document pass a check?
A policy can satisfy part of the design evidence. The pass criteria also require a selected operating example and expected result. Record the actual result and source artifact, along with any follow-up.
- How should partial coverage be graded?
Mark it remediate. Record the covered systems and missing route. Identify the missing owner and evidence, along with the control. Add an interim measure and target date. Upgrade the result only after a documented retest.
- Where can an HTTP control point receive credit?
Credit it for authenticated application-to-LLM HTTP requests that actually traverse the point. Local and embedded inference stay with separate controls. Direct browser use and vendor-managed calls outside that path do as well.