Sus desarrolladores ya están ejecutando IA localmente: por qué la inferencia en el dispositivo es el nuevo punto ciego del CISO

Durante los últimos 18 meses, el manual del CISO para la IA generativa ha sido relativamente simple: controlar el navegador.

Equipos de seguridad reforzaron las políticas del agente de seguridad de acceso a la nube (CASB), bloquearon o monitorearon el tráfico a puntos finales de IA conocidos y enrutaron el uso a través de puertas de enlace autorizadas. El modelo operativo era claro: si datos confidenciales salen de la red para una llamada API externa, podemos observarlos, registrarlos y detenerlos. Pero ese modelo está empezando a resquebrajarse.

Un cambio silencioso de hardware está impulsando el uso del modelo de lenguaje grande (LLM) fuera de la red y hacia el punto final. Llámelo Shadow AI 2.0, o la era de “traiga su propio modelo” (BYOM): los empleados ejecutan modelos capaces localmente en computadoras portátiles, fuera de línea, sin llamadas API y sin una firma de red obvia. La conversación sobre gobernanza todavía se enmarca como “exfiltración de datos a la nube”, pero el riesgo empresarial más inmediato es cada vez más una “inferencia no investigada dentro del dispositivo”.

Cuando la inferencia ocurre localmente, la prevención de pérdida de datos (DLP) tradicional no ve la interacción. Y cuando la seguridad no puede verlo, no puede gestionarlo.

Por qué la inferencia local de repente es práctica

Hace dos años, ejecutar un LLM útil en una computadora portátil del trabajo era un truco de nicho. Hoy es una rutina para los equipos técnicos.

Tres cosas convergieron:

• Los aceleradores de consumo se pusieron serios: Una MacBook Pro con memoria unificada de 64 GB a menudo puede ejecutar modelos cuantificados de clase 70B a velocidades utilizables (con límites prácticos en la longitud del contexto). Lo que antes requería servidores multi-GPU ahora es factible en una computadora portátil de alta gama para muchos flujos de trabajo reales.

• La cuantización se generalizó: Ahora es fácil comprimir modelos en formatos más pequeños y rápidos que caben en la memoria de una computadora portátil, a menudo con compensaciones de calidad aceptables para muchas tareas.

• La distribución es sin fricciones: Los modelos de peso abierto están a un solo comando de distancia, y el ecosistema de herramientas hace que “descargar → ejecutar → chatear” sea trivial.

El resultado: Un ingeniero puede extraer un artefacto de modelo de varios GB, apagar Wi-Fi y ejecutar flujos de trabajo confidenciales localmente, revisar el código fuente, resumir documentos, redactar comunicaciones con los clientes e incluso realizar análisis exploratorios sobre conjuntos de datos regulados. Sin paquetes salientes, sin registros de proxy, sin seguimiento de auditoría en la nube.

De un perspectiva de seguridad de redesa actividad puede parecer indistinguible de «no pasó nada».

El riesgo ya no es sólo que los datos abandonen la empresa

Si los datos no salen de la computadora portátil, ¿por qué debería importarle a un CISO?

Porque los riesgos dominantes pasan de la exfiltración a la integridad, la procedencia y el cumplimiento. En la práctica, la inferencia local crea tres clases de puntos ciegos que la mayoría de las empresas no han puesto en práctica.

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

Los modelos locales a menudo se adoptan porque son rápidos, privados y «no requieren aprobación». La desventaja es que con frecuencia no son examinados para el entorno empresarial.

Un escenario común: Un desarrollador senior descarga un modelo de codificación adaptado a la comunidad porque ofrece buenos resultados comparativos. Pegan lógica de autenticación interna, flujos de pago o scripts de infraestructura para «limpiarlo». El modelo devuelve resultados que parecen competentes, compila y pasa pruebas unitarias, pero degrada sutilmente la postura de seguridad (validación de entrada débil, valores predeterminados inseguros, cambios de concurrencia frágiles, opciones de dependencia que no están permitidas internamente). El ingeniero confirma el cambio.

Si esa interacción ocurrió fuera de línea, es posible que no tenga ningún registro de que la IA haya influido en la ruta del código. Y cuando luego responda al incidente, estará investigando el síntoma (una vulnerabilidad) sin visibilidad de una causa clave (uso incontrolado del modelo).

2. Licencias y exposición de la propiedad intelectual (riesgo de cumplimiento)

Muchos modelos de alto rendimiento se envían con licencias que incluyen restricciones de uso comercialrequisitos de atribución, límites de campo de uso u obligaciones que pueden ser incompatibles con el desarrollo de productos patentados. Cuando los empleados ejecutan modelos localmente, ese uso puede eludir el proceso normal de revisión legal y de adquisiciones de la organización.

Si un equipo utiliza un modelo no comercial para generar código de producción, documentación o comportamiento del producto, la empresa puede heredar el riesgo que aparece más adelante durante la diligencia de fusiones y adquisiciones, las revisiones de seguridad de los clientes o los litigios. La parte difícil no son sólo los términos de la licencia, sino la falta de inventario y trazabilidad. Sin un centro de modelos gobernado o un registro de uso, es posible que no pueda demostrar qué se usó y dónde.

3. Modelo de exposición de la cadena de suministro (riesgo de procedencia)

La inferencia local también cambia el problema de la cadena de suministro de software. Los puntos finales comienzan a acumular grandes artefactos de modelo y las cadenas de herramientas que los rodean: cargadores propios, convertidores, tiempos de ejecución, complementos, shells de interfaz de usuario y paquetes de Python.

