Quem decide quando um agente delega?

A delegação pode tornar um fluxo de trabalho de IA mais capaz sem o tornar mais responsável. A diferença está em manter a autoridade, as evidências e o...

Quem decide quando um agente delega?

Uma passagem de testemunho não esvazia o lugar

Um agente delega uma tarefa. Outro agente recolhe material, compara registos, chama uma ferramenta ou prepara uma recomendação. Um terceiro agente verifica o resultado. O trabalho move-se, e esse movimento pode ser útil. Também pode criar um problema de gestão muito antigo com uma forma nova: todos fizeram alguma coisa, mas ninguém consegue dizer quem tinha autoridade para tomar a decisão.

A resposta tentadora é o agente que fez a última chamada. É também, em geral, a resposta menos útil. Um componente de software pode selecionar um percurso, pedir mais trabalho e submeter uma instrução a um sistema ligado. Nenhuma dessas coisas estabelece quem aceitou o propósito, quem definiu o limite, quem podia ter recusado a ação, ou quem tinha de ser informado quando as condições mudaram. Apenas estabelece que um programa esteve na cadeia.

Essa distinção torna-se nítida quando um fluxo de trabalho tem consequências. Uma resposta sugerida pode tornar-se uma comunicação com o cliente. Uma classificação pode tornar-se a razão pela qual um processo é colocado numa determinada fila. Uma comparação pode tornar-se uma recomendação de compra. Uma instrução de pagamento redigida pode tornar-se um pagamento. Cada passo pode ser tecnicamente competente e ainda assim estar organizacionalmente incompleto. O sistema fez o trabalho da delegação sem fazer o trabalho da autoridade.

Não é preciso inventar uma falha dramática para ver o problema. Tomemos um fluxo de trabalho deliberadamente hipotético. Um agente de triagem recebe uma pergunta, pede a um agente de pesquisa que examine o material relevante, envia o resultado a um revisor e depois prepara uma ação para um sistema de gestão de processos. O agente de pesquisa não está autorizado a agir. O revisor não está autorizado a tornar eficaz o desfecho do processo. O agente de triagem tem uma credencial de ferramenta. A organização não especificou se essa credencial lhe permite assumir o resultado. O fluxo de trabalho pode parecer ordenado num painel de controlo. Ainda assim, chegou à pergunta mais importante sem resposta.

A delegação não é o desaparecimento da responsabilidade. É a responsabilidade tornada mais difícil de ver. Um bom desenho operacional torna-a mais fácil de ver novamente. Diz qual é a decisão inicial, o que pode ser delegado, quais as condições que acompanham a tarefa, quem pode aprovar uma ação irreversível ou com consequências, que registo permanece após a passagem de testemunho e como uma pessoa ou sistema pode intervir quando o percurso deixa de ser seguro. Não se pede à tecnologia que possua agência moral. Pede-se-lhe que deixe intacta a agência da organização.

É este o significado prático da responsabilização num fluxo de trabalho com múltiplos agentes. Não é uma linha decorativa numa política, nem é uma caça retrospetiva ao funcionário mais próximo quando algo corre mal. É uma propriedade do percurso antes de o trabalho começar. A pessoa certa pode inspecionar o que foi proposto, compreender por que foi proposto, exercer a autoridade que lhe foi atribuída e deixar um registo que possa ser contestado mais tarde.

As regras emergentes da Europa sobre IA são úteis aqui porque estão menos interessadas num humano teatral no fim de um fluxo do que nas condições em que a supervisão pode realmente funcionar. As disposições do AI Act sobre supervisão humana aplicam-se a sistemas de alto risco, não a todos os usos de um agente. Esse limite importa. Mas as questões operacionais do AI Act viajam bem: pode uma pessoa singular designada compreender as capacidades e limites relevantes, monitorizar anomalias e desempenho inesperado, evitar a dependência excessiva, interpretar o resultado, ignorá-lo ou revertê-lo, e interromper o sistema para um estado seguro? Um fluxo de trabalho com muitos agentes não torna essas questões mais pequenas. Multiplica os lugares onde a resposta se pode perder.

