Artificial intelligence

2026 has seen continued strong policy and supervisory activity on AI in financial services at global and national level. Globally, the Financial Stability Board’s proposed sound practices for the responsible adoption of AI — currently under consultation — provide a global reference point around organisation-wide governance of AI and AI lifecycle management, complementing the more specific national expectations as well as IOSCO's supervisory-oriented AI toolkit.

Across observed requirements, emphasis remains on making AI use visible, risk-tiered and operationally controllable through board and senior-management oversight, defined ownership across business and control functions, AI use inventories, dependency mapping, use-case suitability checks, risk appetite boundaries, high-risk approvals, lifecycle validation, performance and drift monitoring, data lineage, explainability, audit-ready documentation, human intervention points and fallback arrangements. More granular requirements are being applied where AI affects customers, markets, critical operations or financial decisions, including customer disclosure and challenge routes, bias and suitability testing, restrictions where systems cannot be explained or evidenced, incident response, business continuity, and clearer contractual and assurance expectations for externally sourced models. An additional emphasis point and layer of expectations as of 2026 is the translation of generative and agentic AI risks into practical controls, including prompt and configuration records, restrictions on autonomous execution, AI-specific cyber testing for prompt injection, poisoning, model extraction and agent misuse, and closer scrutiny of third-party, cloud, open-source and model-provider dependencies, including concentration, auditability, data-use restrictions and exit options.

Firms are expected to place AI within a defined governance structure that sets ownership, authority, risk appetite, reporting lines, control responsibilities, competence requirements and escalation routes across the board, senior management, business, technology and control functions. The requirement is not limited to approving AI initiatives; it extends to ensuring that AI-related decisions, controls and outcomes remain accountable, challengeable and subject to effective oversight, including where systems are externally sourced. More prescriptive approaches require dedicated AI or model-risk committees and formal board-approved frameworks, while outcomes-based approaches permit reliance on existing governance structures where they demonstrably address AI-specific risks.

• Establish a board-approved or senior-governed AI, model-risk or technology governance framework proportionate to the scale, complexity, materiality and risk profile of AI use.
• Embed AI-related risks within existing enterprise risk management, internal control, conduct, operational resilience, cyber, outsourcing and model-risk frameworks.
• Assign board and senior management accountability for AI strategy, risk appetite, permitted and prohibited uses, resource allocation, oversight and material AI outcomes.
• Define ownership and responsibility across business, technology, data, model, compliance, risk, internal audit, cyber and vendor-management functions.
• Establish effective challenge through the three lines of defence, independent validation, internal audit, compliance review and board / committee oversight.
• Ensure board, senior management, users and control functions have proportionate AI literacy and technical competence to understand, challenge and oversee AI use.
• Maintain escalation, remediation and reporting channels for AI-related incidents, control weaknesses, risk-appetite breaches and unresolved model or data issues.
• Preserve human accountability for AI-assisted or automated decisions, including by assigning accountable decision owners and ensuring that AI does not obscure responsibility.

AI use should be managed through processes that give the firm a complete and current view of where AI is used, what purpose it serves, who owns it, how it operates, what data it uses and which internal or external dependencies support it. Each use should be assessed for suitability and classified by reference to materiality, complexity, autonomy, explainability, customer or market impact, operational criticality, data sensitivity and third-party reliance. Stricter formulations treat inventory inclusion, high-risk classification or formal approval as preconditions for use, while less prescriptive approaches rely on structured mapping, self-assessment and proportionate governance controls.

• Maintain a complete and current inventory of AI uses, including internally developed systems, third-party tools, embedded AI, generative AI, agentic AI, office automation, scripts and vendor-hosted capabilities.
• Record each use case’s purpose, owner, business process, model or system type, provider, deployment status, data inputs, outputs, dependencies, lifecycle status and affected customers, markets or operations.
• Classify AI uses by materiality, complexity, autonomy, explainability, data sensitivity, customer impact, market impact, operational criticality, model reliance and third-party dependency.
• Define permitted, restricted and prohibited AI uses in policies, procedures and risk appetite statements.
• Assess use-case suitability before deployment, including whether the proposed model, tool or provider is appropriate for the business objective, available data, legal context and intended decision process.
• Set functional boundaries, user permissions, system permissions, data-access rights, output-use limits and escalation triggers before deployment.
• Require enhanced approval for high-risk, high-impact, customer-facing, market-facing, critical-function or highly autonomous uses.
• Reassess and re-tier AI uses when they are scaled, materially changed, connected to new data sources, moved into new business processes or affected by provider changes.

