Imagen impactante de una enorme puerta de cámara acorazada abierta de par en par con «123456» en su cerradura, dejando ver dentro filas de siluetas humanas: una seguridad catastróficamente débil que custodia datos profundamente personales a gran escala.
Artificial IntelligenceCybersecurityTechnology

64 millones de personas buscaban trabajo. Una contraseña «123456» reveló todos sus secretos

Ashutosh SinghalAshutosh Singhal19 de marzo de 202615 min

Estaba en una llamada con un cliente potencial —una empresa de logística de tamaño medio— cuando estalló la noticia de McHire. Mi cofundador me envió un enlace a mitad de frase. Le eché un vistazo, leí las dos primeras líneas y me quedé completamente en silencio. El cliente preguntó si seguía ahí.

«Perdón», dije. «Acabo de leer que la plataforma de contratación con IA de McDonald's —la que criba a millones de candidatos— estaba protegida por la contraseña “123456”. Y alguien acaba de colarse sin más.»

Hubo una larga pausa. Entonces el cliente dijo: «Básicamente, así es como lo tenemos montado nosotros.»

Lo decía medio en broma. Pero solo medio.

La brecha de McHire de junio de 2025 expuso los datos personales de aproximadamente 64 millones de personas en busca de empleo —nombres, correos electrónicos, números de teléfono, direcciones IP, transcripciones de chats con una reclutadora de IA llamada “Olivia” y, lo más inquietante, los resultados de sus pruebas de personalidad. El vector no fue un sofisticado ataque de un Estado-nación. No fue un exploit de día cero que requiriera un equipo de hackers de élite. Fue una contraseña de administrador por defecto que llevaba sin cambiar desde 2019, en una cuenta sin autenticación multifactor, protegiendo una API que permitía a cualquiera recorrer los ID de los candidatos desde la barra de direcciones del navegador.

Cuando le cuento a la gente lo que hacemos en Veriprajna —construir sistemas de IA con la seguridad y la gobernanza integradas en la arquitectura— a veces recibo el gesto cortés de asentimiento que significa «claro, pero ¿no es eso excesivo?». La brecha de McHire es mi respuesta. No es excesivo. Es lo mínimo indispensable. Y la mayoría de las empresas ni siquiera hacen eso.

¿Qué ocurrió realmente dentro de la plataforma McHire?

Un diagrama paso a paso que muestra la cadena de ataque exacta —desde las credenciales por defecto hasta la explotación de IDOR y el acceso masivo a datos— que deja inmediatamente clara la secuencia técnica.

La brecha no la descubrió un equipo de inteligencia de amenazas ni una agencia gubernamental. Empezó con dos investigadores de seguridad —Ian Carroll y Sam Curry— que notaron algo de lo más mundano: los usuarios se quejaban de que el chatbot “Olivia” fallaba. La experiencia del front-end era tosca y poco fiable.

Ese detalle importa. Según mi experiencia, un front-end defectuoso es casi siempre una señal. Si una empresa no ha invertido en la parte que los usuarios ven, imagina lo que ocurre en las partes que no ven.

Carroll y Curry empezaron a hurgar y encontraron un portal de gestión destinado a los empleados de Paradox.ai —el proveedor que construyó y operaba McHire por cuenta de McDonald's—. Probaron con una cuenta de prueba. ¿El nombre de usuario? “123456”. ¿La contraseña? “123456”. Funcionó.

Recuerdo leer aquello y sentir un tipo específico de ira que reconocerá cualquiera que haya construido alguna vez sistemas en producción. No es sorpresa: es la furia de saber que esto era completamente evitable. No fue una sutil mala configuración en un clúster de Kubernetes. Fue el equivalente digital a dejar la puerta de la cámara acorazada abierta con una nota adhesiva que dice “la llave está bajo el felpudo”.

Pero la contraseña era solo la primera etapa. Una vez dentro, los investigadores descubrieron una vulnerabilidad de Referencia Directa Insegura a Objetos —un IDOR, en la jerga de seguridad—. Esto significaba que la API no verificaba si un usuario con sesión iniciada estaba realmente autorizado para ver los datos de un candidato concreto. Cambiando el número de ID del candidato en la URL —literalmente, solo incrementando un número— podían sacar los registros completos de cualquier candidato del sistema.

Sesenta y cuatro millones de ellos.

