Training a team on AI: my 30 day protocol

Your team comes back from an AI training day. Everyone found it fascinating. Three weeks later, two people are tinkering on their own, the senior art director still reworks everything, and the only trace left of that day is the trainer's invoice.

I have watched this play out often enough to know where it comes from. A training day passes on gestures. It does not touch the schedule, the sign off criteria, or the way a deliverable leaves the building. Three weeks in, the old process has swallowed everything.

What follows is the calendar I run when a company asks me to bring a creative team up to speed on AI. Thirty dated days, named artefacts, three numbers recorded before anything starts, and a clear decision at the end. No seminar, no certificate.

What these 30 days have to produce

By day 30, the team ships a client deliverable made with AI without the senior redoing the work behind them. Knowing how to write a prompt sits far below that goal, and three conditions matter more.

Everyone has to judge quality with the same words. When the art director says "that looks plastic" and the motion designer hears "that is oversaturated", every round trip costs another generation. That part is the teaching side, and I covered it in the programme on training an internal creative team in AI video: shared vocabulary, a QA grid on the wall, rotating roles. This article handles the other half, the one nobody budgets for: how you run the operation, who sits in the room, how many hours it eats, and how you prove it worked.

Second condition, one deliverable serves as the testing ground. Scope it down to "the three variants of the product video for client X" and keep the phrase "AI in the agency" out of the room entirely. The brief itself has to be tight, which is why I keep a client brief for AI video production short and physical rather than adjectival.

Third condition, you know your starting point in numbers. That is the job of day 1, and it is where most programmes fall over before they even begin.

💡 Frank's cut: I turn down training jobs where the client will not hand me a live deliverable. With nothing at stake, people produce pretty exercises and forget all of it, because none of it ever met a client who pushes back.

Since February 2025, training your team is a legal duty

I usually run into this one at the end of an engagement, too late to handle it properly. Article 4 of the European AI Act covers AI literacy, and it has applied since 2 February 2025.

The text was rewritten in July 2026 by Regulation (EU) 2026/1744, the Digital Omnibus on AI. In the version in force published by the AI Act Service Desk, paragraph 1 requires providers and deployers of AI systems to "take measures to support the development of AI literacy" among their staff and anyone operating those systems on their behalf, accounting for their technical knowledge, experience, education and training, and the context of use. The same paragraph adds that the duty does not require anyone to guarantee a specific level of AI literacy in a given individual.

A deployer, in that vocabulary, means any organisation using an AI system under its own authority in a professional setting. A three person agency running an image generator on a client project is a deployer.

Screenshot of the Article 4 page on the European Commission's AI Act Service Desk, taken on 3 October 2026. Paragraph 1 carries the AMENDED marker, and the note at the top states that the text shown follows the EUR-Lex consolidated version as at 27 July 2026, with NEW and AMENDED flagging the Digital Omnibus changes.

No formal training or certificate is imposed. The Commission's official FAQ on AI literacy, updated on 27 July 2026, states that there is no one size fits all and that no strict requirements or mandatory trainings are imposed. The acceptable measures it lists stay broad: trainings, guidance, internal resources, human in the loop setups, and documentation of what you did.

Supervision, on the other hand, has a date. National market surveillance authorities enforce Article 4, and they have been doing so since 2 August 2026. The Commission's AI Office does not enforce this provision itself.

In practice that changes one thing in how you train: you document. Every session, every internal guide, every version of your sign off grid becomes a piece of evidence. I have that trail kept and dated from day 1, and it costs ten minutes a week.

For the rest of the rules that hit our trade directly, in particular the labelling of generated content, the detail sits in my piece on audiovisual jobs facing AI.

The three numbers to record before day 1

With no starting point, the end of the programme boils down to "people enjoyed it". That holds up for about three minutes in front of a managing director.

I record three measurements on one specific deliverable, the one that will serve as the testing ground, in its pre AI version.

Cycle time. From approved brief to delivery accepted by the client, in calendar days. Not working hours, actual days, waiting time included.

Working time. The sum of billable hours spent on it, per person. If nobody logs time, ask each person separately for an estimate and keep all three numbers. The spread between estimates already tells you something.