A delegação pode fazer avançar o trabalho. Não pode apagar o caminho por onde a autoridade e a contestação regressam.

A delegação é uma cadeia, não uma névoa

As pessoas delegam constantemente. Um gestor pede a um colega que prepare uma nota. Uma equipa de compras pede a um especialista que examine uma cláusula contratual. Um clínico pede um resultado a um laboratório. Quem recebe a tarefa ganha um papel definido no trabalho; não herda automaticamente toda a autoridade de quem a pediu. As boas organizações tornam esta distinção banal visível através de descrições de funções, limites de aprovação, procedimentos, segregação de funções e registos. Fazem-no porque capacidade e permissão são coisas diferentes.

Os sistemas de agentes tendem a esbater essa distinção porque um agente consegue descrever, planear e executar numa única superfície conversacional. Um modelo pode ser capaz de gerar um plano convincente para contactar um fornecedor. Um invólucro de ferramenta pode ser tecnicamente capaz de enviar a mensagem. Uma camada de orquestração pode ser capaz de chamar esse invólucro sem pausa. Esses factos descrevem capacidade. Não decidem se a mensagem deve ser enviada, se o destinatário proposto está dentro do âmbito, se a informação é adequada para divulgar, ou quem deve aceitar a consequência se a ação proposta estiver errada.

É útil separar cinco perguntas que muitas vezes vêm empacotadas. Quem deu à tarefa o seu propósito? Quem pode realizar o trabalho preparatório? Quem pode delegar uma subtarefa? Quem pode decidir que uma ação proposta é aceitável? Quem pode tornar essa ação eficaz no mundo exterior? Por vezes, um único papel humano detém legitimamente várias destas respostas. Por vezes, têm de ser separadas. A questão não é criar uma cerimónia elaborada para uma nota de baixo risco. A questão é evitar tratar silenciosamente uma capacidade técnica como uma transferência de autoridade institucional.

Uma delegação deve, por isso, transportar mais do que uma instrução. Deve transportar um mandato. O mandato identifica o objetivo, o contexto limitado, as entradas permitidas, o resultado esperado, as ações que continuam proibidas, o orçamento ou limite de tempo quando relevante, as condições que exigem escalada, e a pessoa ou papel responsável pelo resultado. O agente recetor pode então fazer trabalho útil dentro de um envelope visível. Pode pedir a outro agente uma análise. Não pode expandir o envelope apenas porque lhe ocorre um passo seguinte plausível.

Este não é um argumento para transformar cada interação numa reunião de aprovação. É um argumento para escolher o ponto em que a organização deseja que uma decisão aconteça. Um sistema pode redigir uma explicação sem que um humano veja cada frase quando o propósito, o público, o limite das fontes e as regras de publicação já estão fixados. Um sistema não deve adquirir o poder de alterar o direito de um cliente apenas porque o mesmo componente tem acesso à base de dados relevante. A diferença está na consequência, não na inteligência do modelo.

Essa consequência é muitas vezes distribuída. Uma tarefa pode ser inofensiva numa fase e ter consequências na seguinte. Ler um ficheiro pode ser rotineiro. Combiná-lo com outra fonte pode alterar a sensibilidade do material. Preparar uma recomendação pode ser rotineiro. Carregar num botão que cria um resultado legal, financeiro ou de serviço pode não o ser. Um desenho de governação que pergunta apenas se um agente é autónomo ignora esta mudança de estado. A questão útil é mais restrita: autónomo para fazer o quê, para quem, contra que condições e com que autoridade?

Há um modesto instinto holandês que vale a pena manter aqui. Se um processo precisa de uma dúzia de assinaturas, carimbos e um fluxograma plastificado para estabelecer quem pode carregar num botão, pode não ser um triunfo da governação. Mas a disposição oposta, em que uma credencial de ferramenta é tratada como um acordo constitucional, também não é um triunfo. O objetivo é um percurso proporcional que torne clara a autoridade com consequências, sem encenar uma pequena ópera em torno de cada ação rotineira.

