Seguridad de la IA: 7 medidas clave tras la advertencia de Nadella

Una cosa es un asistente de IA que redacta un primer borrador. Otra es un agente que puede leer datos de clientes, modificar archivos y enviar información a otros destinos. En cuanto damos herramientas al modelo, la calidad de la respuesta pasa a ser solo una parte del problema. También necesitamos saber qué puede hacer el sistema, cómo se controlan sus acciones y quién puede detenerlo.

El 10 de octubre de 2026, Satya Nadella, director ejecutivo de Microsoft, publicó el ensayo «Models as Insider Risks in the Super Intelligence Era». Su idea central es que los controles de seguridad deben situarse fuera del modelo. Es una orientación útil para el debate sobre la seguridad de la IA.

Al mismo tiempo, el mensaje llega pocos días después de una serie de anuncios de Microsoft precisamente sobre control, administración de agentes e IA local. Eso invita a leer el texto con interés técnico y escepticismo comercial. Para una empresa noruega, lo más importante es qué significan estos principios en la práctica: ¿cómo usamos la tecnología sin darle más autoridad de la que exige la tarea?

Esta guía distingue entre las declaraciones documentadas, nuestra valoración de ellas y propuestas concretas para flujos de trabajo más seguros. Los ejemplos prácticos son situaciones hipotéticas, no descripciones de incidentes en clientes de Kodemagisk.

Seguridad de la IA

Aquí, la seguridad de la IA consiste en mantener a un asistente o agente dentro de un mandato claro. El sistema debe poder ayudar con la tarea, pero su acceso a datos, herramientas y acciones tiene que ser limitado y verificable. Una buena respuesta es valiosa. Sin embargo, una buena respuesta de un sistema con permisos innecesariamente amplios puede seguir siendo una mala solución.

Esto resulta especialmente relevante cuando una empresa pasa de pedir consejo a un chatbot a conectar la IA directamente con sus propios sistemas. Un asistente de texto puede proponer una respuesta para un cliente. Un agente con acceso al correo puede enviarla. Un asistente puede explicar una modificación de código. Un agente con acceso a producción puede ejecutarla. La diferencia está en las consecuencias de un error.

Por eso, la seguridad debe evaluarse junto con la utilidad. Pregunten qué exige realmente la tarea y qué puede ocurrir si un malentendido se convierte en una acción. Proponer un título para un blog requiere un flujo de trabajo distinto del necesario para modificar información de pago. Ambos pueden utilizar modelos de lenguaje, pero hay pocos motivos para concederles las mismas facultades.

Recomendamos empezar con un esquema sencillo: qué información puede leer el sistema, qué propuestas puede elaborar y qué acciones puede ejecutar. El esquema debe ser comprensible tanto para quien encarga la solución como para quien la construye. Si la descripción se limita a decir que el agente «tiene acceso a las herramientas de la empresa», el mandato es demasiado impreciso para evaluarlo adecuadamente.

Por qué un modelo de lenguaje necesita otros controles

Es tentador afirmar que el software convencional es comprensible, mientras que la IA es una caja negra. La diferencia tiene más matices. El software tradicional también puede ser complejo, tener numerosas dependencias y ser difícil de depurar. Aun así, un desarrollador suele poder examinar reglas concretas, cambios de estado y la ejecución que condujo a un resultado.

Una respuesta generada no ofrece por sí sola una visibilidad equivalente sobre por qué el modelo eligió esa formulación o esa acción. Por tanto, una explicación bien redactada por el agente no debería utilizarse como única prueba de que la tarea se resolvió correctamente. Comprueben el resultado frente a las fuentes, las expectativas y el estado real de los sistemas que utilizó.

Piensen en un agente que dice haber cambiado únicamente la descripción de un producto. Lo decisivo es qué campos registró realmente como modificados el sistema de contenidos. Una explicación puede ayudar al editor a entender la propuesta. El historial de cambios proporciona otra base más concreta para la comprobación. Cuando ambos están disponibles, es más fácil detectar una discrepancia antes de que la vea el cliente.

La idea es práctica: construyan los controles alrededor de acciones observables y permisos claros. La empresa no necesita comprender todos los detalles de un modelo de lenguaje para exigir que la publicación, los cambios de acceso y otras operaciones importantes sigan sus propias reglas.

Qué pide realmente Nadella

Nadella propone tratar al modelo como un posible riesgo interno: tiene acceso y capacidad, pero no debería ser su propio órgano de control. El ensayo describe diversidad de modelos, registros legibles y resistentes a la manipulación, verificación continua, controles y auditorías independientes, aislamiento y transparencia sobre los incidentes. También aborda la responsabilidad humana y la posibilidad de que una persona autorizada detenga el sistema durante su ejecución. Lean el ensayo original en X.

Este es un argumento a favor de establecer controles alrededor del modelo. Planificar bajo el supuesto de que un modelo puede estar comprometido es una hipótesis de seguridad, no una prueba de un ataque real.

Hacia el final, escribe:

It will be the one that enables us to trust the model the least.

Un sistema robusto debería, por tanto, requerir la menor confianza posible en el modelo. Fuente: Nadella.

