I keep seeing architecture reviews begin with the same question: “Which deployment model is compliant?”
That sounds decisive. It is usually where the confusion starts. A better opening is: “Which parts of voice agent monitoring may process which data, in which environment, under whose operational control?”
That distinction matters because a voice monitoring system can touch recordings, transcripts, phone numbers, prompts, tool traces, QA findings, reviewer notes, exports, and support logs. A “private” label tells you almost nothing about where those artifacts go. And “self-hosted” can still hide an outbound model API, support tunnel, crash reporter, or backup.
Voice agent monitoring deployment models define where monitoring software runs, where call evidence is processed and stored, who operates each component, and which parties can access the resulting data.
TL;DR: Draw the evidence path first. If managed SaaS can meet every written constraint, take the operational simplicity. Move to a vendor-hosted private tenant for dedicated resources, to BYOC for customer-cloud controls, or to self-hosting when the customer must operate the whole stack. Hybrid is useful when raw evidence must stay customer-side but limited results may leave. Each step toward customer control also hands the customer more work.
This is an architecture decision guide, not legal advice. Your legal, security, privacy, and compliance owners still need to determine which requirements apply to the actual voice-agent use case.
Methodology Note: This comparison is based on Hamming's analysis of production voice agent monitoring and enterprise security-review workflows across 10K+ voice agents (2025-2026). We've tested agents built on LiveKit, Pipecat, ElevenLabs, Retell, Vapi, and custom-built solutions.The decision rules are also grounded in public HHS, NIST, PCI Security Standards Council, and European Commission guidance cited below. They are architecture-review prompts, not universal compliance conclusions.
Last Updated: September 2026
Related Guides:
- Voice Agent Security Review Questions - the full vendor questionnaire and evidence request list
- Voice Agent Log Retention Checklist - retention, deletion, legal hold, and audit lifecycle decisions
- PII Redaction Compliance Architecture - sensitive-data boundaries for audio and transcripts
- Call Logging for Voice Agents - a taxonomy for call records, traces, and metadata
- Voice Agent Monitoring Platform Guide - broader monitoring capability and vendor criteria
- SOC 2 Voice Agent Testing - control evidence and enterprise procurement basics
- Voice Agent Production Readiness - launch gates before real callers enter the system
- Voice Agent Incident Response - evidence and ownership during customer-impacting incidents
Does a Regulated Voice Agent Need Private or Self-Hosted Monitoring?
Not automatically. “Regulated” describes obligations and risk, not a single infrastructure diagram.
HHS cloud guidance explicitly says a HIPAA covered entity or business associate may use public, hybrid, or private cloud configurations when the arrangement otherwise meets HIPAA requirements, including an appropriate business associate agreement and risk analysis. The cloud configuration changes the risk analysis; it does not replace it.
The same requirements-first principle travels well beyond healthcare. The NIST AI Risk Management Framework Playbook organizes AI risk work around Govern, Map, Measure, and Manage. Its governance guidance asks organizations to document legal requirements, risk tolerance, roles, and lifecycle responsibilities. It does not prescribe one hosting label for every AI system.
The EU AI Act is also risk-based. The European Commission's overview distinguishes obligations by the AI system's risk and use. A voice agent is not automatically high-risk merely because it uses speech or because its monitoring system stores traces.
Deployment rule: Do not promote a preference such as “private cloud” into a requirement. Write down the data, threat, contractual term, jurisdiction, or recovery objective behind the request. If nobody can name one, the team has a hunch, not an architecture constraint.
Before Comparing Models, Draw the Agent and Monitoring Boundaries
The agent runtime and the monitoring platform are related systems. They do not have to live in the same kind of environment.
For example, an agent can run in a customer VPC while sanitized monitoring metadata goes to SaaS. The reverse split is possible too: the agent uses managed providers, but recordings and transcripts remain in customer-owned storage. A self-hosted dashboard may still query a vendor-hosted model. A private tenant may still export alerts into a shared ticketing service.
Map these four planes separately:
| Plane | What It Does | Voice Data It May Touch | Questions to Resolve |
|---|---|---|---|
| Collection plane | receives webhooks, media events, call records, transcripts, and traces | caller identifiers, audio pointers, transcript text, provider IDs | Does raw media cross the boundary? Is redaction before or after ingestion? |
| Processing plane | evaluates calls, clusters failures, generates scores, and runs search | transcripts, prompts, tool evidence, model inputs and outputs | Which model and analytics subprocessors process content? In which regions? |
| Evidence plane | stores recordings, transcripts, traces, scores, and reviewer notes | raw and derived call evidence | Who owns storage, keys, lifecycle rules, backups, exports, and deletion? |
| Control and support plane | handles identity, configuration, upgrades, support, and diagnostics | tenant metadata, admin logs, sampled diagnostics, support attachments | Can vendor staff reach customer data? How is access approved, limited, and audited? |
If a vendor diagram shows only the application box and database, it is incomplete. Ask where authentication logs, telemetry exporters, crash reports, backups, model calls, and support tools sit too.
SaaS vs Private Tenant vs BYOC vs Self-Hosted vs Hybrid
“Private tenant” is overloaded. Some vendors mean a dedicated environment in the vendor's cloud account. Others mean vendor software deployed into the customer's cloud account. Those are different control models, so this comparison separates them.
| Model | Typical Operating Boundary | Customer Control | Customer Operations Burden | Best Fit | Main Question |
|---|---|---|---|---|---|
| Multi-tenant SaaS | vendor account; logically isolated tenants | configuration, identity integration, retention policy, export | lowest | teams whose requirements can be met by vendor controls and contracts | Can the vendor prove tenant isolation and the full data/subprocessor path? |
| Vendor-hosted single tenant | dedicated vendor-managed application and data resources | stronger isolation and custom policy, but limited infrastructure ownership | low to moderate | teams needing dedicated resources without running the platform | Which resources are actually dedicated, and can vendor operators still access them? |
| BYOC or customer VPC | customer cloud account; vendor may operate software through delegated access | network, region, keys, storage, and access boundaries vary by design | moderate | teams needing customer-cloud controls with vendor-managed application operations | Who can change infrastructure, read data, rotate keys, and recover the service? |
| Self-hosted | customer cloud or on-premises environment; customer operates the stack | highest infrastructure and operational control | highest | explicit isolation, sovereignty, disconnected-network, or custom-control requirements | Can the customer patch, scale, monitor, back up, and support the system continuously? |
| Hybrid | sensitive evidence stays customer-side; limited metadata or evaluation results reach SaaS | high control over raw evidence; shared control over derived data | moderate to high | teams able to minimize the vendor data path without losing managed workflows | Are the exported fields truly sufficient for monitoring, search, and incident response? |
None of these rows is “most secure” in the abstract. A neglected self-hosted deployment can be riskier than a well-operated SaaS service. A dedicated database does not help if support exports unredacted transcripts into a shared ticket. A customer-managed key does not solve deletion if backups, indexes, and derived evaluations are outside its scope.
Control is not the same as assurance. Self-hosting gives a customer more ways to operate the system well—and more ways to neglect it. With a managed service, the customer has less machinery to run and more vendor evidence to verify.
Eight Questions I Would Put on the Architecture Whiteboard
Work through these in order. Keep vendor product names off the whiteboard until the constraints are visible.
- Which evidence classes may enter monitoring? Separate raw audio, unredacted transcript, redacted transcript, call metadata, prompt/tool trace, QA result, reviewer note, and aggregate metric.
- Which evidence is prohibited from leaving a boundary? Name the customer account, region, network, country, or controlled store. “Keep data private” is not testable.
- Does the restriction cover storage, processing, support access, or all three? A regional database does not prove regional model inference or support handling.
- Which third parties may process each class? Include speech, model, analytics, observability, backup, and support providers.
- Who must own keys, network policy, deletion, and export? “Customer managed” should map to specific administrative actions.
- What availability and recovery objectives apply? Decide who owns upgrades, incident response, backup restoration, capacity, and disaster recovery.
- What evidence must an auditor or customer receive? List access logs, deletion records, control reports, architecture diagrams, and responsibility attestations.
- Can a simpler model meet every written requirement? If yes, prefer it. Operational complexity is itself a reliability and security risk.
Use the answers as gates:
- Choose multi-tenant SaaS when vendor controls, contracts, regions, and evidence satisfy every constraint.
- Choose vendor-hosted single tenant when dedicated resources or stronger isolation are required but vendor operation remains acceptable.
- Choose BYOC when customer-cloud network, key, storage, or access ownership is required and delegated vendor operation is acceptable.
- Choose self-hosted when the customer must operate the complete runtime or external operation/egress is prohibited.
- Choose hybrid when raw evidence must remain customer-side but limited metadata or derived results may use a managed service.
Copy This Data-Flow and Constraint Worksheet
Fill one row for every evidence class. “Same as above” is a warning sign because audio, transcripts, QA scores, and aggregate metrics often need different controls.
| Evidence Class | Contains Sensitive Data? | Collection Location | Processing Location and Processor | Storage and Backup Location | Human Access | Retention and Deletion Owner | Hard Constraint |
|---|---|---|---|---|---|---|---|
| raw recording | yes / no | ||||||
| unredacted transcript | yes / no | ||||||
| redacted transcript | yes / no | ||||||
| call metadata | yes / no | ||||||
| prompt and tool trace | yes / no | ||||||
| QA result | yes / no | ||||||
| reviewer note | yes / no | ||||||
| aggregate metric | yes / no |
Then record the decision:
Chosen model:Decision owner:Applicable policies, contracts, and jurisdictions:Constraints that eliminated simpler models:Vendor-operated components:Customer-operated components:Approved subprocessors and regions:Support-access path:Recovery owner and objective:Evidence required before production:Re-review triggers:Keep this record beside the architecture diagram and vendor approval. Revisit it when a new model provider, region, recording store, support tool, or monitoring feature changes the data path.
Build a Shared-Responsibility Matrix Before Signing
The PCI Security Standards Council's cloud guidance makes a durable point: cloud security is shared responsibility, and operation, management, reporting, and evidence duties should be clearly assigned and acknowledged in writing. The guidance is supplemental rather than a substitute for current PCI requirements, but this responsibility principle applies to any sensitive monitoring architecture.
Start with this matrix and replace every “shared” cell with named actions:
| Responsibility | SaaS Default | Single Tenant / BYOC Question | Self-Hosted Default |
|---|---|---|---|
| application patching | vendor | who schedules and proves upgrades? | customer |
| infrastructure patching | vendor | vendor or customer cloud team? | customer |
| tenant/workspace access policy | shared | who provisions roles and reviews access? | customer |
| vendor support access | vendor-controlled, customer-reviewed | how is delegated access approved and revoked? | usually none unless explicitly enabled |
| encryption-key operation | vendor or cloud provider | vendor-managed, BYOK, or customer-operated? | customer |
| retention configuration | shared | who implements and verifies each evidence class? | customer |
| deletion execution and proof | vendor executes, customer requests/verifies | which stores and backups are in scope? | customer |
| backup and disaster recovery | vendor | who owns restore testing and recovery objectives? | customer |
| incident detection and notification | shared | which telemetry stays visible to each party? | customer, plus disclosed dependencies |
| control evidence | vendor provides; customer evaluates | who proves customer-cloud controls? | customer |
“Shared” cannot be the final answer. It should become “vendor rotates the application secret; customer rotates the customer-managed storage key; both test recovery every six months,” or another precise assignment approved by the responsible teams.
Evidence to Request Before Approving the Model
Ask for artifacts, not adjectives.
| Claim | Evidence to Request |
|---|---|
| data stays in a region | data-flow diagram covering processing, storage, backups, support, and subprocessors |
| tenant is isolated | list of dedicated versus shared resources, identity boundaries, and isolation test evidence |
| customer controls keys | key hierarchy, administrative roles, rotation/revocation process, and outage behavior |
| support cannot casually access calls | approval flow, just-in-time access, audit-log sample, and break-glass policy |
| deletion is complete | store inventory, deletion workflow, backup treatment, and completion evidence |
| self-hosted works without vendor egress | dependency manifest, license/update path, telemetry settings, and disconnected-operation test |
| service is recoverable | backup scope, recovery objectives, restore-test result, and incident owner |
| vendor controls are audited | current report scope, exceptions, bridge coverage, and systems excluded from the audit |
For the broader due-diligence package, use the voice agent security review checklist. For lifecycle details, complete the voice agent log retention checklist after the architecture is selected.
Three Worked Deployment Patterns
Pattern 1: Managed SaaS With Minimized Evidence
The customer keeps recordings and unredacted transcripts in its controlled store. The monitoring service receives redacted transcript text, call/agent version IDs, timing, tool status, and QA outcomes. Reviewers use scoped links to request raw evidence only when authorized.
This pattern fits when managed operations matter and the monitoring job can work with minimized evidence. Its failure mode is accidental expansion: a new feature begins copying raw prompts, recordings, or support attachments into the managed boundary without re-review.
Pattern 2: Customer-Cloud Data Plane With Vendor Operation
Collectors, processing workers, and evidence storage run in the customer's cloud account and region. The vendor operates application upgrades through controlled access. A separate management plane may receive health and license metadata.
This pattern fits when the customer needs network, region, storage, or key control but does not want full application ownership. Its failure mode is ambiguous delegation: the customer assumes the vendor owns recovery while the vendor assumes the customer's cloud team owns it.
Pattern 3: Customer-Operated Self-Hosted Monitoring
The customer deploys, patches, scales, backs up, and monitors the complete system. Model inference, storage, identity, logging, update delivery, and support are reviewed for outbound dependencies. The customer owns incident response and control evidence.
This pattern fits a written requirement for customer operation, disconnected networks, or controls a managed vendor cannot provide. Its failure mode is treating installation as completion. Self-hosted software without an upgrade, restore, capacity, and on-call plan is not production-ready.
Red Flags in Deployment Model Discussions
- “Regulated means on-prem.” Ask which rule, contract, data class, or risk decision creates that requirement.
- “Single tenant means no shared infrastructure.” Ask which application, database, queue, storage, analytics, identity, and support components remain shared.
- “The database is in-region, so data residency is solved.” Ask where inference, logs, backups, exports, and human support processing occur.
- “We use customer-managed keys, so the vendor cannot access data.” Ask who can invoke decrypt operations and what plaintext the application or support workflow can see.
- “Self-hosted means no vendor dependency.” Test installation, licensing, updates, model calls, crash reporting, and support without outbound access.
- “Our certification covers it.” Verify that the exact service, region, deployment option, and responsibility boundary are in scope.
- “We delete customer data.” Require the store inventory, timing, backup behavior, derived-data treatment, and proof of completion.
The cleanest vendor answer is often, “Here is the diagram, here is the responsibility matrix, and here are the controls we cannot own for you.”
How Hamming Fits
Hamming is a managed voice-agent testing and monitoring platform with enterprise access controls, audit evidence, regional data options, and single-tenant options. The right configuration still depends on which call evidence you send, where it is processed, who needs access, and which contractual or policy constraints apply.
Use this worksheet during the Hamming security review too. Ask for the current data-flow diagram, deployment boundary, subprocessor path, retention behavior, support-access controls, and shared-responsibility model for the proposed configuration. Product labels should never replace architecture evidence.
Once the model is approved, connect it to three operating workflows:
- Define the evidence lifecycle with the log retention checklist.
- Prove the monitoring data path and access boundary with synthetic calls before production evidence enters it.
- Add the architecture and evidence owners to the incident response runbook.
Final Deployment Approval Checklist
- Every monitoring evidence class is mapped through collection, processing, storage, backup, support, and export.
- Legal, security, privacy, and compliance owners documented the requirements that apply to this use case.
- “Private tenant” is defined as vendor-hosted dedicated resources or customer-cloud deployment, not left ambiguous.
- The chosen model is the simplest one that meets every hard constraint.
- Vendor and customer duties are assigned by action, not labeled merely “shared.”
- Regions and subprocessors cover processing and human access, not only primary storage.
- Retention, deletion, backup, key, and support-access evidence has been reviewed.
- Recovery and upgrade ownership is tested before production launch.
- A synthetic call proves the actual boundary and audit trail.
- Architecture changes have named re-review triggers.
The decision is complete when the team can explain not only where the monitoring platform runs, but also where every evidence class goes, who can act on it, and who proves the controls keep working.
