Código con alucinaciones: El eslabón imaginario que compromete al software real

En las trincheras del desarrollo moderno, la figura del programador solitario ha sido reemplazada por una simbiosis creciente con asistentes inteligentes. GitHub Copilot, ChatGPT, Claude o Gemini han pasado de ser curiosidades experimentales a asistentes cotidianos. Pero en medio de esta revolución, pocas preguntas se han formulado con el nivel de gravedad que merecen. ¿Qué sucede cuando esa IA, a la que se le confía el diseño de una aplicación crítica, inventa cosas que no existen?

Alucinaciones con consecuencias: el fenómeno de los paquetes inexistentes

Las alucinaciones de la inteligencia artificial no son fallos evidentes. Son distorsiones verosímiles que se infiltran en los entornos de desarrollo bajo la forma de soluciones legítimas. Un modelo puede sugerir una librería que suena perfectamente plausible —por nombre, por estructura, por pertenencia al ecosistema—, pero que en realidad no tiene existencia previa. El LLM la ha fabricado como parte de su predicción estadística, no como resultado de una verificación contra repositorios reales.

Slopsquatting: la nueva versión del typosquatting impulsada por IA

Investigadores de la Universidad de Texas en San Antonio, junto a equipos de Virginia Tech y Oklahoma, demostraron que los modelos de lenguaje, al alucinar nombres de dependencias, pueden ser explotados indirectamente. En vez de registrar variantes tipográficas de paquetes existentes, los atacantes monitorean las alucinaciones más frecuentes generadas por IA, registran esos nombres inventados y los cargan con código malicioso. En su estudio, generaron más de 200.000 nombres a partir de prompts a LLMs. Alrededor del 22% fueron considerados creíbles por desarrolladores reales. Los autores bautizaron a su herramienta de exploración como SlopFinder, un motor inverso que escanea el espacio probable de nombres que una IA podría alucinar.

Impacto en la cadena de suministro: del laboratorio al despliegue corporativo

Un desarrollador, bajo presión por cumplir un sprint, acepta una sugerencia del copiloto que incluye una dependencia con nombre creíble. El paquete no existe… aún. Pero alguien ya lo ha registrado con una carga útil hostil. Se instala. Todo compila. El CI/CD lo aprueba. La aplicación se despliega. Durante semanas, nada parece fuera de lugar, hasta que un microservicio comienza a realizar conexiones inusuales a dominios exóticos. La dependencia alucinada, aceptada sin escrutinio, fue el punto de entrada.

Vacío de responsabilidad: ¿quién protege al desarrollador que confía en su IA?

Los disclaimers legales de las plataformas de IA son vagos. Los IDE no emiten alertas sobre posibles dependencias inexistentes. Las guías de seguridad del software todavía no incluyen el riesgo de alucinaciones como parte de sus catálogos. No existen políticas claras sobre cómo auditar lo que sugiere un copiloto digital.

Estrategias defensivas reales (y sin ilusiones)

Blindarse frente a este vector requiere fricción deliberada: validar automáticamente que toda dependencia sugerida por una IA exista realmente en repositorios confiables, tenga historial de actualizaciones, y presente patrones de comportamiento conocidos. El uso de Software Bills of Materials (SBOMs) puede ayudar a identificar componentes no verificados antes del despliegue. Los entornos de seguridad modernos deben partir del principio de que no todo lo sugerido debe ser instalado, y que la verosimilitud no es sinónimo de autenticidad.

Epílogo: el veneno en el código sugerido

Un desarrollador comienza su día. El editor le sugiere completar una función. Una línea aparece: import sslhelperfast. El nombre es impecable. Compila. Todo parece en orden. Pero esa línea es una invención, aceptada sin verificación e instalada como parte de un flujo ágil. La próxima gran crisis de ciberseguridad podría no originarse en una vulnerabilidad conocida, sino en una línea de código generada sin malicia. El primer eslabón fue imaginado. Y nadie lo cuestionó.