Collaborative AI Operations.

There are four borrowed names in use right now, and every one of them describes tooling rather than practice.

MLOps, which was built for a world of models you trained yourself. LLMOps, which mostly means prompt versioning and a dashboard. AI enablement, which usually means licences. Agent platforms, which describes a product category rather than a way of working.

None of them describes the thing that decides whether your AI is still running eighteen months from now. That thing is a question, and it is embarrassingly plain.

Six months after go-live, the refund threshold changes. Who changes the AI, and how long does it take?

Ask it in any company running AI in production today and watch what happens. The business lead looks at the engineering lead. The engineering lead looks at the backlog. Somebody says they would need to raise a ticket. Somebody else says two weeks, minimum. And the operation, which changed on Monday, keeps running on an AI that reflects how it worked last quarter.

That gap is not a tooling problem. It is an operating model problem, and because it has no name, no one owns it.

It is worth being precise here, because the industry keeps answering this question with a better model.

Models did get better. They got better every quarter for three years, and the enterprise failure rate did not move with them. The failures that kill AI in production are almost never that the model was not clever enough. They are operational, and there are three of them.

• Nobody can say why it did that. Not in a way that survives a regulator, an auditor, or an angry customer. A log of what was said is not a record of why it acted.
• The person who knows the rule cannot change the AI. The compliance officer who owns the KYC threshold, the support manager who owns the escalation path, the underwriter who owns the exception. None of them can touch the thing making those decisions all day. They describe it to someone who does not know the domain, who implements an approximation, which nobody with the domain knowledge can read back.
• Nothing it learned made it better. Month six is the same agent as month one, plus drift. Every correction a human made along the way was a conversation, not an artifact, so none of it accumulated.

Fix the model and you still have all three. Fix these three and the model becomes an interchangeable component, which is what it always should have been.

We have watched this go the other way. Betsson France runs customer support on Interactive Agents in a regulated market. Roughly 75% of their customer issues are now resolved end to end by AI, and more than 30% of tickets were eliminated at root cause rather than answered faster. What made that possible was not a model choice. It was who was allowed to operate it.

“I write the policy, test it, deploy it. No engineering ticket, no waiting cycle.”

Mehdi Aounallah, Head of Customer Support, Betsson France

That sentence is the whole category in twelve words.

Collaborative AI Operations is the practice of building and running AI as a joint operation between the people who know the business and the people who know the systems, in one governed environment the company owns.

Four things in that sentence are non-negotiable, and each one is doing work.

Co-authored

Domain experts and developers build the same AI, in the same place, in the artifacts each of them is accountable for. Not a specification handed across a wall and a black box handed back.

Governed turn by turn

Every decision is attributable to the rule that produced it. Governance is not a review meeting before launch. It is a property of every single run.

Owned by the company

The rules, the procedures, the vocabulary and the accumulated corrections are yours. They live in artifacts you can read, version, export, and take with you.

Improving from its own production record

The system gets better from what it actually did, under human gates, or it is depreciating. There is no third state.

Notice what is not in that definition. No model. No vendor. No architecture diagram. This is an operating model, and you can hold it against any technology choice you are about to make, including ours.

Three approaches dominate today. Each is a real answer to roughly a third of the problem, and each is chosen by serious people for defensible reasons.

Outsourced AI

A partner builds and runs it for you. This is the fastest possible start and it is genuinely the right call for a first proof of value. What it does not do is accumulate on your side. The operational knowledge, the edge cases, the corrections, all of it compounds inside someone else's environment, and the arrangement is renewed rather than owned. You are renting the intelligence that runs your business.

The do-it-yourself stack

An orchestration framework, a vector store, a gateway, an evaluation tool, an observability layer, a secrets manager, a deployment pipeline. Full control, real engineering ownership, and no vendor telling you what is possible. What you also own is every seam between those tools, and the seams are exactly where governance dies: the trace stops at the boundary, the policy lives in one system and its enforcement in another. It works, and it costs you a platform team forever.

AI enablement

Give everyone the tools and let a thousand flowers bloom. This distributes authorship, which is right, and it is the only one of the three that gets domain experts near the work. But it distributes control to nobody. Nothing is enforced, nothing traces back to a rule, and six months in you have forty agents and no way to answer what any of them did.

Two of the three keep control and lose the domain experts. The third keeps the domain experts and loses control. The premise of Collaborative AI Operations is that this trade is not real, and that it only looks real because of how the tools were built.

This is the part that decides whether a category is a real practice or a marketing word.

One environment carrying the foundations

Infrastructure, connections to the systems of record, governance, security, data residency. Engineering owns this, and should. It is not a place domain experts should ever have to go, and it is not something that should be reassembled per project.

Authored artifacts, not code and not prompts

This is why Interactive Agents exist as a product class rather than a wrapper. The rules, procedures, vocabulary and knowledge an agent uses are objects: composable, versioned, readable by the person accountable for them, and interpretable after the fact. A prompt is a paragraph. A policy is an artifact with an owner.

An authoring surface built for domain experts

The Co-Pilot exists so that writing a policy is writing a sentence, in plain language, with the platform doing the translation and asking for approval before anything is created, updated, or deleted. Without it, domain experts authoring the AI is a slogan. With it, the compliance officer writes the compliance rule, which is the only arrangement that was ever going to work.

Governance that makes distributed authorship safe

This is the load-bearing one. Distributed authorship without centralised governance is chaos. Centralised governance without distributed authorship is the ticket queue we started with. You get both only if every change is traced, versioned, reversible, and attributable, so that letting more people author is not the same as letting go.

“Every decision is traceable, testable, explainable, and auditable.”

Mehdi Aounallah, Head of Customer Support, Betsson France

That is what buys the permission for the first quote to be true. The two are not separate achievements. One is the precondition for the other.

Five questions. They are deliberately awkward.

1. 1When a rule changed last month, who edited the AI, and how many days passed?
2. 2Take the last decision your AI made that you disagreed with. Can you name the rule that produced it, without asking an engineer?
3. 3Which of your domain experts has personally changed something in production this quarter?
4. 4What did the system learn last month that it did not know the month before, and where is that stored?
5. 5If you changed platform vendors next year, what would you keep?

Score them honestly and you will know which of the three partial answers you actually chose, whatever the strategy deck says.

Five questions is the short version. The full instrument is twelve dimensions across ownership, trust and leverage, each with a named stakeholder, scored 0 to 3, in The Right AI Infrastructure.

Here is the argument underneath all of this.

Intelligence is becoming a commodity. Every company will have access to the same frontier models within a year, at prices that keep falling, and no durable advantage will come from which one you picked.

What does not commoditise is your operation: how your business actually decides things, the exceptions that matter, the vocabulary your market uses, the reasons behind the rules. Today most of that lives in people's heads, in wikis nobody reads, and in the gap between what the process document says and what the experienced person actually does.

Collaborative AI Operations is the practice of getting that into a form the business owns and the machine executes, correction by correction, under governance. Every rule an expert writes and every wrong answer they fix becomes an artifact that stays. The AI gets sharper because the operation taught it, and the operation gets sharper because it finally had to write down what it knows.

That is what compounds. Not the model. The operation.

For the mechanism that makes context work per decision, read Context Is the Agent. For what this looks like where the obligations are hardest, read how to run AI in regulated industries.