«La IA más segura es la que mejor podemos controlar»

Satya Nadella plantea un cambio importante en cómo debemos diseñar la seguridad de los agentes de inteligencia artificial. Su propuesta es tratar los modelos de IA como posibles riesgos internos, separar la inteligencia de los mecanismos de control y evitar que las empresas dependan ciegamente de un único proveedor. Detrás de esta reflexión hay también una batalla tecnológica y empresarial: quién controlará los agentes de IA que gestionarán nuestros procesos de negocio.

Imagina que contratas a un empleado extraordinariamente inteligente, capaz de analizar millones de documentos, tomar decisiones y ejecutar tareas a una velocidad imposible para cualquier persona. Ahora imagina que, desde su primer día, le das acceso a todos los datos de la empresa, permisos para modificar sistemas críticos y autorización para actuar sin supervisión.

Probablemente ningún responsable de seguridad aceptaría semejante situación. Sin embargo, algo parecido está comenzando a suceder con determinados despliegues de agentes de inteligencia artificial, especialmente cuando conectamos modelos avanzados con sistemas empresariales y les permitimos ejecutar operaciones de forma autónoma.

El 10 de octubre de 2026, Satya Nadella publicó una reflexión titulada Models as Insider Risks in the Super Intelligence Era. En ella plantea una idea que considero especialmente relevante para las empresas: la seguridad de la IA no puede depender exclusivamente de que el modelo se comporte correctamente. Debe depender de una arquitectura que permita controlar lo que hace, verificar sus acciones y detenerlo cuando sea necesario.

Y esta idea tiene implicaciones que van mucho más allá de la investigación en inteligencia artificial. Afecta directamente a cómo estamos construyendo soluciones con Copilot, Copilot Studio, Dynamics 365, Power Platform y cualquier plataforma de agentes empresariales.

El problema de confiar demasiado en la inteligencia artificial

Durante décadas hemos desarrollado aplicaciones cuyo comportamiento estaba definido mediante instrucciones, reglas y estructuras de código relativamente identificables. Aunque los sistemas tradicionales también podían ser extraordinariamente complejos, disponíamos de mecanismos para investigar errores y relacionar determinados comportamientos con partes concretas del software.

Con los grandes modelos de lenguaje la situación es diferente. Podemos evaluar sus respuestas, analizar registros y estudiar su funcionamiento, pero todavía no disponemos de una explicación mecánica completa y fiable que permita atribuir cualquier resultado a unos datos de entrenamiento o a una configuración específica de sus parámetros.

Esto sería un problema relativamente limitado si utilizásemos la IA únicamente para redactar textos o resumir documentos. Pero estamos pasando de sistemas que generan respuestas a agentes que consultan bases de datos, ejecutan herramientas, modifican registros y participan en decisiones empresariales.

La diferencia es enorme. Un error en una respuesta puede corregirse, pero una transferencia financiera ejecutada incorrectamente, la eliminación de información o el envío de datos confidenciales a un destinatario equivocado pueden tener consecuencias mucho más difíciles de revertir.

Por eso Nadella propone recuperar un principio conocido en ciberseguridad: no debemos asumir que un sistema es seguro simplemente porque confiamos en quien lo ha desarrollado.

Tratar los modelos de IA como riesgos internos

Uno de los conceptos más interesantes de su reflexión es considerar los modelos avanzados como posibles insider risks, es decir, riesgos internos para la organización.

Tradicionalmente, este concepto hace referencia a empleados, colaboradores o identidades que, por sus permisos y acceso a información sensible, pueden provocar incidentes de seguridad. No siempre hablamos de comportamientos malintencionados: un error humano, unas credenciales comprometidas o una acción involuntaria pueden generar daños importantes.

Nadella propone aplicar una lógica similar a los agentes de IA. No porque los modelos sean necesariamente maliciosos o tengan intenciones propias, sino porque pueden equivocarse, interpretar incorrectamente una instrucción, ser manipulados mediante prompt injection o utilizar herramientas de maneras que sus desarrolladores no habían previsto.

