Cifrado en herramientas de transcripción: cómo leer las afirmaciones

Most encryption claims in transcription marketing describe two protections that apply to every respectable cloud service: TLS in transit and AES-256 at rest. Understanding what each one actually covers, and where both stop, lets you evaluate providers honestly and avoid spending effort on the wrong questions.

Two Layers, Two Threat Models

For any cloud transcription service, encryption operates at two distinct points in the data's journey.

Encryption in transit protects audio while it moves from your device to the provider's servers. The protocol is TLS (Transport Layer Security). TLS 1.3 is now the current standard, with roughly 75% adoption among major websites as of mid-2025 according to SSL Pulse tracking. TLS 1.2 remains cryptographically acceptable. TLS 1.0 and 1.1 are obsolete and should not appear anywhere.

Encryption at rest protects audio and transcripts while stored on the provider's disks. The standard is AES-256 (Advanced Encryption Standard with 256-bit keys). Cloudflare R2, which CATT uses, implements AES-256-GCM with keys managed internally by Cloudflare. AWS S3, used by Otter.ai and others, provides the same algorithm via server-side encryption.

These two protections solve different problems. In-transit encryption defeats network eavesdroppers on public WiFi, ISPs, and intermediate routers. At-rest encryption defeats anyone who steals a physical disk or gets unauthorized access to storage infrastructure.

What neither protection covers: the provider's own application, which decrypts data transparently to process it. This is the limit most marketing materials quietly skip past.

What TLS in Transit Actually Guarantees

When you upload a file, TLS creates an encrypted tunnel between your browser or app and the provider's server. Even on an untrusted network, a passive observer sees only encrypted gibberish.

TLS specifically guarantees three things:

• Confidencialidad: el contenido es ilegible para terceros en la red
• Integridad: los datos no fueron modificados durante la transmisión
• Autenticación: el servidor al que te conectas es quien dice ser según el certificado

Puedes comprobar la calidad TLS de cualquier proveedor tú mismo en ssllabs.com/ssltest. La herramienta puntúa la configuración completa, incluyendo qué versiones de protocolo se admiten y qué suites de cifrado están activas. Busca una calificación A o A+, y marca cualquier servicio que aún soporte TLS 1.0 o 1.1.

¿Sigue siendo aceptable TLS 1.2 para un servicio de transcripción en 2026?

Sí, TLS 1.2 sigue siendo criptográficamente aceptable, aunque TLS 1.3 es ahora el estándar preferido. Lo que TLS no protege: un atacante que ya haya comprometido tu dispositivo, un servidor comprometido, o que el proveedor lea tus datos después de que lleguen. TLS termina en el servidor. Después de eso, los datos están en texto plano dentro de la aplicación.

Qué Garantiza Realmente AES-256 en Reposo

AES-256 en reposo significa que la capa de almacenamiento cifra tus datos en el disco. La documentación de Cloudflare para R2 lo describe explícitamente: todos los objetos y sus metadatos se cifran con AES-256-GCM. Amazon S3 usa AES-256 mediante SSE (cifrado del lado del servidor), que Otter.ai, Descript y otros servicios de transcripción heredan de su capa de almacenamiento en AWS.

¿Significa el cifrado AES-256 que un proveedor de transcripción no puede leer mis archivos?

No. El cifrado en reposo protege específicamente contra el robo físico de discos en un centro de datos, hardware retirado que no se borró correctamente, y el acceso entre inquilinos a nivel de infraestructura en entornos cloud multiinquilino.

No protege contra:

• El servidor de aplicación leyendo datos a través de rutas de código normales (tiene las claves de descifrado y las usa automáticamente)
• Empleados del proveedor con acceso a nivel de aplicación
• Un sistema de gestión de claves comprometido
• Controles de acceso mal configurados que exponen un bucket de almacenamiento públicamente (lo que eludiría el cifrado por completo)

El proveedor tiene acceso. Eso no es un fallo en su implementación. Es así como funciona el cifrado del lado del servidor por diseño.

Por qué el cifrado de extremo a extremo real es imposible para el ASR en la nube

¿Qué significa "cifrado de extremo a extremo" cuando una herramienta de transcripción lo afirma?

El cifrado de extremo a extremo (E2EE) en el sentido de Signal significa que el proveedor está bloqueado criptográficamente: no puede descifrar tus datos ni siquiera si se lo obliga. La clave privada nunca sale de tu dispositivo.

Esto no es alcanzable para la conversión de voz a texto en la nube, y cualquier proveedor que afirme lo contrario merece un escrutinio cuidadoso. El modelo de IA debe procesar audio en texto plano para producir una transcripción. No puedes transcribir audio que permanece cifrado en la capa de procesamiento.

Cuando los proveedores de transcripción usan la frase "cifrado de extremo a extremo", normalmente quieren decir una de dos cosas más débiles:

