Zum Hauptinhalt springen
Kontakt
Enablement and change

You don't adopt AI by buying a licence

Tools are bought in an afternoon. The judgment to use them is built, and it is built per role: the person who signs doesn't need what the person who specifies needs, and neither needs what the person answering an auditor does.

Talk to the team See the material
We train
By role, not by template
Where
Inside real work
What remains
Evidence, not attendance

The gap isn't knowledge. It's judgment

Most teams have already used an assistant. What's missing is rarely how to write a prompt: it's knowing when the output is good enough, when to stop it, what must never be sent to a model, and who answers if it goes wrong. That doesn't transfer in a two-hour session, and an attendance certificate doesn't prove it.

A responsible-use policy sitting in a shared document isn't training. It's the intention to provide it.

How we do it

Three ways, and almost always all three

Standalone training is forgotten and training without context is never applied. So the usual answer isn't picking one, but combining them around a case the team actually has in front of them.

  • Training programme

    The catalogue itinerary, for teams that need common ground before touching anything. It is the closest thing to a course, and it is what delivers least on its own.

    • Common vocabulary and shared judgment
    • Adapted to the sector and the client's systems
    • A way in, not a destination

  • Inside the rollout

    The part that actually moves the needle. While something is being installed, the client's team works alongside ours on their own cases, their own data and their own constraints.

    • Learning on the real case, not on an example
    • Documentation and handover as part of the deliverable
    • The explicit goal is that you can carry on without us

  • Sessions and workshops

    Short format to unblock one specific group: a committee that has to decide, a legal team facing a new obligation, an area that doesn't know where to start.

    • Half a day or a full day
    • About a concrete decision, not about «AI» in general
    • Also open format, at our own events
By role

What each one has to be able to do

This table is the skeleton of the plan. It isn't a syllabus: it is what each role must be able to do by the end, and what proves it. The concrete content comes from your systems and your cases.

Role Has to be able to Proven by
Executive committee Ask what needs asking: which AI systems we use, which risk category they fall into, who can stop them and on what evidence. Minutes where those questions are on the record, with the name of who answers each one.
Legal and compliance Turn a regulatory obligation into a requirement an engineering team can implement, and recognise when a technical answer doesn't cover the obligation. The system inventory mapped to its risk category, and vendor contracts reviewed against it.
People Design and evidence AI training for staff who use or oversee it, proportional to their role. A record with date, content and attendees. Not a policy: the record that it was delivered.
Product and business Specify a case precisely enough to be built and evaluated, and decide when an output is good enough. Specifications with acceptance criteria and a metric agreed before starting.
Engineering Work with coding agents without lowering the bar: specify, review someone else's output, and catch the subtle failure the model misses. Reviews where real defects get caught, and tests shipped alongside what was generated.
Operations and support Live with a system that is right almost always: recognise the rare case, escalate it, and refuse a plausible answer as good enough. Escalation routes actually used, and cases returned with a reason.
The material

What we use is what we publish

There is no briefcase of sample material. What we put in front of a team is the same material that is published and signed, and that you can read right now without talking to anyone.

  • Briefings and whitepapers

    Ten published documents

    Sector reports and executive briefings, each with its author and its sources. They are the pre-reading behind almost any session.

  • Self-assessment

    AI readiness check

    Six questions and a radar by area. Used to open a conversation with a committee: it shows where the imbalance is before anyone argues about it.

  • Compliance

    AI Act checklist

    A step guide with the official sources, to work from the binding text rather than third-party summaries.

  • Vocabulary

    Glossary

    So a room stops arguing about words. More useful than it sounds in the first sessions.

  • Method

    Enterprise AI-SDLC

    How software is built and maintained with agents without losing control. The reference material for engineering training.

  • Direct query

    MCP server

    Our public knowledge base connected to Claude, ChatGPT or Cursor, no API key, read-only. A team can ask it instead of searching the web.

All of the above is public and free. If any of it solves your problem without hiring us, better.

How it starts

Four steps, and the first one is looking

A training plan written before knowing where the imbalance sits is a course catalogue. That's why the first step isn't training.

  1. Where you are

    What is used today — including what is used without permission —, who decides, and which obligations already apply to you. The output is a map, not a note.

  2. What's missing, per role

    On that map, what each role must be able to do and the real distance to get there. This is where you decide what doesn't need training at all.

  3. Train on real work

    Sessions are built on a live case of yours. By the end there is something that works, not an exercise.

  4. Leave the evidence

    A record of what was delivered, to whom and when, and what each team can now do. It is what you will be asked for, and the first thing missing when they ask.

Attendance is not a metric

Counting people trained measures what you spent, not what changed. What gets looked at is whether the work is done differently, and whether there is something to show when an outsider asks.

  • Work that wasn't done, or was done by hand, and now isn't
  • Decisions stopped in time because someone recognised the rare case
  • A training record that survives an auditor's question
  • Teams that stop depending on us for what they already know

Let's start with where you are

Tell us which teams will use it and what you already have running. The map comes out of that, and the plan out of the map.

Talk to the team