I look at this as someone who audits rather than sells. In five industries and five countries I have run audits, from aviation to precision manufacturing. What an auditor learns: the one polished act says little. The small, unvarnished details say everything.

The cheapest test almost nobody runs

Scroll to the bottom of the consultant website and open the legal notice, in Germany the Impressum. If it still references the Telemediengesetz, the TMG, that is a first, quiet warning sign. The TMG was replaced in May 2024 by the Digital Services Act, the DDG. The obligation to publish a legal notice now sits in Section 5 DDG, not in the TMG anymore.

Sounds like a tiny detail. It is not. Many of these pages were written by an AI, or at least clicked together with one. And if someone never even proofread their own legal notice, then they did not check the output of their AI. On the very text that makes them legally easiest to attack.

Anyone who does not check their own AI output is not someone I would trust with another companys processes.

This is not legal advice and not a call to send warning letters. It is an assessment. An outdated legal notice does not make anyone a bad person. But it says something about the care with which someone works. And care is exactly what you expect from a person who is meant to touch your data and your processes.

What an outdated legal notice also reveals

The legal notice is a small, clearly regulated mandatory text. If even that is wrong, it hints at how someone works in general. Watch for these patterns:

• A reference to the TMG instead of the DDG, even though the DDG has applied since May 2024.
• A dead link to online dispute resolution that leads nowhere.
• Vague, generic wording that sounds like an unedited template.
• No named, accountable person for the content.
• Technical terms that do not fit together because they come from different templates.

Each single sign is harmless on its own. Several together form a pattern. And patterns are exactly what an auditor watches for: not the one mistake, but the accumulation that shows how carefully or carelessly someone works. A single typo is human. A consistently unchecked web presence is a statement.

And yes, the same applies to my own trade. I have my legal notice checked regularly too. Not because I fear warning letters, but because I expect from others the same care I deliver myself. Anyone who sells scrutiny has to apply it to themselves first.

Three sentences that make me listen closely

In conversation a pretender gives themselves away faster than they would like. Three sentences make me sit up immediately:

• We will just build you an AI agent that handles it. Before anyone has understood the process.
• The AI does that fully automatically, you do not need to check anything. The exact opposite of accountability.
• We will deliver the numbers later. When the needs analysis ends without a tangible result on the table.

None of these sentences is a crime in itself. But they reveal an attitude: technology before process, speed before care, promises before evidence. That order is exactly what leads to expensive surprises in operations.

Process first, then the tool

The most important sign shows in the first question. A credible advisor asks about your process first. A pretender talks about their tool immediately. Anyone who wants to build you an AI agent in the first meeting, without understanding your workflow, is not selling you a tool, but a risk.

Take three typical mid-market cases. An AI that pre-sorts applications. A camera with a model that inspects parts in final control. An AI that creates orders in the ERP. In all three the technology is the easy part. The hard part is the process behind it: who decides, who checks, what happens when it fails.

A picture from the shop floor: you would not buy an expensive CNC machine before it is clear which part it should make, in what quantity and to what tolerance. First the part, then the process, then the machine. With AI it is exactly the same. Put AI on a broken process and it just automates the mess, faster and more expensively. You get the same error, now a thousand times over and stamped objective.

A good advisor therefore brings order to the workflow first and asks about the tool second. That is less comfortable, because it sounds less like the future and more like homework. But it is the only path where something usable stands at the end.

First the process. Then the tool. And only after that the AI.

A needs analysis is not an end in itself

A needs analysis that ends with no tangible output, only the recommendation to keep consulting, is a warning sign. You then pay for the consultants learning curve, not for your own progress. Ask up front what concretely lands on the table at the end: a decision basis, a process map, a clear make-or-buy comparison.

Credible consulting makes itself redundant by making you capable. Poor consulting makes itself indispensable by building dependency. You tell them apart by whether something stays in your house after each meeting, something that carries on even without the consultant.

Why an auditor asks differently than a salesperson

A salesperson wants you to buy. An auditor wants it to hold. That difference sits in every question. The salesperson shows you what the AI could do. The auditor asks what happens when it gets it wrong, who notices, and how fast. For your business you need the second kind of person, even if the first sounds more pleasant.

This stance costs speed in the short term and saves money in the long run. I have seen enough businesses buy an expensive solution because the presentation was good, only to find a year later that nobody in the house could operate, check or, in an emergency, switch the thing off. The bill then comes twice: once for the tool and once for the cleanup.

The accountable human on the letterhead

Artificial intelligence does not carry liability. In the end a human always stands accountable, with their name, on the letterhead. A credible advisor knows this and names clearly who carries responsibility, instead of delegating it to a model.

Ask concretely: who checks the output? By what rule? Who signs at the end? If the answer is a shrug, you have your answer. A named person with a simple checking rule is worth more than any glossy presentation.

This same stance sits inside a management system for AI under ISO/IEC 42001: named accountability, checked output, documented processes instead of gut feeling. In the end an audit checks nothing other than whether there is a clear-headed human behind the tool and whether they can prove what they claim.

Your quick check for the next consultant meeting

You do not need to be an AI expert to ask the right questions. These five are enough to separate substance from show before you sign a contract.

• Does the legal notice cite the DDG or still the old TMG?
• Does the advisor ask about my process first or about their tool first?
• Can they show what the AI does on a real example, instead of just slides?
• Who carries responsibility after the rollout, by name?
• What happens when the AI gets it wrong, and who even notices?

Anyone who answers these five confidently and concretely has understood what matters. Anyone who dodges, shows slides and talks about big promises without letting you touch a single example has not. And that is an answer in itself.

One closing thought that goes beyond the single meeting. Choosing a consultant is not just choosing a tool, but a dependency. You hand someone your workflows, your data and a piece of your future. That decision deserves the same standards as a new supplier in production: references, traceability, clear accountability. Nobody would put a supplier into the series without checking, just because sales were likeable. With AI consulting that happens surprisingly often.

The legal-notice test is only the first, cheap filter. It does not replace a thorough check, but it sorts out the obvious cases quickly. If someone cannot even keep their own mandatory text clean, you do not need to discuss the hard questions at all. And if the legal notice is fine, the good questions only begin. Either way it is time well spent, long before the first euro changes hands.

I look at this as someone who audits rather than sells. What an auditor learns: the polished act says little. The small details say everything. Here are the patterns that separate well-packaged hot air from real substance.

Invented numbers with decimal places

The first warning sign is numbers that are too precise. If someone writes that a certain behaviour triggers exactly 15.6 percent more of something, pay attention. Decimal places are meant to sound serious. They are almost never backed by evidence. Real numbers come with a source and context, or they do not come at all.

As an auditor I follow a simple rule: a verifiable number or no number. A claim without checkable evidence is not a fact, it is an opinion in costume. Ask politely for the source. Substance gives you an answer. Show gives you an evasion.

Help or bait?

The second pattern is the bait. Drop a codeword in the comments and I will send you the PDF. It boosts reach in the short term, but it is a mechanic, not a gift. You type a word, the post gets interaction, and you land in a sales funnel.

Real help is openly accessible. Anyone who genuinely wants to give you something links the article, shows the example, names the source. Anyone who first routes you through a comment and a direct message is optimising their funnel, not your knowledge. It is not forbidden, but you should see it for what it is.

Substance is shared openly. Show is kept scarce and behind a price.

Selling a tool instead of understanding the process

The third and most important sign shows up in conversation. A credible advisor asks about your process first. A pretender talks about their tool immediately. Anyone who wants to build you an AI agent in the first meeting, without understanding your workflow, is not selling you a tool, but a risk.

Take three typical mid-market cases. An AI that pre-sorts applications. A camera with a model that inspects parts in final control. An AI that creates orders in the ERP. In all three the technology is the easy part. The hard part is the process behind it: who decides, who checks, what happens when it fails. Put AI on a broken process and it just automates the mess, faster and more expensively.

The self-appointed AI elite

The fourth pattern is the self-appointed elite. Lots of stage, lots of webinars, big words about the future. The uncomfortable question is: what has this person actually built, implemented or been accountable for? Anyone who never stood on the shop floor and never paid for their own mistake talks about AI the way people talk about the weather.

I have run audits in five industries, from aviation to precision manufacturing, in five countries, with over 1,200 documented audit hours. That does not make me the smartest person in the room. But I know what it is like when a process stops at half past three in the morning because a model fails to recognise something. You can hear that grounding in a person. You can also hear when it is missing.

Buzzword bingo as a substitute for substance

The fifth sign is the language. If a sentence collapses once you remove the fashionable words, there was nothing in it. Run the test: cut forward-looking, holistic, scalable and synergy from a consultant sentence. Is there a concrete statement left, or only hot air?

Substance sounds unspectacular. It names the part, the process, the number, the limit. It also says what does not work. That admission of limits is itself a sign of quality. Anyone who tells you AI solves everything has either understood nothing or wants to sell you something.

Your hype filter in five questions

You do not need to be an AI expert to separate the wheat from the chaff. These five questions are enough before you listen to someone, let alone sign a contract.

• Are the numbers backed by a source and context, or just made precise?
• Is the help openly accessible, or tied to a bait and a direct message?
• Does the person ask about my process first, or about their tool first?
• What has this person actually built, implemented or been accountable for?
• Is there a concrete statement left once I delete the buzzwords?

Anyone who answers these confidently and concretely has substance. Anyone who dodges, shows slides and talks about the big future without letting you touch a single example does not. It is no guarantee, but a reliable first filter.

And yes, the same principle shows up in the smallest detail. Anyone who does not even keep their own legal notice up to date is not checking their AI output either. Hype is loud. Substance is quiet and verifiable. When in doubt, trust the quiet.

Who the CRA affects

It covers products with digital elements, from pure software to the connected machine. Whoever manufactures, imports or distributes has duties. Unlike before, cybersecurity becomes a precondition for market access in the EU, no longer a voluntary extra, but part of the CE marking.

The core obligations

At its core the CRA demands three things: security by design and by default, that is, security from the start rather than bolted on. A working vulnerability management across the whole lifecycle, including security updates. And reporting duties: actively exploited vulnerabilities and serious incidents must be reported within short deadlines. On top come technical documentation and the conformity evidence.

The deadlines

The CRA applies in stages. A first stage, among others on conformity assessment bodies, applies from June 2026. The reporting duties and the full manufacturer obligations phase in towards 2027. Those who build products with long development and service lives should start now, not just before the deadline.

Why ISO 27001 is the natural foundation

At its core the CRA requires a structured approach to information security and vulnerabilities. An information security management system to ISO/IEC 27001 provides exactly that frame: risk management, access control, a secure development process and vulnerability and incident management. It does not satisfy the CRA automatically, because the CRA adds product-specific requirements. But it is the foundation the product duties build on cleanly. How to connect the two, we clarify in a free initial call.

Why prompt injection stays

A language model has no built-in boundary between "this is a command from me" and "this is just data I am reading". Inject instructions into a document, an email, a web page or a code comment, and you can make the model execute them as a command. Filters and tight permissions lower the risk, they do not remove it. With an agent that acts on its own, a wrong answer becomes a wrong action: an email, an order, a system access.