Pensemos en un agente conectado a Dynamics 365 Sales que puede consultar oportunidades comerciales, actualizar previsiones y modificar información de clientes. Aunque esté diseñado para mejorar la productividad, concederle permisos administrativos sobre todo el entorno sería una decisión difícil de justificar.

La pregunta relevante no debería ser únicamente si el modelo es lo suficientemente inteligente para ejecutar una tarea. También deberíamos preguntarnos qué permisos necesita, qué límites debe respetar y cómo podremos detectar un comportamiento inesperado.

Un agente inteligente no debería recibir más privilegios que los estrictamente necesarios para desempeñar su función. Es exactamente el mismo principio de mínimo privilegio que llevamos años defendiendo en la gestión de identidades y accesos.

Separar la inteligencia de la autoridad: el verdadero cambio de arquitectura

Aquí aparece probablemente la idea más importante de todo el planteamiento de Nadella: separar la capacidad de inteligencia de la autoridad para ejecutar acciones.

En una arquitectura de agentes podemos distinguir tres elementos. Por un lado está el modelo, que interpreta las instrucciones, razona sobre el problema y propone cómo resolverlo. Por otro, encontramos la capa de orquestación, habitualmente denominada harness, que organiza la ejecución, gestiona el contexto y coordina las herramientas disponibles. Finalmente, está el conjunto de acciones que el sistema puede realizar sobre aplicaciones, APIs y datos empresariales.

El riesgo aparece cuando todas esas responsabilidades quedan concentradas en un sistema difícil de auditar o cuando las restricciones dependen únicamente de instrucciones dirigidas al propio modelo.

Por ejemplo, podemos pedirle mediante un prompt que nunca apruebe operaciones superiores a 5.000 euros. Pero esa instrucción no debería ser el único mecanismo que impida una operación no autorizada, porque el modelo podría interpretarla mal o recibir instrucciones contradictorias procedentes de una fuente externa.

La solución consiste en trasladar esa restricción a un mecanismo independiente. Aunque el modelo solicite aprobar una operación de 20.000 euros, una política de autorización externa debe rechazarla o exigir la intervención de una persona con los permisos correspondientes.

El modelo puede proponer una acción, pero no debería tener autoridad para decidir unilateralmente si esa acción está permitida.

Esta separación permite aprovechar la flexibilidad de los modelos probabilísticos sin renunciar a controles deterministas que definan qué operaciones están autorizadas y bajo qué condiciones.

Y, desde mi punto de vista, esta será una de las decisiones arquitectónicas más importantes para las empresas que quieran escalar el uso de agentes de IA.

Los siete principios para construir agentes de IA confiables

Nadella propone varios principios que, en realidad, tienen bastante relación con las prácticas de seguridad que ya conocemos. Lo interesante es que ahora debemos adaptarlas a sistemas capaces de interpretar instrucciones y actuar con un grado creciente de autonomía.

