HIPAA, PCI, TCPA, and More: The Complete Compliance Guide for Voice AI in 2026

In 2023, a telehealth company paid $1.9 million to settle HIPAA violations in part related to call recording practices — recordings that captured patient Protected Health Information without adequate safeguards. In 2024, a financial services company paid $3.4 million to settle a TCPA class action for autodialed calls made without prior express written consent. In 2025, a national real estate franchise settled a Fair Housing complaint in part arising from inconsistent AI-assisted responses to prospective buyers.

None of these companies deployed voice AI recklessly. Most thought they had addressed the relevant compliance requirements. What they had actually done was configure their AI systems without understanding the specific compliance obligations that attach to voice AI — obligations that are different from those that attach to web forms, email, or even live phone calls with human agents.

Voice AI creates new and specific compliance attack surfaces. Most voice AI platforms either don't know about them or don't enforce against them automatically. Your deployment is your liability.

This guide covers every major compliance framework applicable to voice AI in regulated industries: HIPAA for healthcare, TCPA for outbound calling, Fair Housing for real estate, PCI DSS for payment handling, ABA Model Rules for legal, and GLBA for financial services. For each framework, we will describe what the law actually requires (with citations), explain how voice AI creates specific risks, and provide a clear accounting of what a compliant platform must do and what you as the operator must still do yourself.

This is not legal advice. For any specific compliance question, consult qualified legal counsel in your jurisdiction. This is a technical and operational overview designed to help you ask the right questions — of your voice AI vendor, of your legal team, and of yourself.

---

Section 1: Why Voice AI Compliance Is Different

A misconception is worth dispelling before we go further: compliance for voice AI is not just "the same as compliance for live phone calls, but with an AI instead of a person."

It is different in three important ways.

First, voice AI creates transcript and recording artifacts that live phone calls often do not. When a human receptionist has a conversation with a patient, the only persistent record might be a brief note in the scheduling system. When a voice AI agent has the same conversation, the entire transcript is logged — every word the patient said, including their insurance policy number, their diagnosis description, their date of birth, their symptoms. This transcript persists. It is PHI. It must be handled accordingly.

Second, voice AI scales TCPA exposure by orders of magnitude. A human agent making autodialed calls can process perhaps 100 calls per day. A voice AI agent can process 10,000 calls per day. The TCPA penalty per call — $500 to $1,500 — does not care how many calls your system is capable of making. If 10,000 calls are made without proper consent, the exposure is $5 million to $15 million before any multiplier for willful violations. Scale without compliance is not an efficiency gain. It is an accelerating liability.

Third, voice AI creates consistency risks that human agents do not. A human Fair Housing violation requires a specific human making a specific decision to treat callers differently. A voice AI Fair Housing violation can emerge from a pattern across thousands of calls that no single person directed — the AI learning, through RLHF or prompt sensitivity, to respond differently to callers with different characteristics. The violation is systemic and harder to detect. The liability is the same.

These three differences — persistent transcripts, scale, and systemic pattern risk — define why voice AI compliance deserves its own analysis rather than inheriting the compliance posture designed for human phone operations.

---

Section 2: HIPAA for Voice AI

Who Must Comply

The Health Insurance Portability and Accountability Act (HIPAA) applies to Covered Entities — healthcare providers, health plans, and healthcare clearinghouses — and to their Business Associates: organizations that create, receive, maintain, or transmit Protected Health Information on behalf of a Covered Entity.

A voice AI vendor that handles calls for a dental practice, medical clinic, or mental health provider is a Business Associate under 45 CFR § 160.103. This is not a gray area. It is the definition. If your voice AI vendor is recording conversations, generating transcripts, storing call data, or processing any information disclosed during a healthcare-related call, they are a Business Associate. The HIPAA Rules apply to them. They must sign a Business Associate Agreement (BAA) with you before the first PHI-containing call flows through their system.

If your voice AI vendor does not offer a BAA, they cannot legally handle healthcare calls. Full stop.