A supervisão europeia é um requisito operacional

O Regulamento IA dá a expressão legal mais clara desta ideia para os sistemas de IA de alto risco. O artigo 14.º exige que sejam concebidos e desenvolvidos de modo a que pessoas singulares possam supervisioná-los eficazmente durante a sua utilização. O objetivo declarado é prevenir ou minimizar riscos para a saúde, a segurança e os direitos fundamentais quando esses riscos possam permanecer apesar de outros requisitos. As medidas devem ser proporcionais ao risco, à autonomia e ao contexto de utilização. Esta é uma norma deliberadamente operacional. Não diz que uma pessoa algures na organização está genericamente interessada em IA.

A disposição vai além de uma instrução genérica para manter um humano no circuito. Consoante o que for adequado e proporcionado, a pessoa designada para a supervisão deve poder compreender as capacidades e limitações relevantes, monitorizar o funcionamento e detetar anomalias, disfunções ou desempenhos inesperados, permanecer consciente do enviesamento de automatização, interpretar os resultados, decidir não utilizar um resultado ou ignorá-lo, sobrepô-lo ou revertê-lo, e intervir ou interromper o sistema para um estado seguro. A lei não transforma isto numa lista de verificação universal para todos os sistemas de agentes. Mostra, no entanto, por que razão um carimbo de aprovação no fim do processo é um mau modelo de supervisão.

Agora acrescente a delegação. Se um agente entrega uma tarefa a outro agente, o papel de supervisão precisa de ver mais do que a frase final produzida pelo último modelo. Precisa de contexto suficiente para compreender qual agente propôs a subtarefa, que fontes ou ferramentas foram utilizadas, se foi encontrado um limite de política, se um resultado foi alterado por um revisor e se um agente posterior alargou o âmbito. Caso contrário, o humano pode ver um resultado, mas não o percurso que o produziu. Isso pode ser suficiente para um rascunho de baixas consequências. Não é uma base convincente para aceitar uma decisão com consequências.

O artigo 26.º torna o ponto organizacional ainda mais claro para os utilizadores de sistemas de alto risco. Diz que os utilizadores devem atribuir a supervisão humana a pessoas singulares com a competência, formação, autoridade e apoio necessários. Essas palavras pertencem umas às outras. Competência sem autoridade cria um observador bem informado. Autoridade sem competência cria um proprietário formal que não consegue contestar o sistema. Ambas sem apoio criam uma pessoa que se espera que intervenha num processo que não consegue ver, a um ritmo que não consegue acompanhar, usando informações que não consegue interpretar.

No trabalho com múltiplos agentes, o suporte inclui a forma da interface e do registo. Um operador não precisa de todos os tokens que um modelo gerou nem de todas as tentativas internas. Precisa da ação proposta, da finalidade nomeada, da evidência material, da política e do limite aplicáveis, das alterações feitas desde o último ponto de revisão, do efeito esperado, da possível via de reversão e do motivo pelo qual o caso foi escalado. Isto é menos uma questão de tornar um painel de controlo reconfortante do que de reduzir a probabilidade de uma pessoa aprovar uma resposta porque o sistema tornou exaustiva a procura da alternativa.

A Convenção-Quadro do Conselho da Europa sobre Inteligência Artificial e Direitos Humanos, Democracia e Estado de Direito estabelece a ligação institucional mais ampla. O seu objetivo é garantir que as atividades no ciclo de vida dos sistemas de IA sejam coerentes com os direitos humanos, a democracia e o Estado de Direito. Os artigos 8.º e 9.º exigem transparência e supervisão adaptadas a contextos e riscos específicos, bem como responsabilização e responsabilidade por impactos adversos. A Convenção não prescreve um padrão de orquestração de agentes. Constitui, no entanto, uma correção útil à ideia de que uma cadeia de componentes de software pode dissolver as responsabilidades da autoridade pública ou do ator privado que a utiliza.

