Why your first AI project should be boring

There’s a predictable shape to how a company’s first AI project goes wrong.

Someone senior sees a demo. It’s genuinely impressive. A budget appears, a working group forms, and six months later there’s a half-finished system that nobody in the business trusts enough to use. The project is quietly reclassified as a learning exercise, and the organisation concludes AI doesn’t work for them.

What actually happened is that they picked the wrong first project.

Impressive and valuable are different axes

The demos that sell AI internally are the ones that look like magic — the agent that plans the whole campaign, the system that reads the contract and negotiates it. Those are real capabilities and some of them will eventually be worth building.

But a first project has a job beyond its own return: it has to establish that this kind of work can be trusted. And trust is built by shipping something small that works every single time, not something large that works impressively most of the time.

A system that saves four hours a week and has never once been wrong will get you funded for the next thing. A system that saves forty hours a week and produces a serious error in month two will get the whole programme paused.

What “boring” tends to look like

The unglamorous candidates share a few features. The task is high-volume and low-variance. The output is easy to check. Failure is visible immediately rather than three months later. And a person could do it correctly — it’s just tedious.

In practice that means things like inbound enquiries being classified, enriched and routed. Invoice data extracted and reconciled. A monthly report that someone currently assembles by hand from six sources. Support tickets triaged and drafted for human approval. Meeting notes turned into CRM updates and follow-up tasks.

None of these will get written up in a trade magazine. All of them save real hours, and all of them are testable — you can run last quarter’s data through and count exactly how often the system agreed with what your team actually did.

The compounding effects nobody plans for

Boring first projects produce three things that turn out to matter more than the hours saved.

A working integration layer. By the time you’ve automated enquiry routing, you’ve authenticated against your CRM, your email and your data warehouse, and you’ve built somewhere for automations to run and be monitored. The second project starts from there instead of from nothing.

Calibrated expectations. Your team learns where these systems are strong and where they need watching. That knowledge is only obtainable by shipping something and living with it. Getting it on a low-stakes project is much cheaper than getting it on a high-stakes one.

Internal credibility. The colleague who was sceptical now has four hours a week back. They’re the one who suggests the next candidate, and they’ll defend the budget in a way no external consultant can.

The test to apply

Before committing to a first project, three questions.

Can you tell within a week whether it’s working? If the feedback loop is a quarter long, you’ll be a quarter deep before you know it failed.

Can you check the output without specialist effort? If verifying the answer costs as much as producing it, the automation isn’t saving anything.

If it fails on a Tuesday, what happens? If the answer involves a customer, a regulator or a payment, this is not a first project. Make it the third.

Then do the interesting thing

None of this is an argument against ambition. The agent that handles the whole support queue end to end, the retrieval system that makes ten years of institutional knowledge answerable — those are the projects worth the investment, and they’re where the durable advantage sits.

They’re just very hard to land as a first attempt in an organisation with no track record of landing them. Earn the right to attempt them. It usually takes one quarter and one dull, reliable, unexciting system that quietly works.