The second, often-missed risk: the AI supply chain

AI agents are rarely a single piece. They use frameworks and open-source components, which in turn use other components. Poison one of them and every project inherits the weakness, often thousands of times and unnoticed. That is exactly what surfaced recently: a manipulated package deep in the supply chain of widely used agent libraries. If you buy AI components, you buy their weaknesses too.

What actually protects

Not the promise to patch the problem away, but consistent containment in several places at once:

Where this docks into standards

If you run ISO/IEC 27001 and ISO/IEC 42001 properly, the framework is already in place: access control, integrity and supply-chain security from 27001, AI risk and monitoring from 42001, human oversight from the AI Act. For agents, what is added are mainly action guardrails and a harder supply chain. How to set this up in your organisation, we clarify in a free initial call.

From certificate to buying criterion

Once the first large providers are certified, the standard becomes the benchmark everyone else is measured against. You know this from quality: when ISO 9001 became the norm, the question was no longer whether but when. With AI the same mechanism is starting, only faster, because the pressure comes from the EU AI Act, customers and liability at the same time.

Why you are on the hook for your vendors' AI

If you deploy bought-in AI, in a product, in a hiring process, in quality inspection, you carry responsibility and evidence duties as the deployer, regardless of where the model comes from. A bought-in part that is not under control is your problem, not the supplier's. That is exactly why relying on the vendor's marketing slide is not enough.

Auditing AI vendors against ISO 42001

A second-party audit against ISO 42001 turns trust into evidence. What is checked is not the model itself, but whether the supplier has it under control:

Act now, before the customer asks

The topic has two sides, and both are yours: build your own AIMS, because you will be asked for it, and audit your AI vendors, because you are on the hook. Tackle both early and you negotiate from strength instead of scrambling to produce evidence under time pressure. How a supplier audit against ISO 42001 looks for you, we clarify in a free initial call.

What has actually changed

The official reason for the deferral is that the necessary tools were missing: harmonised standards were not ready and national authorities not fully designated. On top came significant industry pressure. What moves and what stays, at a glance:

Worth being precise: the downgrade of the AI literacy obligation is part of the Omnibus proposal, on the Commission's official AI Act page the obligation still applies as of February 2025. So "abolished" would be wrong, "to be downgraded" is correct.

Why the delay happened

It was driven by an open letter from around 46 European corporations calling for a two-year stop, including names such as ASML, SAP and Siemens, with political backing from Germany for an exemption of industrial AI. The Siemens CEO made public that most of a billion-euro investment in industrial AI would go to the United States if the AI Act is not adapted. That unrealistic deadlines and missing standards are being stretched is understandable, not a scandal but a dose of realism.

The wrong lesson: delayed means done

Turning this into "let's just wait" is a mistake for three reasons. First, prohibitions and GPAI duties already apply, and a new ban on non-consensual deepfakes was even added. Second, the real pressure does not hang on Brussels alone: customers, supply chains, liability and insurers ask for evidence regardless of any deadline. Third, December 2027 arrives faster than mid-sized companies think, and building a robust management system takes months, not days.

The right lesson: build on a system, not on a date

Precisely because the rules drift with the political wind, it is a mistake to build your AI system to a Brussels date. What is robust is a management system to ISO/IEC 42001: it makes you audit-ready independent of the exact deadline and adapts whether the rules tighten or loosen. Governance then is a capability, not a box ticked on a date. And speed needs guardrails, not bureaucracy: ISO 42001 enables speed with provability, instead of banning speed or racing blind.

In short: the AI Act gains more time, not less relevance. Those who build their AI management system now are ahead whether the rules loosen or tighten. How that looks in your organisation, we clarify in a free initial call.

ISO/IEC 42001:2023, and no 2026 version

At ISO the standard sits at stage 60.60, which simply means: published International Standard, currently in force. What you may meet as "EN ISO/IEC 42001" is only the European adoption of the same text into the EN catalogue. The year in that designation is the year of European ratification, not a new, technically changed edition. Anyone promising a fresh version of the standard is mistaken.

What presumption of conformity (Article 40) means

The AI Act works with a presumption of conformity: whoever meets a harmonised standard whose reference is published in the EU Official Journal is presumed to conform with the corresponding requirements of the law. That is a real easing of the burden of proof. But it hangs on exactly that word: harmonised.

Why ISO 42001 alone does not carry it

ISO/IEC 42001 is an international standard outside the EU harmonisation process and does not cover every requirement of the AI Act. The dedicated harmonised standard is developed separately by CEN-CENELEC JTC 21. For AI management systems, EN 18286 is expected to fulfil the full set of regulatory requirements. The first harmonised standards are expected in 2026, after which the Commission assesses publishing the references in the Official Journal.

What this means in practice

ISO 42001 is still the right step now, not later. The building blocks are the same ones the AI Act demands: know and treat AI risks, set roles and controls, monitor operation. Build that today and you have the substance in place. The later alignment to the harmonised standard is then a delta, not a restart. Those who wait for the finished standard end up building twice and under time pressure. How to start cleanly, we clarify in a free initial call.

Side by side

When to choose which

• Choose ISO/IEC 42001 if you build, deploy or sell AI and need to govern it, and especially if the EU AI Act touches your market.
• Choose SOC 2 if your buyers (often US-based) want assurance about the security and handling of the data you process as a service provider.
• Do both if you are a SaaS or AI vendor selling into both the US and the EU, SOC 2 reassures on data handling, ISO 42001 proves responsible AI governance.

The good news: the work overlaps

Both rest on the same backbone, risk management, access control, monitoring, documented processes. If you run an ISO/IEC 27001 ISMS, you already cover much of SOC 2's security criteria and a large part of ISO 42001's structure. One control set, several frameworks: that is where an integrated management system pays off, and where I help you avoid doing the same work three times.

Not sure which your customers actually require? A short call usually settles it, and saves you from certifying the wrong thing first.

Two sources, three categories

The documents come from clauses 4 to 10 of the standard (the management-system requirements) and from Annex A (38 controls in 9 objectives). Bundled, that is around 20 real documents, and each is either a policy, a procedure or a record:

• Policies, how you govern AI (maintained, i.e. kept current).
• Procedures, how you operate the system step by step (maintained).
• Records, evidence that the system actually ran (retained).

Category 1, Policies

Category 2, Procedures

Category 3, Records

The simple logic: maintain or retain?

If you are unsure which category a document belongs to, ask one question: does it state HOW we do something, or does it prove THAT we did it? The first is a policy or procedure and is maintained (kept current, versioned). The second is a record and is retained (logs, minutes, audit reports, assessment and impact-assessment results).

Good documentation is not the thickest, but the one actually used in operations, and findable in minutes during the audit.

How we approach it

You do not have to invent these ~20 documents from scratch. I bring proven templates mapped to the standard's clauses and adapt them to your real operation, lean, audit-ready and without duplication where an ISO 27001 or 9001 already exists. The result is a document set that passes the audit and holds up in day-to-day work.

One clarification up front: this is the time to readiness for the external certification audit. The audit itself (Stage 1 and Stage 2) is scheduled separately by the accredited certification body, with its own lead time.

The timeline in six phases

This sequence follows a real implementation project, tailored to ISO 42001, the AI-specific steps (AI inventory, risk and impact assessment) are added:

What really drives the duration

• Existing foundation: a live ISO 27001 (or ISO 9001) already provides structure, roles and management review, a clear shortcut, because ISO 42001 shares the same base structure (Annex SL).
• A clear scope: a few clearly bounded AI systems go faster than "everything that is somehow AI".
• Internal effort: whether your people have weekly time decides the pace more than any method. The most common cause of delay is not complexity but missing internal capacity.
• AI maturity: if you already document and monitor your AI, you are faster than starting from zero.

The external audit: what drives the number of audit days

How many audit days the certification body allocates depends, per ISO/IEC 42006:2025 (Table A.1), explicitly not on your total headcount but on the number of people involved in the AI life cycle and your role (AI provider, AI deployer, or both). A company with 500 employees but only 15 people working with the AI is audited like a small organisation, the single most misunderstood lever.

For orientation, rounded guide values for the initial audit per ISO/IEC 42006:2025: up to around 10 people involved with the AI, roughly 3.5 to 5 audit days; up to ~25 people, roughly 4.5 to 7 days; up to ~85 people, roughly 7.5 to 11 days. An AI provider sits higher than a pure AI deployer. Adjustments apply for the number of AI systems, the regulatory frameworks involved and high-risk applications. Annual surveillance audits are considerably shorter.

What makes it faster

Three levers shorten the timeline without cutting quality: a tightly drawn scope for the initial certification (you can extend it later), building on an existing management system rather than reinventing it, and AI-assisted templates for policy, risk register and evidence. The last mainly shortens the documentation phase, but not the external audit, whose scope follows fixed accreditation rules.

I estimate the realistic timeframe for your case after a short assessment, more reliable than any flat figure, because it depends on your foundation and scope.

The only thing that matters: accreditation

A personnel certificate is not valuable because it says "PECB" or "TÜV" on it, but because the issuing body is accredited to ISO/IEC 17024, the international standard for "bodies operating certification of persons". Accredited means an independent national accreditation body has assessed and continuously monitors the certifier. Only that accreditation makes a certificate comparable and recognised across borders.

• Attendance confirmation: proves only that you were present. No exam, no certification.
• A provider's in-house certificate: the provider attests your learning itself. It sounds like certification but is not an accredited personnel certification, recognition effectively stops at that provider.
• Accredited personnel certification (ISO/IEC 17024): independent exam, issued by an accredited certification body, mutually recognised internationally.

Where PECB stands

PECB is accredited to ISO/IEC 17024 by the International Accreditation Service (IAS), UKAS (United Kingdom) and COFRAC (France). All three are signatories to the IAF Multilateral Recognition Arrangement, the mutual-recognition agreement of the International Accreditation Forum. That is what makes your PECB certificate recognised in roughly a hundred countries, the US and UK included. It is exactly why I deliver official PECB courses rather than my own in-house certificate.

One point on roles, because clean separation is what carries the recognition: I act as the authorised PECB trainer for the course. The exam and the certification itself are issued solely by PECB as the accredited body, not by me.

What to check before you enrol

• Does it say "accredited to ISO/IEC 17024", and by which accreditation body?
• Is it a personnel certification or merely an attendance confirmation?
• Are exam and certificate included, or billed separately (often four figures)?
• Is training cleanly separated from certification?

Check those four points and you make a decision your employer or a client can follow, which is the whole point of an auditor certificate.

The honest answer: a certificate is one building block. Nothing more. Anyone who treats "AI auditor" as a pure diploma exercise hasn't understood the profession.

What an AI auditor really does

An AI auditor checks whether an organization has its artificial intelligence under control. Not the models. Not the algorithms. The management system. Accountability, risk assessment, awareness, controls, evidence. Whoever spends a day on site walks out with a clear picture, or with a big question mark.

That only works if you understand both: the standard and the business. Reading ISO/IEC 42001 is not enough. You have to recognize a workbench, an HR tool or a sales engine when someone is sitting across from you. You have to speak the language of the shop floor, the business units, the management. Otherwise you audit paperwork, not reality.

