AI for Business: What It Can Do, What It Can't, and How to Tell

Most AI projects that fail do not fail because the technology did not work. They fail because nobody asked, at the start, whether the problem was one AI is good at.

This guide is about answering that question before you spend money.

What the technology is actually good at#

Strip away the framing and current AI is reliably strong at a specific set of jobs:

Turning messy input into structured output. Reading an email, an invoice or a form and pulling out the fields you need. This is unglamorous and it is where most of the realised value sits.

Summarising and rewriting. Long document to short summary. Technical note to plain English. Notes to a draft.

Classifying. Which department does this belong to? Is this urgent? Which of these twelve categories fits?

Drafting a first version. Test cases from a requirement, a reply from a template plus context, documentation from code. A human still approves.

Finding things by meaning. Search that works when the user's words differ from the document's words.

Notice the pattern: tasks where a competent person could do it, it takes them a while, and a mistake is visible and correctable. That is the zone.

Where it reliably fails#

Anything requiring guaranteed correctness with no human check. Language models produce the most plausible continuation, not the true one. They are confident when wrong — that is the property that causes damage, because confidence is what people use to judge reliability.

Arithmetic and precise data operations at scale. A database does this perfectly and cheaply. Do not use a model where a query works.

Knowing your specific facts. A general model has never seen your policies, prices or customers. Ask it about them and it will invent something reasonable. Fixing this means supplying the facts — see RAG — not hoping the model knows.

Judgement calls with real accountability. Hiring, credit, medical, legal, disciplinary. Not mainly a capability question — a question of who is answerable, and often a regulatory one.

Anything where the rules never change. If the steps are always identical, write the code. It is cheaper, faster and correct every time.

The four questions#

Before any AI project, get honest answers to these. They kill bad ideas cheaply.

1. What decision or task changes? If you cannot name the specific thing someone does differently on Tuesday, you have a technology in search of a problem.

2. How will we know it worked? A number, measured now, that should move. "Better customer experience" is not measurable. "Average first-response time, currently 9 hours" is.

3. What happens when it is wrong? Not if. This determines your entire design: whether you need human approval, how much you can automate, and whether the project is viable at all.

4. Where does the information live? If the answer is "in people's heads" or "in an inbox", that is the project. AI cannot read what is not written down.

Projects that stall almost always failed one of these at the start, and nobody asked.

Build, buy, or use what you have#

Roughly in order of cost:

Use the AI already in your existing tools. Your helpdesk, office suite and CRM increasingly include it. Zero integration, no project.

Buy a specialist product. Someone has already solved document processing, meeting notes, or support triage for your industry. Almost always cheaper than building.

Build on a model API. Justified when the problem is specific to how your business works, and you have the data and people to do it.

Train your own model. Almost never right. Reserve it for cases where a general model genuinely cannot do the job and you have very large volumes of proprietary data.

Most organisations should exhaust the first two before considering the third. The instinct to build is usually about wanting to own the capability rather than about economics.

What it costs, honestly#

The model is rarely the expensive part. For typical business volumes, API costs are modest.

The real costs are: getting your data into usable shape (usually the largest line), integration into the systems people already use, evaluation — proving it works and continues to work — and change management, because a tool people do not trust does not get used.

Budget on the assumption that the AI is roughly a quarter of the work.

Governance without bureaucracy#

Four things, appropriate for almost any organisation:

• A named owner for each AI system who is accountable for its behaviour
• A written statement of what it does and does not decide
• A log of inputs and outputs for anything consequential, so you can answer "why did it do that?"
• A person who can switch it off, and clarity about who that is

That is enough to start. Elaborate frameworks written before you have a system in production tend to describe a company you do not have.

What the rules now require#

Two developments changed the picture in 2026, and the first one is already in force.

EU AI Act transparency obligations applied from 2 August 2026. Article 50 requires that people are told when they are interacting with an AI system, and that AI-generated content is labelled. This applies now, and it applies to ordinary chatbots and content generation — not only to the systems the Act classifies as high-risk. If you operate an AI assistant reachable by EU users and it does not disclose what it is, that is a live gap rather than a future one.

High-risk obligations were deferred. The Digital Omnibus package, given final approval by the Council on 29 June 2026, moved the compliance deadline for stand-alone high-risk systems under Annex III from 2 August 2026 to 2 December 2027, with product-embedded systems under Annex I moving to 2 August 2028. High-risk covers areas such as employment, credit scoring, insurance, education, critical infrastructure and biometric identification.

The practical reading: you have more time for the heavy conformity work, and none at all for transparency. Organisations that treat the deferral as "AI regulation was postponed" are misreading it.

For a management framework, two are becoming procurement expectations rather than nice-to-haves: ISO/IEC 42001:2023, the AI management system standard, and the NIST AI Risk Management Framework. They are complementary — the NIST framework supplies the risk methodology and vocabulary, ISO/IEC 42001 supplies the certifiable management system. A common sequence is NIST first to establish the discipline, then ISO/IEC 42001 certification once the documentation exists. ISO/IEC 42001 increasingly appears in enterprise due-diligence questionnaires, which is usually what makes it urgent.

This is general information, not legal advice. Obligations depend on your role — provider, deployer, importer — and on where your users are. Take advice on your specific position.

A sensible first project#

Pick something high-volume, tedious, and verifiable. Document extraction, support triage, first-draft generation.

Run it in parallel with the current process for a few weeks: the AI produces its answer, people do what they always did, and you compare. This is the cheapest way to learn what it gets wrong and builds trust with the people who will use it.

Then automate the cases where it is reliably right, and route the rest to a person. Almost all realised value comes from that split — not from replacing the whole process.

FAQ#

Will AI replace our staff?#

In practice it changes what people spend time on more than headcount. The tasks it does well are the tedious, high-volume, verifiable ones — which people are usually glad to hand over. Treat any vendor promising specific headcount reduction as making a claim about your organisation they cannot know.

Is our data safe if we use AI tools?#

Depends on the service and the plan. Business tiers typically exclude your data from training; consumer tiers often do not. Read the terms, choose an approved tool, and tell staff which one — the realistic alternative to an approved tool is people using consumer accounts you cannot see.

How accurate is it?#

The wrong question, because accuracy depends entirely on the task. Structured extraction from clean documents can be very reliable. Open-ended questions about your business, with no supplied context, can be close to worthless. Measure on your task with your data; benchmark numbers tell you little.

Do we need a data scientist?#

For using existing models through an API, usually not — this is software engineering plus domain knowledge. You need data science when you are building custom models, which most organisations should not start with.

How long before we see value?#

For a scoped, well-chosen problem, weeks. Projects that run for a year without producing anything are almost always projects where the four questions above were never answered.

What is the most common mistake?#

Starting with the technology instead of the task. The second most common is having no way to measure whether it worked, which means the project cannot be defended when someone asks.

Should we wait for the technology to mature?#

The capabilities keep improving, but the work that takes time — getting data usable, integrating, building trust — is the same regardless of model generation, and it transfers. Starting small now means you are ready; waiting means starting the slow part later.

What else is coming for AI