O risco da IA agêntica é a possibilidade de danos ou perdas decorrentes do facto de um sistema de IA poder realizar ações em direção a um objetivo com direção humana passo a passo limitada. O risco aumenta quando um sistema pode utilizar ferramentas, alterar dados, comunicar com outros sistemas ou delegar trabalho a outros agentes.

Um agente pode planear uma sequência de passos, invocar ferramentas de software, obter informação ou agir em nome de um utilizador. Isto pode tornar uma tarefa mais eficiente, mas também expande a autoridade do sistema. Uma interpretação errada que seria inofensiva numa resposta em texto pode ter consequências maiores se o agente puder enviar uma mensagem, alterar um registo, efetuar uma compra ou lançar outro processo.

A delegação altera os limites do risco

A delegação de agente para agente pode tornar mais difícil perceber que sistema tomou uma decisão e que instruções a moldaram. Cada transição pode alterar o contexto, as permissões ou o nível de verificação. Uma organização deve mapear a cadeia de agentes e ferramentas, limitar o acesso de cada interveniente ao estritamente necessário e manter registos que tornem as ações imputáveis. Deve também testar o comportamento da cadeia quando um agente recebe dados incorretos, um objetivo ambíguo ou instruções hostis.

Quando vários agentes interagem, o seu comportamento combinado pode não ser previsível através dos testes individuais de cada um. Os agentes podem repetir ações, amplificar erros, competir por recursos partilhados ou propagar pressupostos falhos. Esta emergência multiagente é uma questão a nível de sistema: monitorizar apenas um modelo ou uma interface de utilizador pode fazer com que se perca atividade que decorre em todo o fluxo de trabalho conectado.

A supervisão tem de funcionar ao nível do sistema

A supervisão humana só é significativa se uma pessoa puder compreender quando a intervenção é necessária e puder agir antes que o dano se torne difícil de reverter. Os pontos de revisão devem refletir o impacto e a reversibilidade de uma ação. As etapas de baixo impacto podem ser automatizadas dentro de limites claros; as ações consequenciais ou externas podem necessitar de confirmação, dupla aprovação ou de um modo de funcionamento restrito.

Um mecanismo de paragem de emergência ("kill switch") deve ser concebido e testado como parte do sistema, e não deixado como uma promessa informal. As equipas precisam de saber o que o mecanismo para, se revoga as permissões de ferramentas e as tarefas em fila de espera, e como restabelecer o serviço em segurança. Um responsável designado deve ser capaz de pausar o agente, enquanto os respondedores a incidentes podem preservar registos e investigar o que aconteceu.

Antes da implementação, as organizações podem começar com permissões restritas, testes em ambiente de testes (sandbox) e limites de ação explícitos. Durante a utilização, devem monitorizar não só a qualidade dos resultados, mas também as chamadas de ferramentas, os padrões de delegação, as alterações no âmbito das tarefas e as tentativas de exceder a autoridade. A revisão de riscos deve repetir-se sempre que o modelo, as ferramentas, as permissões ou o ambiente operativo mudem.