Hace algún tiempo, una vulnerabilidad crítica pasó desapercibida en LiteLLM, una de las bibliotecas más usadas para conectar aplicaciones con modelos de lenguaje como GPT o Claude. No era un error menor. Era una puerta trasera que permitía ejecutar código arbitrario en los servidores, con acceso potencial a credenciales de modelos, datos en tránsito y más. Lo revelador no fue el fallo técnico. Fue el tiempo que tardó en detectarse, la dependencia masiva de ese paquete y el hecho de que muchas organizaciones —algunas tomando decisiones con impacto real en vidas— ignoraban por completo su existencia.

Vale la pena examinar no el bug en sí, sino el entorno que lo permitió prosperar.

Para quien no trabaja en tecnología: LiteLLM actúa como un adaptador universal. Conecta aplicaciones con proveedores de IA como OpenAI, Anthropic o Google mediante un lenguaje común. Es esencial en sistemas de atención médica, plataformas educativas y herramientas de análisis financiero. Ese adaptador invisible rara vez se audita, aunque todo depende de él.

El problema es la opacidad estructural. Los bugs surgen en cualquier software; son parte inevitable de estructuras complejas. Lo crítico es que LiteLLM, siendo código abierto y teóricamente auditable, rara vez lo es en la práctica. Las aplicaciones modernas dependen de cientos de paquetes, cada uno con sus riesgos y mantenedores. Pocas organizaciones los revisan con rigor. La transparencia prometida queda en teoría; la mayoría confía en revisiones ajenas que a menudo no ocurren.

Esta dinámica se repite en distintos contextos. La infraestructura crítica se construye con rapidez y se adopta aún más velozmente, mientras la auditoría llega tarde, si es que llega. La historia tecnológica ofrece ejemplos concretos: el protocolo BGP, base del enrutamiento de internet, se diseñó en los ochenta asumiendo confianza mutua entre operadores que ya no existe. El sistema SWIFT de pagos interbancarios falló en 2016 porque los bancos carecían de controles que se daban por sentados. Estas estructuras opacas concentran poder en quienes las controlan o entienden mejor, no siempre en quienes deberían.

Lo inquietante es cómo esto contradice el discurso sobre gobernanza de IA. Se promueve la "IA auditable", los sistemas explicables y la rendición de cuentas algorítmica. Son objetivos válidos. Pero si no auditamos en la práctica los paquetes que unen aplicaciones con modelos, ¿qué valor tiene auditar la IA que aprueba créditos, recomienda libertad condicional o prioriza diagnósticos médicos? La confianza se quiebra en el middleware, en esa dependencia invisible que nadie inspeccionó.

Al analizar IA en sistemas de justicia, el sesgo en modelos resulta solo parte del problema; la arquitectura circundante carece de verificación real. LiteLLM ilustra lo mismo. Un modelo transparente no salva un sistema opaco si la conexión al mundo real no se verifica de forma continua.

Aquí la perspectiva histórica cobra fuerza. En el siglo XIX, con la expansión de los ferrocarriles como infraestructura clave, el poder residía en quienes manejaban nodos, horarios y tarifas, no en gobiernos ni usuarios. Lo mismo ocurrió con las redes de telecomunicaciones, los sistemas financieros y los algoritmos de contenido. En economías emergentes, esa concentración de poder exacerbó desigualdades locales; hoy el mismo proceso se replica en adopciones de IA sin salvaguardas. La opacidad no es accidente: surge de diseños apresurados que nunca integraron transparencia desde el inicio.

Esto cobra urgencia porque la adopción de IA en gobernanza —gestión de recursos públicos, evaluación de riesgos, asignación de servicios— avanza más rápido que los mecanismos de auditoría. No es un argumento contra la IA; sería ilógico. Es una crítica a la prisa institucional y a la noción errónea de que código abierto implica auditoría automática. Importar herramientas complejas a sistemas críticos requiere primero construir verificación adecuada.

No hay una solución completa a la vista. El problema es más intrincado de lo que parece. Pero hay pasos necesarios: auditorías continuas y automatizadas de dependencias como requisito en sectores críticos; equipos técnicos en organismos reguladores con poder de inspección directa; marcos que abarquen la cadena entera —modelo, middleware, datos, infraestructura— y no solo el algoritmo visible.

Construir una sociedad donde la IA orqueste decisiones colectivas justas y verificables exige innovaciones que hoy faltan. El hack de LiteLLM trasciende lo técnico: revela dónde estamos realmente en este trayecto, más allá de los anuncios optimistas.

Las piedras no mienten, pero los historiadores a veces sí.

Fuentes:

1. Trail of Bits / Socket Security — Análisis de vulnerabilidades en cadenas de dependencias de software (2023-2024)

2. SWIFT Banking System Breach — Bangladesh Bank heist, reportes del Federal Reserve Bank of New York (2016)

3. BGP Security History — NIST Special Publication 800-54, Border Gateway Protocol Security

4. Wired / Ars Technica — Cobertura del ecosistema LiteLLM y vulnerabilidades en middleware de IA (2024)

5. AI Now Institute — "Algorithmic Accountability Policy Toolkit" (2023)