La IA interna de McKinsey fue vulnerada: qué revela sobre la seguridad de los agentes empresariales

La noticia de McKinsey no debería leerse como un espectáculo de “IA hackeando IA”. Ese titular llama la atención, pero distrae de lo importante: muchas plataformas internas de IA siguen montadas como aplicaciones empresariales comunes, con acceso privilegiado a información sensible y con controles de seguridad que no siempre están a la altura.

Eso vuelve relevante el caso de Lilli, la herramienta interna de McKinsey. No tanto por el morbo del incidente, sino porque deja una lección incómoda para cualquier empresa que hoy esté construyendo copilotos internos, buscadores con RAG o asistentes conectados a documentos, APIs y bases de datos.

Lo esencial

• Un investigador de seguridad de CodeWall aseguró haber encontrado una cadena de fallos en Lilli, la plataforma interna de IA de McKinsey.
• El reporte describe endpoints sin autenticación, una inyección SQL y acceso amplio a datos y configuraciones del sistema.
• McKinsey confirmó que existía una vulnerabilidad, dijo que la corrigió en horas y afirmó no haber encontrado evidencia de acceso a datos confidenciales de clientes.
• La lección práctica no es “qué tan lista era la IA atacante”, sino qué tan expuesta estaba la plataforma alrededor del modelo.

---

Qué pasó con Lilli, la IA interna de McKinsey

De acuerdo con la divulgación técnica publicada en marzo y retomada después por otros análisis, un agente ofensivo de CodeWall identificó documentación pública de la API de Lilli, detectó endpoints sin autenticación y encadenó una falla de inyección SQL para acceder a una parte muy sensible del sistema.

El punto delicado aquí no es solo el volumen de información que supuestamente pudo quedar expuesto, sino el tipo de acceso descrito: chats internos, archivos, cuentas de usuario, componentes del stack y hasta prompts del sistema. Si ese alcance fue exactamente el que CodeWall presentó o si algunas partes del relato están narradas con el sesgo natural de una startup de seguridad, es una discusión válida. Pero hay un dato que sí importa: McKinsey reconoció la vulnerabilidad y publicó una declaración oficial.

Eso basta para entender que el incidente no fue humo ni un truco de marketing vacío. También basta para desmontar una falsa comodidad empresarial: asumir que un copiloto interno es “menos riesgoso” solo porque no está orientado al público general.

La lectura útil: el problema no era el modelo, sino la plataforma

Cuando una empresa dice que “ya tiene IA interna”, en realidad suele hablar de un conjunto de piezas conectadas: autenticación, APIs, bases de datos, almacenamiento de archivos, permisos, servicios de embeddings, prompts, logs y alguna capa de interfaz que hace que todo se vea ordenado. El modelo es apenas una parte.

El caso de Lilli recuerda algo básico pero fácil de olvidar en medio del hype: la IA empresarial hereda todos los problemas clásicos de AppSec y les agrega algunos nuevos. Si expones documentación sensible, dejas endpoints sin proteger o conectas demasiado contexto a una sola capa, no necesitas un ataque futurista. A veces basta una vulnerabilidad vieja con un envoltorio moderno.

La noticia no demuestra que “la IA se salió de control”. Demuestra algo más terrenal y más peligroso: que muchas empresas están desplegando agentes con permisos de primera clase sobre sistemas que todavía no tratan como infraestructura crítica.

Por eso esta historia encaja mejor en el debate de IA empresarial y en la necesidad de diseñar entornos con controles reales, no en el circo habitual de titulares futuristas.

Por qué este caso importa más allá de McKinsey

Lo más interesante del caso no es la marca McKinsey. Es el patrón. Hoy muchas organizaciones están armando asistentes internos sobre SharePoint, Google Drive, Confluence, CRMs, repositorios documentales, transcripciones de soporte o bases de conocimiento propias. Eso acelera trabajo real, sí, pero también amplía la superficie de ataque.

