Managed AI Services or Your IT Provider: Who Runs AI Agents?

For most companies, the IT provider should keep running the accounts, devices, networks and backups an AI agent depends on, while a specialized operator runs the agent itself: its instructions, memory, tool access, evaluations and changes. The two roles overlap on access, security and incidents, so the split needs to be written down rather than assumed. If you treat an agent as one more application, its behavior, which can shift without any outage, ends up with no owner.

Key takeaways

• Your IT provider is the right owner for identity, devices, networks, backups and the vendor accounts an AI agent relies on.
• A specialized operator is needed for what is unique to agents: the role definition, memory, tool permissions, evaluations and controlled changes.
• An agent can get worse without any outage, so uptime dashboards alone cannot tell you whether it is still doing its job.
• Overlap areas such as access rights, incident response and data handling need a named owner on each side, in writing.
• Ask both parties the same questions about evidence, escalation and approvals, then assign roles based on the answers.

What does a traditional IT provider cover well?

A good IT provider is built around systems that behave predictably. A server is up or down. A license is assigned or not. A laptop is patched or it is not. That discipline is exactly what an AI agent needs underneath it, and you should not try to replace it.

The parts of an agent deployment that fit squarely within a traditional IT scope are these:

• Identity and single sign-on, including who can create accounts and how they are removed when someone leaves.
• Devices, networks and endpoint security on the machines your team uses to reach the agent.
• Email, calendar, file storage and collaboration tools that the agent connects to.
• Backup of the company systems the agent reads from or writes to.
• Vendor and license administration, including who holds the billing relationship.
• Helpdesk intake, so employees have one familiar place to report a problem.

If your provider already does these well, an agent project starts from a healthier place. The question is what happens beyond this list.

What makes an AI agent different from the software your IT provider supports?

Conventional software does the same thing every time you give it the same input. An agent does not. It interprets instructions, reads from memory, chooses among tools and produces output that can vary. That creates operating work that has no direct equivalent in a typical IT service catalog.

First, behavior depends on a model that its vendor can update. The agent may act differently after a change that nobody on your side made, and nothing will show as an error. Second, an agent holds context: documents it can retrieve, notes it has saved, instructions that shape its tone and limits. Someone has to curate that, correct it and decide what it should forget. Third, an agent uses tools with real permissions, so it can send a message or update a record. That makes authorization design a daily concern, not a one-time setup. The OWASP guidance on authorization is a useful reference for the principle of granting only what a task requires.

Fourth, agents read text from emails, documents and web pages, and that text can contain instructions meant to hijack them. Defending against that is a specific discipline, described in the OWASP prompt injection prevention material. Finally, quality is measured by evaluations: a set of realistic tasks with expected outcomes that you rerun over time. Anthropic's writing on evaluations for agents explains why this is different from conventional testing.

None of this makes IT providers incapable. It means the work needs people who do it routinely. For a fuller picture of the daily routine, see what AgentOps means for a business.

Who should own each part of running an agent?

Use this list as a decision guide. For each item, the first owner named is the default, and the second is who must be consulted.

• Single sign-on, multi-factor authentication, account removal: IT provider, with the agent operator told when a person with agent access leaves.
• Devices, network and endpoint protection: IT provider only.
• Role definition and success criterion for the agent: business owner, with the agent operator drafting and refining.
• Instructions, memory contents and knowledge sources: agent operator, with the business owner approving anything that changes what the agent may say or do.
• Tool connections and permission scopes: agent operator proposes, business owner approves, IT provider confirms the underlying accounts are set up correctly.
• Evaluations, monitoring of output quality and drift: agent operator, with reports shared with the business owner.
• Model and vendor changes: agent operator tests, business owner approves any visible change.
• Backup of company systems: IT provider. Backup and restore of the agent's configuration and memory: agent operator, with IT provider aware of where copies live.
• Security incidents touching the agent: both, with one named lead per incident.
• Employee questions about how to use the agent: agent operator for content, IT provider for access problems.

If an item on your own list has no obvious owner, that is the gap to close first.

Where do the two roles overlap, and how do gaps appear?

Gaps rarely appear in the clear cases. They appear where two competent parties each assume the other has it covered. Three overlaps cause most of the trouble.

