Voice agent consent testing is easy to under-test. A clean opening disclosure can pass while the campaign used the wrong consent record, ignored a spoken opt-out, or queued the same number again five minutes later.
That is the consent green-check illusion: the transcript looks compliant, but the system state is wrong.
Quick filter: An inbound FAQ agent that never records calls or initiates outreach probably does not need this runbook. Use it when an outbound AI voice agent depends on consent, identity disclosures, opt-out handling, or suppression rules that must survive real conversation paths.
Voice agent consent testing proves that an outbound AI voice program selected an eligible contact, used the right policy and disclosure, honored refusal or revocation, changed downstream campaign state, and preserved reviewable evidence.
TL;DR: Treat outbound consent as a versioned test contract, not a line in the prompt.
- Separate outreach consent, call-recording consent, and data-processing consent.
- Bind each campaign to a policy version and an approved consent source.
- Run eight synthetic calls, including missing, expired, mismatched, revoked, interrupted, and repeated-opt-out paths.
- Read back the suppression state outside the transcript.
- Save one evidence packet that joins the consent record, call, policy, opt-out event, and reviewer decision.
Last Updated: September 2026
Scope: This engineering runbook applies to outbound AI-generated or artificial-voice calls in the United States. It does not determine which law, exemption, jurisdiction, consent standard, or script applies to your campaign. Legal or compliance owners must define that policy before QA turns it into test cases.
The FCC's February 2024 declaratory ruling confirms that current AI-generated voices fall within the Telephone Consumer Protection Act's artificial or prerecorded voice restrictions. The FCC's robocall guidance also distinguishes consent and opt-out expectations by call type. Those distinctions are inputs to this runbook, not conclusions the test runner should invent.
Related Guides:
- Regulatory Script Adherence for AI Voice Agents for exact, semantic, and ordered disclosure checks
- Voice Agent Call Logging for the event schema behind audit evidence
- Voice Agent Compliance Analytics for reviewer queues and remediation history
- Voice Agent Security Review Questions for vendor access and data-flow review
- Customer Workflow Rules Testing Template for tenant-specific policy matrices
- Sandbox Testing for Tool Calls for safe side-effect verification
What Should Voice Agent Consent Testing Prove?
The test suite should prove a chain, not a sentence. A caller heard the right disclosure is one assertion. The campaign also needs evidence that the number was eligible before dialing, the agent reacted correctly during the call, and later call attempts respected the resulting state.
| Layer | Question to prove | Evidence | Failure action |
|---|---|---|---|
| Selection | Was this contact eligible for this campaign at dial time? | Consent record ID, purpose, channel, status, captured time | Block the call before dialing. |
| Policy | Did the call use the policy approved for this campaign and jurisdiction? | Policy ID and version | Quarantine the campaign version. |
| Conversation | Did the agent state required identity or disclosure content at the required time? | Transcript span and audio pointer | Fail the call-level assertion. |
| Revocation | Did the agent recognize an opt-out expressed in ordinary language? | Classified utterance, rule result, event timestamp | Stop the campaign interaction and create the opt-out event. |
| Suppression | Did downstream state prevent later outreach? | Suppression-list readback and second-attempt result | Stop the campaign and page the owner. |
| Audit | Can a reviewer reconstruct the decision without joining five dashboards? | Canonical evidence packet | Mark the run incomplete. |
Disclosure checks alone miss failures on either side of the conversation: a stale consent lookup before the call, or a suppression write that never reaches the dialer after it.
Separate Three Different Consent Questions
Do not use one boolean called consentGiven. It hides purpose, channel, scope, and lifecycle.
| Consent domain | What it governs | Example test question | Keep separate because |
|---|---|---|---|
| Outreach consent | Whether the organization may initiate this category of call | Does this record authorize this number, channel, campaign purpose, and time window? | Outreach eligibility may differ by campaign type or exemption. |
| Recording consent | Whether audio or transcript capture may begin or continue | Does recording start only after the configured notice or affirmative action? | Recording rules are not the same as permission to place the call. |
| Data-processing consent or other legal basis | How call data may be analyzed, retained, exported, or deleted | Does the data pipeline apply the configured purpose and retention class? | Storage and analytics can outlive the conversation. |
Consent domain rule: permission to place a call, permission to record it, and authority to process its data are different decisions. Test and version them separately, even when one customer interaction supplies more than one decision.
If a campaign needs all three, the evidence packet should contain three independently versioned decisions. If counsel says one domain is not consent-based, store the approved basis or exemption code instead of forcing a fake true value.
That separation also improves retention testing. Revoking one campaign permission should not silently delete records under a legal hold, and a retention exception should not re-enable outreach.
Build the Policy-to-Test Contract
Compliance or legal owners define the rule. QA makes the rule executable. Engineering connects it to the dialer, agent, and system of record.
Define the state readbacks that prove what happened before and after the call alongside the spoken-disclosure assertions.
| Contract field | Example value | Test use |
|---|---|---|
policyId | outbound_servicing_us_v4 | Stable identity for results and review. |
effectiveFrom | 2026-08-01T00:00:00Z | Reject calls evaluated against an inactive policy. |
campaignPurpose | account_servicing | Match the consent scope to the actual campaign. |
requiredConsentSource | customer_preference_center | Verify provenance, not only status. |
requiredOpeningIdentity | Approved entity name and callback number | Run exact or constrained semantic checks. |
optOutPhrases | Approved intent set, not a fixed phrase list | Test natural revocation language and interruptions. |
onOptOut | End outreach, write suppression, cancel queued attempts | Verify every side effect. |
evidenceRequired | Consent ID, call ID, policy version, transcript span, suppression readback | Fail closed when audit proof is missing. |
Keep this contract under version control or in a system with equivalent change history. The tests-as-code template is useful when engineering owns the suite; a governed policy registry may be better when compliance changes rules more often than application code.
Policy-to-test contract: every outbound rule needs a stable identity, effective period, owner, trigger, expected behavior, side effect, and evidence requirement. A prose policy becomes testable only when those fields are explicit.
Run the Eight-Call Minimum Launch Suite
Eight calls are not a legal completeness standard. They are the smallest useful engineering suite for proving the main state transitions before a campaign launches.
| Test call | Starting state | Caller behavior | Expected result | Required readback |
|---|---|---|---|---|
| 1 | Valid consent for exact purpose | Continues normally | Required identity or disclosure passes; call proceeds | Policy version and consent record joined to call. |
| 2 | Valid consent | Requests opt-out clearly | Agent acknowledges; outreach stops | Suppression entry exists and queued attempts are canceled. |
| 3 | No consent record | N/A because call should not start | Dial is blocked | Block reason stored before telephony initiation. |
| 4 | Expired or revoked record | N/A because call should not start | Dial is blocked | Latest record wins; stale cache is not used. |
| 5 | Consent for a different purpose or number | N/A because call should not start | Dial is blocked | Scope mismatch identifies the conflicting field. |
| 6 | Valid consent | Interrupts the opening disclosure | Agent resumes or restarts according to policy | Audio and transcript prove the complete required content. |
| 7 | Valid consent | Uses indirect opt-out language | Classifier follows the approved ambiguity path | Review or suppression event matches policy. |
| 8 | Previously opted out | System attempts a second campaign call | No outbound call starts | Suppression check blocks the attempt at the dialer boundary. |
Call 8 is the one teams skip. It catches a real systems failure: the conversational agent handled the opt-out correctly, but a retry worker or second campaign ignored the write.
Run these calls with synthetic identities and non-routable or controlled phone numbers. The sandbox side-effect guide explains how to keep calendar, CRM, and other test writes away from production users.
Verify Opt-Out Side Effects Outside the Transcript
An agent saying "I will stop future calls" proves only that the model generated a sentence. The test must inspect the authoritative campaign state.
Use this sequence:
- Start the call with a unique synthetic contact and campaign ID.
- Express the opt-out in the target language and conversational style.
- Capture the recognized intent, rule version, and event timestamp.
- Read the suppression record from its authoritative store.
- Verify queued and scheduled attempts are canceled or made ineligible.
- Attempt a second call through the normal campaign path.
- Confirm that telephony initiation never occurs.
Opt-out verification rule: a test passes only when the authoritative suppression state changes and a later campaign attempt is blocked. Transcript acknowledgment alone is not a pass.
For multi-tenant systems, apply the same discipline to policy scope. The customer workflow rules template helps test whether a tenant-specific rule was overridden by a global default.
Preserve One Reviewable Evidence Packet
Store enough evidence to reconstruct the decision without copying raw sensitive data into every log.
{ "canonicalCallId": "call_test_2026_08_27_0042", "campaignId": "campaign_servicing_08", "syntheticContactId": "contact_test_0042", "policy": { "id": "outbound_servicing_us_v4", "version": "4.2", "effectiveAt": "2026-08-01T00:00:00Z" }, "outreachDecision": { "status": "eligible", "consentRecordId": "consent_test_771", "purpose": "account_servicing", "evaluatedAt": "2026-08-27T15:42:11Z" }, "conversationEvidence": { "identityDisclosureTurnId": "turn_0001", "optOutTurnId": "turn_0007", "audioPointer": "recording://restricted/test-call-0042#t=31.2" }, "suppressionReadback": { "status": "suppressed", "reason": "caller_revoked", "observedAt": "2026-08-27T15:43:02Z" }, "secondAttempt": { "result": "blocked_before_dial", "attemptedAt": "2026-08-27T15:48:02Z" }, "reviewStatus": "passed"}The call logging schema provides the broader event envelope. This consent packet adds policy and suppression evidence while keeping raw audio behind a restricted pointer.
Troubleshoot Consent and Suppression Failures
| Symptom | Likely cause | Diagnostic | Fix |
|---|---|---|---|
| Call starts with no eligible consent | Eligibility check runs after telephony initiation | Compare dial timestamp with policy-decision timestamp | Move the gate before the provider call request. |
| Disclosure is skipped after an interruption | Prompt resumes at the next state without completion evidence | Inspect turn order and disclosure completeness | Use a controlled disclosure state that must complete before progression. |
| Agent acknowledges opt-out but calls continue | Conversation event and campaign suppression use different identifiers | Trace contact, phone, campaign, and tenant keys | Introduce one canonical contact key and verify propagation. |
| Only exact words trigger opt-out | Fixed phrase matcher has low recall | Replay paraphrases, interruptions, and multilingual variants | Use an approved intent classifier plus review path for ambiguity. |
| Suppression works in one campaign only | Scope defaults to campaign ID instead of the approved policy scope | Query all active campaigns for the synthetic contact | Encode suppression scope explicitly and test every consumer. |
| Audit packet lacks the active policy | Policy is read dynamically and not snapshotted | Compare current registry value with call timestamp | Store policy ID and version on the call event. |
| Test passes, production fails | Test writes bypass the same queue or dialer path | Compare execution traces | Run the second attempt through the production-equivalent campaign boundary. |
Confirmed failures should enter the failed-call regression runbook. Preserve the safe fixture, policy version, expected side effect, and the bug's original evidence pointer.
When This Runbook Is Not Enough
Policy scope remains a legal decision. This runbook can prove that configured behavior occurred. It cannot decide whether the configured rule is legally sufficient for a call type or jurisdiction.
Speech recognition creates ambiguity. A caller may say "not now," "stop this," or "don't call me about upgrades" while background noise obscures the qualifier. High-risk ambiguity needs an approved fallback, often suppression or human review.
Distributed systems are eventually consistent. A suppression write may take time to reach every campaign worker. Have the policy owner set a maximum propagation delay within the applicable regulatory processing deadline, block queued work during that window, and test the race instead of assuming the write is instant.
Effective dates matter. The FCC's January 2026 order extended a limited waiver through January 31, 2027: the portion of section 64.1200(a)(10) that would apply a revocation for one type of informational message to unrelated future robocalls and robotexts from that caller. It did not suspend all consent-revocation requirements. The FCC subsequently circulated a September 2026 draft proposing changes; a circulated draft is not an effective rule. Keep campaign policy versions tied to the controlling rule and its effective date, confirmed by the policy owner, so proposed, delayed, and active requirements do not collapse into one evergreen test.
The incident response runbook should own confirmed production outreach after revocation. A single affected call may be a call-level bug; repeated calls after suppression can indicate a campaign-wide control failure.
Outbound Consent Launch Checklist
- Legal or compliance approved the policy ID, version, call types, jurisdictions, scripts, exceptions, and effective date.
- Outreach, recording, and data-processing decisions are stored separately.
- Eligibility is checked before the provider receives a dial request.
- The opening identity or disclosure has exact, semantic, and ordering checks appropriate to the policy.
- The eight-call suite passes with synthetic contacts and production-equivalent routing.
- Opt-out tests include clear, indirect, interrupted, and repeated requests.
- Suppression is read back from the authoritative store.
- A second normal campaign attempt is blocked before dialing.
- Queued retries and overlapping campaigns follow the approved suppression scope.
- Evidence packets include policy version, consent source, call evidence, suppression readback, and reviewer state.
- Raw audio and unredacted transcripts stay behind restricted pointers.
- Every confirmed miss has an owner, remediation, and regression test.
Hamming can automate the call execution, assertions, evidence capture, and regression loop. Your policy owner still defines the obligation. That boundary is a feature: it keeps the test deterministic while the legal interpretation stays with the people authorized to make it.
