Self-Hosted vs Cloud AI Agents: How to Decide for Your Company

For most companies, a cloud-hosted agent with clear exit terms is the better starting point. Self-hosting earns its upkeep only when a specific requirement demands it, such as strict data residency, a regulator's expectations or an isolated network. The choice is really about who carries which responsibility: control and evidence on one side, maintenance load on the other.

Key takeaways

• Self-hosted and cloud are not all-or-nothing. An agent has a model, a runtime, memory, tools and logs, and each can be hosted differently.
• Self-hosting gives you control over location, network boundaries and upgrade timing. It does not make the agent safe or compliant by itself.
• The maintenance load is the cost people underestimate. Patching, integration repair, monitoring and access reviews do not disappear in either model.
• Choose the hosting model for a reason you can write down, and name the event that would make you revisit it.
• Whatever you choose, keep your instructions, memory and configuration exportable so the decision stays reversible.

What do self-hosted and cloud AI agents actually mean?

The phrase sounds like a single switch, but an agent is several parts working together. There is the model that generates language and reasoning. There is the runtime, sometimes called the harness, that decides what the model sees, which tools it may call and what gets recorded (see what an AI harness is for a plain description). There is memory, the set of tools and integrations, and the logs that show what happened.

A cloud agent usually means a vendor runs most or all of those parts for you, and you reach them through an account and an interface. A self-hosted agent means you run the runtime, memory, tools and logs on infrastructure you control, which can be your own servers or your own account at a cloud provider. The model is often the exception: many self-hosted setups still call a model through an external service, because running a capable model locally takes specialized hardware and expertise.

That is why the useful question is not which model is better. It is which parts of the agent must sit inside your boundary, and which parts you are happy to rent. A hybrid answer is common and often the most sensible: memory and logs in an environment you control, model access through a provider under a clear agreement.

What does control actually buy you?

Control is the main argument for self-hosting, so it helps to be exact about what it covers.

• Data location. You decide where memory, documents and logs are stored, which matters when a contract or a regulator specifies it.
• Network boundaries. The agent can sit inside a private network and reach internal systems without exposing them to the public internet.
• Change timing. Updates to the runtime and its tools happen when you approve them, not when a vendor ships them.
• Inspectability. You can read the configuration, query the logs and show an auditor how the agent is wired.
• Independence. If a vendor changes terms or disappears, the parts you hosted keep running.

What control does not buy you is security. A self-hosted agent with broad credentials, no review process and unpatched components is less safe than a well-run hosted one. Security comes from narrow permissions, tested behavior and someone watching the system, and those are choices you must make in both models. The guidance in least privilege for AI agents applies equally wherever the agent runs.

Control also has a data-ownership side that is separate from hosting. Even in the cloud, you can insist that your prompts, memory and configuration remain yours and can be exported. Who owns your AI prompts, memory and data covers what to put in writing.

How heavy is the maintenance load?

This is where self-hosting decisions most often go wrong. The licence or setup cost is visible. The recurring work is not, and it falls to someone on your team or a partner.

A self-hosted agent needs, at minimum:

