El mapa de datos de la IA de voz: grabaciones, transcripciones, API y escritura en el CRM

Un mapa de datos de IA de voz es una sola página que enumera cada artefacto que genera una llamada, dónde se almacena, cuánto tiempo se conserva, cómo sale de la plataforma y en cuáles de tus sistemas acaba. El equipo de seguridad lo pide antes de firmar, y TI y operaciones lo usan para planificar la integración.

Esta guía construye ese mapa para Retell AI a partir de la documentación de Retell. Donde la documentación no dice nada, te indica qué preguntar.

¿Qué datos genera una llamada de IA de voz?

Una llamada conectada en Retell produce siete tipos de datos, todos en un único objeto de llamada identificado por call_id:

• Grabación. Audio WAV, como archivo mezclado de un solo canal y como archivo multicanal con cada interlocutor en su propio canal.
• Transcripción. Texto plano, una lista de intervenciones con marcas de tiempo y una versión que intercala cada llamada a herramienta y su resultado.
• Análisis posterior a la llamada. Campos integrados (call_summary, user_sentiment, call_successful, in_voicemail) más campos personalizados que defines como booleano, texto, número o selector.
• Logs. Un log público de las solicitudes y respuestas del LLM, más un log de recuperación de la base de conocimiento si el agente utiliza una.
• Variables y metadatos. Variables dinámicas que se pasan o se recogen durante la llamada, y un objeto metadata de formato libre para tus propios ID.
• Números de teléfono. El identificador de llamada en las llamadas entrantes y el número marcado en las salientes.
• Campos operativos. Marcas de tiempo, duración, estado, motivo de desconexión, destino de la transferencia, latencia y coste.

La mayoría solo están disponibles cuando termina la llamada, y los campos de análisis personalizados quedan vacíos en las llamadas que nunca llegaron a conectarse.

¿Dónde se guarda cada dato y cómo se extrae?

Todo se guarda en el registro de la llamada dentro de tu espacio de trabajo de Retell y sale por tres vías: webhooks, la API y las exportaciones CSV del panel.

Cuatro detalles importan al conectarlo todo:

• List Calls omite las transcripciones y recording_url para que las respuestas sean ligeras, así que una carga retroactiva masiva lo combina con Get Call para cada call_id.
• Los webhooks agotan el tiempo de espera a los 10 segundos y se reintentan hasta 3 veces, así que deduplica por call_id.
• Cada webhook incluye una cabecera x-retell-signature que verificas con tu clave de API, y Retell publica una IP para añadir a tu lista de permitidas (100.20.5.228).
• Las exportaciones CSV se crean en el panel a partir de los filtros activos y se conservan durante una semana. List Export Requests (GET /v2/list-export-requests) devuelve el estado y la URL de descarga de cada exportación.

¿Cuánto tiempo conserva Retell los datos de las llamadas y se puede desactivar el almacenamiento?

Por defecto, Retell conserva los datos de las llamadas de forma indefinida. Puedes cambiarlo para cada agente en Security & fallback settings.

Periodo de retención. Elige 1, 3, 7, 30, 60, 90, 180, 365 o 730 días, o conservarlos para siempre; a través de la API, configura data_storage_retention_days. Los datos caducados se eliminan a diario y de forma permanente, incluidas grabaciones, transcripciones, logs, variables dinámicas y metadatos. Retell conserva internamente algunos metadatos básicos, pero la llamada deja de aparecer en el historial y en las respuestas de la API.

Modo de almacenamiento. Elige uno de estos tres:

• Everything. Se almacenan transcripciones, grabaciones y logs.
• Everything except PII. El contenido se almacena sin las categorías de PII que selecciones, y los originales sin depurar se eliminan.
• Basic Attributes Only. No se almacenan transcripciones, grabaciones ni logs, y Get Call devuelve la llamada sin ellos.

Si desactivas el almacenamiento, los webhooks siguen incluyendo la transcripción y la grabación, pero el enlace de la grabación caduca 10 minutos después de que llegue el webhook. Construye tu receptor de webhooks antes de hacer el cambio.

