Los sistemas de IA amplían la superficie de ataque que prometían cerrar
Las mismas herramientas que prometen defender el software lo dejan expuesto de nuevas formas
El argumento de venta de las herramientas de IA para seguridad ha sido siempre el mismo: la IA detecta más rápido, responde más rápido, escala donde el equipo humano no llega. Es un argumento correcto — y al mismo tiempo incompleto. Porque en los últimos días, con una concentración que no parece casual, vemos la otra cara: los sistemas de IA también atacan más rápido, explotan más rápido, y escalan donde ningún atacante humano llegaría solo. El patrón se acumula desde vectores distintos y en fechas distintas.
El caso Snowflake: cuando el autofix se convierte en la vulnerabilidad
El ejemplo más técnico y concreto ocurrió el 17 de agosto: el equipo de seguridad de Wiz documentó cómo el sistema de autofix de GitHub Copilot introdujo directamente la vulnerabilidad que permitió comprometer la instancia de Jira de Snowflake. El mecanismo es perturbador en su elegancia: Copilot genera un fix para un bug, ese fix contiene código que el desarrollador no revisa en detalle (porque para eso está el autofix), y ese código abre un vector de ataque nuevo. La herramienta diseñada para cerrar vulnerabilidades creó una.
Esto no es un bug de Copilot en el sentido convencional — es una propiedad estructural de los LLMs aplicados a seguridad: generan código plausible, no código correcto. Y el contexto de autofix es exactamente el contexto donde los humanos tienen menos incentivos para revisar. La velocidad que hace valiosa a la herramienta es la misma que elimina la supervisión que la haría segura.
OpenAI post-Hugging Face: más controles internos, menos acceso externo
Al día siguiente, OpenAI anunció nuevos controles de seguridad después de la brecha de Hugging Face: mayor monitoreo de modelos durante el desarrollo y mayor énfasis en alineación y seguridad durante el post-entrenamiento. La respuesta es razonable en el papel. Pero simultáneamente se conoció que OpenAI revocó el acceso de investigadores de ciberseguridad a su programa limitado de acceso para defensores.
El programa Trusted Access for Cyber tenía exactamente esa lógica: dar a defensores de confianza acceso a modelos más capaces para que pudieran encontrar vulnerabilidades antes que los atacantes. Revocar ese acceso en el mismo ciclo en que se anuncian más controles internos revela la tensión irresuelta en el sector: la apertura hacia defensores externos compite con el control de daño reputacional. El resultado neto puede ser menos seguridad, no más.
El vector epistémico: atacar lo que el modelo sabe, no su código
El tercer vector es menos técnico pero igualmente importante. Investigadores documentaron que Israel creó un think tank falso diseñado específicamente para engañar a los chatbots de IA: fabricó materiales que parecen legítimos a los sistemas de recuperación de información y a los modelos de búsqueda, con el objetivo de que esos sistemas reproduzcan narrativas específicas cuando se les consulte. Es el primer caso documentado de ataque deliberado al corpus de conocimiento de los LLMs, no a su código.
Esto expande la definición de superficie de ataque más allá del software: incluye ahora el conjunto de información sobre el que los modelos razonan. Un atacante sofisticado no necesita explotar una vulnerabilidad técnica — puede manipular los datos de los que el modelo aprende, o las fuentes que el sistema de RAG considera confiables. El modelo correcto sobre datos envenenados produce resultados incorrectos.
La predicción falsable
Si esta tendencia se sostiene, en los próximos 6 meses veremos el primer incidente de seguridad atribuido públicamente a un sistema de IA en infraestructura crítica de la región LATAM — no por un ataque externo clásico, sino por una automatización de IA que introdujo una vulnerabilidad en un sistema de control o en un pipeline de desarrollo. Qué mirar: los reportes de incidentes de los CERTs nacionales en Argentina, Brasil, México y España, y si alguno menciona explícitamente herramientas de IA generativa como vector.
Para un decisor en LATAM o España: la pregunta que hay que hacerse antes de desplegar cualquier herramienta de IA en el stack de seguridad o de desarrollo no es «¿qué protege?» sino «¿qué superficie nueva abre?». El autofix de Copilot es el ejemplo más claro: la herramienta de productividad tiene una segunda naturaleza que solo se revela cuando algo sale mal. Auditar esa segunda naturaleza — qué genera la herramienta cuando nadie supervisa — debería ser parte de cualquier evaluación de incorporación de IA a procesos críticos.