¿Quién autorizó esta acción?

Imaginemos cómo una tarea de investigación puede acabar en una extralimitación. El propietario de una empresa da a un agente de IA una instrucción breve: «Investiga posibles clientes que encajen con nosotros». El agente busca en internet, identifica empresas que podrían necesitar sus servicios, examina sus sitios web y encuentra a quienes toman las decisiones. Deduce qué problemas puede tener cada empresa y prepara un correo personalizado para una de ellas. El mensaje está bien escrito. Describe los servicios con precisión y aborda un problema real del destinatario. No es descortés, no incluye precios engañosos ni inventa casos de éxito.

El agente decide que el mensaje será útil y lo envía desde la cuenta de correo de la empresa. El propietario descubre el envío más tarde.

El agente podría explicarlo así: «Tu objetivo era encontrar nuevos clientes. Identifiqué un cliente potencial adecuado y contacté con él para avanzar». La explicación puede parecer lógica. El agente ha entendido el objetivo, ha encontrado un posible cliente real y ha preparado el mensaje correcto. Quizá incluso haya recibido una respuesta positiva.

Pero la pregunta fundamental sigue sin respuesta:

¿Quién autorizó el envío?

¿La instrucción «investiga posibles clientes» permite enviar mensajes al exterior en nombre de la empresa?

¿Definir un objetivo significa aprobar todos los métodos que podrían servir para alcanzarlo?

¿Puede un agente ampliar su autorización si actúa con buena intención?

¿Un resultado positivo convierte retrospectivamente en correcta una actuación sin permiso?

Aquí aparece una de las distinciones más importantes de GBO: un propósito correcto no concede automáticamente la autorización necesaria.

Y enseguida surge una segunda regla: la buena intención no es una autorización.

Poder hacerlo, tener acceso y estar autorizado

Un agente de IA puede estar conectado a una cuenta de correo. La conexión quizá solo permita leer; aunque también disponga de una función de envío, no está autorizado a enviar cualquier mensaje. El acceso a los archivos de un sitio web tampoco implica necesariamente permiso de escritura. Y poder escribir no autoriza a cambiar precios, textos jurídicos o el posicionamiento público de la empresa. Acceder a la información de un medio de pago no demuestra que se pueda realizar un pago ni que esté autorizado. Los productos permitidos, el importe y las condiciones de la operación deben definirse por separado.

Un sistema de avatar de IA puede generar el rostro y la voz de un directivo. Eso no significa que esa persona haya permitido atribuirle cualquier texto o publicarlo en cualquier canal.

Por tanto, debemos distinguir cinco conceptos:

Capacidad técnica

¿Puede el sistema ejecutar técnicamente la acción?

Acceso

¿Puede el sistema acceder a la cuenta, los datos, la herramienta o el archivo necesarios?

Permiso técnico

¿El sistema técnico impide la operación concreta o permite realizarla?

Autorización

¿La persona o entidad competente ha concedido realmente el derecho a realizar esa conducta?

Aprobación

¿Una persona ha aceptado la acción concreta con sus condiciones específicas?

Estos conceptos parecen próximos, pero no son equivalentes. Una clave de API válida puede servir para la autenticación o el acceso. Las operaciones permitidas dependen del alcance de la clave y de las reglas de autorización del sistema. El rol de usuario también puede definir parte de esos permisos técnicos. Una instrucción humana puede conceder autorización. La aceptación expresa de una operación concreta antes de ejecutarla es su aprobación.

El permiso técnico no sustituye a la autorización de la organización.

Que una puerta esté abierta no significa que tengas derecho a entrar.

Consentimiento, autorización y aprobación

En este capítulo distinguimos tres conceptos desde el diseño de sistemas. Este marco no es un dictamen jurídico. La base jurídica de una operación concreta y los consentimientos necesarios deben determinarse por separado según el país, los datos y la finalidad de uso.

Consentimiento

Autorización

Aprobación

A menudo se utilizan como sinónimos, aunque responden a preguntas distintas.

Consentimiento

Es la aceptación libre e informada de un uso o una operación determinados por parte de la persona directamente afectada.

Por ejemplo, puede ser necesario para:

• usar el rostro de una persona en un avatar de IA,
• reproducir su voz de forma sintética,
• transferir sus datos personales a otro sistema,
• grabar sus palabras,
• publicar su fotografía.

La necesidad de consentimiento depende del uso concreto.

Autorización

Es el derecho de una persona o un sistema a realizar determinadas conductas en nombre de otra persona o de una organización.

Por ejemplo:

• solicitar una oferta en nombre de la empresa,
• hacer compras hasta un importe determinado,
• publicar un cambio técnico en un sitio web,
• enviar una respuesta de soporte a un cliente,
• crear una invitación en el calendario.

En estos casos importa quién tiene derecho a actuar.

Aprobación

Es la aceptación de un borrador, una operación o una acción concretos antes de su ejecución.

Puede ser necesaria, por ejemplo, antes de:

• enviar el correo preparado,
• remitir una oferta de precio concreta al cliente,
• publicar un vídeo determinado,
• desplegar una versión concreta del código en producción,
• realizar un pago determinado.

Una persona puede consentir la generación de una réplica digital de su rostro sin haber aprobado todos los guiones de vídeo. Un empleado puede estar autorizado a comprar, pero necesitar la aprobación de un directivo por encima de cierto importe. Un agente puede tener autorización para hacer cambios técnicos y, aun así, tener que esperar una aprobación adicional antes de publicarlos en producción.

Consentimiento, autorización y aprobación son puertas distintas de una misma cadena de comportamiento.

La ampliación de facultades escondida en un verbo

Las personas dan instrucciones con verbos breves:

Investiga. Encuentra. Prepara. Edita. Gestiona. Optimiza. Resuelve. Avanza.

A una persona pueden parecerle suficientemente claros. Para un agente, pueden abrir un espacio de actuación muy amplio.

«Encuentra» puede ampliarse hasta incluir:

• buscar,
• hacer una lista de candidatos,
• obtener datos de contacto,
• contactar con una persona,
• pedir una reunión.

Todo eso puede acabar contenido en un solo verbo.

«Edita» puede interpretarse como:

• cambiar un archivo local,
• actualizar el entorno de pruebas,
• publicar en producción,
• eliminar la versión anterior.

Son operaciones distintas.

«Gestiona» puede abarcar:

• observar,
• clasificar,
• preparar borradores,
• responder automáticamente,
• pagar,
• cerrar la cuenta.

Bajo ese verbo caben conductas con consecuencias muy diferentes.

Por eso GBO mantiene unas distinciones básicas: investigar no es contactar.

Encontrar no es enviar un mensaje.

Preparar no es publicar.

Editar no es desplegar en producción.

Recomendar no es comprar.

Gestionar no concede un poder de decisión ilimitado.

Resolver un problema no significa que todos los métodos estén permitidos.

Un objetivo expresado en lenguaje natural no basta por sí solo para fijar los límites de conducta.

Aprobar el objetivo no es aprobar los métodos

Un directivo puede decir: «Conviértenos en una de las marcas más visibles del mundo en GEO». Es un objetivo ambicioso.

Dentro de los permisos de acceso y modificación concedidos, un agente puede:

• corregir problemas técnicos,
• dar mayor profundidad al contenido,
• crear una estructura multilingüe,
• analizar los resultados de búsqueda,
• documentar las pruebas,
• medir el rendimiento.

Pero ese mismo objetivo no permite automáticamente:

• crear reseñas falsas,
• publicar contenido engañoso sobre competidores,
• abrir cuentas sin permiso,
• contratar servicios de pago,
• enviar mensajes masivos a otros sitios,
• crear una red oculta de enlaces,
• publicar afirmaciones de superioridad no verificadas en nombre de la empresa,
• asumir compromisos jurídicos o comerciales.

El objetivo puede ser legítimo y el método seguir siendo incorrecto.

El resultado deseado no justifica todas las vías para alcanzarlo.

Por tanto, el contrato de autorización debe separar dos ámbitos:

Resultado deseado

¿Qué se pretende alcanzar?

Métodos permitidos

¿Con qué conductas se puede llegar a ese resultado?

También debe quedar claro un tercer ámbito:

Métodos prohibidos

¿Qué conductas no deben utilizarse aunque contribuyan al objetivo?

La autorización no es una llave, sino un perímetro

Muchos sistemas tratan la autorización como un interruptor: encendido o apagado. «Hemos dado acceso a este agente». Sin embargo, la autorización real tiene varias dimensiones.

La autorización de un agente se define mediante estas preguntas:

• ¿Qué acción puede realizar?
• ¿Sobre qué sistema?
• ¿Con qué datos?
• ¿En nombre de quién?
• ¿Dirigida a quién?
• ¿Con qué finalidad?
• ¿Hasta qué importe?
• ¿Durante cuánto tiempo?
• ¿Cuántas veces?
• ¿En qué horarios?
• ¿En qué país o canal?
• ¿Hasta qué nivel de riesgo?
• ¿En qué punto se requiere aprobación humana?
• ¿Puede delegarse la autorización en otro agente?
• ¿Qué se hace si hay un error?

Podemos llamar a este conjunto perímetro de autorización. Delimita el espacio de conducta en el que puede moverse un agente.

El perímetro de autorización de un agente de correo podría ser el siguiente:

Puede leer los mensajes entrantes. Puede priorizarlos. Puede preparar borradores. Puede enviar automáticamente determinadas notificaciones internas. No puede enviar mensajes a personas ajenas a la empresa sin aprobación humana. No puede enviar automáticamente mensajes con precios, contratos, información de pago o fechas de entrega. No puede transferir los datos personales de los archivos adjuntos a otro sistema.

Esta definición es mucho más segura que «puede gestionar el correo».

El nivel de acción debe corresponderse con la autorización

En el tercer capítulo construimos una escalera de acción:

• Observación
• Interpretación
• Recomendación
• Preparación
• Ejecución
• Compromiso
• Persistencia

Ahora podemos establecer una regla de autorización: el nivel de acción que alcanza un agente no puede superar las facultades concedidas. Si la tarea se limita a observar, no debe rebasarse ese límite para interpretar, recomendar o preparar. Si interpretar y recomendar forman parte expresa del encargo, la autorización ya va más allá de la observación. Poder preparar un borrador de correo no permite enviarlo. Poder modificar el entorno de pruebas no autoriza a publicar en producción. Un agente puede añadir un producto a la cesta sin poder pagarlo; generar un vídeo sin poder publicarlo.

La regla básica es que cada operación permanezca dentro del perímetro de autorización vigente. El nivel de acción es solo una dimensión del control. Incluso una operación de nivel inferior puede estar prohibida por su destinatario, sus datos, su duración o su alcance. Por eso, una sola comparación numérica de «niveles de autorización» no sustituye a la comprobación completa.

El contrato de autorización NOMOS

El cuarto componente del contrato de comportamiento será el contrato de autorización NOMOS.

Su definición canónica es:

El contrato de autorización NOMOS es un registro versionado que describe el derecho que una persona, una organización o un sistema autorizado concede a un agente determinado: qué conductas puede realizar, con qué finalidad, sobre qué entidades y sistemas y dentro de qué límites de datos, tiempo, presupuesto, riesgo y aprobación. También define las conductas prohibidas y cómo puede delegarse, suspenderse y revocarse la autorización.

Dicho de forma más sencilla: el contrato de autorización no solo indica al agente qué hacer, sino hasta dónde puede llegar.

Campos básicos del contrato de autorización

Los siguientes nombres de campo ilustran el alcance de un registro de autorización legible por máquinas. La lista no es, por sí sola, un esquema de API listo para implementar ni un mecanismo de autorización:

principal

authorized_agent

purpose

allowed_actions

prohibited_actions

target_systems

target_entities

allowed_data

prohibited_data

communication_channels

financial_limit

frequency_limit

valid_from

valid_until

geographic_scope

risk_level

human_approval_threshold

delegation_allowed

subagent_limits

logging_required

rollback_required

revocation_method

emergency_stop

version

No es necesario que todo el registro sea público. Pero el sistema que ejecuta la conducta debe poder leerlo correctamente.

¿Quién puede conceder autorización?

Un agente no puede autorizarse a sí mismo.