Cifrado del lado del cliente antes de la subida. El dispositivo del usuario cifra el audio antes de enviarlo al servidor. El servidor lo descifra, ejecuta el modelo, vuelve a cifrar la transcripción y la envía de vuelta. El proveedor tiene acceso al texto plano durante la ventana de transcripción. Esto limita la duración de la exposición, pero no la elimina.

Enclaves de computación confidencial. El procesamiento del lado del servidor ocurre dentro de un enclave aislado por hardware (Intel SGX, AMD SEV, Intel TDX) donde los operadores del proveedor no pueden inspeccionar la memoria, aunque el código del proveedor esté en ejecución. Azure ha ofrecido transcripción con Whisper dentro de contenedores confidenciales usando AMD SEV-SNP. Esto reduce significativamente la superficie de exposición, pero aún requiere que el modelo acceda al texto plano dentro del enclave. La garantía es el aislamiento por hardware, no un bloqueo criptográfico.

La investigación sobre cifrado homomórfico para audio, donde el cómputo ocurre sobre el texto cifrado sin descifrarlo, está activa pero no lista para producción. Un artículo de 2025 sobre procesamiento de señales aproximado cuantizado logró el primer pipeline seguro de audio crudo usando cifrado completamente homomórfico. El punto de referencia: calcular una ventana de audio de 64 milisegundos en FHE tomó 12,970 segundos en un Apple M2. En claro tomó 0.004 segundos. Esto es una dirección de investigación, no una funcionalidad de proveedor.

La única vía para una transcripción genuinamente inaccesible para el proveedor hoy en día es el autoalojamiento. Ejecuta Whisper en tu propio hardware y no habrá proveedor que exponga tu audio.

Lo que los principales servicios de transcripción realmente revelan

Esto es lo que los principales proveedores publican sobre su postura de cifrado, verificado contra la documentación del proveedor:

Fuentes: páginas de seguridad de los proveedores y documentación pública, verificadas en julio de 2026. La disponibilidad de BAA suele requerir contratos enterprise. Verifica las condiciones actuales con cada proveedor.

Si un proveedor no publica estos detalles en absoluto, tómalo como una señal: o no ha implementado estándares básicos o no ha invertido en documentación para clientes preocupados por la seguridad.

Claves de cifrado gestionadas por el cliente: cuándo importan

Los despliegues estándar usan claves gestionadas por el proveedor: el sistema del proveedor cifra tus datos y conserva las claves. No tienes capacidad de revocar el acceso rotando una clave desde tu lado.

Las claves de cifrado gestionadas por el cliente (CMEK) invierten este esquema. Aportas tus propias claves mediante un servicio de gestión de claves (AWS KMS, Google Cloud KMS), y el almacenamiento del proveedor no puede descifrar los datos sin que tu infraestructura de claves responda. Puedes revocar el acceso deshabilitando la clave. Tienes un registro de auditoría de cada uso de clave.

AWS Transcribe admite claves gestionadas con KMS para el cifrado de salida. Google Cloud Speech-to-Text v2 admite CMEK para todos los recursos y trabajos de transcripción por lotes. Ambos están documentados en sus respectivas referencias para desarrolladores.

CATT does not offer CMEK. Los archivos viven en Cloudflare R2 con claves gestionadas por Cloudflare. Para clientes cuyos requisitos de seguridad incluyen la propiedad y revocabilidad de las claves, AWS Transcribe o Google Cloud STT v2 son las vías adecuadas, según la comparativa de precios de la API de transcripción de voz.

Lo que el cifrado no resuelve

Esto importa tanto como lo que sí resuelve.

Acceso del proveedor. TLS y AES-256 no impiden que la propia aplicación del proveedor acceda a tus datos. Los controles de acceso internos, las políticas de mínimo privilegio y el registro de auditoría son las protecciones relevantes aquí. Pregunta si los empleados pueden acceder al audio de los clientes, bajo qué circunstancias y si ese acceso queda registrado.

Cuentas comprometidas. Si te roban las credenciales de acceso, el atacante se autentica como tú y accede por las vías normales de la aplicación. El cifrado no ofrece ninguna protección en este caso. La autenticación multifactor en tu cuenta importa más que el algoritmo de cifrado.

Dispositivo comprometido. Si tu portátil está comprometido antes de subir el audio, este es legible en tu dispositivo antes de entrar en cualquier canal cifrado. La seguridad del dispositivo final es un dominio aparte del cifrado en tránsito y en almacenamiento.

Controles de acceso mal configurados. Un bucket de almacenamiento con lectura pública expone tus datos independientemente del AES-256. La configuración correcta de las políticas de acceso es necesaria junto con el cifrado. Pregunta si los proveedores han tenido incidentes de exposición pública.

Datos de entrenamiento de IA. Si el proveedor usa el audio de los clientes para entrenar o mejorar sus modelos, el cifrado protege los datos en almacenamiento, pero no aborda lo que ocurre cuando el modelo los procesa. Pregunta explícitamente si el audio se usa para entrenamiento y consíguelo por contrato. Fireflies.ai, por ejemplo, publica una política de retención de datos de 0 días con sus proveedores de transcripción, lo que aborda este punto de forma específica.

