The mistakes that make an AI training plan fail an audit

In short. An AI training plan gets challenged in an ISO/IEC 42001 audit for six recurring reasons: delivery doesn't match what was declared, evidence isn't tied to roles, effectiveness was never evaluated, the plan doesn't update when systems and people change, whoever approves hasn't understood what they're approving, and the perimeter stops at employees. All six share one origin, training treated as a box to tick and disconnected from the system inventory. Below: how each surfaces, what evidence prevents it, and when a finding becomes a major nonconformity.

During a certification audit the auditor compares the plan against attendance records, samples a few people, and asks direct questions about what they learned and how they apply it. That comparison between paper and reality produces almost every clause 7 nonconformity, including at companies that spent serious budget on training.

Where the plan breaks between stage 1 and stage 2

Certification runs in two stages, and training behaves differently across them. In stage 1 the auditor verifies the documents exist and hang together: there's a plan, there's a role matrix, there's a procedure describing how competence gets determined. Passing it is relatively easy, because the paperwork only has to be in order.

In stage 2 the verification changes nature. The auditor checks that the plan was implemented and produced the stated effect, and does so by talking to people. This is where most clause 7 findings appear, and the gap between the two explains why companies confident after stage 1 end up with a list of observations in stage 2.

Preparing for certification by looking only at documentary completeness means preparing for half the audit.

The plan that doesn't match delivery

The plan exists, perhaps with a tidy calendar and recognised vendors, but what actually got delivered is different. This happens when a course is bought for a wider group than the one that eventually attends, or when the vendor changes the program mid-stream and the internal documentation stays on the original version.

The three most frequent discrepancies all show up in the records: people listed in the plan who don't appear among attendees, modules delivered with content different from what was described, sessions postponed and never rescheduled that the plan marks as complete. None is serious on its own, but together they describe a process nobody governs, and that's the conclusion the auditor writes down.

Prevention is cheap: a plan revision at every program change, with date and reason, turning a discrepancy into a tracked decision.

Generic evidence

Even where training took place, the proof that matters is often missing: a record with a verifiable date, the link between who attended and the role they hold, a certificate describing content in more detail than "AI basics course". Generic vendor certificates, with no reference to the competence required for the role, don't demonstrate that the competence was covered.

The practical test is simple. Take a certificate at random and ask whether, reading it with no other information, you can tell which competence from the matrix that person acquired. If answering requires opening three more documents and reasoning through them, the auditor will hit the same difficulty and note it.

The effectiveness evaluation that doesn't exist

This is the most expensive finding, and often the most unexpected, because it lands at companies that got everything else right. Clause 7.2 requires taking action to acquire the necessary competence and evaluating the effectiveness of those actions, which are two distinct obligations.

An attendance register documents delivery. It says nothing about effectiveness, and when the auditor asks how that was verified, the most common answer is the satisfaction survey, which measures how much attendees enjoyed the course rather than what competence they gained.

The forms of evaluation that hold up are different: a practical case completed and marked, real work reviewed by someone more experienced, a field check weeks later, a structured interview with a recorded outcome. None needs special tooling, all need planning in advance rather than reconstruction afterwards.

A plan frozen in time

A plan written a year ago and never revised loses validity even if it was correct when drafted. New AI systems have arrived since, associated risks have shifted, and people have joined who never saw that plan.

The check the auditor runs is mechanical: compare the date of the plan's last revision against the entry date of the newest system in the inventory and against recent hires. If the inventory moved and the plan didn't, the update mechanism isn't working, however complete the plan is for everyone who was already there.

Training, like the AI system inventory, needs a trigger that refreshes it when something relevant changes. Two triggers work in practice, a new system entering and a person changing role, both attached to processes that already exist and that nobody can skip.

Approval without understanding

This is the most delicate one: a person with approval authority signs off without having understood what they're approving. It happens more often at management level than in operational teams, because training for those who govern gets treated as less urgent than technical training.

A few auditor questions bring it out, and the consequence reaches beyond training. An approval without understanding puts the AI decision-making process itself in question, which is the heart of what the standard asks of top management. The finding therefore tends to travel from clause 7 up to clause 5 on leadership, which is why it weighs more than it appears to.

The perimeter that stops at employees

Clause 7.3 speaks of people working under the organisation's control, a formula covering temporary staff, consultants, contractors and personnel of suppliers operating inside your processes. Almost every plan stops at the payroll, because that's where the HR system the plan was built from ends.

