raabt.ai

Cifrado de datos en empresas: guía para chats con clientes

Cifrado de datos en empresas que venden por WhatsApp, Instagram y Telegram: qué cifrar, en reposo y en tránsito, cómo guardar tokens y 10 preguntas al proveedor.

MR

Mohamed Rasul

Founder & CEO, Raabt AI

10 min de lectura
Cifrado de datos en empresas: guía para chats con clientes

Cada pedido por WhatsApp, cada mensaje directo de Instagram y cada consulta de soporte en Telegram deja datos del cliente: números de teléfono, direcciones de entrega, historiales de chat y los tokens de acceso que conectan tus canales. El cifrado de datos en empresas convierte esos datos en texto cifrado ilegible para cualquiera que no tenga la clave, tanto mientras viajan por la red como mientras reposan en bases de datos y copias de seguridad.

Puntos clave

  • El cifrado de datos en empresas tiene dos capas: el cifrado en tránsito (TLS) protege los datos en movimiento y el cifrado en reposo (normalmente AES) protege los datos almacenados.
  • Los tokens de acceso de los canales, las claves API y los secretos de webhook son credenciales. Un token filtrado puede permitir que un atacante actúe en nombre de tu empresa, así que cífralos a nivel de campo.
  • El cifrado de disco protege un disco robado, no un servidor en marcha. El cifrado a nivel de campo, con las claves guardadas fuera de la base de datos, sigue protegiendo esos campos en un volcado filtrado.
  • AES-256-GCM es cifrado autenticado: oculta los datos y detecta manipulaciones, y depende de no reutilizar nunca un nonce con la misma clave.
  • El cifrado no detiene a quien tiene permiso para descifrar. Una plataforma de respuestas automáticas con IA necesita leer los mensajes para responderlos, así que el control de acceso y la retención pesan tanto como los algoritmos.

Qué debe cubrir el cifrado de datos en empresas que venden por chat

Una empresa que vende por chat, por ejemplo con una bandeja de entrada con IA para WhatsApp, tiene su propio inventario de datos:

  1. Credenciales y secretos. Tokens de acceso de páginas de Facebook y de WhatsApp Business, tokens de bots de Telegram, claves de proveedores de IA, claves de proveedores de pago y secretos de webhook.
  2. Datos personales de clientes. Números de teléfono, correos electrónicos, direcciones de entrega e identificadores de cliente. En el comercio por chat, el número de teléfono suele ser la identidad del cliente.
  3. Historiales de chat y archivos. Transcripciones, notas de voz, fotos y facturas que envían los clientes.
  4. Contraseñas del equipo. Estas se deben hashear, no cifrar (lo vemos más abajo).
  5. Dispositivos del equipo. Laptops y teléfonos que abren la bandeja de entrada o guardan exportaciones. Activa FileVault o BitLocker, códigos de bloqueo y borrado remoto.
  6. Copias. Respaldos, exportaciones CSV, registros y bases de datos de prueba, que suelen estar menos protegidos que producción.

Una regla simple para la protección de datos de clientes: cifra a nivel de campo todo lo que dé acceso o identifique a una persona, y dale a cada copia la misma protección que al original.

Cifrado en reposo y en tránsito

El cifrado en tránsito protege los datos mientras viajan entre un navegador, tu servidor y APIs de terceros. El cifrado en reposo protege los datos guardados en discos, en bases de datos y en copias de seguridad.

AspectoCifrado en tránsitoCifrado en reposo
Protege frente aEscuchas, manipulación, servidores falsosDiscos robados, volcados filtrados, respaldos expuestos
Estándar habitualTLS 1.2 o TLS 1.3AES-256, a menudo AES-256-GCM
Dónde aplicaDel navegador a la aplicación, webhooks, llamadas a APIsDisco, base de datos, campos individuales, respaldos
No cubreLos datos ya descifrados tras llegar a destinoLos datos en uso por una aplicación en marcha

NIST SP 800-52 Rev. 2 exige que los servidores TLS del gobierno de Estados Unidos admitan TLS 1.2 y que admitan TLS 1.3 a más tardar en enero de 2024. Es una base razonable para cualquier empresa: acepta TLS 1.2 y 1.3 y desactiva todo lo anterior.

TLS solo protege el trayecto. La Cloud API de WhatsApp entrega los webhooks por HTTPS, y la documentación de Meta explica que Cloud API descifra los mensajes entrantes y los reenvía a la empresa, y que los conserva 30 días como máximo. A partir de ahí mandan el almacenamiento y los controles de acceso.

