The compliance architecture problem in AI voice — why prompt-instructed compliance is one adversarial input away from class action

On February 8, 2024, the Federal Communications Commission unanimously adopted a Declaratory Ruling holding that calls made with AI-generated voices are "artificial or prerecorded voice" within the meaning of the Telephone Consumer Protection Act and 47 CFR Section 64.1200. The ruling closed an interpretive gap that had let some AI voice operators argue their technology was distinct from traditional robocall infrastructure. After February 2024, that argument is no longer available.

The practical effect: every AI voice call now sits inside the same TCPA framework that has governed robocalls since 1991. The disclosure requirements, call-window restrictions, written-consent obligations for certain call types, and Do Not Call list enforcement all apply. State attorneys general were given explicit authority to seek damages alongside the FCC's civil enforcement and the private right of action that consumers and aggregators have always had under the statute.

In July 2024, the FCC issued a Notice of Proposed Rulemaking that goes further — proposing specific consent requirements and in-call disclosure obligations specifically tailored to AI-generated calls. The NPRM is not yet final rule, but the direction of travel is clear: the regulatory posture is tightening, not loosening, and the surface area of vendor liability is expanding.

TCPA operates on a strict-liability framing for many of its provisions. Strict liability means the plaintiff does not have to prove the caller intended to violate the statute; they only have to prove the violation occurred. A non-compliant call is a non-compliant call regardless of why it was non-compliant.

The statutory damages are fixed and per-call: $500 for inadvertent violations, up to $1,500 for violations the court finds willful or knowing. These numbers are not negotiable; they are the floor that Congress set. A small business making 200 non-compliant collection calls in a year — well within the volume of a single-owner service business — faces $100,000 in statutory damages at the inadvertent rate and $300,000 at the willful rate. Plaintiff attorney fees are typically additional.

The dominant enforcement vehicle is not regulatory action; it is private class action. TCPA permits private plaintiffs and aggregating attorneys to bundle calls across many recipients into single class actions, where statutory damages compound across the class. The math is what makes TCPA cases attractive to plaintiffs' bar: even a small recovery rate per defendant produces meaningful settlement dollars when the underlying class is large.

For AI voice operators, this creates a specific exposure shape. The LLM does not have to violate TCPA on most calls; it has to violate it on enough calls — and on calls to recipients who become plaintiffs — for the class to form. Because LLM behavior is non-deterministic and can drift under adversarial input, the question is not whether the system will eventually produce a non-compliant call. The question is when, and how many calls will have been bundled into the class by then.

The dominant pattern across AI voice products in 2025-2026 is to encode compliance requirements as instructions inside the LLM prompt. The system prompt or per-call prompt contains directives like the following: "Always disclose at the beginning of the call that you are an AI assistant." "Always announce that the call may be recorded." "Do not initiate or continue the call outside the recipient's local 8am-9pm window." "Do not state dollar amounts the model has not been given by the data layer." "If asked, identify yourself as calling on behalf of [business name]."

These are well-intentioned and they often work. On most calls, the LLM follows the instructions. Disclosures get made. Call windows get respected. The customer experience is compliant.

The architectural problem is what the system does on the calls where the LLM does not follow the instructions. Adversarial inputs — customers who steer the conversation in unusual directions, customers who interrupt the disclosure preamble, customers who pose questions that trigger the model to skip a step — produce non-compliant calls at some non-zero rate. Whether that rate is 0.1 percent or 5 percent depends on the model, the prompt, and the inputs encountered. None of those rates is zero, and zero is the only acceptable rate under strict-liability framing because the statute does not care about the rate; it cares about the calls that did violate.

The deeper issue is that LLMs are generative systems. They produce output by sampling from a probability distribution over tokens. Even with rigorous prompts, low-temperature generation, and extensive guardrail engineering, the system cannot guarantee the next token. Compliance disclosures that have to be uttered word-for-word to satisfy the statute cannot be reliably produced by a system whose entire job is producing fluent variation.

The architecturally defensible posture is to split compliance from conversation. The split happens at the call-flow layer, before the LLM speaks. Compliance-required content — recording-notice language, AI-identification language, dollar amounts pulled from the database, call windows enforced by the dialer, business identification — is generated by deterministic code, not the LLM. The LLM never has the option to skip, paraphrase, or omit these elements because they are not in the LLM's output stream.

Concretely, the call begins with a hardcoded preamble injected by the call-flow controller: "This call may be recorded. I'm an AI assistant calling on behalf of [Business Name]." The LLM does not produce this string; the system produces it. The customer hears it before the LLM speaks at all. The disclosure is enforced architecturally; it is not contingent on the model producing the right tokens.

