What Compliance Teams Should Ask Before Approving Real-Time Speech AI
A Checklist for Financial Services Risk Managers
Real-time speech AI can process sensitive conversations as they happen, but products vary widely in what they collect, create, store, and share. “Real-time” describes when the technology operates. But it tells you little about what the technology does to the conversation or the information it exposes. Before you make a final decision about real-time speech technology, there are key questions to consider. These 12 questions help U.S. financial-services compliance, risk, legal, and security teams evaluate data flows, safeguards, vendor assurances, operational resilience, and ongoing governance before approving a deployment.
Two tools can both be called real-time speech AI while posing very different risks. One might enhance incoming audio locally without creating a transcript. Another might stream speech to cloud services, produce transcripts and recommendations, and send those outputs into other systems.
Real-time speech AI includes systems that analyze, enhance, transcribe, translate, generate, or otherwise process speech during a live interaction. The questions apply across banks, insurers, fintechs, and other financial-services operations, but their answers will carry different weight depending on the deployment.
This is a due-diligence framework, not a universal statement of legal requirements. The applicable obligations depend on your institution, the data, and the use case.
12 questions for evaluating real-time speech AI
1. What data does the system process during a live conversation?
Start with an inventory, not a product description. Does the system handle raw or modified audio, transcripts, prompts, responses, speaker identifiers, call metadata, performance telemetry, or diagnostic logs? Does it infer anything new, such as sentiment, intent, or identity?
Why it matters: A recording is only one possible source of exposure. A service that stores no audio may still generate transcripts, analytics, or logs that contain sensitive information. The FTC’s Safeguards Rule guidance recommends inventorying data and identifying where it is collected, stored, and transmitted.
What to look for: A data inventory that distinguishes information received, information generated, and information passed downstream, and that includes the purpose of each.
2. Where does processing happen, and where does the data travel?
Ask the vendor to trace the conversation from microphone to output. Which steps run on an agent’s device, in your environment, or on external infrastructure? Which regions are used for processing, storage, support, and backup? Does the path change for certain features?
Why it matters: “On-device” and “cloud” are descriptions, not compliance decisions. You can’t necessarily come to a data security conclusion based on processing location alone. Local processing may limit data movement; cloud services may provide different security and operational controls. Either way, the actual boundaries determine what must be reviewed. Banking-agency guidance identifies third-party systems, data access, subcontractors, and geographic dependencies as due-diligence considerations.
What to look for: A deployment-specific diagram identifying every material transfer, processing location, output, and party responsible.
3. Is interaction data used for model training, evaluation, or product improvement?
Ask whether audio, transcripts, prompts, outputs, or derived information can be used outside the immediate service. Make sure to include quality testing, human review, fine-tuning, error analysis, and improvement of models shared with other customers. Check the defaults and any opt-in or opt-out settings.
Why it matters: “We don’t train on your calls” sounds reassuring, but just because that might be true doesn’t necessarily explain every secondary use. NIST’s voluntary AI Risk Management Framework provides a useful foundation for documenting AI data practices and risks across the system lifecycle.
What to look for: An explicit policy describing permitted uses by data type, the technical restrictions enforcing it, third-party access, and matching contractual commitments.
4. Where can sensitive information appear, and how is it protected?
A customer might say an account number, payment-card detail, password, or other confidential information without warning. Could it surface in audio, generated text, analytics, diagnostic logs, a support ticket, telemetry, or another integrated application?
Why it matters: Controls must follow the data. Redaction may be useful, but it’s not necessarily the correct or sufficient safeguard in every architecture. When payment account data is involved, teams should evaluate whether relevant systems fall within the scope of the PCI VoIP security standards, rather than treating “PCI compliant” as a blanket product description.
What to look for: A map of potential sensitive-data locations, with the applicable prevention, access, encryption, masking, or deletion controls and their limitations.
5. What is retained, where, and for how long?
Request a retention schedule for audio, transcripts, prompts, outputs, metadata, audit logs, diagnostics, backups, and records created during customer support. Ask whether administrators can change retention periods and what happens when the contract ends.
Why it matters: “Calls are not recorded” is not a retention policy. An institution may need to minimize certain data while preserving other records under applicable legal, supervisory, or business requirements. The FTC Safeguards Rule, for example, specifies secure disposal for covered customer information, with exceptions including legal retention obligations.
What to look for: Data-specific retention periods, documented deletion methods, treatment of backups and downstream copies, and a clear way to reconcile deletion with your required recordkeeping.
6. What consent, notice, or disclosure obligations might this use create?
First establish exactly what happens to the communication.
- Is it recorded, transmitted to another party, transcribed, modified, or analyzed?
- Does the system identify speakers or create information that could be treated as biometric data?
- What changes when callers or agents are in different states?
Why it matters: Existing call-recording scripts may not answer every question raised by a new deployment. Federal interception law includes consent exceptions, while states can impose different rules. Washington law, for instance, generally addresses consent of all participants for intercepting or recording private calls, subject to exceptions. Whether these or other obligations apply requires a fact-specific legal analysis.
What to look for: A precise technical description, configurable disclosure options where available, and documentation counsel can use to determine obligations. Vendors should not make that determination for the institution.
7. What can your company actually audit after the fact?
Find out whether you can reconstruct who accessed the system, which model and configuration were active, what administrative changes occurred, and how a service or security incident was handled. Do logs need to include sensitive conversation content to achieve that visibility?
Why it matters: Logging that exists only inside the vendor’s environment may be of limited use to an internal audit or incident-response team. For covered entities, the FTC’s Safeguards Rule guidance addresses monitoring authorized-user activity and detecting unauthorized access.
What to look for: Defined, protected log fields, access and retention rules, export capabilities, and a clear process for obtaining evidence when an investigation requires it.
8. What do the vendor’s assurances actually cover?
Ask to see the evidence behind any SOC 2 or SOC 3 report, ISO 27001 certification, HITRUST claim, PCI DSS assessment, or statement about privacy-law compliance. Identify the assessed entity, service, environment, period, relevant controls, and exclusions.
Why it matters: These are different forms of evidence, not interchangeable certifications. The AICPA explains that SOC 3 reports are intended for general use and provide less detail than SOC 2 reports. U.S. banking regulators similarly advise banks to consider whether a vendor’s SOC reports, certifications, and other assessments cover the activities the vendor will actually perform. Remember, a mere claim of GDPR compliance is not itself a certification.
What to look for: Current documents, the exact services covered, gaps or carve-outs, remediation status where relevant, and an explanation of how the evidence maps to your deployment.
9. Which third parties can process or access the information?
A single speech AI service may rely on one or more hosting providers, model services, analytics tools, support contractors, and monitoring platforms. Ask which of these are involved in your configuration and whether any receive conversation content or identifiers.
Why it matters: Your risk assessment cannot stop at the company signing the contract. The joint banking-agency guidance explicitly addresses subcontractor oversight, geographic exposure, and dependencies.
What to look for: A current subprocessor list, the purpose and extent of each party’s access, geographic details, contractual safeguards, oversight practices, and advance notification of material changes.
10. Who has access, and how is that access controlled?
Include employees, customer administrators, vendor support, contractors, service accounts, and automated integrations. Ask how privileged access is approved, limited, authenticated, reviewed, and removed when someone changes roles or leaves. And make sure to clarify how that information is logged.
Why it matters: A well-designed processing architecture can still expose information through excessive permissions or uncontrolled support access. Depending on the institution and data, applicable safeguards may include encryption and multifactor authentication. These are addressed in the FTC’s guidance for covered institutions.
What to look for: Demonstrable least-privilege practices, privileged-access safeguards, provisioning and revocation procedures, and evidence of recurring access reviews.
11. What happens when performance degrades or the system fails?
Real-time performance should be tested as a workflow, not just as a latency number. That means stress-testing the actual real-world mechanics of the system. For example:
- What happens if an endpoint times out, speech output becomes inaccurate, the network degrades, or a processing region is unavailable?
- Does the original call continue?
- Is traffic rerouted, and does rerouting change where data goes?
Why it matters: For live financial conversations, an outage may interrupt disclosures, authentication, service, or the customer’s ability to understand an agent. Operational resilience, recovery testing, service levels, and incident reporting appear in the banking agencies’ third-party guidance.
What to look for: Measurable performance commitments, tested fallback behavior, incident-notification terms, recovery procedures, and a description of what happens to data during failure and recovery.
12. How are changes to the technology and its operators governed?
Approval should include future-proofing. Ask about model releases, new features, configuration changes, updated subprocessors, advance notice, testing, rollback, and triggers for customer reapproval. Also ask how employees and contractors are trained, reassessed, and offboarded.
Why it matters: A security review describes the system at a point in time; people and systems change. The FTC’s Safeguards Rule guidance addresses change management, staff training, and service-provider monitoring for covered entities. The same issues deserve practical attention even where a different regulator or framework applies.
What to look for: Documented release controls, notice of material changes, testing and rollback records, role-specific training, access reviews, and defined circumstances for renewed risk assessment.
The decision should rest on evidence
A vendor shouldn’t have to use one prescribed architecture to earn approval. But it should be able to explain precisely what its system does, demonstrate the relevant controls, and give your team evidence it can examine. Any unanswered question becomes a documented risk to resolve, accept, or escalate, based on your institution’s obligations and appetite for risk.
Use these questions in a vendor review, security questionnaire, or internal approval discussion.