What Counts as PHI in a Voice AI Context

Protected Health Information is defined at 45 CFR § 164.514 as individually identifiable health information transmitted or maintained in any form or medium — including voice and text. The 18 identifiers that make health information individually identifiable include name, phone number, date of birth, geographic data smaller than a state, and health condition information.

A dental patient's appointment reminder call contains: the patient's name, their phone number (implied by the call), the date and time of their appointment (which together establish they are a patient), and potentially their procedure type. This is PHI. A medical callback that mentions a prescription is PHI. A mental health scheduling call that reveals the patient is seeing a therapist is PHI.

The practical implication for voice AI: almost every call to a healthcare provider's AI agent generates a transcript that contains PHI. Treating those transcripts like generic call logs — storing them in an unencrypted database, making them accessible without access controls, retaining them indefinitely — is a HIPAA violation.

The Minimum Necessary Standard

45 CFR § 164.502(b) requires that when PHI is used or disclosed, it be limited to the minimum necessary to accomplish the intended purpose. This applies to voicemails.

The Department of Health and Human Services has specifically addressed voicemail in FAQ guidance: healthcare providers may leave appointment reminders on voicemail, but should use minimum necessary information. A voicemail that says "Hi, this is a reminder that John Smith has an appointment Thursday at 2pm for a root canal procedure" has disclosed a treatment type. A compliant voicemail for scheduling purposes says "Hi, this is [practice name] confirming your appointment on Thursday at 2pm. Please call us if you need to reschedule."

Your voice AI's voicemail message templates must be reviewed against this standard. Templates that were written for internal use — where the procedure type helps staff route the callback — are not appropriate for patient-facing voicemails.

De-identification Requirements

Information from which all 18 identifiers have been removed is not PHI and is not subject to HIPAA's Privacy Rule (45 CFR § 164.514(a)). For call analytics and platform improvement purposes, de-identified transcript data is permissible. But de-identification must meet the standard: either Expert Determination (a qualified statistician certifies that residual identification risk is very small) or Safe Harbor (all 18 identifiers are removed or generalized per the specific requirements of 45 CFR § 164.514(b)(2)).

Redacting a patient's name from a transcript while leaving their specific diagnosis, appointment date, and phone number in the same record does not achieve de-identification. The 18 identifiers are cumulative — all must be addressed.

What a Compliant Voice AI Platform Must Do

A HIPAA-compliant voice AI platform for healthcare must:

• Sign and provide a HIPAA Business Associate Agreement
• Encrypt PHI at rest and in transit (AES-256 at rest, TLS 1.2+ in transit meet the standard)
• Implement access controls so that PHI is accessible only to authorized personnel and systems
• Maintain audit logs of all access to PHI (who accessed what, when, from where)
• Redact PHI from transcripts before they are stored in any system not covered by the BAA
• Provide a mechanism for patients to exercise their right of access to their records (45 CFR § 164.524) — which for voice AI means call recordings and transcripts must be retrievable and producible
• Have documented breach notification procedures per 45 CFR § 164.400-414

What You Must Still Do

Even with a fully compliant voice AI platform, you retain HIPAA obligations:

• Obtain patient authorization for call recording where required (your state may have requirements beyond HIPAA)
• Ensure your staff knows what to do when patients request access to their call records
• Include your voice AI vendor in your vendor risk management program and conduct annual due diligence
• Document your configuration decisions — especially decisions about what data the agent captures and stores

---

Section 3: TCPA for Voice AI

The Law

The Telephone Consumer Protection Act (47 U.S.C. § 227) prohibits making any call using an automatic telephone dialing system (ATDS) or an artificial or prerecorded voice to any telephone number assigned to a cellular telephone service, emergency line, or residential line without prior express consent. For marketing calls, the standard is prior express written consent. For non-marketing calls (appointment reminders, informational messages), prior express consent (which can be oral) may suffice, though this distinction is litigated and varies by context.