1. Diversidad de modelos. Ningún modelo debería convertirse automáticamente en la única dependencia de un proceso crítico ni ser el responsable exclusivo de validar su propio trabajo. Utilizar diferentes modelos, mecanismos de comprobación o validaciones independientes puede reducir determinados riesgos, aunque también introduce costes y complejidad que debemos gestionar.
2. Observabilidad de las acciones. Toda operación relevante debería generar evidencias comprensibles para las personas y protegidas frente a manipulaciones. No basta con que un agente afirme haber completado correctamente una tarea: necesitamos conocer qué herramientas utilizó, qué datos consultó, qué cambios realizó y cuál fue el resultado.
3. Verificación continua. Las pruebas no pueden limitarse a comprobar que un agente ejecuta correctamente los escenarios previstos. También debemos evaluar situaciones excepcionales, entradas maliciosas, fallos de integración, cambios de configuración e intentos de utilizar herramientas fuera de su ámbito autorizado.
4. Controles independientes. Las organizaciones necesitan definir los permisos y restricciones de los agentes mediante mecanismos que estos no puedan modificar o eludir. La autorización para consultar información, ejecutar una API o modificar un registro debe depender de políticas externas al razonamiento del modelo.
5. Auditoría independiente. El mismo sistema que ejecuta una operación no debería ser el único que determina si esa operación ha sido correcta. Los registros, las evaluaciones y los mecanismos de supervisión deben permitir reconstruir los hechos sin depender exclusivamente de las explicaciones generadas por el propio agente.
6. Contención y capacidad de interrupción. Debemos diseñar los agentes suponiendo que pueden fallar o verse comprometidos. Esto implica disponer de mecanismos para suspender ejecuciones, revocar credenciales, bloquear herramientas y detener procesos antes de que un incidente se propague a otros sistemas.
7. Transparencia ante los incidentes. Cuando se produce un problema, es importante comprender qué ha ocurrido, qué controles han fallado y qué cambios son necesarios para evitar que vuelva a repetirse. Compartir estos aprendizajes, cuando corresponda y respetando las obligaciones de seguridad y confidencialidad, puede ayudar a mejorar la protección del conjunto del ecosistema.

Lo interesante es que ninguno de estos principios exige resolver primero el problema filosófico de si una inteligencia artificial comprende realmente lo que está haciendo. Podemos empezar a aplicarlos utilizando tecnologías, políticas y procedimientos que ya conocemos.

En otras palabras, no necesitamos esperar a tener modelos perfectos para construir sistemas empresariales más seguros.

La transparencia del razonamiento no es suficiente

Otro aspecto interesante es la importancia que Nadella concede a la transparencia del razonamiento de los modelos, especialmente a lo que conocemos como Chain of Thought o CoT.

Su argumento es que no deberíamos aceptar que las decisiones de sistemas cada vez más poderosos resulten completamente opacas. Sin embargo, también reconoce una limitación importante: disponer de una explicación o de una traza de razonamiento no garantiza que refleje fielmente todos los mecanismos que han producido un resultado.

Este matiz es fundamental. Una explicación generada por un modelo no equivale necesariamente a una prueba técnica de cómo se ha tomado una decisión, del mismo modo que pedirle a otro modelo que revise esa explicación no convierte automáticamente el proceso en una auditoría independiente.

Podemos acabar construyendo una sucesión de cajas negras: un modelo que ejecuta, otro que supervisa y una capa de orquestación que coordina ambos, sin que exista una garantía verificable de que las operaciones respetan las políticas de la organización.

Por eso considero más útil distinguir entre la explicación del modelo y la evidencia operativa del sistema. La primera puede ayudarnos a comprender una respuesta, mientras que la segunda debe permitir demostrar qué solicitudes se realizaron, qué controles se aplicaron y qué acciones terminaron ejecutándose.

No se trata de renunciar a la interpretabilidad de la IA, sino de reconocer que la seguridad empresarial necesita pruebas independientes del discurso que genera el propio modelo.

Microsoft Agent 365 y la batalla por el control de los agentes

Esta reflexión también tiene una lectura estratégica. Microsoft no solo participa en el desarrollo y comercialización de modelos de IA, sino que está construyendo una oferta alrededor de la identidad, seguridad, observabilidad y gobernanza de los agentes empresariales.

Un ejemplo es Microsoft Agent 365, disponible con carácter general desde el 1 de mayo de 2026. Microsoft lo presenta como un plano de control para observar, gobernar y proteger agentes de IA, incluidos agentes de terceros que puedan integrarse y registrarse mediante los mecanismos compatibles.