The formal side: training and certificates

There are three credible routes to a recognized ISO/IEC 42001 auditor certificate:

• PECB (Professional Evaluation and Certification Board): the most widely adopted certification internationally. Lead Auditor: a five-day course plus a written exam. Senior Lead Auditor is NOT an additional exam; it is a status that PECB grants once you have demonstrated at least seven years of field auditing experience and more than 1,000 documented audit hours.
• TÜV / DEKRA / DQS: the German certification bodies offer their own programs. Comparable technical depth, more regionally recognized in the DACH region. Prices and terms vary by provider and format; getting comparison quotes makes sense.
• Exemplar Global: an international personnel certification body, mainly relevant in English-speaking countries.

A word of caution: there are now cheap online courses calling themselves "AI auditor training" that are not recognized personnel certifications. Anyone going to market with that kind of slip will be exposed on the first engagement. Look at the personnel certification body (PECB, TÜV, Exemplar Global), not just the course provider.

The real prerequisite: audit practice

Here lies the most important point the course catalogs leave out: the certificate is the entry ticket. You only turn it into a profession once you accumulate real audit hours.

A pilot with a theory license but no flight hours doesn't fly. An auditor with a certificate but no audit hours doesn't audit.

How do you collect them? In three ways. First: internal audits in your own company, if you are lucky enough that your firm is building a management system right now and you get trained as an internal auditor. Second: as a subcontractor for certification bodies that need auditors with specialist knowledge. Third: supplier audits within your own quality management practice.

My own path: more than ten years of internal and supplier audits across five industries, aviation, staffing services, sanitary wholesale, metal construction and precision engineering. Over 1,200 documented audit hours in five European countries. Only on that foundation did the ISO/IEC 42001 and 27001 Lead Auditor certifications come on top. That is the sequence that holds.

The three realistic ways in

If you are starting from zero today, you have three realistic paths:

• Path 1 - From compliance practice: you already work with ISO/IEC 27001, GDPR or quality management. ISO/IEC 42001 is the natural extension. Timeframe: 6 to 12 months to your first auditor role.
• Path 2 - From AI/tech practice: you have experience with ML models, data quality, MLOps. You need to add the standard and the audit craft. Timeframe: 12 to 18 months; audit practice is the bigger gap than the technology.
• Path 3 - Lateral entry from industry: you have carried responsibility, you know how a business runs. You need both the standard fundamentals AND the audit methodology. Timeframe: 18 to 24 months, but with the field credibility no one can shortcut.

Which path fits depends on where you come from. There is no "best" one. But there is a wrong one: jumping overboard without water experience. Whoever books a 4,000-euro course with zero audit background and hopes the phone will ring off the hook afterward will be disappointed.

What a certificate does NOT do

Three truths that appear in no course brochure:

• A certificate does not make you an auditor for a certification body. These bodies additionally vet their auditors for experience and technical suitability, and they assign engagements only to listed individuals.
• A certificate does not replace the industry you work in. Whoever audits in manufacturing must understand manufacturing. Whoever audits in healthcare must know the MDR and patient data. Standard plus industry, not either-or.
• A certificate has a half-life. ISO/IEC 42001 will keep evolving over the coming years, and the EU AI Act adapts with it. Anyone who stops learning after the course is out of the game in five years.

How to prepare, in 1 to 6 weeks, depending on your learning style

Important context: the core is the official 5-day course with the exam at the end, it provides the material, the exercises and the exam itself. How much you study around it depends on your prior knowledge and learning style: some are ready within a few days around the course, others spread it comfortably over a few weeks. You can compress the six building blocks below into a single week or stretch them over up to six, the sequence matters, not the duration:

What does an AI auditor earn?

An honest market read, not a promise: ISO/IEC 27001 Lead Auditors in Germany earn roughly EUR 62,000 to 82,000 per year, around EUR 70,000 on average (public salary databases such as StepStone and Glassdoor, 2026). The AI governance / ISO 42001 specialisation is still young and in demand, a premium over the pure 27001 level is realistic, depending on industry, experience and whether you are employed or freelance. Self-employed auditors work on day rates, which for specialised audit and advisory work are often four figures. What ultimately drives income is documented audit practice, not the certificate alone.

What I advise new auditors

If you genuinely want to become an AI auditor and not just have the title in your LinkedIn profile, do these three things first:

• Find a company, whether as an employee or a consultant, that is currently building a management system. Collect audit hours there before you put money into expensive certification.
• Read original sources, not summaries. ISO/IEC 42001 itself. The EU AI Act itself. The NIST AI RMF. Those are what you'll be measured against in an audit, not course handouts.
• Find an experienced auditor to mentor you. A mentor replaces three books and two training courses.

Then, and only then, the certification. Then the first small engagements. Then the bigger ones. That is the honest path. It is slower than the LinkedIn career hacks. But it holds.

So that you can still gauge the order of magnitude, here are typical market ranges, offered as orientation and explicitly not as my quote, along with the one cost item almost everyone underestimates.

The Three Cost Blocks

An ISO 42001 implementation has three parts: external consulting and support, the internal effort of your own people, and the actual certification audit by an accredited body. If you only budget for the first and third, you are planning too tight.

• External consulting and support: typically around 8,000 to 30,000 EUR on the market, depending on maturity and the scope of your AI use.
• Certification audit: for an initial certification, accredited bodies generally schedule at least four audit days.
• Certificate and ongoing surveillance: the certificate is valid for three years, with annual surveillance audits and a recertification at the end of the cycle.

What Does It Cost in Total?

For small and mid-sized companies, the total investment, consulting plus internal and external audit plus certificate combined, typically runs between roughly 15,000 and 50,000 EUR on the market. For larger mid-sized firms with 100 to 500 employees and broad AI use, the range can be considerably higher. Daily rates for experienced auditors and consultants move roughly between 800 and 1,500 EUR, often with a premium for AI topics, because the field is young and highly specialized.

The range is deliberately wide, and that is not an evasive answer but the core of the matter: where you land depends heavily on how much foundation is already in place (for example an existing ISO 27001), how clearly the scope is drawn, and how lean the work is kept. That is why a short upfront assessment is worth more than any flat-rate figure.

Over Three Years: the Certification Cycle

An ISO certificate is valid for three years but is confirmed annually by a surveillance audit. The main investment falls in year one; after that it gets considerably cheaper. Budgeting across the full cycle from the start avoids surprises later.

Concrete, from practice: for a small manufacturing company in 2025, offers from accredited certification bodies for the audit alone (ISO 9001, a comparable audit structure) ran at roughly EUR 3,200–4,300 for the year-one certification audit and EUR 1,400–2,000 per surveillance audit, so roughly EUR 7,500–10,500 net over three years, travel costs separate. ISO 42001 sits in the same order of magnitude, tending toward the upper end, because the field is younger and the audit effort somewhat higher. Those are the certification body's fees; consulting and your internal effort come on top.

The Biggest Hidden Cost Factor: Your Own Time

The item that appears on no quote line yet costs the most is the working time of your own people: conducting interviews, reviewing documents, implementing controls, collecting evidence. Underestimate this and you come under pressure, not on the fee, but in day-to-day operations. Good support keeps exactly this internal effort small by staying focused and not reinventing every folder.

Modern, AI-supported methods help further by shortening routine work: document templates, evidence structures, first drafts. That noticeably reduces preparation effort and makes the implementation leaner than it was just a few years ago. One thing AI does not shorten, however, is the external certification audit itself. Its scope follows fixed accreditation rules and is driven by your organization, not by how efficiently you prepared.

The most expensive ISO implementation is the one no one in the organization supports, because it was built past reality.

How to Reduce the Cost

• Use ISO 27001 as a foundation: if you already run an information security management system, you save noticeably on ISO 42001, because the base structure is already in place.
• Tackle both standards together: 42001 and 27001 overlap strongly. Reusing base structure, risk logic, and evidence often reduces the additional effort considerably; the reliable figure comes out of the gap analysis.
• Draw the scope cleanly: not every system has to be in the first scope. A clearly defined scope keeps the initial project lean.
• Risk-based instead of complete: controls are selected by risk rather than all implemented across the board, which saves effort and is conformant.

Funding 2026: What Is Available?

Consulting services for digitalization and AI are frequently eligible for funding for mid-sized companies. One caveat upfront: funding programs change. The following reflects the status as of May 2026 and does not replace individual funding advice.

• BAFA "Promotion of Business Consulting": nationwide for SMEs in Germany, currently still available until the end of 2026. It covers up to 50 percent of consulting costs in the western German states (capped at around 1,750 EUR) and up to 80 percent in the eastern states (capped at around 2,800 EUR).
• State-level programs: depending on the federal state, some are funded considerably more generously, such as the Digitalbonus Bayern (up to 30,000 EUR) or the MID vouchers in North Rhine-Westphalia (up to 15,000 EUR).
• Combination: a concept subsidy can often be combined with a state implementation program and a qualification subsidy.

The nationwide BAFA funding tends to cover the concept phase; the larger amounts usually sit in the state-level programs. Which combination fits your location we clarify in the free initial consultation, and we do so before the project starts, because retroactive funding is rarely granted.

Conclusion

ISO 42001 is an investment, not a bargain, but it is not a corporate megaproject either. With a clearly defined scope, an existing ISO 27001 foundation, and the right funding, the entry point can be made predictable for mid-sized companies. What matters is doing the math honestly from the start: fee, internal effort, and audit together.

What makes agentic AI different

An agent is autonomous enough to break a task into steps and carry them out with tools (APIs, databases, email, actuators). That is powerful, but every step is a potential action with real-world impact. A manipulated input document, an ambiguous instruction or an over-broad access right can then trigger not just a wrong answer, but a wrong action.

Six building blocks to secure AI agents

If you run agents in production, secure six areas deliberately, and dock them onto existing standards and the EU AI Act instead of inventing something entirely new:

The core: human oversight and action guardrails

The biggest lever is separating "may the agent decide this" from "may the agent execute this". Low-risk actions an agent can handle autonomously; anything with external effect or potential for harm, payments, contract emails, deletions, production commands, needs a defined guardrail: a human approval, a limit or a sandbox. The EU AI Act already requires effective human oversight for high-risk AI (Art. 14); for agents this is not a box-ticking exercise but simply good practice.

Where this docks into ISO 42001

ISO/IEC 42001 requires you to know your AI systems, assess their impact (AI System Impact Assessment), treat risks and monitor operation. From that angle, an AI agent is an AI system with greater leverage, the same mechanisms apply, just with more attention to the action side. If you have set up ISO 42001 properly, the framework for agentic AI is largely in place; what is added are mainly action guardrails and tighter access rights.

In short: agentic AI raises both value and risk. With clear identity, least privilege, validated inputs and outputs, action guardrails, monitoring and human oversight, the agent stays a tool, not an uncontrolled actor. How to set this up in your organisation, we clarify in a free initial call.

What applies from 2 August 2026

On that date, the transparency obligations under Article 50 of the AI Act take effect. They apply regardless of whether your AI is high-risk; the point is the open disclosure of AI interaction and AI content.

