Why most AI projects fail, and it is rarely the technology.
Ask a director why the AI project stalled and you will rarely hear "the model wasn't smart enough". You will hear: we couldn't get a grip on it, I had no time for it, or my people wouldn't take to it. Three reasons for failure, and none of them is technology.
A company enthusiastically starts an AI pilot: a smart assistant that pre-sorts applications. The first weeks are promising; it really saves time.
Then the organisation wants to go live with it. And the questions come. The accountant: "can you show why the system rejected this application?" IT: "where do those rules actually live, and who can access them?" The board: "who is responsible if this goes wrong?"
To each of those questions the answer is: we don't know exactly, it's inside the tool. The project doesn't go down with a bang. It dies quietly, in the drawer marked "needs looking into".
No answer to the control questions
The storyline above is failure reason one in action: the project dies on questions no one can answer.
The director has no time for it
Every change project demands your attention and that of your best people, exactly the people who are already fully booked. A months-long project with workshops and steering groups always loses out to the pressures of the day. Not because it is unimportant, but because it never becomes urgent enough to push everything else aside.
The organisation resists change
Your people have already had to learn three systems that were supposed to make work better. Adoption determines success, not the tool. If the new system mostly costs time for the people who are busiest already, the resistance isn't unwillingness but common sense.
It is not the technology that gets rejected. It is the lack of grip, time and support.
Why most AI tools fail this test
Most AI solutions are a black box with a subscription. They do something, often impressively, but you cannot show why. The rules are not yours, the logbook doesn't exist, and the knowledge about your own work disappears into someone else's system. For an experiment, that's fine. For a business process that clients and regulators rely on, it is the end of the road — exactly at the moment it gets serious.
How we avoid all three
Making it concrete with very little time
We ask you for two hours: a one-hour intake, and an hour to go through the demo live. Within 48 hours of the intake you see your own process working. No months-long project fighting for your calendar, but something working to decide on.
One internal champion
We work with one internal ambassador: someone who knows the process inside out and carries it internally. We support that person with everything he or she needs. That way support grows from within, instead of being imposed from above.
Keeping it simple, and flowing like water
One bounded process at a time, implemented along the path of least resistance: alongside your existing systems, at your pace, without a big bang. Because we know how much adoption matters. Your people recognise their own process, minus the routine work, and the first project shows internally that change can be enjoyable and fast.
How it does pass the inspection
Turn the order around. The rules of your process live in a model that is yours: readable, adjustable, under your own control. AI does the routine work within that frame, every step is logged automatically, and the decision stays with your specialist. Then the questions do have an answer: the system decided this, because that rule is right here; this is the logbook; this is what your team adjusts when the way of working changes. Governance stops being a brake and becomes the ticket in: the reason accountant, IT and board can say yes. If your IT lead or buyer has questions, forward them our piece with the eight questions IT and procurement ask.
Arjan van Unen — CMO, Model My Context