• Patching of the operating system, runtime and dependencies.
• Backups and a tested way to restore memory and configuration.
• Monitoring that tells you when the agent is failing, slow or behaving oddly. The [OpenTelemetry observability primer](https://opentelemetry.io/docs/concepts/observability-primer/) is a good reference for what to collect.
• Repair of integrations when an external system changes its interface.
• Regular evaluation of the agent's output, especially after a model or instruction change.
• Periodic review of who and what has access.
• An incident process for the day something goes wrong.

A cloud agent moves the first few items to the vendor. It does not remove the last four. Someone on your side still has to decide what the agent may touch, check that its work is correct and respond when a connected system changes. A vendor can keep the platform running while your workflow quietly degrades, because the platform cannot know what correct looks like for your business.

The honest comparison is therefore not maintenance versus no maintenance. It is which maintenance you do yourself and which you pay someone else to do. The total cost of owning an AI agent walks through how to count these costs beyond licences.

Where does compliance push the decision?

Compliance is the second reason people consider self-hosting, and it is often misunderstood. Most obligations attach to what you do with data and how you can demonstrate it, not to where a server sits.

Three questions usually matter more than the hosting label:

• What personal or confidential data does the agent process, and is it necessary for the role?
• Which parties handle that data, under what agreement, and in which regions?
• Can you show, on request, what the agent did, with what access and under whose approval?

Frameworks give structure to these questions. The [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) offers a way to map, measure and manage risk. The [EU Artificial Intelligence Act](https://artificialintelligenceact.eu/) sets obligations that vary by how an AI system is used. For companies handling personal data in Brazil, the [ANPD](https://www.gov.br/anpd/pt-br) is the authority to follow. This is not legal advice, and your counsel should confirm what applies to you.

In practice, a reputable cloud provider with a clear data processing agreement, a chosen region and audit logs can satisfy many requirements. Self-hosting becomes the stronger option when the rules or your customers demand that certain data never leave an environment you control, or when you cannot accept a third party in the chain at all. If you use a cloud provider, a structured review helps, and how to run a security review of an AI agent provider lays out the steps.

A decision guide you can use in one meeting

Work through these statements with the people who own the data, the risk and the operations. The first one that is true usually points to your starting model.

• If a contract, regulation or customer requires that specific data stay inside infrastructure you control, host the memory, logs and runtime yourself, and decide separately how to reach the model.
• If the agent must reach systems that are not exposed to the internet, run the runtime inside your network.
• If nobody on your side can own patching, monitoring and incident response, choose a hosted or managed arrangement, and write down who is responsible for each duty.
• If the role is low in data sensitivity and you want to learn quickly, start in the cloud with exportable memory and instructions.
• If you are unsure, start hosted, run the agent with read-only access first, and revisit once you know which data it really needs.

An illustrative scenario: a small accounting firm wants an agent to prepare draft summaries of client correspondence. Client files are confidential, and several clients have asked in their engagement terms that records stay in a named region. The firm has no technical staff. A fully self-hosted setup would satisfy the residency request but leave nobody to patch or monitor it. A pure vendor-hosted setup would be easy to run but would put client records wherever the vendor stores them by default. The workable answer is a hybrid: memory and logs in an account the firm controls in the required region, the runtime operated by a partner, and the model reached under an agreement that restricts how inputs are used. The stated reason is residency, and the recorded trigger for review is a change in the clients' terms.

If you are still deciding between building, buying or having someone operate the system, build, buy or managed AI agents is a useful companion to this guide.

What is a sensible step-by-step plan?

A hosting decision is easier to defend, and easier to change, when it follows a short process.

• Write the role in one paragraph: what the agent does, for whom, with which systems.
• List the data it will touch and mark anything personal, confidential or contractually restricted.
• Record every external requirement that affects location or access: contracts, regulations, customer terms.
• Decide which parts of the agent must stay inside your boundary: runtime, memory, logs, tools, model access.
• Name an owner for each recurring duty: patching, monitoring, evaluation, integration repair, access review, incident response.
• Choose the hosting model and write one sentence stating the reason.
• Define the exit: what you can export, in what format, and how fast you could move. An AI provider exit strategy describes what to keep and document.
• Set a review trigger, such as a new data type, a new regulation, a change in team capacity or a change in vendor terms.

The written reason and the review trigger are the parts people skip. Without them, a hosting model hardens into habit, and a decision made for one constraint keeps governing long after that constraint has gone.

How does Be Human handle the hosting question?

Be Human treats hosting as part of the first engagement, not as a technical afterthought. The same session that defines one useful role also defines the memory and tools it needs, the approval boundaries and an observable success criterion, and the hosting model is chosen against those facts. Where the requirement is control, components can be placed in an environment the company controls. Where the requirement is speed and low operating burden, they can be hosted. Either way, Be Human can operate the system remotely, covering monitoring, recurring evaluations, integration maintenance, permission review and incident response, so that the choice of hosting does not leave the maintenance load without an owner. The company keeps its agent's identity, memory and configuration under human control and documented for export.

Frequently asked questions

Is self-hosting an AI agent more secure than using the cloud? Not automatically. Security depends on narrow permissions, patching, monitoring and review, and a poorly maintained self-hosted system can be weaker than a well-run hosted one. Self-hosting gives you more control over where things run, which helps when you have a specific requirement, but you must supply the discipline yourself.

Can we self-host the agent but still use a cloud model? Yes, and it is a common arrangement. The runtime, memory and logs stay in an environment you control, while the model is reached through a provider under an agreement that covers how your inputs are handled. Running a capable model entirely on your own hardware is possible but demands specialized resources, so many companies only do it for the most sensitive work.

What if we start in the cloud and later need to self-host? That is manageable if you planned for it. Keep instructions, memory and tool configuration in formats you can export, avoid depending on features only one vendor offers, and record the trigger that would prompt a move. Moving later is far harder when the agent's knowledge lives only inside a vendor's interface.

Who is responsible for compliance, us or the provider? Usually both, in different ways. The provider is responsible for how it handles data on its platform, and you are responsible for what data you send, what access you grant and how you supervise the agent. Put the split in writing and ask your counsel to confirm which rules apply to your situation.

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