Por qué los datos de las pruebas de personalidad son el peor tipo de datos que se pueden filtrar

Aquí es donde la mayor parte de la cobertura de esta brecha se equivoca. Los titulares se centraron en la contraseña —“123456”, ja ja, qué estupidez— y siguieron adelante. Pero la verdadera catástrofe no es la credencial. Es lo que había detrás de ella.

Los números de tarjeta de crédito se pueden cancelar. Las contraseñas se pueden cambiar. ¿Pero los resultados de una evaluación de personalidad? ¿Las puntuaciones de una criba conductual? ¿Las transcripciones de una conversación en la que una IA sondeó tu temperamento, tus respuestas emocionales, tu estilo ante el conflicto?

Esos datos son . No caducan.

Cuando se filtra un perfil de personalidad, no puedes rotarlo como una contraseña. Tu huella psicométrica te acompaña para siempre.

Pasé una noche en vela después de la brecha leyendo investigaciones sobre el impacto psicológico de la exposición de datos. Las cifras son asombrosas: casi el 70 % de las víctimas de brechas reportan una incapacidad persistente para confiar en los demás. Dos tercios experimentan una profunda impotencia. Diversos estudios han vinculado la exposición de datos personales con la ansiedad, la depresión y el TEPT. Y la gravedad escala con la intimidad de los datos: una dirección de correo filtrada escuece; una evaluación de personalidad filtrada que dice que eres “emocionalmente inestable” o de “baja escrupulosidad” puede sentirse como una disección pública.

Para las personas en busca de empleo —muchas de ellas jóvenes, muchas solicitando su primer trabajo en una cadena de comida rápida— esto es especialmente cruel. Se sometieron a una prueba de personalidad porque una IA se lo dijo. No tenían ninguna forma significativa de entender qué datos se recopilaban, cómo se almacenaban ni quién podía acceder a ellos. Y ahora esos datos están ahí fuera, potencialmente para siempre, en un mundo donde futuros empleadores, aseguradoras o actores malintencionados podrían usar rasgos inferidos en su contra.

Mi equipo tuvo una discusión sobre esto. Uno de nuestros ingenieros dijo: «Mira, los datos quedaron expuestos, pero probablemente no se exfiltraron a gran escala: los investigadores lo reportaron de forma responsable.» Y, técnicamente, es cierto. Paradox parcheó la vulnerabilidad a las pocas horas de la notificación. Pero yo lo rebatí con fuerza. La cuestión no es si este conjunto de datos concreto terminó en un foro de la dark web. La cuestión es que la arquitectura lo permitió. El sistema estaba diseñado de tal manera que una contraseña por defecto y un navegador bastaban para acceder a los perfiles psicométricos de 64 millones de personas. Eso no es un por poco. Es un fallo de filosofía de diseño.

El desarrollador en Vietnam y la contraseña que lo desbloqueó todo

Hay una trama secundaria en esta historia que no recibió suficiente atención. Las investigaciones revelaron que un desarrollador de Paradox.ai radicado en Vietnam había sido comprometido por una cepa de malware llamada Nexus Stealer —una herramienta de robo de credenciales que se vende en foros de ciberdelincuencia—. La infección exfiltró cientos de contraseñas del dispositivo del desarrollador. Muchas de ellas eran deficientes y reutilizadas, usando la misma contraseña base de siete dígitos en múltiples servicios.

Ese único desarrollador comprometido expuso credenciales asociadas a cuentas de Paradox.ai de clientes que incluían a Pepsi, Lockheed Martin, Lowe's y Aramark.

Quiero que se detengan a pensar en eso un momento. Una persona. Un portátil infectado. Una contraseña reutilizada. Y de repente los datos de contratación de algunos de los mayores empleadores de Estados Unidos están en riesgo.

Esto es lo que yo llamo el problema del “nodo humano”, y es lo que me quita el sueño mucho más que cualquier vector de ataque de IA exótico. Puedes construir el modelo más sofisticado del mundo, ajustarlo con datos impecables, envolverlo en guardrails —y entonces la higiene de contraseñas de un solo desarrollador derrumba todo el castillo de naipes. El coste medio de una filtración de datos en 2025 alcanzó los 4,44 millones de dólares. Pero las organizaciones siguen tratando la gestión de identidades como una idea de última hora, algo que el equipo de TI resuelve con un vídeo de formación anual que nadie mira.

