Cuando tu ATS se convierte en la brecha: cómo proteger los datos personales de los candidatos

La brecha de datos de una plataforma de selección de personal es hoy uno de los objetivos de mayor valor de tu stack, porque un sistema de seguimiento de candidatos (ATS) concentra la mayor densidad de datos personales regulados que maneja tu empresa: nombres legales, direcciones, expectativas salariales, currículums y, cada vez más, documentos de identidad oficiales, entrevistas en vídeo grabadas y datos biométricos derivados de IA. Cuando ese sistema sufre una brecha, los atacantes no se llevan una lista de marketing. Se llevan un kit listo para usar de robo de identidad y deepfakes. La solución no es “elegir un proveedor que prometa seguridad”. Es privacy-by-design: recopila menos, cifra lo que conservas, borra según un calendario y trata el ATS como un sistema que tu plan de respuesta a incidentes realmente cubre.

Si eres responsable del stack de contratación y tu CISO o tu consejo han empezado a preguntar “¿podría pasarnos lo de Mercor?”, esto es para ti. Aquí tienes qué ocurrió de verdad, por qué las plataformas de selección están de repente en el punto de mira, la exposición legal que conlleva y un checklist concreto de controles que puedes exigir a cualquier proveedor.

Qué le pasó a Mercor (y por qué debería asustar a todo equipo de contratación)

A finales de marzo de 2026, Mercor, la plataforma de selección para la industria de la IA, sufrió una brecha y se exfiltraron aproximadamente 4 TB de datos, incluidos números de la seguridad social de candidatos, escaneos de pasaportes y carnés de conducir, datos biométricos faciales y entrevistas en vídeo en HD. Mercor, que según se informa se usa para captar contratistas que entrenan modelos para los grandes laboratorios de IA, no fue atacada por su propia puerta principal. La atacaron a través de una dependencia.

El ataque entró montado en el compromiso de la cadena de suministro de LiteLLM. Un actor de amenazas identificado como TeamPCP comprometió las credenciales de publicación de LiteLLM en PyPI y subió dos versiones troyanizadas del paquete, la v1.82.7 y la v1.82.8. Según el propio aviso de seguridad de LiteLLM, los paquetes maliciosos estuvieron disponibles en PyPI durante unos 40 minutos el 24 de marzo de 2026 antes de ser puestos en cuarentena. Cuarenta minutos bastaron. El payload recolectó variables de entorno, claves SSH, credenciales de la nube, tokens de Kubernetes y contraseñas de bases de datos. El grupo de extorsión Lapsus$ listó después a Mercor en su sitio de filtraciones alrededor del 31 de marzo y puso los datos a subasta; Mercor reveló el impacto a principios de abril y se describió como “una de entre miles de empresas” afectadas.

Los datos que reclamó Lapsus$ se desglosan en aproximadamente 939 GB de código fuente, una base de datos de candidatos de 211 GB y unos 3 TB de archivos almacenados (Repello AI; SecurityWeek). La base de datos de candidatos contenía, según se informa, currículums, datos de contacto verificados y números de la seguridad social. Los archivos almacenados eran la parte verdaderamente alarmante: vídeo en HD de los candidatos, escaneos de documentos de identidad y los datos biométricos faciales usados para emparejar rostros con documentos.

La lección no es “LiteLLM era malo”. LiteLLM es muy usado; Wiz lo encontró presente en el 36 % de los entornos cloud analizados (Wiz). La lección es que el radio de impacto de los datos de tus candidatos incluye a los proveedores de tus proveedores, y que el montón más sensible que posees puede estar en un sistema en el que nadie de tu equipo de seguridad piensa.

Por qué las plataformas de selección son ahora objetivos prioritarios