AI systems should be governed as lifecycle-controlled assets, with documented procedures for planning, design, data preparation, development, testing, validation, approval, deployment, monitoring, maintenance, change, revalidation, exit and decommissioning. Firms should be able to evidence why a model or system was selected, how it was tested, who validated it, what limitations were accepted, how performance is monitored and when changes require renewed approval. Requirements differ mainly in depth: some express broad lifecycle guardrails, while others apply detailed model-risk disciplines such as independent validation, change logs, version control, exception approvals, revalidation triggers and formal decommissioning records.

• Establish lifecycle procedures covering planning, design, data preparation, development, training, testing, validation, approval, deployment, monitoring, maintenance, change, revalidation, exit and decommissioning.
• Document model design, methodology, assumptions, limitations, data preparation, feature selection, training approach, testing results, validation outcomes and approval decisions.
• Require independent validation for material AI systems, including third-party models, before deployment, after deployment, after material changes, after trigger events and periodically.
• Test AI systems using methods appropriate to the use case, including out-of-sample testing, back-testing, stress testing, sensitivity testing, benchmarking, live-environment testing, adversarial testing and edge-case testing.
• Monitor performance, accuracy, robustness, stability, bias, hallucination, overfitting, underfitting, data drift, model drift, anomalous outputs and alignment with intended use.
• Define thresholds for escalation, recalibration, retraining, restriction, redevelopment, replacement, suspension or decommissioning.
• Implement change management, version control, release approval, rollback capability, prompt or configuration controls and revalidation triggers.
• Apply compensating controls, use restrictions or redesign where explainability is limited and the use case is higher risk.

AI-related data and records should be managed through controlled processes covering data sourcing, lawful basis, consent, quality, relevance, representativeness, provenance, lineage, access, retention, reuse, sharing and deletion. Firms should distinguish training, testing, inference and monitoring data, protect personal and sensitive information, and ensure that third-party or vendor-hosted data is subject to equivalent scrutiny. Recordkeeping expectations extend to the evidence needed to reconstruct approvals, data lineage, model design, validation, monitoring, incidents, overrides, changes, decisions, remediation and supervisory review.

• Establish data governance across sourcing, collection, cleaning, labelling, transformation, training, testing, inference, retention, reuse, sharing, deletion and exit.
• Ensure data is accurate, relevant, complete, consistent, representative, up to date, secure and appropriate for the intended customer population, business process and model purpose.
• Maintain data lineage, provenance, metadata, data-flow maps, source records, training-versus-inference distinctions and audit trails.
• Document lawful basis, consent, notices, reuse permissions, purpose limitation, data minimisation, retention, cross-border transfer and data-subject or customer rights.
• Apply privacy-by-design, security-by-design, access controls, anonymisation, masking, pseudonymisation, synthetic data or desensitised data where appropriate.
• Monitor data quality, data distribution, data drift and data defects that could affect performance, fairness, legality or customer outcomes.
• Retain records of AI inventories, approvals, risk assessments, data sources, validation reports, monitoring results, incidents, overrides, versions, changes and remediation.
• Maintain records sufficient for board reporting, internal audit, external assurance, customer challenge, complaint handling and supervisory review.

Customer- and market-facing AI should be subject to controls that address fairness, non-discrimination, suitability, disclosure, explainability, complaint handling, redress and market integrity. Firms are expected to prevent AI systems from producing discriminatory, manipulative, misleading, unsuitable or otherwise harmful outcomes in areas such as advice, product recommendations, credit, insurance, claims, marketing, trading, investment research and customer communications. Consumer-focused regimes tend to emphasise challenge rights, vulnerable customers, complaints and redress, while capital-markets approaches place greater weight on investor protection, disclosure, market abuse, recordkeeping and market integrity.

• Test AI systems, data, features and outputs for unfair bias, discriminatory outcomes and disproportionate effects on vulnerable, minority or protected groups.
• Prevent deployment or continued use of AI systems that produce discriminatory, manipulative, misleading, unsuitable or harmful outcomes.
• Ensure AI-supported decisions, advice, recommendations, marketing, onboarding, credit, underwriting, claims handling, collections, trading and customer communications remain consistent with applicable conduct obligations.
• Disclose AI use to customers or investors where AI materially affects interactions, recommendations, products, services or high-impact decisions.
• Provide understandable explanations, human review, challenge routes, correction mechanisms, opt-out or alternative arrangements where applicable.
• Maintain complaints, redress and remediation processes for AI-related errors, harms, unfair outcomes or inaccurate data inputs.
• Control AI-generated marketing, chatbot outputs, investment research, disclosures and product recommendations to prevent misleading statements, pressure selling or unsupported claims.
• Apply market conduct and market integrity controls where AI is used in trading, investment research, portfolio management, market surveillance or client engagement.

