AI Model Governance Checklist for Financial Services

Artificial intelligence already intervenes in financial activities such as credit assessment, fraud detection, and certain operational decisions. Its use can expand capabilities, but it also makes it more important to know which models are deployed, who is accountable for them, and how their failures are detected.

This checklist helps risk, compliance, data, and technology officers review controls throughout the lifecycle. It is a self-assessment tool, not a certification or legal advice. Regulatory and supervisory references have different scopes; each entity must determine which ones apply to it based on its activity, location, and supervision.

1. Responsibilities and Scope

• Is there an AI and model governance policy approved by the corresponding level of authority and reviewed when activities or risks change?
• Are the business, development, independent validation, risk management, compliance, and technology owners identified?
• Have escalation paths been defined for unexpected results, incidents, disputes, or internal control breaches?
• Does management receive sufficient information to supervise relevant risks, without relying solely on technical explanations or providers?
• Has the entity determined which frameworks and obligations may apply in each jurisdiction where it operates, and who verifies that interpretation?

Supervision must be commensurate with the entity's profile and complexity and the relevance of each use. Not all models require identical controls or the same review frequency.

2. Model Inventory and Classification

• Is there an updated inventory that includes models in production, in testing, and, where applicable, solutions acquired or integrated by third parties?
• Are the purpose, user area, owner, inputs, outputs, assumptions, version, and lifecycle status registered for each system?
• Has an internal definition of a model been established that is clear enough to identify algorithms or components that influence decisions, even if presented as external tools or services?
• Is each model classified according to its use, exposure, potential impact, and dependence on other systems?
• Does the inventory allow identifying models without an assigned owner, duplicates, obsolete ones, or those deployed without formal review?

A useful inventory is not just a technical catalog: it allows knowing where each model is used, what decisions it supports, and who can intervene if it stops functioning as expected.

3. Data, Quality, and Traceability

• Is the origin of the data documented and, where possible, its journey from acquisition to use in the model?
• Are the quality, relevance, currency, and representativeness of the data evaluated for the declared purpose?
• Are missing data, errors, changes in definitions, and potential biases that may affect results identified?
• Are access, privacy, retention, and use controls applied in accordance with internal policies and relevant regulations?
• Can it be reconstructed which data and transformations were used in a specific version of the model or in a relevant decision?

The review must cover both development data and the data that feed the system in operation. Good documentation of provenance and transformations facilitates investigating deviations and explaining model limitations.

4. Development, Validation, and Approval

• Are the model's objectives, assumptions, and limits defined before its deployment?
• Is it verified that the chosen method is suitable for the intended use and that its results are sufficiently stable under reasonable conditions?
• Does the validation examine performance, sensitivity to data changes, extreme cases, and possible unintended effects?
• Is the review independent of those who developed or implemented the model, to the extent required by the internal framework and risk?
• Are findings, limitations, corrective measures, and the decision to approve, restrict, or not deploy the model documented?
• Are controls adjusted to risk and complexity, rather than automatically applying an identical frequency or procedure to all models?

Validation does not end with checking initial metrics. It must provide sufficient evidence to evaluate whether the model is suitable for its purpose and what conditions could invalidate that conclusion.

5. Human Oversight and Use of Results

• Is it clear which decisions the model can support and which require human review or authorization?
• Do users know the limitations, warning signs, and steps to question or escalate a result?
• Is there a practicable path to correct or review problematic results when the process and applicable regulations require it?
• Is it avoided that an automated recommendation is treated as conclusive without considering its context and quality?
• If a model is used to evaluate or validate another, are there defined usage limits, controls, and human review to reduce the risk of chained errors?

Human oversight must be effective: people need information, authority, and time to intervene. The mere presence of a formal approval does not by itself demonstrate that substantive control exists.

6. Documentation, Changes, and Monitoring

• Are comprehensible documents about purpose, design, data, tests, results, limitations, and owners retained?
• Is every change in data, code, configuration, or provider registered and subject to a proportional evaluation and approval process?
• Are there indicators to detect performance deterioration, data changes, or atypical results?
• Have owners, alert thresholds, and possible actions been defined when monitoring identifies a deviation?
• Is it periodically reviewed whether the model remains suitable for its use, and is its withdrawal contemplated when it ceases to be so?
• Do the records allow reconstructing versions, changes, and management decisions in the face of an internal or external review?

Monitoring connects initial validation with real behavior. If the environment, data, or purpose changes, it may be necessary to review controls and usage authorization.

7. Providers and External Dependencies

• Are the third-party models, services, and components involved in relevant processes known?
• Has it been evaluated what information the provider receives, how it is used, and what documentation it offers about the system?
• Are channels defined for notifying incidents, substantial changes, interruptions, or modifications to service conditions?
• Does the entity retain sufficient capacity to supervise use and manage the dependency, even when it does not control the model's development?
• Have provider concentration and available alternatives been considered if a service becomes inaccessible or changes significantly?

External contracting does not eliminate the need to understand how a system affects the entity's activities. The degree of available information and control may vary depending on the provider and the service.

How to Interpret Reference Frameworks

The sources considered describe different approaches: supervisory and model management guidelines in the United States, Canada, and the United Kingdom, references on AI in the European Union, and governance proposals in Singapore, in addition to voluntary frameworks and sectoral materials. For example, the NIST AI Risk Management Framework is presented as a voluntary framework; the Canadian OSFI E-23 guide has its own scope and schedule; and the British PRA SS1/23 statement corresponds to its supervisory context. The material also describes a US Treasury sectoral framework with 230 control objectives, which should not be interpreted as a universal obligation.

Therefore, these references serve to guide questions and compare practices, not to replace the analysis of the regulations applicable to each entity. Jurisdiction, type of institution, activity, and specific model use can change the scope of obligations.

Self-Assessment Result

For each question, the entity can record available evidence, owner, detected gap, and next review. Negative or incomplete answers help prioritize work, but they do not by themselves determine legal compliance or the overall risk level. What is important is that control decisions are traceable, proportional to use, and reviewable when the model or its context changes.