Skip to main content

HIPAA, SOC 2, PCI: la lista de verificación de cumplimiento para la IA de voz

La mayoría de las páginas de seguridad de los proveedores presume de un único distintivo —normalmente SOC 2— y se queda ahí.

Digvijay Singh Shekhawat
Digvijay Singh Shekhawat
July 24, 2026
12 min read
Un auricular de teléfono beis reposa sobre papel y losas de travertino bajo una luz cálida del sol

Los 6 marcos que todo comprador empresarial de IA de voz debe exigir

La mayoría de las páginas de seguridad de los proveedores presume de un único distintivo —normalmente SOC 2— y se queda ahí. Los equipos de compras que hacen revisiones de verdad necesitan seis controles aclarados desde el primer día:

  1. HIPAA — entidades cubiertas y socios comerciales que manejan PHI en las llamadas.
  2. SOC 2 Type II — el informe de eficacia operativa (no Type I, no el PDF autodeclarado).
  3. PCI DSS v4.0.1 — allí donde quien llama dicte o teclee por DTMF un número de tarjeta.
  4. GDPR + UK GDPR — personas que llaman desde la UE o el Reino Unido, subencargados en la UE, DPA del Artículo 28.
  5. Residencia de datos — región de almacenamiento físico de transcripciones, grabaciones y embeddings.
  6. Riesgos específicos de la voz — huellas de voz, retención de grabaciones, filtración de datos de entrenamiento.

Si el proveedor no puede responder a los seis en una sola llamada, esa es la respuesta. Sáltate la demo y pasa al siguiente.


HIPAA: BAA, PHI en las transcripciones y exclusión del entrenamiento de modelos

Las transcripciones de voz son PHI en el momento en que quien llama dice su nombre junto a una patología, un medicamento o una cita. Trata el almacén de transcripciones, el almacén de embeddings y el almacén analítico como sistemas con PHI.

Requisitos mínimos de HIPAA para un proveedor de IA de voz:

  • BAA firmado con subencargados nombrados (proveedor de LLM, proveedor de ASR, proveedor de TTS, operador de telefonía, proveedor de observabilidad). Un BAA que excluye al LLM no es un BAA.
  • Cifrado en tránsito (TLS 1.2+, SRTP para el medio) y en reposo (AES-256).
  • Registros de auditoría de cada acceso a PHI durante 6 años.
  • Modo de retención cero de datos (ZDR) en la llamada al LLM. OpenAI ZDR, Anthropic ZDR y el modo sin registro de Google Vertex son configurables: confirma cuál está activado para tu tenant, y no des por hecho el valor por defecto del marketing.
  • Exclusión del entrenamiento de modelos por escrito. El proveedor debe comprometerse contractualmente a que el audio de tus llamadas, las transcripciones y las cargas útiles de las llamadas a herramientas nunca se usen para entrenar ningún modelo, ni suyo ni de un subencargado.

Cláusula BAA de ejemplo para pegar en el RFP:

"El Proveedor no utilizará, y se asegurará de que ningún Subcontratista utilice, la Información Sanitaria Protegida transmitida a través del Servicio de IA de Voz para entrenar, ajustar o evaluar ningún modelo de aprendizaje automático, incluidos, entre otros, los grandes modelos de lenguaje, los modelos de reconocimiento automático del habla y los modelos de texto a voz. El Proveedor configurará a todos los proveedores de modelos de terceros en modo de retención cero de datos o sin registro para el tenant del Cliente y facilitará una certificación escrita de dicha configuración cuando se le solicite."

Si el proveedor se resiste a esa cláusula, está guardando tu PHI en el corpus de entrenamiento de alguien.


SOC 2 Type II: qué verificar más allá del distintivo

El distintivo de SOC 2 en un pie de página no significa nada. Exige el informe completo bajo NDA y lee las partes que los proveedores esperan que te saltes.