Cifrado de disco, de base de datos y a nivel de campo

El cifrado en reposo llega por capas:

  • El cifrado de disco o de volumen protege un disco robado o desechado. Mientras el servidor funciona, el sistema operativo descifra los datos de forma automática, así que un atacante dentro del servidor ve datos en claro.
  • El cifrado de los archivos de la base de datos tiene el mismo límite: cualquiera que pueda consultar la base de datos recibe texto plano.
  • El cifrado a nivel de campo cifra columnas concretas, como un token o un número de teléfono, dentro de la aplicación y antes de que lleguen a la base de datos. La clave vive en otro lugar, así que un volcado filtrado o un respaldo copiado muestra texto cifrado en esos campos.

El costo es la búsqueda: no puedes aplicar un filtro SQL normal sobre una columna cifrada. Un enfoque práctico es reservar el cifrado a nivel de campo para los secretos y para los datos de contacto de más riesgo. Los equipos que necesitan buscar clientes por teléfono o correo pueden guardar un hash con clave (un índice ciego) junto al texto cifrado y buscar sobre él.

AES-256-GCM: tamaño de clave y modo

AES está definido en FIPS 197 con claves de 128, 192 y 256 bits. AES-256 usa la mayor de las tres.

El modo importa tanto como el tamaño de la clave. GCM (NIST SP 800-38D) es cifrado autenticado: mantiene los datos confidenciales y detecta si alguien modificó el texto cifrado. Nunca reutilices un nonce con la misma clave: reutilizarlo rompe las garantías de GCM, así que deja que una biblioteca con mantenimiento activo genere los nonces y nunca escribas tu propia criptografía.

Cómo guardar claves API y tokens de acceso de forma segura

Elige según si necesitas recuperar el valor original:

  • Cifra los secretos que tengas que enviar a otro sistema: tokens de acceso de WhatsApp e Instagram, tokens de bots de Telegram, claves de proveedores de IA y claves de pago. Usa AES-GCM a nivel de campo con una clave guardada fuera de la base de datos.
  • Hashea los secretos que solo verificas: contraseñas, claves API de socios y códigos de un solo uso. Un hash no se puede descifrar para volver al valor original, pero los valores cortos o previsibles se pueden romper por fuerza bruta, así que usa un hash lento como Argon2id o bcrypt para las contraseñas y un HMAC con clave para los códigos.
  • Mantenlos fuera de los registros, de los mensajes de error, de la analítica y de las URL.
  • Limita el alcance y rota. Pide solo los permisos que el token necesita y reemplaza los tokens cuando alguien con acceso deja el equipo.

El cifrado en reposo no protege un token mientras está descifrado en memoria durante una llamada a la API. El endurecimiento del servidor y el mínimo privilegio reducen ese riesgo.

Gestión de claves de cifrado: lo básico

El cifrado vale lo que valga el lugar donde guardas la clave. El fallo clásico es una clave guardada junto a los datos, en la misma base de datos o en un archivo de configuración subido al repositorio.

  • Separa las claves de los datos. Guárdalas en un gestor de secretos, en un KMS o en una configuración de servidor a la que la base de datos no llegue.
  • Usa cifrado de sobre cuando crezcas. Una clave maestra cifra las claves de datos, así que rotarla no obliga a volver a cifrarlo todo.
  • Deriva claves específicas por propósito con una función de derivación de claves como HKDF.
  • Planifica la rotación y la recuperación. Una clave perdida son datos perdidos, también en las copias de seguridad.

Control de acceso y mínimo privilegio: el cifrado no basta

El cifrado detiene a quien no tiene la clave, no a las personas ni a los sistemas con permiso para descifrar. Una plataforma de respuestas automáticas con IA tiene que leer el mensaje del cliente para escribir una respuesta, así que sus servidores procesan mensajes legibles.

La misma lógica aplica más arriba en la cadena. El informe técnico de seguridad de WhatsApp no considera cifrados de extremo a extremo los chats con empresas que usan Cloud API, porque los mensajes no se entregan directamente a un extremo que la empresa controle. Revisa WhatsApp Business Cloud API frente a la app Business antes de elegir tu configuración.