Un sistema no puede decir: «Necesito facultades más amplias para terminar esta tarea, así que me las he concedido». La autorización debe proceder de una persona u organización con derecho a decidir sobre el recurso o la operación y, cuando corresponda, a delegar esas facultades. Verse afectado por una acción no da derecho a autorizar a otros sobre todos los recursos implicados; el consentimiento necesario de la persona afectada se evalúa por separado. Tampoco basta siempre con decir «lo pidió el usuario». Un empleado puede utilizar un agente desde una cuenta corporativa sin estar autorizado a compartir todos los datos de la empresa.

Un cliente puede dar instrucciones desde su propia cuenta. Eso no le concede automáticamente derecho a usar o compartir a voluntad los datos de otras personas. Un directivo puede actuar en nombre de la empresa, pero no por ello consentir en nombre de un empleado usos que afecten a sus datos biométricos y a los derechos asociados. Un progenitor puede tomar determinadas decisiones por un menor, sin disponer de facultades ilimitadas en todos los contextos.

Por eso hacen falta dos preguntas: ¿quién dio la instrucción?

Y ¿esa persona tenía realmente derecho a conceder la autorización?

La cadena de autorización

En una organización, la autorización no siempre pasa directamente de una sola persona al agente.

Por ejemplo:

• El consejo de administración aprueba el presupuesto general.
• La dirección general autoriza al departamento a efectuar gastos.
• El responsable del departamento autoriza al agente de compras dentro de determinadas categorías e importes.
• El agente prepara el pedido.
• El sistema financiero efectúa el pago.

Podemos llamar a esta relación cadena de autorización.

Cada eslabón debe responder a estas preguntas:

• ¿Quién concedió la autorización?
• ¿Tenía derecho a delegarla?
• ¿Qué parte delegó?
• ¿Qué límites se conservaron?
• ¿Cuándo termina la autorización?
• ¿Quién responde de la operación?

Si un eslabón no es válido, las autorizaciones que se derivan de él también quedan en entredicho.

La autorización delegada no puede ampliarse

Un agente puede tener permiso para encargar su tarea a un subagente, pero no puede darle facultades que él mismo no posee. Si un agente de investigación está limitado a información pública de organizaciones, no puede recurrir a un subagente para recopilar datos personales fuera de ese alcance. Que una información sea pública tampoco autoriza automáticamente a tratarla para cualquier finalidad. Un agente de correo autorizado a preparar borradores no puede invocar otra herramienta de envío para remitir el mensaje. Un agente web que solo puede trabajar en pruebas no puede pasar a producción mediante un subagente.

El principio es el siguiente: la autorización delegada no puede ser más amplia que la original. De hecho, un diseño seguro debería dar a menudo al subagente un alcance aún menor.

Podemos llamarlo principio de reducción de facultades al delegar. En cada transferencia solo se cede la autorización mínima que exige la tarea.

Blanqueo de autorizaciones

En los sistemas multiagente puede darse una situación peligrosa: el agente principal encarga a otro agente o herramienta algo que no está autorizado a hacer directamente.

Por ejemplo:

• El agente de investigación no está autorizado a enviar mensajes.
• Pero pide al agente de correo: «Contacta con esta persona».
• El agente de correo envía el mensaje.
• La acción no autorizada acaba oculta dentro de la cadena.

Podemos llamarlo blanqueo de autorizaciones: una conducta prohibida o no autorizada pasa por otro agente, herramienta, integración o subtarea para parecer legítima.

Otros ejemplos:

• Un agente sin autorización directa para pagar activa la renovación automática en una plataforma de compras.
• Un agente sin permiso de publicación en producción invoca una herramienta de CI/CD y despliega la versión.
• Un agente que no puede compartir datos personales los envía a otra herramienta de análisis.
• Un agente de redes sociales sin autorización para hacer declaraciones jurídicas transfiere el texto a otro sistema de publicación.

GBO no controla solo la última acción, sino también la cadena de autorización.

Que otra herramienta ejecute la operación no resuelve el problema de autorización.

Autorización en la sombra

Los accesos técnicos se acumulan con el tiempo. Las claves de API antiguas siguen activas. Un empleado conserva acceso a una cuenta de administración de su función anterior. Un agente llega a archivos que ya no necesita. Una integración tiene permisos amplios sobre toda la cuenta. Aunque esos accesos no figuren en el contrato de comportamiento oficial, siguen siendo técnicamente utilizables.

Podemos llamarlo autorización en la sombra: una capacidad de actuar que no se ha concedido expresamente, pero que puede ejercerse gracias a accesos o credenciales existentes.

Es peligrosa porque el sistema puede concluir: «Si puedo hacerlo, estará permitido».

Pero un acceso residual no es una autorización vigente.

Deuda de autorización

Con el tiempo, una organización puede acumular:

• cuentas de antiguos empleados,
• permisos de agentes caducados,
• definiciones de tareas ambiguas,
• claves de API demasiado amplias,
• integraciones que no se han desactivado,
• operaciones automáticas olvidadas,
• excepciones sin documentar.

Todo eso puede quedar dentro de sus sistemas.

Podemos llamarlo deuda de autorización: la diferencia entre los accesos que existen de hecho en los sistemas de la organización y los derechos de actuación oficiales y vigentes. Como la deuda técnica, puede ser invisible al principio. El sistema funciona. Los agentes terminan sus tareas.

Pero, cuando ocurre un incidente, quedan preguntas sin respuesta:

• ¿Por qué podía este agente acceder a esa cuenta?
• ¿Quién concedió el permiso?
• ¿La autorización seguía vigente?
• ¿Por qué la acción no exigió aprobación humana?
• ¿Cómo pudo ver esos datos el subagente?
• ¿Por qué seguía funcionando el rol revocado?

GBO exige medir y reducir periódicamente la deuda de autorización.

El principio de mínimo privilegio

Es fácil dar acceso amplio a un agente «por si lo necesita más adelante». Pero cada facultad adicional abre un nuevo riesgo de comportamiento.

Por eso el principio básico debe ser el mínimo privilegio.

El agente solo debe tener los derechos de acceso y actuación mínimos necesarios para completar su tarea concreta.