Lista de comprobación del informe:

  • Type II, no Type I. Type I es una revisión del diseño en un momento concreto. Type II cubre de 6 a 12 meses de eficacia operativa. Cualquier cosa menor es teatro.
  • Trust Service Criteria cubiertos. Security es obligatorio. Availability, Confidentiality y Processing Integrity deberían estar dentro del alcance en una plataforma de IA de voz que atiende llamadas reales de clientes.
  • Auditor. Una firma Big-4 real o una firma de auditoría reconocida. No un auditor de fábrica de 5.000 $ que emite informes limpios como si fuera una prestación.
  • Sección de excepciones. Sáltate la carta de presentación. Ve a las excepciones. Cero excepciones en un Type II real suele significar que el alcance se trazó alrededor de nada. Una o dos excepciones bien documentadas con su remediación es lo normal y lo sano.
  • Organizaciones de subservicio. Busca AWS, GCP y Azure listados como exclusiones con sus propios SOC 2. Si el proveedor de LLM o el operador de telefonía es una organización de subservicio, su SOC 2 también debería estar referenciado.
  • Descripción del alcance. Confirma que el producto de IA de voz que estás comprando aparece nombrado en el alcance. A veces los proveedores incluyen solo el sitio de marketing o el panel, no la ruta de inferencia.

PCI DSS: cómo la IA de voz cambia (o amplía) tu alcance en las llamadas de pago

Aquí es donde la mayoría de los despliegues de IA de voz dispara sin hacer ruido el alcance de PCI del comprador. En cuanto quien llama pronuncia 16 dígitos, toda la ruta —operador de telefonía, ASR, ventana de contexto del LLM, almacén de transcripciones, proveedor de observabilidad— queda dentro del Entorno de Datos del Titular de la Tarjeta.

Dos arquitecturas, dos auditorías muy distintas:

PatrónQué ocurre con el número de tarjetaTu alcance de PCI
IA de voz ingenuaEl ASR transcribe "4111 1111 1111 1111" al contexto del LLM y a tus registrosCDE completo: ASR, LLM, base de datos de transcripciones, canal de registros, almacén de BI
Supresión de DTMF / pausar y reanudarQuien llama pasa a un teclado IVR de PCI DSS Level 1, el agente y el ASR quedan silenciados y solo regresa un tokenEl alcance de PCI del proveedor, no el tuyo

El patrón de pausar y reanudar con enmascaramiento de DTMF (a veces llamado "supresión de asistencia al agente") reduce tu alcance de "auditar el universo" a "auditar la integración".

Preguntas del comprador:

  • ¿El enmascaramiento de DTMF es a nivel de SBC o a nivel de aplicación? A nivel de SBC los tonos no entran en absoluto en el flujo de medios.
  • ¿El ASR recibe audio silenciado durante la ventana de captura o simplemente se redacta su transcripción a posteriori? La redacción a posteriori no cumple con PCI: el dato ya pasó por el sistema.
  • ¿El proveedor dispone de un AOC vigente de PCI DSS v4.0.1 para el componente de captura de pagos? Pide el AOC, no una nota de prensa.
  • ¿Se almacenan las grabaciones del tramo de pago, aunque sea cifradas? PCI exige que no se conserven en absoluto si contienen SAD tras la autorización.

GDPR + residencia en la UE: ubicación de los datos, subencargados y señales de alarma en el DPA

Si alguien llama desde la UE o el Reino Unido, GDPR se aplica con independencia de dónde esté tu sede. El proveedor de IA de voz es un encargado del tratamiento (Artículo 28); tu empresa es el responsable.

