Basel Committee AI Guidance for Banks: What to Track
The Basel Committee has not published a single, standalone AI-specific rulebook for banks. Instead, AI and machine learning systems are being brought under existing model risk management, operational risk, and third-party risk frameworks. For chief risk officers, the practical task is identifying which existing validation, monitoring, and audit trail obligations already apply to AI systems, and where gaps remain given behaviors specific to AI, such as data drift, retraining cycles, and vendor dependency.
AI-related expectations currently appear embedded within broader work on operational resilience, technology risk, and existing model risk management principles. Banks are expected to apply those principles to AI and machine learning systems as they would to other models. The work for risk and compliance teams is translation: map what already applies, then close the gaps that dynamic models and vendor-supplied tools create.
What AI guidance implies for bank risk teams
Four themes consistently shape how examiners and internal stakeholders evaluate AI under Basel-aligned frameworks. None of them requires a separate AI rulebook; each extends obligations banks already manage.
Model risk extension
AI systems generally meet existing model risk management definitions and fall under validation and review cycles already in place.
Behavioral monitoring
Inputs, outputs, drift, and human overrides need consistent logging for any AI system influencing a business decision.
Third-party exposure
Vendor-supplied AI tools bring model risk under existing third-party and operational risk frameworks, not a separate track.
Audit trail readiness
Examinations typically test whether a bank can reconstruct an AI decision after the fact, not just whether a policy exists.
Why AI extends existing model risk frameworks
In most banks, existing model risk management policy already covers AI systems in principle. If a policy defines a model as any input-output process affecting a business decision, AI systems typically meet that definition. The practical gap is usually in monitoring cadence and audit trail granularity rather than in the scope of the policy itself.
AI introduces behaviors that static or slowly changing quantitative models often did not: frequent retraining, data drift, and dependence on vendor change cycles. Those behaviors do not remove AI from model risk scope. They raise the bar on how validation, ongoing monitoring, and documentation must operate day to day.
Categories of AI behavior and output that need monitoring
For AI systems that influence credit, pricing, fraud, or compliance decisions, risk teams should treat the following as first-class monitoring concerns:
- Model inputs and outputs logged with enough context to support later reconstruction
- Version changes, including retraining, fine-tuning, and configuration updates
- Drift and performance metrics on a schedule matched to how often data or the model changes
- Human override and escalation events tied to AI-generated outputs
Monitoring is not only a production operations task. It is the evidence base for showing that an AI system remains within its validated use and that deviations are detected and handled.
Where AI tracking intersects operational and third-party risk
Vendor-supplied AI tools do not sit outside model risk because a third party operates them. They sit at the intersection of model risk, operational risk, and third-party risk. Due diligence questionnaires should extend to AI-specific vendor practices, including retraining frequency and change notification.
Operational resilience expectations still apply: ownership, continuity, and the ability to explain how a system behaves under change. When a vendor controls retraining or model updates, the bank still needs notification paths, impact assessment, and records that support internal challenge and external examination.
Common tracking gap
Reconstructing why a specific AI-generated output occurred, particularly for systems retrained frequently or supplied by third-party vendors, tends to be the most common gap. Existing audit trails were often designed for less dynamic models and may capture that a decision was made without capturing enough to explain why.
Governance and audit trail capabilities to demonstrate compliance
Policy statements alone rarely satisfy scrutiny. Teams need operational capabilities that produce durable evidence:
- An inventory of AI and ML systems in use, including vendor-supplied tools, with owners and business purpose
- Audit trails that can reconstruct why a specific AI-driven decision was made, not only that a decision occurred
- Linkage between overrides, escalations, and the outputs that prompted them
- Change history that remains readable across internal and vendor-driven updates
Align AI monitoring cadence with existing model risk tiering. Higher-impact AI use cases should receive the same rigor applied to high-impact quantitative models.
| Obligation area | What to track | Why it matters |
|---|---|---|
| Inventory and ownership | Systems in use, owners, business purpose, vendor vs internal | Scope of model risk and accountability cannot be established without a current inventory |
| Decision evidence | Inputs, outputs, model version at decision time | Examinations test reconstructability of material AI-driven outcomes |
| Performance and drift | Scheduled metrics matched to change frequency | AI behavior can shift between formal validation cycles |
| Human challenge | Overrides and escalations tied to outputs | Shows ongoing control effectiveness, not only automated scoring |
| Third-party change | Retraining frequency, notification, due diligence responses | Vendor updates can alter model behavior without an internal release |
Documentation practices worth establishing now
Documentation does not need to wait for a consolidated Basel AI rulebook. Practices that reduce later remediation cost include:
- Assign clear model ownership for every AI system, including tools introduced by business units outside formal technology procurement.
- Document the intended use case and boundaries of each AI system separately from its technical specification.
- Require change logs for any AI system that is retrained, fine-tuned, or reconfigured, regardless of whether the change originates internally or with a vendor.
- Align AI monitoring cadence with existing model risk tiering, treating higher-impact AI use cases with the same rigor applied to high-impact quantitative models.
Practical tracking checklist for risk and compliance teams
Use the following as an operating checklist when extending model risk, operational risk, and third-party controls to AI systems.
- Maintain a current inventory of AI and ML systems in use, including vendor-supplied tools, with owners and business purpose documented.
- Log model inputs, outputs, and version changes for AI systems that influence credit, pricing, fraud, or compliance decisions.
- Define and track drift and performance metrics on a schedule appropriate to how frequently the underlying data or model changes.
- Record human override and escalation events tied to AI-generated outputs as part of ongoing model performance monitoring.
- Extend third-party due diligence questionnaires to cover AI-specific vendor practices, including retraining frequency and change notification.
- Ensure audit trails can reconstruct why a specific AI-driven decision was made, not only that a decision was made.
Frequently asked questions
Has the Basel Committee issued a single AI-specific regulation for banks?
Not as a standalone, consolidated rulebook. AI-related expectations currently appear embedded within broader work on operational resilience, technology risk, and existing model risk management principles, which banks are expected to apply to AI and machine learning systems as they would to other models.
Does existing model risk management policy already cover AI systems?
In most banks, yes, in principle. If a policy defines a model as any input-output process affecting a business decision, AI systems typically meet that definition. The practical gap is usually in monitoring cadence and audit trail granularity rather than in the scope of the policy itself.
What is the most common tracking gap banks face with AI systems today?
Reconstructing why a specific AI-generated output occurred, particularly for systems retrained frequently or supplied by third-party vendors, tends to be the most common gap, since existing audit trails were often designed for less dynamic models.
Extend Model Risk Discipline to AI Systems
Mapping tracking and documentation obligations to concrete controls is the practical starting point for extending model risk management to AI. Trussed AI provides runtime governance and audit logging capabilities relevant to that control layer.
Explore MCP Security