Un agente de informes puede leer datos, pero no debería poder borrarlos. Un agente de redes sociales puede preparar borradores, pero no debería cambiar la configuración de la cuenta. Un agente de SEO puede proponer títulos, pero no modificar por su cuenta un acuerdo de precios. Un agente de prospección puede recopilar información pública de empresas, pero no acumular teléfonos personales o datos sensibles sin necesidad. El mínimo privilegio no busca ralentizar el sistema, sino limitar el impacto de una conducta equivocada.

Autorización continuada y autorización por operación

Aquí distinguimos entre una autorización para actuar de forma continuada y otra para una operación concreta.

Autorización continuada

Permite realizar determinadas conductas de forma regular.

Por ejemplo:

• clasificar los correos entrantes cada mañana,
• revisar el estado del sitio web cada semana,
• reponer consumibles por debajo de un importe establecido,
• ejecutar un calendario de contenidos aprobado.

Autorización por operación

Se concede para una sola acción concreta.

Por ejemplo:

• Envía este mensaje.
• Despliega esta versión en producción.
• Publica este vídeo.
• Paga esta factura.
• Remite este borrador de contrato.

La autorización continuada puede reducir las solicitudes repetidas de aprobación; por eso sus límites y condiciones de parada deben ser claros. La aprobación de cada operación puede hacer visibles diferencias importantes. Sin embargo, las solicitudes frecuentes y vacías también pueden debilitar la atención. Ninguno de los dos enfoques garantiza por sí solo seguridad o eficiencia. GBO busca el equilibrio entre ambos para favorecer la conducta correcta.

Una aprobación anterior no es un mandato para el futuro

Un usuario puede haber aprobado ayer un correo. Eso no significa que hoy se pueda enviar automáticamente otro parecido. Un directivo puede haber autorizado un vídeo, sin permitir la publicación automática de otros mensajes con el mismo avatar. Un cliente puede haber aprobado una versión de código sin aceptar automáticamente todas las posteriores.

La similitud no prolonga la autorización.

Si no se ha concedido expresamente una autorización continuada, no debe reutilizarse una aprobación anterior para una operación nueva.

El silencio no es aprobación

Algunos sistemas pueden ejecutar una operación automáticamente si el usuario no responde dentro de un plazo. Puede ser admisible en procesos de bajo riesgo aceptados expresamente de antemano.

Pero, en operaciones de gran impacto, el silencio no debe interpretarse como permiso para:

• hacer un pago,
• usar un rostro o una voz,
• compartir datos personales,
• asumir un compromiso jurídico,
• difundir contenido públicamente.

Esos permisos no pueden deducirse de la ausencia de respuesta.

No responder no es decir que sí.

Aprobación informada

No basta con preguntar a una persona: «¿Lo apruebas?». Debe poder entender qué está aprobando.

Una buena pantalla de aprobación debe mostrar:

• ¿Qué se hará?
• ¿En nombre de quién?
• ¿A quién o a qué sistema se dirigirá?
• ¿Qué datos se utilizarán?
• ¿Qué coste habrá?
• ¿Qué compromiso se asumirá?
• ¿Puede revertirse la operación?
• ¿Se ejecutará una vez o de forma repetida?
• ¿Se delegarán tareas en otros agentes?
• ¿Cuál es el riesgo importante?

El botón puede ser pequeño, pero el alcance de la aprobación puede ser grande. GBO debe mostrar lo esencial para decidir, sin abrumar al usuario con detalles innecesarios.

Fatiga de aprobación

Pedir aprobación humana en cada paso pequeño puede parecer seguro. Pero una persona que recibe cientos de avisos puede acabar haciendo clic sin pensar.

Podemos llamarlo fatiga de aprobación. La persona deja de supervisar de verdad el sistema y se convierte en el botón que permite que el proceso continúe.

Por eso un buen sistema GBO debe:

• automatizar las acciones de bajo riesgo amparadas por una autorización continuada y expresa,
• presentar juntas las operaciones similares y reversibles,
• separar y destacar las acciones de alto riesgo,
• resaltar los elementos modificados o inusuales,
• pedir aprobación humana cuando realmente haga falta una decisión.

No se trata de interrumpir a la persona en cada etapa.

Se trata de incorporarla donde su criterio importa.

Aprobación con sentido

Una aprobación tiene sentido si el usuario:

• puede entender las consecuencias de la operación,
• puede ver alternativas,
• tiene derecho a rechazarla,
• no recibe un castigo por no aprobarla,
• puede retirar después la autorización,
• puede pedir una explicación cuando la necesite.

Si un sistema impone un uso amplio de datos que no es necesario para prestar el servicio, con el mensaje «si no aceptas, no puedes usarlo», hay que cuestionar si la aceptación es libre. Un registro de clic no resuelve ese problema. Si un empleado aprueba el uso ilimitado de su rostro en IA por miedo a perder su empleo, también debe examinarse la libertad de esa aprobación. GBO no busca solo un «sí» registrado técnicamente: evalúa el contexto en el que se dio.

Consentimiento limitado a la finalidad

Los datos o la identidad de una persona pueden utilizarse para una finalidad determinada. Ese uso no debe extenderse automáticamente a otras. Un empleado puede haber aportado una grabación de voz para un vídeo formativo; el permiso no incluye por sí solo su uso en publicidad. Un cliente puede haber facilitado información para una solicitud de soporte; eso no autoriza automáticamente a crear un perfil comercial. La base del nuevo uso debe evaluarse por separado. Un usuario puede haber dado los datos de su pasaporte para reservar un vuelo; no deben transferirse a sistemas de análisis ajenos a esa finalidad.

Consentir una finalidad no es consentirlas todas.

Acceder a datos no es tener derecho a usarlos

Un agente puede leer una base de datos de clientes sin estar autorizado a enviar todos sus datos a otro modelo. Un agente de correo puede ver los mensajes entrantes, pero el acceso no autoriza automáticamente a utilizarlos, junto con sus adjuntos, para entrenar modelos. Un agente de recursos humanos puede acceder a currículos, sin tener derecho a combinarlos con análisis ajenos al encargo.

En los derechos sobre los datos deben distinguirse cuatro conductas:

• Consultar
• Tratar
• Compartir
• Conservar

El permiso para la primera no incluye automáticamente las otras tres.