Así que la siguiente capa trata de quién puede llegar a los datos:

  • Control de acceso de mínimo privilegio: dale a cada persona del equipo el rol más pequeño que le sirva. Un agente que responde chats no necesita facturación.
  • Inicio de sesión reforzado: agrega un segundo paso de verificación y revoca las sesiones al cerrar sesión.
  • Aislamiento entre empresas: cada solicitud debe demostrar que quien la hace pertenece a esa empresa.
  • Registros de auditoría y retención: deja constancia de las acciones privilegiadas y conserva los historiales de chat solo el tiempo que los necesites.

Copias de seguridad, exportaciones y retención

Las copias de seguridad son copias completas de los datos de clientes, y suelen guardarse más tiempo y vigilarse menos que producción. Cifra los archivos de respaldo, limita quién puede descargarlos, prueba las restauraciones incluida la recuperación de claves y borra las exportaciones CSV antiguas que circulan por correo o por chat.

El cifrado también tiene peso legal. El artículo 32 del RGPD menciona el cifrado como medida de seguridad, y el artículo 34(3)(a) permite al responsable no notificar la brecha a las personas afectadas cuando el cifrado hizo que los datos fueran ininteligibles para quien no estaba autorizado. El deber del artículo 33 de notificar a la autoridad de control en un plazo de 72 horas desde que se tiene conocimiento de la brecha es independiente. La PDPL de Arabia Saudita y la KVKK de Turquía también fijan plazos de 72 horas ante el regulador.

Esto es información general, no asesoramiento legal. Que aplique el RGPD u otra ley, y que una excepción encaje en una brecha concreta, depende de tu situación, así que consulta a un abogado calificado.

Preguntas para cualquier proveedor de chat o CRM

Antes de conectar tus canales, usa estas preguntas de seguridad para proveedores de chatbot como un cuestionario por escrito:

  1. ¿Qué versiones de TLS aceptan sus endpoints?
  2. ¿Qué datos se cifran en reposo y en qué capa? ¿Incluye el contenido de los mensajes?
  3. ¿Los tokens de canal y las claves API se cifran a nivel de campo, y dónde se guarda la clave?
  4. ¿Las copias de seguridad están cifradas y quién puede acceder a ellas?
  5. ¿Su personal puede leer nuestras conversaciones, y queda registrado ese acceso?
  6. ¿Qué roles y permisos podemos configurar para nuestro equipo?
  7. ¿Cómo se aíslan nuestros datos de los de otros clientes?
  8. ¿Nuestros chats se usan para entrenar modelos de IA, sea por ustedes o por sus proveedores de IA?
  9. ¿Quiénes son sus subencargados y dónde se almacenan los datos?
  10. ¿Firmarán un DPA, y en cuánto tiempo se borran los datos cuando nos vayamos?

Desconfía de respuestas como "cifrado de grado militar" o "todos los datos totalmente cifrados". Un proveedor confiable nombra el algoritmo, la capa y las carencias.

Qué cifra y protege Raabt hoy

Cada punto de esta lista refleja el código de Raabt a septiembre de 2026.

  • Cifrado a nivel de campo: los campos sensibles se cifran a nivel de aplicación con AES-256-GCM. Las escrituras nuevas usan una clave derivada con HKDF-SHA256, y los valores antiguos se vuelven a cifrar con ella la próxima vez que se guardan. La aplicación no arranca sin una clave de al menos 32 caracteres.
  • Qué se cifra: credenciales y tokens (tokens de acceso de canal de Facebook, Instagram, WhatsApp y Telegram, claves API de proveedores de IA y de pago, secretos de webhook) y ciertos datos de contacto (números de teléfono, correos y direcciones de pedido de los clientes).
  • Hashing: las contraseñas usan Argon2id (19 MiB de memoria, 2 iteraciones), y los hashes antiguos de bcrypt se actualizan al iniciar sesión. Los secretos de las claves API de socios se guardan solo como hashes SHA-256.
  • Inicio de sesión: los accesos con correo y contraseña exigen un código de un solo uso enviado al correo del usuario antes de emitir cualquier sesión (el acceso con Google no usa ese código). Los códigos se guardan solo como hashes HMAC-SHA256, caducan y funcionan una sola vez.
  • Acceso del equipo: cuatro roles (owner, admin, agent, viewer) con permisos por sección. El acceso a facturación no se puede delegar a quien no sea owner.
  • Aislamiento: los endpoints de empresa confirman que quien llama es miembro activo de esa empresa y, si no, devuelven "not found".
  • Webhooks y archivos: los webhooks de Meta se rechazan si no traen una firma X-Hub-Signature-256 válida, los webhooks de Telegram exigen un token secreto y los adjuntos se sirven solo mediante URL firmadas que caducan.
  • Infraestructura: la aplicación no está expuesta directamente a internet; el tráfico público llega a través de un Cloudflare Tunnel. Los registros de errores de la base de datos nunca incluyen los parámetros de las consultas, así que los teléfonos y los correos no aparecen en esos registros.
  • Registro de auditoría de los administradores de plataforma: las acciones de los administradores de plataforma se escriben en un registro de auditoría de solo adición (append-only) (quién, qué, cuándo, IP, con instantáneas de antes y después y los secretos ocultos). No es un registro de los mensajes de los clientes.

