Humanos no circuito para agentes de IA: como conceber aprovações que reduzam o risco sem bloquear o trabalho

O problema: «um humano aprova» não define um controlo suficiente

Um agente capaz de consultar sistemas internos, modificar registos, enviar comunicações ou iniciar transações não deixa de ser arriscado por existir uma pessoa em algum ponto do fluxo. A supervisão só funciona se a intervenção humana for significativa: a pessoa deve conseguir compreender a decisão proposta, impedi-la, corrigi-la ou interromper o processo antes que produza um efeito que ultrapasse a autonomia aceite.

A expressão «requer aprovação humana» costuma ocultar questões de conceção decisivas. Não diz que componente é aprovado — um objetivo, um plano, uma ação concreta ou um lote —; também não identifica a pessoa com autoridade para aprovar, a informação disponível, o tempo máximo de resposta nem o comportamento predefinido perante o silêncio. Sem estas definições, a aprovação pode transformar-se numa formalidade ou, no extremo oposto, numa fila que impede o fluxo de gerar valor.

Convém tratar a aprovação como um controlo de decisão, e não como uma interface. O controlo deve ligar uma classe de ação a um nível de risco, um responsável, um conjunto mínimo de evidências, uma regra de execução e um registo auditável. As permissões técnicas continuam a ser necessárias: uma aprovação não deve ampliar os privilégios do agente nem substituir a autorização do sistema de destino.

Esta abordagem complementa a conceção geral de agentes abordada na secção de aprendizagem e deve coordenar-se com as decisões de avaliação e descoberta de ferramentas. Contudo, o âmbito aqui é mais concreto: decidir onde uma pessoa intervém numa ação de um agente e como demonstrar posteriormente que essa intervenção foi eficaz.

Três modalidades que não devem ser confundidas: aprovação prévia, revisão posterior e paragem de emergência

A aprovação prévia suspende uma ação antes de esta produzir um efeito externo. É o padrão adequado quando o impacto potencial é elevado, a reversão é limitada, são tratados dados sensíveis ou ainda não existe evidência suficiente de que o agente atua de forma fiável nesse caso. O seu custo é o tempo de espera e a carga do revisor, pelo que não deve ser imposta indiscriminadamente.

A revisão posterior permite executar uma ação dentro de limites predeterminados e examinar depois uma amostra, um alerta ou o conjunto de resultados. É adequada quando o dano é limitado e reversível, existe um mecanismo de correção comprovado e a organização consegue detetar efeitos indesejados rapidamente. Não equivale à ausência de controlo: requer registos completos, limiares de alerta, responsáveis pelo acompanhamento e capacidade real de reverter.

A paragem de emergência é um mecanismo separado. Deve permitir pausar uma execução concreta, desativar uma integração ou retirar temporariamente a autonomia de uma classe de ações. É necessária mesmo em fluxos com aprovação prévia, porque podem surgir incidentes sistémicos, sinais de manipulação ou uma alteração do contexto que torne inadequado prosseguir. As orientações de gestão do risco agêntico recomendam controlos para orientar, corrigir e interromper comportamentos autónomos, sobretudo perante ações de elevado impacto ou entradas ambíguas.

Existe ainda uma intervenção de esclarecimento: o fluxo é pausado para pedir informação em falta, mas não para autorizar uma ação já bem especificada. Separá-la da aprovação evita que uma resposta informativa seja erradamente interpretada como consentimento para executar. Algumas plataformas de fluxos de trabalho implementam passos humanos capazes de suspender uma execução pendente e pedir uma revisão ou informação adicional; o padrão técnico, por si só, não determina a política de risco.

Construir uma matriz de decisão: impacto, reversibilidade, sensibilidade, âmbito e confiança empírica

Não existe uma lista universal de ações que exijam sempre aprovação. A classificação deve partir da ação concreta e do seu contexto. Numa organização, atualizar uma etiqueta interna pode ser inócuo; noutra, a mesma alteração pode ativar uma exclusão de serviço ou modificar um registo regulado. Por isso, a matriz deve documentar o efeito produzido pela ação no sistema de destino, e não apenas o nome da ferramenta.

Avalie pelo menos cinco dimensões. O impacto é a magnitude do possível prejuízo para pessoas, clientes, operação, finanças ou conformidade. A reversibilidade mede se é possível desfazer o efeito de forma completa, segura e a um custo razoável. A sensibilidade abrange os dados consultados, revelados ou transformados. O âmbito considera o volume, os destinatários, os sistemas e a duração. Por fim, a confiança empírica não é uma impressão sobre o modelo: é evidência obtida em testes e operação comparável de que o agente identifica corretamente o caso, propõe parâmetros válidos e não omite condições relevantes.

Uma pontuação pode ajudar a ordenar decisões, mas não deve automatizar uma conclusão sem regras de veto. Por exemplo, uma transação irreversível ou um acesso a dados especialmente sensíveis pode exigir aprovação, mesmo que a ação tenha âmbito unitário e o agente tenha tido bom desempenho nos testes. Do mesmo modo, uma ação de baixo impacto pode passar para revisão prévia se surgir num contexto anómalo, se o agente usar uma ferramenta nova ou se os sinais de validação não estiverem disponíveis.