Essa visão mais ampla é importante porque uma decisão delegada pode afetar mais do que o desempenho técnico. Pode afetar a capacidade de uma pessoa compreender uma decisão, contestá-la, obter reparação ou simplesmente saber qual organização é responsável. Um fluxo de trabalho pode ser composto por componentes de vários fornecedores, modelos de vários prestadores, ferramentas operadas por outra equipa e um serviço prestado ao abrigo de um contrato público. O facto de a cadeia ser tecnicamente distribuída não torna o impacto no indivíduo menos real. Na prática, torna mais importante uma atribuição clara de papéis.

A proteção de dados dá o mesmo aviso a partir de uma direção diferente. O trabalho do Comité Europeu para a Proteção de Dados sobre modelos de IA sublinha que a análise de proteção de dados permanece contextual: as organizações devem determinar o seu papel, identificar o tratamento envolvido e aplicar as obrigações relevantes, em vez de tratar o rótulo modelo de IA como uma isenção da responsabilização comum. Quando um fluxo de trabalho com múltiplos agentes envolve dados pessoais, a delegação não deve obscurecer quem determina as finalidades e os meios do tratamento, qual agente ou ferramenta recebe quais dados e se a próxima transferência é necessária para a tarefa. Uma subtarefa continua a ser uma etapa de tratamento. Chamar-lhe delegação não a faz desaparecer.

Nada disto produz uma resposta mágica para todos os casos difíceis. As obrigações legais dependem da utilização, dos atores, dos dados e do setor. Um artigo não pode classificar um sistema específico. Mas pode enunciar um princípio disciplinado: se um fluxo de trabalho distribui o trabalho, deve distribuí-lo de forma a preservar a capacidade de identificar a autoridade, intervir a tempo, prestar contas do percurso e responder às pessoas afetadas pelo resultado.

A pessoa no circuito precisa de um circuito real

A supervisão humana é facilmente reduzida a um ecrã com um botão de aprovação. Esse ecrã pode ser útil. Também pode ser um objeto cerimonial. A questão é se a pessoa que o utiliza tem uma escolha significativa. Uma escolha não é significativa apenas porque a interface apresenta dois botões. Depende de a pessoa ter tempo, informação, competência e permissão institucional suficientes para decidir de forma diferente.

O tempo é a parte menos glamorosa do design e, muitas vezes, a mais decisiva. Se o sistema envia centenas de propostas num período em que um revisor poderia razoavelmente inspecionar apenas uma fração, a organização criou uma fila, não uma supervisão. Se a proposta expira antes de o revisor obter contexto, o sistema tornou a velocidade no decisor efetivo. Se uma equipa é recompensada apenas pelo volume processado, recebeu uma instrução silenciosa sobre qual botão premir. O software não cura estas disposições acrescentando uma pontuação de confiança num tom de verde diferente.

A informação tem de ser proporcional, não exaustiva. Um revisor a quem é dado apenas uma conclusão não a pode contestar. Um revisor a quem é dado um registo integral de cada interação do agente também não a pode contestar, em geral. O meio utilizável é um pacote de decisão. Identifica que ação é proposta, por que razão está dentro do propósito declarado, que evidência material a sustenta, que incerteza permanece, que política ou regra é relevante, qual é o efeito proposto e o que aconteceria se a ação não for aprovada. O pacote deve ligar a evidência mais aprofundada, mas não deve exigir uma expedição arqueológica para o caso comum.

Competência significa mais do que um curso genérico sobre IA. Para a tarefa em causa, o revisor deve compreender o tipo de resultado, as limitações conhecidas que podem ser relevantes, a forma como o fluxo de trabalho se destina a funcionar e os sinais que exigem escalonamento. Uma pessoa que reconhece uma fatura de fornecedor defeituosa pode estar bem posicionada para rever uma proposta relacionada com faturas. A mesma pessoa pode não estar bem posicionada para avaliar a cobertura linguística de um modelo ou uma implicação de proteção de dados. Atribuir supervisão é, portanto, também uma decisão de pessoal.

