Deployment Models
Siesta AI can be operated as a managed SaaS service or deployed into a customer-controlled Azure environment. The functional platform can remain consistent while ownership of infrastructure, identity, networking, monitoring, and change approval differs.
Responsibility Comparison
| Area | Managed SaaS | Customer-controlled Azure |
|---|---|---|
| Azure subscription and resource lifecycle | Managed by Siesta AI | Customer-owned with agreed delivery responsibilities |
| Platform updates | Managed release process | Coordinated release and maintenance process |
| Network integration | Standard managed boundary | Customer VNet, DNS, firewall, and ingress integration |
| Identity | Customer SSO connected to managed service | Customer SSO plus Azure workload identities and RBAC |
| Secrets | Managed secure stores | Customer-approved Key Vault or secret store with named owners |
| Monitoring | Managed service monitoring | Shared or customer-owned monitoring and escalation |
| Backup and recovery | Managed service policy | Customer-specific RTO, RPO, retention, and recovery tests |
| Cost management | Included in service model | Azure budgets, sizing, quota, and cost ownership agreed with customer |
Selection Questions
Choose the deployment model after answering:
- Must runtime or data resources reside in the customer's Azure tenant?
- Are private endpoints, custom DNS, fixed egress, or customer SIEM integration required?
- Who can approve production changes and emergency access?
- Which team owns provider quota, model deployments, backups, and incident escalation?
- What availability, RTO, RPO, maintenance window, and evidence requirements apply?
- Which contractual or regulatory controls require customer ownership?
Document the final responsibility matrix before provisioning begins. Avoid assumptions such as "customer-hosted means customer-operated" unless the operating agreement assigns that work explicitly.