Private cloud or self-hosted: how to choose your AI agents' deployment
Where to deploy an agent by data, team, and audits: three places, four frameworks, and a checklist to decide.

The useful question is not which option sounds more modern. It is where the agent has to run: which data it touches, who really operates it, what the full stack costs, and what the rules require. In a SaaS that sells in Europe, the deployment place is not an infrastructure detail. It is part of the product decision.
This article compares three usual options: managed cloud, private cloud, and self-hosted, to see what you gain, what you give up, and which responsibilities appear in each.
The question is not which one is more modern
In a demo it does not matter where the agent is deployed. In a real environment it does: where data is stored, whether the call to the model leaves the company's network, and whether the industry and region where the company operates require specific audits, security, and confidentiality.
If, in the rush for agility, we say that "the cloud is faster", we are really making a strategic and infrastructure decision in a hurry. Sooner or later you have to settle where the data lives, who operates the system, what level of control exists, and which requirements the product must meet.
Three places, three trade-offs
Managed cloud
Another company operates the model on its own servers and gives the customer an account, an API key, and terms and conditions to use it. It fits when what holds you back is time and there is no specialized in-house team: the value is in solving the use case, not in standing up and maintaining servers.
The model, the record, and in some cases memory may live on that provider's machines. Before using it with customer data, it is worth knowing the region where information is processed, who can access it, how deletion is handled, and what records the service provides.
Managed cloud brings speed and reduces operational load, but it also means giving up some direct control over infrastructure. The contract must make clear what happens to the data, which providers are involved, and how incidents are handled.
Private cloud
In a SaaS, a private cloud is usually a VPC: a logically isolated virtual network with its own access and egress rules, inside AWS, Google Cloud, or Azure. You still rent machines, but the company can control better who gets in, what traffic may leave for the internet, and which region runs the system.
In exchange for greater isolation and security, you take on extra maintenance, updates, and security management. Even so, software companies often choose a hybrid setup: they keep the application in a private cloud and use frontier models served by third parties such as Anthropic, OpenAI, or Gemini.
That architecture choice only protects what does not leave the network. If requests go to an external API, the customer's text and the context needed to generate the answer leave that network.
When confidentiality and control are the priority, another option is models deployed in a private cloud as well and served by the cloud provider itself, through products such as Amazon Bedrock, Google Vertex AI, or Azure OpenAI Service. In these architectures, identity and permission policy matters especially: it must define what each component of the system may read or execute.
On your own machines: self-hosted and on-premise
Self-hosted means the company installs and operates the program on its own. If the hardware is on its own premises, people say on-premise. In this model the company decides where data is stored, how the disk is protected, and who has access to the infrastructure.
It also takes on the responsibilities managed cloud reduces: updates, capacity, backups, monitoring, incident response, and having a team available to operate the system.
To run models locally there are tools such as Ollama, LM Studio, or Jan, which let you download and serve certain models on your own hardware. They are useful for development, tests, or cases where data must not leave the company's infrastructure. In production, beyond choosing the model, you need to weigh performance, resource use, maintenance, and operational capacity.
Self-hosted makes sense when data cannot leave, when the buyer requires it in the tender, or when the company already operates similar systems. It does not make sense as a gesture: infrastructure that nobody updates or watches is a risk with a different address.
What the rules require, and what they do not choose for you
The place does not replace the rules, and the rules do not say you must use a specific cloud. What matters is being able to show which data is processed, who accesses it, where it is processed, how incidents are managed, and what record remains of operations.
The AI Act, the GDPR, Spanish data protection law, the ENS when it applies, and frameworks such as ISO 27001 can impose different requirements depending on the use case, sector, and contract. A private cloud does not automatically make a system compliant, just as self-hosted does not by itself guarantee security or confidentiality.
The decision should be reviewed with legal, security, and platform teams. This article is a product and infrastructure guide, not legal advice.
By sector and team maturity
Situation | Place that usually fits | What is usually too much |
|---|---|---|
An internal process, with no sensitive customer data | Managed cloud | Standing up servers for an alert between tools |
A SaaS with customer data in the European Union | Managed cloud only with a contract for region, deletion, and processors; otherwise the program in a private network | Assuming that "private" in the plan's name is enough |
The model cannot leave the company's network | Program and model in the private network or on your own machines | Calling a public API just to try |
A public buyer, or a tender that cites the ENS | The place you can evidence: region, access, record, and separation | Choosing on-premise the same day, with no team to operate it |
You already operate critical systems and the agent is part of the product | Your own machines or private network, with the same team | A second product that nobody inherits at six months |
Maturity weighs as much as sector. A platform team can operate the agent on its own network. A small software company, with the same kind of data, may struggle if it starts by managing all the infrastructure. Data sets the minimum required. The team sets the maximum you can sustain.
Cost is not just the model bill
The price per use of the model is the visible line, not the full cost of the place. In managed cloud you pay for the service and the model, but also human review, integration, and the team that defines the case. In a private cloud you add machines, observability, and platform hours. On your own machines, the software may be open, but operations and payroll are not.
The full account depends on what a task done right costs. Changing place does not always cut cost: sometimes it only moves the bill from one line to another.
Where Devic fits
Devic is offered as a SaaS product so the customer does not have to take on the infrastructure needed to operate an agent. The customer can focus on defining the use case, tools, rules, and permissions, while Devic provides the managed environment.
The product works with models served from public clouds and with models deployed in private clouds or on-premise environments. That lets each organization choose the deployment model that best fits its data, security, operations, and compliance requirements.
When the priority is to move fast and there is no dedicated team to operate infrastructure, the SaaS model lets you launch the use case without standing up servers, managing updates, or maintaining the whole execution layer. The customer keeps control over the case, the actions, and the agent's rules.
For organizations that need more control over data or models, Devic can also integrate with models served from a private cloud or from the customer's own infrastructure. Its open source initiative also lets users who need it run their own harness without giving up control of the infrastructure.
In every model you still need sound identity, permission, and record management. Where the agent is deployed does not provide those guarantees on its own: they must be designed and operated as part of the product.
A checklist for choosing
Question | If the answer is no |
|---|---|
Do you know what personal data enters the task, and which customer it belongs to? | Do not choose a place yet. Close the case first. |
Do you know whether the call to the model leaves the company's network? | Do not call that deployment "private". |
Does the contract or tender state region, deletion, and who processes the data? | Managed cloud is not chosen yet. |
Is there a person who will operate this place within six months? | Do not take the program home yet. |
Can you show one task, with the action, the data, and the result, without opening the chat? | The place does not matter: you cannot audit it. |
Do you know in how many weeks you can migrate the program and the record if the provider stops fitting? | You are choosing a lock, not a place. |
If the answers hold, the next step is a short trial in the place the data allows, not the one that looks better on the slide. If two or more fail, the work is in the case, the contract, or the team. Moving the agent to another building does not replace that work.
Conclusion
Managed cloud is usually the fastest option to validate a use case. Private cloud offers more control over the network, access, and region, but demands more operations. Self-hosted and on-premise may be necessary when data cannot leave or the buyer requires it, although they shift full responsibility to the team that maintains them.
There is no winning deployment in the abstract. The right decision is the one that protects data, meets applicable requirements, and lets you operate the agent sustainably over the coming years.
Turn your SaaS AI-Native
Get a free trial just by signing up
Latest posts