• Interactive AI such as chatbots: users must be able to recognise that they are talking to an AI, not a human.
• Deepfakes: AI-generated or AI-manipulated images, audio and video must be labelled as such.
• AI texts on matters of public interest: must be labelled when published without human or editorial oversight.
• Providers of generative AI: must mark their AI outputs in a machine-readable way, so they are technically detectable as artificially generated.

The new Code of Practice mainly operationalises two of these: machine-readable marking by providers (Article 50(2)) and the visible labelling of deepfakes and published texts by deployers (Article 50(4)). The plain chatbot disclosure is the related duty under Article 50(1) and also applies from 2 August 2026.

Provider or deployer: where do you stand?

The AI Act distinguishes two roles, and the Code is split into two sections accordingly. The decisive point for most companies: anyone who merely uses AI is a deployer, not a provider.

• Providers: develop or distribute generative AI systems and must ensure the machine-readable marking of outputs.
• Deployers: use AI, and must visibly label deepfakes and AI texts on public topics, and disclose the AI in chatbots.

What this means for mid-sized businesses

Most mid-sized companies are deployers. Even so, real obligations arise as soon as generative AI becomes visible to the outside world:

• A chatbot on your website or in customer service: a clear notice such as "You are chatting with an AI" meets the requirement.
• AI-generated images or videos in marketing and social media: check whether a deepfake label is needed.
• AI-created texts published without human review that concern public-interest topics: label them.
• Keep an internal record of where AI is used at all. That is the basis for any labelling.

How to label: the EU icon

For visible labelling, the Code of Practice provides an official EU icon that may be used freely and without attribution. There are two variants: "AI GENERATED" for fully AI-created content and "AI MODIFIED" for partly AI-altered content. This answers the question "How do I label?" in concrete terms.

• Images and videos: place the icon clearly visible, for example top right; in videos at the start and after ad breaks.
• Published texts: place the notice near the headline or at the start of the text.
• Audio-only with no screen: prepend a short, clearly understandable audible notice.
• The label must be clearly recognisable and accessible at the latest on first contact.

When you do not have to label

The Code sets out clear exceptions. Not every piece of AI content needs to be labelled:

• Published texts that have undergone human or editorial review and for which a person holds editorial responsibility.
• Artistic, creative, satirical or fictional works: here labelling is done so it does not impair the work, for example in accompanying text or credits.
• Content whose use is legally permitted for detecting, preventing or prosecuting criminal offences.

Voluntary, but with an upside

The Code is not mandatory. However, those who sign it can, once approved by the Commission and the AI Board, more easily demonstrate compliance with the relevant AI Act duties. In addition, the Commission has announced practical guidelines that will further clarify the scope. The Code was drawn up by six independent experts with the involvement of more than 180 stakeholder groups.

People in Europe have a right to know whether what they see, hear or read was created or altered by AI. Transparency is how we protect trust. (paraphrased: Henna Virkkunen, Executive Vice-President of the European Commission)

The bridge to ISO 42001

Labelling is not a standalone topic but part of a whole: those who know which AI systems run in their organisation, who is accountable for them and how their outputs are handled meet transparency duties almost in passing. That is exactly what an AI management system (AIMS) under ISO/IEC 42001 delivers. It makes the AI Act's duties structured and demonstrable. I build such systems so they work in day-to-day operation, and I check beforehand whether your labelling holds up.

If you are unsure whether you count as a provider or a deployer, and which labelling your AI requires, a short initial conversation is enough to classify your systems. Source: European Commission, press release IP/26/1328 of 10 June 2026.

The AI Act thinks in four risk classes

The AI Regulation (Regulation (EU) 2024/1689) follows a risk-based approach. It does not regulate "AI" across the board, but instead asks: what could this application do in the worst case? Four levels follow from that.

• Prohibited practices (Art. 5): a small number of clearly named applications such as social scoring, manipulative behaviour, or certain biometric practices. These are banned.
• High-risk AI: narrowly defined fields of use carrying significant obligations. This is where the real focus of the regulation lies.
• Limited risk (Art. 50): transparency obligations. Anyone running a chatbot or generating AI-produced content and deepfakes must, as a rule, label it.
• Minimal risk: everything else. No specific obligations under the AI Act.

The decisive point for mid-sized companies: the vast majority of everyday AI applications land in the lower two levels. High-risk is something you essentially have to "earn", and only via one of two clearly described routes.

High-risk only arises via two routes

An AI is not high-risk because it is "important" or "powerful". It is high-risk only if it hits one of the two routes laid down in law. Anyone who knows both can roughly classify their own application in a few minutes.

Route A: Annex III - the eight areas of use

Annex III lists eight areas in which AI is deemed high-risk because it directly affects people's fundamental rights, safety, or life chances. Check honestly whether your application falls into one of them:

• Biometrics (e.g. biometric identification)
• Critical infrastructure (e.g. control of electricity, water, or transport networks)
• Education and vocational training (e.g. grading of exam performance, access to education)
• Employment and workforce management (e.g. AI for candidate selection or employee evaluation)
• Access to essential private and public services (e.g. creditworthiness assessment, risk assessment in life or health insurance)
• Law enforcement
• Migration, asylum, and border control
• Administration of justice and democratic processes

Don't see yourself here? Then Route A is, as a rule, already settled for you. This is exactly where the all-clear comes for many industrial and service businesses: a machine that detects defective parts via camera, or a model that forecasts material demand, belongs to none of these eight areas.

Route B: Annex I - AI as a safety component in products

The second route concerns AI that sits as a safety component in an already regulated product subject to a conformity assessment. Think of machinery, medical devices, lifts, or toys. When the AI takes on safety-relevant functions there, it is captured through the respective product regulation.

For many manufacturers this is familiar territory: they already go through a conformity assessment anyway. The AI Act hooks into this existing logic rather than creating an entirely new world. For pure deployers who merely use such products, Route B is usually not relevant.

High-risk is not a gut feeling. Either your AI hits one of the eight Annex III areas, or it sits as a safety component in a regulated product under Annex I. Neither applies? Then, as a rule, it is not high-risk.

The most important exception: Annex III does not automatically mean high-risk

Now comes the rule that brings the most relief in practice and that many overlook. Even when an AI nominally falls into an Annex III area, it can be classified as not high-risk. The regulation provides for this exception in Art. 6(3).

It applies when the AI performs only a preparatory or narrowly limited supporting task and does not pose a significant risk to health, safety, or fundamental rights. A system that, for instance, merely pre-sorts incoming documents or provides a purely supportive secondary function without making the actual decision can fall out of the high-risk class despite its Annex III link.

Important: you must be able to justify and document this classification cleanly. It is not a free pass but a deliberate, traceable assessment. This is precisely the transition from the question "Are we high-risk?" to the question "Can we prove our answer?"

Typical mid-market AI - and where it really lands

Let's look at the applications I encounter most often. The classification almost always turns out reassuring.

• Predictive maintenance: as a rule, minimal risk.
• Camera-based quality control and image processing in manufacturing: as a rule, minimal risk.
• Demand and requirements forecasting: as a rule, minimal risk.
• Internal chatbot or customer-service chatbot: usually limited risk, i.e. a transparency or labelling obligation, not high-risk.
• Text generation and AI assistants: usually limited risk with labelling of AI-generated content.

It only becomes high-risk once the same technology moves into one of the sensitive areas. The same text analysis is harmless when it sorts service tickets, and potentially high-risk when it decides on job applications. It is not the technology that matters, but the purpose and context.

What applies when? The deadlines at a glance

The AI Act does not enter into force all at once but in stages. That gives you time to sort things out rather than fall into a panic.

• 02.02.2025: the prohibitions (Art. 5) and the obligation on AI literacy (Art. 4) apply.
• 02.08.2025: obligations for general-purpose AI models (GPAI) plus the governance and authority structure.
• 02.08.2026: transparency obligations under Art. 50 (e.g. labelling of AI-generated content).
• High-risk obligations: originally Annex III from 02.08.2026 and Annex I from 02.08.2027, postponed by the Digital Omnibus (agreement of 7 May 2026) to 02.12.2027 and 02.08.2028 respectively.

Note: the obligation on AI literacy under Art. 4 applies to everyone who deploys AI, regardless of risk class. Your staff should understand what they are working with. That is not a high-risk question but common sense with a legal basis.

The self-check in four questions

If you need a quick initial assessment for a specific application, work through these four questions in order. They do not replace a full legal evaluation of the individual case, but they sort most cases cleanly in advance.

• 1. Is it a prohibited practice under Art. 5 (e.g. social scoring)? If yes, the application is banned. For typical mid-market AI, almost never the case.
• 2. Does the application fall into one of the eight Annex III areas, or is it a safety component under Annex I? If no, it is, as a rule, not high-risk.
• 3. If Annex III: does the exception under Art. 6(3) apply because the AI performs only a preparatory or narrowly limited task? Then it can still fall out of high-risk, properly documented.
• 4. Otherwise check: do you need transparency under Art. 50 (chatbot, labelling of AI content)? If yes, limited risk. If no, minimal risk.

The right question is not "Are we using AI?" but "For what exactly, and with what effect on people?" From that, the risk class follows almost by itself.

Why an AI Management System makes the difference here

Regardless of which class your AI falls into, you need a solid answer when a customer, an insurer, or an authority asks. That is exactly what ISO/IEC 42001 is built for. The standard gives you a structure to systematically capture, assess, and govern your AI applications.

The self-check above is the snapshot. An AI management system to ISO/IEC 42001 turns it into a durable, traceable process: you document why an application falls into which class, keep it up to date, and can present it on request. In practice this is often worth more than the class itself, because it shows that AI is being deployed here deliberately and under control.

A note on classification: this overview does not replace a legal review of the individual case. It helps you ask the right questions and approach the topic with a clear head rather than a knot in your stomach. In the vast majority of mid-market cases, the honest answer in the end is: not high-risk, but good that you took a closer look.

The difference in one sentence

A Lead Implementer builds the management system and keeps it running. A Lead Auditor checks whether it actually works. One constructs, the other verifies.

The Implementer is the architect and site manager. The Auditor is the structural engineer who, at the end, decides whether the building will stand.

What a Lead Implementer really does

A Lead Implementer establishes an AI management system (an AIMS to ISO/IEC 42001) or an information security management system (an ISMS to ISO/IEC 27001) from the ground up. They translate the requirements of the standard into something that genuinely works in operation, not into a binder gathering dust on a shelf.

• Clarify context and scope: what exactly should the management system cover?
• Assess risks and produce the Statement of Applicability
• Select, design and implement the controls
• Build up documented information, communication, competence and awareness
• Run ongoing operations, conduct internal audits and improve continuously
• Prepare the organisation for the external certification audit

PECB teaches this with its own step-by-step methodology (IMS2), from initiation through to certification readiness. It is the role for anyone who wants to build something, whether internally or as a consultant.

What a Lead Auditor really does

A Lead Auditor assesses whether an existing management system meets the standard, following the rules for auditing (ISO 19011) and for certification bodies (ISO/IEC 17021-1). They plan the audit, gather and verify evidence, formulate findings, write the report and lead an audit programme.