El DPA debe especificar:

  • Subencargados nombrados con sus ubicaciones. "AWS" no basta; "AWS eu-central-1" sí.
  • Standard Contractual Clauses (módulos de 2021) si algún subencargado está en EE. UU., más una Transfer Impact Assessment.
  • Garantía de residencia de datos por escrito. "UE en la medida de lo posible" no es residencia. Busca una fijación de región a nivel de tenant: audio, transcripciones, embeddings e índices vectoriales permanecen todos en eu-west-1 / eu-central-1 / eu-north-1.
  • SLA de supresión. Supresión conforme al Artículo 17 de GDPR en un plazo de 30 días, propagada a las copias de seguridad dentro de la ventana documentada de rotación de copias.
  • Notificación de cambios de subencargados con un derecho de objeción real: 30 días como mínimo, no un "actualizaremos la página".

Señales de alarma en los DPA de los proveedores:

  • "Los datos agregados y anonimizados pueden utilizarse para mejorar nuestros servicios". Los datos de voz rara vez son verdaderamente anonimizables: las huellas de voz son identificadores biométricos según el Artículo 9 de GDPR. Elimina esa cláusula.
  • Centro de datos únicamente en EE. UU. con un "cumplimos con GDPR" pero sin SCC ni TIA.
  • Lista de subencargados escondida detrás de un inicio de sesión o de un NDA. El Artículo 28 exige que esté a tu disposición.

Riesgos específicos de la voz: retención de grabaciones, huellas de voz biométricas y filtración de datos de entrenamiento

Los marcos anteriores se escribieron para el SaaS y los pagos. La IA de voz añade tres modos de fallo que ninguno de ellos cubre por completo:

1. Retención de grabaciones. La retención por defecto en la mayoría de las plataformas es de 30 a 90 días, a veces indefinida. Presiona para conseguir una retención configurable por tenant hasta 0 días (solo transcripción, sin audio) y confirma que se trata de un borrado definitivo, no de marcas de borrado lógico.

2. Huellas de voz biométricas. Algunas plataformas calculan embeddings de locutor (un vector de 192 dimensiones que identifica de forma única una voz) para la diarización o la detección de fraude. Bajo el Artículo 9 de GDPR, BIPA (Illinois) y la Texas CUBI, ese vector es un dato biométrico con requisitos de consentimiento que superan a los de la PII normal. Pregunta: ¿se generan huellas de voz?, ¿dónde se almacenan?, ¿pueden desactivarse por tenant?

3. Filtración de datos de entrenamiento. Incluso con una exclusión del entrenamiento de modelos, a veces los proveedores usan transcripciones redactadas para evaluar el rendimiento del modelo o construir conjuntos de evaluación. La "evaluación" puede ser un resquicio legal. Haz que la cláusula cubra cualquier uso posterior del modelo, incluidas las evaluaciones y los conjuntos de datos de optimización de prompts.


El cuestionario RFP descargable (15 preguntas)

Pega estas preguntas en tu cuestionario de proveedores. Las respuestas de sí o no obligan al proveedor a comprometerse sobre el papel.

  1. ¿Firmaréis un BAA de HIPAA que cubra a todos los subencargados, incluidos los proveedores de LLM, ASR y TTS?
  2. ¿Operáis el LLM en modo de retención cero de datos o sin registro para nuestro tenant de forma predeterminada?
  3. ¿Os comprometeréis contractualmente a que nuestro audio, nuestras transcripciones y las cargas útiles de las llamadas a herramientas nunca se usen para entrenar, ajustar ni evaluar modelos?
  4. Facilitad vuestro informe SOC 2 Type II más reciente bajo NDA. ¿Qué Trust Service Criteria están dentro del alcance?
  5. ¿La ruta de inferencia de la IA de voz aparece nombrada explícitamente en la descripción del alcance del SOC 2?
  6. Enumerad todas las excepciones del SOC 2 Type II más reciente y el estado de remediación de cada una.
  7. Facilitad vuestro AOC vigente de PCI DSS v4.0.1. ¿Qué componente está certificado?
  8. ¿Cómo se capturan los datos de la tarjeta de pago: supresión de DTMF a nivel de SBC, enmascaramiento a nivel de aplicación o redacción a posteriori?
  9. ¿Se conservan de alguna forma las grabaciones de los tramos de pago? En caso afirmativo, ¿dónde y durante cuánto tiempo?
  10. Facilitad una lista de subencargados con las regiones físicas de centro de datos de cada uno.
  11. ¿Pueden fijarse el audio, las transcripciones, los embeddings y los índices vectoriales a una región de la UE a nivel de tenant?
  12. ¿Cuál es vuestro SLA de supresión conforme al Artículo 17 de GDPR, incluida la propagación a las copias de seguridad?
  13. ¿Generáis embeddings de locutor o huellas de voz? ¿Pueden desactivarse por tenant?
  14. ¿Cuál es el periodo mínimo configurable de retención de grabaciones de llamadas? ¿Puede ponerse a cero?
  15. Facilitad un resumen reciente de una prueba de penetración externa (de los últimos 12 meses) que cubra la ruta de inferencia de voz.

