Why Use AI?

Most conversations about AI start in the wrong place. They start with the technology, then go looking for a problem to point it at. That order produces impressive demos and disappointing projects.

The better question is narrower. Where in your business does someone read something, decide something, and write something, over and over, in a way that is important but not quite important enough to hire for? That is where AI earns its keep. Everything else is worth a longer look.

What the technology is actually good at

Strip away the marketing and a large language model does a few things unusually well.

It reads unstructured text and turns it into structure. Emails, PDFs, support tickets, contracts, meeting notes, CVs, invoices. Anything a person currently opens, skims, and retypes into a system. This is the least glamorous use of AI and consistently the most profitable.

It answers questions from a body of documents. Not from general knowledge, which is where the horror stories come from, but from your documents, with references back to the source. Onboarding material, policy libraries, technical documentation, historical project records.

It drafts. First drafts of replies, summaries, reports, descriptions. A person still reviews and sends. The saving is in going from a blank page to a good enough starting point.

It classifies and routes. Which team should see this ticket, is this review positive, does this application meet the basic criteria, is this transaction unusual. Rules based systems handle the clear cases; a model handles the messy middle that used to need a human.

It writes and reviews code. Genuinely, and at a level that has changed how development teams work over the past two years.

What it is bad at, and what that costs

Being clear eyed about the limits is what separates a project that ships from one that gets quietly shelved.

It does not know things reliably. A model produces plausible text, and plausible is not the same as correct. Ask it a factual question outside the context you gave it and you may get a confident, well written, wrong answer. The fix is architectural: give the model the source material and require it to cite. It is not a prompt you can write your way out of.

It is not deterministic. The same input can give slightly different output. For drafting, that is fine. For anything where the same input must always produce the same result, such as pricing, compliance decisions or financial calculations, put the logic in code and let the model handle only the parts that genuinely need judgement.

It cannot be held accountable. If a decision needs an owner, a person owns it. AI can prepare the decision, gather the evidence and recommend an answer. Someone still signs.

It has a running cost. Every request costs money. Small per request, real at volume. A workflow that runs a thousand times a day needs the arithmetic done before it is built, not after.

Where the money actually is

Three patterns come up again and again in real deployments, in rough order of how quickly they pay back.

Removing manual data entry

Someone opens a document, reads it, and types the contents into a system. Invoices into accounts, orders into an ERP, applications into a CRM. This is high volume, low judgement, and error prone precisely because it is boring. It is also easy to measure: count the documents, count the minutes, do the sum.

The return here is unusually clean because you are replacing a task nobody wanted to do, and errors are catchable by validating against the systems you already have.

Making internal knowledge findable

Every organisation past a certain size has knowledge locked in documents nobody can find. New staff ask the same questions for months. Experienced staff get interrupted answering them. The documentation exists but the search does not work.

A retrieval system over your own documents fixes the search problem rather than the documentation problem, which is usually the cheaper of the two. The measurable outcome is time to competence for new hires and fewer interruptions for senior people.

Triaging the inbox, whatever the inbox is

Support tickets, sales enquiries, maintenance requests, job applications. Anything that arrives as a queue and needs sorting before it can be worked. Classification and routing are among the most reliable things a model does, and the failure mode is mild: a misrouted item gets rerouted.

Where it usually disappoints

In fairness, the same honesty applies in the other direction.

Low volume, high stakes decisions. If something happens twice a month and matters enormously, the review effort will consume the saving. Let people do it.

Work that is already automated. If a rules based system handles it correctly today, replacing that with a model makes it slower, more expensive and less predictable. Non determinism is a cost, not a feature.

Anything where the process is undefined. If two people in your organisation do the same task in two different ways and disagree about which is right, AI will not settle that. Define the process first. Sometimes writing the specification is enough to fix the problem without any software at all.

Chatbots as a first project. An open ended conversational interface is one of the harder things to get right and one of the most visible when it fails. It is a poor place to learn. Start with something internal, bounded, and measurable.

How to evaluate a candidate use case

Five questions, in this order.

1. How often does it happen? Under a few times a week, the payback is unlikely to be there. Daily or hourly is where it gets interesting.

2. What does a wrong answer cost? If the answer is "nothing much, someone spots it", you can move quickly. If it is "regulatory exposure", you need a review step, and that review step needs to be in the budget.

3. Can you tell right from wrong? This is the question people skip. If you cannot evaluate the output, you cannot improve the system and you will not know when it degrades. No evaluation, no project.

4. Does the data exist and can you reach it? Most AI projects that stall stall on data access, not on models. The documents are in someone's inbox, the system has no API, the records contradict each other.

5. What is the manual baseline? Know what the task costs today, in hours and in errors. Without that number you cannot prove the project worked.

Build, buy, or wait

Buy when the problem is generic. Transcription, translation, document signing, meeting notes. Someone has solved it, solved it well, and will sell it for less than you can build it.

Build when the value comes from your own data or your own process. A tool that understands your product catalogue, your policies, your workflow. Nobody sells that, because it only exists inside your business.

Wait when the honest answer to any of the five questions above is "we do not know yet". Spending a fortnight defining the process and gathering example data is not a delay. It is the project.

What a sensible first project looks like

Narrow. Internal. Measurable. One workflow, one team, one number that goes up or down.

Run it alongside the manual process rather than replacing it. Compare the outputs for a few weeks. You will learn more about your own process in that fortnight than in six months of planning, and you will have real evidence before anything depends on the system.

Then expand into the second use case, which will go faster because the plumbing already exists. Most of the work in an AI project is not the AI. It is the integrations, the access, the evaluation and the interface. That work carries over.

The honest summary

AI is not transformative for every business, and the companies that say otherwise are selling something. It is very good at a specific class of problem: high volume, text heavy, judgement light work where a wrong answer is recoverable. If you have that kind of work, and most organisations do, the payback is real and quick.

If you are trying to work out which category your problem falls into, or you have a use case in mind and want a straight assessment before committing budget, get in touch with Eight Mile. Custom software, AI assistants, RAG systems, workflow automation and technical consultancy are the work we do, and we would rather tell you a project is a bad idea early than build it anyway.