Rework rate. Across the last ten deliverables of the same kind, how many came back for correction after going out. That is the number teams hate pulling up, and the one that speaks loudest.

These three take half a day to collect if projects are tracked, two days otherwise. The rework number matters most, because it is the only one the client actually feels. If your reporting makes it hard to pull, the format I use for client PDF reporting on AI video deliverables will save you that dig next time.

Pick the right people too. Training six when only two will use the gesture day to day is the waste I see most often.

The protocol, day by day

Thirty working days, not thirty calendar days. Count six weeks on the calendar once you allow for holidays and client emergencies.

Days 1 to 5: inventory and baseline

Day 1, the inventory. Which AI tools already run in the company, paid by whom, on whose account. You will find two or three subscriptions on an employee's personal card, and often a free tier training on client images. I have never once run an inventory without hitting at least one of those.

Days 2 and 3, the three baseline numbers. Write them in a dated file you will never edit again.

Day 4, choose the ground. One deliverable, one client, a real deadline between day 21 and day 27.

Day 5, the kickoff meeting, 90 minutes, everyone present. You announce the ground, the three starting numbers, and what happens on day 30. People work a lot better once they know the verdict will be a number.

Artefacts by the end of week 1: an inventory, a baseline file, a written scope.

Days 6 to 12: one tool, one gesture

This is the week everyone wants to test fifteen tools. Hold the line at one.

Pick one tool and one single gesture inside the deliverable. The three background variants, say, rather than "the whole video". Each person redoes the same gesture on the same brief, alone, in two hours maximum.

Day 9, the comparison workshop, 2 hours. You put all six outputs side by side without saying who made what. You note what keeps coming up. The shared vocabulary shows up on its own here, because people have to name the differences in order to explain them.

Days 10 to 12, each person redoes their gesture applying what came out of the workshop. Second pass, two hours, and you keep both versions.

Artefacts: six version 1 outputs, six version 2 outputs, one page of vocabulary.

Days 13 to 20: the grid and the blind test

Day 13, you write the sign off grid. One page, no more. My usual five lines: skin and faces, light and directional consistency, geometry and continuity, sound, and how it holds up after mobile compression. Each line gets a binary threshold, pass or fail, never a score out of ten. A score out of ten gets negotiated. A fail does not.

Day 15, the blind test, and this is the most useful hour of the whole month. You mix four shots the team produced with two shots from an older project made without AI, and two you know are bad. Everyone fills the grid alone, on paper, in silence. Then you count the disagreements line by line.

Those disagreements tell you exactly what is left to teach. Five people out of six passing a shot whose lighting does not hold flags a gap in reading light, and that takes an hour of examples to fix.

Days 16 to 20, you go back over the two or three lines where disagreements cluster. One short session per line, 45 minutes, using examples pulled from the team's own work rather than from a catalogue.

Artefacts: the grid in version 1, the blind test tally, two or three documented targeted sessions.

Days 21 to 27: the client deliverable, for real

The team produces the deliverable picked on day 4, with AI, under real conditions. You touch nothing. You watch and you log the hours.

The rule I hold hard: the grid arbitrates, the senior does not. If a shot passes the grid, it ships. If the senior wants it out anyway, the grid has to change, not the decision. Otherwise you slide back to the old regime where one brain approves everything, and you have burned three weeks.

Watch the time spent on internal round trips, which usually spikes early. Count the thrown away generations, because they cost money. And listen for the exact moment someone says "let us just do it the old way, it will be faster". That moment is data in itself: note the time and the gesture involved.

On the contract side, what you promise the client about AI generated material belongs in writing before delivery, and I keep a client contract clause for AI-generated content ready for exactly that.

Days 28 to 30: measure and decide

Day 28, you record the same three numbers you took on day 2. Same definitions, same method, same file.

Day 29, you write two pages. Numbers before, numbers after, the three gestures that landed best, the two that did not, and your recommendation. Two pages, no forty slide deck.