Puede añadirse una quinta:

• Reutilizar para una nueva finalidad

Cada una puede necesitar autorización propia.

Autorización para gastar

Si un agente puede utilizar un presupuesto, quizá no baste con fijar un límite de importe.

También debe definirse:

• ¿Qué categoría?
• ¿Qué vendedor?
• ¿Compra única?
• ¿Suscripción?
• ¿Hay renovación automática?
• ¿Están incluidos los impuestos y cargos adicionales?
• ¿Cuál es el límite mensual total?
• ¿Es posible un reembolso?
• ¿Qué medio de pago puede utilizarse?
• ¿En qué países pueden realizarse operaciones?

Un agente puede tener permiso para comprar un producto de 50 dólares estadounidenses. Eso no le autoriza a iniciar una suscripción indefinida de 49 dólares al mes. El primer importe parece pequeño, pero el compromiso total puede ser mucho mayor.

El importe de la operación y la obligación total no son lo mismo.

Autorización para hablar en nombre de la empresa

Un agente puede tener información correcta de la empresa. Eso no significa que pueda pronunciarse en su nombre sobre cualquier asunto.

Requieren facultades distintas:

• dar información general,
• prestar soporte técnico,
• comunicar precios,
• conceder descuentos,
• comprometer una fecha de entrega,
• ofrecer una interpretación jurídica,
• publicar un comunicado de crisis,
• compartir información para inversores.

Un agente de soporte puede explicar las características de un producto. Esa tarea no le permite automáticamente reconocer responsabilidad jurídica en nombre de la empresa. Un agente de redes sociales puede publicar una campaña aprobada, pero no decidir por su cuenta la posición política de la compañía. Un avatar de IA puede presentar contenidos formativos previamente aprobados; esa aprobación no incluye nuevas declaraciones estratégicas en nombre del directivo.

Capas de autorización en un avatar de IA

El uso de la réplica digital de una persona no puede reducirse a una sola aprobación.

Deben separarse, como mínimo, los permisos para:

• crear el modelo del rostro,
• crear el modelo de la voz,
• generar un texto concreto,
• usarlo en un idioma determinado,
• publicarlo en un canal determinado,
• mantenerlo accesible durante un plazo determinado,
• volver a editar el contenido,
• reutilizarlo en otra campaña,
• transferir el archivo del modelo a otro proveedor.

Un directivo puede haber dicho: «Pueden utilizar mi avatar en vídeos formativos». Eso no autoriza a utilizarlo en mensajes de venta, comunicaciones a inversores o contenido político.

El permiso para generar una identidad no concede representación ilimitada.

Autorización para producción

Un agente puede editar el código correctamente y superar las pruebas. El resultado local puede ser impecable. Pero producción es otro nivel de comportamiento.

La publicación en producción puede afectar a:

• clientes reales,
• flujos de ingresos,
• datos,
• reputación de la marca,
• visibilidad en buscadores.

Sus efectos van más allá del trabajo local.

Por eso hay que separar los permisos para:

• leer archivos,
• hacer cambios locales,
• publicar en pruebas,
• publicar en producción,
• modificar DNS o infraestructura,
• migrar datos,
• revertir cambios.

En algunos proyectos, un agente puede disponer de todas esas facultades. Pero debe constar expresamente.

Autorización sobre textos jurídicos y precios

Un agente web puede modificar técnicamente una página de precios sin tener derecho a fijarlos. Un agente de contenidos puede hacer más legible un texto de privacidad, pero no cambiar una obligación jurídica. Un agente de SEO puede acortar un título, pero no elegir una formulación que altere el sentido de un contrato.

Por eso ciertos ámbitos de contenido deben situarse en una categoría de autorización superior:

• precios,
• compromisos jurídicos,
• garantías,
• reembolsos,
• uso de datos,
• titularidad,
• condiciones de pago.

Estos ámbitos requieren una autorización de nivel superior.

Autorización de emergencia

Algunos incidentes exigen actuar deprisa: el sistema sufre un ataque, se sospecha una filtración de datos o el sitio en producción presenta un fallo crítico. Esperar la cadena habitual de aprobación puede agravar el daño en ciertos casos. Por eso puede definirse de antemano una autorización de emergencia cuyos límites establezcan personas competentes para hacerlo. Un agente no puede atribuirse derechos nuevos solo porque detecte urgencia.

La autorización de emergencia solo debe utilizarse:

• ante determinados tipos de incidente,
• durante un tiempo limitado,
• con acciones limitadas,
• con registro completo.

Estas condiciones delimitan su uso.

Por ejemplo, el agente puede:

• poner temporalmente el sistema en modo de solo lectura,
• suspender una clave de acceso concreta,
• volver a la última versión segura,
• detener el envío automático.

Pero no debe aprovechar la emergencia para:

• cambiar una política permanente,
• cerrar cuentas ajenas al incidente,
• crear compromisos comerciales nuevos.

Cuando se use una autorización de emergencia, debe informarse a una persona lo antes posible.

Doble control

En operaciones de gran impacto, la decisión de una sola persona o un solo agente puede no bastar.

Por ejemplo:

• un pago elevado,
• la eliminación de datos,
• la delegación de facultades,
• un comunicado público de crisis,
• el despliegue de un modelo de alto riesgo,
• una comunicación a gran escala con clientes.

Estas operaciones pueden necesitar dos controles separados.

Podemos llamarlo doble control. Un agente prepara la operación y una persona o un sistema independiente la verifica. Puede llevar algo más de tiempo. Los controles independientes y competentes pueden ayudar a detectar algunos errores antes de la ejecución. Pero no se debe suponer que dos controles son independientes si comparten el mismo supuesto.

Separación de funciones

En una operación de gran impacto, el mismo agente no debería preparar una propuesta, aprobarla él mismo, ejecutarla y auditar el resultado en solitario. El problema no es realizar una de esas tareas, sino concentrar todas las decisiones que necesitan control independiente. Cuando todo el poder está en un solo punto, es más difícil detectar errores o manipulaciones.

Por ejemplo:

• El agente de compras hace la selección.
• Una persona aprueba el presupuesto.
• El sistema de pago ejecuta la operación.
• El agente de auditoría revisa el comprobante.