Una postura de seguridad completa combina cifrado con controles de acceso, autenticación, registro de auditoría, gestión de proveedores y políticas claras de uso de datos. El cifrado es una capa, no la solución completa.

Consulta ¿es privada la transcripción con IA? para ver el panorama general del manejo de datos, y transcripción conforme al RGPD para el marco regulatorio en contextos europeos.

Qué preguntar a un proveedor antes de comprometerse

Para la mayoría de los casos de uso empresarial, estas cinco preguntas cubren lo esencial:

1. ¿Qué versiones de TLS y conjuntos de cifrado admiten? (Una calificación A/A+ en SSL Labs es el estándar)
2. ¿Están cifrados los datos en reposo y con qué algoritmo?
3. ¿Quién tiene las claves de cifrado y puedo aportar las mías?
4. ¿También están cifradas las copias de seguridad y los registros?
5. ¿Usan audio de clientes para entrenar o mejorar sus modelos?

¿Qué opciones de cifrado existen para sectores regulados como la sanidad?

El documento más importante no es la especificación de cifrado, sino un Acuerdo de Asociado Comercial (BAA) firmado por el proveedor. Sin un BAA, usar un servicio de transcripción con información sanitaria protegida (PHI) puede infringir la HIPAA, independientemente de las afirmaciones sobre AES-256. Rev, Otter.ai y Fireflies.ai (nivel empresarial) publican su disponibilidad de BAA. Para un control total de las claves, AWS Transcribe y Google Cloud Speech-to-Text v2 admiten claves de cifrado gestionadas por el cliente (CMEK) a través de sus respectivos servicios KMS.

Para sectores regulados, añade estas preguntas:

6. ¿Tienen un Acuerdo de Asociado Comercial (BAA) firmado para HIPAA?
7. ¿Tienen un Acuerdo de Procesamiento de Datos (DPA) para el RGPD?
8. ¿Están auditados según SOC 2 Tipo II y puedo ver el informe?
9. ¿Admiten claves de cifrado gestionadas por el cliente?
10. ¿Cómo gestionan la rotación de claves y responden ante una brecha de seguridad?

A note on compliance language. Saying a tool "is HIPAA compliant" or "is GDPR compliant" is imprecise. Compliance is a property of the specific deployment and the agreements you have in place with the vendor, not a badge the tool carries independently. A signed BAA with a provider that has appropriate technical controls is what matters for HIPAA. A signed DPA with appropriate data handling commitments is what matters for GDPR. Ask for the documents, not the badge.

Honest Disclosure for CATT

What CATT does:

• TLS 1.2+ in transit, delivered through Cloudflare's edge network
• AES-256-GCM at rest on Cloudflare R2, with Cloudflare-managed keys
• Encrypted backups inherited from R2's default protection
• Role-based access controls in the application

What CATT does not do:

• Customer-managed encryption keys (CMEK)
• Hardware security module (HSM) integration
• FIPS 140-3 certified key handling (note: FIPS 140-2 validations sunset September 2026)
• Confidential computing enclaves for processing
• True client-side encryption at upload

For the majority of business and personal transcription use cases, the first list is adequate. If you need the second list, you are operating in an enterprise or regulated industry context that likely requires a different provider, or self-hosting. If you need a clean, fast transcript without a meeting bot or complex compliance overhead, CATT's audio-to-text tool handles it directly without sign-up.

See auto-deletion of transcription files for practical steps to reduce your data footprint after transcription.

Sources

• Documentación de seguridad de datos de Cloudflare R2 - AES-256-GCM en reposo, TLS en tránsito, claves gestionadas por Cloudflare
• Página de privacidad y seguridad de Otter.ai - AES-256 mediante AWS SSE, SOC 2 Tipo II
• Página de seguridad de Descript - AES-256 en reposo, TLS 1.2 en tránsito, SOC 2 Tipo II
• Página de seguridad de Fireflies.ai - AES-256 en reposo, TLS en tránsito, SOC 2 Tipo II, HIPAA-BAA empresarial
• Documentación de CMEK de Google Cloud Speech-to-Text - Claves de cifrado gestionadas por el cliente, API v2
• Documentación de cifrado de datos de AWS Transcribe - Integración con KMS para cifrado de salida
• Prueba de servidor de Qualys SSL Labs - Herramienta de evaluación de configuración TLS
• Seguimiento de adopción de TLS 1.3 en SSL Pulse - 75% de adopción de TLS 1.3 entre los sitios web más visitados, mediados de 2025
• Procesamiento de señales aproximado cuantizado para audio FHE (preprint de 2025) - Pruebas de rendimiento de procesamiento de audio con cifrado homomórfico
• Página de seguridad HIPAA de Rev.com - Disponibilidad de BAA y detalles del nivel HIPAA