---
title: "McHire: los datos de 64 millones de aspirantes detrás de la contraseña 123456"
description: "El chatbot de contratación McHire de McDonald's expuso los datos de 64 millones de aspirantes tras la contraseña 123456. El fallo fue de proceso, no del modelo."
slug: "atencion-mcdonald-s-paradox-ai"
url: "https://catalizadora.ai/blog/atencion-mcdonald-s-paradox-ai"
cluster: "casos-ia"
author: "Pablo Estrada"
published_at: "2026-08-26T22:39:37.45+00:00"
updated_at: "2026-08-26T22:39:38.24929+00:00"
read_minutes: "7"
lang: "es"
---
# McHire: los datos de 64 millones de aspirantes detrás de la contraseña 123456

> El chatbot de contratación McHire de McDonald's expuso los datos de 64 millones de aspirantes tras la contraseña 123456. El fallo fue de proceso, no del modelo.

## Qué pasó

McHire es la plataforma con la que McDonald's recibe postulaciones de empleo. Quien quiere trabajar en un restaurante no llena un formulario y espera: conversa con un chatbot de contratación construido por Paradox.ai, que recoge sus datos y lo mueve por las etapas del proceso. Es automatización de manual, del tipo que sí tiene sentido: atiende a cualquier hora, reduce fricción y escala a un volumen que ningún equipo de recursos humanos podría cubrir a mano.

El 11 de julio de 2025, TechCrunch [publicó](https://techcrunch.com/2025/07/11/ai-chatbots-simple-123456-password-risked-exposing-personal-data-of-millions-of-mcdonalds-job-applicants/) que el acceso a ese sistema estaba protegido con la contraseña "123456". Detrás de esa puerta quedaban expuestos los datos personales de 64 millones de aspirantes a un empleo.

La cifra no describe un ataque sofisticado. Describe una puerta sin llave en un edificio lleno de gente.

## Por qué pasó

El chatbot hizo exactamente lo que se le pidió: conversar, capturar datos, ordenarlos. El modelo no falló. Falló lo que rodea al modelo.

Cuando una empresa contrata a un proveedor para automatizar un proceso, delega la ejecución, no la responsabilidad. Ahí se abre el primer hueco: entre "el proveedor construye el sistema" y "la empresa responde por los datos de las personas" tiene que existir alguien con nombre y apellido que revise ese sistema antes de que reciba a la primera persona. Cuando esa revisión no está escrita en el plan de trabajo, no ocurre. No la salta nadie por descuido; simplemente no le tocaba a nadie.

El segundo hueco es de escala. Un proceso manual de contratación falla de a uno: se traspapela un expediente, se pierde un currículum. Un proceso automatizado falla de a millones, porque concentra en un solo lugar lo que antes vivía disperso en carpetas y correos. Esa contraseña habría sido igual de débil con 500 registros. Lo que cambió no fue la contraseña: fue el tamaño de lo que protegía, y nadie volvió a medir el riesgo cuando el volumen creció.

El tercero es de calendario. La revisión de seguridad casi siempre queda al final, cuando el sistema ya está en producción y detenerlo cuesta dinero. En ese momento deja de ser un requisito y se convierte en una recomendación. Y las recomendaciones no bloquean lanzamientos.

## Dónde te puede pasar a ti

No hace falta operar a escala de McDonald's para reproducir este patrón. Es el mismo cada vez que conectas una herramienta de terceros a datos de personas reales:

- Un bot de WhatsApp que captura leads y los deposita en una base a la que también entra el proveedor que lo instaló.
- Un panel de administración que quedó con la credencial que trajo de fábrica porque "solo lo usamos internamente".
- Un formulario del sitio que escribe directo a una tabla sin reglas de acceso, porque en la demo funcionaba así.
- Un tablero de reportes compartido por enlace, sin caducidad, con el histórico completo de clientes adentro.

La pregunta útil no es si tu proveedor es serio. Es quién revisó, con fecha y nombre, que el sistema estuviera cerrado antes de abrirlo al público.

## Cómo se evita

Una auditoría básica antes de conectar el sistema habría bastado. Eso significa cuatro cosas concretas y baratas:

1. **Un dueño con nombre.** Cada integración de un tercero tiene una persona responsable de su seguridad, no un área. Si nadie firma, nadie revisa.
2. **Ninguna credencial de fábrica sobrevive al primer día.** Toda contraseña se genera, se guarda en un gestor de secretos y nunca circula por chat, correo ni documento compartido.
3. **La revisión es un bloqueo, no una recomendación.** Si el sistema no pasa el chequeo de acceso, no sale a producción. Un requisito que se puede posponer no es un requisito.
4. **El riesgo se vuelve a medir cuando cambia el volumen.** Lo que era aceptable con mil registros deja de serlo con un millón, y ese recálculo tiene que estar en el calendario.

Nada de esto frena la automatización. La sostiene: un sistema que expone a sus usuarios no llega a demostrar que servía.

## Cómo lo hacemos en Catalizadora

En los sistemas que construimos, ningún secreto pasa por el chat ni queda en el código: entra por un vault que lo propaga a los entornos que lo necesitan. Las bases de datos llevan un candado automatizado que verifica, en cada despliegue, que un visitante anónimo no puede leer los datos de personas. Si esa prueba falla, el despliegue no sale. No depende de que alguien se acuerde de revisarlo.
## Preguntas frecuentes

### ¿Qué es McHire y qué datos concentraba?

Es la plataforma con la que McDonald's recibe postulaciones de empleo, operada por un chatbot de contratación construido por Paradox.ai. Concentraba los datos personales de quienes solicitaban trabajo: según TechCrunch, los de 64 millones de aspirantes quedaron expuestos.

### ¿El fallo fue del chatbot o del modelo de inteligencia artificial?

De ninguno de los dos. El chatbot capturó y ordenó datos, que es su función. Lo que falló fue el control de acceso al sistema que los almacenaba: una contraseña de seis dígitos consecutivos y ninguna revisión de seguridad antes de conectarlo al público.

### Si contrato a un proveedor para automatizar, ¿la responsabilidad sobre los datos pasa a ser suya?

Se delega la ejecución, no la responsabilidad. Ante la persona que postuló y ante el regulador responde la empresa que recibió la postulación, sin importar quién construyó la herramienta.

### ¿Cuál es la revisión mínima antes de conectar una herramienta de terceros?

Cuatro cosas: un responsable con nombre y apellido para esa integración, ninguna credencial de fábrica activa, los secretos en un gestor y no en documentos compartidos, y un chequeo de acceso que bloquee el lanzamiento si no pasa.


---

Source: https://catalizadora.ai/blog/atencion-mcdonald-s-paradox-ai
Author: Pablo Estrada — AI Catalysts, LLC (catalizadora.ai)
