IA local y BYOM: el nuevo punto ciego del CISO

El punto ciego que ningún CISO quiere admitir: la IA ya corre en los laptops de tu equipo

Durante los últimos 18 meses, el manual de seguridad para IA generativa fue relativamente claro: controla el navegador, bloquea los endpoints de las APIs externas y enruta el tráfico por gateways aprobados. Si los datos sensibles salían de la red hacia un proveedor en la nube, el equipo de seguridad podía verlo, registrarlo y detenerlo. Ese modelo, sin embargo, está quedando obsoleto más rápido de lo que la mayoría de los CISOs imagina.

Un cambio silencioso en el hardware está desplazando el uso de los modelos de lenguaje grandes (LLM) fuera de la red y directo al endpoint. Es lo que los analistas ya denominan Shadow AI 2.0 o la era Bring Your Own Model (BYOM): desarrolladores ejecutando modelos capaces en sus propios laptops, sin conexión, sin llamadas API y sin firma de red visible. Y cuando la seguridad no puede verlo, tampoco puede gestionarlo.

Por qué la inferencia local ya es rutina para los desarrolladores

Hace dos años, correr un LLM útil en un laptop de trabajo era una rareza técnica. Hoy es práctica común en equipos de ingeniería, gracias a tres factores que convergieron casi simultáneamente:

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

Aceleradores de consumo con capacidad seria: Un MacBook Pro con 64 GB de memoria unificada puede ejecutar modelos cuantizados de clase 70B a velocidades utilizables. Lo que antes requería servidores multi-GPU hoy cabe en un laptop de gama alta.
Cuantización mainstream: Técnicas que comprimen modelos a formatos más pequeños y rápidos —como GGUF— permiten ajustarlos a la memoria disponible con sacrificios aceptables de calidad para muchas tareas cotidianas.
Distribución sin fricción: Herramientas como Ollama, llama.cpp y LM Studio hacen que el flujo descarga → ejecuta → chatea sea cuestión de un solo comando. Los modelos de pesos abiertos como Llama 3 o Mistral se descargan libremente desde repositorios como Hugging Face.

El resultado es que un ingeniero puede descargar un artefacto de varios gigabytes, desconectar el Wi-Fi y procesar flujos de trabajo sensibles localmente: revisión de código fuente, resumen de documentos, borradores de comunicaciones con clientes o análisis exploratorio sobre datasets regulados. Sin paquetes de salida, sin logs del proxy, sin rastro en la nube. Desde la perspectiva de seguridad de red, esa actividad puede ser indistinguible de que no pasó nada.

Según datos del sector, en 2026 el 85% de las empresas ya tienen algún tipo de Shadow AI, incluidos modelos locales, frente al 65% de 2024. El crecimiento anual se duplicó impulsado precisamente por la facilidad del BYOM.

Los tres puntos ciegos que el CISO no está midiendo

Si los datos no salen del laptop, ¿por qué debería preocuparse un CISO? Porque los riesgos dominantes se desplazan desde la exfiltración hacia la integridad, la procedencia y el cumplimiento normativo. Tres clases de puntos ciegos que la mayoría de las empresas no tienen operacionalizados:

1. Contaminación de código y decisiones (riesgo de integridad)

Los modelos locales se adoptan porque son rápidos, privados y no requieren aprobación. La contracara es que frecuentemente no han pasado ningún proceso de revisión para el entorno empresarial.

El escenario más común: un desarrollador senior descarga un modelo de código afinado por la comunidad porque tiene buenos benchmarks. Pega lógica interna de autenticación, flujos de pago o scripts de infraestructura para limpiarlo. El modelo devuelve código que parece competente, compila y pasa las pruebas unitarias, pero degrada sutilmente la postura de seguridad: validación débil de inputs, configuraciones inseguras por defecto, cambios de concurrencia frágiles, dependencias no permitidas internamente. El ingeniero hace el commit.

Si esa interacción ocurrió offline, es posible que no exista ningún registro de que la IA influyó en ese camino de código. Durante la respuesta a incidentes, se investigará el síntoma —una vulnerabilidad— sin visibilidad de la causa raíz: el uso no controlado de un modelo.

2. Exposición de licencias y propiedad intelectual (riesgo de compliance)

Muchos modelos de alto rendimiento incluyen licencias con restricciones de uso comercial, requisitos de atribución, límites de campo de uso u obligaciones incompatibles con el desarrollo de productos propietarios. Cuando los empleados ejecutan modelos localmente, ese uso puede eludir los procesos normales de adquisición y revisión legal de la organización.

Si un equipo usa un modelo no comercial para generar código de producción, documentación o comportamiento de producto, la empresa hereda un riesgo que aparece más tarde durante la due diligence de M&A, revisiones de seguridad de clientes o litigios. El problema no son solo los términos de la licencia; es la falta de inventario y trazabilidad.

3. Exposición en la cadena de suministro de modelos (riesgo de procedencia)

La inferencia local también transforma el problema de la cadena de suministro de software. Los endpoints comienzan a acumular grandes artefactos de modelos y el ecosistema de herramientas que los rodea: descargadores, convertidores, runtimes, plugins, interfaces y paquetes Python.

Existe un matiz técnico crítico: el formato de archivo importa. Mientras que formatos modernos como Safetensors están diseñados para prevenir la ejecución arbitraria de código, los archivos PyTorch basados en Pickle pueden ejecutar payloads maliciosos simplemente al cargarse. Si tus desarrolladores están descargando checkpoints no verificados desde Hugging Face u otros repositorios, no solo están descargando datos: podrían estar descargando un exploit.