Dollar amounts and dates work the same way. When the LLM needs to reference a specific invoice, the system supplies the amount and date as variables that the LLM can refer to but not generate. The model cannot say "$4,237" if the data layer did not give it that number. If the model attempts to generate a different number, the call-flow controller can reject the output before it reaches the speech-synthesis layer. This is not a guardrail in the prompt; it is a hard constraint at the architecture level.

Call-window enforcement happens at the dialer layer, not the LLM layer. The system does not place the call at all if the recipient's local time is outside the compliant window. The LLM is not asked whether to call; the dialer simply refuses. Frequency caps work the same way: if the system has already attempted three calls on this invoice, it does not initiate a fourth. The LLM is downstream of these decisions and is never given the opportunity to violate them.

Compliance-safe rails for the conversational portion of the call cover the topics the LLM is and is not allowed to discuss. The rails exclude legal advice, settlement negotiation outside pre-approved parameters, third-party disclosure of debt details, and content that would trigger FDCPA-style obligations even on first-party calls. The LLM operates inside these rails for the conversational flow, but cannot cross them.

The single most useful question to ask any AI voice vendor is: where is compliance enforced — in the prompt or in the architecture? The answer reveals whether the vendor has designed the system to be safe under strict-liability framing or has relied on the model's good behavior.

Wrong answer 1: "We tell the model to always disclose." This is prompt-instructed compliance. The disclosure is encouraged, not enforced. The model can skip it under adversarial input.

Wrong answer 2: "We have a guardrail that checks the LLM output for the disclosure phrase before speaking it." This is closer but still wrong. If the guardrail detects the disclosure was missing, the system has already failed in interesting ways — what does it do then? Re-prompt? Insert? Both options carry latency and customer-experience cost. The disclosure should not have to be checked because it should have been hardcoded at the front of the call before the LLM ever spoke.

Wrong answer 3: "We use a fine-tuned model that always produces compliant output." Fine-tuning reduces the rate of non-compliance but does not eliminate it. Strict liability does not care about rates.

Right answer: "The compliance disclosures are hardcoded in the call flow before the model speaks. The dollar amounts come from the database; the model cannot generate them. The call window is enforced at the dialer layer before the call is placed. The model only handles conversational flow within compliance-safe rails it cannot cross." That architecture is the only one that survives the strict-liability test.

A useful follow-up question: "What happens if the LLM tries to generate a dollar amount that is not in the data layer?" The answer should describe a hard rejection at the call-flow controller, not a prompt that asks the model not to do that. "What happens if the customer asks the AI to call them back at 11pm?" The answer should describe the dialer refusing to place the call regardless of what the LLM said in the conversation.

Liability for TCPA violations follows the call. The business whose name is on the call — typically the SMB whose invoices are being collected — is the entity most exposed if the calls are non-compliant. The vendor may also be exposed under various theories, but the SMB is the front-line target because the call appears to come from their business.

This is materially different from how SaaS liability usually flows. In most SaaS categories, a vendor bug or misbehavior produces contract-level liability against the vendor. In TCPA, the bug or misbehavior produces statutory-damages exposure against the customer of the SaaS. The SMB pays the $500-1500 per call, plus class-action attorney fees, plus the reputational damage of being named in a TCPA suit.

Vendor due diligence is therefore a real obligation, not a checkbox. SMBs adopting AI voice for collection or sales should ask the architecture question, get a specific answer, and ideally see a description of the call flow that makes the deterministic-vs-LLM split visible. A vendor who cannot explain their architecture in those terms is selling a product that exposes the SMB to a class of liability the SMB may not realize they are inheriting.

The economic consequence of getting this wrong is asymmetric. A compliant AI voice product saves time and money. A non-compliant one can produce six-figure liability events in a single class-action settlement. The downside is large enough that the architectural question is worth taking seriously even if it feels technical.

The legal framework cited above — TCPA, 47 CFR Section 64.1200, the February 2024 FCC Declaratory Ruling, the July 2024 NPRM — is public and verifiable; sources are listed below. The interpretive arguments about strict liability and class-action mechanics are well-established in TCPA case law going back decades; this piece does not break new legal ground on those points.

The architectural argument about deterministic-vs-LLM compliance enforcement is engineering observation. It describes how Syntharra is built and contrasts with how most AI voice products handle compliance based on publicly visible product behavior, vendor documentation, and standard prompt-engineering practices in the industry. It is not a peer-reviewed claim and is open to challenge by other vendors who can describe their own architecture in equivalent specificity.

Syntharra is not a law firm and this piece is not legal advice. Specific TCPA exposure varies by call volume, recipient demographics, jurisdiction, and the structure of the underlying creditor-debtor relationship. SMBs evaluating AI voice products should consult counsel with TCPA experience before signing any vendor contract, and should require the vendor to make the architecture question answerable in writing.

If you operate an AI voice product and want to challenge any claim above, we welcome the engagement. Disagreement that is specific enough to test is more useful than agreement that is too general to evaluate.