The FCC's implementing regulations at 47 CFR § 64.1200 add calling window restrictions: no autodialed calls before 8am or after 9pm, measured in the recipient's local time zone. This is not a best practice. It is a legal requirement. Calls made outside these windows are TCPA violations regardless of consent status.

The 2024 One-to-One Consent Rule

In January 2024, the FCC issued a rule (FCC 24-8) requiring that express written consent for autodialed calls or texts be specific to a single seller. Prior to this rule, a single consent obtained through a lead generation website could be sold to multiple companies, each of whom could then rely on that consent for their own outbound calls. The rule eliminated this practice.

For businesses running voice AI outbound campaigns — recall calls, appointment reminders, reactivation campaigns — this rule means that consent collected on a form that says "I consent to be contacted by [practice name] and its marketing partners" does not satisfy TCPA requirements for the contacts those "marketing partners" make. Consent must be obtained specifically for your organization.

The operational implication: if you are running a dental recall campaign or a service business reactivation campaign, you need consent records showing that each cell phone number consented specifically to receive automated calls from your practice or business, with a timestamp, the source of consent, and the specific language the patient or customer agreed to.

Penalties

TCPA penalties are $500 per call for unknowing violations and $1,500 per call for willful or knowing violations (47 U.S.C. § 227(b)(3)). Courts have generally held that defendants who learn of TCPA issues and continue calling are liable for trebled damages. The statute provides a private right of action, which means individual plaintiffs can sue without government involvement — and class action aggregation of TCPA claims is well-established.

A recall campaign that autodials 5,000 dental patients without proper consent, with half of those calls to cell phones, exposes the practice to $1.25 million to $3.75 million in potential liability. For a multi-location DSO running campaigns at scale, the numbers become extraordinary quickly.

What a Compliant Voice AI Platform Must Do

TCPA compliance in a voice AI platform requires:

• Calling window enforcement: Automatic blocking of outbound calls before 8am and after 9pm in the recipient's local time zone. For multi-timezone deployments, this requires mapping each phone number to a time zone (available via a number lookup or by prompting the user to provide one). This enforcement must be platform-side, not just a best practice recommendation.
• Consent tracking: The platform must provide a mechanism for operators to record consent data — when consent was collected, through what mechanism, and for what type of contact — and must enforce that outbound campaigns only contact numbers with valid consent records.
• Do-Not-Call compliance: The platform must honor do-not-call requests made during calls and must maintain and check against the national DNC registry for marketing calls.
• Manual dialing mode: For calling cell phone numbers without documented consent, the platform must provide a compliance-safe path — typically a manual-dial mode where a human initiates each call rather than an automated system, removing the ATDS definition from the interaction.

What You Must Still Do

• Collect and store written consent records with timestamp, consent language, and source for all cell phone numbers you intend to autodial
• Train staff on the one-to-one consent requirement — consent collected before January 2024 may not satisfy the updated standard if it was a "and partners" consent
• Review your existing contact database to identify which records have adequate consent and which require re-engagement through compliant channels before autodialing
• Consult with TCPA counsel before launching any large-scale outbound campaign

---

Section 4: Fair Housing for Real Estate Voice AI

The Law

The Fair Housing Act of 1968 (42 U.S.C. §§ 3601-3619) prohibits discrimination in the sale, rental, financing, and terms of housing based on race, color, national origin, religion, sex, familial status, and disability. Section 804 makes it unlawful to make, print, or publish any statement that indicates a preference, limitation, or discrimination based on a protected characteristic.

Fair Housing does not require intent to discriminate. A statement that has the effect of limiting housing availability to members of a protected class is a violation, even if the speaker did not intend a discriminatory outcome.

How Voice AI Creates Fair Housing Exposure

The Fair Housing risk from voice AI is subtler than overt discrimination. The risks are:

Inconsistent information delivery. If a voice AI agent provides more detailed information about a property, a neighborhood, or financing options to some callers than others — based on any characteristic that correlates with a protected class — the pattern constitutes differential treatment. AI models are sensitive to subtle conversational signals, and without specific countermeasures, they can develop inconsistent response patterns across caller groups without any human directing them to.

