AI automation for business: where to start

Most conversations about AI in a company start at the wrong end: with a model, a tool or a vendor, and then a search for a problem to attach it to. The result is usually a pilot that impresses in a demo and quietly stops being used a few weeks later.

The useful conversation starts somewhere less exciting. Not "where can we use AI?", but "where is a person currently acting as the glue between two systems?" This guide walks through how to answer that question, which processes to automate first, and how to run a first project that reaches production.

What AI automation is, and what it is not

Classic automation follows rules: when a form is submitted, create a record; when an invoice is paid, send a receipt. It works well when the input is structured and the steps never change.

AI automation covers the work rules could never handle: reading an email and deciding what it is about, pulling the right fields out of a PDF that looks slightly different every time, answering a question from internal documents, or drafting a reply that a person approves. It is automation applied to work that used to require judgement.

What it is not: a replacement for accountability. A well-designed system takes over the repetitive part of a task and leaves the decisions that matter, and the exceptions, with people.

The processes worth automating first

In almost every company, the best candidates are unglamorous:

• Document intake: invoices, purchase orders, delivery notes, contracts and forms that arrive by email and get typed into another system.
• Email and support triage: reading incoming messages, classifying them, routing them to the right person and drafting a first answer.
• Lead qualification: enriching enquiries, checking fit and passing the good ones to sales with a summary.
• Data entry between systems: copying the same information from a CRM to an ERP to a spreadsheet.
• Internal knowledge: answering staff questions from policies, procedures and past projects, with a link to the source.
• Reporting: turning raw data and notes into a weekly summary someone currently writes by hand.

A quick test for any candidate process

Before investing in a process, check it against five questions. The more "yes" answers, the better the candidate:

• Does it happen at least every week, ideally every day?
• Does the input arrive in a recognisable shape, even if the format varies?
• Is a person mostly reading, copying or routing, rather than negotiating or creating?
• Can a wrong result be caught and corrected before it causes damage?
• Can you measure what the process costs today, in hours, delays or errors?

Estimate the value before you build anything

The simplest estimate is volume multiplied by time. As an example: a team that handles 400 documents a month at six minutes each spends 40 hours a month on that step alone. Add the cost of errors and the value of answering faster, and you have a number to compare against the cost of building and running a system.

This estimate also tells you when not to automate. A process that takes two hours a month is rarely worth a project, however elegant the solution would be.

Design for the cases it gets wrong

A system that is right most of the time is either very valuable or quietly dangerous, and the difference lies in how it handles the rest. The systems that survive in production share a few properties:

• They cite their sources, so a person can check an answer in one click instead of redoing the work.
• They measure confidence, and send uncertain cases to a person instead of guessing.
• They keep a log of what they did, so an error can be traced instead of argued about.
• They start with decisions that are easy to reverse, and earn more responsibility over time.

Data and security questions to settle early

Settle these before the first line of code, not after the pilot:

• Which data leaves your systems, and which provider receives it.
• Whether processing has to stay in the EU, and which providers can guarantee that.
• The provider terms: business API use should not allow your data to be used for training.
• Access: the system should see only the data the task needs.
• GDPR: if personal data is involved, a data processing agreement with every supplier in the chain.

How a first project runs

The most common failure is scope. A company decides to "adopt AI", which becomes a programme, which becomes a committee, which becomes nothing. The alternative is narrower and far more effective:

• Map one process as it really runs, including the steps nobody documented, and measure it.
• Test the approach on real examples from that process, including the awkward ones.
• Put a first version in front of the team that does the work, with a person reviewing every result.
• Measure time saved and error rates against the baseline.
• Reduce the human review where the numbers justify it, then move to the next process.

A focused first workflow is usually a matter of weeks rather than months. And once it works, you have something rare inside a company: a concrete, measured example the rest of the organisation can argue from.