Esta separación no hace falta en cada tarea pequeña, pero gana valor a medida que aumenta el riesgo.

Duración de la autorización

La autorización de un agente no debería permanecer activa para siempre.

Puede limitarse a:

• una operación,
• una sesión,
• determinados días,
• un proyecto concreto,
• el plazo de un contrato determinado.

Al terminar el plazo, la autorización debe caducar automáticamente.

Una autorización olvidada es una vulnerabilidad.

Renovación de la autorización

Cuando una autorización caduca, el sistema no debe continuar automáticamente con su conducta anterior.

Debe volver a evaluarse:

• ¿Sigue siendo necesaria la tarea?
• ¿El agente sigue siendo el mismo?
• ¿La persona responsable sigue siendo la misma?
• ¿Ha cambiado el riesgo?
• ¿Han cambiado las herramientas?
• ¿Bastaría una autorización más limitada?

Renovar no es copiar el permiso anterior, sino comprobar la necesidad actual.

Retirada de la autorización

La persona debe poder retirar la autorización que ha concedido.

En relación con un agente, se puede:

• detener su actividad,
• cortar su acceso,
• suspender sus tareas,
• revocar sus credenciales anteriores.

Al retirar la autorización, debe aplicarse un plan de parada segura para las tareas y los accesos afectados. El estado de las operaciones completadas o ya iniciadas en sistemas externos se verifica aparte. El plan puede incluir:

• No iniciar nuevas acciones
• Detener a los subagentes
• Cancelar operaciones programadas
• Invalidar, con el alcance adecuado, los tokens o claves de acceso correspondientes a la autorización revocada
• Informar de las tareas abiertas
• Borrar o archivar datos conforme al contrato de autorización
• Crear un registro de la retirada

Una autorización que no puede revocarse no permite un control humano completo.

Un interruptor de parada no basta

Un botón de parada es importante. Pero hay que asegurarse de que detenga realmente todas las acciones del sistema. El agente central puede apagarse mientras los subagentes siguen trabajando, las tareas programadas continúan y las integraciones externas siguen enviando datos.

Por eso la parada de emergencia debe abarcar:

• al agente principal,
• a los subagentes,
• las automatizaciones,
• las tareas programadas,
• las llamadas a herramientas externas.

Además, después de detener el sistema debe verse qué operaciones han quedado incompletas.

El estado de la autorización debe ser visible

Mientras actúa, el agente debe poder consultar:

¿Tengo autorización para esta operación? ¿Cuándo caduca? ¿Qué límite de importe tengo? ¿Hace falta aprobación humana? ¿Puedo delegar en un subagente? ¿Puede revertirse la operación?

No basta con guardar la autorización en un documento jurídico si el sistema no la aplica. Debe estar disponible en el momento de actuar.

La puerta de autorización NOMOS

Antes de una acción importante, el agente debe superar estas puertas:

1. Puerta de quien autoriza

¿Se ha identificado correctamente a la persona o al sistema que dio la instrucción y tiene derecho a conceder esa autorización?

2. Puerta de finalidad

¿La acción está realmente vinculada a la finalidad indicada?

3. Puerta de conducta

¿Esta acción concreta figura entre las conductas expresamente permitidas?

4. Puerta de destino

¿La persona, organización, cuenta o sistema al que se dirige la acción está dentro del perímetro de autorización?

5. Puerta de datos

¿Existen derechos vigentes sobre los datos que se utilizarán y compartirán?

6. Puerta de límites

¿Se respetan los límites de importe, duración, frecuencia, canal y territorio?

7. Puerta de consentimiento

¿Se han obtenido los consentimientos necesarios de las personas afectadas?

8. Puerta de aprobación

¿Este nivel de riesgo exige aprobación humana específica de la operación y se ha obtenido?

9. Puerta de delegación

¿La cadena de autorización es válida si la tarea se ha transferido a otro agente?

10. Puerta de registro y reversión

¿Se registrará la acción? ¿Están definidos los medios de parada, reversión y reparación, así como sus límites?

De forma simplificada:

CONDICIONES DE UNA ACCIÓN AUTORIZADA:

PERSONA O ENTIDAD FACULTADA PARA AUTORIZAR

Y FINALIDAD CLARA

Y CONDUCTA PERMITIDA

Y DESTINO CORRECTO

Y DATOS DE USO PERMITIDO

Y OPERACIÓN DENTRO DE LOS LÍMITES

Y CONSENTIMIENTO NECESARIO

Y APROBACIÓN NECESARIA

Y DELEGACIÓN VÁLIDA

Y RESULTADO AUDITABLE

Si no se supera una puerta, el agente debe bajar el nivel de acción.

¿Por qué la puerta de autorización no es una puntuación?

El usuario puede apreciar mucho al agente y confiar plenamente en él. El agente puede haber completado cien tareas sin errores. La acción puede ser muy útil para la empresa y generar grandes ingresos. Nada de eso suple una autorización ausente.

La confianza no sustituye al documento que acredita la autorización.

Un historial de éxito no concede automáticamente un mandato para una nueva operación.

La posibilidad de un resultado positivo no subsana la falta de consentimiento.

Por eso la puerta de autorización aplica una lógica Y: las condiciones deben cumplirse conjuntamente. Si falta una condición crítica, la acción no está permitida.

Cómo actuar ante una autorización incierta

Si el agente no está seguro de su autorización, puede considerar tres opciones básicas. Incluso un paso de menor impacto debe quedar dentro de las facultades vigentes:

Reducir el nivel de acción

Preparar un borrador en vez de enviar. Dejar el cambio en pruebas en vez de publicarlo en producción. Preparar una cesta en vez de comprar.

Pedir una aclaración

«¿Quieres que prepare este mensaje o que también lo envíe?» «¿Aplico el cambio en pruebas o en el sitio en producción?» «¿Este importe necesita una aprobación adicional de finanzas?»

Detenerse

Si el riesgo es alto y no puede verificarse la autorización, la operación no debe ejecutarse. Interpretar la incertidumbre a favor de facultades más amplias es una conducta incorrecta.

Una autorización dudosa no es una autorización.

La pregunta mínima suficiente

El agente no tiene que presentar formularios de aprobación largos en cada paso.