Lo que el cifrado no puede hacer aquí: una bandeja de entrada con IA tiene que leer el texto de los mensajes para escribir una respuesta, así que el contenido de las conversaciones se procesa de forma legible en el servidor. Justo por eso los puntos anteriores sobre control de acceso, retención y copias de seguridad pesan tanto como el algoritmo que elijas.

Las solicitudes de eliminación de datos de Meta devuelven un código de confirmación con un enlace de estado en nuestra página de eliminación de datos. Eliminar la cuenta exige tu contraseña más un código de un solo uso enviado por correo, y la cuenta queda desactivada y su correo anonimizado.

Checklist de cifrado de datos en empresas: orden de implementación para equipos pequeños

El cifrado de datos para pymes funciona mejor en un orden fijo, empezando por lo que más daño hace cuando se filtra:

  1. Sirve todo por HTTPS, solo con TLS 1.2 o 1.3.
  2. Activa el cifrado de disco completo y el bloqueo de pantalla en cada dispositivo que abra chats de clientes.
  3. Pasa los tokens y las claves API a cifrado a nivel de campo con claves separadas.
  4. Hashea las contraseñas con Argon2id o bcrypt y agrega un segundo paso al iniciar sesión.
  5. Cifra los números de teléfono, los correos y las direcciones de los clientes.
  6. Cifra las copias de seguridad, define roles de mínimo privilegio y fija periodos de retención de los chats.
  7. Envía las preguntas para proveedores a cada herramienta de chat, CRM e IA que uses.

Preguntas frecuentes

¿Qué datos de una empresa se deben cifrar?

Empieza por todo lo que dé acceso o identifique a una persona: tokens de canal, claves API, secretos de webhook y los teléfonos, correos y direcciones de los clientes. Después cubre los historiales de chat, los dispositivos del equipo y cada copia de seguridad o exportación.

¿Cuál es la diferencia entre cifrado en reposo y en tránsito?

El cifrado en tránsito, normalmente TLS, protege los datos que se mueven entre dispositivos, servidores y APIs. El cifrado en reposo, normalmente AES, protege los datos almacenados.

¿El cifrado AES-256 es suficiente para proteger los datos de los clientes?

AES-256 es fuerte, pero el algoritmo rara vez es el punto débil. Los fallos habituales son guardar mal las claves, reutilizar nonces, dar acceso amplio al personal y dejar las copias de seguridad sin proteger.

¿Cómo guardar claves API y tokens de acceso de forma segura?

Cifra con AES-GCM a nivel de campo los tokens que tengas que reutilizar y guarda la clave fuera de la base de datos. Hashea los secretos que solo verificas, como las contraseñas y las claves API de socios.

Si uso HTTPS, ¿mis datos están protegidos en el servidor?

No. HTTPS protege los datos solo en tránsito. En el servidor, la seguridad depende del cifrado en reposo, del control de acceso y del manejo de las copias de seguridad.

¿Qué preguntar a un proveedor de chatbot o CRM sobre seguridad?

Pregunta qué versiones de TLS aceptan, qué se cifra en reposo y en qué capa, dónde se guardan las claves, si queda registrado el acceso de su personal a los chats, quiénes son sus subencargados y dónde se almacenan los datos, si los chats entrenan modelos de IA y si firmarán un DPA con un plazo de eliminación.

¿Listo para llevar tus chats en una bandeja de entrada con IA que cifra los tokens de canal y ciertos datos de contacto de tus clientes? Empieza gratis.

MR

Sobre el autor

Mohamed Rasul

Founder & CEO, Raabt AI

LinkedIn →