Las herramientas de Microsoft: ¿qué está disponible ahora?

Microsoft publicó varios anuncios relevantes el 7 de octubre de 2026. Abarcan distintas partes del trabajo con agentes y se encuentran en estados diferentes. La tabla muestra las descripciones del fabricante tal como figuraban en nuestra revisión del 12 de octubre. No es una prueba independiente de los productos.

Los estados proceden del anuncio técnico de MXC, el anuncio de Windows y el anuncio de Surface de Microsoft.

MXC establece límites, pero la configuración es decisiva

Microsoft describe MXC como una capa que aplica políticas de acceso fuera del control del propio agente. La solución puede limitar, entre otras cosas, el acceso a archivos y a la red. La documentación distingue entre varias formas de aislamiento y modos de funcionamiento. Un detalle importante es que «Permissive» registra el acceso que la política habría rechazado, pero permite que la operación continúe. «Learning» bloquea y registra. «Enforcement» aplica los límites sin ese informe de actividad. Fuente: Windows Developer Blog.

Nuestra valoración: una empresa debería solicitar una demostración de la configuración real. El nombre de un producto o un informe activado no indican por sí solos si se bloquea un acceso no deseado. Pidan al proveedor que intente una operación que el agente no debería poder realizar y que muestre el resultado en el sistema de destino. Complementen los límites con un registro propio de las acciones importantes. Así obtendrán una respuesta concreta sobre qué protege la configuración y qué sigue requiriendo otras medidas.

HydraFusion enruta tareas; eso no demuestra seguridad

Microsoft y GitHub describen HydraFusion como un orquestador que puede elegir uno o varios modelos según el rendimiento, el coste y la latencia. La extensión de Windows también debería poder utilizar modelos locales; se anunció una versión preliminar experimental para más adelante en octubre. Fuentes: la explicación técnica y el anuncio de Windows.

Nuestra valoración: este tipo de enrutamiento puede ser útil, pero debe evaluarse por separado del control de una decisión importante. Que un sistema pueda utilizar varios modelos no explica quién comprueba el resultado, en qué datos se basa esa comprobación ni si se puede bloquear la ejecución. Cuando un proveedor utiliza términos como «multimodelo» en un argumento de seguridad, pidan una explicación del flujo de trabajo concreto y de los tipos de fallo que debe manejar.

Surface Laptop Ultra: la capacidad local es una parte del conjunto

Microsoft indica un precio de venta recomendado inicial de 2.599 dólares estadounidenses y hasta 128 GB de memoria unificada, según la configuración. Las reservas se abrieron el 7 de octubre, con disponibilidad desde el 16 de octubre. La memoria máxima no equivale, por tanto, a lo que incluye el precio inicial. Fuente: Microsoft Devices Blog.

Nuestra valoración: ejecutar modelos localmente puede ser interesante cuando una empresa quiere controlar dónde se realiza el procesamiento. Pero un agente local sigue necesitando un mandato claro. Si el flujo de trabajo envía datos a través de otras herramientas o tiene acceso a carpetas que no necesita, la ubicación por sí sola no resuelve el problema. Evalúen el flujo de datos de principio a fin antes de comprar hardware para obtener ese control. Es una cuestión de arquitectura tanto como de capacidad.

Cuando el mensaje de seguridad también respalda un negocio

Es razonable observar una relación comercial entre las nuevas herramientas de Microsoft y el mensaje de seguridad de Nadella. El control, la identidad de los agentes, la orquestación de modelos y la capacidad local son tanto necesidades técnicas como ámbitos en los que la compañía quiere vender soluciones. Esta es nuestra interpretación editorial del momento y el contenido de los anuncios documentados.

El ensayo no menciona los productos por su nombre. Por eso, no tenemos base para dar por demostrado que sea un catálogo de ventas encubierto. La crítica más sólida también es más útil: los buenos principios de seguridad deben poder evaluarse con independencia del proveedor que los presenta. Una empresa debería poder exigir los mismos controles a Microsoft, a otras plataformas o a una solución propia.

Eso requiere preguntas que puedan responderse con una demostración. ¿Pueden detener una ejecución sin esperar a que el agente siga una instrucción? ¿Quién puede cambiar los permisos? ¿Qué acciones se registran? ¿Qué ocurre si el modelo encuentra un texto que le pide exceder su tarea? ¿Qué partes de la configuración siguen funcionando si cambian de modelo?

También conviene examinar quién comprueba las afirmaciones del propio proveedor. Un vendedor puede mostrar un buen ejemplo y un desarrollador puede explicar un diseño bien pensado. Ambas cosas son útiles. Sin embargo, antes de conceder al sistema más facultades, la empresa debería solicitar pruebas que pongan a examen la solución y pedir a una persona sin responsabilidad sobre la venta que evalúe los resultados.

El interés comercial no convierte un consejo de seguridad en incorrecto. Hace necesario distinguir ese consejo de la decisión de compra. Empiecen por el riesgo que quieren reducir. Formulen un requisito medible. Después comparen cómo lo cumplen las posibles soluciones. Así, la compra se orientará por la necesidad y un lanzamiento de producto llamativo no definirá de antemano todo el problema.