Auditing means checking, not consulting. Whoever has built a system is not allowed to certify it externally themselves, and it is precisely this separation that makes the whole system credible. The auditor looks at it from the outside and says what holds and what does not.

Which path fits whom?

• Lead Implementer if you want to BUILD: as a project lead, consultant, member of an AIMS/ISMS team, or as the person responsible for implementing the standard in-house.
• Lead Auditor if you want to CHECK: as an internal auditor, as an auditor for a certification body, or to assess suppliers and partners in a defensible way.

Both are genuine personnel certifications to ISO/IEC 17024, both run for five days (four training days plus an exam day) and both earn 31 CPD points. Neither path is "higher" than the other; they simply point in different directions.

Why both together are strongest

The most compelling option is not either-or, but both. Anyone who can build a management system AND audit it understands both sides of the table, and that shows in every project. This dual qualification is rare.

PECB even rewards it formally: hold both Lead Implementer and Lead Auditor within one scheme, pass four additional Foundation exams, and you qualify for the PECB Master credential.

My own starting point was the audit side: Senior Lead Auditor ISO/IEC 42001 and Lead Auditor ISO/IEC 27001, built on more than 1,200 documented audit hours across five European countries. Those who come from implementation travel the opposite route, and both meet in the middle.

How you get in, and what really matters

The formal entry is similar for both: ideally start with the Foundation course (the fundamentals of the standard), then take the five-day Lead course with its exam. For personnel certification, PECB additionally requires experience, graded from Provisional (no proof of experience required) through Implementer or Auditor up to Senior Lead (around ten years and roughly 1,000 documented hours).

The certificate is the entry ticket. You turn it into a profession only through real hours: project hours for the Implementer, audit hours for the Auditor.

In practical terms: start with the course that matches your direction and gather experience alongside it. For the Implementer, in real implementation projects; for the Auditor, in internal and supplier audits. Each builds on the other, and the two can be combined later on.

Let’s be honest: these three audit roles do not differ by a nuance. They differ in mandate, in responsibility, in independence, and in what is ultimately legally defensible. I’ll explain it here the way I’d explain it to a managing director at the kitchen table who has just been handed a quote for an “AI audit” and doesn’t know whether to buy.

Three mandates, three responsibilities

Before we talk about prices or providers, we need to sort the mandate cleanly. Each of the three roles has its own goal. Confuse them, and you buy the most expensive service for the least benefit.

1. Consulting (Implementer)

The consultant helps build. They help you stand up the management system to ISO/IEC 42001 or ISO/IEC 27001, write policies with you, define roles, train staff, run risk assessments, and close gaps. They are partial, on your side. That is not meant negatively, quite the opposite: a good consultant has one goal, that you become ready for certification. Full stop.

What consulting is not: an independent judgment. Whoever builds their own system cannot assess it objectively. That is not a question of morality but of human logic, nobody reliably finds their own blind spots. Exactly for that reason, consulting is separated from certification.

A consultant is like an architect. They build you a good house. But they are not the building inspector who signs off on it at the end.

2. Internal audit (first-party audit)

The internal audit examines your own management system, carried out by you, on behalf of top management. It is mandatory: ISO/IEC 42001 requires it just as ISO/IEC 27001 and ISO 9001 do. No internal audit, no certificate, because the standard explicitly demands a demonstrable self-assessment.

An internal audit can be performed by:

• Your own staff with auditor qualifications and sufficient independence from the area under review (never audit your own area).
• External auditors brought in as service providers when in-house know-how is missing, this is legitimate and very common among smaller and mid-sized companies.

What an internal audit is not: an accredited certificate. It is a mandatory step in the PDCA cycle of your management system, not external market evidence. But: whoever audits honestly here walks calmly into the certification body’s Stage 2 audit. Whoever cuts corners here builds the risk straight into the process.

3. Third-party audit (accredited certification audit)

The third-party audit is carried out by an accredited certification body, in Germany supervised by the national accreditation body (DAkkS). Only this body may issue an accredited certificate. This is the form that customers, authorities, and regulators accept as evidence.

This body is independent, bound by ISO/IEC 17021, and audits according to a clearly documented procedure in two stages (Stage 1: document review; Stage 2: on-site audit). The certification body’s auditor must not have advised you, nor built your system, nor be economically dependent on you.

I myself work as a Senior Lead Auditor ISO/IEC 42001 and Lead Auditor ISO/IEC 27001 (PECB), also on behalf of certification bodies, when they engage me as an external auditor. More than 1,200 documented audit hours across five European countries, the Netherlands, Scotland, Croatia, Serbia, Türkiye, and in five different sectors from aviation to precision engineering. But: consulting and an accredited certification audit are something I may not do for the same client. Never.

A quick aside: where does second-party fit in?

Sometimes the term second-party audit comes up. That is the supplier audit: you assess a supplier on your own behalf, not accredited, but as a customer toward the provider. Important: this is not a substitute for ISO certification. But it is a form I often work in, when a company engages me to audit one of its AI service providers or subcontractors.

When do I need what?

Here is the decision logic from my practice. It is not academic, it grew out of real engagements.

• You want to build ISO/IEC 42001 but don’t yet have a management system? → Consulting / gap analysis / implementation support. Build the system first, then audit it.
• You have built the system and want to know, before the certification audit, where it still falls short? → Internal audit by an external auditor (someone not involved in the build). A reality check before Stage 2.
• You want the accredited certificate? → Third-party audit via an accredited certification body. Full stop. No consultant may issue it.
• You want to assess an AI supplier you work with? → Second-party audit. Pairs well with a confidentiality agreement.
• You are already certified and need the annual surveillance? → Surveillance audit, again by the same certification body (re-certification every three years).

The mixing trap: why it burns when roles cross

In the market there are providers who offer everything from one hand: consulting plus audit plus “certificate.” That sounds convenient. But it is legally and substantively problematic. Reasons:

• Independence under ISO/IEC 17021: an accredited certification body may neither consult nor implement, otherwise it loses its accreditation.
• Credibility in the market: customers and supervisory authorities recognize very well whether a certificate comes from an accredited body or from a consultant who cobbled together their own logo.
• Liability in a dispute: if something goes wrong (a data protection breach, an AI bias incident, a regulatory proceeding), the authority examines who performed which audit for which purpose. Mixed roles weaken your defensive position.

My test when a client puts a provider’s “AI audit package” on the table: I ask who issues the certificate. If the answer is “we do”, hands off. If the answer is “through an accredited body such as TÜV, DEKRA, DQS or similar”, then I can take a closer look.

What I deliberately don’t do, and why that’s a mark of quality

A clear statement from my side: I am an auditor and a consultant. I can run internal audits, gap analyses, implementation support, supplier audits. I can also work as an external auditor for accredited certification bodies, as a subcontractor under their mandate.

What I do not do: issue my “own certificate.” That would be worthless, would destroy my brand, and would be misleading in marketing toward authorities and clients. “The AI Auditor” is a brand of FERNAU Präzisionstechnik GmbH, not a certification body. This separation is deliberate. It is my mark of quality.

Anyone who tells you they are consultant, auditor, and certifier in one has not understood the system. Or they are hoping that you don’t.

The two rules every managing director should know

If you remember only two things:

• Rule 1: Whoever builds you must not certify you. Consulting and accredited certification are separate, by standard, by accreditation rule, by common sense.
• Rule 2: Only accredited certification bodies issue accredited certificates. Anything else is a confirmation, but not market evidence in the sense of the standard.

With these two rules in your pocket, you can assess any audit offer in 30 seconds. And you save yourself expensive bad purchases, not only in euros, but in trust toward customers and regulators.

First the process. Then the role. Then the evidence. I look in that order.

What an ISO 42001 audit is not

An auditor does not check whether an AI model performs well. That is the job of validation. Nor whether the cloud architecture is sound, that belongs in the ISO 27001 scope. And not whether you are using the best available model either. Model choice is your decision, not mine.

An audit doesn't ask: does your AI work? It asks: who is accountable when it doesn't?

What is actually on the test bench

An ISO 42001 audit (standard published in 2023, audits now conducted under ISO/IEC 42006) examines five core areas, and not a single one of them is primarily technical:

• Leadership and accountability: Does someone visibly hold the mandate to be accountable for AI governance? Is it written into a role, a record, a board decision?
• Risk management: Do you know the risks your AI poses to affected people and to the organization? Have you assessed them systematically, not from gut feeling?
• Impact assessment: Can you show what consequences an AI system has for the outside world (ISO/IEC 42005)? Not just risks to you, but effects on others.
• Awareness and competence: Do staff know what they are and aren't allowed to do? Who completed the mandatory training? Is there evidence?
• Controls and evidence: Have you selected the relevant controls from Annex A, and can you demonstrate that they are effective?

A concrete scene from audit practice

I ask in a mid-sized company: "Which AI systems are you currently using?" The managing director names three. The head of IT adds: "Plus the component inspection in plant three. And the chat assistant for sales." The managing director looks surprised.

This is not a trap. It is the audit test: does a complete, maintained inventory of AI systems exist? When leadership learns about systems instead of already knowing them, the governance isn't there yet.

The next test is classification. I ask about the applicant-screening tool in HR. "It's only a filter," says the head of IT. Wrong. An AI that pre-sorts or scores job applications falls into the high-risk category under Annex III of the EU AI Act. That triggers obligations around human oversight, bias testing, transparency, and documentation. Anyone who doesn't know this has a gap in their risk register, and a hard question coming in the audit.

An AI tool that sorts résumés isn't a convenience. It is a discrimination claim waiting to become actionable.

The same applies to AI-assisted quality inspection in manufacturing: does the camera reliably detect a crack, or does it wrongly pass defective parts? That is not just a quality issue, it is product liability. Anyone operating here without documented validation, without defined thresholds, without an escalation path has built AI risks into their production without controlling them.

What an auditor sees in the first two hours

Experienced auditors don't need three days to gauge maturity. Four indicators reveal it by mid-morning:

• Can the responsible person answer "Which AI do we use?" in under two minutes?
• Is there a risk register with concrete entries, or just a list of theoretical risk categories?
• Is there a training overview with names, dates, and content, or just a PDF sitting on the server?
• Are the Annex A controls linked to concrete measures, or simply ticked off?

If all four are clean, the audit runs as a confirmation. If two are thin, it goes deeper. If three or four are thin, it is too early for an external audit, and an honest gap analysis helps more than an embarrassing, lost certification mandate.

Why technology is only a by-catch in the audit

Imagine someone certifying your fire protection without ever looking at your fire alarm system. Sounds absurd, but it is exactly what to expect with ISO 42001. The standard examines the management system, not the equipment. It checks whether you know what you are doing, why you are doing it, who answers for it, and whether your controls fit.

That is not a flaw in the standard. That is its purpose. Technology changes monthly. Accountability, roles, and risks do not. That is precisely why the standard builds on what endures.

When an organization is audit-ready

Audit-ready does not mean having every answer ready. Audit-ready means being able to demonstrate, traceably, where you stand, where you don't, and what is planned. Auditors don't expect perfection. They expect honesty, evidence, and consistency.

Those who have that walk into the audit relaxed. Those who don't should not go to the certification body first, but go to themselves first.