Day 30, the decision meeting, 60 minutes, management in the room. Three possible outcomes and you pick one: extend to a second deliverable, stay on this scope and industrialise it, or drop this gesture. Dropping is an honourable outcome and it does happen. A gesture that gains nothing on a real deliverable will gain nothing at scale either.

The table I fill in on day 29

That table fits on one page, and it is the thing that circulates, not the two page write up.

What it really costs, in hours

I stopped pricing these programmes in euros, because the price depends entirely on who is teaching and how big the team is. In hours the structure holds steady from one company to the next, and the budget below is for a team of six.

Producing the deliverable on days 21 to 27 stays out of this budget, since it would have happened anyway. What matters is that these 92 to 100 hours get paid in one go, and they land while the team is already loaded. A team already maxed out on its schedule will not absorb them. Free the slots before day 1, or client emergencies will eat the programme around day 12.

💡 Frank's cut: block the slots in the shared calendar before the kickoff meeting, not after. A slot that was announced but never booked does not exist, and the first client emergency will prove it.

What counts as a measure under Article 4

The Commission published a repository of AI literacy practices, fed by two surveys, first among AI Pact pledgers and then among any interested organisation. It gathers more than forty initiatives, from e-learning platforms and in-person trainings to bootcamps and industry-academia collaborations.

Screenshot of the European Commission's repository of AI literacy practices, taken on 3 October 2026. It shows the forty plus listed initiatives, the two collection waves, and the opening of the warning about presumption of compliance.

One warning on that page deserves reading before you copy anything. The Commission writes that replicating the practices collected in the living repository does not automatically grant presumption of compliance with Article 4, the aim being to encourage learning and exchange between providers and deployers.

So lifting a large group's programme does not cover you. What counts is that your measures fit your context and your tools, and that you can show it.

The evidence I have teams build during the thirty days fits in one dated folder: the day 1 inventory with the list of tools and accounts, the sign off grid in its successive versions, the write ups of the day 16 to 20 sessions with attendance, the shared vocabulary page, and the day 30 decision record. It is light, it is dated, and it answers the question "what measures did you take".

The six ways to blow these 30 days

The most common one is training everybody at once. Six people discovering a tool together produce six opinions and zero standard, whereas starting with the two roles where the gain is most likely gives you a reference the others can copy.

Next comes the fake testing ground. An internal exercise with no client reveals nothing, because nobody is risking anything. A real deadline brings the actual problems up, in my experience around day 23.

The third trap is sneakier, since it comes from good intentions. The senior sees a shot they dislike, they reject it outside the grid, and within a week you have rebuilt the bottleneck you set out to remove. The team works out very fast that the grid is decorative, and they stop filling it seriously.

Skipping the baseline costs less at the time and far more on day 30, where the decision then gets argued on gut feel. Gut feel always sides with whoever talks loudest in the room.

There is also the pull towards scoring out of ten. A 6.5 average on a shot does not tell you whether it ships, while a binary fail forces whoever rejected it to name the line that blocks.

And the last one, the silliest: documenting nothing. Thirty days of serious work with no written trace is a loss for the next team and a hole in your Article 4 file.

Troubleshooting: what breaks along the way

The programme dies around day 12. Classic symptom, the slots were never booked and emergencies ate them. Fix: do not limp forward, push the whole thing back a week and rebook the slots. A programme that restarts in dribs and drabs never really restarts.

Blind test disagreements stay huge at the retest. Then the grid is too abstract. Swap qualitative criteria for physical observations: the direction of cast shadows, whether eye reflections match, how stable contours are between two consecutive frames. People agree on a shadow far more easily than on "it looks AI".

Two people move, four drop off. Usually the two moving were already using AI at home. Give them a role, keeping the vocabulary page for instance, and shrink the gesture for the other four. A gesture that is too broad is the most frequent cause of people checking out.

The client rejects the deliverable on day 26. It happens, and the programme survives it. Note the grid line that should have caught the problem, fix the grid, and keep the incident in the write up. A documented client rejection is worth more than an unexamined win.

Management wants a cost saving on day 30. The three measurements talk about time, not money, and that is on purpose. Turn the hours gained into capacity instead of savings: how many more deliverables per month at the same headcount. That conversation also sets up how you price the work afterwards, which I covered in how to sell AI videos to professional clients.