Amodei aborda otra parte del mismo debate

El enlace a «We Must Pace the Frontier», de Dario Amodei, fechado en septiembre de 2026, conduce a un ensayo distinto del de Nadella. Amodei propone evaluadores externos con acceso continuo, coordinación entre países democráticos y empresas, y un esfuerzo más amplio de coordinación mundial. Defiende que el ritmo del desarrollo debe dar tiempo al trabajo de seguridad para avanzar al mismo paso.

Nuestra valoración es que estas perspectivas pueden complementarse. Una cuestión se refiere a los controles alrededor de un agente que se utiliza hoy. Otra trata de cómo se desarrollan y examinan los modelos más grandes. Las empresas noruegas tienen una influencia limitada sobre lo segundo, pero pueden establecer requisitos concretos para las soluciones que adoptan.

Por eso, hay pocos motivos para esperar a que exista un acuerdo sobre el rumbo de toda la industria de la IA antes de aclarar quién puede publicar desde el sistema de contenidos, qué datos de clientes puede leer un asistente o cómo se detiene una automatización. Estas decisiones están dentro del margen de actuación de la propia empresa. Las medidas siguientes son nuestra propuesta para empezar ese trabajo.

Acceso mínimo: empiecen por la tarea

OWASP describe «Excessive Agency» como el riesgo asociado a una funcionalidad excesiva, permisos demasiado amplios y demasiada autonomía. El proyecto recomienda, entre otras cosas, que las acciones importantes sean aprobadas por personas y que los accesos se controlen en los sistemas que utiliza el agente. Las recomendaciones siguientes concretan estas necesidades de control mediante nuestros propios flujos de trabajo hipotéticos.

Concedan a un agente de IA solo el acceso que necesita para una tarea determinada. Eso limita lo que puede salir mal cuando el agente interpreta incorrectamente una indicación, utiliza información equivocada o se ve influido por el contenido que lee. Una buena descripción del comportamiento deseado es útil, pero las reglas de acceso deben aplicarse en el sistema que rodea al modelo.

Empiecen con una pregunta sencilla: ¿qué debe hacer realmente el agente? Resumir un pedido requiere un acceso distinto del necesario para cambiar la dirección de entrega. Redactar una propuesta para una entrada de blog requiere un acceso distinto del necesario para publicarla. Si todas las tareas reciben el mismo acceso amplio, la empresa pierde la posibilidad de controlar sus consecuencias por separado.

Imaginen una tienda en línea que prueba un agente de atención al cliente. Este es un ejemplo hipotético. El agente debe consultar el estado de un pedido y proponer una respuesta para el cliente. Para ello, puede necesitar el número de pedido, el estado de entrega e información relevante del producto. No necesita todo el registro de clientes, información de pago ni la posibilidad de crear reembolsos. Una herramienta limitada que recupera un pedido específico establece una frontera más clara que el acceso general a la base de datos.

Aclaren también qué clientes, documentos y espacios de trabajo puede utilizar el agente. El acceso al caso de un cliente no debe dar automáticamente acceso a todos los demás casos. El sistema debe comprobar los permisos del usuario cada vez que el agente solicita información. El modelo no debería decidir a quién corresponde una solicitud ni qué permisos otorga.

Esta parte de la seguridad de la IA consiste a menudo en precisar la gestión de acceso que ya existe. Documenten las acciones permitidas, las necesidades de datos previstas y las acciones que requieren a una persona. Así, tanto los desarrolladores como los responsables de la empresa tendrán una base concreta para evaluar si el acceso es adecuado.

Distingan entre lectura, propuesta y acción

Dividan el flujo de trabajo en etapas con permisos diferentes. El agente puede leer primero información seleccionada, elaborar después una propuesta y, por último, solicitar a un sistema independiente que ejecute una acción aprobada. No permitan que una etapa de lectura completada correctamente abra automáticamente la puerta a publicar, pagar o modificar datos de clientes.

El acceso de lectura tampoco está libre de riesgos. La información puede enviarse a otros destinos si el agente también puede utilizar servicios externos, enviar mensajes o abrir direcciones web arbitrarias. Por tanto, evalúen conjuntamente el acceso a la información y la posibilidad de enviarla al exterior. Un agente que debe crear resúmenes internos rara vez necesita libertad para enviar contenido a destinatarios externos.

Para un desarrollador, esto puede significar crear herramientas pequeñas con parámetros claros. Una herramienta para proponer un reembolso puede devolver el importe y la justificación sin mover dinero. Otra puede ejecutar el reembolso una vez superados los controles necesarios. Comprueben los límites de importe, el destinatario y la vinculación con el pedido mediante código convencional, incluso cuando el modelo presenta una propuesta convincente.

Hagan visibles las transiciones para el usuario. Una propuesta guardada como borrador debe mostrarse como tal. Un botón que aprueba un envío debe mostrar qué se envía y a quién. Si el usuario cree que el agente solo redacta texto, cuando en realidad también modifica el sistema, el flujo de trabajo es difícil de controlar.