Las plataformas de selección son objetivos de alto valor porque el embudo de contratación recopila más datos sensibles que casi cualquier otro sistema de back-office y, sin embargo, rara vez entra en el alcance del programa de seguridad de la empresa. Piensa en lo que fluye por un ATS en una sola contratación: nombre legal, domicilio, teléfono, email, historial laboral completo, expectativas salariales, currículum, referencias y, en muchos stacks modernos, una entrevista en vídeo grabada, un documento de identidad oficial para verificar el derecho a trabajar y transcripciones o puntuaciones generadas por IA. Es un perfil más rico que el que guardan la mayoría de los CRM, los sistemas de facturación o los wikis internos.

Dos cambios estructurales empeoraron esto en los últimos años.

Las herramientas de contratación con IA recopilan datos cuasibiométricos por defecto. Las entrevistas en vídeo, el análisis de voz y el emparejamiento de rostro con documento son ahora funciones habituales. Cada una convierte un paso de la contratación en un registro biométrico permanente.

Los servicios de pasarela y proxy de IA concentran credenciales. Herramientas como LiteLLM se sitúan delante de las API de los modelos y acumulan claves de API y credenciales de la nube. Cualquier plataforma que adopte una hereda su riesgo de cadena de suministro aguas arriba, que es exactamente la vía de entrada a Mercor.

Junta ambas cosas y obtienes un sistema que guarda los datos más valiosos, ampliado por funciones de IA, expuesto a través de dependencias y casi nunca incluido en el plan de respuesta a incidentes. Los atacantes se dieron cuenta antes que la mayoría de los equipos de contratación.

Los datos que no puedes rotar

La razón por la que una brecha en selección es peor que una fuga de datos personales típica es sencilla: los identificadores biométricos no se pueden restablecer. Como lo expresó un análisis de la brecha de Mercor, “no hay un botón de ‘rotar’ para tu cara” (IQ Source).

Una contraseña robada se reemite en segundos. Una tarjeta de crédito filtrada se cancela y se vuelve a imprimir. Pero el escaneo robado de un rostro junto con una grabación de voz es permanente, y es precisamente la materia prima necesaria para generar deepfakes convincentes. En el caso de Mercor, eso significa suplantar a contratistas que tienen acceso a laboratorios de IA, una cadena de consecuencias que sobrevive a cualquier email de restablecimiento de contraseña. Las entrevistas en vídeo grabadas y las transcripciones de voz por IA entran en la misma categoría. Son cuasibiométricas, son funcionalmente irreversibles una vez filtradas y la mayoría de las empresas las almacenan sin política alguna de retención o borrado.

Este es el argumento central a favor de la minimización de datos en la contratación. Los datos que nunca recopilaste no pueden filtrarse. Los datos que borraste según calendario no pueden aparecer en el próximo volcado. Cada entrevista en vídeo que conservas “por si acaso” es un pasivo permanente alojado en el bucket de S3 de otra persona.

El radio de impacto legal

Una brecha de datos de candidatos no es solo un incidente de seguridad; es un evento regulatorio y de litigios, y las facturas llegan rápido. Durante la primera semana de abril de 2026 se presentaron al menos cuatro demandas colectivas contra Mercor, la mayoría en el Tribunal de Distrito de EE. UU. para el Distrito Norte de California, y reportes posteriores elevaron la cuenta a cinco o seis (HR Dive; ComplianceHub). Una de las demandas propone una clase nacional de más de 40.000 personas, con reclamaciones que abarcan negligencia, incumplimiento de contrato implícito, invasión de la privacidad y la Ley de Competencia Desleal de California. Una demanda aparte en Texas señala a subproveedores aguas abajo, convirtiendo un problema de terceros en uno de cuartos.

Los regímenes regulatorios vigentes elevan aún más lo que está en juego:

Fuentes: National Law Review; evidenced.app.

El patrón en todos estos marcos es el mismo: los reguladores premian la minimización, la retención documentada, el consentimiento y la capacidad de borrar a petición. No son meras casillas de cumplimiento. Son los mismos controles que reducen una brecha.

Cómo proteger los datos de los candidatos en un ATS: el checklist