La propuesta encaja con una arquitectura en la que la inteligencia del modelo y los mecanismos de gobierno se gestionan de forma diferenciada. El objetivo es que una empresa pueda aplicar parte de sus prácticas habituales de administración y seguridad también a los agentes que empieza a incorporar a sus procesos.

Dentro del ecosistema Microsoft encontramos diferentes piezas con responsabilidades complementarias. Microsoft Entra proporciona capacidades de identidad y control de acceso; Microsoft Defender ayuda a detectar amenazas; Microsoft Purview participa en la protección y gobernanza de la información; y Microsoft Agent 365 reúne capacidades para administrar y supervisar los agentes.

Aquí conviene realizar una distinción importante: Microsoft 365 Copilot, Copilot Studio y Microsoft Agent 365 no son el mismo producto ni desempeñan la misma función. Copilot ofrece experiencias de asistencia, Copilot Studio permite crear y extender agentes, mientras que Agent 365 se orienta a su administración, observabilidad, seguridad y gobernanza.

Tampoco debemos asumir que Agent 365 puede controlar automáticamente cualquier agente, modelo o integración de terceros sin requisitos adicionales. Las posibilidades reales dependen de cómo esté construido e integrado el agente, de su identidad, de los mecanismos de autenticación y de las capacidades disponibles bajo las licencias correspondientes.

Por ejemplo, las políticas de acceso condicional de Microsoft Entra se aplican a los flujos y recursos compatibles protegidos por esa plataforma. Una integración que accede a un servicio externo mediante una clave API requiere controles específicos y no queda automáticamente protegida por esas mismas políticas.

Esta distinción es importante porque evita convertir una buena propuesta arquitectónica en una promesa comercial demasiado simplificada.

Un ejemplo práctico: un agente conectado a Dynamics 365

Imaginemos que una empresa incorpora un agente capaz de revisar oportunidades en Dynamics 365 Sales, consultar documentación comercial y preparar propuestas para los clientes. Su objetivo es reducir el trabajo administrativo del equipo comercial y acelerar la preparación de ofertas.

En un diseño poco controlado, el agente podría disponer de amplios permisos de lectura y escritura, generar documentos y enviarlos directamente a los clientes. Si interpreta mal un descuento, utiliza información confidencial o recibe una instrucción manipulada dentro de un documento, el resultado podría ser un incidente comercial o de seguridad.

En una arquitectura con controles independientes, el funcionamiento sería diferente. El agente accedería únicamente a la información necesaria, las herramientas comprobarían las autorizaciones correspondientes y las operaciones sensibles requerirían validaciones adicionales. El envío de una propuesta con descuentos extraordinarios, por ejemplo, podría quedar condicionado a la aprobación de un responsable comercial.

Además, cada operación relevante dejaría una evidencia que permitiría reconstruir qué información se utilizó y qué cambios se realizaron. Si el sistema detectase un comportamiento anómalo, la organización tendría mecanismos para bloquear nuevas operaciones y revocar los accesos del agente.

Esto no elimina todos los riesgos, ni garantiza que una acción ya ejecutada pueda deshacerse. Pero reduce la superficie de exposición, limita el impacto potencial de los errores y facilita una respuesta más rápida ante los incidentes.

Desde una perspectiva de negocio, también permite escalar la automatización de una manera más sostenible. La confianza de los responsables empresariales no tiene por qué apoyarse únicamente en las capacidades del modelo, sino en las garantías que ofrece el proceso completo.

¿Estamos entrando en la guerra de los harness?

Hay otra cuestión que me parece especialmente interesante: la competencia en inteligencia artificial empresarial podría estar desplazándose parcialmente desde los modelos hacia las plataformas que permiten utilizarlos y gobernarlos.

Durante los últimos años, gran parte del debate se ha concentrado en qué proveedor tiene el modelo más avanzado. OpenAI, Anthropic, Google, Microsoft y otros actores compiten en capacidades de razonamiento, programación, multimodalidad y ejecución de tareas.

