AI services that do real work

What AI is genuinely good at, and where it fails

Language models are strong at working with text and patterns. Summarising long documents, drafting first versions, classifying and routing incoming messages, extracting structured information from messy input, translating, and answering questions when the answer is in material you have given them. In those jobs they are fast, cheap and consistent enough to change how a small team operates.

They are weak wherever exactness and accountability matter. They will produce a confident answer when they do not know, because producing plausible text is what they do. They cannot reliably do arithmetic, hold a policy in mind across a long conversation, or tell you which parts of their answer they are unsure about. They also have no awareness of your business unless you give it to them.

The practical rule we use is this. If a wrong answer is embarrassing but recoverable, AI can do the first pass with review. If a wrong answer costs money, breaks a commitment or misleads a customer, AI can prepare the work but a person signs it off. That line is where most successful deployments sit.

• Good: drafting, summarising, classifying, extracting, answering from supplied material
• Poor: precise calculation, guaranteed factual recall, knowing what it does not know
• Never: unsupervised decisions with legal, financial or safety consequences

Why grounding a chatbot in your own content is the whole job

A general model knows nothing about your prices, your policies, your delivery times or your product range. Ask it and it will answer anyway, inventing something plausible. That is not a bug you can prompt your way out of. It is what happens when a model has no source to work from.

Grounding fixes it by changing the shape of the task. Instead of asking the model to recall an answer, you retrieve the relevant passages from your own content first, then ask the model to answer using only those passages. The model becomes a reader and a summariser rather than a source. That is a job it is genuinely good at.

The quality of a grounded bot therefore depends mostly on the quality of the content behind it. If your policies are contradictory across three pages, the bot will be contradictory too. Building a useful chatbot usually forces a business to tidy up documentation it has been avoiding, which turns out to be valuable on its own.

• Retrieve from your real content, then answer from what was retrieved
• Constrain the bot to say it does not know rather than guess
• Show sources so the person can check the answer themselves
• Route anything uncertain, sensitive or high value to a human
• Log the questions it could not answer, because that list is your content plan

Where automation pays back, and where it does not

Automation pays when a task is frequent, rule-based, and currently done by a person moving information between systems. Copying an enquiry from a form into a CRM. Routing a lead to the right person by territory. Chasing an unpaid invoice. Assembling the same report every Monday. These are boring, high-volume and unambiguous, which is exactly what automation handles well.

It does not pay when a task is rare, when the rules change constantly, or when the process only exists informally in someone head. Automating a broken process makes it broken faster and harder to fix. If nobody can write down how the task is done today, that is a sign to fix the process before automating it.

The maths is straightforward and worth doing before you build. Estimate how often the task runs and how long it takes, compare that with the build and maintenance cost, and be honest that automations need occasional repair when an upstream tool changes. A workflow saving five minutes once a month is not worth owning.

• Automate: frequent, rule-based, cross-system, currently manual
• Leave alone: rare, judgement-heavy, or governed by rules that keep changing
• Fix first: any process nobody can describe in writing
• Budget for upkeep, because integrations break when the tools either side change

Human review as a requirement, not an option

Every AI system we build has a defined point where a person is in the loop, and the design question is where that point sits rather than whether it exists. For low-risk, high-volume work such as tagging enquiries, review can be a sample checked weekly. For customer-facing answers on refunds, medical, legal or financial topics, review is per response, before it goes out.

Review has to be practical or it gets skipped. That means putting the check where the work already happens rather than in a separate tool, showing the person what the AI used to reach its answer, and making approval fast. A review step that adds five minutes to every item will be bypassed within a month.

The same principle applies to generated content and images. Nothing ships raw. A person checks it for accuracy, for brand voice, and for the specific claim risk that AI introduces, which is inventing a statistic or a source that sounds right and does not exist.

The practical risks worth planning for

The first is confident error. The system produces a wrong answer in the same tone as a right one, so nobody questions it. The mitigations are grounding, showing sources, allowing the system to say it does not know, and logging answers so mistakes are visible after the fact rather than never.

The second is data handling. Sending customer information to a third-party model means it leaves your systems, so you need to know what the provider does with it, whether it can be used for training, where it is processed and how long it is kept. We set this up deliberately, and we avoid sending personal data where the job does not require it.

The third is dependency. Models are deprecated, prices change, providers change terms. Building so the model is one replaceable component rather than the foundation of the system keeps that manageable. The fourth is quiet drift, where a workflow keeps running after the thing it depends on changed. Monitoring and periodic review catch that.

• Log inputs and outputs so errors can be found and fixed
• Know what your provider does with the data you send
• Keep the model swappable, because the best option will change
• Monitor automations, because silent failure is the common failure

How to evaluate an AI vendor

Ask what the system does when it does not know. A vendor who cannot describe the failure behaviour has not thought about accuracy. The good answer involves grounding, refusal, escalation and logging. The bad answer is that the model is very accurate.

Ask where your data goes, whether it is used for training, and what happens to it when you leave. Ask who owns the prompts, the workflows and the configuration. Ask what the ongoing costs are once usage grows, because token or run-based pricing behaves differently to a fixed licence.

Then ask about the boring parts, which is where projects actually fail. How do changes get tested. What happens when the underlying model is retired. Who fixes the automation when a connected tool changes its interface. How is quality measured after launch rather than demonstrated before it. A vendor with clear answers to those questions is more useful than one with an impressive demonstration.

• What does it do when it does not know the answer
• Where does our data go and is it used for training
• Do we own the prompts, workflows and configuration
• How does cost behave as usage grows
• Who maintains it when a model or a connected tool changes

A sensible order to adopt AI in a business

Start internally. Use AI on work where a mistake is caught by a colleague rather than a customer: drafting, summarising meetings, first-pass research, cleaning up data. This builds judgement about what the tools are good at, at low risk, and it usually finds the highest-value use cases before you have spent much.

Move next to assisted customer work, where AI prepares and a person sends. Drafted replies to common enquiries, suggested responses in a helpdesk, summarised call notes into the CRM. The person stays accountable, and you learn how accurate the system really is on your actual traffic.

Only then automate anything customer-facing without a person in the loop, and only where the content is grounded, the failure behaviour is defined and the logs are being read. Businesses that reverse this order tend to launch a customer-facing bot first, get burned publicly, and abandon AI entirely. That is an avoidable outcome.