The first is access. IT controls accounts, but the agent holds its own credentials and scopes inside connected tools. When an employee leaves or a system is reconfigured, the agent's access can quietly stay as it was. A recurring review helps, and a step-by-step permission review for AI agents shows what to check and how often.

The second is incidents. If the agent sends something wrong to a customer, is that a helpdesk ticket, a security event or a quality problem? It can be all three. Decide in advance who triages, who can pause the agent and who talks to the affected person.

The third is change. IT teams are used to change windows for systems. Agent changes are smaller and more frequent: an edited instruction, a new document in memory, a different model. Without a shared way to request and approve them, changes either pile up unreviewed or stall. The shared responsibility model for AI agents describes how to divide these duties between a provider and a company in a way both sides can follow.

An illustrative scenario: green dashboards, wrong answers

This is an illustrative scenario, not a real case.

A distribution company has an agent that drafts replies to supplier questions about delivery terms. Its IT provider monitors the hosting, the mailbox connection and the sign-in system. All of it reports healthy. Meanwhile the model behind the agent is updated by its vendor, and the agent starts summarizing terms more loosely. It sometimes omits a condition that the buyer needs to see.

No alert fires, because nothing is down. A buyer notices that two drafts look off and mentions it to a colleague, but there is no agreed place to report it. The IT helpdesk does not know how to judge whether a draft is wrong, and the business owner assumes the provider would have flagged a problem.

With a specialized operator in place, a recurring evaluation using sample supplier questions would have shown the change in output. The operator would have compared results against the previous version, proposed a correction to the instructions, and asked the business owner to approve it. The IT provider would not need to do any of that work. It would only need to keep the underlying systems healthy, which it already did.

How does Be Human's managed approach handle this?

Be Human designs, implements and operates personalized AI infrastructure for companies, with agents that keep their identity, memory, channels, tools and permissions under human control. A first engagement defines one useful role, the memory and tools it needs, approval boundaries and an observable success criterion. Managed operations then cover monitoring, recurring evaluations, integration maintenance, permission review, incident response and controlled improvements. The work is remote, in English and Portuguese, and it is designed to sit alongside your existing IT provider, which keeps ownership of accounts, devices and networks. For a detailed breakdown of the recurring work, see what managed AI services include.

A step-by-step plan to split the work

You can do this in a single working session with your IT provider and whoever will operate the agent.

• Step one: write the agent's role in a few sentences, including what it may read, what it may change and what it must never do.
• Step two: list every system the agent touches, and mark who administers each one today.
• Step three: go through the ownership list above and assign a first owner and a consulted party to each item. Leave nothing as shared without a named lead.
• Step four: agree how problems are reported. Give employees one place to report a bad answer and make sure it reaches the agent operator, not only the helpdesk.
• Step five: define what can pause the agent, who can do it, and who must be told afterwards.
• Step six: set a review rhythm for permissions, evaluation results and requested changes, and put dates on the calendar.
• Step seven: write the split into the contract or statement of work for each party, so that the responsibilities survive staff turnover.

If your IT provider is already stretched, or if you have no internal owner for the agent, consider how the same questions apply to other options in in-house team or external partner.

Frequently asked questions

Can my IT provider run our AI agents if it is willing to learn? Possibly, for a narrow and low-risk agent, if it commits to evaluations, permission reviews and change control as ongoing duties and not as a one-time setup. Ask it to show how it would detect a drop in answer quality and who would approve a change to the agent's instructions. If those answers are vague, add a specialized operator.

Do I need to replace my IT provider to work with a managed AI provider? No. The IT provider keeps the foundation: identity, devices, networks, email and backups of company systems. The managed AI provider takes the agent-specific work on top of it. What matters is that both know where their responsibilities begin and end.

Who is responsible if the agent makes a mistake that affects a customer? Responsibility should be assigned before it happens, in your agreements and your internal rules. In practice, the business owner remains accountable for the role the agent performs, the operator is responsible for how the agent is configured, monitored and corrected, and the IT provider is responsible for the systems underneath. Write down who can pause the agent and who contacts the customer.

How do I know whether I need a specialized operator at all? Look at what the agent can do. If it only answers internal questions from a small set of documents, light oversight may be enough. If it uses tools, touches customer or financial data, or its output reaches people outside the company, you need someone accountable for evaluations, permissions and changes on a recurring basis.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.