Compliance You Cannot Demonstrate Is Compliance You Do Not Have: Willy Tadema on EN 18286, AI Standards, and What the AI Act Actually Requires
Q1. The publication of EN 18286 — the AI Quality Management System standard — is a significant milestone for organizations trying to operationalize the requirements of the EU AI Act. For a Chief Risk Officer, a Head of Compliance, or a public sector technology leader who has been following the AI Act but has not yet engaged deeply with this specific standard, can you explain in concrete terms what EN 18286 actually requires organizations to do that they are probably not doing today — and what the gap typically looks like between an organization that thinks it is AI Act-ready and one that actually is?
EN 18286 helps providers of high-risk AI systems set up a quality management system, as required by Article 17 of the AI Act. To meet EN 18286, you must set out how you will demonstrate compliance for each high-risk AI system in scope, and manage and document the evidence for it throughout the lifecycle.
Three things are easy to miss. The first is the meaning of “quality” in this context. Traditionally (ISO 9000) quality is how well a product meets the needs of customers and other interested parties. In EN 18286, quality is about compliance with the AI Act. That is the goal of the QMS: to ensure that each high-risk AI system complies with the AI Act throughout its entire life cycle. The second point is that, although EN 18286 sets organisational requirements, it is product-focused, unlike ISO 9001 and ISO/IEC 42001. This is because the AI Act is product safety legislation: in the end, it is the product — the high-risk AI system — that must meet the essential requirements of the AI Act. The third point is that risk here is not organisational risk, but harm to people and groups: injury or damage to their health and safety, and interference with their fundamental rights.
The gap is really a shift in thinking. An organisation that thinks it is ready mistakes strong organisational governance, such as policies and an ISO 42001 certificate, for compliance. An organisation that actually is ready can show, for a specific AI system, the evidence that it meets the AI Act, and it has taken the risks to people’s health, safety and fundamental rights into account.
Q2. The presumption of conformity that comes with demonstrated adherence to EN 18286 once the European Commission harmonizes the standard is a significant legal and operational benefit — it shifts the burden of proof toward regulators rather than leaving organizations to demonstrate compliance from scratch in each interaction. But “demonstrably working in accordance with EN 18286” is not a trivial threshold. What does that actually require in terms of documentation, process governance, and organizational structure — and what are the most common ways you expect organizations to fall short of meeting that threshold even while believing they have done the work?
Without presumption of conformity, a provider has to prove from scratch that its approach meets the requirements of the AI Act. A harmonised standard replaces that with a recognised baseline: follow the harmonised standard, and you are presumed to meet the corresponding legal requirements, unless an authority shows otherwise.
I won’t reproduce the standard here, but what is worth saying is what the threshold demands in practice: a system in which compliance of a specific AI system can be traced to evidence, to a decision that was actually made, and to a person who owns it. Documentation has to be controlled and retrievable, processes defined and followed, and responsibility assigned to clear roles with the competence to carry it. For the exact requirements, the standard itself is the source.
An important part of EN 18286 is the strategy for regulatory compliance: how are you going to demonstrate compliance with the essential requirements in Articles 9 to 15? Here the provider chooses an approach — whether, and to what extent, to follow the harmonised standards to meet the essential requirements — and then selects and documents the measures that show how each of them is met. Choosing the harmonised standards lowers the burden of proof and the level of justification you have to provide. The strategy also covers determining the applicable conformity assessment procedure: internal control (Annex VI) or assessment involving a notified body (Annex VII).
A common mistake is to think that an ISO/IEC 42001 certificate is enough for presumption of conformity. It is not. ISO/IEC 42001 is a global, general-purpose AI management standard. It is valuable for any organisation that develops or uses AI, but it serves a different purpose: it was not written for compliance with one specific regulation, and on its own it does not meet the EU AI Act’s requirements. The two standards are, however, complementary — EN 18286 does not replace ISO/IEC 42001. A mature AI management system gives you a head start.
EN 18286 recognises the overlap: its annexes map its clauses to ISO/IEC 42001 and ISO 9001. A clear difference is the clause on AI system realization: requirements for each lifecycle stage, for data management, for continuous learning systems, and for product documentation — the technical file kept ready for regulatory review, and the instructions for use for the deployer. EN 18286’s Annex C makes the gap visible: the whole clause on AI system realization maps to a single, much narrower subclause in ISO/IEC 42001. Part of that ground does appear in ISO/IEC 42001, but as selectable controls in its own annex — in EN 18286 they are binding requirements.
Another source of confusion, especially among organisations unfamiliar with product safety legislation, is conformity assessment. It is sometimes mistaken for an ethical assessment or an impact assessment, but it is neither: it is the formal procedure to verify that a high-risk AI system meets the requirements of the AI Act before it is placed on the market or put into service.
Where I see organisations struggle most, though, is not with doing the work, but with proving it. Under EN 18286, compliance you cannot demonstrate is compliance you do not have — and without that demonstration, there is no presumption of conformity to fall back on.
Q3. EN 18286 translates Article 17 of the AI Act — which covers quality management systems for high-risk AI — into concrete, applicable specifications. Article 17 is notably detailed about what a QMS must cover: risk management, data governance, technical documentation, transparency, human oversight, accuracy, robustness, and cybersecurity. From your experience working within Dutch government on algorithmic decision-making and AI in public administration, which of these dimensions do organizations — both public and private — consistently underinvest in, and which ones generate the most difficult implementation challenges in practice?
This is a difficult question, mainly because we are still at the very beginning of implementing the AI Act. But if I have to choose, I would say: risk management. I see many organisations dive straight into human oversight, accuracy or data bias. Your starting point, however, should be the quality management system, then the risk management system, and from there the more technical standards.
There are three reasons why risk management should come before the more technical topics. The first is that it determines what you actually need. In product safety logic, areas such as human oversight, accuracy and cybersecurity each address specific hazards. Which control measures are appropriate follows from your risk analysis, not the other way around. If you skip that step, you are choosing measures without knowing which risks they are supposed to address, and you cannot justify afterwards why they are enough.
The second reason is that the intended purpose and the reasonably foreseeable misuse are the foundation. The risk management process starts before development begins, by defining what the system is for and how it can reasonably be misused. Those two define your risk acceptability criteria, and with them the boundaries of compliance. Without that foundation, there is no baseline to test accuracy or bias against.
The third reason is that it demands a different way of thinking. Organisations familiar with ISO 31000 are used to weighing risks against their own objectives and risk appetite. That flexibility does not exist in product safety legislation. For organisations without that background — including many public administrations — that is the biggest shift.
So my answer to both questions is the same: the underinvestment is in risk management, and the hardest part is learning to do it the product safety way.
Q4. You are also preparing to publish the Dutch Technical Agreement for public profiling algorithms — a standard that addresses one of the most sensitive and contested applications of AI in government: the use of algorithms to profile citizens for public services, benefits, or enforcement. Profiling algorithms have been at the center of some of the most serious AI failures in European public administration in recent years, including the Dutch childcare benefits scandal. What does the Dutch Technical Agreement establish that current practice does not, and what are the most important safeguards it introduces for citizens who are subject to public profiling?
The Dutch Technical Agreement NTA 8047, “Development and testing methods to support compliance with the principle of non-discrimination in profiling algorithms”, focuses on indirect distinction: an apparently neutral provision, criterion or practice that, compared with other persons, particularly affects people with a protected characteristic such as ‘race’ or nationality. In the outcomes of profiling algorithms, indirect distinction often goes unnoticed, or is accepted without any justification — even though we have seen how much harm it can do to individuals and groups in society.
NTA 8047 is built on one core principle. When a government organisation uses a profiling algorithm, it must test whether the algorithm produces indirect distinction. And if it does, the organisation must draw the conclusion that this is discrimination, unless there is an objective justification. Without an objective justification, indirect distinction is discrimination.
The legal protection itself is not new: government organisations were already required to test for indirect distinction and to carry out the objective justification test. What we have tried to do is build a bridge between legal experts and engineers. How do you operationalise these obligations? Which testing methods do you apply? NTA 8047 provides qualitative and quantitative methods for exactly that: identifying indirect distinction, and carrying out the objective justification test. For citizens subject to public profiling, that is the safeguard: legal protection that is actually put into practice.
A Dutch Technical Agreement is not a full standard. In the coming period, the Dutch government will test its value in practice through pilots, and we are having NTA 8047 translated into English and made available free of charge, to gather as much feedback as possible. We expect the English version to be available in September. Based on the experience we gain and the feedback we receive, we will then explore whether it can be developed into a full standard.
Q5. You sit at a genuinely unusual intersection — you are a member of the Z-Inspection® initiative, which conducts independent assessments of AI systems against trustworthy AI principles, and you are actively involved in creating European AI standards for the AI Act. Those two roles reflect different but complementary approaches to the same problem: making AI trustworthy in practice rather than just in principle. How do the insights you gain from hands-on Z-Inspection® assessments of real AI systems inform the standards you help write — and conversely, where do you find that standards work reveals gaps or blind spots that the assessment process alone would not have surfaced?
What I take from Z-Inspection® into standards work is, first of all, practical experience: hands-on assessment of a real AI system from different perspectives — ethical, legal, technical, and the domain itself. That experience is valuable when writing standards, because a standard ultimately has to work in practice. When you have done such an assessment yourself, you know which specifications are implementable and testable, and which only sound good on paper.
I have also learned how important a common language is. Without it, you end up with separate legal, ethical, technical and domain assessments, leaving the person ultimately responsible for the AI system to weigh them — instead of one integrated assessment. Each discipline needs its own precise vocabulary, because the details it captures matter. But to assess values and risks, and to weigh them against each other, you have to move from that open, discipline-specific vocabulary to a shared, closed one. The system of harmonised standards for the AI Act attempts something similar: assessing risks of very different kinds, weighing them, and drawing a conclusion — is this acceptable?
Finally, I take with me the claim–argument–evidence framework that is fundamental to Z-Inspection®. Every claim about an AI system has to be supported by arguments, and every argument by evidence. That way of reasoning and documenting is exactly what demonstrating conformity under the AI Act requires: you claim that a requirement is met, you explain why, and you back it up with evidence.
The other way around, standards work has also taught me a few things. In standardisation, legislation is the starting point. That is limiting, in a sense: you are bound to the legal text. And with harmonised standards, you also have to be confident that the specifications cover the essential requirements to a sufficient degree. A Z-Inspection® assessment can ask what is right, beyond what the law prescribes; a harmonised standard cannot.
And I find the standardisation process itself fascinating. At first sight it is bureaucratic and time-consuming, but it brings stakeholders to the table, gives them a voice, and builds support for the end result. Nearly 400 experts contributed to EN 18286, there was a public consultation round, and more than 4,000 comments were processed by consensus. That is quite an achievement. Developing a standard is, of course, different from assessing a single AI system. But I think the Z-Inspection® framework could draw inspiration from the standardisation process, especially when working with larger groups of experts, or when seeking feedback from outside the assessment team.
Q6. You have spent years working within Dutch government to address discrimination and ensure fairness in algorithmic decision-making — work that is often unglamorous, technically demanding, and politically sensitive all at once. For a policymaker or public sector leader in another EU member state who is looking at the AI Act compliance timeline and feeling overwhelmed by the combination of technical, legal, and governance requirements it imposes, what is the single most important piece of practical advice you would give them — the thing you wish you had known earlier in this work that would have made the journey less painful and the outcomes more durable?
My advice is personal, because it comes from my own driving force behind joining the Z-Inspection® initiative and the standardisation working groups. Responsible AI is a young and immature field. There is little to hold on to, and that can make you insecure. It also makes you vulnerable — I have experienced that myself. When the outcome of an assessment is unwelcome to the commissioning organisation, it is easy to criticise the assessor, or the assessment process and methods. That is why frameworks like Z-Inspection®, tested scientifically and in practice, are so important — and that is why standards are so important. They are condensed knowledge and experience you can fall back on.
So my advice: you do not have to invent this yourself — that is what I wish I had known earlier. Do not take this on alone. Anchor your work in tested methods and standards, and join the communities that build them. It makes the work less lonely, and the outcomes more durable.
Note: where to find EN 18286
EN 18286 is a European standard and, like all European standards, it is distributed through the national standardisation institutes. There is no single link: you can obtain the text from your own national standards body. In the Netherlands, that is NEN; in other countries, look for the national equivalent, such as BSI (UK) or DIN (Germany).
…………………………………………………………….
Willy Tadema is an AI governance consultant with the Rijks ICT Gilde at the Dutch Ministry of the Interior and Kingdom Relations. She is an AI standardisation expert at both national (NEN) and European (CEN-CENELEC) level, and a member of the Z-Inspection® initiative. Willy also serves on the Data & Technology Ethics Committee of the Municipality of Groningen and on the Interprovincial Ethics Committee. Her work focuses on translating ethical, legal and policy frameworks into practice.