¿Quién decide cuando un agente delega?
Una cesión no vacía la silla
Un agente delega una tarea. Otro agente reúne material, compara registros, llama a una herramienta o prepara una recomendación. Un tercer agente comprueba el resultado. El trabajo se mueve, y ese movimiento puede ser útil. También puede crear un problema de gestión muy antiguo con una forma nueva: todos han hecho algo, pero nadie puede decir quién estaba facultado para tomar la decisión.
La respuesta tentadora es el agente que hizo la última llamada. También suele ser la menos útil. Un componente de software puede seleccionar una ruta, pedir más trabajo y enviar una instrucción a un sistema conectado. Ninguna de esas cosas establece quién aceptó el propósito, quién fijó el límite, quién pudo haber rechazado la acción o a quién había que informar cuando cambiaron las condiciones. Solo establece que un programa formaba parte de la cadena.
Esa distinción se vuelve nítida cuando un flujo de trabajo tiene consecuencias. Una respuesta sugerida puede convertirse en una comunicación con el cliente. Una clasificación puede convertirse en el motivo por el que un caso se coloca en una cola determinada. Una comparación puede convertirse en una recomendación de compra. Una instrucción de pago redactada puede convertirse en un pago. Cada paso puede ser técnicamente competente y, aun así, estar organizativamente incompleto. El sistema ha hecho el trabajo de la delegación sin hacer el de la autoridad.
No hace falta inventar un fallo dramático para ver el problema. Tomemos un flujo de trabajo deliberadamente hipotético. Un agente de clasificación recibe una pregunta, pide a un agente de investigación que examine el material pertinente, envía el resultado a un revisor y luego prepara una acción para un sistema de gestión de casos. El agente de investigación no está autorizado a actuar. El revisor no está autorizado a hacer efectivo el resultado del caso. El agente de clasificación tiene una credencial de herramienta. La organización no ha especificado si esa credencial le permite confirmar el resultado. El flujo de trabajo puede parecer ordenado en un panel de control. Sin embargo, ha llegado a la pregunta más importante sin respuesta.
La delegación no es la desaparición de la responsabilidad. Es la responsabilidad hecha más difícil de ver. Un buen diseño operativo la hace más fácil de nuevo. Dice cuál es la decisión inicial, qué se puede delegar, qué condiciones viajan con la tarea, quién puede aprobar una acción irreversible o con consecuencias, qué registro queda después de la cesión y cómo una persona o un sistema puede intervenir cuando la ruta ya no es segura. No se pide a la tecnología que posea capacidad moral. Se le pide que deje intacta la capacidad de la organización.
Ese es el significado práctico de la rendición de cuentas en un flujo de trabajo con múltiples agentes. No es una línea decorativa en una política, ni una búsqueda retrospectiva del empleado más cercano cuando algo sale mal. Es una propiedad de la ruta antes de que comience el trabajo. La persona adecuada puede inspeccionar lo propuesto, entender por qué se propuso, ejercer la autoridad que se le asignó y dejar un registro que pueda cuestionarse después.
Las nuevas normas de IA en Europa son útiles aquí porque les interesan menos las personas teatrales al final de un flujo que las condiciones en las que la supervisión puede funcionar de verdad. Las disposiciones de supervisión humana de la Ley de IA se aplican a los sistemas de alto riesgo, no a todos los usos de un agente. Ese límite importa. Pero las preguntas operativas de la Ley funcionan bien en otros contextos: ¿puede una persona física asignada comprender las capacidades y los límites pertinentes, supervisar anomalías y rendimientos inesperados, evitar la dependencia excesiva, interpretar los resultados, descartarlos o revertirlos, e interrumpir el sistema hasta un estado seguro? Un flujo de trabajo con muchos agentes no hace esas preguntas más pequeñas. Multiplica los lugares donde la respuesta puede perderse.
La delegación es una cadena, no una niebla
La gente delega constantemente. Un responsable pide a un colega que prepare una nota. Un equipo de compras pide a un experto que inspeccione una cláusula contractual. Un clínico pide a un laboratorio un resultado. La persona que recibe la tarea adquiere un rol definido en el trabajo; no hereda automáticamente toda autoridad de quien la pidió. Las buenas organizaciones marcan esta distinción cotidiana con descripciones de puesto, límites de aprobación, procedimientos, segregación de funciones y registros. Lo hacen porque la capacidad y el permiso son cosas distintas.
Los sistemas de agentes tienden a difuminar esa distinción porque un agente puede describir, planificar y ejecutar en una misma superficie conversacional. Un modelo puede ser capaz de generar un plan convincente para contactar con un proveedor. Un envoltorio de herramienta puede ser técnicamente capaz de enviar el mensaje. Una capa de orquestación puede ser capaz de llamar a ese envoltorio sin una pausa. Esos hechos describen capacidad. No deciden si el mensaje debe enviarse, si el destinatario propuesto está dentro del alcance, si la información es apropiada para divulgarse, ni quién debe aceptar la consecuencia si la acción propuesta es incorrecta.
Conviene separar cinco preguntas que a menudo van juntas. ¿Quién dio a la tarea su propósito? ¿Quién puede realizar el trabajo preparatorio? ¿Quién puede delegar una subtarea? ¿Quién puede decidir que una acción propuesta es aceptable? ¿Quién puede hacer efectiva esa acción en el mundo exterior? A veces un único rol humano ostenta legítimamente varias de esas respuestas. A veces deben separarse. La cuestión no es crear una ceremonia elaborada para una nota de bajo riesgo. La cuestión es evitar tratar en silencio una capacidad técnica como una transferencia de autoridad institucional.
Una delegación debe, por tanto, llevar más que una instrucción. Debe llevar un mandato. El mandato identifica el objetivo, el contexto acotado, las entradas permitidas, la salida esperada, las acciones que siguen prohibidas, el presupuesto o límite de tiempo cuando proceda, las condiciones que exigen escalar, y la persona o rol responsable del resultado. El agente receptor puede entonces hacer trabajo útil dentro de un marco visible. Puede pedir análisis a otro agente. No puede ampliar el marco solo porque se le ocurra un paso siguiente plausible.
Esto no es un argumento para convertir cada interacción en una reunión de aprobación. Es un argumento para elegir el punto en el que la organización desea que ocurra una decisión. Un sistema puede redactar una explicación sin que una persona revise cada frase cuando el propósito, la audiencia, el límite de la fuente y las reglas de publicación ya están fijados. Un sistema no debería adquirir el poder de cambiar el derecho de un cliente solo porque el mismo componente tiene acceso a la base de datos pertinente. La diferencia es la consecuencia, no la inteligencia del modelo.
Esa consecuencia suele estar distribuida. Una tarea puede ser inofensiva en una fase y trascendente en la siguiente. Leer un archivo puede ser rutinario. Combinarlo con otra fuente puede cambiar la sensibilidad del material. Preparar una recomendación puede ser rutinario. Pulsar un botón que genera un resultado legal, financiero o de servicio puede no serlo. Un diseño de gobernanza que solo pregunta si un agente es autónomo pasa por alto este cambio de estado. La pregunta útil es más concreta: ¿autónomo para hacer qué, para quién, bajo qué condiciones y con la autoridad de quién?
Hay un modesto instinto neerlandés que conviene conservar aquí. Si un proceso necesita una docena de firmas, sellos y un organigrama plastificado para establecer quién puede pulsar un botón, quizá no sea un triunfo de la gobernanza. Pero la disposición contraria, en la que una credencial de herramienta se trata como un acuerdo constitucional, tampoco lo es. El objetivo es una vía proporcionada que deje clara la autoridad trascendente sin montar una pequeña ópera en torno a cada acción rutinaria.
La supervisión europea es un requisito operativo
La Ley de IA ofrece la expresión jurídica más clara de esta idea para los sistemas de IA de alto riesgo. El artículo 14 exige que se diseñen y desarrollen de modo que las personas físicas puedan supervisarlos eficazmente mientras estén en uso. La finalidad declarada es prevenir o minimizar los riesgos para la salud, la seguridad y los derechos fundamentales cuando esos riesgos puedan persistir a pesar de otros requisitos. Las medidas deben ser proporcionales al riesgo, a la autonomía y al contexto de uso. Es una norma deliberadamente operativa. No dice que una persona en algún lugar de la organización tenga un interés general por la IA.
La disposición va más allá de una instrucción genérica de mantener a un humano en el circuito. Según lo que sea adecuado y proporcionado, la persona asignada a la supervisión debe poder comprender las capacidades y limitaciones pertinentes, supervisar el funcionamiento y detectar anomalías, disfunciones o rendimientos inesperados, ser consciente del sesgo de automatización, interpretar los resultados, decidir no utilizar un resultado o ignorarlo, anularlo o revertirlo, e intervenir o interrumpir el sistema hasta dejarlo en un estado seguro. La ley no convierte esto en una lista de verificación universal para todos los sistemas de agentes. Pero sí muestra por qué un sello de goma al final del proceso es un mal modelo de supervisión.
Ahora añadamos la delegación. Si un agente entrega una tarea a otro agente, la función de supervisión debe poder ver algo más que la frase final producida por el último modelo. Necesita suficiente contexto para entender qué agente propuso la subtarea, qué fuentes o herramientas se usaron, si se encontró un límite de política, si un revisor cambió un resultado y si un agente posterior amplió el alcance. De lo contrario, el humano puede ver un resultado, pero no la ruta que lo produjo. Eso puede bastar para un borrador de baja trascendencia. No es una base convincente para aceptar una decisión trascendente.
El artículo 26 expresa el punto organizativo con aún más claridad para los responsables del despliegue de sistemas de alto riesgo. Dice que los responsables del despliegue deben asignar la supervisión humana a personas físicas con la competencia, la formación, la autoridad y el apoyo necesarios. Esas palabras van juntas. Competencia sin autoridad crea un espectador bien informado. Autoridad sin competencia crea un propietario formal que no puede cuestionar el sistema. Ambas sin apoyo crean una persona a la que se espera que intervenga en un proceso que no puede ver, a un ritmo que no puede seguir y con información que no puede interpretar.
En el trabajo con múltiples agentes, el soporte incluye la forma de la interfaz y del registro. Un operador no necesita todos los tokens que generó un modelo ni todos los reintentos internos. Lo que sí necesita es la acción propuesta, el propósito designado, la evidencia material, la política y el límite aplicables, los cambios realizados desde el último punto de revisión, el efecto esperado, la posible vía de reversión y el motivo por el que se escaló el caso. Esto no es tanto una cuestión de hacer que un panel de control parezca tranquilizador como de reducir la probabilidad de que una persona apruebe una respuesta porque el sistema ha hecho que la alternativa resulte agotadora de encontrar.
El Convenio Marco del Consejo de Europa sobre Inteligencia Artificial y Derechos Humanos, Democracia y Estado de Derecho establece la conexión institucional más amplia. Su finalidad es garantizar que las actividades en el ciclo de vida de los sistemas de IA sean coherentes con los derechos humanos, la democracia y el Estado de Derecho. Los artículos 8 y 9 exigen transparencia y supervisión adaptadas a contextos y riesgos específicos, así como rendición de cuentas y responsabilidad por los impactos adversos. El Convenio no prescribe un patrón de orquestación de agentes. Pero sí constituye un correctivo útil frente a la idea de que una cadena de componentes de software puede disolver las responsabilidades de la autoridad pública o del actor privado que la utiliza.
Esa visión más amplia importa porque una decisión delegada puede afectar a algo más que al rendimiento técnico. Puede afectar a la capacidad de una persona para comprender una decisión, impugnarla, obtener reparación o simplemente saber qué organización es responsable. Un flujo de trabajo puede estar compuesto por componentes de varios proveedores, modelos de varios proveedores, herramientas gestionadas por otro equipo y un servicio prestado en virtud de un contrato público. El hecho de que la cadena esté técnicamente distribuida no hace que el impacto sobre el individuo sea menos real. En la práctica, hace que una asignación clara de funciones sea más importante.
La protección de datos advierte de lo mismo desde otra dirección. El trabajo del Comité Europeo de Protección de Datos sobre los modelos de IA subraya que el análisis de protección de datos sigue siendo contextual: las organizaciones deben determinar su función, identificar el tratamiento implicado y aplicar las obligaciones pertinentes, en lugar de tratar la etiqueta de modelo de IA como una exención de la rendición de cuentas ordinaria. Cuando un flujo de trabajo con múltiples agentes trata datos personales, la delegación no debe ocultar quién determina los fines y los medios del tratamiento, qué agente o herramienta recibe qué datos y si la siguiente transferencia es necesaria para la tarea. Una subtarea sigue siendo un paso de tratamiento. Llamarla delegación no hace que desaparezca.
Nada de esto ofrece una respuesta mágica para todos los casos difíciles. Las obligaciones legales dependen del uso, los actores, los datos y el sector. Un artículo no puede clasificar un sistema concreto. Pero sí puede enunciar un principio disciplinado: si un flujo de trabajo distribuye el trabajo, debe distribuirlo de manera que preserve la capacidad de identificar la autoridad, intervenir a tiempo, dar cuenta de la ruta y responder a las personas afectadas por el resultado.
La persona en el circuito necesita un circuito real
La supervisión humana se reduce fácilmente a una pantalla con un botón de aprobar. Esa pantalla puede ser útil. También puede ser un objeto ceremonial. La cuestión es si la persona que la utiliza tiene una elección significativa. Una elección no es significativa solo porque la interfaz muestre dos botones. Depende de si la persona tiene suficiente tiempo, información, competencia y permiso institucional para decidir de otro modo.
El tiempo es la parte menos glamurosa del diseño y, a menudo, la más decisiva. Si el sistema envía cientos de propuestas en un periodo en el que un revisor razonablemente solo podría inspeccionar una fracción, la organización ha creado una cola, no una supervisión. Si la propuesta caduca antes de que el revisor pueda obtener contexto, el sistema ha convertido la velocidad en el tomador de decisiones efectivo. Si un equipo solo recibe recompensas por el rendimiento, se le ha dado una instrucción silenciosa sobre qué botón pulsar. El software no puede curar estas disposiciones añadiendo una puntuación de confianza en un tono de verde diferente.
La información debe ser proporcionada, no exhaustiva. A un revisor que solo recibe una conclusión no se le puede exigir que la cuestione. A un revisor que recibe una transcripción bruta de cada interacción de los agentes tampoco se le puede exigir, por lo general, que la cuestione. El punto medio útil es un paquete de decisión. Identifica qué acción se propone, por qué está dentro del propósito declarado, qué evidencia material la respalda, qué incertidumbre persiste, qué política o regla es relevante, cuál es el efecto propuesto y qué ocurriría si la acción no se aprueba. El paquete debe enlazar con evidencia más profunda, pero no debe exigir una expedición arqueológica para el caso ordinario.
La competencia significa más que un curso genérico sobre IA. Para la tarea en cuestión, el revisor debe comprender el tipo de resultado, las limitaciones conocidas que podrían importar, la forma en que se espera que funcione el flujo de trabajo y las señales que requieren escalado. Una persona que puede reconocer una factura de proveedor defectuosa puede estar bien situada para revisar una propuesta relacionada con facturas. Esa misma persona puede no estar bien situada para evaluar la cobertura lingüística de un modelo o una implicación de protección de datos. Asignar la supervisión es, por tanto, también una decisión de personal.
El permiso institucional es la prueba que muchos diseños suspenden en silencio. El revisor debe poder rechazar, pausar o cambiar la ruta propuesta sin ser tratado como la fuente de un fallo del sistema. Necesita acceso a una persona o rol que pueda decidir qué ocurre a continuación. Necesita una forma de registrar que el asunto se escaló. Y el sistema necesita un estado seguro en el que el trabajo pueda esperar sin ser comprometido accidentalmente por un reintento, un tiempo de espera o un agente diferente que tome la instrucción original como un asunto pendiente.
La ingeniería de seguridad ha tratado durante mucho tiempo el rendimiento humano como parte del sistema, en lugar de una capa final de barniz. La Agencia Ejecutiva de Salud y Seguridad del Reino Unido describe los factores humanos como la tarea, el individuo y la organización en conjunto, y advierte contra considerarlos de forma aislada. Ese es un marco sensato para la supervisión de agentes. Un revisor no es un tapón humano abstracto para una brecha de software. Está realizando una tarea concreta, con información y herramientas concretas, dentro de una organización concreta con presiones y límites concretos. La calidad del control depende de todo ello.
Por esa razón, un buen diseño de supervisión humana comienza antes de que aparezca el botón. Define qué decisiones necesitan una barrera humana, quién la mantendrá, qué evidencia recibirá, cuánto tiempo permite la tarea, qué ocurre cuando la persona está ausente y si la barrera tiene autoridad sobre la acción en sí o solo sobre una explicación de la acción. Si la organización no puede responder a esas preguntas un martes tranquilo, no será más claro cuando llegue un caso de alto impacto. Tampoco debería necesitar una crisis imaginaria para darse cuenta.
Una tarea, varios tipos de autoridad
Un modelo de autoridad compacto puede facilitar la operación de un flujo de trabajo de agentes. No necesita ser grandioso. Empieza por la diferencia entre leer, proponer, delegar, comprometer y detener. Un rol con permiso de lectura puede inspeccionar el material necesario para una tarea. Un rol con permiso de propuesta puede preparar una acción posible. Un rol con permiso de delegación puede asignar trabajo acotado a otro actor. Un rol con permiso de compromiso puede hacer efectiva una acción con consecuencias. Un rol con permiso de detención puede pausar o detener una ruta cuando sus condiciones dejan de cumplirse.
Estos no son simplemente rangos. Un revisor de cumplimiento puede detener un flujo de trabajo pero no comprometer un resultado de cliente. Un agente especializado puede proponer una ruta pero no delegar trabajo nuevo fuera de su dominio. Un responsable puede rendir cuentas por el propósito de un servicio y aun así no ser la persona autorizada para liberar un pago concreto. La propiedad útil no es una jerarquía por sí misma. Es que el sistema pueda evaluar si un actor concreto tiene la autoridad pertinente para una acción concreta en el contexto actual.
El contexto hace gran parte del trabajo. La misma acción propuesta puede ser ordinaria en una circunstancia y tener consecuencias en otra. Enviar una plantilla ya aprobada a una dirección interna conocida puede estar dentro de un mandato de comunicación rutinario. Enviar un mensaje recién redactado con datos personales a un destinatario nuevo es distinto. Un reembolso dentro de un umbral definido puede delegarse en un proceso bien probado. Un cambio en un derecho, una eliminación de datos o un compromiso externo puede requerir una decisión humana nominada. La política debe expresar esa distinción antes de que se pida al modelo planificar en torno a ella.
También hay una diferencia importante entre una aprobación y un acuse de recibo. Un acuse de recibo registra que alguien vio un mensaje. Una aprobación registra que una persona autorizada aceptó una acción definida, con el contexto pertinente, en un punto definido de la ruta. En un sistema conversacional ambos pueden parecer similares. El registro no debería serlo. Si un revisor posterior no puede distinguir qué acción se aprobó y qué efecto se esperaba, la organización ha registrado una conversación en lugar de capturar una decisión.
La delegación en sí misma necesita límites. Un agente que recibe la tarea de comparar tres propuestas existentes puede tener permiso para pedir a un agente de investigación que extraiga los términos pertinentes. No debe tratar ese permiso como una invitación a contactar con proveedores, adquirir datos nuevos o reformular el objetivo de la contratación. El límite puede expresarse en la política, en el alcance de las herramientas, en un contrato de tarea estructurado o en los tres. Lo que importa es que sea lo bastante exigible como para restringir la ruta y no solo describir el comportamiento deseado a posteriori.
La profundidad de delegación es otro límite que merece la pena nombrar. Una persona puede encomendar una tarea a un agente y aun así conservar una visión clara de su primera transferencia. Tras varias transferencias anidadas, el propósito original puede estar técnicamente presente en los metadatos pero ser prácticamente invisible. Las organizaciones pueden establecer una profundidad máxima de delegación para una clase de trabajo, exigir una revisión a una profundidad determinada o prohibir que un delegado cree más delegados sin una nueva autorización. Son decisiones de diseño, no requisitos universales. Resultan más útiles cuando una cadena más larga dificulta ver qué actor introdujo una nueva suposición o cambió el alcance efectivo.
La autoridad sobre las herramientas también debe separarse de la autoridad del modelo. Un modelo puede elegir una herramienta basándose en un plan. La integración de la herramienta debe comprobar igualmente si la acción solicitada, el objetivo, la categoría de datos, el límite de recursos y el estado del flujo de trabajo permiten la llamada. Esto no es desconfianza del modelo en un sentido moral. Es diseño de límites ordinario. Un plan bien formado puede seguir siendo inapropiado para el caso actual, y un plan mal formado no debería hacerse realidad simplemente porque llegó a una credencial con acceso amplio.
Lo mismo ocurre con la recuperación. Un reintento no siempre es inofensivo. Reintentar una solicitud para leer un documento público no es lo mismo que reintentar una solicitud que envía un mensaje o realiza un cargo. Cuando una tarea delegada falla, un flujo de trabajo necesita una elección explícita entre reintentar, redirigir, escalar, pausar y fallar de forma controlada. Tratarlos como un único gestor de errores genérico es cómo una decisión operativa se toma silenciosamente mediante la configuración predeterminada. El entorno de ejecución del agente puede poner las opciones a disposición. La organización debe decidir qué opción se aplica a cada clase de acción.
El fallo suele ser una decisión que falta
Cuando la gente oye la palabra fallo, a menudo se imagina a un agente que produce una afirmación falsa o a una herramienta que agota el tiempo. Ambos pueden importar. Los fallos más reveladores en el trabajo delegado suelen ser más silenciosos. La tarea se asignó sin un responsable claro. La propuesta cruzó un límite que nadie había modelado. El revisor podía ver la conclusión pero no las pruebas. Un reintento continuó después de una pausa. Una persona notó un problema pero no tenía autoridad para detener la acción. Se tomó una decisión, pero el registro conservó solo el resultado final y no la condición que lo hacía aceptable.
Estas no son afirmaciones sobre un incidente concreto. Son modos de fallo derivados de la propia estructura de la delegación. También pueden encontrarse en procesos humanos. En el software, sin embargo, pueden viajar a la velocidad de la automatización y repetirse de forma muy consistente. Esa consistencia no es motivo de desesperación. Es un motivo para tratar el diseño del flujo de trabajo como parte del control, en lugar de suponer que las pruebas de precisión de un componente del modelo resuelven la cuestión.
Consideremos otro diseño explícitamente hipotético. Se pide a un agente que prepare un resumen de un caso. Delega la extracción de documentos a un componente y la normalización del lenguaje a otro. Un tercer componente ve un campo incompleto y utiliza una fuente de conocimiento conectada para rellenar el vacío. El resumen final se lee con fluidez. Si el flujo de trabajo no ha registrado el campo que faltaba, la fuente utilizada para rellenarlo, la confianza o incertidumbre que la acompañaba y el hecho de que la tarea original solo permitía resumir, un revisor no puede saber si está aprobando un resumen o una afirmación fáctica recién creada. El problema no es que la última frase suene extraña. El problema es que el significado de la tarea cambió dentro de la ruta.
Una respuesta sensata no es prohibir la delegación. Es dejar constancia de los puntos de cambio en el registro. Una nueva fuente, una nueva herramienta, una nueva categoría de datos, una nueva clase de acción, un cambio material en el nivel de confianza, un control fallido, una cadena de delegación más larga de lo permitido o una propuesta para cruzar un límite externo pueden ser, cada uno, un motivo para sacar el trabajo a revisión. Los desencadenantes exactos variarán según el contexto. El principio es estable: un cambio que le importaría al propietario responsable no debería permanecer invisible por haberse producido entre componentes.
Este es un lugar donde resulta útil el pensamiento de caso de seguridad. Un caso de seguridad no es una promesa de que nada pueda salir mal. Es un argumento estructurado sobre por qué un sistema es aceptable para un fin definido bajo condiciones definidas, con la evidencia, las suposiciones, los controles y los riesgos residuales a la vista. Aplicado con cuidado a un flujo de trabajo de agentes, eso significa que la afirmación no es que los agentes sean seguros en general. La afirmación es más acotada: esta ruta puede usarse para este fin, con estos límites, porque existen estos controles y acuerdos de supervisión, y debe reconsiderarse cuando las suposiciones declaradas dejen de cumplirse.
Entonces es más fácil cuestionar el flujo de trabajo. Un operador puede preguntar si la clase de acción se asignó correctamente. Un propietario de riesgos puede preguntar si el revisor todavía tiene tiempo suficiente. Un ingeniero puede preguntar si un reintento podría crear un efecto duplicado. Un especialista en protección de datos puede preguntar si la subtarea sigue siendo necesaria y proporcionada. Una persona afectada por un resultado puede, cuando el marco aplicable lo exija, disponer de una vía para impugnar la decisión. Esas preguntas no son burocracia añadida después del interesante trabajo técnico. Son el trabajo de hacer que el sistema técnico rinda cuentas dentro de una organización.
Las métricas deberían seguir la misma disciplina. Contar el número de tareas delegadas nos dice algo sobre el volumen, no sobre una operación responsable. Medidas más útiles pueden incluir la tasa a la que un flujo de trabajo escala porque cambió un límite, el tiempo que una decisión espera en un punto de control, la proporción de acciones de consecuencia con un paquete de decisión completo, el número de reversiones exitosas o el número de casos en que una comprobación de política rechazó una llamada a una herramienta. Tales mediciones aún necesitan una definición y un contexto. Nunca deberían inventarse para un folleto. Pero diseñar los registros de modo que puedan medirse es una señal de que la rendición de cuentas se trata como una propiedad operativa.
El registro es donde sobrevive la responsabilidad
Un sistema multiagente produce un tipo incómodo de historial. Tiene mensajes, llamadas a herramientas, salidas intermedias, comprobaciones de política, versiones de modelo, información de tiempos, reintentos, asignaciones cambiadas y quizás aprobaciones humanas. Conservar cada byte para siempre no es necesario ni suele ser apropiado. Conservar solo la respuesta final suele ser demasiado poco. El registro debe preservar las decisiones y la evidencia que explican cómo el flujo de trabajo pasó de una solicitud a un resultado.
Para una acción de consecuencia, ese registro normalmente debería permitir a un revisor reconstruir algunos datos básicos. ¿Cuál era el objetivo? ¿Qué política o mandato hacía permisible el trabajo? ¿Quién o qué recibió cada asignación? ¿Qué se propuso en cada punto de control de consecuencia? ¿Qué información se usó para respaldar la propuesta? ¿Qué límites, advertencias o fallos se encontraron? ¿Quién tenía autoridad para aprobar, detener o revertir la acción? ¿Qué acción entró en vigor y qué ocurrió después? Estas no son preguntas exóticas. Son las preguntas que una organización se hace cuando quiere saber si una decisión fue su decisión.
The record should distinguish an operational fact from an explanation produced later. If a system says a reviewer approved an action, the event should record the identity or role of the reviewer, the action they were shown, the relevant context and the time at which the approval bound to that action. If the system says a model selected a delegate, the record should preserve the selection rule, candidates or criteria at the level appropriate for the use, and the resulting assignment. A later narrative can help a reader, but it should not replace the event that occurred.
Versioning matters here. An agent's output may be regenerated. A policy may be updated. A tool schema may change. A model endpoint may be swapped. If a decision depends on a particular version of a prompt, policy, model, knowledge source or integration, the record needs a stable reference to that version. Otherwise replay becomes a performance: it reproduces whatever the organisation happens to have now and calls the result an explanation of what happened then.
Reversibility deserves equal attention. The AI Act expressly refers, in the high-risk oversight context, to the ability to disregard, override or reverse an output and to interrupt a system so it comes to a halt in a safe state. In a multi-agent route, the safe state is not necessarily a stopped model process. It may mean no external communication is sent, a queued action is held, a downstream system is not updated, temporary credentials are no longer usable for the task, and the evidence needed to decide what happens next is retained. That is an operational inference from the oversight requirement, not a quotation of the law. It is also a useful design test.
Safe does not mean frozen forever. A halted workflow needs a controlled resumption path. Someone must decide whether to amend the task, discard the proposal, rerun a bounded part of the work, use a different tool, seek further evidence or abandon the route. A clean record makes that choice easier because it tells the next person what is known, what was attempted, why the work stopped and which effects have and have not occurred. Without that record, recovery becomes another unstructured delegation, usually undertaken under more pressure than the first one.
This is why retention and access need their own decisions. Not every actor should be able to read every trace. A record may contain personal data, commercially sensitive material or security-relevant details. But controlled access is not the same as no record. The Council of Europe Convention's emphasis on transparency, oversight, accountability and responsibility is a useful reminder that the boundary should be designed rather than assumed. An organisation can preserve an accountable route while limiting access to the detail that a particular reviewer genuinely needs.
What a delegation contract should make visible
A delegation contract can be a data structure, a workflow schema, a signed approval packet or a combination of these. Its form matters less than its content. It should tell the receiving actor what it is allowed to do, what it is not allowed to do and how the work will be judged. When these constraints are absent, agents tend to compensate with increasingly elaborate instructions. That may improve a particular run. It does not create an organisational boundary that a tool, reviewer or auditor can enforce.
Begin with the intended purpose. A purpose should be concrete enough to exclude nearby tasks. Compare the terms in the supplied proposals is different from find the best supplier. Summarise the received documents is different from establish the missing facts. Draft a reply for review is different from communicate a decision. The contrast can sound fussy until an agent uses a broad instruction to take a reasonable but unauthorised next step. Then it is the difference between useful initiative and an unbounded mandate.
Indique las clases de acciones permitidas y prohibidas. Un agente puede tener permiso para leer un expediente, extraer campos designados, comparar con una política y preparar un borrador. Puede tener prohibido modificar un registro de origen, contactar con una parte externa, seleccionar una nueva fuente o realizar una transacción. Estas no son meras instrucciones de mensaje. La capa de herramientas y de flujo de trabajo debe hacerlas cumplir cuando sea práctico. Una política que no puede verificarse en el momento de la acción sigue siendo útil como orientación, pero es más débil como control.
Indique el propietario y la vía de escalado. El propietario no es necesariamente la persona que hará clic en aprobar en cada acción. Es el rol responsable del resultado y de decidir qué ocurre cuando la vía llega a una cuestión sin resolver. La vía de escalado identifica a la siguiente autoridad cuando el agente detecta una vulneración del límite, pruebas insuficientes, un conflicto entre fuentes, una discrepancia con la política o una condición que el sistema no tiene permiso para resolver. Una cola sin un propietario de decisión designado es simplemente una demora con una etiqueta optimista.
Adjunte una regla de evidencia. La regla puede indicar qué fuentes son autorizadas, si el agente puede buscar más allá de ellas, cómo se representa la incertidumbre, qué debe citarse en la propuesta y cuándo una fuente contradictoria requiere revisión. Esto es especialmente importante para los sistemas que generan prosa fluida. La fluidez puede hacer que una vulneración del límite parezca una finalización útil. Una regla de evidencia hace disponible la pregunta correcta: ¿se mantuvo el flujo de trabajo dentro del material que estaba autorizado a utilizar?
Establezca un límite de tiempo, recursos y delegación donde sea relevante. Una tarea que puede continuar indefinidamente puede generar coste, congestión operativa o presión para confirmar un resultado obsoleto. Una tarea que puede delegar repetidamente puede crear una cadena que ningún propietario pueda inspeccionar fácilmente. Un diseño acotado indica cuánto tiempo sigue siendo válida la tarea, cuántos recursos puede consumir, si puede crear una subtarea, qué profundidad máxima se permite y qué ocurre cuando se alcanza un límite. La respuesta puede ser una pausa automática, un escalado o un fallo controlado. Lo importante es que se decida antes de que se cruce el límite.
Por último, defina la condición de finalización. Completado no siempre significa que el agente haya producido texto. Puede significar que un revisor recibió un paquete completo, que una puerta de política aceptó una acción específica, que un sistema posterior confirmó una actualización reversible o que un propietario responsable decidió no continuar. Las condiciones de finalización mantienen la honestidad del flujo de trabajo. Evitan que un agente trate el acto de proponer una decisión como si la organización hubiera tomado una.
Estos patrones son útiles tanto si el flujo de trabajo contiene un único agente basado en modelos como si contiene un equipo más amplio de componentes especializados. Más agentes no requieren automáticamente más proceso. Sí requieren que los límites entre roles se expresen en lugar de darse por sentados. El coste de esa expresión suele ser mucho menor que el coste de intentar reconstruir la autoridad después de que varios sistemas hayan intercambiado instrucciones parciales y uno de ellos haya tocado el mundo exterior.
La delegación debería hacer a la organización más capaz, no menos responsable
A menudo se describe a los sistemas de agentes como si su valor residiera en eliminar la organización del trabajo. La perspectiva más interesante es la contraria. Un sistema cuidadosamente diseñado puede hacer más claros los compromisos organizativos: una tarea tiene un propietario, una delegación tiene un límite, una acción trascendente tiene una autoridad, una revisión tiene evidencia, una detención tiene un estado seguro y un registro puede reproducirse. Eso no es un obstáculo para la automatización útil. Es lo que permite que la automatización asuma un trabajo significativo sin pedir a las personas que confíen en una cadena invisible.
Construimos Dweve Nexus en torno a esta distinción. Su documentación local de producto describe tareas duraderas, autoridad evaluada frente al contexto de ejecución antes de actuar, estructuras de colaboración explícitas, incluida la delegación, y un registro escrito a medida que el trabajo ocurre. La afirmación relevante es deliberadamente modesta. Son propiedades de diseño destinadas a que una ruta delegada sea inspeccionable. No son prueba de que un despliegue concreto sea lícito, seguro o adecuado, y no eliminan la necesidad de que una organización decida su propio propósito, autoridad y supervisión humana.
La lección más amplia no depende de un solo producto. Un modelo puede decidir cómo dividir una tarea. Un agente puede pedir trabajo a otro agente. Una herramienta puede realizar una acción. La organización sigue teniendo que decidir dónde reside la autoridad. Debe hacerlo antes de que comience la delegación, no después de que un resultado final se haya pulido hasta volverse difícil de cuestionar.
Esa es la respuesta al título. El dueño de una decisión no es el agente que casualmente habló en último lugar. Es la persona o el rol al que la organización asignó la autoridad para aceptar la consecuencia de la decisión, con suficiente información y poder para rechazarla. La delegación es útil cuando hace que esa persona sea más capaz. Se vuelve peligrosa cuando hace que sea imposible encontrarla.
Fuentes
- Reglamento (UE) 2024/1689, la Ley de Inteligencia Artificial, EUR-Lex
- Convenio Marco del Consejo de Europa sobre Inteligencia Artificial y Derechos Humanos, Democracia y Estado de Derecho
- Dictamen 28/2024 del CEPD sobre aspectos de protección de datos en el tratamiento de datos personales en el contexto de los modelos de IA
- Factores humanos: introducción, Health and Safety Executive del Reino Unido
- Dweve Nexus