We Have a Policy, a Standard and a Certificate — What Do They Prove?

The legal framework defines the obligation

The legal layer determines which obligations attach to an AI system, the organisation's regulatory role and the evidence required for compliance.

Within the European Union, the AI Act sits alongside GDPR, DORA and existing sectoral requirements. The relevant obligations depend on matters such as the intended purpose, system classification, affected persons, organisational role and use within a regulated process.

For high-risk AI systems, the AI Act addresses areas including risk management, data governance, technical documentation, record-keeping, human oversight, accuracy, robustness, cybersecurity and quality management. Article 17 requires providers to maintain a documented quality-management system that ensures compliance with the Regulation.

This does not mean that a bank should build an isolated AI Act control structure. Existing governance requirements remain relevant. DORA governs ICT and operational resilience. GDPR establishes accountability for personal-data processing and restrictions around certain automated decisions. Financial-sector governance, outsourcing, conduct and model-risk requirements may continue to apply to the same system.

The legal layer must therefore answer three questions:

• Which obligations apply?
• To which entity, role and use case do they apply?
• Through which controls and evidence will they be demonstrated?

A legal inventory that does not connect to controls remains an interpretation. A control library that does not connect to law remains an internal design choice.

The management system makes governance repeatable

ISO/IEC 42001 establishes requirements for an AI management system. It addresses the organisational processes used to establish, implement, maintain and improve AI governance.

Its value lies in repeatability. It can provide a structure for scope, policy, objectives, responsibilities, risk processes, competence, communication, monitoring, internal audit and continual improvement.

A certification against ISO/IEC 42001 is therefore meaningful evidence about a defined management-system scope. It does not automatically establish that every AI use case is inside that scope or that every system complies with the EU AI Act.

That distinction is reinforced by EN 18286:2026, the first European standard published in support of implementing the AI Act. It addresses the quality-management system required for regulatory purposes, particularly Article 17.

CEN-CENELEC JTC 21 considered whether ISO/IEC 42001 could be adopted for the quality-management requirement in Article 17 of the AI Act. Because the objectives and definitions were not considered fully aligned with that regulatory requirement, a separate European standard was developed: EN 18286, Artificial intelligence — Quality management system for EU AI Act regulatory purposes.

The point is not that ISO/IEC 42001 is inadequate. The point is that an organisational management-system standard and a regulatory quality-management requirement do not establish the same thing.

EN 18286 defines quality in relation to conformity with applicable AI Act requirements rather than product quality in the conventional ISO 9001 sense. Its structure also allows the AI-specific requirements to be incorporated into an existing sectoral quality-management system rather than forcing organisations to create a second parallel system.

For banks, the practical principle is integration. AI governance should extend existing enterprise, technology, data, risk and operational-resilience frameworks where those structures remain appropriate.

Article 40 of the AI Act provides a presumption of conformity only where the reference to a harmonised standard has been published in the Official Journal, and only for the requirements that the standard covers. At the end of July 2026, the reference to EN 18286 had not yet been published in the Official Journal.

An institution can buy a certificate. It cannot buy the crosswalk.

The board should therefore request the precise certification scope, exclusions, covered activities and relationship to the AI inventory and regulatory obligations.

The risk framework structures judgement

The NIST AI Risk Management Framework organises AI-risk activity through four functions:

• Govern
• Map
• Measure
• Manage

Govern is cross-cutting. Map establishes context and identifies affected parties and risks. Measure assesses and monitors system behaviour and risk. Manage prioritises and treats risks according to organisational objectives and tolerances.

This creates a common language for AI risk without prescribing one regulatory outcome or one control set.

The framework can support:

• risk taxonomy;
• use-case classification;
• impact and materiality assessment;
• risk measurement;
• acceptance criteria;
• escalation thresholds;
• and treatment decisions.

But the framework does not determine which legal obligations apply. Nor does completion of a risk assessment demonstrate that the mitigation operates effectively.

Classification should determine the governance route. It should not merely populate a reporting field.

A high-impact customer decision, a low-risk internal productivity tool and an autonomous agent with production access should not follow the same approval, testing and monitoring route. Each should, however, follow a defined route that can be explained and evidenced.

The board should expect every material risk decision to connect to:

• an accountable owner;
• an approved tolerance;
• a control objective;
• an implemented control;
• a test;
• and a current operating status.

Testing and assurance produce evidence

Testing converts governance claims into examinable evidence.

AI Verify illustrates this layer through eleven governance principles. Each principle is connected to intended outcomes, processes and documentary evidence. The framework combines technical and non-technical assessments rather than treating trustworthy AI as a model-performance question alone.

Testing and assurance may include:

• accuracy and performance assessment;
• robustness and cybersecurity testing;
• bias and fairness evaluation;
• explainability assessment;
• data-lineage and quality evidence;
• impact assessment;
• human-oversight exercises;
• red-team and misuse testing;
• reproducibility checks;
• control testing;
• and independent assurance.

The relevant test depends on the intended use. A model may perform well on a benchmark and still be unsuitable for a specific decision, customer population, operating environment or risk tolerance.

A statement that a human remains "in the loop" is not a control description. The governance record should identify what the person decides, which information is available, how much time exists to intervene and whether the person has the authority to alter the outcome.

The same discipline applies to external certification. ISO/IEC 42006 establishes requirements for bodies that audit and certify AI management systems. It supports confidence in the certification process; it does not enlarge the scope of what ISO/IEC 42001 certifies.

The board does not need to approve individual test scripts. It should require management to explain:

1. the outcome being tested; 2. the reason the method is appropriate; 3. the acceptance threshold; 4. who may approve an exception; 5. how long the evidence remains valid; 6. and which changes require reassessment.

The purpose of board reporting is not to reproduce the AI inventory. It is to show whether the governance system remains effective and where a decision is required.