Nobody keeps the evidence file. Name a person on day 5, put their name in the kickoff record, and give them ten minutes a week. With no name on it, the folder does not exist on day 30.

FAQ

Foire aux questions

Réponses rapides aux questions les plus fréquentes sur cet article.

Why 30 days instead of a one day training?

A day passes on gestures, it does not change the process. Three weeks later the old sign off circuit has swallowed everything, because the quality criteria, the schedule and the arbitration habits never moved. Thirty days buy you three things a day cannot: measuring a starting point, putting a real client deliverable through the team, and measuring again at the end. The long format mostly exists to install the shared sign off grid, which is the one object that outlives the programme. Without it, everyone goes back to judging on feel and the senior becomes the bottleneck again.

What team size does this protocol fit?

Between three and eight people. Below three, the day 15 blind test loses its point, since tallying disagreements has no spread left at all. Above eight, the comparison workshops become unmanageable in two hours and the targeted sessions on days 16 to 20 turn into a lecture. For a larger company I run the protocol on a core of six who then become the reference group, and the other teams go through them. Running the programme in parallel across three groups produces three different grids, which is exactly the problem you were trying to solve.

Do you need a certificate to comply with Article 4?

No. The European Commission's FAQ on AI literacy, updated on 27 July 2026, says there is no one size fits all and that no strict requirements or mandatory trainings are imposed. The measures it lists stay broad: trainings, guidance, internal resources, human in the loop setups, documentation of what you did. Paragraph 1 of Article 4, in its July 2026 rewrite, also states that the duty does not require guaranteeing a specific level of AI literacy in any given individual. What is expected are measures that fit your context, your tools and the people involved, plus enough of a trail to account for them.

Who enforces the AI literacy duty, and since when?

National market surveillance authorities, and they have enforced Article 4 since 2 August 2026. The Commission's AI Office does not enforce this provision itself, unlike other parts of the regulation. The article itself has applied since 2 February 2025, which means the unsupervised window has closed but the duty already existed before that. Practically, a dated file built eighteen months ago carries more weight than a programme launched in a panic, and the documentation counts as much as the training.

How many working hours does this cost the team?

For six people I count 92 to 100 cumulative hours across the thirty days, excluding production of the deliverable that would have happened anyway. The big item is the double pass on the chosen gesture between days 6 and 12, around 24 hours, followed by the comparison workshop at 12 hours. That budget gets paid in one go and it lands during a normally busy stretch. A team already saturated on its schedule will not absorb it: free the slots in the shared calendar before the day 5 kickoff, or the programme dies around day 12.

What if the day 30 call comes out as a no-go?

You drop that gesture and keep everything else. A no-go means one specific gesture gains nothing on a real deliverable, and it will gain nothing more at scale. What survives, and this is the point, is the sign off grid, the vocabulary page, the numbered baseline and the evidence folder. All of it gets reused on another gesture next quarter, with a shorter protocol since the grid already exists. I have seen no-gos create more value than go decisions, because they killed a rollout nobody would have dared stop six months later.

How do you convince management expecting immediate savings?

By changing the unit. The three measurements talk about cycle time, working hours and rework rate, never euros. The gain translates into capacity, meaning how many more deliverables per month at the same headcount, and that is a more honest conversation than a promise of savings. Announce the entry cost at the kickoff too, the 92 to 100 hours, so nobody discovers the bill halfway through. Management that signed off on the cost up front accepts a measured result far better, including a modest one.

And day 31

By day 30 your team can judge, it has a grid, it has numbers to arbitrate with. Treating it as trained from there is the classic end of programme mistake: the skill holds through the next deliverables, not through the memory of the protocol.

So I keep two rituals after day 30, and only two. A 45 minute review every fortnight, where you run three approved outputs and one rejected one, adding or removing a grid line if needed. And a quarterly reading of the three measurements, in the same file as on day 2, to see whether the gain held or drifted away.

If you would rather do this alone, start with day 1: the inventory of AI tools already running in your company. What you find there will hand you half the programme.