Para proteger los datos de los candidatos en un ATS, aplica privacy-by-design: recopila lo mínimo, cífralo a nivel de columna, fija valores de retención por defecto que borren los datos según calendario, registra los accesos, examina a los subproveedores de tu proveedor, atiende las solicitudes de borrado y mete el ATS dentro de tu plan de respuesta a incidentes. Aquí tienes la versión corta que puedes entregar a un proveedor o a tu propio equipo:

1. Minimiza la recopilación. No reúnas números de la seguridad social, documentos de identidad completos ni vídeo grabado a menos que una etapa concreta lo requiera de verdad. Los datos más baratos de proteger son los que nunca tomaste.
2. Cifra los datos personales a nivel de columna. Los campos sensibles deben cifrarse en reposo en la capa de aplicación, no con vagas promesas de “disco cifrado”.
3. Fija valores de retención por defecto. Cada registro de candidato, vídeo y transcripción necesita un reloj de borrado por defecto medido en meses, no en “para siempre”.
4. Registra los accesos. Quién vio qué currículum o CV, y cuándo, debe quedar como un registro auditable.
5. Examina a los proveedores y a sus proveedores. Pregunta qué dependencias y pasarelas de IA hay detrás de tu ATS. El radio de impacto de Mercor pasó por un paquete que la mayoría de su equipo nunca eligió directamente.
6. Atiende el borrado a petición. El GDPR y la CCPA dan a los candidatos el derecho al olvido; tu stack debe ejecutarlo de forma limpia en vídeos, transcripciones y datos derivados.
7. Mete el ATS en tu plan de respuesta a incidentes. Un sistema que guarda números de la seguridad social, pasaportes y vídeo biométrico es un activo de máximo valor y debe estar dentro del alcance, no en un punto ciego.

Tu ATS pertenece a tu plan de respuesta a incidentes

La carencia más común es estructural: los planes de respuesta a incidentes cubren la infraestructura de “producción” y excluyen sin hacer ruido el sistema de contratación, aunque el ATS suele guardar los datos más sensibles de la empresa. Un alcance moderno de CSIRT incluye de forma explícita los sistemas que guardan los datos más sensibles y las funciones legales y de RR. HH. necesarias para gestionar la notificación de brechas (FIRST CSIRT Services Framework). Un ATS que guarda números de la seguridad social, pasaportes y vídeo biométrico es exactamente esa clase de sistema.

Tratar el ATS como una superficie de seguridad significa tres cosas concretas. Primero, aparece en tu inventario de activos y en tus mapas de flujo de datos con su clasificación de datos etiquetada. Segundo, el riesgo de su proveedor y subproveedores se revisa con la misma cadencia que el resto de tu cadena de suministro. Tercero, cuando llega un incidente, las personas que pueden responder “qué datos de candidatos había ahí y a quién tenemos que notificar” ya están en la lista de respuesta, no improvisando. La mayoría de las empresas llevan contratación y seguridad como dos mundos desconectados. Las demandas a Mercor son lo que ocurre cuando la costura entre ambos es justo donde viven los datos.

Cómo aborda esto Kit

Kit es una plataforma combinada de contratación y seguridad, y los fallos de Mercor se corresponden con controles que ya implementa, por lo que esto es un argumento de postura más que de marketing. Nada de esto hace a ningún proveedor inmune a las brechas —los ataques a la cadena de suministro pueden alcanzar a cualquiera—, pero los valores por defecto correctos reducen tanto el radio de impacto como la exposición regulatoria cuando algo sale mal.

