Where AI earns its place in an operation, and where it does not
The useful question is not what AI can do. It is which decisions an organisation is willing to be accountable for without a person having made them.
Written for executives deciding where to apply ai, and the people who will carry the consequences.
Start from the consequence, not the capability
Most AI programmes begin with a capability looking for a process. The ones that survive contact with an operation begin somewhere less exciting: a piece of repetitive work that is expensive, high volume and low consequence when it goes wrong.
That framing sorts the candidates quickly. Classifying an inbound enquiry, extracting fields from a document, summarising a long thread, drafting a reply for a person to approve: these are high volume, and a mistake is visible and cheap to correct.
The line we hold
Anything financial, contractual or customer-facing keeps a person deciding, and the system keeps a record of what it recommended and what the person did. That is not caution for its own sake. It is what makes the decision defensible six months later when somebody asks why it was made.
- Automate the work, not the accountability. A system can prepare a decision. Someone still owns it.
- Record what the system did. An action with no audit trail is an action nobody can stand behind.
- Design the failure case first. What happens when the model is confident and wrong is the design question that matters.
- Keep a person in the path where the consequence is money, a contract or a customer relationship.
The unglamorous prerequisite
AI applied to fragmented data produces confident answers drawn from records that disagree. If the same customer exists three times, a model asked about that customer will be wrong in a way that is harder to notice than a wrong spreadsheet, because it will be fluent.
This is why the AI conversation and the integration conversation are the same conversation. One authoritative record per piece of data is not a precondition somebody invented to slow the project down. It is the difference between automation that compounds and automation that quietly multiplies an existing error.
What good looks like
A narrow, well-chosen application, running on data the organisation trusts, with a person at the point of consequence and a record of every decision the system took part in. It will look less impressive in a demonstration than the version that promises to run the department, and it will still be running in two years.