La seguridad de tu sistema de IA nunca es más fuerte que la credencial humana más débil de la cadena.

En Veriprajna, hemos construido nuestra arquitectura en torno al supuesto de que el acceso humano es un vector de alto riesgo que requiere verificación continua —lo que la industria llama Confianza Cero (Zero Trust)—. No porque no confiemos en nuestro equipo, sino porque he visto lo que ocurre cuando confías en cualquier punto único de autenticación para mantener la línea.

¿Qué significa realmente la “IA profunda” y por qué debería importarte?

Necesito introducir una distinción que considero la idea más importante en la IA empresarial ahora mismo, y una que la brecha de McHire ilustra a la perfección: la diferencia entre un envoltorio de IA (AI Wrapper) y lo que llamamos IA profunda (Deep AI).

Un envoltorio de IA es lo que la mayoría de las empresas construyen en realidad cuando dicen que están “haciendo IA”. Es una fina capa de aplicación —a menudo un chatbot o un formulario— que envía las entradas del usuario a un modelo fundacional como GPT-4 o Claude a través de una API, obtiene una respuesta y la muestra. La IA es un servicio que alquilas. Tu aplicación es el escaparate. La seguridad, la gestión de datos, la gobernanza: todo eso se añade después, usando las mismas prácticas de desarrollo web que emplearías para cualquier aplicación CRUD.

La “Olivia” de Paradox.ai era, arquitectónicamente, un envoltorio. Uno sofisticado, sí. Pero la postura de seguridad estaba anclada a la infraestructura web tradicional —y esa infraestructura falló al nivel más básico imaginable.

La IA profunda es fundamentalmente diferente. Trata el modelo de IA como una primitiva arquitectónica —como una base de datos o una cola de mensajes— con sus propios límites de seguridad, sus propios controles de acceso, sus propios registros de auditoría. El modelo no es una caja negra que invocas; es un componente que gobiernas. Construyes enrutadores de prompts, capas de memoria, evaluadores de retroalimentación. Implementas defensas por capas que asumen que toda entrada es hostil y toda salida es no confiable.

Escribí sobre esta filosofía arquitectónica en profundidad en la versión interactiva de nuestra investigación, pero la idea central es simple: si tu estrategia de seguridad de IA es “ya añadiremos autenticación y un WAF”, estás construyendo un envoltorio, y estás a una contraseña por defecto de la catástrofe.

La defensa de 5 capas que nadie quiere construir

Un diagrama de arquitectura de defensa en anillos concéntricos que muestra las cinco capas de seguridad de la más externa a la más interna, con etiquetas claras para la función de cada anillo.

Tras la noticia de McHire, reuní a mi equipo de ingeniería en una sala y dije: «Explicadme exactamente cómo nuestra pila habría evitado esto.» No porque dudara de ellos, sino porque quería someter a prueba de estrés cada supuesto.

Le dedicamos tres horas. En cierto momento, nuestro ingeniero de seguridad principal dibujó en la pizarra un diagrama que parecía la sección transversal de un castillo medieval: anillos concéntricos de defensa, cada uno operando de forma independiente. Si uno cae, el siguiente aguanta. Así es como se ve en la práctica:

El anillo más externo es la sanitización de entradas: a cada prompt, a cada llamada de API, se le despoja de cualquier cosa que pudiera malinterpretarse como un comando de inyección. El segundo anillo es la detección heurística de amenazas, que escanea activamente en busca de patrones adversarios conocidos. El tercero es el envoltorio de metaprompts, donde la petición del usuario queda encerrada en un sobre seguro de instrucciones que el modelo no puede anular.

El cuarto anillo es donde la cosa se pone interesante: modelos canario y adjudicador. Un modelo más pequeño analiza primero la petición. Si marca algo sospechoso, un segundo modelo toma la decisión final. Es un sistema de compañeros para la IA: ningún modelo por sí solo puede actuar unilateralmente.

El quinto anillo, el más interno, es la validación de salidas. Cada respuesta que genera la IA se trata como no confiable hasta que se demuestre lo contrario. Las capas de redacción de PII escanean en busca de datos sensibles. Los clasificadores de toxicidad comprueban si hay contenido dañino. Nada pasa sin ser inspeccionado.