Steering language. Describing a neighborhood in terms that imply its demographic character — "up-and-coming," "changing area," "transitional neighborhood" — constitutes steering under Fair Housing guidance, even when the speaker intends the description neutrally. AI models trained on general data can reproduce these patterns from training corpus exposure. Without a vocabulary filter that detects and blocks such phrases, the agent may produce Fair Housing-violating responses.

Inconsistent availability information. If an agent consistently indicates that a specific property or unit type is unavailable to callers with certain characteristics, this constitutes a refusal to show housing in violation of Section 804(d). AI agents with poorly constructed context handling can produce this pattern unintentionally.

HUD Guidance on Algorithmic Systems

HUD has issued guidance indicating that the Fair Housing Act applies to algorithmic systems, including AI. The relevant precedent is the disparate impact doctrine, established by the Supreme Court in Texas Department of Housing & Community Affairs v. Inclusive Communities Project (2015): a practice that has a disparate impact on a protected class violates the FHA even without discriminatory intent, unless it is justified by a legally sufficient interest.

The practical implication: even if your voice AI was never configured to treat callers differently, if call data analysis reveals disparate outcomes by protected-class-correlated factors, you have Fair Housing exposure.

What a Compliant Voice AI Platform Must Do

• Prohibited phrase filtering: A real-time filter monitoring agent responses for language associated with steering, redlining, or demographic characterization. This list should include 200+ terms: neighborhood quality characterizations, demographic references (direct and coded), language that implies housing availability varies by caller, and financial qualification language that may correlate with protected class.
• Consistent response enforcement: Structural testing to verify that the agent provides consistent information regardless of caller characteristics. This may include built-in response validation that checks outputs against a consistency baseline.
• Audit logging: Every interaction logged with sufficient detail to support a disparate impact analysis if needed. The ability to produce response patterns aggregated across caller segments is essential for compliance defense.

What You Must Still Do

• Review your agent's configured language — system prompt, knowledge base, and response templates — with a Fair Housing attorney before deployment
• Conduct periodic audits of call patterns for consistency across caller segments
• Train your staff on what the agent can and cannot say, and what to do when a caller escalates to a human after an AI interaction

---

Section 5: PCI DSS for Payment Card Data

The Risk

Payment Card Industry Data Security Standard (PCI DSS) applies to any organization that stores, processes, or transmits cardholder data. If your voice AI agent accepts payment card numbers — for booking deposits, service fees, product orders, or any other purpose — you are in PCI DSS scope.

The specific risk with voice AI is transcript storage. A caller who provides their 16-digit card number during a voice interaction has that number transcribed by the AI's speech-to-text layer. If that transcript is stored in a database, you have stored cardholder data. PCI DSS Requirement 3 prohibits storing cardholder data beyond what is necessary for authorized transactions, and requires that Primary Account Numbers (PAN) be unreadable anywhere they are stored (through tokenization, truncation, encryption, or masking).

A transcript that reads "my card number is 4532 1234 5678 9012" is a stored PAN. It is a PCI DSS violation if it is not immediately masked.

PCI DSS Scope

PCI DSS version 4.0 (released 2022, fully effective 2024) defines scope as all system components and people involved in payment card processing, or that could impact the security of cardholder data or sensitive authentication data. A voice AI system that transcribes calls in which card numbers are spoken is in scope. The transcript storage database is in scope. The call recording is in scope.

Scope reduction is the preferred compliance architecture: minimize the number of systems and processes that touch cardholder data. The best implementation for voice AI is to avoid capturing card numbers in the AI conversation entirely — redirect payment to a DTMF (touch-tone) entry system where digits are captured outside the AI transcript pipeline, or to a tokenized payment link sent via SMS that the caller completes independently.

What a Compliant Voice AI Platform Must Do

