# Repositorios de código abierto concentran el riesgo real de IA — los modelos envenenados siguen en el laboratorio
Mientras la industria debate ataques teóricos a modelos, los incidentes documentados golpean flujos de trabajo de desarrollo y dependencias de paquetes.
El CEO de Zentera Systems, Jaushin Lee, señaló en una entrevista reciente que la superficie de ataque en sistemas de inteligencia artificial no se materializa donde la mayoría de las organizaciones concentra su atención. Según su análisis, la mayoría de los incidentes de seguridad vinculados a IA afectan flujos de trabajo de desarrolladores y repositorios de paquetes de código abierto — no los modelos en sí. Los vectores más discutidos en conferencias de seguridad, como pesos de modelos envenenados o servidores MCP (Model Context Protocol) comprometidos, permanecen principalmente confinados a demostraciones de investigación sin evidencia de explotación en producción a escala.
Por qué los repositorios de paquetes concentran el riesgo antes que los modelos
Lee identificó los repositorios de paquetes de código abierto como el vector de ataque predominante en la cadena de suministro de IA. Este patrón replica exactamente lo observado en software tradicional durante la última década: atacantes que insertan dependencias maliciosas en registros públicos (PyPI, npm, RubyGems) para comprometer proyectos downstream. La diferencia en el contexto de IA es que los equipos de machine learning tienden a consumir bibliotecas con menos escrutinio que los equipos de infraestructura tradicional, bajo la premisa de que están trabajando en entornos de experimentación aislados.
La realidad documentada contradice esa premisa. Los flujos de trabajo de desarrollo de IA — notebooks de Jupyter, pipelines de entrenamiento, scripts de preprocesamiento — operan frecuentemente con credenciales de acceso a datos sensibles, claves de API de servicios en la nube y permisos de escritura en buckets de almacenamiento. Un paquete comprometido en ese contexto no necesita atacar el modelo: puede exfiltrar datasets completos, credenciales o código propietario antes de que el modelo llegue a entrenamiento.
Dónde están realmente los ataques a modelos y por qué no escalan
Los pesos de modelos envenenados — archivos de parámetros entrenados modificados para comportarse de forma maliciosa bajo condiciones específicas — siguen siendo un problema teórico bien documentado en papers académicos pero sin incidentes confirmados en producción empresarial. Lee ubicó este vector en la categoría de demostraciones de investigación, junto con servidores MCP comprometidos. La razón técnica es simple: envenenar un modelo requiere acceso durante el entrenamiento o capacidad de sustituir el artefacto final, dos escenarios que implican compromiso previo de infraestructura — el mismo compromiso que ya permite exfiltración directa sin necesidad de manipular el modelo.
Los servidores MCP comprometidos enfrentan una barrera similar. MCP es un protocolo propuesto para estandarizar la comunicación entre modelos de lenguaje y herramientas externas, pero su adopción en entornos de producción sigue siendo marginal. Comprometer un servidor MCP en un entorno de demostración es trivial; hacerlo en una implementación empresarial requiere primero que la organización haya adoptado el protocolo y luego que el atacante logre persistencia en la infraestructura que lo aloja — nuevamente, un nivel de acceso que habilita vectores de ataque más directos.
Segmentación como estrategia de mitigación más eficiente que herramientas especializadas
Lee planteó que la segmentación de red y de cargas de trabajo ofrece más reducción de riesgo por unidad de inversión que herramientas de seguridad específicas para IA. La lógica es estructural: si un flujo de trabajo de desarrollo de IA no puede alcanzar sistemas de producción, bases de datos de clientes o repositorios de código fuente, el impacto de un paquete comprometido queda contenido al entorno de experimentación. Esta aproximación no requiere visibilidad profunda en el comportamiento del modelo ni análisis de anomalías en inferencia — solo políticas de red que traten los entornos de ML como zonas de confianza reducida.
La recomendación contrasta con la tendencia de mercado hacia soluciones de seguridad especializadas en IA (escaneo de modelos, detección de adversarial examples, monitoreo de drift). Lee no descartó esas herramientas, pero las ubicó como segunda línea de defensa después de controles arquitectónicos básicos. En términos prácticos, una organización que segmenta correctamente sus entornos de ML puede tolerar un paquete malicioso en un notebook sin que ese incidente escale a compromiso de datos o sistemas críticos.
Auto-alojamiento de modelos y sus límites como estrategia de mitigación
La entrevista también abordó el auto-alojamiento de modelos (self-hosting) como estrategia para reducir dependencia de proveedores externos. Lee reconoció el valor de esa aproximación para control de datos y cumplimiento regulatorio, pero señaló que no elimina riesgos de cadena de suministro — solo los desplaza. Un modelo auto-alojado sigue dependiendo de frameworks de inferencia (TensorFlow Serving, TorchServe, ONNX Runtime), bibliotecas de preprocesamiento y drivers de hardware, cada uno con su propia cadena de dependencias. El auto-alojamiento reduce exposición a compromisos en APIs de terceros, pero introduce responsabilidad directa sobre la seguridad de toda la pila de software subyacente.
Lee mencionó prácticas de aislamiento en semiconductores como referencia para equipos de software. La industria de chips implementa separación física entre entornos de diseño, fabricación y testing, con controles estrictos sobre qué herramientas pueden ejecutarse en cada etapa. Traducido a software, eso implica pipelines de CI/CD donde cada fase (desarrollo, entrenamiento, validación, despliegue) opera en entornos aislados con permisos mínimos y sin capacidad de comunicación lateral no autorizada.
Exposición en América Latina por dependencia de repositorios públicos sin auditoría local
Aunque la entrevista no abordó geografías específicas, el patrón descrito tiene implicancias directas para organizaciones en América Latina. La región presenta alta dependencia de repositorios públicos de código abierto sin capacidad local de auditoría o mirrors privados en la mayoría de empresas medianas. Equipos de ML en Brasil, México, Argentina y Chile consumen paquetes de PyPI y Hugging Face sin procesos de validación intermedios, bajo la premisa de que esos repositorios son confiables por defecto. Esa premisa ya fue refutada en múltiples incidentes documentados en software tradicional (typosquatting en PyPI, paquetes maliciosos en npm), pero los equipos de IA en la región tienden a operar con menos controles que los equipos de desarrollo de aplicaciones.
La falta de segmentación en entornos de ML es particularmente pronunciada en startups y equipos de innovación dentro de empresas tradicionales, donde los notebooks de Jupyter frecuentemente tienen acceso directo a bases de datos de producción para facilitar experimentación rápida. Ese patrón, común en toda la región, convierte cada dependencia no auditada en un vector de exfiltración potencial sin necesidad de comprometer el modelo final.
Nuestro análisis
La observación de Lee sobre dónde se materializan los incidentes reales versus dónde se concentra la atención de la industria revela un desajuste estructural en priorización de riesgos. La narrativa dominante en seguridad de IA — ataques adversariales, modelos envenenados, alucinaciones maliciosas — describe amenazas técnicamente válidas pero sin evidencia de explotación sistemática fuera de entornos controlados. Mientras tanto, los vectores que ya funcionan en software tradicional (dependencias comprometidas, credenciales expuestas, falta de segmentación) operan sin fricción en entornos de ML porque los equipos de IA tienden a verse a sí mismos como fuera del alcance de políticas de seguridad convencionales.
El énfasis en segmentación como control primario es consistente con décadas de práctica en seguridad de infraestructura, pero su aplicación a entornos de ML sigue siendo irregular incluso en organizaciones maduras. La razón no es técnica — las herramientas de segmentación existen y son bien entendidas — sino cultural: los equipos de ciencia de datos históricamente operaron con autonomía casi total sobre sus entornos de trabajo, y la introducción de controles de red es percibida como fricción que ralentiza experimentación. Esa percepción ignora que la alternativa — responder a un incidente de exfiltración originado en un notebook comprometido — genera órdenes de magnitud más fricción y costo que implementar segmentación preventiva. ¿Cuántos incidentes más en flujos de desarrollo se necesitan antes de que la segmentación de entornos de ML se vuelva práctica estándar en lugar de excepción?