Clause index

Every paragraph of the MAS Guidelines on Artificial Intelligence Risk Management (7 October 2026) and what in this toolkit implements it. Generated from src/airm/catalog/mas_airm_2026.yaml and src/airm/controls/controls.yaml; do not edit by hand.

Summaries are the toolkit authors' paraphrase, never the regulatory text. Read the cited paragraph in the primary document before relying on it.

Clause	Kind	Due	Summary	Controls	Module
§1.1	context	2027-10-07	States the purpose: MAS supervisory expectations on AI risk management covering oversight, key systems/policies/procedures, lifecycle controls and capability/capacity, to support responsible AI adoption by financial institutions.	—	airm.catalog
§1.2	scope	2027-10-07	Guidelines complement existing MAS legislation and guidelines (FEAT still applies; read with other guidelines, circulars and industry standards). They apply on a group basis for locally incorporated FIs under consolidated supervision or owning critical information infrastructure.	—	airm.catalog
§1.3	definition	2027-10-07	Defines AI as machine-based systems or models deriving outputs through learned premises from data or inputs; outputs include estimates, predictions, content, summaries, recommendations, decisions. Rule-based calculators and fixed-logic tools are excluded.	—	airm.catalog
§1.4	definition	2027-10-07	Defines model (method converting assumptions and inputs to outputs), system (one or more models plus other machine-based components) and use case (the real-world context a model or system is applied to).	—	airm.catalog
§1.5	scope	2027-10-07	High-level expectations apply to all FIs deploying AI, including Generative AI and AI agents. An FI in a global group may rely on group AI risk frameworks if they meet these expectations.	AIRM-3.6-LOCAL-ACCOUNTABILITY	airm.catalog
§1.6	expectation	2027-10-07	Implement the Guidelines proportionately to the FI's size, nature of activities and the extent to which its AI use could create material risks.	AIRM-3.2-RISK-FRAMEWORK-COVERAGE	airm.catalog
§1.7	expectation	2027-10-07	Regularly review the adequacy of AI risk management against AI developments and address new or accentuated risks.	AIRM-1.7-PERIODIC-FRAMEWORK-REVIEW	airm.catalog
§1.8	scope	2027-10-07	Effective 7 October 2027. Sections 3-4 expectations from 7 October 2027; Sections 5-6 by 7 October 2028.	—	airm.catalog
§1.9	context	2027-10-07	AI's complexity and probabilistic nature increase uncertainty and hidden bias. Risks extend existing categories: financial, operational, conduct, financial crime and reputational.	—	airm.catalog
§1.10	context	2027-10-07	Generative AI amplifies AI risks and is harder to evaluate, test and explain. Additional risks: security (prompt injection, poisoning), privacy, legal/IP, third-party concentration, operational outages, human factors including shadow AI and automation bias.	—	airm.catalog
§1.11	context	2027-10-07	AI agents with autonomy and tool access can execute unauthorised or erroneous actions misaligned with goals; compromised agents may exfiltrate data or run malicious commands at scale.	—	airm.catalog
§1.12	context	2027-10-07	MAS will update or augment the Guidelines as AI and its risks evolve.	—	airm.catalog
§2.1	scope	2027-10-07	Guidelines apply to all FIs proportionately to size and risk profile.	—	airm.controls
§2.2	expectation	2027-10-07	Unless 2.3 applies, an FI must establish oversight frameworks with AI identification, materiality assessment and inventory (Sections 3-4) and apply lifecycle controls and capabilities (Sections 5-6), calibrated by relevance and risk materiality.	—	airm.controls
§2.3	scope	2027-10-07	An FI may apply only basic governance (2.5) if poor performance or unavailability of its AI tools is unlikely to materially harm the FI, customers or stakeholders, considering financial/operational/regulatory/legal/reputational impact and fairness, ethics, consumer protection.	AIRM-2.5-BASIC-POLICIES	airm.controls
§2.4	guidance	2027-10-07	Examples that generally meet the 2.3 basic-regime test: AI assisting with drafting emails, summarising documents, initial document review, generating formulas or charts, image generation for materials, and internal resource-finding chatbots, with human review.	AIRM-2.5-BASIC-POLICIES	airm.controls
§2.5	expectation	2027-10-07	Basic AI governance must minimally include accountable senior management, permitted and prohibited uses with human oversight rules, an approved-tool list and approval process, staff education, compliance checks, and periodic/trigger-based review of the 2.3 criteria.	AIRM-2.5-BASIC-POLICIES	airm.controls
§3.1	context	2027-10-07	Board and senior management are central to establishing and overseeing AI risk frameworks.	—	airm.controls
§3.2	expectation	2027-10-07	Ensure existing risk frameworks identify, assess and address AI risks; maintain oversight, foster risk culture, and ensure AI use does not conflict with regulatory requirements or supervisory expectations.	AIRM-3.2-RISK-FRAMEWORK-COVERAGE	airm.controls
§3.3	expectation	2027-10-07	Ensure consistent standards, clear accountability and coordination across the FI; a centralised AI risk function or existing functions are both acceptable if management is consistent and coordinated.	AIRM-3.3-COORDINATED-OVERSIGHT	airm.controls
§3.4	expectation	2027-10-07	Board (or delegated committee) approves and reviews the AI governance approach and strategic direction, embeds AI risks in the risk appetite framework, sets roles, maintains adequate AI understanding, and reviews these regularly.	AIRM-4.11-RISK-APPETITE, AIRM-5.11-CONCENTRATION, AIRM-3.3-COORDINATED-OVERSIGHT, AIRM-3.6-LOCAL-ACCOUNTABILITY	airm.controls
§3.5	expectation	2027-10-07	Senior management implements and reviews AI risk frameworks, institutes lifecycle controls, sets roles including control functions for identification/inventory/materiality, runs escalation for incidents and breaches, updates the board, and resources competence.	AIRM-5.23-INCIDENT-MANAGEMENT, AIRM-3.3-COORDINATED-OVERSIGHT	airm.controls
§3.6	expectation	2027-10-07	Local senior management remains accountable that group frameworks address Singapore-specific requirements, has visibility and input, has escalation paths for local issues, and can demonstrate oversight to MAS.	AIRM-3.6-LOCAL-ACCOUNTABILITY	airm.controls
§4.1	expectation	2027-10-07	The AI risk framework must include systems, policies and procedures for identification, inventorisation and risk materiality assessment, applied consistently, with controls proportionate to assessed materiality.	AIRM-4.1-FRAMEWORK-PROCESSES	airm.inventory, airm.materiality, airm.scan
§4.2	expectation	2027-10-07	Establish systems, policies and procedures for consistent AI identification across all business and functional areas, with clear definitions, criteria and processes supported by tools; minimally cover AI embedded in services from material third-party providers.	AIRM-4.3-IDENTIFICATION-PROCESS, AIRM-4.2-FN21-EMBEDDED-AI	airm.inventory, airm.materiality, airm.scan
§4.3	expectation	2027-10-07	Assign roles for AI identification and designate a control function with independent oversight; it is the final arbiter of what is AI, keeps documentation, and reviews the process for new technologies and third-party AI introductions.	AIRM-4.3-IDENTIFICATION-PROCESS, AIRM-4.1-FRAMEWORK-PROCESSES	airm.inventory, airm.materiality, airm.scan
§4.4	expectation	2027-10-07	Keep residual risk from unidentified AI (embedded AI, shadow AI) within risk appetite: identify the risks from identification constraints and put mitigating measures in place.	AIRM-4.4-FN22-SHADOW-AI	airm.inventory, airm.materiality, airm.scan
§4.5	expectation	2027-10-07	Establish and maintain an accurate inventory of AI use cases, systems or models to the extent practicable, with policies on maintenance and an appropriate update frequency reflecting new, updated or decommissioned AI.	AIRM-4.5-INVENTORY-MAINTAINED	airm.inventory, airm.materiality, airm.scan
§4.6	expectation	2027-10-07	Enhance existing inventories or build a dedicated AI inventory; either way maintain clear linkages to other inventories (data, third-party) for cross-referencing.	AIRM-4.6-FN23-REGISTER-LINKAGE, AIRM-4.6-FN23-LINKAGES-DECLARED	airm.inventory, airm.materiality, airm.scan
§4.7	expectation	2027-10-07	Inventory captures key attributes at appropriate granularity: purpose and description, approved scope, model type, data used, dependencies, lifecycle status, materiality rating, review status, roles (owners, developers), links to documentation.	AIRM-4.7-INVENTORY-ATTRIBUTES, AIRM-5.1-LIFECYCLE-ROLES	airm.inventory, airm.materiality, airm.scan
§4.8	expectation	2027-10-07	Regularly review inventory design so attributes cover newer AI technologies (e.g. agent attributes, guardrails) and third-party AI information.	AIRM-4.8-FN25-AGENT-ATTRIBUTES, AIRM-5.16-AGENT-PERMISSIONS, AIRM-1.7-PERIODIC-FRAMEWORK-REVIEW	airm.inventory, airm.materiality, airm.scan
§4.9	expectation	2027-10-07	Assign roles for inventorisation and designate a control function to own inventory policies; business units may maintain entries but the control function retains independent oversight of accuracy and completeness.	AIRM-4.5-INVENTORY-MAINTAINED, AIRM-4.1-FRAMEWORK-PROCESSES	airm.inventory, airm.materiality, airm.scan
§4.10	expectation	2027-10-07	Establish a materiality assessment methodology anchored on the AI use case, applied consistently to every use case, so that controls scale with risk and higher-materiality use cases receive more scrutiny.	AIRM-4.11-MATERIALITY-ASSESSED	airm.inventory, airm.materiality, airm.scan
§4.11	expectation	2027-10-07	Assess both inherent (pre-control) and residual (post-control) materiality; residual materiality must meet risk appetite before deployment; review methodology and assessments regularly.	AIRM-4.11-MATERIALITY-ASSESSED, AIRM-4.11-RISK-APPETITE	airm.inventory, airm.materiality, airm.scan
§4.12	expectation	2027-10-07	Materiality must minimally cover Impact (consequences of failure on FI and customers, data sensitivity), Complexity (technology, novelty, data, explainability, third-party visibility) and Reliance (dependence, autonomy, human involvement).	AIRM-4.11-MATERIALITY-ASSESSED	airm.inventory, airm.materiality, airm.scan
§4.13	expectation	2027-10-07	Designate a control function to own the materiality framework and arbitrate or approve ratings, with independent oversight, clear documentation and regular review of assessments.	AIRM-4.13-MATERIALITY-ARBITRATED, AIRM-4.1-FRAMEWORK-PROCESSES	airm.inventory, airm.materiality, airm.scan
§5.1	expectation	2028-10-07	Plan and implement controls across the entire lifecycle of each use case, system or model; assign roles across units; review controls regularly for newer AI technologies.	AIRM-5.1-LIFECYCLE-ROLES, AIRM-1.7-PERIODIC-FRAMEWORK-REVIEW	airm.controls, airm.evals, airm.monitor, airm.thirdparty
§5.2	expectation	2028-10-07	Apply lifecycle controls proportionately to materiality; where constraints exist (e.g. limited third-party disclosure) identify the risks, mitigate (e.g. limit use) and keep residual risk within appetite.	AIRM-5.2-FN28-PILOT-GUARDRAILS, AIRM-5.11-LIMIT-SUSPEND-REPLACE	airm.controls, airm.evals, airm.monitor, airm.thirdparty
§5.3	expectation	2028-10-07	High-risk use cases need tested contingency plans with fallback options (alternative systems, manual processes), reviewed regularly; kill-switch activation protocols must exist and be tested.	AIRM-5.3-CONTINGENCY-PLAN, AIRM-5.3-KILL-SWITCH	airm.controls, airm.evals, airm.monitor, airm.thirdparty
§5.4	expectation	2028-10-07	Data across the lifecycle must be fit for purpose, representative, high quality and governed; cover fitness, representativeness, quality, classification, security, privacy, and auditability/lineage.	AIRM-5.4-DATA-GOVERNANCE, AIRM-5.4-DATA-CLASSIFICATION, AIRM-5.4-DATA-SECURITY, AIRM-5.4-DATA-PRIVACY, AIRM-5.4-DATA-LINEAGE	airm.controls, airm.evals, airm.monitor, airm.thirdparty
§5.5	expectation	2028-10-07	Establish controls for an appropriate level of transparency and explainability so customers, users and stakeholders can assess risks, reliability and limitations, and the FI can show AI use aligns with stated objectives.	AIRM-5.5-TRANSPARENCY-CONTROLS	airm.controls, airm.evals, airm.monitor, airm.thirdparty
§5.6	expectation	2028-10-07	Degree scales with context and materiality; high-impact uses (credit, underwriting, advisory, fund management) need input-feature justification, key-driver identification, customer notification, consequences and redress channels, tailored to the audience.	AIRM-5.5-TRANSPARENCY-CONTROLS, AIRM-5.6-CUSTOMER-DISCLOSURE	airm.controls, airm.evals, airm.monitor, airm.thirdparty
§5.7	expectation	2028-10-07	Define "fair" outcomes and control for harmful bias and discrimination across the lifecycle, calibrated to context and materiality; credit and underwriting warrant greater attention.	AIRM-5.8-FAIRNESS-ASSESSMENT	airm.controls, airm.evals, airm.monitor, airm.thirdparty
§5.8	expectation	2028-10-07	Where fairness is relevant, conduct fairness assessments: define protected attributes (and proxies), test for systematic disadvantage with fairness metrics, document results and mitigations.	AIRM-5.8-FAIRNESS-ASSESSMENT	airm.controls, airm.evals, airm.monitor, airm.thirdparty
§5.9	expectation	2028-10-07	Put in place and review human oversight proportionate to materiality, mindful of automation bias and decision fatigue; cover roles, capabilities and authority to intervene, design for oversight with escalation triggers, and documentation/review of interventions.	AIRM-5.9-HUMAN-OVERSIGHT, AIRM-5.9-DESIGN-FOR-OVERSIGHT, AIRM-5.9-OVERSIGHT-EFFECTIVENESS	airm.controls, airm.evals, airm.monitor, airm.thirdparty
§5.10	expectation	2028-10-07	Onboarding, development and deployment controls for third-party AI must fit materiality; contracts must give visibility of AI introduction and changes; test in the FI's context with its own data, do compensatory testing, and document suitability.	AIRM-5.10-THIRD-PARTY-TESTING	airm.controls, airm.evals, airm.monitor, airm.thirdparty
§5.11	expectation	2028-10-07	FI retains accountability for third-party AI; assess transparency, supply chain, concentration, change notification, contingency, legal terms, capabilities and complexity; if residual risk exceeds appetite, limit, suspend or replace the provider.	AIRM-5.11-THIRD-PARTY-TRANSPARENCY, AIRM-5.11-CHANGE-NOTIFICATION, AIRM-5.11-CONCENTRATION, AIRM-5.11-SUPPLY-CHAIN, AIRM-5.11-LIMIT-SUSPEND-REPLACE	airm.controls, airm.evals, airm.monitor, airm.thirdparty
§5.12	expectation	2028-10-07	When selecting systems, models or features consider objectives and risks; document the rationale proportionately to materiality, especially for complex choices; weigh performance against complexity, fairness, explainability; involve domain experts.	AIRM-5.12-SELECTION-RATIONALE	airm.controls, airm.evals, airm.monitor, airm.thirdparty
§5.13	expectation	2028-10-07	For newer, less-understood systems or models, weigh benefits against heightened risks such as hallucination, opaqueness and security, and the FI's capability to mitigate them.	AIRM-5.12-SELECTION-RATIONALE	airm.controls, airm.evals, airm.monitor, airm.thirdparty
§5.14	expectation	2028-10-07	Evaluate and test each system or model to an appropriate reliability and safety level before deployment; set measurable thresholds agreed by business, developers and reviewers; use representative datasets, diverse testing approaches, and overfitting mitigation.	AIRM-5.14-EVALUATION-MEASURES, AIRM-5.14-TESTING-APPROACHES	airm.controls, airm.evals, airm.monitor, airm.thirdparty
§5.15	expectation	2028-10-07	Mitigate identified risks and limitations with controls and guardrails before deployment; testing of Generative AI and agents must cover key failure modes and the effectiveness of guardrails.	AIRM-5.2-FN28-PILOT-GUARDRAILS, AIRM-5.15-GUARDRAIL-EFFECTIVENESS, AIRM-5.15-GENAI-FAILURE-MODES	airm.controls, airm.evals, airm.monitor, airm.thirdparty
§5.16	expectation	2028-10-07	Secure, well-governed AI systems with controls proportionate to materiality: hardened secure environments, input validation, API authentication, encryption, DLP; RBAC, MFA, privileged access, separation of duties; governance of third-party plugins and APIs.	AIRM-5.16-SECURITY-CONTROLS, AIRM-5.16-ACCESS-CONTROL, AIRM-5.16-AGENT-PERMISSIONS, AIRM-5.16-THIRD-PARTY-COMPONENTS	airm.controls, airm.evals, airm.monitor, airm.thirdparty
§5.17	expectation	2028-10-07	Document the development process so an independent party can understand and potentially replicate the implementation and its evaluation; rigour scales with materiality; cover data, selection, training, evaluation, explainability/fairness, assumptions and limitations.	AIRM-5.4-DATA-LINEAGE, AIRM-5.17-DEVELOPMENT-DOCUMENTATION	airm.controls, airm.evals, airm.monitor, airm.thirdparty
§5.18	expectation	2028-10-07	Before deployment, parties not involved in development review that controls were followed and assess suitability, robustness and performance within defined boundaries; scope and independence proportionate to materiality.	AIRM-5.18-PRE-DEPLOYMENT-REVIEW	airm.controls, airm.evals, airm.monitor, airm.thirdparty
§5.19	expectation	2028-10-07	High-materiality use cases need formal independent validation by competent, objective personnel independent of development and deployment, covering conceptual soundness, data, implementation integrity, evaluation results, explainability/fairness, assumptions.	AIRM-5.19-INDEPENDENT-VALIDATION	airm.controls, airm.evals, airm.monitor, airm.thirdparty
§5.20	expectation	2028-10-07	Non-high-materiality use cases may use other documented reviews, such as peer review by qualified individuals not involved in development or deployment.	AIRM-5.18-PRE-DEPLOYMENT-REVIEW	airm.controls, airm.evals, airm.monitor, airm.thirdparty
§5.21	expectation	2028-10-07	Reviewers report findings, limitations, remediation and conditions of use to the approval body, which ensures recommendations are actioned.	AIRM-5.21-FINDINGS-ACTIONED	airm.controls, airm.evals, airm.monitor, airm.thirdparty
§5.22	expectation	2028-10-07	Technology and cybersecurity reviews before production: secure design, least privilege, deployment checklists confirming encryption, DLP, firewalls, access, logging; vulnerability assessment, penetration testing, red teaming and adversarial testing with safeguards.	AIRM-5.22-SECURITY-REVIEW	airm.controls, airm.evals, airm.monitor, airm.thirdparty
§5.23	expectation	2028-10-07	Ongoing monitoring of all deployed AI proportionate to materiality: metrics and tiered thresholds, drift checks, agent reasoning/action/tool monitoring, incident management with kill switches for high risk, accountable roles, records and access logging, training.	AIRM-5.3-KILL-SWITCH, AIRM-5.23-MONITORING-MEASURES, AIRM-5.23-AGENT-TRACE-MONITORING, AIRM-5.23-GENAI-LOGGING, AIRM-5.23-INCIDENT-MANAGEMENT, AIRM-5.23-ACCOUNTABLE-PERSON, AIRM-5.23-TRAINING-AWARENESS	airm.controls, airm.evals, airm.monitor, airm.thirdparty
§5.24	expectation	2028-10-07	Re-validate or review AI as needed, with frequency and rigour informed by materiality; high-materiality use cases get regular independent re-validation; triggers include interconnected findings, monitoring breaches, significant changes, new external risks.	AIRM-5.24-REVALIDATION	airm.controls, airm.evals, airm.monitor, airm.thirdparty
§5.25	expectation	2028-10-07	Comprehensive change controls: a framework to grade change significance with review and re-approval for significant changes (compensating monitoring where prior review is impossible); change control with version tracking and rollback; enhanced controls for automatic updates.	AIRM-5.11-CHANGE-NOTIFICATION, AIRM-5.25-CHANGE-FRAMEWORK, AIRM-5.25-CHANGE-CONTROL, AIRM-5.25-DYNAMIC-UPDATES	airm.controls, airm.evals, airm.monitor, airm.thirdparty
§5.26	expectation	2028-10-07	Controls for retirement or decommissioning when AI is no longer needed or exceeds risk tolerance: dependencies, data retention, secure removal from production, stakeholder notification.	AIRM-5.26-RETIREMENT	airm.controls, airm.evals, airm.monitor, airm.thirdparty
§6.1	expectation	2028-10-07	Ensure competence and proper conduct of personnel developing, deploying and using AI: recruit talent, train, build culture; allocate human, technological and financial resources proportionate to risk.	AIRM-5.23-TRAINING-AWARENESS, AIRM-6.1-COMPETENCE	airm.controls
§6.2	expectation	2028-10-07	Regularly review that personnel have adequate capability and capacity, and that training programmes stay current for newer AI technologies.	AIRM-5.23-TRAINING-AWARENESS, AIRM-6.1-COMPETENCE	airm.controls
§6.3	expectation	2028-10-07	Technology infrastructure (compute, network, memory, secure data pipelines) must meet performance, scalability and resilience needs, considering technology risk management guidelines and industry frameworks.	AIRM-6.3-INFRASTRUCTURE	airm.controls