The auditor notices indirectly, spotting that someone met during the visit appears in no record. The typical case is the external agency running customer service with an AI-assisted tool, where the people using the system daily aren't yours and no training plan covers them.

The only instrument that works here is the contract, which needs to set competence requirements and an obligation to supply evidence they're met.

How they surface in audit

Mistake	How it surfaces	Evidence that prevents it
Plan differs from delivery	Comparison of plan against attendance records	Updated records and a plan revised at every program change
Generic evidence	Request to link certificates to roles	Certificates with detailed content, tied to the role matrix
Effectiveness not evaluated	Question on how acquired competence was verified	Marked practical cases, reviewed work, field checks with recorded outcomes
Plan frozen in time	Comparison of plan date, inventory and org chart	Documented triggers for new systems and new joiners
Approval without understanding	Direct questions to whoever signed	Minutes of management training and of subsequent decisions
Perimeter limited to employees	People met on site and absent from the records	Competence requirements in supplier and agency contracts

The auditor's sample

Sampling isn't random, and knowing how it's built allows you to simulate it beforehand. The auditor starts from the role matrix and picks three to five people across different profiles, favouring three categories: whoever exercises human oversight over a significant system, whoever joined recently, whoever signed an approval.

The questions are simple and nearly always the same. What's the company's AI policy and where is it. What does the system you use every day do. What would you do if you noticed it getting something wrong. Who would you report that to.

When the sampled person can't answer, the nonconformity isn't theirs. It belongs to the management system, which planned a training action without verifying its effectiveness, which loops back to the third mistake on this list.

When a finding blocks the certificate

Findings don't carry equal weight, and the difference decides whether certification arrives or slips.

A minor nonconformity is partial implementation of a requirement, an isolated case, missing evidence on one person. It's handled with a corrective action plan, normally due within three months, and doesn't block issuance of the certificate.

It rises to major when a requirement is systematically absent, or when a failure compromises the system's ability to achieve its objectives. A complete absence of effectiveness evaluation, repeated across every module, has the characteristics to qualify, and in that case the certificate isn't issued until the finding is closed and verified, often through an additional visit.

The practical distinction is between a repeated error and an isolated one. A generic certificate for one person is an instance. Generic certificates for everyone are a process that doesn't work.

A hypothetical example

A department head signed off his team's training on an AI sales-support system as complete. During the audit the auditor asks which risks of the system the course covered, how staff recognise an output that needs checking, and who they report an anomaly to. By the third question the head admits he doesn't know the course content, and the nonconformity covers both the competence evidence and the approval process. The example is illustrative and does not describe a real case.

The same gap, in a different forum

A training plan that fails an audit has, since the end of September, a second place where it can come due. Legislative Decree 160/2026, in force in Italy from 30 September, allows a court to order disclosure of the human oversight parameters and arrangements required by Article 14 of the AI Act, and provides that failing to disclose without justified reason leads the facts alleged by the claimant to be treated as established.

Demonstrating human oversight also means demonstrating that whoever exercised it was able to. The generic evidence described above, the attendance register without an effectiveness check, the approval without understanding, is precisely what fails to support the claim that oversight genuinely existed. The defect is the same one that triggers an audit finding, with consequences of a different nature.

Anyone preparing the plan for an audit is therefore preparing, without realising it, material that may be needed elsewhere. The context is set out in the article on evidence and causation under Legislative Decree 160/2026.

Before the audit, a simulated sample

The most useful check consists of doing what the auditor will do, a few weeks earlier and on a sample built with the same criteria.

• Does the plan match, module by module, what the records show?
• Is every piece of evidence tied to the person's role in the matrix?
• For each module, is there an effectiveness evaluation distinct from a satisfaction score?
• Is there a mechanism that updates the plan when a new system or a new person arrives?
• Has whoever approves the training followed the path set for their level?
• Do contractors with system access appear in the plan or in the contracts?
• Picking three people by the auditor's criteria, can they answer the four standard questions?

That last point yields the most reliable information and takes half an hour. If two out of three hesitate, the problem isn't theirs, and better to find out now.

Next step

Preventing every mistake on this list runs through training tied to roles and systems. The levels are described in a roles-competence matrix for AI, the coordination with the AI Act in AI literacy and ISO 42001 competence, and the full clause requirements in clause 7 explained without jargon.

If you want your plan checked before the audit, AI Rating is the starting point, or you can book an assessment meeting.