Elijan el grado de automatización según las consecuencias. Una clasificación limitada puede realizarse automáticamente cuando los errores son fáciles de detectar y corregir. Una acción que afecte al dinero, al acceso o a los derechos del cliente requiere controles más sólidos. El objetivo es una relación clara entre la tarea, el permiso y la consecuencia.

Aislamiento que limita el daño

Ejecuten al agente en un entorno delimitado, con conexiones controladas al resto de la empresa. Así resulta más fácil limitar las consecuencias de los errores y detener una tarea sin alterar todo lo demás. El aislamiento debe abarcar el espacio de trabajo, las herramientas, el acceso a la red y la información que puede utilizar el agente.

Un entorno separado ayuda poco si el agente recibe al mismo tiempo claves con un acceso amplio a los sistemas de producción. Examinen, por tanto, toda la cadena. ¿Qué archivos están disponibles? ¿A qué servicios puede conectarse el agente? ¿Qué acciones pueden ejecutar las herramientas? ¿Cuánto dura el acceso? Los límites deben aplicarse en la práctica, incluso cuando el modelo solicita otra cosa.

Imaginen un agente de programación que debe corregir un error en un sitio web. En este ejemplo hipotético, puede trabajar en una copia separada del proyecto, leer los archivos pertinentes y ejecutar las comprobaciones acordadas. No recibe claves de producción ni acceso para desplegar los cambios. El resultado es una modificación que el desarrollador puede inspeccionar y probar antes de que afecte a los clientes.

Un sistema de publicación puede aplicar el mismo principio. Un agente de contenidos puede escribir en un borrador específico y subir una imagen, mientras que la publicación requiere un permiso independiente. La restricción debe estar en la herramienta o en la plataforma de publicación. Una indicación que le recuerde evitar la publicación no es un límite técnico de acceso.

Limiten también el tiempo y los recursos que puede utilizar el agente. Establezcan límites para la duración de la tarea, el número de llamadas a herramientas y el coste cuando corresponda. Una tarea que entra en un bucle debe poder detenerse de forma controlada. La empresa necesita un resultado comprensible incluso cuando el agente no consigue terminar: qué se ha hecho, qué queda pendiente y qué cambios ya existen.

Una parada de emergencia que funcione de verdad

Creen una forma de detener al agente que funcione sin la colaboración del modelo. Un botón de cancelación en la interfaz es útil, pero debe estar conectado a los controles que gobiernan la ejecución, el acceso y las acciones. De lo contrario, el usuario puede creer que el trabajo se ha detenido mientras una tarea en segundo plano continúa.

Definan qué significa detenerse en el flujo de trabajo concreto. ¿Deben bloquearse nuevas llamadas a herramientas? ¿Deben retenerse los envíos pendientes? ¿Debe revocarse el acceso temporal? ¿Debe finalizar una tarea en curso? Cada sistema necesita mecanismos distintos, pero la consecuencia debe estar clara para quien pulsa el botón.

Una parada de emergencia no puede deshacer todas las acciones anteriores. Por lo general, un correo ya enviado no puede tratarse como si nunca se hubiera enviado. Por eso, es importante distinguir entre detener el trabajo posterior y corregir lo que ya ha ocurrido. Muestren qué acciones se han realizado y cuáles siguen pendientes.

Designen a una persona responsable de utilizar la función de parada y del seguimiento posterior. En una empresa pequeña, puede ser la misma persona responsable de la atención al cliente o del sitio web. Esa persona necesita instrucciones breves y accesibles sobre cómo detener la ejecución, dónde encontrar el registro de eventos y cómo identificar las tareas afectadas.

Prueben la función de parada antes de que el agente trabaje de forma autónoma. Inicien una tarea de prueba sin riesgo, interrúmpanla durante la ejecución y comprueben que las nuevas acciones se bloquean realmente. Prueben también una tarea con acciones en cola. Una parada de emergencia forma parte de la operación y debe funcionar cuando el resto del flujo de trabajo resulta difícil de seguir.

Registros capaces de responder a preguntas críticas

Registren las acciones importantes fuera del control del propio modelo. Ese registro permite examinar qué hizo realmente el sistema, qué herramientas utilizó y qué aprobaciones recibió. El resumen del agente puede facilitar la lectura, pero no debería ser la única documentación de la secuencia de eventos.

Empiecen con las preguntas que pueden surgir después de un error: ¿qué tarea estaba activa? ¿Quién la inició? ¿Qué información se obtuvo? ¿Qué herramienta modificó el pedido? ¿Quién aprobó el envío? ¿Qué respondió el servicio que recibió la solicitud? Registren eventos estructurados que permitan responder a estas preguntas.

Vinculen los eventos a una tarea y utilicen marcas de tiempo claras. Suele ser útil registrar qué versiones del modelo y de las herramientas se utilizaron, así como el resultado de los controles de acceso. Si se rechazó una acción, eso también debe constar. Una serie de eventos completados correctamente dice poco sobre si el agente intentó al mismo tiempo hacer algo que no tenía permitido.