• Real-time PAN masking: Speech-to-text output must be scanned in real time for 16-digit sequences matching the Luhn algorithm (the checksum that validates card numbers). Detected sequences must be masked before transcript storage (e.g., replacing 4532 1234 5678 9012 with XXXX XXXX XXXX 9012 or [CARD NUMBER REDACTED]).
• Call recording pause/resume: For deployments where agents do accept card information over voice, the platform must implement pause/resume for call recording at the card number capture point, ensuring the spoken card number is not captured in the recording artifact.
• PCI scope documentation: A compliant platform should be able to provide documentation of its PCI DSS scope and the controls it has in place, including its status as a Service Provider under PCI DSS if applicable.

What You Must Still Do

• Do not store card numbers in your own systems outside of your payment processor's tokenized vault
• Use a QSA (Qualified Security Assessor) to validate your overall PCI scope if your organization handles significant card volume
• Train staff and configure agent instructions to redirect card number capture to compliant channels (DTMF, payment links) rather than verbal disclosure

---

Section 6: ABA Ethics Rules for Legal Voice AI

The Applicable Rules

The American Bar Association's Model Rules of Professional Conduct have been adopted in some form in all 50 states. For legal intake voice AI, four rules create specific requirements.

Model Rule 1.1 (Competence) requires that an attorney provide competent representation, which includes the legal knowledge, skill, thoroughness, and preparation necessary for the representation. A voice AI system that provides legal analysis or advice — even if framed as general information — risks creating a representation that a competent attorney has assessed the caller's situation. If that assessment is wrong, it may constitute ineffective assistance.

Model Rule 1.4 (Communication) requires that an attorney keep a client reasonably informed about the status of a matter and promptly comply with reasonable requests for information. For AI-conducted intake, this creates an obligation to be transparent about the AI's role and limitations: a caller who believes they have received legal advice from an attorney, when they have actually received a screening by an AI, has not been adequately informed about the status of their matter.

Model Rule 1.6 (Confidentiality) requires that a lawyer not reveal information relating to the representation of a client unless authorized. Information disclosed by a prospective client during intake may be protected as confidential even before an attorney-client relationship is formally established (see also Rule 1.18, Duties to Prospective Client). A voice AI that captures intake information is capturing potentially privileged communications. The handling of that data — storage, access, retention — must be consistent with the firm's confidentiality obligations.

Model Rule 7.3 (Solicitation) prohibits in-person or real-time electronic solicitation of prospective clients when a significant motive is pecuniary gain, unless the prospective client is a lawyer, a family member, or a person with whom the lawyer has an existing relationship. Whether a proactive AI outreach to a prospective client constitutes prohibited solicitation under Rule 7.3 depends on the specific circumstances and state bar interpretation, but it is an area requiring careful analysis before any outbound legal AI deployment.

The Attorney-Client Relationship Risk

The most significant ABA risk in legal voice AI is the inadvertent creation of an attorney-client relationship. ABA Formal Opinion 90-357 establishes that a prospective client who reasonably relies on an attorney's representation that a matter has been reviewed may have an attorney-client relationship, even if the attorney never intended one.

A voice AI for a law firm that discusses a caller's legal situation in detail, asks clarifying questions about the facts, and indicates that "our attorneys will review your situation" may create the reasonable belief that an attorney has been retained. If the firm then fails to follow up, or takes a conflicting case, or does not adequately protect the information disclosed, it has ethical exposure.

The safeguards required: mandatory disclosure that the caller is speaking with an AI, not an attorney; explicit disclaimer that the interaction does not constitute legal advice or create an attorney-client relationship; avoidance of any substantive legal analysis in the AI interaction; and clear handoff protocols to a human attorney for any caller who needs substantive guidance.

Conflict Screening

An often-overlooked ABA requirement for legal intake AI: conflict of interest screening. Model Rule 1.7 prohibits representing a client whose interests are directly adverse to another current client, and Rule 1.9 addresses duties to former clients. Before a law firm can begin a representation, it must check whether the prospective client or their adverse party is already a current or former client in a matter that would create a conflict.