Aquí hay un matiz técnico crítico: el formato del archivo importa. Mientras que los formatos más nuevos como tensores de seguridad están diseñados para evitar la ejecución de código arbitrario, más antiguo a base de pepinillos Archivos PyTorch puede ejecutar cargas útiles maliciosas simplemente cuando se carga. Si sus desarrolladores están tomando puntos de control no examinados de Hugging Face u otros repositorios, no solo están descargando datos: podrían estar descargando un exploit.

Los equipos de seguridad han pasado décadas aprendiendo a tratar los ejecutables desconocidos como hostiles. BYOM requiere extender esa mentalidad a los artefactos del modelo y la pila de tiempo de ejecución circundante. La mayor brecha organizacional hoy en día es que la mayoría de las empresas no tienen equivalente a un lista de materiales del software para modelos: procedencia, hashes, fuentes permitidas, escaneo y gestión del ciclo de vida.

Mitigación de BYOM: trate los pesos del modelo como artefactos de software

No se puede resolver la inferencia local bloqueando las URL. Necesita controles que tengan en cuenta los endpoints y una experiencia de desarrollador que haga que el camino seguro sea el camino fácil.

Aquí hay tres formas prácticas:

1. Mover la gobernanza hasta el punto final

Network DLP y CASB siguen siendo importantes para el uso de la nube, pero no son suficientes para BYOM. Comience a tratar el uso del modelo local como un problema de gobernanza de endpoints buscando señales específicas:

• Inventario y detección: Busque indicadores de alta fidelidad como archivos .gguf de más de 2 GB, procesos como llama.cpp o Ollama, y ​​oyentes locales en común puerto predeterminado 11434.

• Conciencia del proceso y del tiempo de ejecución: Supervise la utilización elevada y repetida de GPU/NPU (unidad de procesamiento neuronal) desde tiempos de ejecución no aprobados o servidores de inferencia locales desconocidos.

• Política de dispositivos: Usar gestión de dispositivos móviles (MDM) y detección y respuesta de terminales (EDR) políticas para controlar la instalación de tiempos de ejecución no aprobados y aplicar un refuerzo básico en los dispositivos de ingeniería. El punto no es castigar la experimentación. Es recuperar visibilidad.

2. Proporcionar un camino pavimentado: un centro de modelos interno y seleccionado

IA de las sombras es a menudo el resultado de la fricción. Las herramientas aprobadas son demasiado restrictivas, demasiado genéricas o demasiado lentas para aprobarse. Un mejor enfoque es ofrecer un catálogo interno seleccionado que incluya:

• Modelos aprobados para tareas comunes (codificación, resumen, clasificación)

• Licencias verificadas y guía de uso

• Versiones fijadas con hashes (priorizando formatos más seguros como Safetensors)

• Documentación clara para un uso local seguro, incluido dónde se permiten y no se permiten datos confidenciales. Si quieres que los desarrolladores dejen de buscar en la basura, dales algo mejor.

3. Actualizar el lenguaje de la política: los “servicios en la nube” ya no son suficientes

Las políticas de uso más aceptables hablan de SaaS y herramientas en la nube. BYOM requiere una política que cubra explícitamente:

• Descarga y ejecución de artefactos de modelo en puntos finales corporativos

• Fuentes aceptables

• Requisitos de cumplimiento de licencia

• Reglas para usar modelos con datos confidenciales

• Expectativas de retención y registro para herramientas de inferencia locales. Esto no tiene por qué ser demasiado estricto. Tiene que ser inequívoco.

El perímetro vuelve al dispositivo.

Durante una década trasladamos los controles de seguridad “hacia arriba” a la nube. La inferencia local está devolviendo una porción significativa de la actividad de la IA al punto final.

Cinco señales de que la IA en la sombra se ha trasladado a los puntos finales:

• Artefactos de modelos grandes: Consumo de almacenamiento inexplicable por parte de archivos .gguf o .pt.

• Servidores de inferencia locales: Procesos escuchando en puertos como 11434 (Ollama).

• Patrones de utilización de GPU: Picos en el uso de GPU sin conexión o sin conexión a VPN.

• Falta de inventario de modelos: Incapacidad para asignar salidas de código a versiones de modelos específicas.

• Ambigüedad de la licencia: Presencia de pesos de modelos «no comerciales» en las versiones de producción.

Shadow AI 2.0 no es un futuro hipotético, es una consecuencia predecible de un hardware rápido, una distribución fácil y la demanda de los desarrolladores. Los CISO que se centran únicamente en los controles de la red se perderán lo que sucede en el silicio que se encuentra en los escritorios de los empleados.

La siguiente fase de la gobernanza de la IA se trata menos de bloquear sitios web y más de controlar los artefactos, la procedencia y las políticas en el punto final, sin acabar con la productividad.

Jayachander Reddy Kandakatla es ingeniero senior de MLOps.

¡Bienvenido a la comunidad VentureBeat!

Nuestro programa de publicaciones invitadas es donde los expertos técnicos comparten conocimientos y brindan análisis profundos neutrales y no adquiridos sobre inteligencia artificial, infraestructura de datos, ciberseguridad y otras tecnologías de vanguardia que dan forma al futuro de las empresas.

Leer más de nuestro programa de publicaciones de invitados y consulte nuestro pautas ¡Si estás interesado en contribuir con un artículo propio!