A permissão institucional é o teste que muitos designs falham silenciosamente. O revisor deve poder recusar, pausar ou alterar a rota proposta sem ser tratado como a origem de uma falha do sistema. Precisa de acesso a uma pessoa ou função que possa decidir o que acontece a seguir. Precisa de uma forma de registar que o assunto foi escalado. E o sistema precisa de um estado seguro em que o trabalho possa aguardar sem ser acidentalmente cometido por uma repetição, um tempo limite ou outro agente que tome a instrução original como negócio inacabado.

A engenharia de segurança trata há muito o desempenho humano como parte do sistema, e não como uma camada final de verniz. A Health and Safety Executive do Reino Unido descreve os fatores humanos como a tarefa, o indivíduo e a organização em conjunto, e alerta contra considerá-los isoladamente. É um enquadramento sensato para a supervisão de agentes. Um revisor não é uma ficha humana abstrata para preencher uma lacuna de software. Está a realizar uma tarefa específica, com informação e ferramentas específicas, dentro de uma organização específica, com pressões e limites específicos. A qualidade do controlo depende de tudo isto.

Por essa razão, um bom design com humano no circuito começa antes de o botão aparecer. Define que decisões precisam de um portão humano, quem segurará o portão, que evidência receberão, quanto tempo a tarefa permite, o que acontece quando estão ausentes e se o portão tem autoridade sobre a própria ação ou apenas sobre uma explicação da ação. Se a organização não consegue responder a estas perguntas numa terça-feira calma, não ficará mais claro quando chegar um caso de elevada consequência. Nem deve precisar de uma crise imaginária para o notar.

As permissões devem descrever a consequência de uma ação, e não apenas o alcance técnico de uma credencial.

Uma tarefa, vários tipos de autoridade

Um modelo de autoridade compacto pode tornar um fluxo de trabalho de agente mais fácil de operar. Não precisa de ser grandioso. Comece pela diferença entre ler, propor, delegar, comprometer e parar. Uma função autorizada a ler pode inspecionar o material necessário para uma tarefa. Uma função autorizada a propor pode preparar uma ação possível. Uma função autorizada a delegar pode atribuir trabalho limitado a outro ator. Uma função autorizada a comprometer pode tornar efetiva uma ação consequente. Uma função autorizada a parar pode pausar ou interromper um percurso quando as suas condições deixam de se verificar.

Estas não são simplesmente hierarquias. Um revisor de conformidade pode conseguir parar um fluxo de trabalho, mas não comprometer um resultado de cliente. Um agente especializado pode conseguir propor um percurso, mas não delegar novo trabalho fora do seu domínio. Um gestor pode ser responsável pela finalidade de um serviço e, ainda assim, não ser a pessoa autorizada a libertar um determinado pagamento. A propriedade útil não é uma hierarquia por si só. É que o sistema consiga avaliar se um determinado ator tem a autoridade relevante para uma determinada ação no contexto atual.

O contexto faz grande parte do trabalho. A mesma ação proposta pode ser comum numa circunstância e consequente noutra. Enviar um modelo já aprovado para um endereço interno conhecido pode estar dentro de um mandato de comunicação rotineiro. Enviar uma mensagem recém-redigida com dados pessoais para um novo destinatário é diferente. Um reembolso dentro de um limite definido pode ser delegado a um processo bem testado. Uma alteração a um direito, uma eliminação de dados ou um compromisso externo podem exigir uma decisão humana nomeada. A política deve expressar essa distinção antes de o modelo ser solicitado a planear em torno dela.

Há também uma diferença importante entre uma aprovação e um reconhecimento. Um reconhecimento regista que alguém viu uma mensagem. Uma aprovação regista que uma pessoa autorizada aceitou uma ação definida, com o contexto relevante, num ponto definido do percurso. Num sistema conversacional, estes podem parecer semelhantes. O registo não deve. Se um revisor posterior não conseguir distinguir que ação foi aprovada e que efeito era esperado, a organização registou uma conversa em vez de capturar uma decisão.