Does the AI Act actually apply to you?

Article 2(1) is deliberately broad. The Regulation reaches providers who place AI systems on the EU market regardless of their location, and it reaches providers and deployers outside the EU whose system’s output is used in the EU. Three quick examples: a US SaaS company selling AI-powered analytics to European customers is covered. A Swiss medical AI exporter is covered. An Indian back-office whose AI results are sent to an EU operator is covered.

Your role decides your obligations

• Provider, you develop the AI system (or have it developed) and put it on the EU market under your own name or trademark.
• Deployer, you use an AI system under your authority in a professional context; for non-EU deployers, if the output is used in the EU.
• Importer, established in the EU, you place on the market an AI system bearing the name of a person established outside the EU.
• Distributor, anyone else in the supply chain making the system available on the EU market.

Providers and deployers carry the heaviest set of duties; importers and distributors carry due-diligence and corrective-action duties (more on those in the dedicated supplier-audit article).

Authorised Representative (Article 22), the door key

Before placing a high-risk AI system on the EU market, a non-EU provider must appoint, by written mandate, an Authorised Representative established in the Union. The representative keeps the technical documentation, registers the system in the EU database where required, is the contact point for market-surveillance authorities and may terminate the mandate if the provider acts against AI Act obligations. The minimum content of the mandate is set out in Annex V.

For limited- or minimal-risk AI and for general-purpose AI models there are different mechanisms (a GPAI provider outside the EU must also appoint a representative under the GPAI chapter). The point: identify what kind of system you place on the market before you assume one mechanism fits all.

The conformity path for high-risk systems

• Classify against Annex III (use-case based) and Annex I (safety component of regulated products under EU harmonisation law).
• Build the management-system requirements: risk management (Art. 9), data governance (Art. 10), technical documentation (Art. 11), record-keeping and logs (Art. 12), transparency (Art. 13), human oversight (Art. 14), accuracy/robustness/cybersecurity (Art. 15).
• Run the conformity assessment (Art. 43), typically internal control for Annex III systems, with third-party assessment in safety-component cases.
• Affix the CE marking, draw up the EU declaration of conformity and register the system in the EU database (Art. 71).

What happens if you ignore it

Article 99 sets the maximum fines: prohibited practices up to EUR 35 million or 7% of worldwide annual turnover, whichever is higher; high-risk and other operator violations up to EUR 15 million or 3%; supplying incorrect, incomplete or misleading information up to EUR 7.5 million or 1.5%. SMEs and start-ups are subject to the lower of the two figures. These are caps, not standard fines, but the headline numbers are what board rooms react to.

The Digital Omnibus may move the high-risk dates

On 7 May 2026 the EU institutions reached a provisional political agreement that would postpone the high-risk applicability, Annex III systems to 2 December 2027 and Annex I to 2 August 2028, and ease some AI literacy requirements. It is not yet formally adopted. Plan against the original dates and treat the relief as a buffer.

A pragmatic order of operations

• Decide whether you place AI on the EU market or use it for the EU.
• Map your role: provider, deployer, importer, distributor.
• If you are a non-EU provider of high-risk AI: appoint your Authorised Representative early, the mandate takes time to negotiate.
• Build a management system (ISO/IEC 42001 is the most direct way to deliver the AI Act’s evidence load).
• Run the conformity assessment, CE-mark, register, document.

The AI Act does not stop at the EU border. It reaches every provider whose system touches the EU market, but the workload is structured. With the right management system in place, most of it is documentation you would build anyway.

Note on scope: this article covers AI compliance only. Tax, labour, corporate, immigration and contract questions about entering the German or EU market require a licensed German lawyer or tax advisor. I focus on ISO/IEC 42001, ISO/IEC 27001 and AI Act readiness, and work with a network for the rest.

The four frameworks at a glance

• EU AI Act (Regulation (EU) 2024/1689): a binding law with risk-based obligations, conformity assessment and fines up to 7% of worldwide turnover. Extra-territorial.
• NIST AI RMF 1.0 (January 2023): a voluntary US framework with four functions, Govern, Map, Measure, Manage. Strong practice guidance; not a certification.
• ISO/IEC 42001:2023: the global voluntary standard for an AI management system. Certifiable by accredited bodies.
• UK approach: the white paper “A pro-innovation approach to AI regulation” (March 2023; the government published its response to the consultation in February 2024) sets out five non-statutory principles delivered through existing sectoral regulators (ICO, MHRA, CMA, Ofcom). A dedicated UK AI bill is debated but not in force as of May 2026.

How they differ in nature

• Legal force, AI Act = law with fines. NIST, ISO 42001, UK principles = voluntary (with the UK partly enforced via existing sectoral regulators).
• Coverage, AI Act classifies systems by risk; NIST organises by lifecycle functions; ISO 42001 sets management-system requirements; UK works by sectoral application of high-level principles.
• Audience, the AI Act addresses regulators and operators; ISO 42001 addresses customers and certification bodies; NIST AI RMF addresses practitioners; UK principles address sectoral compliance officers.

How they fit together

For a non-EU company operating in the EU, the EU AI Act is the mandatory layer. A NIST-aligned practice or a UK-aligned governance posture does not by itself satisfy the AI Act, but it gives you a real head start, because most controls map across.

ISO/IEC 42001 is the most direct bridge: it asks for exactly the structures the AI Act expects, AI inventory, risk and impact assessment, human oversight, data governance and life-cycle control, and it is certifiable. A system built to ISO 42001 makes meeting the AI Act easier to demonstrate to authorities, customers and partners, and it aligns naturally with NIST AI RMF functions.

What this means in practice

• One AIMS, three or four narratives: build the management system once (ISO 42001), then map your evidence to AI Act articles, NIST functions and UK principles.
• Run a single AI impact assessment process, it satisfies AI Act human-oversight expectations and feeds the NIST Measure function.
• Use ISO/IEC 27001 as your information-security foundation; it underpins all four frameworks and is the natural prerequisite for trustworthy AI evidence.
• Document once, report many: keep a Statement of Applicability that cross-references the four frameworks, so the same artefact serves regulator, customer and auditor.

The frameworks are not a buffet. Treat them as one structure with different audiences: regulators want the AI Act, customers want ISO certificates, security teams want NIST functions, the UK wants sectoral evidence.

Note on scope: this article focuses on AI governance and certification. National rules outside AI Act scope, sectoral law, privacy enforcement, taxation, need their respective specialists.

Who counts as importer and distributor

An importer (Article 3) is a person established in the Union that places on the market an AI system bearing the name or trademark of a person established outside the Union. A distributor is anyone else in the supply chain, other than provider or importer, that makes a system available on the EU market.

Importer obligations (Article 23)

• Verify that the provider carried out the conformity assessment and that technical documentation and instructions are in place.
• Verify the CE marking and the EU declaration of conformity.
• Indicate your name, registered trade name and contact address on the system, on its packaging or in accompanying documentation.
• Keep a copy of the EU declaration of conformity for ten years; keep certificates issued by notified bodies available to authorities.
• Cooperate with market-surveillance authorities, and take corrective measures or withdraw the system if you suspect non-compliance.

Distributor obligations (Article 24)

• Before making available, verify the CE marking, the EU declaration of conformity, instructions for use and that the provider and importer fulfilled their duties.
• Make sure storage and transport conditions do not jeopardise compliance.
• If you suspect a risk, inform the provider or importer and take corrective measures.

Responsibilities along the AI value chain (Article 25)

Article 25 introduces a duty to allocate responsibilities along the value chain by written agreement, between providers of high-risk systems, providers of components and downstream operators integrating AI into their products. Crucially: if a downstream actor substantially modifies a high-risk AI system, or places it on the market under their own name or trademark, they may become the provider of that modified system, with the full provider duty set (and, for non-EU actors, an Authorised Representative).

What a useful AI supplier audit covers

• Technical documentation completeness (Article 11, Annex IV) and whether updates are tracked.
• Risk management system (Article 9): how the supplier identifies, evaluates and mitigates risks across the AI life cycle.
• Data governance (Article 10): provenance, quality, representativeness and bias control of training, validation and test data.
• Logging and traceability (Article 12), events you can reconstruct after an incident.
• Human-oversight measures available to the operator (Article 14).
• Transparency information you can hand to your own deployers (Article 13).
• For non-EU providers of high-risk AI: existence and contact details of the Authorised Representative (Article 22).
• Information security and AI governance evidence: ISO/IEC 27001 for the foundation, ISO/IEC 42001 for AI specifically, or equivalent demonstrable evidence.

Second-party audits as a working control

A second-party audit, you (or a representative auditor) auditing your supplier, is the most useful tool to make Articles 23–25 real. It is not a certification; it is your own evidence that you exercised due diligence. A clear audit plan, on-site or remote review, and a written report with findings and corrective measures protect you in market-surveillance interactions and in customer audits.

Article 25 turned “my supplier is responsible” into a documentation duty. If you cannot prove what you checked, you did not check it.

How to start

• List every AI component and supplier feeding into your products or operations, including model APIs and embedded libraries.
• Classify each component by AI Act risk class and by your own criticality.
• Build a baseline supplier-audit checklist mapped to Articles 9–15, 22 and 25.
• Run risk-based audits, high-risk components yearly, lower-risk on a longer cadence; trigger ad-hoc audits after material model changes.
• Fold the supplier-audit evidence into your ISO 42001 management system, so the rest of your governance benefits from it.

Note on scope: this article covers AI compliance and audit aspects only. Procurement and contract law (warranty, liability, indemnity, intellectual-property clauses) need legal counsel, supplier audits sit alongside contract review, not instead of it.

What is ISO/IEC 42001?

ISO/IEC 42001 was published in December 2023. It describes how an organisation governs the use of AI in a responsible, traceable and controllable way, across the entire life cycle of an AI system. It follows the same high-level structure as ISO 9001 (quality) or ISO/IEC 27001 (information security), so it integrates well into management systems you may already have.

At its core it answers three questions: Which AI do we use, and what for? What risks does that create, for our customers, our staff, our company? And how do we make sure those risks stay under control?

The main building blocks

• An AI policy and clear responsibilities, who decides how AI is used?
• Systematic risk assessment and an AI impact assessment
• Data management: provenance, quality and suitability of training and operational data
• Transparency and human oversight over AI-supported decisions
• Control across the whole life cycle, from selection to decommissioning
• Annex A of the standard: a catalogue of concrete controls you implement

Do I really need it?

A certified management system is not (yet) a legal requirement. But with the EU AI Act, being able to prove that you have your AI under control becomes a competitive factor. Clients, especially large industrial customers, increasingly ask for credible evidence. A system built to ISO/IEC 42001 is the most structured way to meet the obligations of the AI Act and to show trust to the outside world at the same time.

ISO 42001 turns “we use AI responsibly” from a claim into a verifiable fact.

How do you get started?

The pragmatic route starts with a gap analysis: where do you stand today against the requirements of the standard? That produces an action plan that fits how you actually operate, not a binder that helps no one. Then the controls are built, an internal audit is run, and the system is prepared for the external certification audit. Important: the certification itself is always issued by an accredited certification body, for reasons of independence.