O resultado da matriz deve corresponder a uma de quatro políticas: execução automática dentro de limites; aprovação prévia por uma pessoa responsável; dupla aprovação por funções distintas; ou proibição de execução pelo agente. A última categoria não significa necessariamente que a tarefa seja proibida para a organização, mas sim que requer um procedimento humano ou uma integração diferente.

Conceber o pedido de aprovação para que possa ser revisto

Um revisor não deve ter de reconstruir todo o raciocínio do agente nem confiar numa explicação persuasiva para tomar uma decisão. O pedido deve apresentar os factos e os limites da ação de forma verificável. O seu objetivo é permitir detetar erros no destinatário, no âmbito, nos dados, na autorização ou na consequência prevista.

Inclua o objetivo operacional, a ação exata que se pretende executar, a ferramenta ou sistema de destino, os parâmetros vinculativos, os dados que serão consultados ou revelados e uma pré-visualização do efeito. Sempre que possível, apresente a alternativa mais segura ou menos intrusiva, como guardar um rascunho em vez de enviar, limitar o lote ou pedir um esclarecimento. Indique também o que acontecerá se a pessoa rejeitar, modificar ou não responder.

A interface deve distinguir claramente entre aprovar a ação tal como está definida, pedir alterações e rejeitá-la. Um campo de texto livre pode ser útil para uma exceção, mas não deve permitir que uma instrução ambígua se transforme numa autorização ampla. Se o revisor alterar um parâmetro essencial, o agente deve gerar uma nova proposta ou executar um fluxo determinístico validado; não deve reinterpretar livremente a alteração.

Um bom pedido também declara a proveniência do contexto: que fontes internas ou entradas do utilizador sustentam a proposta, que verificações foram realizadas e que incertezas continuam em aberto. Mostrar esta informação não significa expor dados desnecessários ao revisor. A visibilidade deve respeitar a minimização de dados e as restrições de acesso da própria função.

Atribuir responsáveis, substitutos e escalonamentos

A pessoa que revê deve ter autoridade real sobre o efeito da ação. Um responsável de operações pode aprovar uma atualização de inventário dentro do seu âmbito, enquanto o acesso a dados pessoais pode exigir um proprietário de dados ou uma função de segurança. Atribuir revisores apenas pela disponibilidade tende a produzir aprovações mecânicas ou rejeições por falta de contexto.

Documente um proprietário da política para cada classe de ação, as funções autorizadas a aprovar e as condições em que é exigida separação de funções. A dupla aprovação faz sentido quando uma única pessoa não deve controlar por completo uma decisão: por exemplo, uma função conhece a necessidade operacional e outra valida o risco de conformidade. Não deve ser usada como resposta automática a toda a incerteza, pois duplicar revisões sem objetivos distintos pode aumentar a demora sem aumentar a deteção.

Defina substitutos com o mesmo nível de autoridade, mas evite reencaminhar automaticamente um pedido para muitas pessoas. Uma fila com responsáveis, prazo e escalonamento explícitos é mais auditável. O pedido deve expirar se mudarem as condições que o sustentam, como a validade de um dado, o estado de um caso ou o conteúdo de uma integração.

Os quadros de gestão de riscos de IA recomendam atribuir funções, responsabilidades e autoridades, documentar o risco e manter monitorização após a implementação. Num sistema com agentes, essa atribuição deve abranger tanto a decisão de permitir uma ação como a capacidade de intervir perante um incidente.

Gerir silêncios, rejeições e desacordos sem abrir vias de contorno

O silêncio não é aprovação. A regra predefinida deve ser não executar quando uma ação aguarda autorização e o prazo expira, salvo se uma política documentada estabelecer uma ação alternativa segura. Por exemplo, um agente pode guardar um rascunho, criar uma tarefa ou pedir dados adicionais, mas não transformar a ausência de resposta em permissão para enviar, alterar ou divulgar.

Uma rejeição deve ter uma semântica definida. Pode encerrar o caso, devolvê-lo ao agente com parâmetros explícitos que este deve respeitar ou encaminhá-lo para uma pessoa executar manualmente. É importante impedir que o agente tente novamente a mesma ação com uma formulação superficialmente diferente para obter uma nova aprovação. Agrupe tentativas equivalentes, mantenha a ligação à rejeição anterior e exija uma diferença material identificável.

Os desacordos entre aprovadores também precisam de uma saída: prevalência de uma função de risco, encaminhamento para um responsável pelo caso ou bloqueio até existir uma decisão humana com autoridade superior. O sistema deve conservar as decisões e os seus fundamentos operacionais, sem atribuir certeza a uma explicação gerada pelo agente.

Após a aprovação, valide que o artefacto executado corresponde ao que foi aprovado. Compare o identificador da ação, a versão do plano, os parâmetros, os destinatários, as ferramentas e o resultado. Se algum destes elementos mudar, peça uma nova aprovação ou aplique uma rota de alteração previamente autorizada e estritamente limitada.

