What should the contract be explicit about?

Whether improving it is included or only keeping it running. Those are different activities, and a contract silent about the boundary tends to settle towards the narrower one over time, which leaves an organisation paying for maintenance while expecting development.

What happens if we want to bring it in-house later?

You inherit something nobody internally has operated. The knowledge sits with the supplier by construction, so a transition means building an understanding from documentation and handover rather than from experience, and it is worth asking what handover looks like before signing.

Is this a sign we chose too complicated a tool?

Not usually. Ongoing attention is a property of this category rather than of a bad choice, because models change and connected systems move regardless of which product was picked, so the question is who provides that attention rather than whether it is needed.

Glossary

Managed service

An arrangement where somebody else runs the thing for you indefinitely, rather than building it and handing it over.

In plain terms

Paying somebody to keep it working rather than to build it. The distinction that matters is duration: a build ends and somebody hands you the keys, while this arrangement has no natural end and neither does the invoice.

Why it matters

Because AI tools need ongoing attention in a way that surprises organisations expecting software to settle down. Models change underneath, quality drifts, connected systems move, and somebody has to notice and respond. An organisation without that person either buys the attention or slowly discovers they needed it.

How it works

What transfers is operation rather than responsibility. Somebody else runs it, watches it and fixes it, and the organisation remains accountable for what the thing does, which matters most where the output reaches customers or touches personal data.

It suits this category better than it suits most software, because the work genuinely does not stop. A conventional system reaches a steady state where little changes month to month; a tool resting on a model that gets updated, and on connections that move, has ongoing work built into it by construction.

The dependency it creates is different from the one it removes rather than smaller. An organisation that never operates the thing does not learn how it works, so the knowledge lives with the supplier, and moving away later means rebuilding an understanding nobody inside ever had.

The scope boundary is where these arrangements go wrong. Running it and improving it are different activities, and a contract silent about which is included tends to resolve towards the narrower reading over time, so the service quietly becomes keeping the lights on while everybody assumed it included getting better.

It is often the honest answer for a small organisation, and worth saying plainly. Where nobody internally has the time or the inclination to watch a system continuously, buying that attention is more realistic than assuming somebody will find it, and the alternative is usually a tool that degrades without anybody noticing.

What the fee is actually buying

The third right-hand line deserves the attention because the other two are obvious and it is not. Nobody signing this kind of arrangement believes they have transferred accountability, and everybody understands they still decide what the system should do. What goes unnoticed is that an organisation which never operates a thing does not accumulate any understanding of it, and that understanding is what makes every future decision cheaper: whether a proposed change is hard, whether a supplier's estimate is reasonable, whether a problem is serious. Three years in, an organisation can find itself unable to evaluate the advice it is paying for, which is an uncomfortable position that arrived through no single bad decision. That is not an argument against the arrangement, which is frequently the right answer and particularly for a small organisation where the internal alternative is nobody watching at all. It is an argument for treating the handover terms as a live part of the contract rather than boilerplate, and for having somebody internally who follows what is being done closely enough to stay able to judge it.

Seen in the wild

Paying somebody to keep a support assistant tuned as products and policies change.
Tidio Lyro
An outside team maintaining the connectors a search deployment depends on as systems move.
Glean
Automations built and then operated by a supplier, because nobody internally watches them.
Make

Common misconceptions

People assume

It transfers responsibility for the outcome.

In fact

It transfers the operating work. Accountability for what the system does stays with the organisation, which matters most where output reaches customers or personal data is involved, and no arrangement with a supplier changes that.

People assume

It is more expensive than doing it internally.

In fact

It is more visible. The internal alternative costs somebody's attention indefinitely, which appears in no budget line, and organisations frequently compare a quoted fee against an internal cost they have never calculated.

Telling them apart

Managed service vs Implementation partner

Managed service

Runs it indefinitely; the relationship has no natural end.

Implementation partner

Builds it and hands it over; the relationship is meant to end.

Ask what happens in month thirteen. One arrangement has an answer and the other has finished.

Questions

What should the contract be explicit about?: Whether improving it is included or only keeping it running. Those are different activities, and a contract silent about the boundary tends to settle towards the narrower one over time, which leaves an organisation paying for maintenance while expecting development.
What happens if we want to bring it in-house later?: You inherit something nobody internally has operated. The knowledge sits with the supplier by construction, so a transition means building an understanding from documentation and handover rather than from experience, and it is worth asking what handover looks like before signing.
Is this a sign we chose too complicated a tool?: Not usually. Ongoing attention is a property of this category rather than of a bad choice, because models change and connected systems move regardless of which product was picked, so the question is who provides that attention rather than whether it is needed.