Esto es lo que me frustró durante aquella sesión de pizarra: nada de esto es exótico. Nada de ello requiere un avance científico. Es disciplina de ingeniería aplicada a un nuevo dominio. La razón por la que la mayoría de las empresas no lo hacen es porque es caro, es lento y no queda bien en una demo. Un chatbot envoltorio se puede construir en un fin de semana y enseñárselo a un consejo el lunes. Un sistema de IA debidamente gobernado tarda meses. Adivina cuál consigue financiación.

La industria de la IA tiene un problema de demos: aquello que impresiona a los inversores en un pitch es arquitectónicamente opuesto a lo que protege a los usuarios en producción.

¿Por qué la ley trata los datos de personalidad como si fueran radiactivos?

Una pregunta que me hace cada CTO con quien hablo: «¿Cómo de grave es la exposición legal aquí, en realidad?»

La respuesta: potencialmente existencial.

Bajo la CCPA, una empresa puede ser demandada si se roba información personal no cifrada debido a un fallo en el mantenimiento de “procedimientos de seguridad razonables”. Los daños estatutarios son de 750 dólares por consumidor y por incidente. Multiplica eso por 64 millones de registros y estás ante una responsabilidad teórica de 48.000 millones de dólares. Ningún tribunal concedería esa cantidad íntegra, pero incluso una fracción sería el fin de la empresa.

Bajo el RGPD, las sanciones se limitan a 20 millones de euros o el 4 % de la facturación anual global —lo que sea mayor—. Y la Ley de IA de la UE, que clasifica la IA de contratación como “de alto riesgo”, introduce multas de hasta 35 millones de euros o el 7 % de la facturación global por incumplimiento de las evaluaciones de riesgo obligatorias y de los requisitos de supervisión humana.

Pero esto es lo que la mayoría de los análisis jurídicos pasan por alto: el daño reputacional es peor que las multas. Hablé con una directora de RR. HH. (CHRO) de una empresa del Fortune 500 unas semanas después de la brecha. Me contó que su equipo había estado evaluando herramientas de contratación con IA y había preseleccionado a tres proveedores. Tras la historia de McHire, el CEO canceló toda la iniciativa. «Lo haremos manualmente un año más», dijo. «No pienso ser el próximo titular.»

Ese es el coste real. No solo para Paradox.ai, sino para toda empresa legítima de IA que intenta construir confianza con los compradores empresariales. Una brecha catastrófica envenena el pozo para todos.

¿Cómo se gobierna realmente una IA que toma decisiones sobre las personas?

Aquí es donde tengo que ser honesto acerca de algo incómodo: los marcos de gobernanza suenan aburridos. ISO 42001, NIST AI RMF, OWASP Top 10 para LLM: estas no son las cosas que entusiasman a los fundadores en las cenas. Pero son las cosas que separan a las empresas que sobreviven al escrutinio regulatorio de las que no.

ISO 42001 es la primera norma internacional del mundo para sistemas de gestión de IA. Exige que las organizaciones identifiquen riesgos específicos de la IA, establezcan objetivos claros de transparencia y seguridad, realicen evaluaciones de impacto para cada sistema de IA y mantengan un seguimiento continuo mediante auditorías internas. No es un ejercicio de marcar casillas: es un sistema de gestión que te obliga a pensar en la gobernanza de la IA de la misma manera que piensas en los controles financieros.

El Marco de Gestión de Riesgos de IA del NIST proporciona el ancla de políticas, organizado en torno a cuatro funciones: GOBERNAR, MAPEAR, MEDIR, GESTIONAR. En la brecha de Paradox, la función GOBERNAR falló de la manera más flagrante: no había ninguna responsabilidad organizativa para dar de baja la obsoleta cuenta de administrador que llevaba ahí desde 2019.

Y el marco OWASP —en particular su actualización de 2025 para la IA agéntica— ofrece a los desarrolladores una taxonomía clasificada de las vulnerabilidades más críticas. El secuestro del objetivo del agente (Agent Goal Hijack), donde contenido malicioso altera el comportamiento central de un agente. El uso indebido de herramientas (Tool Misuse), donde se engaña a un agente para que use una capacidad legítima con un propósito dañino. El envenenamiento de la memoria (Memory Poisoning), donde se inyectan datos maliciosos en la memoria a largo plazo de un agente persistente.