A própria delegação precisa de limites. Um agente que recebe a tarefa de comparar três propostas existentes pode ser autorizado a pedir a um agente de investigação que extraia os termos relevantes. Não deve tratar essa permissão como um convite para contactar fornecedores, adquirir novos dados ou reformular o objetivo da aquisição. O limite pode ser expresso na política, no âmbito das ferramentas, num contrato de tarefa estruturado ou nos três. O que importa é que seja suficientemente aplicável para restringir o percurso, em vez de apenas descrever o comportamento desejado a posteriori.

Delegation depth is another limit worth naming. A human can give one agent a task and still retain a clear view of its first handover. After several nested handovers, the original purpose may be technically present in metadata yet practically invisible. Organisations can set a maximum delegation depth for a class of work, require review at a particular depth, or prohibit a delegate from creating further delegates without a fresh gate. These are design choices, not universal requirements. They are most useful where a longer chain makes it difficult to see which actor introduced a new assumption or changed the effective scope.

Tool authority must also be separate from model authority. A model might choose a tool based on a plan. The tool integration should still check whether the requested action, target, data category, resource limit and workflow state permit the call. This is not distrust of the model in a moral sense. It is ordinary boundary design. A well-formed plan can still be inappropriate for the current case, and a poorly formed plan should not become real merely because it reached a credential with broad access.

The same goes for recovery. A retry is not always harmless. Retrying a request to read a public document is different from retrying a request that sends a message or makes a charge. When a delegated task fails, a workflow needs an explicit choice among retry, reroute, escalate, pause and controlled failure. Treating them as one generic error handler is how an operational decision is quietly made by default settings. The agent runtime can make the options available. The organisation must decide which option applies to which action class.

Failure is often a missing decision

When people hear failure they often picture an agent producing a false statement or a tool timing out. Both can matter. The more revealing failures in delegated work are frequently quieter. The task was assigned without a clear owner. The proposal crossed a boundary no one had modelled. The reviewer could see the conclusion but not the evidence. A retry continued after a pause. A human noticed a problem but had no authority to stop the action. A decision was made, but the record preserved only the final output and not the condition that made it acceptable.

These are not claims about a named incident. They are failure modes derived from the structure of delegation itself. They can be found in human processes too. In software, however, they can travel at the pace of automation and be repeated very consistently. That consistency is not a reason to despair. It is a reason to treat workflow design as part of the control, rather than assuming that accuracy testing of one model component settles the question.

Consider another explicitly hypothetical design. An agent is asked to prepare a case summary. It delegates document extraction to one component and language normalisation to another. A third component sees an incomplete field and uses a connected knowledge source to fill the gap. The final summary reads smoothly. If the workflow has not recorded the missing field, the source used to fill it, the confidence or uncertainty that came with it, and the fact that the original task permitted only summarisation, a reviewer cannot tell whether they are approving a summary or a newly created factual assertion. The problem is not that the last sentence sounds odd. The problem is that the meaning of the task changed inside the route.

Uma resposta sensata não é proibir a delegação. É registar os pontos de mudança. Uma nova fonte, uma nova ferramenta, uma nova categoria de dados, uma nova classe de ação, uma alteração material na confiança, um controlo que falhou, uma cadeia de delegação mais longa do que o permitido, ou uma proposta para cruzar uma fronteira externa podem, cada uma, tornar-se motivo para expor o trabalho a revisão. Os gatilhos exatos variam consoante o contexto. O princípio é estável: uma mudança que interessaria ao responsável final não deve permanecer invisível por ter ocorrido entre componentes.