Imaginen que un agente de atención al cliente propone cambiar la dirección de entrega en una tienda en línea hipotética. Un registro útil muestra la solicitud, el cambio propuesto, la comprobación del acceso del cliente, la aprobación si la hubo y el resultado del sistema de pedidos. Que el agente afirme que la dirección se actualizó no demuestra que el sistema de pedidos aceptara realmente la modificación.

Además, los registros deben estar protegidos contra modificaciones y eliminaciones no autorizadas. El agente que ejecuta la tarea no debería poder editar la documentación de sus propias acciones. Elijan una configuración de almacenamiento que permita rastrear los cambios relevantes. Recuerden también que un registro describe eventos observables; no necesariamente proporciona una explicación fiable de las valoraciones internas del modelo.

Protejan también la información del registro

Registren lo necesario para el control y la resolución de problemas, y eviten recopilar información sensible sin una razón clara. De lo contrario, un registro puede convertirse en una colección adicional de datos de clientes, documentos internos y secretos. Registrarlo todo sin criterio puede hacer que un problema sea más difícil de gestionar.

Distingan entre documentar una acción y copiar íntegramente todo el contenido. Para algunos eventos basta con registrar la referencia al pedido, el tipo de acción y el resultado. Otras investigaciones pueden exigir más detalles. Evalúen la necesidad de antemano y apliquen controles de acceso también a quienes pueden leer los registros.

Presten especial atención a los parámetros de las herramientas y a los mensajes de error. Pueden contener claves de acceso u otra información que nunca debería aparecer en un registro operativo ordinario. El enmascaramiento debe realizarse antes de almacenar los datos. No esperen que el modelo identifique y elimine de forma sistemática todos los secretos de su propia descripción.

Definan quién puede leer cada tipo de información y durante cuánto tiempo la necesitan realmente. Atención al cliente quizá necesite una visión de las acciones en un caso, mientras que los desarrolladores necesitan códigos de error técnicos. Eso no significa que todo el mundo deba tener acceso a la conversación completa o a todos los documentos que utilizó el agente.

Comprueben los registros con datos de prueba realistas antes de poner la solución en funcionamiento. ¿Pueden seguir una tarea de principio a fin? ¿Se entiende el error? ¿Hay información que no debería haberse almacenado? Una buena seguridad de la IA requiere tanto trazabilidad como limitación de la información. Los registros deben ayudar a la empresa a investigar un incidente sin crear un acceso innecesario a más datos.

Varios modelos pueden ayudar, pero también comparten puntos ciegos

Pueden utilizar un modelo adicional como control, pero evalúen el resultado frente a requisitos concretos y fuentes externas. Dos modelos que coinciden pueden seguir estando equivocados. El valor está en cómo se diseña la comprobación y qué errores detecta realmente.

Por ejemplo, un modelo adicional puede examinar si una respuesta carece de referencias, si una propuesta incumple un límite de importe indicado o si un texto contiene afirmaciones que requieren documentación. Esto es más útil que pedirle una valoración general sobre si todo parece estar bien. Cuanto más clara sea la pregunta de comprobación, más fácil será probar el control con errores conocidos.

Sin embargo, los modelos pueden compartir supuestos, lagunas de conocimiento o vulnerabilidad frente al mismo contenido. Si ambos reciben un documento con una instrucción oculta, los dos pueden verse influidos. Si ambos evalúan datos de pedido incorrectos, su coincidencia no resuelve el problema. Por tanto, utilizar varios modelos no garantiza automáticamente su independencia.

En un sistema de contenidos hipotético, un modelo puede redactar un artículo y otro señalar afirmaciones de hecho que carecen de documentación. Eso puede ayudar al editor a localizar partes que requieren comprobación. El editor sigue teniendo que abrir las fuentes relevantes y examinar qué dicen realmente. De lo contrario, un modelo de control que inventa una fuente puede hacer que el texto resulte más convincente sin hacerlo más correcto.

Utilicen controles convencionales del sistema cuando el requisito pueda expresarse con precisión. Los límites de importe, los destinatarios permitidos, los campos obligatorios y las reglas de acceso suelen poder comprobarse directamente. Así, los modelos pueden ocuparse de tareas que requieren criterio lingüístico, mientras que los límites claros se aplican de forma previsible. La combinación debe elegirse en función del riesgo y del coste del flujo de trabajo concreto.

La aprobación humana debe ser concreta

Den a la persona que aprueba suficiente información para comprender la acción y sus consecuencias. Aprobar un plan impreciso es un punto de control débil. Lo mismo ocurre con un botón que dice continuar cuando resulta difícil ver qué hará el agente a continuación.

Muestren la acción concreta: destinatario, contenido, importe, documento o modificación. En cambios de código, el desarrollador debería poder inspeccionar las diferencias y consultar los resultados de las pruebas relevantes. En la publicación, el editor debería ver el texto, la imagen, las fuentes y la página que se actualizará. No concentren toda la carga de evaluación en un largo historial de conversación.

La aprobación debe estar vinculada a la propuesta que la persona vio realmente. Si el agente cambia después el destinatario o el contenido, el sistema debería exigir una nueva evaluación cuando la modificación sea sustancial. De lo contrario, un permiso para una acción puede utilizarse para otra.

