Getting started with AI in your company

"How do we adopt AI" is the wrong question. A better one: which of the things we already do by hand is repetitive enough for a machine to do more cheaply, and harmless enough that a mistake will not cost us a client. The answer to that decides the project far more than the choice of model.

Picking the process: three numbers

Instead of debating capabilities, score your candidates on three quantities:

• Frequency. How many times a month it happens. A process run three times a year will never pay for itself, however annoying it is.
• Time per instance. How many minutes it takes a person.
• Cost of a mistake. What happens if the output is wrong and nobody catches it.

A good first project has high frequency, measurable time and a low cost of error. That is why adoption usually starts from the same short list: sorting incoming mail, pulling data out of invoices and documents, classifying tickets, and drafting a first version of a reply for a human to approve.

Conversely, do not start with processes that rest on judgement, that are undocumented ("we just know how it is done"), or where a mistake has legal or financial consequences.

A chat widget on your website is a poor first project. It is the most visible and the least forgiving - every mistake is seen by a customer rather than an employee. Better to start with an internal process, learn on it, and go public only once you know how the model behaves on your data.

Measure the starting point before you switch anything on

Without a baseline there is no way to tell whether the project paid off. Write down before you start: how many cases come in, how long one takes to handle, what share needs correcting. Then compare - but honestly, counting the cost of the tooling and the time people spend checking the output.

RAG or fine-tuning

This is the usual fork for an assistant built on company documents, and in most cases it resolves the same way.

Choose RAG (the model answers using fragments retrieved from your documents) when what matters are facts that change. A new policy only has to be added to the collection, with no rebuilding of the model, and the answer can be shown together with its source - which in customer service is sometimes more important than the answer itself.

Fine-tuning makes sense when the problem is not facts but form: a consistent tone of voice, sticking to a template, returning results in a fixed structure. It needs a prepared set of examples and skills a web team usually does not have.

The two combine - fine-tuning for form, retrieval for content. But start with RAG: it is cheaper, quicker to evaluate and easier to back out of.

In any case, the most common reason for poor results does not sit with the model. It sits in the documents: out of date, contradictory, existing in five versions. The model will not decide which version applies - it will show the one it finds.

Where to keep a human

Match oversight to the cost of a mistake rather than applying it everywhere at once. A proven starting arrangement: the model prepares the output, a person approves it, and the cases where the model is uncertain go into a manual queue. Over time, once you can see the correction statistics, the range of automatic decisions can widen.

Whatever the scale, three things are needed: a record of what was decided and on what basis, clear ownership of every automated flow, and an escalation path for when the system does not know.

Data that should not leave the company

Before the first request goes out, settle what reaches the model provider. Customer personal data, material covered by confidentiality agreements and sensitive data all require a processing agreement - and sometimes simply should not leave your own infrastructure. In that case the answer is a model running on your own server: weaker than the largest commercial models, but often good enough for classification and data extraction.

Check too whether the provider uses submitted content for training. On business plans usually not; on free ones it varies.

A realistic order of work

One process, narrowly cut. A measured baseline. A pilot on real data, but with a human at the end. A decision based on the numbers, not the impression. Only then the next process - and only then a conversation about an assistant for customers.