Microsoft publicó el 4 de septiembre de 2026 unas directrices para proteger la inteligencia artificial perimetral (Edge AI), advirtiendo que trasladar la ejecución de los modelos a dispositivos, pasarelas o entornos locales propiedad de los clientes no solo cambia el lugar donde se procesan los datos, sino que también redistribuye la responsabilidad sobre la confianza y la seguridad. En este modelo, los pesos de los modelos, los datos de los clientes, las credenciales y la capacidad de influir en sistemas reales pueden encontrarse dentro de una infraestructura que el proveedor del modelo no controla directamente.
Microsoft define Edge AI como la ejecución de inferencias en el dispositivo o cerca de él, donde se producen los datos y se utilizan para tomar decisiones, en lugar de depender por completo de un servicio en la nube centralizado. Las organizaciones pueden elegir este enfoque por razones relacionadas con el coste, la elección del modelo, la soberanía de los datos, la reducción de la latencia o la capacidad de operar cuando se interrumpe la conexión.
¿Qué cambia en el modelo de confianza?
En los servicios de inteligencia artificial en la nube, la propiedad del hardware y de la plataforma, los pesos de los modelos y la demostración de su estado suelen estar distribuidos entre proveedores que pueden ofrecer evidencias uniformes sobre el entorno. En cambio, en Edge AI, el cliente gestiona una parte mayor de la pila, lo que significa que debe verificar el hardware, el firmware, el entorno de ejecución, el modelo y los componentes integrados antes de permitirles acceder a activos sensibles.
Los riesgos aumentan porque el propio entorno puede contener el modelo, los datos, las claves y los medios de acceso a sistemas físicos. Entre los posibles vectores de ataque se incluyen la inyección de instrucciones, la manipulación del modelo, la modificación del firmware, el envenenamiento de los datos de recuperación, la configuración de herramientas y la cadena de suministro del modelo. En las operaciones Edge separadas de la red, no siempre es posible depender de una detección directa desde la nube, de actualizaciones inmediatas de las políticas o de una revocación centralizada de permisos.
Cuatro pilares para la verificación antes de la liberación
- Demostración del entorno de ejecución: debe comprobarse que el entorno de ejecución sea medible, capaz de informar sobre su estado y compatible con una línea base aprobada.
- Demostración del origen de los componentes: deben verificarse los pesos del modelo, las definiciones de las herramientas, las definiciones de los agentes, los índices de recuperación y su proceso de construcción y entrega.
- Mediación determinista de las acciones: el modelo debe recomendar la acción, no autorizarla directamente. Una capa externa al modelo debe aplicar una lista de permitidos, restringir los parámetros, controlar la frecuencia y liberar las credenciales conforme a una política definida.
- Vinculación de los activos sensibles con el entorno confiable: las claves, los datos o los pesos de los modelos no deben entregarse hasta reunir las evidencias requeridas y superar la política de verificación.
La demostración por sí sola no basta
Microsoft explica que la demostración del entorno de ejecución y la demostración del origen de los componentes abordan dos preguntas distintas. Un entorno de ejecución aceptable puede cargar un componente contaminado, mientras que un componente confiable puede ejecutarse en una plataforma comprometida. Por ello, ambas evidencias deben combinarse, realizando un seguimiento de la cadena de demostración desde el proceso de construcción y distribución hasta el hardware que acepta el verificador.
La computación confidencial puede respaldar este modelo cuando cubre todo el recorrido conforme al modelo de amenazas declarado de la plataforma. Un host con privilegios o una ruta de acelerador no protegida podrían leer los pesos, las claves o los datos después de descifrarlos. Sin embargo, protegerse del acceso del host no impide que el modelo ejecute una acción maliciosa mediante una interfaz autorizada; por eso, la mediación y las políticas independientes siguen siendo necesarias.
Asimismo, la liberación de activos no debería considerarse una decisión permanente. Las directrices proponen tratarla como un arrendamiento renovable que finaliza cuando las evidencias recientes dejan de coincidir con el estado aprobado. Estas evidencias pueden utilizarse para controlar la programación de cargas, el almacenamiento, la identidad y la disponibilidad de las credenciales.
¿Por qué no bastan los controles tradicionales de seguridad del software?
El software tradicional funciona conforme a código enviado por el desarrollador, mientras que el comportamiento de los sistemas de inteligencia artificial se ve afectado por las solicitudes, los datos de recuperación, las instrucciones de los agentes y las entradas en tiempo de ejecución. Por tanto, firmar los archivos ejecutables o comprobar la integridad del código no basta para proteger el sistema. La firma puede demostrar el origen de los datos, pero no demuestra que su contenido sea seguro para que lo interprete un modelo de inteligencia artificial.
Microsoft subraya que debe suponerse que se producirán inyecciones de instrucciones, ya sean directas o indirectas, y que las salidas del agente y las entradas de pantalla no constituyen una autorización por sí mismas. Además, el carácter no determinista del comportamiento limita la dependencia exclusiva de la detección mediante firmas o de las pruebas tradicionales. Por ello, deben establecerse límites deterministas en los puntos de autoridad, exigiendo una aprobación independiente, un mecanismo de separación o un comportamiento seguro para las acciones de consecuencias graves o irreversibles.
¿Qué significa esto para las organizaciones?
En la práctica, la organización debe cartografiar los activos sensibles, los entornos de ejecución, los componentes a los que acceden y la entidad responsable de cada decisión de liberación. También debe definir las evidencias requeridas en cada límite de confianza y mantener visibles los cambios locales como una desviación en las mediciones, en lugar de adoptarlos silenciosamente como una nueva línea base.
Lectura editorial de certi.news: el valor principal de estas directrices es que trasladan la seguridad de Edge AI de la protección del modelo como archivo a la gestión de toda la cadena de confianza, desde el hardware hasta las acciones que el sistema pueda ejecutar. Sin embargo, no ofrecen garantías de que toda acción permitida por la mediación sea segura ni eliminan la necesidad de controles físicos y de una revisión independiente de las operaciones de alto riesgo. Por ello, la pregunta abierta para cada despliegue local sigue siendo: ¿qué evidencia demuestra que el entorno, los componentes y la política actuales justifican liberar ahora el activo sensible?