Este é um caso em que o pensamento de safety case é útil. Um safety case não é uma promessa de que nada pode correr mal. É um argumento estruturado sobre por que um sistema é aceitável para um fim definido em condições definidas, com evidências, pressupostos, controlos e riscos residuais visíveis. Aplicado com cuidado a um fluxo de trabalho de agentes, isso significa que a afirmação não é a de que os agentes são genericamente seguros. A afirmação é mais restrita: esta rota pode ser usada para este fim, com estes limites, porque existem estes controlos e disposições de supervisão, e deve ser reconsiderada quando os pressupostos declarados deixarem de se verificar.

O fluxo de trabalho torna-se então mais fácil de contestar. Um operador pode perguntar se a classe de ação foi corretamente atribuída. Um responsável pelo risco pode perguntar se o revisor ainda tem tempo suficiente. Um engenheiro pode perguntar se uma repetição poderia criar um efeito duplicado. Um especialista em proteção de dados pode perguntar se a subtarefa continua a ser necessária e proporcionada. Uma pessoa afetada por um resultado pode, quando o enquadramento aplicável o exigir, ter uma via para questionar a decisão. Essas perguntas não são burocracia acrescentada depois do trabalho técnico interessante. São o trabalho de tornar o sistema técnico responsável perante uma organização.

As métricas devem seguir a mesma disciplina. Contar o número de tarefas delegadas diz-nos algo sobre volume, não sobre operação responsável. Medidas mais úteis podem incluir a taxa a que um fluxo de trabalho escala porque uma fronteira mudou, o tempo que uma decisão espera num portão, a proporção de ações consequentes com um pacote de decisão completo, o número de reversões bem-sucedidas, ou o número de casos em que uma verificação de política recusou uma chamada de ferramenta. Essas medições ainda precisam de uma definição e de um contexto. Nunca devem ser inventadas para um folheto. Mas desenhar os registos de modo a que possam ser medidos é um sinal de que a responsabilização está a ser tratada como uma propriedade operacional.

O registo é onde a responsabilidade sobrevive

Um sistema multiagente produz um tipo estranho de história. Tem mensagens, chamadas de ferramenta, resultados intermédios, verificações de política, versões de modelo, informação de tempo, repetições, atribuições alteradas e talvez aprovações humanas. Guardar todos os bytes para sempre não é necessário nem muitas vezes apropriado. Guardar apenas a resposta final é geralmente demasiado pouco. O registo precisa de preservar as decisões e as evidências que explicam como o fluxo de trabalho passou de um pedido a um resultado.

Para uma ação consequente, esse registo deve normalmente permitir a um revisor reconstruir alguns factos básicos. Qual era o objetivo? Que política ou mandato tornava o trabalho permitido? Quem ou o quê recebeu cada atribuição? O que foi proposto em cada portão consequente? Que informação foi usada para apoiar a proposta? Que limites, avisos ou falhas foram encontrados? Quem tinha autoridade para aprovar, parar ou reverter a ação? Que ação se tornou efetiva, e o que aconteceu depois? Estas não são perguntas exóticas. São as perguntas que uma organização faz quando quer saber se uma decisão foi sua.

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 as classes de ações permitidas e proibidas. Pode ser permitido a um agente ler um processo, extrair campos nomeados, comparar com uma política e preparar um rascunho. Pode ser-lhe proibido alterar um registo de origem, contactar uma entidade externa, selecionar uma nova fonte ou efetuar uma transação. Estas não são meras instruções de prompt. A camada de ferramentas e de fluxo de trabalho deve impô-las sempre que for prático. Uma política que não pode ser verificada no momento da ação continua a ser útil como orientação, mas é mais fraca enquanto controlo.

Indique o responsável e a via de escalonamento. O responsável não é necessariamente a pessoa que irá clicar em aprovar em cada ação. É o papel responsável pelo resultado e por decidir o que acontece quando a via chega a uma questão por resolver. A via de escalonamento identifica a autoridade seguinte quando o agente deteta uma violação de limites, provas insuficientes, um conflito entre fontes, uma incompatibilidade com a política ou uma condição que o sistema não está autorizado a resolver. Uma fila sem um responsável nomeado pela decisão é apenas um atraso com um rótulo otimista.

