Article · Buying Decisions
AI Managed Services: What They Are and When to Contract Them
AI managed services are a contract under which a provider runs a process of your company with agents, operates and maintains it, and answers for the outcome. They do not sell you a license or hand you a team of programmers: they hand you the work done, with an agreed metric and a trace of every decision. The difference from buying software is who carries the maintenance. The difference from hiring people is that the work is done by a system and you buy its performance, not its hours.
I have deployed these systems, and the most expensive confusion I see in a boardroom is treating “AI managed services” as a marketing label. It is not: it describes a specific split of responsibility. If it is not clear who operates the system next month, who updates it when the model changes, and what happens the day you want to leave, you do not have a managed operation. You have a demo with a recurring invoice.
What a real managed operation includes
The service is not “access to a platform”. It is the full operation of a process, with the provider on the hook for keeping it working. In practice it covers four things, continuously.
- Process execution. The system does the work: reconciling invoices, tracking orders, resolving patterned support cases, feeding systems from documents. I have written about the catalogue of work already executed this way in AI agents in operations.
- Supervised operation. Someone watches quality, reviews the doubtful cases, and adjusts when reality drifts from the assumption. Supervision does not disappear, it changes hands.
- Technical maintenance. Models, prices, connectors and rules all change. The provider absorbs that cycle: re-evaluate, update, test again. This is the work that kills most in-house deployments, because nobody budgeted for the after.
- Traceability and control. Every agent action is recorded, and permissions define what it may read and write. Without this there is no possible audit, and without audit a serious board should approve nothing.
The acid test is simple: if you fire your provider tomorrow, does the process keep running on its own? In a real managed operation, no. You were buying a live capability, not an installation left sitting there.
How it differs from classic BPO
Business process outsourcing (BPO) also takes work off your plate, but with a different engine: people. You hire a team, usually offshore, that runs your process with human hands. Cost scales with volume because every extra case consumes someone’s time, and quality depends on the turnover and training of that workforce.
An AI managed operation swaps the engine. The work is done by a system, and the provider’s people supervise, govern the exceptions, and maintain the machine. That has two consequences worth understanding before you sign. First, cost stops growing linearly with volume, because processing ten thousand cases or a hundred thousand does not multiply headcount the same way. Second, less comfortably: a system fails differently than a person. It does not tire or improvise, but when it is wrong it is wrong consistently and at scale, which is exactly why evaluations and well-placed human escalation matter so much.
It is not that one is better than the other in the abstract. BPO still makes sense for work that needs human judgment on every case or that lacks a stable pattern. An AI managed operation fits where there is volume, known rules and typifiable exceptions.
How it differs from an IT MSP
An IT managed service provider (MSP) maintains your infrastructure: servers, networks, endpoints, backups. Its object is keeping technology available and healthy. It is measured in uptime, incident response times, and compliance with a service-level agreement.
The difference is the object of the contract. An MSP answers for a system working. An AI managed operation answers for a piece of business work coming out right. It does not promise the platform will be up 99.9% of the time: it promises an outcome on your process —invoices reconciled, orders tracked, cases resolved— measured in business units, not infrastructure ones. Confusing the two leads to signing an availability contract when what you needed was an outcome contract.
What the contract must say
This is where a serious offer separates from a slide deck. These are the clauses I review, and without all four I would not call it a managed operation.
| Element | What has to be in writing |
|---|---|
| Measurable outcome | The process metric, not the platform’s: volume completed, error rate, escalations, cycle time, cost per unit. How it is measured and how often it is reviewed. |
| Permissions and access | Which systems the agent touches, what it may read, what it may write, what it must never touch. Detailed enough to pass a security review. |
| Traces and audit | A record of every decision and access to those records. Without a trace there is no way to audit or to argue about a specific error. |
| Clean exit | What you take when it ends: your operating architecture —rules, exceptions, controls, data contracts, evaluation criteria— updated, plus the export of data, outputs and traces. |
The exit clause is the one most people forget and the one that protects most. A managed operation should not lock you in. At Arkatai the provider keeps its platform, but the operating architecture specific to your process is yours, and when the contract ends you receive it updated to take to another implementer or to build on. That lowers the cost of switching. It does not remove it, because reimplementing the operation still costs. The framework for that ownership split is in buy vs build for enterprise AI.
When it beats building in-house
The managed operation solves a concrete problem: many mid-sized companies do not have —and do not want to stand up— a product and technology department able to maintain agents, evaluations and integrations at the current pace. Building in-house gives you full control in exchange for creating that permanent function, with its fixed cost and its turnover risk. Contracting the operation leaves you the outcome and spares you the function, in exchange for depending on a provider and demanding a well-written contract.
It fits when the process has volume, a measurable outcome, and enough continuity for the system to improve on execution data. It fits worse when AI is part of your product, when the process changes with no clear owner, or when what you need is a bounded one-off project, where an automation agency versus a managed operation may be enough. And if you are still unsure between building a team, calling a consultancy, or contracting a service-as-software model, that decision about whom to work with is developed in in-house, consultancy or boutique.
One last thing I always check: the return. Contracting an operation is not justified with the promise of the demo, but with a business case —cost per unit, effect on margin or service— that holds up on the process’s real data. That calculation is in AI operations ROI, and it is worth having before you sign, not after. The full territory of what agents are is covered in the pillar on AI agents for business.
Frequently Asked Questions
Is an AI managed operation the same as “AI as a service”?
Not exactly. “AI as a service” usually means consuming models or capabilities through an API: you get the tool and build and operate on top of it. A managed operation goes a level further: the provider does not give you the tool, it runs the whole process with it and answers for the outcome. You buy the work done, not the raw material.
Do I lose control of my process if I hand it to a provider?
You should not, if the contract is well made. You still set the rules, the permissions and the cases that require a human decision, and you appoint a process owner with business authority. What you cede is technical maintenance, not governance. The traces and the exit clause are precisely what keeps you in charge.
How much of my own staff do I need for a managed operation?
Less than for building, but not zero. You need a process owner who decides rules and exceptions, someone to open access to the systems, and someone to review the cases the system escalates. What you do not need is a team dedicated to swapping models, maintaining connectors and running evaluations every week.
What happens if I want to change providers later?
It depends on the exit clause. With a clean exit, you receive your operating architecture updated plus the export of data, outputs and traces, and you can take it to another implementer. Without that clause, the cost of switching can lock you in de facto. It is the first thing to negotiate, not the last.