EU AI Act Masterclass, Part Two

The difference between an AI policy and evidence of AI compliance

Ask a company whether it governs its AI and you will usually get a document. Ask it to prove the document is true and the room goes quiet.

 Ahmed draws the line in one move. A policy is a promise. Evidence is a receipt. Regulators, boards and insurers are not in the business of collecting promises, and they stopped being impressed by them a while ago.

 His analogy is the one worth stealing. A policy is a menu. It tells you what is theoretically on offer. What an inspector actually wants is the recipe: what goes into the dish, who made it, and whether the kitchen passed its last check. As he put it, what is the regulator or your board going to do with the menu? It is good marketing material. It is not proof of anything.

 There is a test in there you can run on your own company this afternoon. If somebody asked you tomorrow to show rather than tell, what could you physically hand over? If the honest answer is a PDF, you have a menu.

 The annexes of the EU AI Act set out what the documentation is expected to contain, so this is not a matter of guessing what would satisfy someone.

What counts as evidence under Article 4 of the EU AI Act

Article 4 requires providers and deployers to make sure the people working with their AI systems have a sufficient level of AI literacy. It has applied since 2 February 2025, and when the Digital Omnibus pushed most of the high-risk obligations out to December 2027, Article 4 was not among them. Whatever else moved on the calendar, this one is live now.

 The wording says train your people. What it means in practice is train your people and be able to prove you did.

 Ahmed starts with the business case rather than the legal one, which is the right order. If you have five thousand people, or twenty-five thousand, with new hires arriving and existing staff changing roles, how would you even know whether your workforce meets a minimum standard? You would not. So the first thing you need is a record that tells your HR team who has reached the baseline and who has not, because if you are not bringing people to that standard you are letting them down before you are letting any regulator down.

From there, what counts as evidence:

He is blunt about why attendance on its own does not clear the bar. Plenty of people attend training. Not everybody pays attention. So he adds a quiz, and where the role is genuinely critical, a full assessment, and only once somebody has demonstrated competence at a basic level do they get to resume the part of the job that touches the tool. Otherwise that person becomes a single point of failure.

 His comparison is a hydraulic hammer. You would not hand one to somebody who had never been trained on it and hope they worked out the button. They would take the factory apart. AI tools carry comparable force in the wrong hands and almost none of the same handling requirements, which is the part that should bother people more than it does.

 And then the line that belongs on a wall somewhere: a certificate nobody can find is a policy. It is not proof.

Why documented training becomes a mitigating factor when something goes wrong

Ahmed points out that these questions are not hypothetical, because privacy regulators already ask them. When there is a breach and you report it, one of the first things you get asked is when you last trained your staff, specifically the staff involved in the incident, and whether you can share the details. Nobody should be surprised by that question. It is standard.

 If you can demonstrate a real training programme, it acts as a mitigating factor when a penalty is being set.

 His point holds. The numbers around it are worth getting right, because the Act does not have a single fine ceiling. It has three tiers.

For SMEs and start-ups the lower of the two figures applies rather than the higher. And Article 99 requires authorities to weigh mitigating and aggravating factors when they set an amount, which is where the training evidence earns its keep. The record is not a nice-to-have you produce afterwards. It is the thing that moves the number.

The five clauses to demand from every AI vendor contract

This is the most immediately usable part of the conversation. Ahmed names five things he wants in writing from any general-purpose AI vendor before a deal gets signed.

The clause vendors resist hardest

Ahmed is realistic about why vendors push back at all. Your point of contact is usually somebody on the sales side who wants the deal closed and the commission booked, so the reflex is to say you can sort all that out later. His advice is to not accept that. Later is how this ends up unresolved and in your file.

 The harder case is a power imbalance. Walk up to a hyperscaler with a list of demands and you will be shown the standard terms and told to take them or leave them. The consolation is that the largest vendors already have AI governance teams, already understand the requirements, and already want to sell into Europe, so the documentation frequently exists whether or not they will negotiate the paper.

 The one they push back on hardest is the fifth. Nobody wants to be contractually pulled into your conversations with a regulator. As Ahmed put it, everybody would like to stay invisible to the regulator, which is exactly why the clause matters.

 And the stakes on that fifth clause run in three directions. If a regulator asks you for something and you cannot produce it because your vendor will not hand it over, that counts as an aggravating factor against you. If an important client makes a reasonable request you cannot meet, you lose the client or you lose money. And if your insurer asks and you cannot answer, you either pay a higher premium or, in the worst version, you find out that the risk you thought you had transferred was never transferred at all.