Padrões por tipo de ação e limites de execução

Para comunicações externas, separe a geração do rascunho do envio. Pode ser razoável automatizar a classificação e a preparação quando o conteúdo permanece interno; o envio exige um limiar mais elevado se afetar clientes, comprometer uma posição contratual ou contiver dados sensíveis. Alterações de destinatário, idioma, anexos ou listas de distribuição devem ser tratadas como alterações materiais.

Em alterações de código ou configuração, uma revisão humana do conteúdo não substitui os controlos do ciclo de entrega. A aprovação deve estar associada a uma versão identificável, testes disponíveis, ambiente de destino e plano de reversão. Um agente não deve ampliar a implementação de um ambiente de teste para produção através de uma aprovação obtida para uma validação limitada.

Nas atualizações de registos, estabeleça que campos o agente pode modificar, que fontes são admissíveis e quando deve mostrar a diferença entre o valor atual e o proposto. As atualizações em massa requerem um controlo específico do âmbito, dos critérios de seleção e do mecanismo para desfazer. No acesso a dados, aplique o princípio do menor privilégio, autorização no sistema de destino e execução no contexto autorizado; uma aprovação na camada do agente não deve conceder acesso que o sistema de origem recusa.

As transações com impacto financeiro, legal ou físico exigem geralmente uma política restritiva. A classificação depende do contexto e dos controlos existentes, mas a irreversibilidade, a possível afetação de terceiros e a dificuldade de reparação são sinais fortes para exigir dupla aprovação ou excluir o agente da execução. As recomendações de segurança sobre agência excessiva destacam o menor privilégio, a autorização no sistema de destino, a supervisão de ações de elevado impacto e o registo de atividade.

Medir se o controlo deteta erros reais e ajustar a autonomia com evidência

A existência de aprovações não demonstra que o controlo funcione. Meça quantas propostas são rejeitadas ou alteradas devido a erros materiais, que tipos de erros são detetados, quantas ações aprovadas têm de ser revertidas e quanto tempo a fila demora. Segmente estas métricas por classe de ação, integração, versão do fluxo e responsável, pois uma média global pode ocultar um problema concentrado.

A taxa de aprovação, por si só, é ambígua. Uma taxa muito elevada pode refletir propostas corretas e de baixo risco, mas também fadiga, falta de contexto ou pressão para escoar a fila. Investigue sinais combinados: aprovações com tempos invulgarmente curtos, comentários repetitivos, discrepâncias encontradas na revisão posterior, taxa de anulações e diferenças entre revisores. As amostras de qualidade e a revisão de casos negativos ajudam a distinguir eficiência de automatização indevida.

A confiança no agente deve ser atualizada com resultados observados, não com uma afirmação geral de desempenho. Para transferir uma classe de ação de aprovação prévia para supervisão posterior, defina antecipadamente que evidência será exigida: uma população de casos comparável, erros materiais abaixo do limiar interno, reversão comprovada, deteção posterior dentro do tempo aceitável e ausência de alterações relevantes no modelo, nas ferramentas ou nos dados. Se estes elementos mudarem, reavalie a política.

Registe uma rastreabilidade que permita reconstruir o caso: pedido original, contexto permitido, plano, ação proposta, versão do agente e das ferramentas, aprovador, decisão, hora, parâmetros executados, resposta do sistema de destino e resultado posterior. O registo deve ser protegido e acessível apenas às funções autorizadas; recolher mais contexto do que o necessário pode criar um risco adicional de privacidade ou segurança.

Plano de implementação e lista de verificação de lançamento

Comece por um fluxo limitado, com uma única classe de ação e um sistema de destino onde seja possível observar o resultado e revertê-lo. Faça o inventário das ações do fluxo, não apenas das suas ferramentas: consultar, redigir, atualizar, enviar, eliminar, escalar e executar podem exigir controlos diferentes. Para cada uma, descreva o efeito, as permissões técnicas, os limites dos parâmetros e o proprietário da política.

Antes da implementação, teste casos normais, entradas ambíguas, pedidos maliciosos, ferramentas que devolvem erros e alterações de parâmetros após a aprovação. Verifique em especial que o agente não consegue executar uma ação diferente da aprovada, que um pedido expirado não é executado e que a paragem de emergência afeta execuções pendentes e novas.

Realize uma fase controlada com evidência suficiente para detetar padrões, sem prometer que uma quantidade fixa de casos seja válida para todos os riscos. Reveja semanalmente as rejeições, as anulações, os tempos de espera, os pedidos sem resposta e os incidentes. Amplie a autonomia apenas para uma classe concreta de ação e somente quando os resultados e os mecanismos de reversão justificarem a alteração.

A política de aprovações é um documento vivo. Deve ser atualizada quando são adicionadas ferramentas, mudam os dados disponíveis, o modelo é modificado, um novo sistema de destino é integrado ou surgem incidentes. A governação deve conservar uma versão da política aplicável a cada execução para interpretar corretamente o registo histórico.

Continue a explorar

Correções e transparência

Se encontrar informação incorreta ou desatualizada, envie-nos a página e a fonte que devemos rever.