El parámetro data_storage_setting de Update Call puede hacer que una llamada concreta sea más restrictiva, nunca menos. Los usuarios autorizados del panel pueden eliminar los datos sensibles de una llamada o borrar la llamada, y Delete Call (DELETE /v2/delete-call/{call_id}) hace lo mismo por API. Ambas acciones son irreversibles.

Las URL de grabaciones y logs no caducan por defecto. Activa Opt In Secure URLs (opt_in_signed_url) y cada URL que solicites se firmará y caducará a las 24 horas, o tras la duración que configures, de 1 minuto a 7 días.

¿Qué elimina realmente la depuración de PII?

Con Everything except PII, Retell detecta tras la llamada las categorías que selecciones y sustituye cada aparición por un marcador numerado como [email 1]. Las 13 categorías son: nombre de persona, dirección, email, SSN (número de la Seguridad Social de EE. UU.), pasaporte, permiso de conducir, tarjeta de crédito, cuenta bancaria, contraseña, PIN, identificador médico, fecha de nacimiento y número de cuenta de cliente.

La depuración abarca más que la transcripción: la grabación (los intervalos con PII se convierten en un pitido), los logs públicos, las variables dinámicas, los metadatos, el resumen de la llamada y los datos de análisis personalizados, y los argumentos y resultados de las llamadas a herramientas. Los dígitos DTMF pasan a ser [PII INFO] siempre que haya alguna categoría activada.

Seleccionar phone_number elimina el número del cliente del propio registro de la llamada (from_number en las entrantes, to_number en las salientes). Déjalo desactivado si algún sistema posterior hace la correspondencia por ese número.

Algunos campos nunca se depuran, como call_id, agent_id, las marcas de tiempo, el estado, el motivo de desconexión, call_successful, user_sentiment, el coste y los atributos personalizados. Para eliminarlos también, usa Basic Attributes Only o un periodo de retención.

El acceso se basa en roles. El rol Member solo ve el historial depurado, mientras que los roles Admin y Developer pueden ver las transcripciones y grabaciones sin depurar.

¿Dónde se alojan los datos y qué debería preguntar seguridad?

La documentación de cumplimiento de Retell indica que Retell cumple con HIPAA y el RGPD y cuenta con las certificaciones SOC 2 Tipo 1 y Tipo 2, que cumple el RGPD utilizando AWS con un anexo de tratamiento de datos conforme al RGPD, y que actualmente no opera servicios dentro de la Unión Europea. El BAA y el DPA (con las cláusulas contractuales tipo de la UE) se firman de forma autónoma sin coste adicional, y los certificados e informes están disponibles en el Compliance Trust Center.

La documentación pública no especifica una región de almacenamiento por artefacto ni nombra el servicio de almacenamiento subyacente, así que no des nada por supuesto. Pregúntaselo a Retell por escrito (support@retellai.com gestiona revisiones de seguridad, evaluaciones de proveedores y listas de subencargados del tratamiento) y confirma tu propia configuración:

• ¿Dónde se procesa el audio de las llamadas y dónde se almacena cada artefacto de la tabla?
• ¿Qué subencargados acceden al audio, las transcripciones y el análisis?
• ¿El periodo de retención y el modo de almacenamiento de cada agente en producción se ajustan a nuestra política?
• ¿Están activadas las URL seguras, con una caducidad que aceptemos?
• ¿Qué usuarios nuestros tienen los roles Admin o Developer y pueden ver datos sin depurar?
• ¿Nuestro receptor de webhooks verifica las firmas y guarda lo que necesitamos antes de que la retención lo elimine?

Para la parte contractual (BAA frente a DPA, bloqueos por residencia de datos, fases de compras), consulta lo que deben saber los compradores empresariales antes de desplegar IA de voz.

¿Qué llega a tu CRM y por qué vía?

