Hiring an AI Integrator: Scope, Data Access and Who Owns the Result

Many companies want AI inside the systems they already use: a support desk that drafts answers, a document archive that answers questions, a sales tool that summarizes calls. Few have the in-house staff to build this. So a market for AI integration services has grown up, ranging from large consultancies to small specialist studios and freelancers.

These firms sell something that is easy to underestimate. The language or vision model is often rented from one of a few large providers. The integrator's real work is connecting it to company data, wiring it into existing applications, testing it and keeping it running. That work determines whether the project helps or quietly fails.

This article looks at what a client should know and agree on before an outside team starts.

What integration work actually consists of

A typical AI integration project combines several layers. The model is only one of them, and often the most interchangeable.

• Data access: connecting to document stores, databases or ticket systems, with permissions that mirror who may see what.
• Retrieval: preparing documents so the system can find the relevant passages for each question.
• Application wiring: placing the AI function inside the screens and workflows people already use.
• Guardrails: rules that block unsafe answers, mask personal data or hand a case to a person.
• Evaluation: a set of test questions or cases with known good answers, used to measure quality.
• Operations: logging, monitoring, cost tracking and updates when the underlying model changes.

When a proposal spends most of its pages on the model and few on the rest, it is worth asking why. A short discovery phase that inspects the actual data sources before any price is fixed is usually money well spent. It shows whether documents are current, whether permissions are documented and how much cleanup lies ahead.

Why the proof of concept can mislead

Most engagements start with a proof of concept, a short trial meant to show that the idea works. The risk is that it works too well. Trials often use a few hundred tidy documents and questions chosen by enthusiastic staff. Real use brings scanned files, outdated versions, contradictory sources and questions nobody anticipated.

A useful trial is built on a sample of real, messy material and on questions collected from the people who will use the system. It should record failures, not only successes. Take a regional hospital testing a system that answers staff questions about internal guidelines. It learns more from the cases where the system cited an outdated version than from a hundred correct answers.

It also helps to fix the success measures before the trial starts. If the team decides afterward what counts as good enough, almost any result can be presented as a success. Agreeing in advance which error rate would stop the project keeps the trial honest.

A proof of concept should try to break the idea, not to sell it.

Acceptance criteria and evaluation sets

Traditional software projects define acceptance as a list of features. AI projects need more, because the same feature can work well or badly. The practical answer is an evaluation set: a fixed collection of inputs with expected results, agreed by both sides before the build starts.

The contract can then tie acceptance to measured results on that set. Typical measures are how often answers are correct, how often the system declines to answer and how often it hands a case to a person. The client should keep the set, because it remains the yardstick for every later change, including a switch to another provider.

Data protection and security

Any integration moves company data along new paths. The client needs clear answers on several points. Which data leaves the company network, and to which model provider? Is it stored, and for how long? Can it be used to train the provider's models? Who at the integrator can see it during the project?

In Europe, the GDPR requires a written agreement with any service provider that processes personal data on a company's behalf, and similar duties exist elsewhere. Beyond the legal minimum, permission design matters. If an employee cannot open a document in the archive, the AI assistant must not quote it to them. Integrators who treat this as an afterthought create one of the most common security problems in these projects.

Logs deserve the same scrutiny. Prompts and answers often contain customer details, and they may be stored for debugging long after the conversation ends. The contract should say where logs live, who can read them and when they are deleted.

Ownership, lock-in and the exit

Integration projects produce assets that outlast the engagement: code, configuration, prompts, retrieval pipelines, evaluation sets and sometimes adapted models. The contract should state who owns each one and in what form it is handed over. Without that, a client may find that its working system lives in the integrator's cloud account and cannot be moved.

Lock-in can also come from the model layer. Some designs tie everything to special features of one provider. Others keep a separating layer that allows a different model to be swapped in after testing. The second approach costs a little more at first but leaves the client with more negotiating power.

Knowledge transfer is part of the exit as well. Internal staff should take part in the build, not just receive a folder of documents at the end. A system that only the integrator understands is owned on paper but not in practice.

Costs after go-live

Integration fees are only the visible part of the bill. Model providers usually charge by usage, so costs rise with the number of users and the length of the documents processed. Monitoring, updates and periodic retesting need someone's time. When a provider retires an older model, the system must be checked against the evaluation set again.

A sound proposal estimates these running costs and offers an operating arrangement, either a support contract or a planned handover to internal staff. Clients who budget only for the build often end up with a system that works on launch day and degrades within a year. The cheapest offer at signing is rarely the cheapest system to own.