Artificial intelligence integration

What integrating AI means, and what it does not mean

In short: Three very different realities hide behind the same word: using a consumer assistant, switching on AI features inside a tool already in place, or having an agent built that is connected to your data and your processes.

The first reality is the use of a consumer assistant. Someone opens a chat interface, asks a question, copies the result into a document. Nothing is connected to the information system: the tool knows about the company only what is typed into it at each exchange. This is a natural entry point and it has a real merit — it shows quickly, on the actual texts of the business, what the model handles well and what it gets wrong. It is also the stage at which usage spreads without rules, each person choosing their own tool and deciding on their own what they are willing to paste into it.

The second is switching on AI features inside tools already in use: a mail client that summarises a thread, a sales management system that drafts a first follow-up message, a word processor that rewrites a paragraph. Here the model sees the data already present in the tool, with nothing to develop. The work becomes one of decision and configuration: which features to open, to whom, on which data, and with what validation before anything leaves the company.

The third is building an agent fitted to one specific process. An assistant that reads incoming requests, sorts them into your own categories, retrieves the matching information from your documents and prepares a reply that a person reviews before it is sent. This is where integration really begins, because the process has to be described, what becomes automatic has to be separated from what stays a human decision, and the model has to be connected to identified data sources.

What the term does not cover deserves to be said just as plainly. Integrating AI is not buying a product that would make the company intelligent on its behalf. Nor is it a purely technical project: the gains that are actually observed come from a change in how a task is done, which means work on the process as much as on the tool. And it is not one single irreversible decision, but a series of small reversible choices — which is rather reassuring, provided they are made knowingly rather than by default.

How a language model connected to your data works

In short: A language model predicts what follows a piece of text based on what it is given to read. All the engineering of an integration consists in supplying it with the right material — instructions, extracts from your documents, tools it can call — at the right moment.

A language model is trained to predict what comes after a text. Both its strengths and its weaknesses follow from that mechanism. It is remarkable at rephrasing, classifying, summarising, pulling a piece of information out of a document, translating, producing a first draft. On the other hand it has no verified knowledge of your files, and nothing in the way it works forces it to say that it does not know: in the absence of knowledge, it produces whatever most resembles an answer. That is the origin of what are called hallucinations, and it is a property of the method, not a temporary flaw.

What it is given to read is called the context. It contains the instruction — often called the prompt — and everything added to it: an extract from a procedure, the content of a document, the history of the current exchange. That context has a maximum size, and more importantly an answer degrades when the context is cluttered. A large part of integration work therefore consists in automatically selecting the right elements rather than sending everything, and in writing a stable instruction that describes the expected role, the output format and what to do in case of doubt.

Connecting a model to company data is most often done through document retrieval. Documents are split into fragments, indexed by meaning rather than by exact wording, and then, for each question, the fragments closest to the subject are retrieved and placed in the context. The model answers from those extracts and can indicate which document they came from. The practical advantage is decisive: when a procedure changes, the document simply has to be re-indexed, with nothing retrained. The trade-off is just as real: if internal documentation is out of date or contradictory, the assistant will faithfully reproduce those contradictions.

A model can also call tools. Rather than inventing an order number, it triggers a function that queries your database and returns the real value. That mechanism is what separates an assistant that talks from an assistant that acts: checking a calendar, creating a record, preparing a message. Each tool has to be described precisely, and the rule of caution is simple — an action that reads may stay automatic, an action that writes, commits or sends deserves explicit human validation.

That leaves the question of access rights, which is often discovered too late. An assistant plugged into a file space sees exactly what the account it was connected with sees. If internal permissions are approximate, the assistant will expose them: someone will obtain in a single question content they would never have found by browsing the folders. Mapping access before connecting anything is part of the work itself, not an optional preliminary.

How an integration assignment unfolds

In short: Order matters more than speed: understand the real tasks, choose a narrow and verifiable use case, choose the tools, put it in place with human review, train the teams, then measure before deciding to extend.

Everything starts with an inventory of tasks, not with a product demonstration. You look at what teams actually do, noting what is repetitive, what is essentially textual, what follows stable rules, and what sits blocked waiting for a person. Good candidates look alike from one trade to another: a frequent, written task, one where you can describe what a good answer looks like, and where a mistake can be recovered without serious consequence. This framing has a useful side effect — it often brings to light awkward habits that needed no technology at all to be fixed.

Then comes the choice of tools. It is decided on three criteria far more than on advertised performance: what happens to the data sent and where it is processed, the ability of the tool to connect to what you already use, and the possibility of leaving it without having to rebuild everything. The least spectacular answer — switching on a feature already included in a tool you have — is frequently the most sensible one for a first use case, because it reduces the number of new things that have to work at the same time.