Depende de la vía. Las integraciones nativas de Retell con Salesforce, HubSpot, Microsoft Dynamics 365, GoHighLevel y Zoho CRM importan contactos (cada 5 minutos a fecha de agosto de 2026), mapean los campos del análisis posterior a la llamada a campos de contacto, devuelven los cambios de campos al CRM y registran cada llamada como una actividad. Una Task de Salesforce, por ejemplo, incluye la duración, el resumen, el ID de conversación, los números de teléfono y el motivo de desconexión. La sincronización saliente solo actualiza registros existentes, salvo que actives Create new contacts in CRM, y la actividad solo se registra para contactos importados desde el CRM conectado.

Las grabaciones y las transcripciones completas solo llegan al CRM cuando la vía las transporta, como hacen el registro de llamadas de la app de HubSpot Marketplace o tu propio proceso de escritura mediante webhook. Para ver la mecánica desde el disparador hasta la escritura, consulta el flujo de trabajo del CRM a la IA de voz; el directorio de integraciones muestra lo que se conecta de forma nativa.

¿Cómo forman la lectura previa y la escritura posterior a la llamada un único circuito comprobable?

Una integración está terminada cuando una llamada lee el registro correcto antes de empezar, concierta la cita durante la conversación y escribe la nota del técnico después, todo en el mismo registro. La página Workflow del agente de Retell lo modela como un único grafo. En una línea de servicio técnico de campo:

1. Lectura previa a la llamada. Una función previa a la llamada busca {{user_number}} en el CRM y asigna el ID del registro a una variable. Las llamadas entrantes esperan hasta 1 minuto a que termine; las salientes permiten 5 minutos antes de marcar.
2. Reserva durante la llamada. El agente concierta la cita con una herramienta de calendario (calendarios de Cal.com, Calendly o GoHighLevel) o con una función personalizada que llama a la API de tu sistema de programación, que puede verificar la cabecera X-Retell-Signature. El ID de la reserva se guarda en una variable.
3. Escritura posterior a la llamada. Una función posterior a la llamada crea la nota: las herramientas de Salesforce, Dynamics 365 y Zoho crean notas, Zendesk añade notas privadas y cualquier otro sistema necesita una función personalizada. Reutiliza el ID del registro obtenido antes de la llamada, escribe {{call_summary}} o un campo personalizado como access_instructions, y está condicionada para ejecutarse solo cuando existe la variable de la reserva. Las funciones posteriores a la llamada se detienen a los 5 minutos.

Si la búsqueda falla, se omiten todas las funciones que dependen de ella, de modo que no se escribe ninguna nota sin ID de registro, y la llamada sigue adelante. Una limitación para los equipos de plataforma: las funciones de workflow solo se configuran en el panel y no forman parte de la API pública (a fecha de agosto de 2026), así que no estarán en tu infraestructura como código.

Prueba el circuito en dos pasadas:

• Pruebas de simulación con mocks. Simula con mocks todas las funciones personalizadas y herramientas de calendario. Una función sin mock llama a su endpoint real y puede crear una reserva real.
• Una llamada real contra un registro de sandbox. Haz una llamada de prueba web o telefónica y ábrela en el historial de llamadas. Las funciones previas a la llamada aparecen en Before call y las posteriores en Call ended, con los argumentos enviados y las respuestas devueltas. Dala por buena solo si la reserva existe, la nota está en el mismo registro y tu receptor ha registrado un único evento call_analyzed para ese call_id.

Para el plan piloto completo, consulta cómo evaluar una plataforma de agentes de voz antes de pasar a producción. Para ver cómo funcionan las funciones previas y posteriores a la llamada, consulta Retell Workflows.

Pon el mapa a trabajar

Rellena la tabla para cada agente y adjunta las respuestas de seguridad: una sola página te servirá para la revisión, el plan de integración y la pista de auditoría. Para ver qué extrae Retell de cada llamada y cómo fluye hacia tus sistemas, empieza por el análisis posterior a la llamada de Retell.