An organisation that 1) received its CASP authorisation from a National Competent Authorities (NCAs) such as the Luxembourg CSSF, fully authorised under MiCA, 2) is in scope of DORA via Article 2(1)(20), and 3) with most of the AI systems outside the high-risk obligations of the EU AI Act, could conclude it has no obligation to operate an AI management system (AIMS) at all.
While that reading is technically defensible, it can be challenged considering where supervisory pressure is going.
Let us assume that such organisation uses AI on roughly 55% of fraud cases, and with an internal target of 50% AI-generated code, and the firm has launched the Payments MCP protocol to let AI agents transact with crypto autonomously. None of those activities, taken individually, places the firm in Annex III of the AI Act. All of them sit inside operations the CSSF, ESMA, and the EBA already supervise under MiCA and DORA. The supervisory question is no longer whether AI is in scope. It is what an AI-specific governance discipline looks like inside an organisation where the law has already authorised everything it does.
This article explains why a fully MiCA-authorised CASP still needs an AI management system (AIMS), what an AIMS delivers that ISO/IEC 27001 and DORA’s ICT framework do not, and where the harmonised standards landscape is moving to. We consider here the CEN adoption of EN ISO/IEC 42001:2026 in March 2026, the upcoming prEN 18286 and the rest of the JTC 21 programme.
The regulatory triangulation
MiCA imposes a governance and operational-resilience layer through Articles 67–74 that says nothing AI-specific but assumes the firm controls every operational risk material to clients and the market. DORA requires an ICT risk-management framework (Articles 5–15), incident reporting (Articles 17–23), digital operational resilience testing (Articles 24–27), and third-party ICT risk management (Articles 28–44). None of these provisions carve out AI as a special category. None prescribe AI-specific controls. MiCA Article 68(7)–(8) hands its operational-resilience layer to DORA Articles 11 and 12 wholesale, by number.
So the supervisor reads MiCA’s “appropriate governance” through DORA’s “appropriate ICT risk management”. For a CASP where AI is the engine of fraud detection, sanctions screening, transaction monitoring, KYC verification, and increasingly customer-facing agentic services; the supervisor expects the firm to demonstrate appropriate controls over the AI components of every operation it has authorised. The Regulations do not specify what “appropriate” looks like for AI. The AIMS is the only running discipline that fills the gap with auditable evidence.
What an AIMS delivers that 27001 and DORA do not
ISO/IEC 27001 governs information security. It does not address AI-specific concerns: model lifecycle, training-data provenance, drift monitoring, explainability, bias testing, post-deployment performance evaluation. DORA’s ICT risk framework was drafted for classical IT and covers application security, change management, third-party assurance, backup and recovery. AI is not mentioned anywhere.
ISO/IEC 42001:2023 imposes specifically AI-shaped obligations. Clause 5 and Annex A.2 require a documented AI policy linked to the firm’s risk appetite. Annex A.5 requires AI system impact assessments. Annex A.6.1 specifies processes for responsible design and development covering data acquisition, model training, verification, validation, and deployment. Annex A.6.2 and A.9 cover processes for responsible use, including monitoring, event logging, and incident handling. Annex A.7.2–A.7.6 govern data quality and provenance. Annex A.10 sets supplier and customer obligations specific to AI.
For an AI-powered fraud-detection stack, those controls translate into concrete artefacts: an inventory of every model in production, classification of each model against the firm’s risk taxonomy, documented training-data sources with provenance and quality controls, drift and bias monitoring on model outputs, defined human-oversight roles for blocked transactions and account freezes, logged decisions sufficient to reconstruct any individual outcome under regulator request, and an incident-response playbook calibrated for AI failure modes (e.g. model collapse, training-data poisoning, prompt injection on agent endpoints, hallucinated outputs reaching customer communications).
None of those artefacts is produced by an ISO/IEC 27001 certificate or a SOC 2 Type II report. None is produced by a DORA-aligned ICT risk register that treats the AI subsystem as one more application. They are produced by running an AIMS, and they are precisely the artefacts a supervisor will ask for. A NCA’s MiCA fitness reviews and DORA’s first full supervisory cycle are the venues in which that ask will become concrete.
The European standards picture, as of mid-2026
Two developments are relevant here.
First, ISO/IEC 42001:2023 is now itself a European Standard. EN ISO/IEC 42001:2026 was approved by CEN on 13 March 2026 following a direct CEN-CENELEC enquiry that ran from 20 November 2025 to 12 February 2026. CEN/CENELEC members are bound to transpose it as a national standard without alteration, which is why BSI has published BS EN ISO/IEC 42001:2026 in the UK, with equivalent national adoptions in the other CEN/CENELEC countries. The technical content is identical to ISO/IEC 42001:2023 but its standing is no longer international-only. It is the European baseline AIMS standard. However, on its own it confers no presumption of conformity for EU AI Act purposes.
The European Commission has been explicit about why it did not simply harmonise 42001. The Commission’s own digital-strategy guidance states that “although ISO/IEC 42001:2023 helps to set up an AI management system, its goals and definitions are not aligned with the quality management system that is required under the AI Act.” The JRC’s evaluation of the JTC 21 work programme reached the same conclusion: 42001 has limited coverage on logging and recordkeeping, treating both as optional risk controls, whereas the AI Act mandates them at Articles 12 and 19. The Commission therefore asked CEN-CENELEC JTC 21 to develop a home-grown QMS standard built specifically against Article 17 of the AI Act. That is prEN 18286.
prEN 18286, titled Quality Management System for EU AI Act regulatory purposes, completed its Public Enquiry at the beginning of 2026. The CEN-CENELEC On the Spot newsletter of 27 May 2026 confirms that all comments have been reviewed and the standard is now out for Formal Vote by the National Standardization Bodies after the harmonised-standard review. It supports Article 17, the provider QMS obligation that the Article 17(4) deemed-fulfilment in financial-services regulation modifies but does not eliminate. Once published with OJEU citation, it triggers the Article 40 presumption of conformity for the QMS dimension of high-risk AI Act compliance.
The rest of the JTC 21 programme sits alongside it. prEN 18228, supporting Article 9 (risk management), is under Public Enquiry until the end of July 2026, with the ETUC actively contributing to its development. JTC 21 is further developing prEN 18283 on managing bias in AI systems, formally requested by the European Commission to facilitate implementation of the Article 10 data and data governance requirements.
The architectural relationship between EN ISO/IEC 42001:2026 and prEN 18286 is the part most worth understanding. EN ISO/IEC 42001:2026 is the foundational AIMS scaffold. It is voluntary, certifiable, applicable to any organisation using or providing AI, broader in scope than the EU AI Act. prEN 18286 is the AI Act-specific QMS instrument that sits on the same scaffold and extends it for high-risk regulatory purposes. The draft of prEN 18286 includes an annex mapping its requirements directly to ISO/IEC 42001 Annex A controls, so organisations operating an EN ISO/IEC 42001 AIMS can carry their existing controls into the harmonised-standard regime when prEN 18286 is cited in the OJEU, rather than rebuild from scratch.
This is the most consequential design choice in the standards programme for any firm thinking about sequencing. Implementing EN ISO/IEC 42001:2026 today is not adopting an international standard while waiting for the European one to arrive. It is adopting the European AIMS standard now, against a scaffold the EU AI Act-specific QMS standard is being explicitly designed to extend.
What about waiting for prEN 18286?
The temptation, for a CASP whose AI is mostly non-high-risk, is to wait. Wait for prEN 18286 to be cited in the OJEU. Wait for the AI Act’s high-risk obligations to clarify in practice. Wait for the EU AI Office to publish guidance. Then implement against the harmonised standard with the presumption-of-conformity shield, skipping the intermediate 42001 step entirely.
This can be challenged for three reasons.
The first is supervisory cadence. NCAs such as Luxembourg’s CSSF are already conducting MiCA fitness reviews. ESMA’s review of national licensing practices is already producing reports. DORA’s first full supervisory cycle is underway in 2026. None of these processes will pause for the Commission to publish a reference in the OJEU. The supervisor will ask what governance the firm has over its AI subsystems.
The second is procurement. Enterprise vendor due diligence. AI-governance attestations will start entering RFP questionnaires in the same way ISO/IEC 27001 entered them a decade ago. There is no equivalent attestation against prEN 18286 that a buyer can request today. There is an equivalent against ISO/IEC 42001, and the market is starting to adopt it as the AI-governance signal of choice.
The third is litigation and enforcement posture. If an AI-driven decision goes wrong such as a wrongful account freeze, a sanctions misclassification, a biased fraud refusal triggering a consumer-protection claim or a class action then the firm’s defence rests on demonstrating documented due diligence in AI governance. A 42001-certified AIMS, with documented risk treatment, oversight controls, and incident logging, is materially better defensive evidence than a 27001 certificate read across to AI by analogy. The same is true in front of a supervisor enforcing Article 7 of MiCA on fair, honest, and professional conduct, or Article 5 of DORA on ICT risk-management governance.
For a MiCA-authorised CASP that whose AI may handle over 50% of fraud cases and whose leadership team has publicly described the operating model as “intelligence, with humans around the edge”, the cost of arriving at the supervisor’s question without an AIMS is asymmetric. The cost of arriving with one, built on a standard whose successor is explicitly designed for forward compatibility, is moderate, scoped, and recoverable.
The principle that runs through all of this
The key compliance question here is “what AI-specific governance can a MiCA-authorised CASP demonstrate when the regulator, the institutional buyer, or the claimant’s counsel asks?”
ISO/IEC 42001 is the only running standard that produces the evidence in a form a third party can verify. The harmonised standard now at Formal Vote at CEN-CENELEC is being designed to take that evidence forward. The organisations that build the AIMS now are not buying a regulatory shield they do not yet need. They are buying the operating discipline that makes the supervisory conversation, the procurement conversation, and the litigation conversation answerable in the same vocabulary the regulator and the buyer are already moving toward.
The text of the Regulations does not require an AIMS yet. The supervisory practice already does.