How to implement AI on the systems you already have

There is a gap that comes up again and again: the company tried something with artificial intelligence, it worked in the demo, everyone left the meeting enthusiastic, and a year later it still is not in production.

It is not a technology problem. The models have long been more than good enough for what a mid-sized company needs. The pilot gets stuck somewhere else, and always in the same four places.

Why the pilot never reaches production

Because it was not connected to anything. The demo ran on a file exported by hand. To be useful it has to read from the real system, write to the real system, and do it on its own, every time. That work is ninety per cent of the project and nought per cent of the demo.

Because nobody owned it. The pilot was pushed by one enthusiastic person. When their priorities changed, no process depended on it. Nobody missed it, which is the quietest way to fail.

Because there was no way to tell whether it was working. No execution log, no alert when it fails, no number comparable to the previous process. At the first odd result the team stopped trusting it and went back to the spreadsheet — and once you go back to the spreadsheet, you do not come out.

Because the most impressive case was chosen instead of the dullest. The showy case is usually the one that requires the most judgement and tolerates errors the worst. It is the one that presents best and survives contact with real operations worst.

The order that does work

Write the process down before looking at tools

Before evaluating platforms, write the process as it works today: who does what, with what information, in which system it gets recorded.

Half the time that exercise alone shows the problem was not AI but a duplicated step or a permission nobody had. It is free and it saves the entire project.

Choosing the tool first is the most expensive mistake available here, because you then end up adapting how your team works to fit what you bought.

Buy the generic, build the integration

Almost everything generic is already solved: classifying text, extracting fields from a document, summarising, answering over your own knowledge base. That gets bought and connected; building it from scratch today makes no economic sense.

What has to be built is the integration. How the data comes in, how it is validated, where it gets recorded, what happens when it fails, who finds out. That is where the real work is, and where no product will do it for you, because it depends on how your operation runs.

Put the human at the edge, not at every step

A check at every step cancels the benefit: if someone has to approve everything, you did not automate anything, you added a screen.

The human belongs at the edge. The flow runs on its own while everything falls inside the rules, and stops when something falls outside.

The key is defining “outside” properly, and it has to be a concrete rule: an amount above a threshold, a client that did not exist before, a variance against expectation greater than a percentage. If the definition is “when it looks odd”, no automated flow is possible.

Measure against the old process

How long it took before, how long it takes now. How many errors there were before, how many now.

Without that pair of numbers you will not be able to defend the investment when someone asks, or decide sensibly whether to widen the scope. The three indicators worth recording are set out in benefits of automating processes, and they get captured before you start, because afterwards they cannot be reconstructed.

If you cannot compare it to what you were doing before, it is not a project: it is an experiment.

What it takes technically

Less than people assume. In most cases three pieces are enough:

Somewhere for the data to live that the AI will query. It can be your own database, synced from the CRM and the ERP. You do not need a data warehouse to start, and building one prematurely is a well-worn way to spend six months.

An orchestration layer that decides when each thing fires, in what order, and what happens if a step fails. This is where automation platforms come in, and where it is worth not writing your own code if a tool already solves it.

Logging and alerts. Every run recorded, and a notification to a named person when something breaks. It is the part nobody shows in demos and the only one that makes the system survive its first month.

What “in production” means

It is worth agreeing the definition before you start, because “it’s up and running” means different things to different people. A flow is in production when it meets all six:

• It runs on its own, with nobody exporting or keying anything in.
• It has an owner with a name, not a department.
• It records every run with what it did and on what data.
• It raises an alert when it fails, to a person, through a channel that person actually reads.
• There is a number comparable to the previous process.
• Someone reviewed it a week after launch and adjusted what needed adjusting.

If any of those is missing, it is still a pilot. There is nothing wrong with that; what is wrong is believing otherwise.

A realistic timeline

A well-chosen, contained flow, with the data reasonably in order, is in production in weeks. Not months.

Projects that take a year almost always take a year for one of two reasons: the scope chosen for the first step was too ambitious, or the data was in worse shape than anyone believed and nobody checked before starting.

Both are detectable in the first week if you run an honest assessment instead of a demo. And if you have not yet settled which process to tackle first, that is the prior step: nine signs for identifying it.