Además, la velocidad cambia. Un atacante humano ya no es la única referencia útil. Un agente ofensivo puede mapear, probar, encadenar y volver a intentar con mucha más persistencia que un flujo manual. Eso no convierte cada incidente en ciencia ficción, pero sí acorta el tiempo entre “teníamos una mala configuración” y “ya alguien la encontró”.

En ese sentido, la conversación conecta directamente con lo que ya hemos visto sobre arquitecturas IA multi-entorno: si vas a repartir cargas entre herramientas, nubes, repositorios y capas de inferencia, también tienes que repartir controles, segmentación y observabilidad. De lo contrario, la comodidad operativa se convierte en radio de daño.

Qué deberían revisar hoy las empresas que usan agentes internos

La utilidad de esta noticia está en la lista de preguntas que deja abierta. Si una empresa ya tiene un asistente interno conectado a información sensible, al menos debería revisar esto:

• Autenticación y exposición de APIs: ningún endpoint “temporal”, de desarrollo o poco usado debería quedar fuera del mismo rigor que el resto del sistema.
• Privilegios y segmentación: el agente no debería ver todo por default. Menos privilegio y más separación por dominios sigue siendo la regla correcta.
• Prompts y configuraciones como activos críticos: no son texto decorativo; controlan comportamiento, límites y confianza operativa.
• Logs y monitoreo: si no sabes qué consulta el agente, qué recupera, qué modifica y qué patrones son anómalos, no tienes visibilidad real.
• Pentesting de la cadena completa: no solo del frontend o del modelo, también de RAG, conectores, almacenamiento, permisos y rutas de administración.

Aquí entra un tema que suele quedar subestimado: la observabilidad en IA no es adorno corporativo. Si el asistente toca documentos, consultas, embeddings y salidas de alto impacto, observar bien el sistema es parte del control, no un extra para después.

Qué significa esto para México y LatAm

Para equipos en México y América Latina, la lectura no es “eso le pasa a firmas globales, no a nosotros”. Más bien al contrario: muchas organizaciones de la región están entrando a la IA interna con presupuestos apretados, integraciones rápidas y presión por mostrar resultados antes de construir gobernanza seria.

Eso aplica a consultoras, bancos, despachos legales, universidades, áreas de soporte, equipos comerciales y cualquier operación que hoy esté subiendo documentos sensibles a un copiloto privado. El riesgo regional no siempre será un ataque sofisticado de película. A veces será algo mucho más banal: permisos heredados, conectores mal configurados, entornos de prueba expuestos o prompts sin control de cambios.

También hay una implicación cultural. En muchas empresas todavía se vende la IA interna como una capa “segura por defecto” solo porque no es pública. Ese discurso ya se siente viejo. Una herramienta cerrada hacia afuera puede seguir estando abierta por dentro.

Mi lectura: el problema no es la novedad del ataque, sino la normalidad del fallo

Lo más incómodo de este caso es que no apunta a una técnica exótica ni a un escenario imposible de prever. Apunta a algo peor: fallos conocidos, mezclados con una capa nueva de confianza operativa. Es decir, infraestructura común, pero ahora conectada a sistemas que resumen, recomiendan, recuperan y moldean trabajo de alto valor.

Por eso vale la pena enlazar esta discusión con cómo la IA transforma tu código. Cada vez que una organización mete IA en flujos reales, no solo compra velocidad; también redefine dependencias, superficies de ataque y puntos de confianza. Y si esa transición ocurre sin disciplina técnica, el resultado no es inteligencia aumentada. Es fragilidad aumentada.

Mi conclusión es simple: si tu agente interno puede leer demasiado, tocar demasiado y nadie tiene claro cómo se audita, entonces tu problema no es de IA; es de arquitectura, seguridad y gobernanza. McKinsey solo puso el reflector sobre algo que muchas otras empresas todavía prefieren no mirar.