Para el desglose técnico completo de cómo se cruzan estos marcos, incluidos los detalles de implementación y una hoja de ruta de 90 días para directivos, he publicado un documento complementario detallado. Pero el resumen ejecutivo es este: para 2026, la gobernanza de la IA no será opcional. Será un requisito previo para hacer negocios con cualquier empresa que tenga un equipo jurídico.

«¿No podemos añadir la seguridad después?»

La gente me pregunta esto constantemente. La respuesta siempre es la misma, y siempre es incómoda: no. No puedes.

La seguridad que se añade después de los hechos es teatro de seguridad. Es una cerradura en una puerta a la que ya le han quitado los goznes. La brecha de McHire lo demuestra: Paradox.ai tenía autenticación. Tenía un portal de administración. Presumiblemente tenía algún proceso de revisión de seguridad. Pero como la seguridad no estaba integrada en la arquitectura desde el primer día, todo el sistema era solo tan fuerte como una contraseña que un niño pequeño podría adivinar.

Otra objeción que escucho: «Pero usamos un gran proveedor de nube. ¿No es su seguridad suficientemente buena?». El desarrollador de Paradox en Vietnam fue comprometido por malware de mercado —no por un exploit de la infraestructura en la nube—. Tu proveedor de nube puede tener una seguridad perfecta y tu sistema aun así puede sufrir una brecha porque un desarrollador reutilizó una contraseña en varios servicios. El perímetro no está donde tú crees que está.

Y luego está la que me pone genuinamente furioso: «Nuestro proveedor de IA se encarga de la seguridad». Esto es exactamente lo que pensó McDonald's. Externalizaron su contratación con IA a Paradox.ai y, al hacerlo, externalizaron su postura de seguridad a un proveedor cuyo portal de administración estaba protegido por “123456”. La cadena de suministro es ahora el perímetro de seguridad. Si no gobiernas la infraestructura de IA de tus proveedores con el mismo rigor que aplicas a la tuya propia, no estás delegando el riesgo: lo estás ignorando.

El pensamiento que no puedo quitarme de la cabeza

Esto es a lo que sigo volviendo, semanas después de que la historia de McHire estallara por primera vez.

Sesenta y cuatro millones de personas —muchas de ellas adolescentes, muchas solicitando su primer trabajo— se sentaron frente a una pantalla y respondieron a las preguntas de un chatbot de IA. Compartieron información sobre sí mismas porque el sistema se lo dijo. No tenían ninguna influencia, ningún poder de negociación, ninguna capacidad de decir «la verdad, preferiría no hacer una prueba de personalidad para freír hamburguesas». La asimetría de poder era total.

Y el sistema que custodiaba sus datos —sus nombres, sus perfiles conductuales, la evaluación que la IA hacía de su personalidad— estaba protegido por la misma contraseña que usa mi hija para su cuenta de Roblox.

Construimos sistemas de IA capaces de evaluar la personalidad humana a escala. Simplemente olvidamos proteger a los humanos.

Esto no es un problema de tecnología. Es un problema de valores. Es lo que ocurre cuando la industria trata la IA como un producto que enviar en lugar de como un sistema que gobernar. Cuando el “muévete rápido y rompe cosas” se topa con “estamos tomando decisiones automatizadas sobre el sustento de las personas”.

La era del envoltorio ha terminado. Las empresas que sobrevivan a la próxima ola de regulación, a la próxima brecha, al próximo ajuste de cuentas público —serán las que integraron la seguridad en los cimientos, no las que la añadieron después del titular. En Veriprajna, ese es el único tipo de IA que estamos dispuestos a construir. No porque sea más fácil. Porque la alternativa es indefendible.

La contraseña “123456” debería ser una reliquia. La arquitectura que permitió que importara debería estar extinta. Y los 64 millones de personas cuyos datos quedaron expuestos merecen algo mejor que la definición actual de “suficientemente bueno” de la industria.

Investigación relacionada

También publicado en

Construya su IA con confianza.

Colabore con un equipo que cuenta con amplia experiencia en la creación de la próxima generación de IA empresarial. Permítanos ayudarle a diseñar, construir e implementar una estrategia de IA en la que pueda confiar.

Veriprajna consultora de Deep Tech está especializada en la creación de sistemas de IA críticos para la seguridad en los sectores de salud, finanzas y ámbitos regulatorios. Nuestras arquitecturas se validan conforme a protocolos establecidos, con documentación de cumplimiento integral.