Anexe uma regra de provas. A regra pode indicar quais as fontes que são autoritativas, se o agente pode pesquisar para além delas, como a incerteza é representada, o que deve ser citado na proposta e quando uma fonte conflituosa exige revisão. Isto é particularmente importante para sistemas que geram prosa fluente. A fluência pode fazer uma violação de limites parecer uma conclusão útil. Uma regra de provas disponibiliza a pergunta correta: o fluxo de trabalho permaneceu dentro do material que estava autorizado a utilizar?

Defina um limite de tempo, de recursos e de delegação onde for relevante. Uma tarefa que pode continuar indefinidamente pode criar custos, congestionamento operacional ou pressão para confirmar um resultado desatualizado. Uma tarefa que pode delegar repetidamente pode criar uma cadeia que nenhum responsável consegue inspecionar facilmente. Um design limitado indica durante quanto tempo a tarefa permanece válida, quantos recursos pode consumir, se pode criar uma subtarefa, qual a profundidade máxima permitida e o que acontece quando um limite é atingido. A resposta pode ser uma pausa automática, escalonamento ou falha controlada. O importante é que seja decidida antes de o limite ser ultrapassado.

Por fim, defina a condição de conclusão. Concluído nem sempre significa que o agente produziu texto. Pode significar que um revisor recebeu um pacote completo, que uma porta de política aceitou uma ação específica, que um sistema a jusante confirmou uma atualização reversível ou que um responsável decidiu não avançar. As condições de conclusão mantêm o fluxo de trabalho honesto. Impedem que um agente trate o ato de propor uma decisão como se a organização tivesse tomado uma.

Estes padrões são úteis quer o fluxo de trabalho contenha um único agente baseado em modelo quer uma equipa maior de componentes especializados. Mais agentes não exigem automaticamente mais processo. Exigem que os limites entre papéis sejam expressos em vez de implícitos. O custo dessa expressão é geralmente muito inferior ao custo de tentar reconstruir a autoridade depois de vários sistemas terem trocado instruções parciais e um deles ter tocado o mundo exterior.

A delegação deve tornar a organização mais capaz, não menos responsável

Os sistemas de agentes são frequentemente descritos como se o seu valor residisse em remover a organização do trabalho. A perspetiva mais interessante é a oposta. Um sistema cuidadosamente concebido pode tornar os compromissos organizacionais mais claros: uma tarefa tem um responsável, uma delegação tem um limite, uma ação consequente tem uma autoridade, uma revisão tem provas, uma paragem tem um estado seguro e um registo pode ser reproduzido. Isso não é um obstáculo à automação útil. É o que permite que a automação assuma trabalho significativo sem pedir às pessoas que confiem numa cadeia invisível.

Construímos o Dweve Nexus em torno desta distinção. A sua documentação local do produto descreve tarefas duradouras, autoridade avaliada contra o contexto de execução antes da ação, estruturas explícitas de colaboração, incluindo delegação, e um registo escrito à medida que o trabalho acontece. A afirmação relevante é deliberadamente modesta. São propriedades de conceção destinadas a tornar uma via delegada inspecionável. Não são prova de que qualquer implementação específica seja legal, segura ou adequada, e não eliminam a necessidade de uma organização decidir o seu próprio propósito, autoridade e supervisão humana.

A lição mais ampla não depende de um único produto. Um modelo pode decidir como dividir uma tarefa. Um agente pode pedir trabalho a outro agente. Uma ferramenta pode executar uma ação. A organização continua a ter de decidir onde reside a autoridade. Tem de o fazer antes de a delegação começar, e não depois de um resultado final ter sido polido até se tornar difícil de questionar.

Essa é a resposta ao título. O dono de uma decisão não é o agente que por acaso falou por último. É a pessoa ou função a quem a organização atribuiu a autoridade para aceitar a consequência da decisão, com informação e poder suficientes para a recusar. A delegação é útil quando torna essa pessoa mais capaz. Torna-se perigosa quando a torna impossível de encontrar.

Fontes