A voice AI handling legal intake should integrate with the firm's conflict-checking system (Clio, MyCase, and most legal practice management systems have conflict screening features) before collecting detailed case information. An intake conversation that captures extensive information about a matter and then discovers a conflict has both created unnecessary disclosure risk and wasted the prospective client's time.

What a Compliant Voice AI Platform Must Do

• Mandatory disclosure templates: First-call disclosure that the caller is speaking with an AI system, not an attorney, and that the interaction does not constitute legal advice or create an attorney-client relationship
• Scope limiting configuration: Strict instructions preventing the agent from discussing case merits, providing legal analysis, or characterizing the likelihood of success
• Conflict screening integration: Pre-intake conflict check against Clio, MyCase, or equivalent before collecting substantive case information
• PHI-equivalent data handling for privileged information: Intake information should be treated with confidentiality protections equivalent to attorney-client privilege — access controls, audit logging, retention limits

What You Must Still Do

• Work with your bar compliance counsel before deploying any legal intake AI
• Review your state bar's specific rules — some states have adopted the ABA Model Rules with modifications that may be more restrictive
• Ensure all disclosure language is reviewed and approved by qualified legal ethics counsel
• Establish clear handoff protocols so that callers who express urgency or distress are promptly escalated to a human

---

Section 7: GLBA for Financial Services

The Law

The Gramm-Leach-Bliley Act (15 U.S.C. §§ 6801-6827) requires financial institutions to protect the security and confidentiality of customers' Non-Public Personal Information (NPI). Financial institutions include banks, mortgage lenders, insurance companies, investment advisors, and any company that provides financial products or services to consumers.

The FTC's Safeguards Rule (16 CFR Part 314), significantly updated in 2021 and effective 2023, requires financial institutions to implement a comprehensive information security program that includes:

• A designated qualified individual responsible for the information security program
• A data inventory identifying where NPI is held and who has access
• Access controls limiting NPI access to those who need it
• Encryption of NPI in transit and at rest
• Multi-factor authentication for access to NPI
• Continuous monitoring or periodic penetration testing
• Incident response plan
• Annual reporting to the Board of Directors

For voice AI at financial institutions, NPI appears in call transcripts: account numbers, Social Security numbers, financial balances, credit application information, insurance policy details. These transcripts must be managed under the Safeguards Rule.

The Annual Risk Assessment Requirement

The updated Safeguards Rule requires financial institutions to conduct a risk assessment identifying and assessing risks to the security, confidentiality, and integrity of customer information. For institutions deploying voice AI, this means the voice AI system must appear in the risk assessment as a data processing component, with its controls documented and its risks identified.

If a financial institution's annual risk assessment does not include its voice AI vendor and system, that risk assessment is incomplete by regulatory standard.

What a Compliant Voice AI Platform Must Do

• Encrypted-at-rest and in-transit storage for all call data and transcripts
• Access controls with audit logging meeting the Safeguards Rule standard
• Ability to provide security documentation supporting the institution's vendor due diligence obligation
• SOC 2 Type II certification (or roadmap) as evidence of third-party-verified security controls
• Contractual commitments appropriate for a GLBA service provider relationship

What You Must Still Do

• Include voice AI in your annual GLBA risk assessment
• Conduct vendor due diligence on your voice AI provider and document the results
• Ensure your data inventory includes call transcripts and recordings as NPI categories
• Review the Qualified Individual designation — your GLBA compliance program must have a named accountable person

---

Section 8: Building a Compliant Voice AI Deployment

The following checklist consolidates the requirements across all frameworks. Every item should be verifiable — either through platform configuration, contractual documentation, or your own records.

Platform-Level Requirements (Your Vendor Must Provide)

