Banks whose services depend on AI agents must show the Basel Committee's operational resilience principles still hold: the board sets tolerance for disruption, agents are mapped into critical operations, third-party model providers are managed, incidents are handled, ICT is resilient, and continuity plans work when an agent fails or misbehaves. National supervisors turn these principles into binding rules.
What do the Basel principles require, in plain words?
The Basel Committee on Banking Supervision has published principles for operational resilience: a bank's ability to deliver critical operations through disruption. They build on its earlier operational risk principles and are written for supervisors and banks worldwide. In substance, they cover seven areas:
- Governance. The board approves the approach to resilience and sets the bank's tolerance for disruption to critical operations.
- Operational risk management. The existing framework identifies threats and vulnerabilities and maintains controls.
- Business continuity planning and testing. Plans are tested against severe but plausible scenarios.
- Mapping. The bank maps the people, technology, processes, information and facilities behind each critical operation, including their interconnections.
- Third-party dependency management. Reliance on outside providers is managed to the same standard as internal operations.
- Incident management. Incidents are identified, contained, recovered from and learned from.
- Resilient ICT, including cyber security. Technology supporting critical operations is protected, tested and monitored.
Who do they apply to?
The principles are addressed to internationally active banks and to the supervisors that oversee them, and they shape national rules elsewhere. They are not law in themselves. National supervisors adopt them in their own regimes, which is why a UK bank meets them through the UK's resilience rules, an EU bank through DORA and an Australian bank through APRA CPS 230.
That makes them a useful common language for groups operating in several markets. A bank can design one approach to agents around the principles and then confirm local detail. The UK version is covered in UK operational resilience rules and AI agents.
What changes when an agent sits inside a critical operation?
The principles assume a bank can map what its operations depend on. Agents complicate the map in three ways.
The dependency chain gets longer. An agent relies on a model provider, its sources, the systems it writes to and the people who approve its held actions. Each is a point of failure, and the model provider is often shared by many banks, a concentration that one bank's map will not reveal on its own.
Failure modes multiply. A server either runs or it does not. An agent can run and be wrong, producing confident outcomes that look normal. Resilience for agents must cover integrity, not only availability.
Recovery is less obvious. Restarting an agent does not undo what it did while wrong. Recovery means finding every affected case, which depends on keeping a complete record of what the agent did, and then putting each case right with a person deciding the remedy.
How do you apply each principle to agents?
| Requirement | Control | Evidence it leaves |
|---|---|---|
| Governance and tolerance | Board-approved tolerances for critical operations that include agent-down and agent-wrong scenarios | Board minutes and tolerance statements |
| Operational risk management | Agent risks in the risk taxonomy; every action checked against its bounds at the moment of action | Risk register entries and filed verdicts |
| Continuity planning and testing | Fallback to people at reduced speed; tests of model provider outage and mass depth reduction | Test reports against tolerance |
| Mapping | Agents, model providers, sources, credentials and approvers in the critical operation map | Dependency maps per critical operation |
| Third-party dependency | Model and platform providers assessed, contracted and monitored; change notice required | Due diligence files and change notices |
| Incident management | Agent incidents triaged; affected cases identified from the action record | Incident reports with case lists |
| Resilient ICT and cyber | Agent identities with least privilege; prompt injection tested; credentials protected | Access reviews and security test results |
The testing row is where agents need new scenarios. Testing approaches under DORA, covered in DORA resilience testing for AI agents, translate well to banks outside the EU.
What will a supervisor ask?
- Which critical operations depend on an agent, and how was that captured in your mapping?
- What is your tolerance for disruption to those operations, and does it assume the agent fails?
- If the agent ran wrongly for a day, how would you find every affected customer?
- Which model providers do your agents rely on, and how many of your critical operations depend on the same one?
- Has your board discussed agents in the context of resilience?
That last question often reveals that agents were approved by a technology forum and never reached the board's resilience discussions. Composition matters here, as discussed in who should sit on an AI governance committee.
What do the principles not cover?
They are principles, not detailed rules, so they leave design to banks, a point made in principles-based regulation leaves the agent design to you. They do not address fairness, explainability or consumer outcomes; frameworks such as Singapore's FEAT principles, discussed in how MAS FEAT principles apply to AI agents, speak to those. They do not set numeric tolerances or test frequencies. And they do not bind banks directly; local rules do. For the cross-regime map, see AI agent regulation mapped to controls.
This is an explanation of the rules, not legal advice; confirm how they apply to you with counsel.
Questions people ask
Do the Basel principles mention AI?
They are technology-neutral and do not single out AI. They apply to whatever a critical operation depends on, which now includes agents and the providers behind them.
Is model risk the same as operational resilience?
No. Model risk is about whether a model's outputs are sound. Resilience is about whether the service keeps running within tolerance. An agent raises both, and they need joined-up governance.
How should a bank treat a shared model provider?
As a third-party dependency that may create concentration across several critical operations. Map which operations rely on it, plan for its failure, and consider whether a fallback provider or a human fallback is needed.