The pilot went well. That is usually where the problem starts.
A small team, a clear use case, people who wanted to be part of it. After eight weeks there is a result worth showing. Then comes the roll-out across the organisation – and suddenly nothing happens. The licences are bought, the training has run, and after three weeks usage falls back to where it was before.
The usual reflex is to switch models. In my experience it is almost never the model.
A pilot tests the technology. It never tests the organisation.
That is the design flaw. A pilot team consists of volunteers working under conditions that exist nowhere else: high motivation, a direct line to the project, mistakes without consequences, time to experiment. None of that survives the roll-out. What decides things in day-to-day operation are four questions nobody had to ask during the pilot.
Which task exactly? “We are using AI in customer service” is not a use case, it is a statement of intent. A use case names a step in the work that a person does today and says what is different afterwards.
Who is accountable for the result? As soon as a system prepares decisions, responsibility shifts without anyone having redistributed it. That is precisely what we examined for the connected factory: we developed a matrix of services with the corporate functions responsible for each, and found that IT takes a central role while production-related services remain dependent on operational technology – and that new digital OT functions emerge at the interface which simply did not exist before. The setting was the smart factory. The pattern is the same everywhere: clarify responsibilities before the system goes live, not after.(source)
What does the manager model? Anyone who does not work with the tool themselves cannot credibly explain to their team why it should.
Which rules apply? What may go in, what may not, who checks the output, what happens when it is wrong. Without an answer everyone decides for themselves – and the cautious decide against using it.
Adoption is leadership work, not training
In a systematic review of leader traits in digital environments we found that the classic traits still count. But adaptability, communication skills, social and emotional abilities as well as change, coaching and trust competencies gain weight.(source)
That is a statement about leadership in digital settings in general, not a finding about AI. But the conclusion is close enough to say out loud: when technology comes between people and their work, the bottleneck moves from the technology to the support around it. A training calendar does not solve that.
Data protection and co-determination are design parameters
In many projects data protection and the works council come at the end – as a review you either pass or fail. That is expensive, because you then build twice.
My position: these requirements are design parameters, not obstacles. Involving the works council early gets you more than an approval; it gets you information – namely which kind of use the workforce will support. You would have needed that information anyway, only later and under more pressure.
An example from my own work
In the GameLOAP sub-project I developed online learning formats with a language-model integration and brought them into live teaching. The technology was the smaller half. The larger one was: how does the format fit into ongoing teaching? Who supports students when the model answers something unexpected? What happens if it fails? Only once those questions were answered had a working prototype become something you can actually deploy.(source)
Five questions that should be answered before the roll-out
- Which step in the work does the system replace or support – and what does the person do instead?
- Who is accountable for the result once the system has prepared it?
- How will we know in three months whether it is being used – and what do we do if it is not?
- Which rules on data, review and errors apply, and who helped decide them?
- Who in the leadership team visibly works with it themselves?
None of these questions is technical. If they go unanswered, the adoption does not fail because of the model but because of the organisation – and you only notice once the pilot is long over.