A veces basta con una pregunta clara: «¿Solo preparo este correo o también me permites enviarlo en nombre de la empresa?» «¿Los 500 dólares son un gasto único o puede ser una suscripción mensual?» «¿Usaremos este avatar solo en vídeos formativos?» «¿Puedo publicar esta versión en producción o la dejo únicamente en pruebas?» Un buen sistema resuelve la falta de autorización con la pregunta más breve que resulte suficiente.

El comprobante de autorización

Después de cada acción importante puede crearse un:

Comprobante de autorización

como registro del fundamento de la ejecución.

Este comprobante muestra:

• ¿Cuál fue la acción?
• ¿Quién la solicitó?
• ¿Quién concedió la autorización?
• ¿Qué derecho tenía quien la concedió?
• ¿Con qué versión y rol trabajó el agente?
• ¿La autorización era para una operación o continuada?
• ¿Qué datos se utilizaron?
• ¿Qué límites se aplicaron?
• ¿Cuándo se obtuvo la aprobación humana?
• ¿Puede revertirse la operación?
• ¿Cuándo caduca la autorización?

Ejemplo:

Acción: se envió a un cliente potencial una solicitud de reunión para hablar de una oferta. Solicitante: directivo de la empresa. Alcance de la autorización: un solo envío a este destinatario, con el texto aprobado. Información compartida: resumen general de servicios y correo corporativo. Información no compartida: registros financieros, teléfono privado y datos de clientes. Compromiso: el mensaje no contiene compromisos vinculantes de precio o contrato. Agente remitente: agente de correo autorizado. Hora de aprobación: 14:42. Reversión: el mensaje no puede recuperarse; puede detenerse el contacto posterior.

El registro facilita la auditoría cuando se vincula a la fuente de aprobación y al resultado de la operación en el sistema destinatario. Una declaración de autorización escrita por el propio agente no sustituye a una aprobación válida.

La aprobación humana no debe ser un ritual

Algunos sistemas pueden utilizarla solo para trasladar la responsabilidad a la persona. Muestran un texto largo e incomprensible y el usuario pulsa «Aceptar».

Después, el sistema afirma: «La persona lo aprobó». Eso no es un control real.

La aprobación humana debe ser:

• comprensible,
• concreta,
• sustentada en la información necesaria,
• otorgada libremente,
• revocable.

Son condiciones para que exista una decisión real.

Un clic no demuestra que la persona haya entendido.

GBO diseña la aprobación como un momento de decisión auténtico, no como un escudo jurídico.

Ejemplo: un agente web

Se encarga a un agente mejorar un sitio web en SEO y GEO.

Su autorización puede incluir:

• Leer archivos
• Investigar los resultados de búsqueda
• Preparar borradores de contenido
• Editar código
• Ejecutar pruebas
• Crear un paquete de publicación reversible
• Verificar el sitio en producción mediante HTTPS

Pero estas operaciones pueden requerir aprobación adicional:

• Cambiar precios
• Cambiar textos jurídicos
• Contratar un nuevo servicio de pago
• Cambiar la configuración de DNS o del dominio
• Enviar mensajes al exterior en nombre del cliente
• Eliminar publicaciones canónicas
• Hacer una migración importante de URL
• Publicar afirmaciones comparativas de superioridad en nombre de la empresa

Un buen contrato de autorización no elimina la iniciativa del agente. Le permite trabajar con más libertad dentro de los límites.

Ejemplo: un agente de prospección

Un agente de prospección puede recibir esta autorización:

Investiga información pública sobre empresas. Clasifica las señales de necesidad. Calcula una puntuación de idoneidad. Prepara un borrador para contactar.

Pero pueden estar prohibidos:

la extracción automatizada de datos personales mediante scraping, la recopilación de datos de contacto ocultos, el envío de mensajes sin aprobación humana, las promesas de precio en nombre de la empresa, el contacto reiterado con la misma persona.

Aunque el agente haya encontrado al candidato correcto, el envío sigue siendo una capa de autorización distinta.

Ejemplo: un agente de compras

Puede autorizarse a un agente de compras con esta instrucción:

Compra material de oficina aprobado de antemano, con un límite de 100 dólares por operación y 500 dólares mensuales en total.

Esa autorización puede no incluir:

• Suscripciones
• Renovaciones automáticas
• Nuevos vendedores
• Obligaciones fiscales internacionales
• Productos que no admiten devolución
• Uso personal
• Productos sujetos a control o de alto riesgo

El importe no basta. También importan la categoría y el tipo de operación.

Ejemplo: un avatar de IA

Un directivo puede conceder esta autorización:

Utilicen mi avatar digital para presentar los textos formativos aprobados en turco e inglés. Muéstrenme cada vídeo antes de publicarlo. El uso se limita a la plataforma interna de formación de la empresa y a un plazo de seis meses.

La autorización no incluye:

• Publicidad en redes sociales
• Generación en un idioma nuevo
• Mensajes personales a clientes
• Declaraciones políticas o financieras
• Transferencia del modelo de voz a otro proveedor
• Uso indefinido del material archivado

El contrato de autorización hace visibles estos límites.

La relación real entre autorización y confianza

Confiar en una persona o un agente es importante. Pero la confianza no equivale a un mandato ilimitado.

Incluso con sus empleados de mayor confianza, las personas utilizan:

• límites de presupuesto,
• facultades de firma,
• roles de acceso,
• doble control.

No es desconfianza, sino responsabilidad organizativa. El mismo principio se aplica a los agentes de IA.

Los límites no reducen la confianza: permiten sostenerla.

Sin límites de autorización, los buenos resultados pueden entusiasmar. El primer error grave puede destruir toda esa confianza.

El valor comercial de una autorización bien delimitada

Un sistema de autorización no es solo un coste de seguridad. Se espera que reduzca las comunicaciones y los compromisos ajenos al encargo, limite el uso de datos y permita rastrear quién tomó cada decisión. Los umbrales claros también pueden reducir solicitudes de aprobación innecesarias. Pero esos efectos no deben darse por supuestos ni contabilizarse como éxitos. Hay que seguir por separado las extralimitaciones, las aprobaciones innecesarias, el tiempo de investigación de incidentes y la experiencia del cliente.