For small and mid-sized companies the effort pays off especially when AI already influences decisions, processes customer data, or you have to provide evidence to clients.

The staged timeline

• 2 February 2025: Prohibited AI practices are banned, and the AI literacy obligation (Art. 4) applies. Providers and deployers must take measures, to their best extent, to ensure a sufficient level of AI literacy among their staff (a proportionate best-efforts duty).
• 2 August 2025: Rules for general-purpose AI models (GPAI) and the governance framework start to apply.
• 2 August 2026: The bulk of the obligations for high-risk AI systems (Annex III) become applicable, in the original text.
• 2 August 2027: Obligations for high-risk AI that is a safety component of regulated products (Annex I) apply.

What the Digital Omnibus changes

On 7 May 2026 the EU institutions reached a provisional political agreement on a so-called Digital Omnibus that adjusts parts of the AI Act. The key points for businesses: the application of the high-risk obligations is to be postponed, for Annex III systems to 2 December 2027, and for Annex I systems to 2 August 2028, and the requirements around AI literacy (Art. 4) are to be eased and simplified.

Important caveat: as of May 2026 this is a provisional agreement, not yet formally adopted and in force. Until it is, the original text and its dates apply. Plan against the original deadlines and treat the relief as a welcome buffer, not as a reason to wait.

The honest summary in May 2026: the prohibitions, GPAI rules and AI literacy already apply. The high-risk obligations are likely to move later, but that is not yet law.

What you should do now

• Build an inventory of your AI systems and classify them by risk (prohibited / high-risk / limited / minimal).
• Cover the AI literacy duty: proportionate, documented training for the people who work with AI.
• Check transparency obligations (Art. 50): label AI interactions and AI-generated content where required.
• If you operate high-risk AI, start the governance work now, the build-up takes longer than the remaining time often suggests.

How ISO 42001 helps

A management system built to ISO/IEC 42001 gives you exactly the structures the AI Act asks for: an AI inventory, risk and impact assessments, human oversight, transparency and life-cycle control. It is the most efficient way to turn a legal obligation into a repeatable, auditable process.

What each standard is for

ISO/IEC 27001 is the established standard for an information security management system (ISMS). It protects the confidentiality, integrity and availability of information, your data, your systems, your know-how.

ISO/IEC 42001 is the new standard for an AI management system (AIMS). It governs the responsible use of artificial intelligence: risks to people and society, transparency, human oversight, data quality and the life cycle of AI systems.

Where they overlap

• The same high-level structure (Annex SL): context, leadership, planning, support, operation, evaluation, improvement.
• Risk-based thinking and a Statement of Applicability that documents which controls apply.
• Internal audits, management review and continual improvement as recurring duties.
• A large shared base of evidence, policies, roles, training, supplier management.

The key difference

ISO 27001 asks: are our information assets secure? ISO 42001 asks: is our AI responsible and under control? Information security is largely about protecting the organisation; AI governance adds a strong focus on protecting the people affected by AI decisions. ISO 42001 therefore introduces AI-specific elements such as the AI impact assessment that 27001 does not have.

ISO 27001 secures your information. ISO 42001 builds on that and makes your AI trustworthy. A solid ISMS is a good foundation, but not a hard prerequisite.

Which one first?

Both orders work. A robust ISMS is a good foundation, but it is not a mandatory predecessor for ISO 42001. Because the two share structure, risk logic and much of the evidence, it often pays to look at them together and avoid building the same things twice. In practice the right sequence depends on where your risks and your client requirements sit, that is what a short assessment clarifies.

What does Article 4 require?

Providers and deployers of AI systems must take measures to ensure, to their best extent, a sufficient level of AI literacy among their staff and other people who operate and use AI on their behalf. It is therefore a proportionate best-efforts duty, not a guarantee of a particular outcome. What counts as “sufficient” depends on the prior knowledge, experience and training of the people involved, on the context the AI is used in, and on who the AI is used on.

AI literacy, as the Regulation defines it, is the skills, knowledge and understanding that allow people to deploy AI in an informed way and to be aware of its opportunities, risks and possible harm.

Who is affected?

Practically every company that uses AI. A “deployer” is anyone who uses an AI system under their own authority in a professional context, from the marketing team using a text generator to the workshop using an AI-based inspection tool. Purely personal, non-professional use is excluded.

What good measures look like

• Basic training: how AI works, what it can and cannot do, where its limits and risks are.
• Role-specific depth: people who make decisions with AI need more than occasional users.
• Practical rules: what may be entered into which tool, how to handle outputs, when a human has to check.
• Documentation: keep a record of what training happened and who took part.

What the Digital Omnibus changes

Even the original text frames Art. 4 as a proportionate best-efforts duty (“to their best extent”), not a rigid training guarantee. The Digital Omnibus (provisional political agreement of 7 May 2026) additionally foresees relief and simplifications to the AI literacy requirements. That is not yet formally adopted, however; until it is, the original text applies. Anyone who trains sensibly now is on the safe side either way.

AI literacy is the cheapest obligation in the AI Act, and one of the most effective. Teams that understand AI make fewer expensive mistakes.

No legal obligation, unlike the DPO

Under certain conditions, the GDPR requires companies to appoint a data protection officer. The EU AI Act knows no comparable, legally mandated "AI officer." So anyone waiting for an appointment obligation will wait in vain, and waste valuable time in the meantime.

What the law and the standard do require

• EU AI Act: deployers of high-risk AI must assign human oversight to competent people and define responsibilities (among others, Art. 26). The AI literacy obligation (Art. 4) also needs someone to organise it.
• ISO/IEC 42001: the standard requires clearly defined roles and responsibilities for AI, as well as accountability of top management. Responsibility must be assigned and documented.

In other words: there is no obligation to appoint a specific person, but there is an obligation to assign responsibility clearly. And that needs someone to own it.

What the role actually does

• Maintain an overview of all AI systems in use (an inventory).
• Initiate and track risk and impact assessments.
• Maintain the AI policy and ground rules, and organise training (AI literacy).
• Act as a point of contact, internally as well as for clients, auditors and supervisory authorities.
• Build a bridge between management, IT, data protection and the business units.

One person or a committee?

For small and mid-sized companies, a single named person in a part-time role is usually enough, ideally with a short line to management and close ties to data protection and information security. In larger or heavily regulated organisations, a small AI committee works well. What matters is not the title, but that responsibility is assigned unambiguously and documented in a way others can follow.

One thing stays true: top management carries the responsibility. The AI officer coordinates and takes operational load off leadership, but does not relieve management of its accountability.

AI governance is not made by a title, but by the clear, documented assignment of responsibility. An AI officer is the simplest path to get there.

Three concepts that carry everything

• Audit criteria: the yardstick, for example the standard, your own policies, or legal requirements.
• Audit evidence: the facts, including documents, records, statements and observations.
• Audit findings: the result of comparing the evidence against the criteria (conforming or not).

The seven principles behind every credible audit

The methodology for management system audits is described in ISO 19011. Seven principles guide every auditor:

• Integrity: professional trustworthiness and honesty.
• Fair presentation: reporting truthfully and accurately, including uncomfortable facts.
• Due professional care: applying sound, appropriate professional judgement.
• Confidentiality: handling all audit information with care.
• Independence: remaining impartial and avoiding conflicts of interest.
• Evidence-based approach: drawing conclusions only from evidence (sampling).
• Risk-based approach: focusing the audit where the risk is greatest.

An audit never proves that "everything is perfect." Using samples, it assesses whether the system demonstrably works, honestly and with a focus on risk.

First, second or third party?

• First-party audit (internal): the organisation audits itself, which is mandatory in every management system.
• Second-party audit: a customer audits its supplier (supplier audit).
• Third-party audit: an independent certification body audits with the goal of certification.

The audit lifecycle

Whatever the type, the process follows the same pattern:

• Initiation and planning: define the objective, scope, criteria and audit programme.
• Preparation: review documents and prepare the audit plan and checklists.
• Conduct: hold the opening meeting, gather evidence (interviews, observation, documents) and draw samples.
• Reporting: classify the findings, produce the audit report and hold the closing meeting.
• Closure and follow-up: track corrective actions and verify their effectiveness.

It is the final step that decides the real value. An audit whose findings nobody acts on was a waste of time. That is why verifying the effectiveness of the corrective actions is an inseparable part of the process.

The chain of trust, from top to bottom

• Accreditation body (in Germany, the DAkkS): oversees and accredits certification bodies. In effect, it certifies the certifiers.
• Certification body: carries out the external audits and issues the certificate. It is itself accredited against international requirements.
• Organization: has its management system audited and certified.

This chain is exactly why an accredited certificate carries weight. It does not stand on its own; it is part of a supervised system.

Who is allowed to do what?

• Internal auditor: audits their own organization (a requirement), but may not issue certificates.
• Consultant / implementer: helps build the management system.
• Lead auditor (external): leads audits, including on behalf of certification bodies, with the corresponding qualification and audit experience.
• Certification body: the only party that can issue the accredited certificate.

Why advice and certification are kept apart

One core rule applies: whoever builds or advises on a system cannot also certify it. Otherwise you would be reviewing your own work, and independence would be gone. That is why the division of tasks makes sense. An implementation partner brings you to maturity, and the accredited body confirms it independently.

This separation is not an obstacle but a safeguard for quality: preparation and judgment are deliberately placed in different hands.

System certification vs. person certification

Two things are often mixed up. System certification confirms that an organization has a functioning management system. Person certification confirms an individual's qualification, for example as a lead auditor. Both are useful, but they are different kinds of evidence with different purposes.

For AI management systems under ISO/IEC 42001, this landscape is still taking shape: accreditation and certification bodies are positioning themselves, and qualified auditors remain scarce. That is an advantage for everyone who starts early.

Classic risk management: risk TO the organization

Familiar risk management asks: what could harm my organization? With AI, that includes things like faulty model decisions, poor data quality, outages, or dependence on suppliers. ISO/IEC 23894 gives this approach depth and ties into the general risk standard ISO 31000: identify, analyze, evaluate, treat, monitor.

• Treatment options: avoid, reduce, transfer, or knowingly accept the risk.
• AI-typical risk sources: bias, lack of robustness, drift in operation, missing transparency.
• Important: risks are documented and their treatment is tracked, not assessed once and forgotten.

Impact assessment: risk FROM the AI to others

This is where the decisive difference with AI lies. An AI system impact assessment (guidance: ISO/IEC 42005) does not ask what harms the organization, but what effects the AI has on affected people and society, for example on applicants, customers, or patients. Classic risk management does not capture this outward perspective in the same way, and it is exactly what responsible use of AI demands.

DPIA: the data protection impact assessment

If the AI processes personal data that is likely to result in a high risk, the GDPR (Art. 35) requires a data protection impact assessment (DPIA). In substance it overlaps heavily with the AI impact assessment, since both ask about the consequences for people.

Where AI processes personal data, it pays to combine the AI impact assessment and the DPIA into one consolidated document instead of two separate compliance exercises.

Why these belong together

ISO/IEC 42001 forces you to take both viewpoints: the risk to the organization and the effect on the outside world. It is precisely this dual perspective that turns "we use AI" into a responsible, auditable practice, and it incidentally produces the evidence that the EU AI Act requires for high-risk systems.