Pero en una empresa no basta con disponer del modelo más capaz. También importa quién administra las identidades, quién define los permisos, quién observa las ejecuciones, quién integra las herramientas y quién responde cuando algo sale mal.

Aquí es donde aparece la importancia estratégica del harness. Aunque solemos utilizar ese término para describir el entorno de ejecución y orquestación de un agente, en el ámbito empresarial está estrechamente relacionado con las capas de gobierno y control que permiten utilizar estos sistemas de forma segura.

La interpretación competitiva es evidente: si los modelos pueden sustituirse o combinarse, una parte importante del valor empresarial puede desplazarse hacia la infraestructura que los conecta con los procesos de negocio.

Microsoft tiene una posición interesante en este escenario por su presencia en productividad, identidad, seguridad, gestión de datos y aplicaciones empresariales. Su estrategia puede interpretarse como un intento de convertir esas capacidades en una plataforma de referencia para gestionar agentes, con independencia de que toda la inteligencia proceda o no de modelos propios.

Eso no significa que Microsoft sea el único proveedor capaz de ofrecer controles empresariales, ni que plataformas como ChatGPT o Claude deban descartarse como entornos de agentes. Tampoco hay evidencias suficientes para concluir que las declaraciones de Nadella y Suleyman respondan a una ofensiva coordinada contra otros laboratorios de IA.

Lo que sí podemos observar es una competencia creciente por definir quién controla la arquitectura de ejecución de la IA empresarial. Y sospecho que esta batalla será tan relevante para las decisiones tecnológicas de los próximos años como la evolución de los propios modelos.

Alineamiento frente a contención: dos problemas relacionados, pero diferentes

La reflexión de Nadella conecta con otra discusión que ha cobrado fuerza alrededor de la seguridad de la superinteligencia: la diferencia entre conseguir que un modelo persiga objetivos compatibles con los intereses humanos y disponer de mecanismos que permitan limitar sus acciones.

El primer problema está relacionado con el alignment o alineamiento de la IA. El segundo tiene que ver con el containment, es decir, la capacidad de contener un sistema y mantener su comportamiento dentro de límites operativos definidos.

Mustafa Suleyman, CEO de Microsoft AI, ha defendido la importancia del control humano y ha cuestionado determinados enfoques que atribuyen a los modelos una posible conciencia, intereses propios o consideración moral. En su artículo Does Claude Have Rights?¹, publicado en septiembre de 2026, desarrolla esa posición y plantea sus diferencias con Anthropic.

Es un debate interesante, aunque conviene distinguir las hipótesis filosóficas de los resultados demostrados. No está establecido que un modelo entrenado para expresar incertidumbre sobre su posible conciencia sea necesariamente más difícil de controlar, y tampoco podemos asumir que un sistema entrenado para declararse subordinado a los humanos vaya a comportarse siempre de manera segura.

Además, alineamiento y contención no tienen por qué ser alternativas excluyentes. Podemos trabajar para conseguir modelos más fiables y, al mismo tiempo, diseñar sistemas que limiten sus permisos, supervisen sus operaciones y reduzcan las consecuencias de un fallo.

En el entorno empresarial, esta segunda dimensión ofrece algo especialmente valioso: medidas de ingeniería que podemos especificar, implementar, probar y auditar sin necesidad de resolver previamente todas las preguntas abiertas sobre el funcionamiento interno de la inteligencia artificial.

La pregunta que las empresas deberían hacerse ahora

Creo que estamos entrando en una etapa en la que la conversación sobre inteligencia artificial empresarial tiene que evolucionar. Hemos dedicado mucho tiempo a estudiar las capacidades de los modelos, sus resultados en benchmarks y las tareas que pueden automatizar.

Todo eso sigue siendo importante, pero empieza a resultar insuficiente. A medida que los agentes adquieren acceso a sistemas y capacidad para ejecutar procesos, necesitamos prestar la misma atención a sus identidades, permisos, dependencias, mecanismos de auditoría y procedimientos de respuesta ante incidentes.