En el primer trimestre de 2025 se documentó al menos un caso en una empresa Fortune 500 donde una variante de Llama modificada y ejecutada localmente vía Ollama contenía malware inyectado en los pesos del modelo, exfiltrando datos de clientes sin ser detectada por las soluciones DLP de nube. El mayor gap organizacional hoy es que la mayoría de las empresas no tienen el equivalente de un Software Bill of Materials (SBOM) para modelos: procedencia, hashes, fuentes permitidas, escaneo y gestión del ciclo de vida.

Cómo mitigar BYOM: tratar los pesos del modelo como artefactos de software

No puedes resolver la inferencia local bloqueando URLs. Necesitas controles conscientes del endpoint y una experiencia de desarrollador que haga que el camino seguro sea también el camino fácil. Tres líneas de acción concretas:

1. Llevar la gobernanza al endpoint

El DLP de red y el CASB siguen siendo relevantes para el uso en la nube, pero no son suficientes para BYOM. Comienza a tratar el uso de modelos locales como un problema de gobernanza de endpoint buscando señales específicas:

Inventario y detección: Escanea indicadores de alta fidelidad como archivos .gguf mayores de 2 GB, procesos como llama.cpp u Ollama, y listeners locales en puertos conocidos como el 11434 (default de Ollama).
Conciencia de proceso y runtime: Monitorea picos recurrentes de uso de GPU/NPU desde runtimes no aprobados o servidores de inferencia local desconocidos.
Política de dispositivo: Usa MDM y EDR para controlar la instalación de runtimes no aprobados y reforzar el hardening base en los dispositivos de ingeniería. El objetivo no es castigar la experimentación; es recuperar la visibilidad.

2. Construir un catálogo interno de modelos: la ruta pavimentada

El Shadow AI es frecuentemente el resultado de la fricción. Las herramientas aprobadas son demasiado restrictivas, demasiado genéricas o tardan demasiado en aprobarse. Una mejor estrategia es ofrecer un catálogo interno curado que incluya:

Modelos aprobados para tareas comunes: codificación, resumen, clasificación.
Licencias verificadas y guías de uso.
Versiones fijadas con hashes, priorizando formatos más seguros como Safetensors.
Documentación clara sobre uso local seguro, incluyendo qué datos sensibles están o no permitidos.

Si quieres que los desarrolladores dejen de buscar en repositorios externos, dales algo mejor internamente.

3. Actualizar el lenguaje de política: "servicios en la nube" ya no es suficiente

La mayoría de las políticas de uso aceptable hablan de SaaS y herramientas cloud. El BYOM exige políticas que cubran explícitamente:

Descarga y ejecución de artefactos de modelos en endpoints corporativos.
Fuentes aceptables.
Requisitos de cumplimiento de licencias.
Reglas para el uso de modelos con datos sensibles.
Expectativas de retención y logging para herramientas de inferencia local.

No necesita ser pesado o burocrático. Necesita ser inequívoco.

Marcos de referencia para la gobernanza de modelos en 2026

La industria está comenzando a articular estándares específicos para este desafío:

NIST AI RMF 1.0 (actualizado en 2025): Marco de gestión de riesgos para la confiabilidad de sistemas de IA, incluyendo cadena de suministro y despliegue en entornos empresariales.
CISA AI Security Framework: Guías sobre integridad de modelos, escaneo de endpoints y protección contra envenenamiento de datos y modelos.
AI-SBOM (basado en SLSA/CycloneDX): Extensión del concepto de software bill of materials a modelos de IA, rastreando pesos, procedencia y dependencias.
NIST y CISA recomiendan ya tratar los artefactos de modelos con el mismo rigor que cualquier otro ejecutable desconocido en la red.

5 señales de que Shadow AI ya migró a tus endpoints

Si no sabes por dónde empezar la auditoría, estos son los indicadores concretos que buscan los equipos de seguridad más avanzados:

Artefactos de modelos grandes: Consumo de almacenamiento no explicado por archivos .gguf o .pt.
Servidores de inferencia locales: Procesos escuchando en puertos como el 11434 (Ollama).
Patrones de uso de GPU: Picos de GPU mientras el equipo está offline o desconectado de la VPN.
Falta de inventario de modelos: Incapacidad de mapear outputs de código a versiones específicas de modelos.
Ambigüedad de licencias: Presencia de pesos de modelos "no comerciales" en builds de producción.

Conclusión

Durante una década movimos los controles de seguridad "hacia arriba", a la nube. La inferencia local está jalando una porción significativa de la actividad de IA de regreso "hacia abajo", al endpoint. Shadow AI 2.0 no es un futuro hipotético; es la consecuencia predecible del hardware rápido, la distribución fácil y la demanda del desarrollador.

Los CISOs que se enfoquen únicamente en los controles de red perderán lo que está ocurriendo en el silicio que descansa sobre el escritorio de sus empleados. La próxima fase de la gobernanza de IA tiene menos que ver con bloquear sitios web y más con controlar artefactos, procedencia y política a nivel del endpoint, sin destruir la productividad del equipo.

Para los founders de startups que están escalando equipos de ingeniería, este es el momento de construir una cultura de IA responsable desde el inicio, antes de que el Shadow AI 2.0 se convierta en un pasivo que frene su próxima ronda o su primera auditoría de enterprise security.

Descubre cómo otros founders gestionan la seguridad y la IA en sus equipos: únete gratis a la comunidad de Ecosistema Startup.

Unirme a la comunidad