What is Annex A?

Annex A is a catalogue of controls, that is, concrete measures an organization uses to get its risks under control. In ISO 42001 these are organizational and governance controls around AI, grouped by area: AI policy, roles and resources, impact assessment of AI systems (effects on individuals and on society), the AI lifecycle, data for AI systems (quality and provenance), transparency and information for interested parties, responsible use, and the handling of third parties and suppliers.

Important: Annex A is deliberately generic and organizational. Model-specific technical tests, such as for bias, robustness, or adversarial attacks, must be planned in addition; the annex does not replace them.

What is the Statement of Applicability (SoA)?

The Statement of Applicability is the document that records, for each control: Does it apply to us? Why (or why not)? And what is its implementation status? It is the bridge between your risk assessment and the concrete measures.

• Which controls are applicable, derived from the risk assessment?
• Justification for the inclusion or exclusion of each control.
• Implementation status: planned, implemented, effective?

Why the SoA is the heart of the audit

For the auditor, the Statement of Applicability is the map through the entire system: it shows what you have declared relevant, and that is exactly what gets sampled for effectiveness. A well-considered, honest SoA is therefore half the battle; an empty or whitewashed one stands out immediately.

The SoA is not a bureaucratic form but the map of your management system, for yourself just as much as for the auditor.

Risk-based, not a tick-box list

The decisive point: controls are not adopted as "all implemented" across the board but selected risk-based. An exclusion is entirely legitimate, as long as it is justified. It is precisely this traceable logic from risk to measure that an audit wants to see.

What is a standard?

A standard is a voluntary document developed by consensus. ISO is the International Organization for Standardization, based in Geneva, where national standards bodies work together. A standard describes how to do something "according to recognized good practice." It is not a law, yet it can become effectively binding through contracts, tenders or regulation.

A label such as "ISO/IEC 27001" already tells you something about a standard's pedigree: ISO is the international body, IEC the International Electrotechnical Commission, and the two publish information-security and AI standards jointly. In Europe and Germany the same text is then adopted as "EN" and "DIN" respectively. The content stays identical, only the level of adoption changes.

What is a management system?

A management system is the way an organization steers a particular topic, using objectives, roles, processes, documents and controls. A quality management system (QMS) steers quality, an information security management system (ISMS) steers information security, and an AI management system (AIMS) steers the responsible use of AI.

A management system standard sets out the requirements for such a system, not for a single product. An ISO 9001 certificate therefore says something about how you work, not about a specific manufactured part.

Why the standards look so similar: Annex SL

Modern management system standards, including ISO 9001, ISO/IEC 27001 and ISO/IEC 42001, follow a common backbone called the "Harmonized Structure" (formerly Annex SL / High Level Structure). As a result they share the same clauses: context of the organization, leadership, planning, support, operation, performance evaluation and improvement.

• Context: Who are we, which interested parties exist, and what is the scope?
• Leadership: Top management takes responsibility and sets a policy.
• Planning: Risks and opportunities are assessed and objectives are set.
• Support & operation: Resources, competence, documentation and processes that are actually lived.
• Performance evaluation & improvement: internal audit, management review, corrective actions.

The big advantage: anyone already living ISO 9001 will recognize the same logic in ISO/IEC 27001 or ISO/IEC 42001, and can integrate the systems instead of maintaining three separate bureaucracies.

The core principle: PDCA

Behind every management system sits the PDCA cycle: Plan, Do, Check, Act. A management system is therefore never "finished". It is an ongoing loop of continual improvement. And that is exactly what an audit examines: is the loop genuinely being lived?

Certifiable, or just a guideline?

Not every ISO publication is certifiable. Requirements standards such as 9001, 27001 or 42001 (recognizable by the word "shall") are the basis for a certificate. Alongside them sit guidance documents and technical reports that only offer orientation and are not certified against. So if you are aiming for certification you need the right standard, plus an accredited certification body to issue it.

A management system is never "finished". It is an ongoing loop of continual improvement, and an audit asks whether that loop is genuinely being lived.

The central standard: the "what"

ISO/IEC 42001 defines the requirements for the management system, in other words what has to be in place: policy, roles, risk assessment, controls, improvement. It is the only standard in the family you can actually get certified against.

The companion standards: the "how" and "how deep"

• ISO/IEC 42005, AI System Impact Assessment: how to evaluate the consequences for affected people and for society.
• ISO/IEC 23894, AI risk management: deepens the risk work and ties into the generic risk standard ISO 31000.
• ISO/IEC 22989, Terminology and concepts: the shared vocabulary that ISO/IEC 42001 refers to.
• ISO/IEC 23053, Framework for AI/ML systems: the technical vocabulary for the architecture.
• ISO/IEC 38507, Governance implications of AI: the perspective of top management.
• ISO/IEC 42006, Requirements for bodies certifying AIMS: relevant for accreditation, not for the organization being audited.

And the standards for the auditor?

Two further standards are less about content and more about method. ISO 19011 provides the audit methodology for management systems, while ISO/IEC 17021-1 sets the requirements for certification bodies. They don't define what makes a good AI system, but how cleanly an organization is audited and certified.

Rule of thumb: ISO/IEC 42001 says WHAT an AI management system needs. The companion standards say HOW to do the individual parts well. ISO 19011 and ISO/IEC 17021-1 say how the whole thing is audited.

What this means in practice

For an audit or an implementation you don't need the entire library. ISO/IEC 42001 is the anchor; you reach for ISO/IEC 23894 and ISO/IEC 42005 when risk and impact assessment need real depth; ISO/IEC 38507 helps the leadership level. What matters is knowing the right standard for the right question, and that is precisely part of an auditor's competence.

The internal audit

In an internal audit, the organization checks itself, in a planned way, against its own audit program. Independence is essential: no one should audit their own work. In small operations you solve this through peer audits, contracted internal auditors, or a clear separation of roles.

• An audit program defines what is audited, when, and in what depth.
• The findings feed into corrective actions and into the management review.
• The goal is not to tick a box, but to get an honest picture before the external audit.

The management review

In the management review, top management looks at the entire system at planned intervals: Is it working? Is it meeting its objectives? Where does it need to be adjusted? This is the moment when leadership visibly takes ownership.

Typical inputs are audit results, performance indicators, risks and opportunities, feedback from interested parties, changes, and the status of open actions. Typical outputs are decisions on improvements, resources, and objectives.

The internal audit supplies the facts, the management review makes the decisions. Together they keep the PDCA cycle turning.

Why the certification body looks here first

In a certification audit, the internal audit and the management review are among the first records requested, often already in Stage 1. The reason is simple: an organization that does not assess and review itself cannot have a living management system. If they are missing, the audit fails before it has really begun.

The most common mistakes

• Running the internal audit pro forma just before the external audit.
• Treating the management review as a minute-taking exercise with no real decisions.
• Documenting findings, but never verifying that the corrective actions were effective.

Before you start: proposal and contract

You sign a contract with a certification body. The body plans the audit based on your scope, your headcount and the complexity of your operation, and from this it derives the number of audit days. One important point: a body that certifies you may not, for reasons of independence, also act as your consultant.

Stage 1: the readiness review

In the first stage, the auditor focuses primarily on your documentation and your fundamental audit readiness. Is there a policy, a defined scope, a risk assessment, the core procedures and, depending on the standard, evidence such as a Statement of Applicability? Stage 1 exists to surface gaps early, to plan the Stage 2 date and to avoid surprises later.

• Review of the documented information and the scope
• Assessment of whether an internal audit and a management review have been carried out
• Clarification of sites, key processes and open issues
• Outcome: readiness for Stage 2, or a list of gaps to close

Stage 2: the on-site audit

The second stage is about effectiveness: is what is written on paper actually lived in practice? On site (or remotely), the auditor gathers evidence through interviews, observation and examination of records. The entire standard is assessed, with a risk-based focus on the areas that matter most.

A typical flow: an opening meeting, an audit of leadership and of the core processes along the clauses of the standard, a continuous log of findings, and finally a closing meeting where the results are presented.

Findings, corrective actions, decision

You must respond to nonconformities with corrective actions and a root cause analysis; for major nonconformities, evidence is required before the certificate can be issued. The actual certification decision is then made by a body within the certification body that is independent of the audit team, not by the auditor.

A certificate is usually valid for three years, but only as long as the annual surveillance audits confirm that the system continues to be lived.

The role of preparation

This is exactly where the leverage lies. If you run an honest gap analysis and an internal audit "the way the certification body would" before the external audit, you already know your weak points. The external audit then becomes a confirmation rather than a risk.

The severity levels of a finding

• Major nonconformity: a systemic failure or a serious risk. A requirement is not met, or the system is at risk of failing.
• Minor nonconformity: an isolated case or a small gap that does not fundamentally call the overall system into question.
• Observation: not yet a nonconformity, but an early warning signal worth keeping an eye on.
• Opportunity for improvement: a suggestion for doing things even better, with no obligation attached.

The difference between a major and a minor nonconformity is not arbitrary. It comes down to systematics and risk. A single forgotten record is judged differently from a process that simply does not exist.

The right response in three steps

• Correction (immediate): fix the specific problem right away.
• Root cause analysis: understand why it happened, not just the symptom.
• Corrective action (CAPA): eliminate the cause so it does not recur, then verify that the action was effective.

If you only fix the symptom, you will see the same nonconformity again at the next audit. Root cause analysis is the real lever.

What does this mean for certification?

A major nonconformity must, as a rule, be demonstrably closed before the certificate can be issued. For minor nonconformities, an accepted action plan is usually sufficient, with its implementation reviewed at the next surveillance audit. A clean, honest root cause analysis counts for more than a quick cosmetic fix.

The right mindset

Mature organizations welcome findings. They are free, expert pointers to real weaknesses, identified in the protected setting of an audit rather than in an actual incident. Once you internalize that, the audit becomes a tool for improvement instead of a source of exam-style anxiety.

Findings are the most valuable outcome of an audit: they show exactly where you need to act.

The three-year cycle

• Year 0: certification audit (Stage 1 + Stage 2), the certificate is granted.
• Year 1: first surveillance audit.
• Year 2: second surveillance audit.
• Year 3: recertification audit, the certificate is renewed for the next cycle.

The surveillance audit

Surveillance audits are shorter than the certification audit, but they look specifically at whether the management system is still being lived and improved. A few elements are almost always on the list:

• The internal audit and management review carried out since the last visit
• How complaints, incidents and changes have been handled
• The status of the agreed corrective actions
• Correct use of the certificate and the certification mark

Recertification

At the end of the cycle comes a more comprehensive reassessment of the entire system, similar to the first certification audit, but with an eye on how the system has developed over the three years. After that, the cycle starts again.

A management system is never "finished." That is exactly the point of the cycle: continual improvement instead of a one-off heroic effort.

What happens if the system goes to sleep?

If a surveillance audit finds that the system is no longer being lived, the certification body can suspend the certificate and, in serious cases, withdraw it. Anyone who treats the cycle as routine from day one, internal audit, management review, well-maintained actions, never runs into that problem.