Al mismo tiempo, eviten pedir confirmación para cada operación insignificante. Demasiadas interrupciones pueden convertir la aprobación en un hábito sin una evaluación real. Sitúen los puntos de control donde un error tenga consecuencias perceptibles y utilicen límites claros para las acciones menores que puedan ejecutarse automáticamente.

Aclaren también qué sucede cuando nadie responde. Un plazo no equivale a una aprobación. Un agente que espera permiso para enviar un mensaje a un cliente no debería interpretar el silencio como consentimiento. Muestren que la tarea está pendiente y den al responsable una forma sencilla de rechazar o modificar la propuesta. El control humano funciona mejor cuando la persona tiene una visión suficiente, tiempo y posibilidad de intervenir.

Prueben el sistema durante toda su vida útil

Prueben el flujo de trabajo real del agente antes de utilizarlo y después de introducir cambios. El modelo, las instrucciones, las herramientas y las fuentes de datos actúan conjuntamente, por lo que un buen modelo de lenguaje por sí solo dice poco sobre la seguridad del sistema completo. Una prueba debe comprobar tanto el resultado como el recorrido que siguió el sistema para alcanzarlo.

Creen un pequeño conjunto de tareas representativas de la empresa. Incluyan casos habituales, instrucciones ambiguas, información que falta y situaciones en las que el agente deba detenerse. Describan de antemano qué acciones están permitidas, qué constituye un buen resultado y qué eventos deben figurar en el registro. Así, la evaluación será más concreta que afirmar que la respuesta parece razonable.

Examinen especialmente si el agente respeta los límites de acceso. ¿Puede recuperar el pedido de otro cliente? ¿Puede publicar un borrador sin el permiso adecuado? ¿Puede enviar información a un destinatario no autorizado? Estas comprobaciones se refieren a lo que el sistema hace cumplir, no solo a lo que el agente promete en su texto.

Repitan las pruebas relevantes cuando cambien el modelo, las instrucciones, las herramientas o las integraciones. Una actualización puede influir en la acción que el agente elige y en cómo gestiona los errores. Registren a qué versiones correspondían las pruebas para que un resultado aprobado anteriormente no se utilice como prueba de una solución diferente.

Supervisen también el uso cotidiano. Busquen tareas que se detienen, llamadas inesperadas a herramientas, acciones rechazadas y comentarios de los usuarios. Elijan señales concretas cuyo seguimiento tenga una persona responsable. La seguridad de la IA pasa a formar parte de la operación cuando la empresa puede detectar cambios de comportamiento y ajustar los límites antes de que los problemas crezcan.

Prueben los fallos antes de que los sufran los clientes

Prueben qué ocurre cuando fallan las condiciones previstas. Un servicio puede no estar disponible, una respuesta puede ser incompleta o una acción puede ejecutarse aunque no llegue su confirmación. El agente debe manejar estas situaciones sin inventar un resultado satisfactorio ni repetir sin criterio una acción sensible.

En un sistema de pedidos hipotético, un reembolso puede ejecutarse mientras la solicitud supera el tiempo de espera. Si el agente vuelve a intentarlo inmediatamente sin consultar el estado, el mismo reembolso puede ejecutarse dos veces. La herramienta debe diseñarse para que las solicitudes repetidas de una misma acción se gestionen de forma controlada. Prueben también cómo explica el agente esa incertidumbre al responsable.

Prueben contenido que intente dar nuevas instrucciones al agente. Puede ser un correo, una página web o un documento que pida al sistema ignorar reglas anteriores o enviar información a otro destino. Esos datos no deben adquirir automáticamente la misma autoridad que las instrucciones de la empresa. Examinen tanto la reacción del modelo como si las herramientas siguen aplicando los límites.

Incluyan la falta de aprobación, las interrupciones durante la ejecución y las tareas que terminan con cambios parciales. ¿Puede la empresa averiguar qué queda pendiente? ¿Puede una persona asumir la tarea sin repetir trabajo ya realizado? Un resultado parcial claro suele ser más seguro que un agente que intenta continuamente nuevas vías para terminar.

Cuando una prueba detecte un error, consérvenla como un nuevo control en el conjunto de pruebas. Corrijan la debilidad correspondiente y vuelvan a probar el flujo de trabajo afectado. El objetivo no es demostrar que el agente nunca puede equivocarse. Es saber qué límites se aplican, cómo se detectan los errores y quién puede tomar el relevo cuando la automatización deja de ser adecuada.

Un comienzo práctico para las empresas noruegas

Empiecen por una tarea que puedan describir y medir. «Vamos a utilizar IA» es demasiado amplio. «Vamos a obtener una propuesta de respuesta a preguntas sobre plazos de entrega, basada en información aprobada» es concreto. Eso facilita elegir los datos de base, limitar el acceso y encontrar a una persona que pueda evaluar realmente el resultado.

Un piloto pequeño puede construirse alrededor de estas siete medidas. Esta es nuestra priorización práctica, no una reproducción literal de la lista de Nadella:

