When AI has no business being in your company

“We need to do something with AI” is a symptom

The sentence “we need to do something with AI” is almost never a brief. Someone read a report on a Sunday. Someone else came back from a trade fair where a competitor talked about their assistant. The board asked what the company is doing about it, and now there has to be an answer by the next meeting.

That pressure is understandable. Before anyone spends money, turn it into a brief.

A brief sounds like this: our bookkeeper opens a scanned supplier invoice, reads four numbers off it, types them into another window, checks them against the order, and does that a hundred and fifty times a month. Or like this: two people in customer service answer the same question about delivery status every day, because the shop never tells the customer where the parcel is. Both sentences contain a process, a volume and a cost of getting it wrong. All three can be counted before anybody picks a technology.

If nobody in the company can finish the sentence “we want AI to do…”, what you have so far is an agenda item. Better to find that out early, because an agenda item costs an hour and an implementation with no process behind it costs a quarter.

Three conditions and one if statement beat a model that is right almost every time

assessment sessions recorded on the psychometric platform

1,324

certificates issued on the training platform

899

A language model is probabilistic. Ask it the same question twice and you can get two different answers, both of which sound reasonable. It was designed that way, and no amount of money washes it out.

Ordinary software fails loudly: an exception, a line in the log, an alert at three in the morning. A model fails quietly and politely. It writes 12,400 where the invoice said 124.00, with exactly the confidence it had for the hundred amounts it got right, and nothing anywhere turns red. You find out when the balance stops matching.

Anywhere the result has to be identical every time, I write a rule.

I built a psychometric platform that now has 1,324 assessment sessions recorded in production. Five traits, some items scored in reverse, raw totals converted into percentiles against one company’s norms, and a recommendation attached to a named role at the end. That number affects whether somebody gets a job. Nobody sane wants it produced by something that is right most of the time. It has to be arithmetic you can put in front of the candidate, a lawyer and an audit, and it has to return the same score for the same answers in session one and in session 1,324. The same goes for the training platform I run for a law firm: 899 certificates issued, every one of them verifiable when an HR audit asks.

I run Google Ads campaigns for clients, and every account I manage has one rule they ask about: a separate controller beside the model holds the daily spending ceiling and checks it before every change. Automation may pause a campaign or lower a bid. Raising a limit is a person’s decision, and it goes on record. Money leaving an account has to be repeatable and checkable to the last cent, whatever tool moves it. The same logic covers invoices, stock levels, issued documents and anything somebody will one day have to defend in front of somebody else.

Hence the question I ask about every proposal: can this decision be written as three conditions? If it can, write it as three conditions. It will be cheaper, faster, testable, and nobody will break it on a Monday morning with a version change on the other side of the internet.

Where an AI implementation does earn its keep

A model belongs where the input is a mess and more than one answer is correct. Three shapes of work where it holds up.

The first: the input is human text, or a document with no fixed layout. A supplier invoice arrives in the inbox as a scan, and every supplier has their own template and their own opinion about where the order number goes. Writing rules for every variant costs more than a model that reads the fields. Notice where its job ends, though: the system reads the fields, checks them against the order, updates the CRM and routes mismatches to a person for approval. Only the reading goes to the model, because that is the one step with endless variety in it. The check against the order is ordinary code.

The second: the output is a draft that somebody edits anyway. Ad copy variants, a first pass at a reply, a product description that gets read before it goes live. A mistake here costs the price of deleting a paragraph.

The third: matching by meaning. For dotlaw, a law firm, I built search across the firm’s own magazine on a vector index in Postgres, answering only from material that firm has published itself. A question asked in a client’s words finds an article written in a lawyer’s. Keyword search cannot do that, because the client does not know the words to search for.

The cleanest split is in my own product. ShieldWave checks eight areas of a website and turns what it finds into a report in about a minute and a half. The tests themselves are ordinary deterministic code: the header is either there or it is not. The model comes in at the end, where a list of findings has to become sentences a business owner can act on without a translator. I own and operate that product, so every decision inside it is billed to me.

The expensive mistake happens before you buy anything

It usually happens a quarter before any purchase, at the moment somebody agrees to automate a process that nobody has read end to end.

Automation copies the process as it finds it, oddities included.

The exception that one person in accounts always handled with a single phone call becomes a branch nobody programmed, so it comes back as an error once a week. The step that exists only because somebody who left in 2019 liked having their own copy of the spreadsheet now has a maintenance budget and an owner. The field retyped by hand between two systems goes on being retyped, faster and on a subscription.

What comes afterwards is worse. An automated process is harder to change than the same process done by hand, because an integration, a prompt, two reports and somebody’s board slide depend on it now. From then on, questioning it costs political capital as well as work.

Some steps are better deleted

Before automating a step, check whether anyone needs it.

The report that goes out every Monday and that nobody opens. Check who opened it last quarter; your analytics already knows. The approval nobody has ever refused, which in practice is a delay with a signature on it. Double entry of the same data into the shop and into the warehouse, which is an integration problem: on one store I run, catalogue and stock move through BaseLinker, with no intelligence involved.

A deleted step costs nothing from then on. An automated one brings a monthly bill and needs somebody who still understands it two years later.

What an AI audit looks like, and why it is cheaper than a pilot

Every implementation I do runs in the same order.

1. Pick one process with a clear stake: time, volume, cost of error or customer experience.
2. Map the data, tools, decisions and exceptions before choosing a model.
3. Build a small production flow: input, context, action, a human in the loop and a quality measure.
4. Test on real examples, and extend only once the base flow works.

The second point matters most, together with the word “real” in the fourth. Real examples means your documents from last month: the scan that is four degrees crooked, the typo in a company name, the one invoice that arrived in another currency. A vendor demo runs on clean data, picked to make it look good.

An audit can also end like this: no model needed here, one integration and two steps removed. If every audit a supplier runs ends with a model to buy, ask them what they measured.

Starting from the model is more fun than a conversation about why somebody has been retyping four numbers by hand for three years. That conversation costs less, and whether the project works depends on it.

Five questions that ruin a bad AI proposal

What happens when the model is wrong, and who sees it first? If the answer is that it is not wrong, you can end the meeting there.

Which examples did you measure quality on, and can I see the ones where it failed? A supplier who measured will have the failures to hand.

Which part of this could be a plain condition in code? A good supplier will point at two or three themselves.

What does this cost at ten times the volume? A model bills per call, and a pilot on a hundred documents a month reads differently once the whole flow goes through it.

What happens on the Monday when the vendor changes the model version, or the API stops responding? “We switch to another one” is only a good answer if somebody has already rehearsed it.

Where to start with AI in your company

Take one process, the one everybody in the company complains about, and write it down step by step with numbers: how many times a month, how many minutes, who corrects whose work, and what happens when the data does not match. That sheet of paper is worth more than an AI strategy and it takes an afternoon.

Then count how many steps on it require any thinking at all. Usually it is one, sometimes two. The rest is moving data from one place to another, and an integration handles that.

Depending on what the sheet shows, do one of two things.

One process, and you already know which one. Describe it in the brief with the numbers from your sheet: how often, how many minutes, who corrects whom.

You are not sure there is anything worth automating yet. Write anyway, through the same brief or through contact. Of all the questions in this article, that one is the cheapest to answer. How the audit and the build run, step by step, is on the AI implementation page.

Frequently asked questions