Before an AI employee touches sensitive enterprise data, screens a real transaction against a sanctions list, or reviews a clinical batch record, someone has to decide where the data that it touches actually lives, who controls the infrastructure, and what happens to the data in transit and at rest. That decision is the deployment model, and it usually settles a vendor shortlist faster than any other feature comparison. A bank with data-residency requirements or a pharma company operating under FDA 21 CFR Part 11 audit rules can rule out an otherwise strong platform if it only ships as public multi-tenant SaaS.
Zamp supports three deployment models: multi-tenant SaaS, BYOC (Bring Your Own Cloud), and on-premises. The right one depends on the job's data sensitivity, the buyer's existing cloud commitments, and how quickly the team needs to get to production.
In multi-tenant SaaS, Zamp hosts and operates the infrastructure, and each AI employee runs inside Zamp's cloud environment, isolated from other customers by account-level boundaries. This is the fastest path to production: there is no infrastructure to provision, and platform updates ship centrally without a maintenance window on the customer's side.
BYOC deploys the same AI employee platform inside the customer's own cloud environment, whether that is AWS, Azure, or GCP. Data never leaves an environment the customer already controls, and the customer keeps its existing network policy, key management, and audit logging infrastructure in place, while Zamp continues to operate and update the agent logic running inside it.
This is the model most regulated enterprises prefer. It answers the data-location question a compliance team will ask in the first meeting, without the longer timeline of a fully on-premises rollout.
On-premises deployment runs entirely inside the customer's own data center, with no external network path. This is the highest-control and maximum secure option, built for organizations whose data cannot leave their own infrastructure under any circumstances. It is also the longest setup of the three, since it depends on the customer's infrastructure team to provision and maintain the environment the agent runs in.
Deployment model just decides where the agent's compute runs. Integration surface, which is a separate decision, decides what it can reach, and if it works the same way across all three models.
Usage is metered in Agent Compute Units, the same way regardless of which deployment model or integration path a given job uses.
Deployment model does not cap how far volume can scale. In production, weekly throughput on a single job has grown more than tenfold within seven weeks without any change to the underlying deployment, because the deployment layer and the workload it carries are managed independently. The AI employee's operating context, its Agent Operating Procedure, keeps working the same way whether it is processing tens or thousands of cases a week; what changes is scheduling and compute allocation underneath it, not the deployment model itself.
Vendors in this category tend to lead with one default. Some lead with air-gapped, on-premises deployment as their headline differentiator; others lead with cloud-native deployment and a fast time-to-production as theirs. Zamp's position is that the right default is the buyer's, not the vendor's: supporting all three models means the deployment decision follows the data's actual sensitivity and the buyer's existing cloud commitments, rather than forcing every customer through the same infrastructure regardless of fit.
For the broader set of questions to ask before deploying an AI employee, see What is an AI employee? Definition, examples and complete guide.