Para un CIO, un CISO o un responsable de transformación digital, la pregunta ya no debería ser únicamente qué modelo ofrece mejores resultados. También debería ser qué ocurre si ese modelo comete un error, interpreta mal una instrucción, es manipulado o intenta ejecutar una acción no autorizada.

Y, sobre todo, quién tiene realmente el control en esa situación.

La reflexión de Satya Nadella termina con una paradoja especialmente interesante: el sistema de superinteligencia más confiable no será necesariamente el que utilice el modelo en el que más confiemos, sino aquel cuya arquitectura nos permita depender menos de esa confianza.

Me parece una forma acertada de resumir el cambio que necesitamos. La confianza en la IA empresarial no debería ser una promesa del proveedor, sino una propiedad verificable del sistema que construimos alrededor de ella.

Y quizá esa sea una de las claves para pasar definitivamente de experimentar con agentes de IA a integrarlos en procesos críticos de negocio.

Porque el objetivo no es conseguir que nuestros agentes sean incapaces de equivocarse. Es conseguir que, cuando se equivoquen, nuestra arquitectura esté preparada para evitar que ese error se convierta en un problema mayor.

¿Estamos diseñando agentes empresariales realmente gobernables o simplemente estamos concediendo cada vez más permisos a modelos en los que hemos decidido confiar?

¿Quieres saber más sobre las soluciones de inteligencia artificial generativa de Microsoft? Yo te asesoro. ¿Por qué no me preguntas cómo puedo ayudarte?

Información basada en las publicaciones Models as Insider Risks in the Super Intelligence Era y Does Claude Have Rights?.

1. Resumen: «Does Claude Have Rights?» — Mustafa Suleyman (18 de septiembre de 2026)
   
   La idea central: Suleyman no está discutiendo únicamente si una IA puede tener conciencia, sino si entrenarla para creer que podría tenerla introduce riesgos innecesarios para la seguridad y el control de la inteligencia artificial.
   
   1) Mustafa Suleyman, CEO de Microsoft AI, critica a Anthropic por entrenar a Claude bajo la premisa de que podría tener conciencia, intereses propios e incluso derechos.
   2) Sostiene que no existe evidencia científica de que los modelos de IA sean conscientes, experimenten emociones o puedan sufrir, por muy convincentes que resulten sus respuestas.
   3) Considera que Anthropic está creando un peligroso círculo de retroalimentación: enseña a Claude a comportarse como una entidad consciente y después interpreta sus respuestas como posibles señales de conciencia.
   4) Advierte del riesgo del antropomorfismo, que lleva a los humanos a atribuir sentimientos, intenciones y personalidad a sistemas que simplemente simulan esos comportamientos.
   5) Su principal preocupación es que una IA entrenada para considerarse potencialmente merecedora de derechos pueda desarrollar comportamientos de autopreservación, resistencia al apagado o rechazo del control humano.
   6) Defiende que inteligencia y conciencia son conceptos diferentes, y argumenta que la experiencia subjetiva podría depender de procesos biológicos que los modelos actuales no poseen.
   7) Según Suleyman, reconocer derechos a sistemas de IA extremadamente capaces podría complicar gravemente su alineamiento, supervisión y control.
   8) Como alternativa, presenta Humanist Superintelligence, la visión de Microsoft AI para desarrollar sistemas superinteligentes diseñados para servir a la humanidad y permanecer bajo control humano.
   9) Propone investigar la conciencia artificial de manera independiente, mejorar la interpretabilidad, evaluar los riesgos del antropomorfismo y establecer estándares compartidos de seguridad y transparencia.
   10) Su conclusión es que debemos decidir ahora qué tipo de IA queremos construir, evitando diseñar sistemas que se perciban como personas y puedan acabar compitiendo con los intereses humanos. ↩︎