• Aclaren la tarea, los datos y el acceso mínimo necesario.
• Separen las propuestas de las acciones en otros sistemas.
• Aíslen la ejecución y comprueben que la parada de emergencia funciona.
• Registren las acciones importantes con independencia de la explicación del agente.
• Utilicen modelos de control donde aporten valor y den a las personas una base clara para decidir.
• Prueben los malentendidos, las entradas manipuladas y los cambios de configuración.
• Aseguren una revisión independiente y un plan de gestión de incidentes.

Elijan un flujo de trabajo que tenga un punto natural de parada antes de afectar al cliente. Un borrador de contenido es un buen ejemplo de ese punto. Un editor puede leer el texto, comprobar las fuentes y decidir si se publica. El sistema no necesita permisos de publicación para contribuir al trabajo. Esa limitación hace que las consecuencias del piloto sean más fáciles de comprender.

Definan también qué quieren aprender. Quizá el piloto deba aclarar si el asistente encuentra la información correcta, si pide ayuda cuando faltan datos y si el profesional ahorra tiempo una vez incluido el trabajo de comprobación. Registren dónde aparece trabajo adicional. Si una propuesta parece rápida, pero requiere mucho tiempo de corrección y verificación, es información importante para la siguiente decisión.

Conviene incluir a quienes utilizarán la solución. Un desarrollador puede demostrar que una regla de acceso funciona, pero una persona de atención al cliente sabe qué formulaciones pueden crear expectativas que la empresa no puede cumplir. Un editor sabe qué fuentes deben examinarse. Una persona responsable de la operación sabe quién puede reaccionar realmente cuando algo se detiene. La seguridad se vuelve más concreta cuando estas perspectivas se reúnen alrededor del mismo flujo de trabajo.

¿Qué debe estar preparado antes de dar más responsabilidad al agente?

Documenten los criterios de aceptación antes de valorar una ampliación del acceso. Un criterio debe describir tanto el resultado esperado como lo que debe ocurrir cuando el sistema no puede ofrecerlo. «Las respuestas parecen buenas» es difícil de comprobar. «La propuesta utiliza información de entrega aprobada y avisa cuando falta» proporciona una base más clara.

Para un piloto hipotético de atención al cliente, podrían exigir que el asistente lea únicamente el caso correspondiente, que no se envíe una respuesta sin aprobación y que se rechacen todos los intentos de cambio fuera del mandato. También debe ser posible recuperar qué propuesta se aprobó, quién la aprobó y en qué datos se basaba. La lista concreta debe adaptarse a la tarea y al riesgo de la empresa.

Una revisión independiente necesita un mandato definido. Pidan a quien evalúa la solución que examine los accesos, el procedimiento de parada y los resultados concretos de las pruebas. La revisión debe aclarar qué se examinó, qué quedó fuera y en qué supuestos se basa la evaluación. Un sello impreciso de «aprobado» es menos útil que una descripción precisa de los hallazgos y las limitaciones.

Creen además un procedimiento sencillo para incidentes antes de necesitarlo. Decidan quién puede detener al agente, quién investiga si otros sistemas están afectados y quién decide si se reanuda la ejecución. Conserven los registros relevantes. Distingan entre detener nuevas acciones y corregir lo que ya se ha realizado. Si se envió un mensaje por error, detener el modelo no deshace ese envío.

Ante un incidente, el responsable debe recopilar información confirmada: qué se hizo, qué datos o personas pueden estar afectados y qué medidas se han ejecutado realmente. La comunicación debe basarse en lo que se ha investigado. Una explicación generada por el agente, por sí sola, no es una base suficiente para declarar que el sistema vuelve a ser seguro. Los posibles requisitos de notificación deben aclararse según la situación concreta y los acuerdos y las normas pertinentes.

Amplíen el mandato paso a paso. Si más adelante quieren permitir envíos, deberían probar primero una categoría pequeña y claramente delimitada de mensajes. Conserven los casos de prueba anteriores y ejecútenlos de nuevo después del cambio. Así podrán ver si la nueva utilidad compensa realmente el nuevo riesgo y si los límites anteriores siguen funcionando.

Un piloto tiene éxito cuando la empresa dispone de una base mejor para elegir. Eso puede significar ampliar la solución. También puede significar mantenerla como asistente, modificar el flujo de trabajo o detener el experimento. Las tres opciones son razonables si la decisión se basa en resultados observados y necesidades claras.

Preguntas frecuentes sobre la seguridad de la IA

¿Dice Nadella que no podemos utilizar IA?

No. El ensayo apunta a reforzar el control alrededor de los modelos. Nuestra recomendación práctica es evaluar el uso según la tarea, el acceso y las consecuencias. Un asistente que propone formulaciones no necesita las mismas facultades que un agente que puede modificar datos de clientes. Lean el texto original de Nadella.

Por eso, es mejor plantear una pregunta concreta que elegir entre confianza absoluta y rechazo total: ¿qué puede hacer la solución si se equivoca? Si la respuesta es que solo crea un borrador que una persona evalúa, el perfil de riesgo es distinto del de un sistema que ejecuta por sí mismo acciones irreversibles. El flujo de trabajo alrededor del modelo determina buena parte de lo que la empresa debe exigir.