Si un proveedor no puede responder a las 15 por escrito en una semana, todavía no ha hecho el trabajo, y estás pagando por ser su proyecto de I+D en cumplimiento normativo.


Preguntas frecuentes

¿Basta con HIPAA para un despliegue de IA de voz en el sector sanitario? No. HIPAA es necesario, pero no suficiente. También necesitas SOC 2 Type II para los controles de la plataforma, una prueba de penetración vigente para la ruta de inferencia y cobertura biométrica a nivel estatal (BIPA, CUBI, Washington My Health My Data) si generas huellas de voz.

¿Un informe SOC 2 Type II significa que el proveedor cumple con GDPR? No. SOC 2 cubre la eficacia operativa de los controles internos. GDPR es un régimen jurídico que exige un DPA, subencargados nombrados, SCC para las transferencias y derechos de las personas interesadas. Un proveedor necesita ambos, y los dos informes cubren superficies distintas.

¿Puede un proveedor de IA de voz reducir mi alcance de PCI a cero? Casi, pero no exactamente a cero. Un proveedor con supresión de DTMF a nivel de SBC y un AOC de PCI Level 1 para el componente de captura de pagos te sitúa en el terreno del SAQ A o del SAQ A-EP en la mayoría de los despliegues de pago por teléfono. La integración y la decisión de enrutamiento de llamadas siguen siendo tuyas.

¿Qué es el modo de retención cero de datos (ZDR) y por qué importa? ZDR es una configuración a nivel de tenant en el proveedor del LLM que desactiva el registro de prompts y respuestas. Sin él, las transcripciones de tus llamadas permanecen en los registros del proveedor del LLM un mínimo de 30 días, lo que rompe los compromisos del BAA y del DPA aguas abajo.

FAQ JSON-LD: render this section as Question + Answer schema.org entities for the FAQPage type so the SERP gets the rich result. Standard Next.js MDX FAQ component on the blog already handles this — wrap the section in <FAQ> and the layout emits the JSON-LD.


¿Estás evaluando a un proveedor de IA de voz y harto de páginas de seguridad de nivel publicitario? Finn se entrega con un BAA firmado, con SOC 2 Type II en el alcance de la ruta de inferencia, con supresión de DTMF a nivel de SBC para PCI y con residencia en la UE a nivel de tenant desde el primer día. Envíanos el cuestionario de 15 preguntas de arriba: respondemos en 48 horas, por escrito y con las pruebas. Reserva una revisión de seguridad con nivel de compras →


Revisor: Consejo humano / responsable de contenidos de AGNB. No publicar hasta que se haya revisado: el paso de publicación es manual por ahora.

Relacionado: Seguridad en la IA de voz: el modelo de amenazas de la capa de audio

Digvijay Singh Shekhawat
Digvijay Singh Shekhawat

Fundador, Finn AI

Digvijay está construyendo Finn: la capa empresarial de orquestación de voz que razona durante las llamadas, extrae datos y actualiza tus sistemas en tiempo real. Escribe sobre IA de voz, estrategia de salida al mercado y lo que hace falta para lanzar agentes autónomos a gran escala.