Footnotes that carry requirements

Several footnotes carry expectations rather than references, and the toolkit treats them as binding.

Footnote	Anchored to	Kind	Summary
fn1	§1.1	definition	FI as defined in Section 2 of the Financial Services and Markets Act 2022.
fn4	§1.2	scope	Consolidated supervision covers locally incorporated banking and insurance FIs.
fn5	§1.2	definition	Critical information infrastructure as defined in the Cybersecurity Act 2018.
fn6	§1.3	scope	In-scope examples: machine learning, deep learning, NLP, computer vision, generative AI/LLMs, AI agents and multi-agent systems. Out of scope: rule-based systems, manually specified formulae, fixed RPA.
fn7	§1.4	definition	Use case / system / model are used explicitly where a point is specific to one.
fn10	§1.10	definition	Third-party AI: AI systems or models, and services or tools incorporating AI, developed, owned, operated or provided externally that an FI procures, subscribes to, accesses or relies on.
fn13	§2.4	expectation	Humans in the 2.4 example use cases should review and check outputs before use.
fn20	§3.5	definition	AI incident means an incident involving failure, malfunction or poor performance of the underlying AI system(s) or model(s).
fn21	§4.2	scope	Embedded AI example: SaaS not sold as AI but containing AI features the FI uses.
fn22	§4.4	guidance	Shadow-AI mitigations: staff guidance on allowed/disallowed uses including embedded features and public tools, and technical controls such as network monitoring and data loss prevention to detect unauthorised AI use.
fn23	§4.6	guidance	Linkages via consistent data asset identifiers to data inventories and vendor/service identifiers to third-party registers.
fn24	§4.7	expectation	Differences in attributes captured across use cases must be delineated in policy; omissions must not compromise oversight.
fn25	§4.8	guidance	Agent inventory attributes: agent-specific identifiers, tools and systems the agent can access, its components, and the guardrails imposed.
fn26	§4.10	expectation	Dependencies between AI systems or models supporting a use case should be considered where they affect its risk profile.
fn27	§5.1	definition	AI life cycle spans inception to retirement (adapted from ISO/IEC 22989).
fn28	§5.2	expectation	Partial deployments (pilots, phased rollouts) need policies governing deviations from standard controls: time and user limits, success criteria, terms of use, close monitoring, scope compliance.
fn29	§5.3	definition	Kill switches are mechanisms to deactivate AI expeditiously if it exceeds risk tolerances.
fn32	§5.5	definition	Transparency is disclosure to affected individuals plus explanations on request; explainability is methods (built-in or post-hoc) for understanding outputs.
fn34	§5.6	guidance	Customer disclosures need not be technical (effects, basis for decisions, redress); technical detail suits internal evaluators; IMDA chatbot transparency guidelines referenced.
fn36	§5.8	expectation	Proxies for, or attributes highly correlated with, protected attributes must also be considered.
fn37	§5.9	scope	Human oversight expectations cover every case where the FI judged human involvement necessary, whether in-the-loop or over-the-loop.
fn38	§5.10	scope	Development controls apply where the FI modifies or fine-tunes third-party AI before deployment.
fn39	§5.10	scope	MAS outsourcing and third-party service expectations apply to third-party AI.
fn41	§5.12	definition	Models include specific ML/DL models or techniques such as optimisation or fine-tuning.
fn42	§5.12	definition	Features are dataset attributes; feature engineering creates or transforms them.
fn45	§5.15	guidance	Pilots or phased rollouts with guardrails can be used to obtain representative data when testing data is limited.
fn46	§5.15	expectation	GenAI testing must pay particular attention to hallucination, toxic/harmful/biased content, bias, data leakage or disclosure, and vulnerability to adversarial attack.
fn48	§5.20	scope	Reviewers must be independent of both initial and ongoing deployment (operation) of the AI.
fn49	§5.25	guidance	Change examples: training data, model/system architecture, key assumptions, scope of use, downstream impact.

Expectations with no implementing control

• §2.2 (Application of the Guidelines) — Unless 2.3 applies, an FI must establish oversight frameworks with AI identification, materiality assessment and inventory (Sections 3-4) and apply lifecycle controls and capabilities (Sections 5-6), calibrated by relevance and risk materiality.