How fast should an AI vendor tell you something broke

There is no universal number here, and Ahmed does not pretend otherwise. It depends entirely on how business-critical the system is and what the consequences look like if it goes wrong.

 But there is a reference point. GDPR says a processor must notify without undue delay, which on its own means nothing operationally. So in his own contracts, Ahmed defines it. Twenty-four to forty-eight working hours, pushed to seventy-two at the absolute outside.

 The reasoning is simple arithmetic. The sooner you know, the cheaper the fix and the fewer people get hurt. The longer it sits, the more both of those numbers move in the wrong direction.

 Then he gives the example that makes it concrete. Say you are in pharmaceuticals and you are using an AI system to help determine the correct dose going into a drug. Those get shipped to hospitals and clinics and people start taking them more or less immediately. Now say there is a glitch. How comfortable are you finding out about it in six months? What is your appetite, exactly? Ten people harmed, a hundred, a million, none? Answer that honestly with your risk team, check what your insurance actually covers, and then write the notification window that matches the answer. That is the process. Not a number somebody copied out of a template.

Where to start if your company has done nothing about AI governance

Four steps, in this order.

 First, get clarity, because without it you cannot make confident decisions about anything else. That means an inventory of every AI system in the business, including the shadow ones nobody registered and everybody is quietly using. You cannot classify what you have not found.

 Second, classify what you found. Twice over. Once against the four risk tiers covered in part one, where limited risk is the tier most people skip past and the one that should have their attention right now.

 The second classification is the one companies get wrong. Ahmed lists five roles a business can play under the Act: provider, deployer, importer, distributor, and authorised representative. The Act’s own definition of an operator adds product manufacturer as a sixth. None of them are mutually exclusive, and every obligation attached to every role you are playing applies to you at once.

"A certificate nobody can find is a policy. It is not proof."

Jamal Ahmed

One tool, three hats

A UK firm buys an AI tool built in the US. That makes it the importer. It white-labels the tool for its own clients. Now it is also the provider. It uses the same tool internally for hiring. Now it is the deployer as well. One purchase, three roles, three rule books, and a company that almost certainly believes it is just a user.

That belief is the whole problem. Most organisations assume they are users with no obligations. A meaningful number of them are already providers and do not know it.

 Third, check what you found against the banned list. Anything on it stops the day you find it.

 Fourth, assess your AI literacy needs, start the training, and document the evidence as you go rather than reconstructing it later under pressure.

What happens when insurers start pricing AI risk separately

This is the part that should get a CFO’s attention.

 Right now, AI risk sits quietly inside general liability and umbrella policies. Not many carriers price it separately. Not many ask hard questions about it at binding. Which means, as Ahmed puts it, a great many companies are currently insured for AI entirely by accident.

 Renewal is where that arrangement ends. Underwriters have already started asking for the AI inventory, the classifications, the evidence of training, and the incident management process. Every single thing covered in this conversation, arriving as a questionnaire with a premium attached to the answers.

 And what satisfies an underwriter is not a policy document. It is an independent, measurable assessment. The question they are asking is not whether you have written something down. It is whether you can evidence the controls.

The training gap runs all the way to the board

Jeff’s observation at the close of the conversation is the one that reframes everything above. The AI fluency problem is not confined to the people using the tools. Boards are being asked to oversee AI risk without the fluency to understand what they are overseeing, which means the training obligation does not stop at the staff who touch the systems. It runs from the bottom of the company to the top of it.

 Which brings the whole conversation back to a measurement problem. Somebody is going to ask your board to prove it. The regulator, the enterprise customer, the underwriter at renewal. They are all asking a version of the same question, and none of them will accept the menu.

Is your AI investment making money or losing money?

TheAIAudit measures your organization’s collective AI investment and returns a single AI Health Score from 0 to 100, with three statements behind it that say what to fix: Governance, Impact, and Risk Flow.

Apply for the founding cohort