How do we tell whether we need one?

Count the systems that have to meet, and ask who would own a problem sitting between two of them. Where that question has an obvious internal answer you probably do not need the role, and where it produces a pause you have found what they sell.

What is the main risk of using one?

Ending up further from the detail than you were before. Where the firm coordinates rather than builds, an extra layer of translation sits between the organisation and the people doing the work, which is the opposite of the closeness a buyer usually believes they are acquiring.

Why does this come up for AI projects?

Because they have more joins than the buying conversation suggests. A tool reading from several systems, writing to another and handing off to a person is an integration project described as a product purchase, and the description is what makes the joins invisible until later.

Glossary

Systems integrator

A firm that takes responsibility for several systems working together, rather than for any single product working on its own.

In plain terms

Somebody accountable for the whole arrangement rather than for one part of it. Each individual supplier can be entirely correct that their piece works, and the thing as a whole can still not work, and this is the role that exists because that situation is so common.

Why it matters

Because the failures that matter are usually at the joins, and joins have no natural owner. Every specialist can demonstrate that their component behaves correctly, which leaves the organisation holding a problem that is genuinely nobody's fault and equally genuinely still a problem.

How it works

The role is defined by breadth rather than by depth in any one product. They will know less about a given tool than that tool's own specialists, and they will be the only party thinking about what happens when four things meet, which is a different and frequently scarcer kind of knowledge.

What they actually sell is single-point accountability. The value is not that nobody else could do the work but that somebody is answerable for the whole, so a problem at a boundary has an owner rather than a discussion between three suppliers who each believe they are finished.

AI projects have more joins than they appear to, which is why the role turns up here. A tool that reads from several systems, writes to another and hands off to a person is an integration project wearing the clothes of a product purchase, and it is usually described in the second way during buying.

The risk is a layer of translation between you and the people doing the work. Where the integrator subcontracts or coordinates rather than building, the organisation can end up further from the detail than it was, which is the opposite of what it thought it was buying.

It is a poor fit for small, single-tool adoptions and frequently sold into them anyway. One product and one connection does not need somebody accountable for an arrangement, and paying for coordination where there is little to coordinate is a common way to spend money on structure rather than on outcome.

Where the problem lives

The uncomfortable thing about the right-hand column is that it contains no villain. Each supplier is describing their own scope accurately, each has tested what they were asked to test, and the thing between them was never anybody's deliverable because it is not a thing anybody supplies. It emerges from the arrangement rather than being built. That is why the response of pressing suppliers harder rarely helps: they will investigate, confirm their part is correct, and return that finding in good faith, and three such findings leave the organisation exactly where it started with more elapsed time. The question worth asking during buying, before any of this happens, is who owns a fault that sits between two components. An organisation with a confident internal answer has the capability already and should keep its money. One that pauses has found the gap, and the choice is then to fill it deliberately by paying somebody, or to fill it accidentally later with whoever internally is nearest when the problem appears.

Seen in the wild

A search deployment reading from half a dozen systems, where the joins are the whole project.
Glean
An automation programme spanning several products, where each vendor is correct that their part works.
Make
A single assistant rollout that does not need this role and is sometimes sold it regardless.
ChatGPT

Common misconceptions

People assume

They are experts in each product involved.

In fact

They usually know less about any single tool than that tool's own specialists, and more about what happens where tools meet. Buying them for product depth is buying the wrong thing from the right sort of firm.

People assume

Every AI project needs one.

In fact

Only the ones with several systems genuinely meeting each other. A single tool and one connection has little to coordinate, and paying for accountability across an arrangement that does not exist is spending on structure rather than outcome.

Telling them apart

Systems integrator vs Implementation partner

Systems integrator

Accountable for several systems working together.

Implementation partner

Accountable for one tool working well here.

Count the systems that must meet. One or two is a partner; several with dependencies between them is an integrator.

Questions

How do we tell whether we need one?: Count the systems that have to meet, and ask who would own a problem sitting between two of them. Where that question has an obvious internal answer you probably do not need the role, and where it produces a pause you have found what they sell.
What is the main risk of using one?: Ending up further from the detail than you were before. Where the firm coordinates rather than builds, an extra layer of translation sits between the organisation and the people doing the work, which is the opposite of the closeness a buyer usually believes they are acquiring.
Why does this come up for AI projects?: Because they have more joins than the buying conversation suggests. A tool reading from several systems, writing to another and handing off to a person is an integration project described as a product purchase, and the description is what makes the joins invisible until later.