La gobernanza de seguridad de IA de Microsoft se refuerza a medida que los agentes obtienen más control
Microsoft ha rediseñado sus normas de IA responsable a medida que los agentes obtienen más acceso, autonomía y alcance operativo en sus productos. El cambio en la gobernanza de seguridad de IA de Microsoft aborda un conflicto básico: los controles diseñados para chatbots no regulan automáticamente un software capaz de ejecutar acciones.
El Informe de Transparencia sobre IA Responsable 2026 de la compañía describe nuevos modelos de amenazas centrados en agentes, defensas contra la inyección de prompts, clasificadores de seguridad y una supervisión previa al lanzamiento más estricta. También amplía la gobernanza más allá de los modelos para abarcar las plataformas, herramientas, datos y aplicaciones que los rodean.
Ese alcance más amplio importa porque un agente puede enviar mensajes, recuperar registros, modificar documentos, invocar herramientas de software y delegar trabajo. Anthropic, OpenAI, Google y otros proveedores de modelos afrontan la misma transición: pasar de generar respuestas a ejecutar tareas.
La respuesta de Microsoft es más que una actualización de políticas. Representa una apuesta por que la seguridad de la IA debe convertirse en un sistema de control operativo, no en un documento revisado antes del lanzamiento.
La gobernanza de seguridad de IA de Microsoft ahora abarca toda la pila de agentes
Microsoft está trasladando su foco de seguridad de las salidas de los modelos a la cadena completa de acciones que puede realizar un sistema de IA.
La compañía afirma que ha rediseñado exhaustivamente su Estándar de IA Responsable. Ese estándar guía cómo Microsoft desarrolla, lanza y opera sistemas de IA en toda su actividad.
Según su informe de transparencia, el enfoque revisado abarca modelos, servicios de plataforma y aplicaciones. Las capacidades agénticas atraviesan todas las capas, en lugar de existir como una categoría de producto independiente.
Un agente de IA es un software que utiliza un modelo para planificar y completar tareas mediante herramientas, datos o entornos digitales. Su perfil de riesgo depende de más factores que las respuestas del modelo.
Un chatbot puede producir una respuesta inexacta. Un agente puede actuar basándose en esa respuesta antes de que una persona la revise.
Esa diferencia transforma lo que debe abarcar la gobernanza. Una empresa necesita examinar la identidad, los permisos, la memoria, las herramientas, los requisitos de aprobación y el historial de ejecución del agente.
Microsoft afirma que su estándar ahora incluye requisitos para capacidades agénticas durante todo el ciclo de vida de la IA. La compañía también introdujo nuevas prácticas de modelado de amenazas diseñadas en torno al comportamiento de los agentes.
El modelado de amenazas identifica cómo un sistema podría fallar, utilizarse indebidamente o sufrir un ataque. En el caso de los agentes, el proceso debe tener en cuenta actividades de múltiples pasos y condiciones cambiantes durante la ejecución.
Microsoft informa de varios cambios relacionados. Amplió las defensas contra la inyección de prompts, aumentó la cobertura de los clasificadores de seguridad, creó nuevas plantillas de transparencia y reforzó las capacidades de gobernanza de agentes.
La inyección de prompts se produce cuando contenido no confiable intenta anular las instrucciones de un agente. El ataque puede aparecer dentro de un documento, correo electrónico, página web o interfaz de software que el agente procesa.
Una inyección exitosa puede redirigir a un agente sin comprometer el modelo subyacente. Esto convierte a la arquitectura de la aplicación circundante en un elemento central de la seguridad.
Microsoft también describe un proceso centralizado de supervisión previa al lanzamiento. El proceso busca verificar que se hayan abordado los riesgos pertinentes antes de que un sistema esté disponible.
La compañía alinea este trabajo con cuatro funciones del Marco de Gestión de Riesgos de IA de NIST: gobernar, mapear, medir y gestionar. Estas funciones tratan la gestión de riesgos como un proceso continuo, en lugar de una revisión final antes del lanzamiento.
Microsoft afirma que impartió formación sobre IA responsable a casi 20.000 ingenieros, responsables de políticas y clientes. También revisó más de 100 leyes propuestas o promulgadas mientras actualizaba su estándar.
Más de 80 empleados de más de 30 equipos participaron en ese trabajo jurídico y de gobernanza. Estas cifras muestran la escala organizativa del esfuerzo, aunque no establecen si cada control funciona según lo previsto.
El cambio central sigue siendo claro. Microsoft ya no presenta la evaluación de modelos como protección suficiente para sistemas cada vez más autónomos.
El comportamiento de un agente surge de la interacción entre su modelo, instrucciones, permisos, herramientas, datos y entorno operativo. La gobernanza debe seguir toda esa cadena.
Por qué las acciones de los agentes plantean un problema de seguridad distinto
El problema más difícil comienza después de que un modelo genera una respuesta, cuando un agente convierte esa respuesta en una acción externa.
Los controles tradicionales de IA generativa suelen centrarse en el contenido. Los equipos prueban si un modelo produce instrucciones inseguras, respuestas sesgadas, información privada o afirmaciones inexactas.
Los sistemas de agentes añaden otra capa. Convierten las decisiones del modelo en llamadas a herramientas con consecuencias reales.
Un agente de atención al cliente podría consultar registros de cuentas, redactar respuestas o autorizar reembolsos. Un agente de programación podría modificar un repositorio, ejecutar comandos o abrir una pull request.
Un agente de oficina podría buscar en el correo, resumir reuniones, actualizar un documento y enviar mensajes a compañeros. Cada paso puede afectar a un sistema distinto con permisos separados.
El riesgo crece por composición. Una salida del modelo que parece inofensiva puede desencadenar una acción peligrosa cuando se combina con acceso amplio o validación incompleta.
El propio ejemplo de Microsoft para Agent Hooks ilustra este problema. Un agente ficticio de soporte emite reembolsos incorrectamente después de que un control de aprobación genere una excepción.
El marco circundante registra el error, pero continúa la ejecución. Una ruta de procesamiento por lotes independiente evita otro control porque la devolución de llamada esperada nunca se ejecuta.
La lección es estructural. Un control de seguridad no puede proteger una ruta de ejecución que nunca ve.
Por eso el trabajo reciente de Microsoft distingue entre observación y aplicación. Registrar la actividad de un agente ayuda a los investigadores, pero no necesariamente detiene una acción insegura.
Microsoft presentó Agent Hooks como un contrato abierto y neutral respecto a frameworks para insertar controles dentro de la ejecución de agentes. La especificación define cómo deben interactuar los frameworks y los componentes de gobernanza.
La versión inicial incluye kits de desarrollo de software para Python, TypeScript, .NET, Rust y Go. También incluye una suite de conformidad de 47 escenarios.
Las pruebas de conformidad verifican si un framework respeta el contrato en condiciones definidas. El objetivo declarado de Microsoft es hacer verificable el soporte en lugar de dejarlo como una mera afirmación de compatibilidad.
El contrato aborda varios modos de fallo. Los controles deben ver cada ruta de ejecución relevante, registrar evidencia y bloquear acciones cuando una política las deniegue.
Ese último requisito parece obvio, pero los frameworks de agentes a menudo evolucionaron a partir de herramientas de orquestación y observabilidad. Su gestión de errores puede favorecer la finalización de tareas por encima de una aplicación estricta.
Los agentes también crean riesgos de delegación. Un agente principal puede pedir a un subagente que complete parte de una tarea, lo que introduce otra identidad y ruta de ejecución.
Los reintentos añaden más complejidad. Una acción bloqueada podría volver mediante una ruta de recuperación que aplica una lógica de middleware o aprobación diferente.
Los trabajos en segundo plano y los procesos por lotes pueden comportarse de forma distinta a las sesiones interactivas. Un control conectado solo a un flujo de trabajo orientado al usuario puede pasar por alto esas rutas por completo.
La memoria crea otra superficie de ataque. El contexto almacenado puede conservar instrucciones falsas o datos sensibles más allá de la sesión en la que aparecieron por primera vez.
Estos riesgos explican por qué Microsoft describe la gobernanza como dinámica. Una prueba única del modelo no puede captar todos los permisos, herramientas, usuarios y fuentes de datos que se encuentran después del despliegue.
La posición de la compañía también refleja la amplitud de sus productos. Microsoft suministra modelos, infraestructura en la nube, aplicaciones de trabajo, sistemas de identidad, herramientas para desarrolladores y productos de seguridad.
Ese alcance ofrece a Microsoft puntos donde aplicar políticas en toda la pila. También da a la compañía responsabilidad sobre más conexiones donde los controles pueden fallar.
Para los compradores empresariales, la cuestión práctica ya no es si un agente produce una demostración aceptable. Es si el sistema desplegado se comporta de manera predecible en cada ruta hacia la acción.
La disyuntiva central es la capacidad frente al control aplicable
Microsoft quiere que los agentes completen tareas más amplias, pero cada permiso adicional dificulta una aplicación fiable de los controles.
Los productos de agentes se vuelven más útiles cuando pueden acceder al contexto relevante y tomar acciones significativas. Los permisos limitados reducen el riesgo, pero también pueden restringir el trabajo que un agente completa.
Los permisos amplios crean el problema opuesto. El agente puede terminar más tareas, pero los errores y ataques adquieren un impacto potencial mayor.
Esta tensión aparece en el ejemplo de Copilot Cowork de Microsoft. La compañía afirma que el sistema completa tareas laborales en Microsoft 365 mediante aprobaciones de usuarios, acceso basado en permisos, controles de seguridad y un despliegue gradual.
Un lanzamiento por fases limita la exposición mientras los equipos recopilan evidencia sobre el comportamiento. La aprobación del usuario coloca a una persona entre el plan del agente y las acciones seleccionadas.
Ningún mecanismo elimina el riesgo. Los usuarios pueden aprobar acciones sin comprender sus consecuencias, mientras que un lanzamiento por fases quizá no revele fallos que requieren condiciones inusuales.
El acceso con privilegios mínimos ofrece otro control. Concede a un agente solo los permisos necesarios para su tarea asignada.
Ese principio se vuelve difícil cuando las tareas son abiertas. Un agente al que se le pide preparar una actualización de proyecto podría necesitar correo, calendario, documentos, chat y registros de clientes.
También podría necesitar permiso para escribir en sistemas compartidos. Cada nueva conexión incrementa tanto la utilidad como el número de posibles rutas de fallo.
El marco más amplio de Microsoft para modelos de frontera aborda los riesgos de capacidades más graves. Su marco de gobernanza sigue preocupaciones relacionadas con riesgos químicos, biológicos, radiológicos, nucleares, cibernéticos, de autonomía, control y manipulación.
El marco evalúa indicadores adelantados como el razonamiento general, el razonamiento con contexto largo, la planificación, el uso de herramientas, el razonamiento científico y la ingeniería de software.
Los modelos que muestran indicadores relevantes reciben evaluaciones más profundas. Microsoft clasifica los riesgos resultantes como bajos, medios, altos o críticos.
La compañía afirma que los riesgos altos o críticos requieren revisión adicional y mitigaciones antes del despliegue. También se compromete a pausar el desarrollo y el despliegue cuando los riesgos identificados no puedan reducirse suficientemente.
Ese compromiso es significativo, pero depende de las evaluaciones internas y las decisiones de gobernanza de Microsoft. Las personas externas no pueden confirmar de forma independiente cada resultado de modelo o decisión de despliegue.
El marco de frontera también se concentra en amenazas a la seguridad nacional y pública. Los agentes empresariales generan muchos riesgos de menor escala que siguen siendo importantes para los clientes.
Un agente no necesita autonomía de nivel frontera para exponer un archivo confidencial, enviar un mensaje no autorizado o ejecutar una transacción incorrecta.
Esos fallos dependen en gran medida del contexto de despliegue. El mismo modelo puede presentar un riesgo bajo en una herramienta de redacción y uno mucho mayor cuando está conectado a software financiero.
Microsoft aborda esta distinción mediante una gobernanza por capas. Las evaluaciones de frontera cubren capacidades excepcionales, mientras que su estándar más amplio abarca productos, despliegues y operaciones continuas.
Su Agent Governance Toolkit de código abierto adopta otro enfoque. Proporciona componentes para la aplicación de políticas, la identidad de los agentes, controles de ejecución, fiabilidad, evidencia de cumplimiento y seguridad de plugins.
El kit de herramientas de gobernanza contiene siete paquetes para Python, TypeScript, Rust, Go y .NET. Microsoft afirma que el repositorio incluye más de 9.500 pruebas.
Un componente sitúa una decisión de política antes de la acción de un agente. Otro asigna identidades criptográficas a los agentes y respalda decisiones de confianza entre ellos.
El kit también incluye anillos de ejecución, gestión de transacciones, interruptores automáticos y un mecanismo de terminación de emergencia. Estas funciones retoman ideas consolidadas de los sistemas operativos y la ingeniería de fiabilidad de sitios.
Esa orientación de ingeniería es importante. La seguridad de los agentes no puede depender por completo de pedirle a un modelo que obedezca una regla en lenguaje natural.
Un prompt puede expresar una intención, pero un motor de políticas externo puede tomar una decisión determinista. Puede denegar una llamada a una herramienta prohibida incluso cuando el modelo la solicite.
La disyuntiva sigue sin resolverse. Los agentes más capaces requieren más vías de acceso a sistemas reales, mientras que más vías generan cargas adicionales de aplicación de controles.
La estrategia de Microsoft consiste en hacer que esas vías sean visibles, comprobables y gobernables. El valor de esa estrategia dependerá de cuán sistemáticamente la adopten los productos.
El marco de Microsoft aún enfrenta una brecha de aplicación
Las normas publicadas describen el sistema previsto, pero la seguridad depende de que los controles resistan la presión del producto, errores de integración y ataques desconocidos.
El informe de transparencia de Microsoft ofrece amplios detalles sobre los procesos de gobernanza. No proporciona evidencia pública completa para cada producto, modelo, control o incidente.
Esta distinción importa porque la gobernanza interna es, en parte, una autoevaluación. Microsoft desarrolla la tecnología, evalúa muchos riesgos, selecciona mitigaciones y decide cuándo puede avanzar el despliegue.
Las pruebas externas pueden reducir ese conflicto. La empresa afirma que ha ampliado sus alianzas de evaluación y utilizado un marco de pruebas externo para Copilot Health.
Consultó a más de 250 médicos con licencia de más de dos docenas de países antes de lanzar esa experiencia de salud. El trabajo abarcó claridad, utilidad y seguridad.
Ese caso demuestra un proceso de evaluación específico para el despliegue. No demuestra que un escrutinio independiente equivalente alcance a todos los productos de agentes.
La transparencia también se vuelve más difícil a medida que los sistemas ganan complejidad. Una sola aplicación puede combinar modelos de Microsoft, modelos de terceros, plugins, datos propietarios y políticas definidas por el cliente.
La responsabilidad puede fragmentarse a lo largo de esa cadena de suministro. Un proveedor de modelos podría documentar limitaciones, mientras un desarrollador de frameworks controla la ejecución de herramientas y un cliente asigna permisos.
Cuando ocurre un incidente, cada participante puede señalar otra capa. Por tanto, una gobernanza efectiva de la seguridad de la IA de Microsoft requiere una propiedad clara en todo el despliegue.
El marco de riesgos de NIST respalda esta visión del ciclo de vida. Trata la gobernanza como una función transversal y exige supervisión, revisión, documentación y responsabilidades definidas de forma continua.
NIST también señala que la revisión independiente puede mejorar las pruebas y reducir el sesgo interno. Ese principio establece un criterio útil para las futuras divulgaciones de Microsoft.
Los compradores deberían buscar evidencia de que los controles funcionan en condiciones de fallo. Un motor de políticas debe denegar una acción cuando una dependencia falla, agota el tiempo de espera o devuelve datos malformados.
Esto se conoce como fallar de forma segura. El sistema bloquea la actividad incierta en lugar de continuar porque un control dejó de estar disponible.
Agent Hooks se dirige directamente a ese requisito, aunque una especificación no puede garantizar una implementación correcta. Los mantenedores de frameworks deben integrarla y los equipos de aplicaciones deben configurarla adecuadamente.
Las pruebas de conformidad ayudan a revelar incompatibilidades. No pueden anticipar cada vía específica de una aplicación, plugin personalizado o error de política.
El rendimiento introduce otra presión. Los desarrolladores pueden omitir controles que añaden una latencia perceptible, generan falsos positivos o interrumpen flujos de trabajo habituales.
Los equipos de producto también enfrentan incentivos de adopción. Un agente que pide aprobación constantemente puede parecer menos útil que uno que actúa con rapidez.
El desafío de diseño resultante no es la restricción máxima. Consiste en aplicar controles más estrictos a las acciones de mayor impacto sin volver inutilizable el trabajo ordinario.
La regulación añade otra capa de presión. Las obligaciones de la Unión Europea para los modelos de IA de propósito general ya exigen documentación técnica e información para proveedores posteriores.
Las obligaciones para modelos de la Comisión Europea también abarcan políticas de derechos de autor y resúmenes públicos del contenido de entrenamiento. Se aplican requisitos adicionales a los modelos con riesgo sistémico.
Estas reglas se centran en gran medida en los proveedores de modelos. Los despliegues de agentes distribuyen el riesgo entre modelos, aplicaciones, herramientas y organizaciones.
El estándar ampliado de Microsoft intenta cerrar esa brecha. Su nuevo capítulo para implementadores establece requisitos para el uso de aplicaciones de IA de terceros dentro de Microsoft.
La empresa describe tres etapas operativas: evaluar al proveedor, gestionar los riesgos del despliegue y detectar y responder de forma continua tras el lanzamiento.
Este enfoque reconoce un hecho incómodo. Incluso un modelo bien probado puede volverse inseguro dentro de una aplicación mal diseñada.
La incertidumbre más importante no es si Microsoft ha redactado reglas detalladas. Es si los equipos pueden demostrar que esas reglas rigen cada vía de acción significativa.
Los clientes deberían pedir evidencia de controles, cobertura de evaluaciones, procesos de incidentes y registros de auditoría. Las garantías generales sobre IA responsable no son suficientes.
También deberían mantener sus propios inventarios. Una organización no puede gobernar agentes cuya existencia desconocen los equipos de seguridad y cumplimiento.
Para el trabajo intensivo en conocimiento, mantener una base de conocimiento de IA con capacidad de búsqueda puede mejorar la trazabilidad. Sin embargo, los controles de almacenamiento y recuperación deben seguir ajustándose a la sensibilidad de la información subyacente.
La brecha de aplicación solo se reducirá cuando la gobernanza se vuelva medible. Microsoft ha proporcionado más mecanismos, pero la evidencia en producción sigue siendo la prueba decisiva.
Los rivales de Microsoft convergen hacia una gobernanza basada en riesgos
Los principales proveedores de IA coinciden cada vez más en que el aumento de capacidades debe activar salvaguardas más estrictas, aunque sus umbrales y divulgaciones difieran.
Microsoft no está sola al utilizar reglas de seguridad basadas en capacidades. Anthropic mantiene una Responsible Scaling Policy desde 2023 y la ha revisado repetidamente a medida que cambiaban los modelos.
La política de Anthropic vincula umbrales de capacidad definidos con salvaguardas obligatorias. Sus materiales actuales abordan riesgos biológicos, riesgos cibernéticos e investigación autónoma de IA.
La empresa describe su política como proporcional, iterativa y apta para su adopción más allá de Anthropic. Su política de escalamiento también incluye un proceso de denuncia de incumplimientos y de protección contra represalias.
El Frontier Governance Framework de Microsoft sigue una estructura relacionada. Ambas organizaciones identifican capacidades de alto riesgo, evalúan modelos y conectan los resultados con protecciones más sólidas.
Los marcos no son idénticos. Utilizan definiciones, umbrales, prácticas de reporte y procesos organizativos distintos.
OpenAI y Google también han publicado enfoques de seguridad para la frontera de la IA. En conjunto, estas políticas muestran un consenso creciente en torno a la evaluación por etapas y el despliegue basado en riesgos.
La competencia ahora se refiere tanto a la implementación como a los principios. Los proveedores quieren lanzar productos más capaces mientras demuestran a gobiernos y clientes que las salvaguardas mantendrán el ritmo.
Microsoft tiene una posición distintiva porque opera en software de consumo, infraestructura empresarial, identidad, seguridad y plataformas para desarrolladores.
Esa integración ofrece una ventaja de gobernanza. Microsoft puede conectar las evaluaciones de modelos con controles de acceso, seguridad de endpoints, políticas de aplicaciones y sistemas de auditoría organizativa.
También genera preocupaciones de dependencia. Los clientes pueden pasar a depender de un solo proveedor para suministrar el agente, la capa de identidad, el motor de políticas, la supervisión y la evidencia de cumplimiento.
La decisión de Microsoft de lanzar Agent Hooks como una especificación neutral respecto a frameworks responde a esa preocupación. Su kit de gobernanza también es compatible con varios frameworks de agentes externos.
Las interfaces abiertas pueden hacer que los controles sean portables. También pueden ofrecer a los clientes una capa de políticas coherente cuando los equipos utilizan modelos y frameworks de distintos proveedores.
La portabilidad importa porque los entornos empresariales de IA rara vez permanecen uniformes. Una empresa puede utilizar Microsoft 365, Azure, un modelo de Anthropic, un agente de programación de OpenAI y software de orquestación de código abierto.
Un contrato neutral respecto a frameworks puede reducir el trabajo de integración duplicado. También puede aclarar qué componente debe aplicar cada decisión.
Sin embargo, una especificación abierta solo adquiere sentido cuando los frameworks competidores la implementan fielmente. Por tanto, la adopción fuera de los productos de Microsoft será una medida crítica.
Los reguladores también influyen en esta convergencia. Las normas de la Unión Europea exigen documentación, gestión de riesgos e intercambio de información en toda la cadena de suministro de IA.
Los estándares voluntarios de NIST proporcionan otro vocabulario común. Microsoft vincula explícitamente su proceso de gobernanza con las funciones de gobernar, mapear, medir y gestionar de NIST.
La terminología compartida puede simplificar las auditorías y las compras. No garantiza un rendimiento de seguridad equivalente entre proveedores.
Cada organización sigue eligiendo qué probar, cómo puntuar los resultados, qué riesgos residuales aceptar y qué información divulgar públicamente.
La presión competitiva puede reforzar la gobernanza cuando los clientes exigen evidencia creíble. Puede debilitarla cuando la velocidad de lanzamiento se convierte en la principal medida del éxito.
Esta es la competencia central del sector. El ganador no se limitará a ofrecer el agente más capaz.
Los clientes empresariales favorecerán sistemas que puedan demostrar una autonomía útil dentro de límites exigibles. Eso requiere que identidad, permisos, supervisión, aprobación, recuperación y responsabilidad funcionen de forma conjunta.
Microsoft está construyendo hacia ese modelo integrado. Los rivales la presionarán para demostrar que la integración produce algo más que coherencia normativa.
Qué observar mientras Microsoft pone sus reglas en producción
La próxima prueba es si Microsoft convierte su arquitectura de gobernanza en evidencia visible y repetible en productos y frameworks externos.
La primera señal es la documentación a nivel de producto. Microsoft debería mostrar cómo el Responsible AI Standard revisado cambia los lanzamientos de agentes individuales, los permisos, las evaluaciones y las respuestas a incidentes.
Las notas detalladas sobre los despliegues reforzarían la afirmación de la empresa de que la gobernanza acompaña todo el ciclo de vida de la IA. Las divulgaciones escasas dejarían a los clientes dependientes de garantías de alto nivel.
Los documentos más útiles identificarían categorías de evaluación, limitaciones conocidas, límites de aprobación, prácticas de supervisión y riesgos residuales. También deberían explicar qué sucede cuando falla un control.
Esa evidencia es relevante para los productos Copilot, los servicios de agentes de Azure, los agentes de programación y los sistemas que coordinan múltiples agentes. Cada contexto genera consecuencias diferentes.
La segunda señal es la adopción de Agent Hooks más allá del propio framework de Microsoft. El respaldo de importantes proyectos de orquestación validaría la demanda de un contrato común de aplicación.
La adopción por sí sola es insuficiente. Los marcos deben superar la suite de conformidad y preservar la aplicación de políticas en las rutas de ejecución interactivas, por lotes, de reintento y delegadas.
Los informes independientes sobre fallos de integración debilitarían la afirmación de Microsoft de que un contrato común resuelve el problema de la fragmentación. Los resultados de conformidad reproducibles la reforzarían.
La tercera señal es la transparencia ante incidentes. Microsoft afirma que la supervisión, los comentarios de los usuarios y las medidas correctivas siguen activos tras el despliegue.
Los lectores deberían observar si la empresa publica información significativa sobre los fallos de los agentes y las correcciones resultantes. Los incidentes reales revelan brechas que las evaluaciones de laboratorio no detectan.
Una cobertura útil distinguiría los errores del modelo de los fallos de permisos, el uso indebido de herramientas, la inyección de prompts y una lógica de aprobación defectuosa. Esa separación ayuda a los clientes a mejorar sus propios sistemas.
El marco de frontera de Microsoft también merece un escrutinio continuo. Los nuevos modelos con mayor autonomía, capacidades de planificación, ciberseguridad o ingeniería de software deberían activar evaluaciones más profundas.
La empresa ha prometido pausar el desarrollo y el despliegue cuando los riesgos no puedan reducirse lo suficiente. Cualquier uso futuro de ese compromiso supondría una prueba importante de la independencia de su gobernanza.
Los clientes no necesitan esperar esas señales para actuar. Pueden elaborar un inventario de los agentes desplegados, reducir permisos, separar las herramientas de alto impacto y exigir aprobación para acciones irreversibles.
También pueden probar las condiciones de fallo. Los equipos deberían interrumpir deliberadamente los servicios de políticas, enviar solicitudes de herramientas malformadas e inspeccionar si las acciones denegadas siguen denegadas.
Los registros deberían vincular una decisión de política con la acción que realmente se ejecutó. Los registros que solo capturan mensajes del modelo dejan vacíos importantes.
Las organizaciones deberían definir quién es responsable de un agente después de su lanzamiento. Los equipos de producto, seguridad, legal, datos y operaciones necesitan responsabilidades claras cuando cambia el comportamiento.
También deberían establecer procedimientos de apagado y recuperación. Una parada de emergencia solo es útil cuando las personas saben cuándo y cómo utilizarla.
La gobernanza de seguridad de la IA de Microsoft avanza en la dirección técnica correcta al tratar a los agentes como sistemas operativos para la acción, en lugar de interfaces de chat. Sus ideas más sólidas abarcan la aplicación de reglas en tiempo de ejecución, la identidad, los permisos y la evidencia.
La cuestión pendiente es si esas ideas resisten las condiciones desordenadas del software de producción. Los compradores deberían exigir pruebas en todas las rutas de ejecución antes de conceder a los agentes una autoridad más amplia.