• [ ] HIPAA BAA signed — If you handle healthcare calls, this is prerequisite. No BAA = non-compliant.
• [ ] PHI redaction in transcripts — Real-time redaction of identifiable health information before transcript storage
• [ ] Encrypted storage — AES-256 at rest, TLS 1.2+ in transit for all call data
• [ ] Audit logging — All access to PHI/NPI logged with user, timestamp, and action
• [ ] TCPA calling window enforcement — Automatic blocking of outbound calls outside 8am–9pm local time, enforced platform-side
• [ ] PAN masking — Real-time detection and masking of 16-digit card number sequences in transcripts
• [ ] Call recording pause/resume — For card capture scenarios
• [ ] Fair Housing phrase filter — Real-time prohibited phrase detection and blocking for real estate agents
• [ ] Consent tracking mechanism — Ability to store and enforce TCPA consent records against outbound campaigns
• [ ] ABA disclosure templates — For legal intake: mandatory AI/non-attorney disclosure on every call

Operator-Level Requirements (You Must Implement)

• [ ] Patient/customer consent for call recording — State law may require two-party consent disclosure at call start
• [ ] TCPA consent collection and storage — Written consent records with timestamp, source, and language for all autodialed cell phone contacts
• [ ] DNC compliance — Regular scrubbing of outbound lists against the National Do Not Call Registry for marketing calls
• [ ] Staff training on agent scope — Employees should understand what the agent can and cannot say, and escalation procedures
• [ ] Fair Housing attorney review — Real estate agent system prompts and knowledge base reviewed before deployment
• [ ] ABA ethics counsel review — Legal intake agent reviewed for compliance with applicable state bar rules before deployment
• [ ] Conflict screening integration — Legal intake configured to run conflict checks before substantive case discussion
• [ ] PCI payment redirection — Card capture routed to DTMF or payment link, not verbal disclosure to AI
• [ ] GLBA risk assessment entry — Voice AI vendor and system included in annual GLBA risk assessment
• [ ] Vendor due diligence documentation — Security review of voice AI vendor completed and documented for GLBA, HIPAA, or PCI requirements
• [ ] Incident response plan updated — Voice AI included in data breach scenarios and notification procedures

Ongoing Operational Requirements

• [ ] Periodic transcript auditing — Sample review of transcripts to verify PHI redaction and Fair Housing filter effectiveness
• [ ] Consent record maintenance — Process to remove consent when revoked, and to update records when contact information changes
• [ ] Knowledge base currency review — Regular review to ensure information is current (outdated information can create both compliance and liability issues)
• [ ] TCPA consent re-solicitation — Process to identify contacts whose consent predates the 2024 one-to-one consent rule and may not meet the updated standard
• [ ] Annual HIPAA/GLBA risk assessment refresh — Including any changes to voice AI configuration, vendor, or data flows

---

The Bottom Line

Voice AI compliance is not a one-time setup task. It is an ongoing operational discipline.

The businesses that deploy voice AI without compliance architecture are not safe because they haven't been caught yet. They are creating liability that accrues with every call. The TCPA exposure from a 90-day outbound campaign without proper consent can exceed the cost of the entire voice AI deployment many times over. A single HIPAA breach involving voice transcripts can trigger notification obligations affecting tens of thousands of patients and the associated regulatory scrutiny.

The good news is that a well-architected voice AI platform handles most of this automatically. PHI redaction, TCPA window enforcement, PAN masking, Fair Housing filtering — these are engineering problems with engineering solutions. The platforms that have invested in building compliance infrastructure shift a substantial portion of the compliance burden to the platform layer, where it can be enforced consistently and systematically rather than relying on operator configuration to get it right every time.

The remaining obligations are real and must be owned by you as the operator: collecting proper consent, reviewing agent language with qualified counsel, training staff, maintaining records, and including voice AI in your ongoing compliance programs. No platform can do these things for you.

The combination — a platform that handles the technical compliance layer and an operator who handles the legal and procedural layer — is what a truly compliant voice AI deployment looks like. Either half alone is insufficient.

Know which half your vendor is responsible for. Know which half is yours. Document both. Review both regularly. That is the work.