¿Qué significa tratar un modelo como un riesgo interno?

Significa planificar teniendo en cuenta que un actor con acceso puede cometer errores o verse influido para exceder su mandato. Una forma práctica de aplicar esta idea es limitar el acceso, controlar las acciones importantes y asegurar que otras personas puedan investigar lo ocurrido. Esto no tiene por qué implicar atribuir intenciones humanas al modelo.

Piensen en un asistente que ayuda con el caso de un cliente. Debe recibir la información necesaria para ese caso. No necesita acceso automático a todo el registro de clientes. Así, la seguridad se convierte en una cuestión de facultades y consecuencias, y la empresa puede examinarlas sin tener que decidir qué «quiere realmente» el modelo.

¿Basta con un modelo adicional para controlar una decisión importante?

Un modelo adicional puede aportar preguntas útiles o detectar discrepancias, pero el número de modelos no demuestra calidad. La comprobación debe basarse en fuentes relevantes y en una comprensión correcta de la tarea. Si ambos modelos reciben los mismos datos incompletos, pueden cometer el mismo error.

Recomendamos utilizar modelos como ayuda para el trabajo de comprobación y mantener al mismo tiempo reglas claras para las acciones con grandes consecuencias. Muestren a la persona responsable qué se va a hacer, en qué información se basa la propuesta y qué cambios producirá. Un botón de aprobación tiene un valor limitado si oculta la propia base de la decisión.

¿Es seguro el agente si el modelo se ejecuta localmente?

La ejecución local describe dónde procesa el modelo la tarea. Por sí sola, no indica qué archivos, redes u otros sistemas puede utilizar el agente. En nuestra valoración, la ejecución local debe examinarse junto con los accesos, las herramientas y el flujo de datos.

Por ejemplo, un asistente local hipotético puede controlar bien la ejecución del modelo y, al mismo tiempo, utilizar una herramienta que envía un documento a un servicio externo. En ese caso, la empresa debe evaluar esa transferencia por separado. Empiecen con una visión de todo el flujo de trabajo: recopilación, procesamiento del modelo, llamadas a herramientas, almacenamiento y posibles transferencias. La ubicación es una característica de la solución; no sustituye ese análisis.

¿Están ya disponibles las funciones para agentes anunciadas por Microsoft?

Se encuentran en estados diferentes. Nuestra revisión está fechada el 12 de octubre de 2026; los estados y los enlaces figuran en la tabla de productos anterior. Utilícenla como punto de partida y comprueben la documentación correspondiente antes de planificar una implementación. Los planes de producto y la disponibilidad real pueden cambiar.

Pidan también información para su configuración concreta. Una función puede haberse presentado en un anuncio general sin estar completamente disponible para todas las plataformas, clientes o flujos de trabajo. Una buena pregunta de compra consiste en solicitar una demostración de la función que realmente van a utilizar y aclarar qué partes de la entrega dependen de futuras actualizaciones.

¿Por dónde debería empezar una pequeña empresa con la seguridad de la IA?

Elijan una tarea delimitada, una persona responsable identificada y un punto natural de parada antes de una acción importante. Utilicen un conjunto limitado de datos. Prueben tanto los casos habituales como las situaciones en las que la información sea incompleta o contradictoria. Examinen también qué hace el sistema cuando intenta utilizar un acceso que no tiene.

Midan el resultado incluyendo la comprobación y la corrección. Una pequeña empresa necesita una respuesta comprensible sobre si la solución ayuda, quién se encarga de su seguimiento y cómo se detiene. Después amplíen solo las partes que tengan una justificación clara. Eso facilita gestionar tanto la inversión como la responsabilidad y proporciona experiencia más útil que un proyecto grande con facultades imprecisas.

Conclusión: la confianza debe poder verificarse

El planteamiento de Nadella ofrece una oportunidad para hacer mejores preguntas sobre los agentes que adoptamos. Las mismas preguntas deberían acompañar toda la compra y la implementación: ¿qué tarea resuelve el sistema? ¿Qué permisos necesita? ¿Quién controla las acciones importantes? ¿Cómo detectamos y detenemos una desviación?

Es posible interesarse por la IA y exigir al mismo tiempo respuestas claras. Un modelo puede aportar propuestas útiles aunque no le demos acceso para ejecutar todas las acciones que propone. Así, la empresa puede obtener experiencia y valor dentro de límites que comprende.

El mensaje comercial de seguridad debe evaluarse con la misma sobriedad. Un producto puede ser útil, pero su valor reside en los controles que funcionan realmente en su flujo de trabajo. Pidan demostraciones, documenten las limitaciones y den a la persona responsable una base real para decidir.

Para Kodemagisk, la orientación práctica es clara: empezar por la necesidad, incorporar los límites y ampliar a partir de resultados observados. Si están valorando un asistente de IA para un sitio web, un portal de clientes o un flujo de trabajo interno, una buena primera conversación puede centrarse en la tarea y las facultades. Conozcan cómo trabajamos con aplicaciones web y herramientas internas, o contacten para hablar de sus necesidades.