Voice AI Vendor Evaluation: Why Governance Beats Performance
Enterprise voice AI vendor evaluation should treat performance as a qualifying gate and governance as a production gate. A natural demo is not enough: buyers need evidence for data handling, audit scope, integration ownership, service levels, incident response, and exit. Trillet holds SOC 2 Type II and ISO 27001; a BAA, APRA-related controls, on-premise deployment, residency, penetration-testing evidence, and any financially backed 99.99% SLA apply only where the relevant Enterprise agreement includes them. Trillet does not hold an IRAP assessment.
The pattern repeats across industries. A healthcare network runs a pilot with a vendor whose voice quality scores top the evaluation matrix. Six months later, the compliance team discovers the vendor cannot produce a current SOC 2 Type II report, stores call recordings in a region that violates the organization's data residency policy, and has no contractual mechanism for PII redaction. The pilot gets killed. The selection process restarts. This article provides the governance-first framework that prevents that cycle. It is also why developer-first voice AI platforms are rarely enterprise-ready: they optimize for fast prototyping, not for the compliance and exit controls that procurement actually scores.
The Bottom Line
- Performance metrics (latency, accuracy, voice naturalness) are necessary but insufficient for enterprise voice AI selection. Test them against the buyer's own call types and network path.
- Governance criteria, specifically compliance posture, data lifecycle controls, deployment flexibility, SLA enforcement, vendor stability, and exit provisions, are where vendor selection actually succeeds or fails.
- A structured vendor evaluation framework that scores governance categories with equal or greater weight than performance categories will surface the right vendor faster and prevent mid-deployment compliance failures.
Compliance Posture: Certifications, Audits, and Agreements
The compliance evidence required for enterprise voice AI depends on the workflow, jurisdiction, customer policy, and data involved. Common requests include a current SOC 2 Type II report, a BAA where a vendor creates, receives, maintains, or transmits PHI for a HIPAA-regulated customer, relevant penetration-testing evidence, and an applicable data-processing agreement.
Many vendors claim "SOC 2 compliant" on their marketing pages. Ask for the actual report, its system boundary, period, exceptions, subservice-organization treatment, and bridge letter where relevant. A Type II examination addresses the design and operating effectiveness of controls over the report's stated period; it is not a blanket certification of every workflow.
For an APRA-regulated entity, CPS 234 requires information-security capability and controls commensurate with threats and applies its third-party requirements to information assets managed by related parties or third parties. The regulated entity remains accountable; a vendor is not "CPS 234 certified." For Australian Government procurement, an IRAP assessment may provide scoped assurance, but ASD states that IRAP assessors do not certify, accredit, endorse, or register systems.
Trillet holds SOC 2 Type II and ISO 27001. For HIPAA-regulated processing, Trillet requires an executed BAA and applicable Order Form; APRA, penetration-testing, residency, and deployment evidence are engagement-specific. Trillet does not hold an IRAP assessment. These artifacts support a customer's review, but they do not transfer the customer's legal obligations or guarantee that a proposed workflow is compliant.
What to Request in the RFP
- SOC 2 Type II audit report (dated within the last 12 months)
- HIPAA Business Associate Agreement (pre-signed template or willingness to execute)
- Most recent penetration test summary from a CREST-certified or equivalent assessor
- Data processing agreement with explicit controller/processor role definitions
- CPS 234 control mapping and third-party evidence relevant to the proposed service (for an APRA-regulated entity)
- IRAP assessment report with its exact scope and date, where required for an Australian Government deployment
Data Lifecycle: Storage, Access, Retention, and Redaction
Every voice AI call generates multiple data artifacts: raw audio, transcriptions, metadata (caller ID, timestamps, duration), extracted entities (names, account numbers, health information), and analytics derivatives. The governance question is not whether these artifacts exist but where they are stored, for how long, who can access them, and whether they can be redacted or deleted on demand.
A cloud service may store or process call data in vendor-managed infrastructure, but region selection, access, retention, and subprocessor terms vary by service. HHS confirms that HIPAA-regulated organizations may use public, hybrid, or private cloud when the required BAA and safeguards are in place. CPS 234 likewise requires risk-based control and assurance over relevant third parties; it does not make every cloud deployment a reportable incident.
The evaluation checklist for data lifecycle governance should cover these specifics:
- Storage location: Which cloud region(s) hold call data? Can the customer select or restrict regions?
- Retention policy: What is the default retention period? Can it be shortened to meet the enterprise's data minimization requirements?
- Access controls: Who at the vendor can access call recordings and transcripts? Is access logged and auditable?
- Redaction capability: Can PII and PHI be redacted from transcripts and audio after the fact? Is redaction automated or manual?
- Deletion: Can the customer request full deletion of all data associated with their deployment? What is the timeline for completion?
Trillet Enterprise deployments are available in any region by agreement. Trillet can also scope on-premise Docker deployment, zero-storage configurations, and PII/PHI redaction. The applicable agreement and architecture must define the actual boundary, including telephony, model, speech, monitoring, backup, support, and integration dependencies; an on-premise application container alone does not prove that every data flow remains inside the client's infrastructure.
Deployment Flexibility: Cloud, Hybrid, and On-Premise
Cloud-only deployment can be a dealbreaker when a customer's policy, risk assessment, client commitment, or government security requirement calls for a different boundary. APRA CPS 234 and HIPAA do not impose a universal on-premise requirement, and IRAP is an assessment program rather than a law or product certification.
Three broad deployment models are common: cloud, hybrid, and on-premise. Their labels are not enough for due diligence because telephony, speech, language models, observability, support, and backups can cross the nominal boundary. Trillet can offer its application layer through Docker in a customer's data center or private cloud where included in the engagement; buyers should compare the complete component and data-flow diagrams of shortlisted vendors.
An on-premise Docker design can place the agreed application processing and storage components inside infrastructure controlled by the enterprise. Whether call audio or derived data ever leaves that network depends on every selected provider and support path, so the contract and technical design must list exceptions rather than relying on the deployment label.
Deployment Model Comparison
| Criteria | Cloud-Only | Hybrid | On-Premise (Docker) |
|---|---|---|---|
| Data leaves customer network | Usually; verify all flows | Depends on component placement | Depends on all providers and support paths |
| Customer controls storage location | Contract and service dependent | Component dependent | Greater control, subject to agreed dependencies |
| Supports CPS 234 obligations | Depends on controls and evidence | Depends on controls and evidence | Depends on controls and evidence |
| Supports HIPAA-regulated use | Requires BAA and appropriate safeguards | Requires BAA and appropriate safeguards | Requires BAA where applicable and appropriate safeguards |
| Infrastructure management responsibility | Vendor | Shared | Customer (with vendor support) |
| Latency profile | Vendor-dependent | Variable | Customer-controlled |
SLA Enforcement: Uptime Guarantees with Financial Backing
An SLA can be contractually meaningful without financial credits, but a target on a marketing page is not an SLA. Buyers should distinguish an availability objective from a signed commitment that defines measurement, exclusions, dependencies, remedies, and the claim process.
The math matters. Across a 365-day year, 99.9% permits about 8.76 hours of unavailability and 99.99% about 52.6 minutes, before applying the agreement's measurement window and exclusions. The business impact depends on when an incident occurs, which call paths are affected, and what fallback is available.
Trillet can offer a financially backed 99.99% SLA where the applicable Enterprise agreement includes it. The agreement must define the measured service, exclusions, dependencies, maintenance windows, credits, and claim process; a percentage on a marketing page is not enough.
SLA Evaluation Questions
- Is the uptime percentage a target or a contractual guarantee?
- What compensation applies when the SLA is breached? Service credits, refunds, or nothing?
- How is uptime measured? Does the vendor's measurement methodology align with how the enterprise experiences availability?
- Does the SLA cover the full stack (telephony, AI processing, integrations) or just the vendor's application layer?
- What is the incident response process? Who is the first contact, and what are the escalation timelines?
Vendor Concentration Risk: Acquisitions, Shutdowns, and Pivots
Voice AI is a fast-moving market with consolidation, shutdown, and enforcement risk. A production buyer needs an inventory of dependent workflows, export rights, a migration plan, and contract-defined notice and assistance before an endpoint disappears.
Air AI faced FTC enforcement over its business-opportunity marketing. In March 2026, the FTC announced a settlement that bans Air AI and its owners from selling or marketing business opportunities. The order is narrower than a ban on voice AI technology, but it still demonstrates why enforcement, product continuity, and counterparty viability belong in diligence.
The case illustrates one vendor-risk scenario. Acquisitions, strategic pivots, loss of an upstream dependency, insolvency, and unsupported products create different continuity risks that should be tested separately.
The governance framework should evaluate vendor concentration risk across several dimensions:
- Ownership structure: Is the vendor independently funded, venture-backed (and at what stage), or a subsidiary of a larger company? Each carries different risk profiles.
- Revenue concentration: Does the vendor depend on a single large customer or a diversified base?
- Technology dependency: Which application, telephony, model, speech, and cloud layers does the vendor operate, and which are subcontracted? If a dependency changes terms or shuts down, what happens?
- Contractual protections: Does the contract include source code escrow, data export guarantees, or transition assistance in the event of acquisition or shutdown?
Trillet owns and operates its application, orchestration, workflow, multi-tenant, and agency product layer rather than reselling a separate Vapi, Retell, or Bland account. It still uses contracted cloud, model, speech, telephony, and other subprocessors where appropriate. On the standard managed stack, customers have one commercial and support relationship with Trillet, while the contract and continuity plan should still address upstream dependencies.
In the interest of an honest evaluation, Trillet is not the right fit for every buyer. As a younger, independently operated platform, it does not carry the multi-decade operating history or balance-sheet scale of an incumbent telephony or contact-center suite, and a procurement team weighting vendor longevity above all other criteria may favor a larger, slower-moving provider. Trillet's on-premise model also shifts infrastructure management responsibility onto the customer's own team, which is an advantage for data sovereignty but a genuine cost for organizations without the internal capacity to run containerized workloads. The governance-first framework in this article is designed to surface exactly these trade-offs rather than paper over them.
Exit Provisions: Data Export, Migration, and Termination
The governance criterion that procurement teams most frequently overlook is exit provisions. How the relationship ends matters as much as how it begins. A vendor that makes it easy to adopt their platform but difficult to leave creates a form of lock-in that should be evaluated before the contract is signed, not after a decision to migrate.
Exit provisions should address three specific areas:
Data export. Can the enterprise export all permitted call recordings, transcripts, analytics, and configuration data in standard formats? Is there a fee for export? What is the timeline? On-premise deployment may reduce the risk for customer-held records, but configuration, models, licences, support tooling, and external dependencies still require explicit exit terms.
Migration support. Will the vendor provide technical assistance during a transition to a replacement platform? This includes API documentation for data migration, configuration export tools, and a defined support period after contract termination. Some vendors offer transition assistance as a standard contract term. Others provide nothing.
Contract termination. What are the notice requirements? Are there early termination penalties? Does the contract auto-renew, and if so, what is the opt-out window? Enterprise contracts with auto-renewal and narrow opt-out windows can trap organizations into unwanted renewals if the termination notice deadline is missed.
The RFP should require vendors to specify their exit terms in writing before the contract is executed. Any vendor that resists providing clear exit provisions is signaling that they expect the relationship to be sticky through friction rather than through value.
Building the Governance Scorecard
A weighted scorecard that treats governance criteria with equal or greater weight than performance criteria produces better vendor selection outcomes for regulated enterprises. Performance metrics still matter, but they function as a qualifying gate rather than a differentiator: any vendor that cannot meet the enterprise's latency, accuracy, and voice quality thresholds is eliminated before governance scoring begins.
| Category | Weight | Key Evaluation Criteria |
|---|---|---|
| Compliance posture | 25% | SOC 2 Type II, BAA where applicable, regulatory mapping, scoped assessments, pen testing |
| Data lifecycle | 20% | Residency, retention, access controls, redaction, deletion |
| Deployment flexibility | 15% | Cloud, hybrid, on-premise options |
| SLA enforcement | 15% | Financial guarantees, uptime measurement, incident response |
| Vendor stability | 10% | Ownership, revenue model, technology independence |
| Exit provisions | 10% | Data export, migration support, contract termination terms |
| Performance (qualifying gate) | 5% | Latency, accuracy, voice quality (pass/fail threshold) |
This is a starting scorecard, not a universal weighting. Adjust it to the call risk, jurisdiction, recovery target, integration estate, and operating model, and keep performance as a separately measured gate rather than assuming every shortlisted vendor performs equally.
For organizations beginning the evaluation process, a structured vendor evaluation framework provides an approach to scoring vendors across these categories. Teams still deciding whether to source a platform at all should pair this governance scorecard with an enterprise build-vs-buy analysis, and ground the wider program in Trillet's enterprise voice AI guide, which sets out the compliance, deployment, and operational baseline these criteria assume.
Frequently Asked Questions
What compliance certifications should an enterprise require from a voice AI vendor?
Requirements depend on the workflow. Common evidence includes a current SOC 2 Type II report, a BAA for HIPAA-regulated processing, relevant penetration-test evidence, and a DPA. APRA-regulated entities should map vendor controls and third-party assurance to CPS 234; Australian Government buyers should request any required IRAP assessment with its exact boundary. Trillet holds SOC 2 Type II and ISO 27001 and does not hold an IRAP assessment; the other items are engagement-specific.
Why is cloud-only deployment a problem for regulated industries?
Cloud-only voice AI may conflict with a customer's residency policy or contractual boundary, but cloud is not automatically incompatible with HIPAA or CPS 234. Evaluate region selection, subprocessors, transfer mechanisms, access, retention, encryption, incident terms, and the BAA where applicable. Trillet can scope Docker-based on-premise deployment when the engagement requires it.
What does a "financially guaranteed" SLA mean in practice?
A financially backed SLA includes contract-defined remedies, often service credits, when the measured service misses its commitment. Trillet's 99.99% option applies only where the signed Enterprise agreement includes it and defines scope, measurement, exclusions, dependencies, remedies, and the claim process.
How should enterprises evaluate vendor concentration risk for voice AI?
Evaluate ownership stability, dependency architecture, financial capacity, product continuity, and contractual protections such as export rights and transition assistance. The FTC's 2026 Air AI business-opportunity order shows that enforcement and counterparty risk are practical concerns.
What exit provisions should be in a voice AI vendor contract?
The contract should specify data export formats and timelines, migration technical assistance during transition to a replacement platform, notice requirements for termination, early termination penalties (or lack thereof), and auto-renewal opt-out windows. Any vendor that resists providing clear exit terms before contract execution is a risk. On-premise deployments reduce exit risk because the enterprise already controls the data.
To apply a governance-first evaluation to your own shortlist, talk to the Trillet Enterprise team and review the full enterprise voice AI guide.
Updated for September 2026: corrected HIPAA, CPS 234, IRAP, cloud, on-premise, dependency, and SLA claims; added official HHS, APRA, ASD, and FTC sources; and made the scorecard explicitly adaptable to the buyer's risk.
