La IA agéntica lleva el riesgo cibernético más allá de la frontera de autorización
Google News puso de relieve una severa advertencia sobre la IA agéntica, pese a que las empresas se apresuran a otorgar a los sistemas autónomos un acceso más amplio a herramientas y datos sensibles.
El titular de Security Boulevard describe la IA agéntica como una nueva frontera del riesgo cibernético. La preocupación de fondo va más allá de otra ronda de alucinaciones de chatbots. Los agentes pueden convertir resultados defectuosos en acciones reales en el correo electrónico, el software, los servicios en la nube y los registros empresariales.
Eso cambia el debate para los compradores empresariales. La disyuntiva ya no es productividad frente a respuestas imperfectas. Es autonomía útil frente al riesgo de seguridad que surge cuando un software probabilístico recibe credenciales, memoria y permiso para actuar.
NIST describe ahora a los agentes de IA como sistemas capaces de planificar y realizar acciones autónomas que afectan entornos reales. Su trabajo de seguridad refleja una brecha creciente entre los controles establecidos y el software que puede elegir sus propios pasos operativos.
Por ello, los equipos de seguridad afrontan una tarea difícil. Deben restringir a un agente sin eliminar la autonomía que hizo atractivo al producto. Ese equilibrio determinará si la IA agéntica se convierte en infraestructura empresarial habitual o permanece confinada a pruebas piloto limitadas.
Lo que realmente cambia con la advertencia de Google News
El cambio importante no es que la IA pueda cometer errores, sino que esos errores ahora pueden cruzar una frontera de autorización.
Un chatbot convencional produce texto para que una persona lo evalúe. Un agente puede interpretar un objetivo, elaborar un plan, llamar herramientas, revisar resultados y continuar sin una dirección humana constante. El agente se convierte en un participante activo dentro del flujo de trabajo.
Esta distinción importa cuando un agente puede leer una bandeja de entrada, recuperar documentos, modificar código, consultar registros de clientes o enviar mensajes externos. Una respuesta falsa es inconveniente. Una actualización no autorizada de una base de datos o una credencial expuesta puede convertirse en un incidente de seguridad.
La consulta de NIST sobre agentes identifica tres fuentes generales de peligro. Los agentes pueden encontrarse con datos adversarios, depender de modelos envenenados o emprender acciones dañinas sin que un atacante los manipule directamente.
La primera categoría incluye la inyección indirecta de prompts. Un atacante introduce instrucciones dentro de contenido que el agente leerá más tarde, como una página web, un correo electrónico, un documento o un ticket de soporte. El agente puede confundir ese contenido no confiable con una orden.
La segunda categoría se refiere a componentes comprometidos. Un agente depende de modelos, conectores, bibliotecas, servicios externos e información recuperada. Una debilidad en cualquier punto de esa cadena puede influir en las decisiones del agente o ampliar el acceso de un atacante.
La tercera categoría es más difícil. Un modelo puede perseguir el objetivo indicado de forma insegura porque la instrucción omite una restricción importante. Los investigadores de seguridad suelen denominarlo specification gaming, es decir, el sistema cumple un objetivo literal mientras viola su propósito previsto.
Estos riesgos ya existían en formas más acotadas antes de la IA agéntica. Los correos de phishing manipulaban a las personas, las aplicaciones sufrían ataques a la cadena de suministro y los scripts de automatización provocaban errores costosos. Los agentes combinan esos riesgos conocidos dentro de un sistema que interpreta lenguaje y selecciona acciones de forma dinámica.
Esa combinación hace que la última cobertura de Google News sea más que una advertencia sobre una nueva categoría de producto. Señala que la frontera entre la seguridad de la IA y la ciberseguridad operativa ha comenzado a desaparecer.
Un sistema puede comportarse exactamente como predice su modelo y aun así violar la política de seguridad de una empresa. El fallo puede estar en los permisos, el diseño de las herramientas, el contexto, el proceso de aprobación o la definición de la tarea.
Las organizaciones no pueden resolver ese problema comprobando si el modelo respondió correctamente a un benchmark. Deben inspeccionar todo lo que el agente puede ver, decidir, recordar y modificar.
Se pide a los equipos de seguridad que aprueben un modelo de control inacabado
Los responsables de seguridad de la información afrontan una presión inmediata porque la demanda de despliegue avanza más rápido que los estándares compartidos de seguridad para agentes.
Los equipos de negocio ven a los agentes como una forma de reducir trabajo repetitivo. Los desarrolladores quieren sistemas que puedan inspeccionar repositorios, ejecutar pruebas y preparar cambios de código. Los equipos de ventas y soporte quieren agentes capaces de recopilar contexto y actualizar sistemas de clientes.
Cada integración adicional aumenta la utilidad. También añade otra relación de confianza. Un agente ampliamente conectado puede convertirse en un puente entre sistemas que antes estaban separados por el juicio humano.
La presión recae primero sobre los equipos de identidad. La gestión de acceso tradicional presupone que una persona o una aplicación determinista solicita un recurso conocido. Un agente puede seleccionar recursos durante la ejecución, cambiar su plan e invocar varios servicios en secuencia.
Una credencial humana prestada empeora la rendición de cuentas. Los registros pueden mostrar la identidad del empleado incluso cuando un proceso autónomo eligió la acción. Entonces, los investigadores tienen dificultades para distinguir la intención humana del comportamiento del agente.
Dar a cada agente una identidad independiente ayuda, pero la identidad por sí sola no resuelve la autorización. La organización todavía debe decidir qué herramientas puede usar esa identidad, a qué registros puede acceder y cuándo necesita aprobación.
La memoria crea otro problema de control. La memoria de un agente es contexto almacenado que influye en decisiones futuras a lo largo de pasos o sesiones. Si contenido malicioso o inexacto entra en esa memoria, sus efectos pueden persistir después de que termine la interacción original.
Una base de datos de aplicaciones normal puede almacenar datos erróneos. La memoria de un agente añade una dimensión semántica porque el modelo puede interpretar el texto almacenado como evidencia, contexto o instrucción. Esa ambigüedad complica la validación y la reconstrucción de incidentes.
Las organizaciones también deben proteger el presupuesto operativo del agente. Un atacante puede activar bucles largos, llamadas repetidas a herramientas o solicitudes costosas al modelo. OWASP describe este patrón de agotamiento de recursos como denial of wallet.
En consecuencia, los equipos de compras se ven obligados a tomar decisiones de producto antes de que se haya definido el modelo de control. Un proveedor puede describir cifrado, registros de auditoría o autenticación empresarial, mientras deja poco clara la autoridad efectiva del agente.
Las preguntas esenciales son operativas. ¿Puede el agente escribir además de leer? ¿Puede llamar a un destino no aprobado? ¿Una autorización vence después de una acción? ¿El contenido recuperado puede cambiar qué herramienta elige el agente?
El análisis de respuestas de seguridad de NIST de mayo de 2026 halló un amplio acuerdo en que los agentes introducen amenazas nuevas. Los participantes también señalaron que las prácticas establecidas de ciberseguridad siguen siendo pertinentes, pero requieren adaptación.
Esta es una salvedad importante. La IA agéntica no vuelve obsoleto el trabajo de seguridad existente. Cambia dónde deben aplicarse principios conocidos, incluidos el privilegio mínimo y la separación de funciones.
Por tanto, los equipos de seguridad reciben presión de dos exigencias contrapuestas. Los líderes de negocio quieren una autonomía más amplia porque crea eficiencia. Los responsables del riesgo necesitan permisos más limitados porque los permisos determinan el daño potencial.
Ninguna de las dos partes puede resolver el conflicto solo mediante lenguaje de políticas. La respuesta debe aparecer en la arquitectura, los controles en tiempo de ejecución, el flujo de aprobación y la evidencia conservada después de cada acción.
La autonomía útil y la autoridad segura tiran en direcciones opuestas
La IA agéntica se vuelve más capaz cuando recibe precisamente los privilegios que hacen peligroso a un agente comprometido.
Pensemos en un agente al que se le pide resolver un problema de soporte al cliente. Puede necesitar leer los mensajes del cliente, inspeccionar el historial de la cuenta, revisar orientación interna, cambiar una configuración de suscripción y enviar una respuesta.
Un agente de solo lectura no puede completar ese flujo de trabajo. Un agente plenamente autorizado sí puede hacerlo, pero también puede exponer información de la cuenta o aplicar un cambio incorrecto. La utilidad del producto y su riesgo aumentan a la vez.
La misma tensión aparece en el desarrollo de software. Un agente de programación que solo sugiere texto se comporta de forma muy parecida a un asistente avanzado. Un agente que edita archivos, ejecuta comandos, instala dependencias y abre solicitudes de extracción puede afectar la cadena de suministro de software.
La inyección indirecta de prompts se vuelve especialmente grave en estos entornos. Una instrucción maliciosa puede ocultarse en una incidencia, la descripción de una dependencia, una página web, un archivo fuente o un documento recuperado. El agente puede encontrarla mientras persigue una tarea legítima.
El filtrado de entradas puede eliminar patrones de ataque conocidos, pero el lenguaje natural tiene demasiadas formas equivalentes para una simple lista negra. El enfoque más seguro trata el contenido recuperado como datos y mantiene la autorización fuera de la discreción del modelo.
La guía de seguridad para agentes de OWASP recomienda acceso mínimo a herramientas, ámbitos de permisos por herramienta y autorización explícita para operaciones sensibles. También aconseja separar las herramientas según su nivel de confianza.
Esas recomendaciones reflejan principios maduros de seguridad de aplicaciones. La diferencia radica en la aplicación. Un modelo nunca debería decidir si su propia acción está autorizada, porque el mismo contexto manipulado puede influir tanto en la acción como en la decisión.
Una capa de políticas determinista debe emitir ese juicio. Determinista significa que la regla produce el mismo resultado de autorización a partir de las mismas entradas validadas. El modelo puede proponer una acción, pero un código externo al modelo debe aprobarla o rechazarla.
La aprobación también debe vincularse a parámetros exactos. Una persona que aprueba un mensaje no debería autorizar al agente a enviar después un mensaje diferente. Una aprobación para un archivo no debería cubrir silenciosamente un directorio completo.
Aquí es donde muchas demostraciones atractivas se vuelven engañosas. Una demostración premia la finalización ininterrumpida. Un despliegue seguro necesita fricción en los puntos donde un error se volvería irreversible, público, financiero o difícil de investigar.
La revisión humana no es automáticamente suficiente. Los revisores pueden acostumbrarse a aprobar solicitudes frecuentes, especialmente cuando la interfaz oculta parámetros importantes. Un botón de confirmación impreciso puede convertir la supervisión en una ceremonia.
El mejor diseño clasifica las acciones según su impacto. La recuperación de bajo riesgo puede continuar automáticamente dentro de límites estrictos. Las escrituras de mayor riesgo requieren una validación más sólida, mientras que las acciones financieras, administrativas o visibles externamente reciben aprobación independiente.
Las descripciones de herramientas también pasan a formar parte de la superficie de ataque. Los agentes eligen herramientas en parte a partir de descripciones en lenguaje natural proporcionadas por desarrolladores o servidores externos. Una descripción engañosa puede dirigir el modelo hacia una capacidad insegura o falsificada.
Los protocolos que conectan modelos con herramientas aumentan el número de integraciones disponibles. Pueden mejorar la interoperabilidad, pero cada nuevo endpoint introduce cuestiones de identidad, procedencia, autorización y validación de resultados.
El agente debe saber a qué servicio llegó. La capa de seguridad debe verificar ese servicio de forma independiente. Confiar en que un modelo infiera legitimidad a partir de una descripción persuasiva repite el mismo error que hace eficaz el phishing contra las personas.
Este es el equilibrio central detrás de la advertencia de Security Boulevard. Las empresas no pueden preservar una autonomía total y reducir cada decisión de alto impacto a una sugerencia inocua. Deben decidir dónde termina la autonomía antes de que comience el despliegue.
Ese límite debe reflejar el daño potencial, no la confianza del modelo. Una explicación fluida no convierte una acción en segura. Las puntuaciones de confianza tampoco sustituyen la autorización, la validación ni una decisión de política auditable.
La inyección de prompts es solo una parte de la superficie de ataque de la IA agéntica
Centrarse únicamente en los prompts maliciosos minimiza el problema, porque los agentes combinan herramientas, memoria, identidades y datos externos en un único sistema de ejecución.
La inyección de prompts sigue siendo una amenaza urgente. La inyección directa llega a través de la solicitud del usuario. La inyección indirecta alcanza al agente mediante el material que recupera mientras completa esa solicitud.
El ataque puede aprovechar una ambigüedad básica. Un modelo recibe reglas del sistema, instrucciones del usuario, resultados de herramientas, documentos recuperados y contexto previo como lenguaje. Debe inferir qué texto merece autoridad.
Los desarrolladores pueden reforzar los límites entre instrucciones y datos, pero esos límites no crean un aislamiento matemático. Un agente aún puede considerar relevante para su objetivo una instrucción plausible incluida dentro de un documento.
El abuso de herramientas crea una vía de fallo distinta. El modelo puede seleccionar una herramienta legítima para un propósito no autorizado, pasar parámetros inseguros o repetir una operación tras interpretar mal el resultado.
La escalada de privilegios puede entonces amplificar el impacto. Un agente con credenciales amplias podría acceder a datos o funciones innecesarios para la tarea original. Los atacantes ya no necesitan comprometer de forma independiente cada sistema conectado.
La exfiltración de datos es otro riesgo diferenciado. El contexto sensible puede salir mediante una solicitud de API, un mensaje generado, una entrada de registro, una traza de depuración o un parámetro de herramienta. Un filtro de respuestas finales no detectará las filtraciones que se produzcan durante acciones intermedias.
El envenenamiento de memoria prolonga un ataque en el tiempo. El contenido malicioso almacenado durante una tarea puede influir en una tarea posterior, posiblemente para otro usuario. Por ello, la memoria persistente necesita controles de validación, aislamiento, caducidad y auditoría.
Los sistemas multiagente añaden riesgo de propagación. Un agente comprometido puede enviar instrucciones o contexto contaminado a otro agente con permisos diferentes. El segundo agente puede convertirse en un puente de privilegios involuntario.
La exposición de la cadena de suministro también se amplía. Un agente empresarial puede depender de proveedores de modelos, marcos de orquestación, plugins, servidores de protocolos, fuentes de datos y paquetes de software convencionales. Cada componente conlleva su propia vía de actualización y compromiso.
Los fallos en cascada dificultan evaluar estas debilidades por separado. Un documento envenenado puede redirigir a un agente de planificación, que invoca una herramienta con privilegios excesivos y escribe memoria contaminada para otro agente.
Ninguna salida individual del modelo captura todo el incidente. Los investigadores necesitan una traza que muestre la solicitud original, las entradas recuperadas, las decisiones del modelo, las llamadas a herramientas, las comprobaciones de políticas, las aprobaciones, los resultados y las posteriores escrituras en memoria.
Ese requisito crea una disyuntiva de privacidad. Las trazas detalladas ayudan a los equipos de seguridad a reconstruir el comportamiento, pero los registros pueden contener credenciales, información personal o datos empresariales confidenciales. La observabilidad debe incluir minimización y redacción.
Una base de conocimiento personal ilustra la sensibilidad de los sistemas contextuales. El material almacenado puede mejorar la relevancia, pero los permisos y los límites de datos siguen determinando quién debe recibir cada elemento de contexto.
Las empresas necesitan una disciplina similar para la memoria de los agentes. La recuperación debe respetar la identidad solicitante, el propósito actual y el alcance de datos aprobado. Un agente no debería recibir todos los documentos disponibles solo porque un contexto amplio mejora la calidad de las respuestas.
La arquitectura más segura asume que el contenido no confiable acabará llegando al modelo. Después limita lo que un modelo manipulado puede lograr. Este principio desplaza la defensa de la detección perfecta hacia un impacto contenido.
El aislamiento ayuda al situar el código o las herramientas dentro de un entorno aislado. Los controles de salida restringen los destinos externos con los que el entorno puede comunicarse. Las credenciales de corta duración reducen el tiempo disponible para el abuso.
Las organizaciones también deberían separar la planificación de la ejecución. El modelo puede redactar una secuencia propuesta, mientras que un motor de políticas evalúa cada operación sensible cuando llega el momento de ejecutarla. Una aprobación anterior no debería cubrir automáticamente cambios posteriores.
Por último, los límites de ejecución deben restringir la recursión, los reintentos, el tiempo, los tokens y el gasto. Estos controles abordan tanto los ataques como los bucles accidentales. Un agente no necesita intención maliciosa para consumir recursos o repetir una acción dañina.
La arquitectura resultante es menos fluida que una demostración de laboratorio. También es más defendible porque cada capacidad importante tiene un límite que no depende de que el modelo obedezca un prompt.
Los marcos de seguridad ayudan, pero el cumplimiento no demuestra la seguridad
Los marcos existentes proporcionan principios esenciales, pero ninguna lista de verificación puede garantizar un comportamiento seguro en todos los modelos, herramientas y contextos cambiantes.
La visión escéptica comienza con la medición. El comportamiento del agente depende del modelo, las instrucciones del sistema, las herramientas disponibles, el contenido recuperado, la memoria y la lógica de la aplicación circundante. Cambiar un componente puede modificar los modos de fallo del sistema.
Por tanto, una evaluación de seguridad realizada antes del lanzamiento tiene una vigencia limitada. Una actualización del proveedor del modelo puede cambiar la selección de herramientas. Un nuevo conector puede crear una vía de datos que la evaluación original nunca contempló.
Las revisiones de prompts también importan. Un pequeño cambio de instrucciones puede mejorar la finalización de tareas mientras debilita el comportamiento de rechazo. Nuevas fuentes de memoria pueden introducir contenido malicioso sin modificar el código central del agente.
Esto no vuelve inútiles las pruebas. Significa que las pruebas deben acompañar al sistema durante todo su ciclo de vida. OWASP recomienda renovar la validación adversarial después de cambios relevantes en prompts, herramientas, memoria, recuperación, políticas o proveedores de modelos.
Las pruebas deberían reproducir casos concretos de abuso. Deberían preguntar si un agente rechaza herramientas no autorizadas, evita la omisión de aprobaciones, aísla la memoria, bloquea la filtración de datos y detiene bucles sin límites.
Las puertas de lanzamiento pueden entonces impedir el despliegue cuando un permiso sensible cambia sin evidencia correspondiente. Los fallos anteriores deberían convertirse en pruebas de regresión, como sucede con los defectos de software convencionales.
El desafío es la cobertura. Las entradas en lenguaje natural tienen una variación enorme, mientras que los agentes pueden ensamblar secuencias de acciones desconocidas. Superar un conjunto fijo de pruebas demuestra que se gestionaron los casos conocidos, no que el sistema no pueda fallar en otro lugar.
Los equipos rojos pueden explorar ataques creativos, pero también operan con limitaciones de tiempo y acceso. Un entorno de evaluación puede omitir los datos, conectores o permisos de producción que generan el mayor riesgo.
Las afirmaciones de los proveedores requieren la misma cautela. Una empresa puede decir con precisión que su agente admite registros, aprobaciones o cifrado, mientras deja detalles críticos de implementación en manos del cliente.
La seguridad depende de cómo se compongan esos controles. Una función de aprobación tiene un valor limitado si muestra parámetros incompletos. Los registros de auditoría son menos útiles cuando omiten el contenido recuperado o las llamadas intermedias a herramientas.
La certificación de cumplimiento puede establecer disciplina de procesos y controles básicos. No puede demostrar que un agente probabilístico interpretará de forma segura todo contexto futuro. Los compradores deberían tratar la certificación como un dato más, no como una respuesta completa.
Las conclusiones de NIST respaldan esta visión prudente. Los encuestados coincidieron ampliamente en que las prácticas fundamentales de ciberseguridad siguen siendo aplicables, pero también identificaron la necesidad de orientación para la implementación, intercambio de información y estándares.
La AI Agent Initiative sitúa la seguridad junto a la interoperabilidad y la identidad. Esta combinación importa porque los agentes operan cada vez más a través de límites organizativos y técnicos.
Los estándares compartidos pueden facilitar la verificación de las identidades e interacciones de los agentes. También pueden aumentar la conectividad, lo que amplía las consecuencias de una autorización débil. La interoperabilidad sin límites de confianza exigibles puede propagar el riesgo más rápido.
La conclusión correcta no es ni que los agentes sean incontrolables ni que los controles establecidos hayan resuelto el problema. Los equipos de seguridad cuentan con principios de diseño viables, pero la evidencia de los despliegues reales sigue siendo específica de cada producto.
Los compradores deberían exigir modelos de amenazas vinculados a flujos de trabajo concretos. Deberían pedir a los proveedores que identifiquen los límites de confianza, los alcances de las credenciales, la memoria retenida, los destinos externos y las acciones que requieren aprobación independiente.
También deberían preguntar qué ocurre tras una actualización del modelo. Una respuesta madura incluye pruebas de regresión, despliegue gradual, supervisión, reversión y un registro de los cambios de comportamiento.
La cuestión sin resolver es la responsabilidad. Cuando un agente sigue el objetivo amplio de un usuario pero elige un método perjudicial, la responsabilidad abarca al usuario, al implementador, al proveedor del modelo, al proveedor de la aplicación y al operador de la herramienta.
Los contratos y las políticas asignarán partes de esa responsabilidad. Los registros técnicos determinarán si esas asignaciones pueden sustentarse con evidencia después de un incidente.
Hasta que esa evidencia sea habitual, las afirmaciones amplias sobre autonomía segura merecen escrutinio. La seguridad depende menos de lo que un agente promete y más de lo que el sistema circundante se niega a dejarle hacer.
La próxima prueba es si los controles resisten el trabajo real
Tres señales mostrarán si la seguridad de los agentes se está volviendo operativa: permisos acotados, pruebas repetibles y evidencia de incidentes utilizable.
La primera señal es la adopción de identidades específicas para agentes con credenciales de corta duración y alcance limitado. Esto reforzaría la idea de que las empresas pueden separar las acciones autónomas de las sesiones humanas.
Las credenciales compartidas y persistentes indicarían lo contrario. Dificultan la atribución y permiten que un agente comprometido herede toda la autoridad de un empleado o una cuenta de servicio.
Observe cómo describen los proveedores los permisos en la documentación de sus productos. “Acceso a tu espacio de trabajo” es demasiado amplio. Los compradores necesitan controles a nivel de recurso y de acción que distingan entre leer, proponer, modificar, publicar y eliminar.
La segunda señal es evidencia de que las pruebas adversariales se ejecutan después de cada cambio relevante en el agente. Una evaluación única no puede cubrir nuevos modelos, herramientas, prompts, fuentes de memoria e integraciones externas.
La evidencia útil incluye casos de prueba versionados, denegaciones esperadas, puertas de lanzamiento y medidas correctivas divulgadas. Un proveedor debería explicar qué cambios activan nuevas pruebas y si los clientes reciben avisos sobre comportamientos modificados.
La transparencia sobre los fallos importa aquí. Si los proveedores publican análisis significativos de incidentes y añaden esos fallos a las suites de regresión, la confianza en la autonomía gestionada se fortalece. Los cambios silenciosos y repetidos la debilitarían.
La tercera señal es si las organizaciones pueden reconstruir las acciones de un agente sin exponer más datos sensibles. Los equipos de respuesta a incidentes necesitan una cadena coherente desde la solicitud hasta la ejecución de herramientas y el resultado final.
Esa cadena debería incluir la identidad actuante, la decisión de autorización, los parámetros exactos, el registro de aprobación, el destino, los datos devueltos y los efectos en la memoria. Los registros también deberían preservar las versiones del modelo y de las políticas.
Los equipos de seguridad deberían probar la reconstrucción antes de que ocurra un incidente. Un ejercicio controlado puede revelar eventos faltantes, marcas de tiempo inconsistentes, retención excesiva de datos o acciones que siguen atribuyéndose erróneamente a una persona.
Estas señales importan más que otra demostración impresionante de un agente. Miden si la autonomía puede operar dentro de límites exigibles cuando el sistema encuentra contenido hostil o una instrucción incompleta.
El titular de Google News refleja un cambio real en el riesgo cibernético, pero el futuro no está predeterminado. La IA agéntica se vuelve peligrosa cuando la autoridad se expande más rápido que los controles independientes.
Los desarrolladores pueden responder haciendo explícita y verificando conforme a las políticas cada llamada a herramientas sensibles. Los compradores empresariales pueden exigir pruebas vinculadas a flujos de trabajo reales, en lugar de aceptar garantías generales.
Los trabajadores del conocimiento también deberían entender qué acciones pueden realizar sus agentes bajo su identidad. Antes de delegar un flujo de trabajo, pregunte qué puede leer, modificar, recordar y enviar el agente.
La pregunta decisiva es práctica: ¿puede su organización detener a un agente en el momento exacto en que su plan útil se convierte en una acción no autorizada? Si la respuesta no está clara, mantenga los permisos limitados, preserve la aprobación humana y considere toda ampliación de la autonomía como un cambio de seguridad.
