Who runs your AI once it’s live?

We sat down with Lars Hasselrot, Head of Run at Redeploy, to hear what it actually takes to keep AI running once it’s in production.

Lars has spent almost twenty years in the IT industry, most of it in managed services. Racking hardware and pulling cables in data halls. Customer platforms on four continents. Monitoring, log management, alerting, service desks, and operations teams with people on call around the clock.

“The technology has been replaced several times over,” Lars says. “The questions about cost, traceability, measurement and drift have stayed the same. AI is the newest workload to raise them.”

One owner for the whole chain

Running an AI agent involves more moving parts than the agent itself. It’s the platform it runs on, the data it reads, the layer that governs its calls to the models, and the application around it. In most organizations, these sit with different teams, and often with different suppliers.

That works fine during the project, Lars says, when everyone is in the same steering group. It stops working the first time something goes wrong in production.

“When the agent starts giving strange answers at three in the morning, the person on call needs to see all of it. The platform, the data, the control layer, and the agent. Split it across three suppliers and every incident starts with a discussion about whose problem it is. The first hour goes to finding the owner instead of fixing the problem.”

There is no shortage of names for the disciplines involved, from MLOps to AgentOps. What Lars sees missing is accountability for the whole. His recommendation is to settle it early: one team responsible for keeping the agent running and behaving, from the platform up, named before the project team leaves the room.

AI runs best on the platform you already have

For the business, production is where the value is supposed to start. The agent is there to clear cases, answer customers, or free up hours, every day, at a cost that makes sense. Whether it keeps doing that depends as much on everything around the agent as on the agent itself.

Many organizations respond by sketching a separate foundation for AI. Lars thinks most of them don’t need one.

“Most of what an agent needs is already in the landing zone you run today. Identity, networking, logging, cost management, security. Extend what you have. A second platform means a second set of everything to operate, patch, and pay for.”

What the existing foundation does need is to be ready for a workload that behaves differently from the ones it was built for.

“An agent leans on everything around it. If access is set up wrong, it reads data it shouldn’t. If logging is missing, nobody can explain an answer afterwards. If cost isn’t tagged, the bill lands on IT with no owner. Those are platform problems, and the business experiences them as AI problems.”

You can only run what you can see

Lars has built enough alerting to know what a failing system looks like. AI fails differently.

“A server that goes down sends an alert. An agent that drifts sends nothing. The answers just get a little worse over time, because the data changed or people started using it differently.”

For Lars, that means measuring two different things. Uptime shows that the agent responds. Only regular checks of its answers show that it still gets things right.

His answer is visibility, built in from the start. When every application talks to the models directly, nobody has the full picture. Lars argues for an AI control plane, sometimes called an AI gateway: one layer between the applications and the models that every call passes through. That’s where policy gets applied, usage gets logged, and cost gets tracked per team. It’s also where quality can be measured against a baseline agreed before go-live: what a good answer looks like, what a normal cost per case is, and the point where a person takes a look.

The control plane also catches changes that come from outside. Model providers retire old versions on fixed dates, so every agent will eventually have to move to a new one.

“Policy documents describe what should happen. The control plane is where you see what did happen. That’s where your cost data comes from, where you notice drift, and where you go when someone asks why the agent answered the way it did.”

What Lars would have in place before go-live

Asked what he would put in place before an agent goes live, Lars answers the following.

1. Name the person on call. Every agent in production has a named owner and someone on call before the project team is released.
2. Tag the cost from day one. Every agent’s spend is tagged to the team that uses it, so cost and value can be compared in the same place.
3. Route model traffic through one place. Once several agents are in production, an AI control plane is the simplest way to apply policy, logging, and cost controls to all of them. For a single, contained use case, though, it can be more than you need.
4. Keep a decision trail, and decide how long to keep it. Log enough to explain afterwards why the agent answered the way it did. The logs can contain personal data, so GDPR and the EU AI Act set limits. Agree with legal on how long to keep them before go-live.
5. Put model retirement dates in the calendar. Treat them like certificate expiries and license renewals, and plan the switch well before the date.
6. Define an AI incident. Agree on what counts as one, who gets paged, and how you roll back a model or prompt version.
7. Run a rollback drill before launch. Switch the agent off or back to the previous version, and time how long it takes.

Lars has heard the same questions throughout his career, first about servers, then cloud platforms, and now AI agents. What does it cost, is it still working, and who answers when it isn’t? The organizations that can answer them on the day an agent goes live are the ones still getting value from it a year later.