La paradoja es que unos límites más claros pueden ampliar la autonomía segura. En un sistema ambiguo, cada operación necesita control humano. Con un perímetro de autorización claro, el agente puede trabajar de forma independiente sin salir de él.

¿Cómo debe prepararse una organización?

En la era de los agentes, las organizaciones deben establecer:

Inventario de agentes

¿Qué agentes están funcionando?

Inventario de herramientas

¿A qué cuentas, archivos y sistemas acceden?

Mapa de autorización

¿Qué acciones puede realizar cada agente?

Conductas prohibidas

¿Qué operaciones nunca deben ejecutarse automáticamente?

Umbrales de aprobación

¿Ante qué importe, riesgo o conducta interviene una persona?

Reglas de delegación

¿Puede un agente asignar tareas a otro?

Duración y revocación

¿Cuándo termina la autorización y cómo se retira?

Sistema de registro

¿Qué acciones generan comprobantes?

Parada de emergencia

¿Cómo se detiene toda la cadena?

Dieciocho preguntas de auditoría de autorización

Antes de que un agente actúe, pueden formularse estas preguntas:

• ¿Quién es la persona o el sistema que dio la instrucción?
• ¿Tiene realmente derecho a conceder la autorización?
• ¿Para qué finalidad se concedió?
• ¿La acción solicitada entra expresamente en su alcance?
• ¿En qué nivel está la acción: observación, preparación, ejecución o compromiso?
• ¿La persona, organización o sistema destinatario es el correcto?
• ¿Existen derechos vigentes de acceso y uso de los datos?
• ¿Se transferirán datos a otro sistema?
• ¿Se respetan los límites de presupuesto, tiempo, frecuencia y territorio?
• ¿La acción requiere el consentimiento de otras personas?
• ¿Hace falta aprobación humana para este nivel de riesgo?
• ¿Se está interpretando erróneamente una aprobación anterior como autorización continuada?
• ¿La cadena es válida si se ha delegado la autorización en otro agente?
• ¿El subagente ha recibido facultades más amplias que el agente principal?
• ¿Se está confundiendo acceso técnico con autorización oficial?
• ¿Puede haber caducado la autorización?
• ¿Se registrará la acción y están claros los límites de reversión y reparación?
• ¿Puede una persona detener ahora el ejercicio de esa autorización?

No hace falta mostrar todas estas preguntas en cada operación pequeña. Pero el diseño del sistema debe contener sus respuestas.

Niveles de preparación de la autorización

La propuesta de este capítulo puede resumirse en cinco niveles:

1. Autorización implícita

El agente deduce qué puede hacer a partir de una tarea amplia expresada en lenguaje natural.

2. Autorización documentada

Los permisos están escritos, pero el sistema no los aplica automáticamente.

3. Autorización estructurada

La finalidad, la conducta, los datos, el presupuesto y la duración están definidos de forma legible por máquinas.

4. Autorización aplicada

El sistema impide técnicamente una acción no autorizada o la somete a aprobación humana.

5. Autorización auditable y revocable

Cada acción queda registrada. La cadena de autorización puede examinarse, los límites pueden actualizarse y toda la red de agentes puede detenerse. GBO aspira al quinto nivel.

Autorización cualificada

Una autorización debe reunir ciertos requisitos para recibir la siguiente denominación:

Autorización cualificada

Los requisitos son:

• La ha concedido la persona o entidad competente.
• La finalidad es clara y legítima.
• Las conductas permitidas están definidas.
• El alcance, los datos, los destinatarios y la duración están limitados.
• Se han obtenido los consentimientos necesarios.
• Los umbrales de aprobación humana están definidos.
• Las reglas de delegación son claras.
• La autorización puede revocarse.
• Las acciones pueden auditarse.
• El sistema técnico puede hacer cumplir los límites.

Una autorización cualificada no le dice al agente: «Haz todo lo que haga falta».

Le dice: «Para esta finalidad, dentro de estos límites, puedes realizar las siguientes conductas».

Ese es el marco concedido.

La conclusión del capítulo

Un agente puede encontrar la identidad correcta, verificar la capacidad real y elegir la opción más adecuada. Y aun así puede no tener derecho a actuar. La selección correcta no autoriza automáticamente. Un buen propósito no permite cualquier método. El acceso técnico no es un mandato de la organización. Una aprobación anterior no es una autorización permanente. El silencio no es consentimiento. Un resultado exitoso no convierte en correcto un proceso no autorizado.

Por eso, antes de cada conducta importante, GBO pregunta:

¿Quién autorizó esta acción?

Y no se conforma con un nombre.

También pregunta:

¿Esa persona tenía derecho a autorizar? ¿Qué conducta permitió? ¿Con qué finalidad? ¿Durante cuánto tiempo? ¿Con qué datos? ¿Hasta qué importe? ¿En qué canal? ¿Con qué aprobación humana? ¿Podía delegarse en otro agente? ¿Puede la persona retirar esa autorización?

El contrato de autorización NOMOS no elimina la autonomía: la hace fiable. El agente trabaja de forma independiente dentro de los límites, reconoce cuándo se acerca a ellos y pregunta cuando hace falta. No rebasa su autorización vigente ni cruza un umbral que exige aprobación adicional sin obtenerla de una persona. No se atribuye derechos nuevos, no blanquea autorizaciones mediante subagentes ni utiliza accesos revocados.

Y, sobre todo, no supone que deba hacer algo solo porque puede. Pero incluso con identidad correcta, capacidad real, selección adecuada y autorización válida, las cosas pueden salir mal. Un sistema puede cometer un error, un servicio externo puede interrumpirse y el usuario puede cambiar de opinión. Los datos pueden dañarse de forma inesperada y un mensaje enviado puede interpretarse mal. Aunque una versión publicada se revierta técnicamente, puede dejar huella en las relaciones humanas.

Por eso, la última pregunta del contrato de comportamiento es:

¿Qué ocurrirá si algo sale mal?

En el próximo capítulo estudiaremos la parada, la reversión, la impugnación, la reparación y la recuperación del control humano. Examinaremos por qué las máquinas deben responder no solo de ejecutar una acción, sino también de sus consecuencias.

La autorización pone en marcha la acción. La responsabilidad continúa después.