Why an AI scan is not an IT project

An AI scan is almost always handed to IT, and that is the first mistake, before any tool has even been chosen. Not because IT could not understand it. Because the questions an AI scan answers are not IT questions.

Which work currently costs the most hours without adding value. Which customer question takes too long to answer. Where does a good employee get stuck on something no person should be doing. None of those questions sit in a systems administration manual. They sit in the owner's head, and nowhere else.

Why this happens, and why it feels logical

It is not a stupid mistake. AI sounds like technology, technology belongs with IT, so AI belongs with IT. That reasoning is intuitive and it is wrong, for the same reason a marketing strategy does not belong with IT even though the website runs on a server.

The consequence of this misallocation is predictable. IT gets a budget and a deadline, and goes looking for a tool that "does AI". A pilot starts on a process IT knows, usually something in its own systems, and not on the process the company suffers most from, because IT does not know that process from the inside. Six months later there is a working system nobody asked for that does not touch the real problem.

A meeting around a conference table. Only the owner sees across every department at once.

The difference between an IT project and an organisation project

An IT project has a clear specification: this system has to talk to that system, this data has to go there. The outcome is measurable in technical terms: does it work, is it fast enough, is it secure.

An AI scan has no specification until someone has decided which problem is worth solving. That decision needs someone who sees the whole company: where time leaks away, where a customer waits too long, where good staff get stuck on work beneath them. In most companies of fifty to three hundred and fifty people, exactly one person has that overview: the owner or the director.

That is not because owners know better than their staff about everything. It is because they are the only ones looking across every department, while IT, sales and operations each only see their own piece.

The two approaches side by side, to make the difference concrete.

The right-hand column is not more expensive to choose. It is the same steps in a different order: the problem first, the system only after.

What goes wrong when IT takes it over

Three patterns we see over and over.

The pilot solves the wrong problem. IT picks a process it has control over, usually something technical like ticket handling or internal reporting. That is rarely the process costing the company most. The real bottleneck more often sits in customer service, planning or administration, departments IT does not talk to daily.

Nobody checks whether it delivers anything. A technically successful project, the system runs, it does not crash, gets celebrated internally as a success, while nobody measured whether it saved the director's time or improved customer satisfaction. Technology and value are two different measurements, and the first does not replace the second.

The project gets no owner outside IT. The moment the project is done, attention moves back to the next sprint. Without someone accountable for the outcome in day-to-day operations, an AI application dies a slow death of maintenance that never happens.

Server cooling fans. A technically successful project is not the same as a valuable one.

A concrete example of how it goes wrong

A mid-sized manufacturing company decides to "get started with AI" and hands it to IT. IT picks, logically from its position, the internal ticketing system as the first trial: a chatbot answering common IT questions. After three months the bot works, the helpdesk gets slightly fewer tickets, and the project gets presented internally as a successful first step.

Meanwhile, scheduling the production line still costs a planner two hours a day done from memory, because nobody ever asked IT that question and IT did not know it existed either. The company has adopted AI, and its most expensive problem has not moved an inch.

This is not a badly thought-out project. Every step in it was logical from the perspective of whoever took it. The problem sat in the first step: who decided which problem was worth solving.

Why this is also a question of mandate

There is another reason this belongs with the owner, and it goes beyond overview alone: the mandate to change something.

An IT department can implement a tool. An IT department can rarely change a work process that crosses departmental lines, because that requires a decision touching sales, operations and administration all at once. If the planner in the example above has to change how they work, that is a decision only someone with authority over that department can make and carry through resistance.

Without that mandate, even a technically perfect project ends up in a drawer. Nobody can enforce the change in the actual work, so in practice nothing changes, even though the system runs.

What we do differently, and why it works

We always start a scan with a conversation with the owner or director, not the IT manager. Not because IT does not belong, but because the first conversation is about priorities, not systems. Where does the most time leak away. What does it cost the company if that continues another year. What would the director themselves most like off their plate.

That conversation produces something a technical intake never does: a ranking of problems based on what matters to the company, not on what is easiest to build. See also our page on what an AI Readiness Scan actually involves and how that ranking comes about.

The worked example on our own scan page shows where that leads: 1,200 hours of manual work a year, a saving of 68,000 euro, paid back within three months. That is an illustrative worked example on our own page, not a promise for every company, but it shows the kind of number that comes out when you start with the problem instead of the system.

Where IT is genuinely indispensable

Nothing in this piece argues for leaving IT out. Once the problem is chosen and the direction is set, IT becomes indispensable: which systems hold the data needed, what is technically possible, where is a risk to the existing infrastructure. Only IT can answer those questions well, and an organisation project that skips them gets stuck just as hard as an IT project that starts with the owner.

The order is the point, not the exclusion. First the owner for the problem and the priority, then IT for feasibility and execution. It does not work the other way round, because then feasibility decides which problem gets solved instead of the reverse.

The question that makes the difference

When you talk to a vendor, ask this one question before any technology comes up: who in our company do you want to speak to first?

If the answer is "your IT department", you get an IT project with an AI layer on top. If the answer is "the owner, and then everyone who actually does the work", you get an organisation project where technology is a means, not an end.

That distinction costs no money to make. It costs an hour-long conversation before anything is signed.

What you can do yourself before requesting a scan

Make your own list of three things that frustrate you most, as owner or director, about how the company runs today. No technical wishes, just frustrations: something that takes too long, something that goes wrong too often, something where good staff are wasted on work beneath them.

Put that list next to every quote you receive. A party that starts by asking for that list understands the difference between an IT project and an organisation project. A party that starts with a product demo does not.

About this page

The worked example of 1,200 hours and 68,000 euro comes from our own AI Readiness Scan page and is an illustrative calculation, not an average or guaranteed result. This is the state of play on 17 August 2026.