• Cifrado a nivel de columna de los datos personales de los candidatos. Kit cifra los campos más sensibles de los candidatos en reposo mediante Active Record Encryption. El email se cifra de forma determinista para que siga siendo consultable a efectos de deduplicación, mientras que los campos que no necesitan búsquedas se cifran de forma no determinista. La lección de “guarda los datos personales cifrados, no en texto plano”, hecha realidad.
• La retención como ajuste de primer nivel. El consentimiento del candidato lleva asociada una ventana de retención configurable con un valor por defecto sensato medido en meses, y el propio consentimiento puede renovarse, rechazarse y caducar en lugar de almacenarse indefinidamente. Los datos que borras según calendario no pueden aparecer en el próximo volcado.
• Manejo disciplinado del vídeo y las transcripciones. Las entrevistas grabadas y las transcripciones por IA se tratan como los activos cuasibiométricos y sujetos a retención que son, con el acceso a los CV de los candidatos registrado para tener un rastro de auditoría.
• Aislamiento multiinquilino y borrado defendible. Los datos de los candidatos se delimitan por cuenta, y el borrado lógico junto con el registro de accesos respaldan el “derecho de supresión” que exigen el GDPR y la CCPA.
• Un módulo CSIRT integrado. Como Kit incluye un módulo completo de divulgación de vulnerabilidades y respuesta a incidentes junto a la contratación, la misma disciplina de respuesta aplicada a producción puede cubrir el ATS. Los dos mundos que Mercor mantenía separados son aquí una sola superficie.

Hablamos de cómo montar la parte de respuesta de todo esto en cómo configurar un programa de divulgación de vulnerabilidades, y de la presión de cumplimiento que ahora recae sobre los equipos pequeños en el plazo de divulgación del Reglamento de Ciberresiliencia de la UE. Este artículo es la capa de datos de candidatos que sostiene a ambos.

Preguntas frecuentes

¿Es mi sistema de seguimiento de candidatos un riesgo de brecha de datos?

Sí; por defecto es uno de tus sistemas de mayor riesgo, porque concentra datos personales regulados (nombres, direcciones, números de la seguridad social, documentos de identidad, datos salariales) y, cada vez más, datos biométricos de las entrevistas en vídeo, mientras que rara vez se incluye en los programas de seguridad. El riesgo es reducible: minimiza lo que recopilas, cífralo, fija límites de retención y mete el ATS dentro del alcance de tu respuesta a incidentes. La brecha de Mercor demostró que los datos están ahí los protejas o no.

¿Qué datos de candidatos son los más peligrosos en una brecha?

Los datos biométricos y de identidad: escaneos faciales, grabaciones de voz, entrevistas en vídeo e imágenes de documentos de identidad oficiales. A diferencia de una contraseña o una tarjeta de crédito, estos no se pueden rotar ni reemitir, y son la materia prima de los deepfakes y el robo de identidad. Los números de la seguridad social también son extremadamente peligrosos. La postura más segura es evitar recopilarlos por completo a menos que una etapa concreta lo requiera, y borrarlos según un calendario fijo cuando sí lo haga.

¿Cuánto tiempo debe conservar un ATS los datos de los candidatos?

El suficiente para cumplir la finalidad de la contratación y las obligaciones legales, y después bórralos. Bajo el GDPR necesitas un periodo de retención definido y documentado en lugar de almacenamiento indefinido, y muchos equipos fijan por defecto unos dos años para los candidatos no seleccionados, con un reloj de borrado claro. Las entrevistas en vídeo y las transcripciones merecen la ventana más estricta, ya que son los datos más difíciles de justificar conservar. La retención debe ser un valor por defecto configurado, no una limpieza manual que nadie ejecuta.

En resumen

La brecha de Mercor es el caso de manual del ATS que se convierte en la brecha: 4 TB hacia la puerta a través de una dependencia, incluida la única categoría de datos —tu cara y tu voz— que nadie podrá restablecer jamás. La respuesta defendible no es comprar un proveedor que prometa seguridad. Es privacy-by-design como una postura que puedes verificar: recopila menos, cifra a nivel de columna, fija valores de retención que borren según calendario, registra los accesos, examina a los proveedores de tus proveedores y mete el sistema de contratación dentro del plan de respuesta a incidentes, donde siempre debió estar.

Si estás auditando tu stack de contratación y quieres minimización, cifrado, retención y disciplina de respuesta a incidentes integrados desde el principio, empieza una prueba gratuita de Kit y configura hoy un proceso de contratación con privacy-by-design.