The rollout happens on a real but restricted scope, with one person systematically reviewing the output. That review is not a sign of distrust: it is what produces the examples needed to correct the system. You write the instructions, observe the cases where the answer goes off the rails, refine the instruction, and start again. The result of that loop — a written instruction, examples of good and bad answers, a list of cases that must not be handled automatically — is a significant part of the value of the project.

Training the teams is the most underestimated part. It is not about learning where to click, but about knowing what to hand over to the model and what never to hand over, how to phrase a useful request, how to recognise a plausible but false answer, and whom to notify when behaviour looks abnormal. A team that has not had that conversation will land on one of two extremes: ignoring the tool entirely, or trusting it without reading. Both are costly, the second more quietly so.

Measurement, finally, is prepared before the start, otherwise it will not exist. You note how the task goes today: how many back-and-forths are needed, what share of files has to be reworked, where the waiting builds up, how the people involved feel about it. After the rollout, you compare on the same indicators. That comparison serves as much to decide to extend as to decide to stop, and a use case abandoned for good reasons is a result, not a failure.

The mistakes that come up most often

In short: Failures look alike: a shaky process gets automated, data is sent without knowing where it goes, a successful demonstration is mistaken for a production system, and human verification is removed too early.

The first mistake is automating a process that works badly. Automation does not repair an incoherent sequence of steps, it merely makes it faster and harder to observe. If an approval exists because nobody dares remove it, if a piece of information is retyped because two tools do not talk to each other, the first question to settle is not a technical one. A successful integration often begins by deleting a few steps that have become pointless.

The second concerns the confidentiality of the data being sent. Sending a text to a model means handing it to a third-party service whose rules you need to know: is the content retained, is it used to train future models, who can access it, where is it processed, how do you have it deleted. Those rules vary between offers from the same vendor, and business offers generally do not allow for the same uses as consumer versions. This check belongs before the first trial, not after the first incident.

The third is mistaking a demonstration for a production system. A demonstration runs on chosen examples, in a chosen order, presented by someone who knows how to phrase the request. Production means badly written cases, unreadable attachments, situations that fit none of the planned categories, and people who have no time to rephrase. A use case can only be judged on real data, including the ugliest, and you must explicitly decide what the system does when it cannot answer.

The fourth is the disappearance of human verification. It rarely disappears by decision: it erodes, because the answers are good and reviewing becomes a formality. That moment is precisely the dangerous one, because a false answer is phrased with exactly the same confidence as a correct one. It is better to keep verification proportionate to the stakes: systematic for anything that leaves the company or commits it contractually, lighter but real for the rest, with an easy way to flag a doubtful answer.

The fifth, more human, is imposing the tool without explaining the intention. When nobody states what is expected, everyone assumes the worst, and the fear of making oneself replaceable produces a silent refusal: the tool is opened when the manager is watching, then closed again. Saying plainly which tasks are targeted, what is not changing, and what will be done with the time saved costs one meeting and prevents a lasting failure.

When AI integration is not the right answer

In short: Too little volume, data that must not leave your environment, a requirement for accuracy the model cannot guarantee, or a process that would first benefit from being simplified: in those cases, integration is not justified.

The first case is volume. Setting up, tuning, documenting and training represents real effort, and that effort only pays off on a task that comes back often. An occasional operation, however tedious, rarely benefits from being automated: the time spent describing correctly what is expected exceeds the time it would have taken to do it. There is one exception, that of rare but risky tasks, where the point is not the time saved but the consistency of the result.

The second case is data that must not leave your environment, whether for contractual reasons, regulatory ones, or plain caution. Solutions exist — models hosted on your own infrastructure, prior anonymisation, processing restricted to extracts that identify no one — but they carry an implementation cost and sometimes lower quality. If most of the value depends on transmitting precisely what cannot leave, that should be said early rather than discovered once the project is under way.

The third case is accuracy. A model produces a plausible text, not a guaranteed value. For a calculation, a regulatory rule, an accounting threshold or any decision that must be reproducible and defensible, an explicit rule or a formula remains superior: it always gives the same result and can be checked line by line. The model keeps a useful place upstream or downstream — extracting data from a document, explaining a result, drafting a summary — but it should not be the thing that decides.

The fourth case is a process that should be simplified rather than automated. The cheapest question remains the most uncomfortable one: does this task need to exist at all? A great deal of repetitive work is the consequence of data entered twice, of a badly designed form, or of a report nobody reads any more. Removing the cause costs less than training a machine to handle its effects, and the result lasts.

There is finally a less clear-cut case, that of an organisation which has no written description of its own processes. Integration is still possible, but it will begin with that mapping work, and it is better to announce it than to discover it. Saying that a need does not call for AI is not an evasion: it is what makes it credible when you state that another need genuinely does.