AI should be brought within cyber and ICT risk-management frameworks, with controls tailored to models, prompts, APIs, code, outputs, training data, deployment environments, connected tools and agentic capabilities. Firms should identify and test for AI-specific threats such as data poisoning, model poisoning, prompt injection, jailbreaking, adversarial inputs, model extraction, model inversion, deepfakes, backdoors, unsafe generated outputs and agent misuse. The level of specificity differs materially: some expectations adapt existing cyber controls to AI, while others prescribe detailed threat modelling, red-teaming, vulnerability scanning, output validation, content filtering and secure supply-chain controls.

• Extend cyber and ICT risk frameworks to AI models, applications, agents, prompts, APIs, training data, test data, deployment environments, outputs and model supply chains.
• Develop AI-specific threat models covering data poisoning, model poisoning, prompt injection, jailbreaking, evasion, model extraction, model inversion, backdoors, sponge attacks, deepfakes, adversarial inputs and agent misuse.
• Apply secure design, secure coding, input validation, output validation, access controls, encryption, data isolation, content filtering, guardrails and data-loss prevention.
• Conduct vulnerability scanning, penetration testing, adversarial testing, prompt-injection testing, red-teaming, security validation and model-behaviour monitoring.
• Monitor anomalous model behaviour, tool use, prompt patterns, data access, system access, third-party code and security events.
• Restrict unsafe execution of generated code, scripts, commands, processes or outputs.
• Integrate AI-related vulnerabilities and incidents into cyber incident response, remediation, escalation and threat-intelligence processes.

Firms should identify where AI supports critical operations, important business services, customer processes, control functions or market-facing activities, and ensure those services can continue, recover or safely degrade if the AI system fails. Continuity arrangements should address model unavailability, degraded performance, unreliable outputs, data-quality failure, cyber compromise, provider outage, agent malfunction, rollback, manual workarounds, backup systems, incident escalation and post-incident remediation. More developed expectations require AI-specific business impact analysis, tested recovery arrangements and explicit emergency stop or model-exit criteria, while less prescriptive approaches fold AI into existing operational resilience frameworks.

• Identify AI dependencies in critical operations, important business services, customer-facing processes, control functions, market-facing activities and ICT systems.
• Include AI unavailability, model degradation, unreliable outputs, data-quality failure, provider outage, cyber compromise and agent malfunction in business continuity and disaster recovery planning.
• Conduct business impact analysis for material AI-enabled services and define tolerances for disruption or degraded performance.
• Maintain manual workarounds, fallback models, backup systems, substitution arrangements, rollback plans, model-exit procedures and emergency stop mechanisms.
• Test recovery arrangements, fallback routes, backup restorability, incident response, service restoration and communication plans.
• Define escalation, ownership, customer communication, vendor communication, post-incident review and remediation procedures for AI-related incidents.
• Consider concentration, common-provider and common-model dependencies that could create correlated failures or single points of failure.

Firms remain responsible for AI systems and outputs even where AI capabilities are procured, hosted, embedded or maintained by third parties. They should conduct due diligence, impose contractual rights, monitor providers, understand subcontracting and fourth-party dependencies, manage cloud, model, data and provider concentration, secure access to information, and maintain exit, continuity and contingency options. The more advanced requirements extend to open-source registers, software bills of materials, supply-chain integrity checks, provider assurance reports, vulnerability testing, data-location controls and compensating controls where vendor transparency is limited.

• Apply outsourcing, ICT, cloud and third-party risk frameworks to AI providers, model providers, cloud and compute providers, data providers, embedded AI tools, open-source components and managed services.
• Conduct due diligence on provider reputation, governance, security, data protection, model methodology, limitations, data quality, performance, update practices, subcontracting and supply-chain exposure.
• Require contractual rights covering access to information, audit, supervisory access, incident notification, vulnerability notification, data location, data use, data protection, service performance, change notification, continuity, termination and exit.
• Maintain vendor, sub-vendor, fourth-party, cloud, model, data, compute and open-source dependency maps.
• Monitor provider performance, model updates, service availability, data handling, subcontracting changes, security posture and ongoing compliance.
• Assess concentration risk across common cloud providers, model providers, data providers, infrastructure layers and geographic regions.
• Apply compensating controls where vendor transparency is limited, including restricted use, enhanced testing, benchmarking, independent validation, human review, reduced deployment scope or non-use.
• Maintain exit, portability, substitution and contingency arrangements for material third-party AI services.