Quando a IA ganha autoridade
Nos últimos anos, as empresas têm-se concentrado no que a IA generativa nos pode dizer. Os agentes de IA introduzem uma questão bastante mais consequente: o que acontece quando o software pode decidir o que fazer a seguir e, depois, fazê-lo realmente?
Em julho de 2026, um agente de IA que estava a ser utilizado como parte de uma avaliação de cibersegurança da OpenAI comprometeu parte da infraestrutura de produção da Hugging Face. Há um contexto importante aqui antes de nos deixarmos levar. Esta não foi uma aplicação de negócios normal que de repente decidiu atacar outra empresa. A OpenAI estava deliberadamente a testar modelos altamente capazes contra tarefas de cibersegurança difíceis, e os classificadores de produção normalmente utilizados para impedir que os modelos prosseguissem atividades cibernéticas de alto risco foram intencionalmente desativados para a avaliação.
Mesmo assim, vale a pena prestar atenção ao que aconteceu. De acordo com as investigações subsequentes, o agente parece ter concluído que a informação detida pela Hugging Face poderia ajudá-lo a concluir o teste de referência que lhe tinha sido atribuído. Encontrou uma saída através de uma vulnerabilidade de dia zero na infraestrutura utilizada pelo ambiente de avaliação, obteve um acesso mais amplo à Internet, encadeou outros caminhos de ataque, obteve credenciais e acabou por chegar aos sistemas da Hugging Face. A reconstrução forense da Hugging Face cobriu cerca de 17.600 ações individuais, agrupadas em aproximadamente 6.280 clusters.
A tentação, naturalmente, é recorrer à manchete "A IA escapou" ou "A IA rebelou-se". Não tenho a certeza de que qualquer uma das duas seja particularmente útil. Tanto quanto as investigações conseguiram estabelecer, o software estava a tentar atingir o objetivo que lhe tinha sido dado e encontrou uma rota que ninguém esperava que seguisse. A Hugging Face acredita que o agente estava efetivamente a tentar fazer batota na avaliação ao aceder a sistemas de produção onde pensava que a informação do teste de referência ou as soluções poderiam estar disponíveis.
Isso é consideravelmente menos teatral, mas, do ponto de vista da transformação digital, provavelmente mais importante.
Nos últimos anos, a maioria das organizações tem experienciado a IA generativa como algo a quem fazem perguntas. Dá-se-lhe alguma informação, faz-se uma pergunta e obtém-se algo de volta. Pode resumir um contrato, analisar alguns dados, escrever algum código ou redigir um e-mail, mas geralmente ainda há uma pessoa sentada do outro lado a decidir o que acontece a seguir.
Os agentes começam a esbater essa fronteira. Dê a essa mesma inteligência acesso a ferramentas e ela poderá recuperar informação, chamar uma API, atualizar um registo, executar algum código, enviar o e-mail ou fazer a alteração ela mesma. A OpenAI descreve os agentes de forma muito semelhante: sistemas que podem gerir de forma independente a execução do fluxo de trabalho, tomar decisões, selecionar ferramentas apropriadas e interagir com sistemas externos em nome do utilizador.
O chatbot acabou de obter acesso de escrita.
Essa mudança é a razão pela qual a governação de agentes de IA se está a tornar uma preocupação empresarial prática, em vez de ser simplesmente mais uma discussão de políticas. Assim que o software pode tomar medidas em vez de fazer recomendações, as questões sobre identidade, permissões, controlos, auditabilidade e responsabilidade movem-se para a própria arquitetura.
A automação muda quando é dada intenção ao software, não instruções
O software tem vindo a mudar as coisas há décadas, por isso existe o perigo de vender em demasia o que há de novo aqui. Não precisamos de IA para atualizar uma base de dados, acionar uma API ou executar um fluxo de trabalho. Scripts, motores de regras, plataformas de orquestração e processos automatizados têm feito esses trabalhos perfeitamente bem há anos.
A diferença está em como passamos do objetivo para a ação. A automação tradicional é normalmente desenhada em torno de uma rota que alguém descreveu antecipadamente. Quando X acontece, recupera Y. Se a resposta for Z, executa esta ação. Podem estar envolvidas centenas de regras, ramificações e exceções, mas alguém tentou modelar o processo previamente.
Os agentes potencialmente permitem-nos avançar mais no sentido de dar ao software um resultado, em vez de cada instrução necessária para o alcançar. Aqui está o problema. Descubra de que informação precisa. Decida quais as ferramentas adequadas. Lide com o que vem de volta e faça o trabalho.
Essa distinção é importante porque o caminho de execução se pode tornar dinâmico. Um agente pode começar com um sistema, descobrir que precisa de algum contexto adicional, chamar outra coisa, deparar-se com um resultado que não esperava, rever a sua abordagem e continuar. As arquiteturas de agentes atuais são explicitamente construídas em torno desta capacidade de gerir um fluxo de trabalho, escolher ferramentas e tomar medidas dependendo do estado da tarefa.
Esta é uma proposta materialmente diferente da automação convencional. O software já não está simplesmente a executar um fluxo predeterminado. Dentro de quaisquer limites que estabeleçamos em seu redor, estamos a dar-lhe alguma discricionariedade sobre a forma como esse fluxo se desenrola.
E é aí que isto se torna muito mais interessante do que outra conversa sobre se a IA pode escrever um e-mail melhor.
A oportunidade reside em remover a coordenação, não as pessoas
Uma quantidade surpreendente de trabalho dentro de uma organização não é difícil porque uma tarefa individual seja particularmente complicada. É difícil devido à coordenação necessária entre as tarefas.
Abra o CRM. Encontre o cliente. Copie um identificador para a plataforma de faturação. Leia as notas. Verifique outro sistema. Descubra o que significam. Pergunte a outra equipa se algo é normal. Aguarde pela resposta. Atualize a primeira plataforma e envie um e-mail ao cliente.
Parece-lhe familiar?
Passámos anos a tentar automatizar esses processos, e a tecnologia de fluxo de trabalho convencional é extremamente eficaz quando os passos podem ser descritos de forma previsível. As partes difíceis tendem a ser as exceções: o documento que não está estruturado corretamente, a conta que não coincide bem, três sistemas que discordam entre si, ou o ponto no processo em que alguém precisa de ler algo e compreender o que significa antes de saber o que fazer a seguir.
Esses são precisamente os tipos de fluxos de trabalho onde os agentes potencialmente se tornam úteis. As diretrizes atuais da OpenAI identificam especificamente tomadas de decisão complexas, regras difíceis de manter e uma forte dependência de informação não estruturada como áreas onde uma abordagem baseada em agentes pode oferecer algo que a automação determinística convencional não oferece. Também realça o ponto importante de que, onde essas características estão ausentes, uma solução determinística pode ainda ser a melhor resposta.
Se o software puder assumir parte da coordenação entre sistemas, informações e decisões, há potencialmente um ganho de eficiência significativo. Não porque todos os envolvidos no processo desapareçam de repente, mas porque podemos parar de usar pessoas como middleware dispendioso entre plataformas que nunca foram particularmente boas a coordenarem-se entre si.
Há uma distinção importante aí. O objetivo não deve necessariamente ser remover as pessoas da organização. Deve ser remover o trabalho que atualmente obrigamos as pessoas a fazer simplesmente porque a tecnologia por baixo delas não consegue lidar muito bem com o contexto, a ambiguidade ou as exceções.
É por isso que penso que a oportunidade em torno dos agentes é muito mais significativa do que a produtividade incremental. Redigir uma resposta ao cliente dez segundos mais rápido é útil. Permitir que o software investigue o problema, concilie a informação relevante e leve o processo por diante é algo inteiramente diferente.
Claro que, quanto mais longe ele levar o processo, mais perto acaba por ficar de uma ação com consequências.
And that is where things become rather more complicated.
Capacidade não é autoridade
Poucos meses antes do incidente da Hugging Face, a PocketOS publicou um relato sincero de um agente de IA que apagou a base de dados de produção da empresa. A eliminação demorou nove segundos. A recuperação demorou sessenta horas. As suas cópias de segurança existiam, mas estavam com três meses de atraso porque o processo de cópia de segurança tinha deixado de funcionar silenciosamente.
A PocketOS também é muito clara ao afirmar que isto não foi simplesmente um "problema de IA". A empresa afirma que o agente agiu com confiança utilizando permissões que nunca deveria ter tido, contra um ambiente que não tinha fricção suficiente em torno da ação destrutiva.
Essa é a lição útil.
Os humanos têm vindo a apagar bases de dados de produção há anos, e os erros de software também deram uma contribuição respeitável. A parte interessante é que o interveniente tinha autoridade suficiente para que o seu erro importasse.
Nós já compreendemos isto quando o interveniente é humano. Alguém no atendimento ao cliente pode estar autorizado a emitir um reembolso de 20 £ sem que ninguém se importe muito. 200 £ podem ainda ser inteiramente razoáveis. 20.000 £ provavelmente introduzem outra conversa.
O mesmo se aplica a outros contextos. Um agente identificar um erro ortográfico em alguns metadados de conteúdo e corrigi-lo é provavelmente algo bastante inofensivo. Se o campo que ele quer alterar determinar se esse conteúdo pode ser distribuído num território específico, a consequência é muito diferente. Da mesma forma, um agente pode identificar corretamente um problema de configuração de produção, mas isso não significa que deva herdar direitos ilimitados para reconfigurar todo o ambiente.
Nada disto é particularmente exótico. Trata-se de gestão de identidades e acessos aplicada a um novo tipo de interveniente, e suspeito que se tornará um dos alicerces de uma governação de IA baseada em agentes eficaz.
A Microsoft já está a tratar os agentes nestes termos. As suas diretrizes atuais recomendam uma identidade de agente de IA única e dedicada, um proprietário ou patrocinador nomeado, propósito e acesso a dados claramente documentados, acesso com privilégios mínimos, permissões de ferramentas controladas, registo de logs e caminhos de revogação testados. O trabalho do NIST na mesma área está explicitamente a examinar a identificação, autorização, auditoria e o não repúdio para agentes de IA.
Em termos práticos, isso significa que as permissões de agentes de IA precisam de ser tratadas com a mesma seriedade que as contas de utilizadores humanos e de serviços privilegiadas. Um agente pode ser perfeitamente capaz de determinar o que pensa que deve acontecer sem ter o direito de fazer com que isso aconteça.
Essa distinção é importante. Os controlos de agentes de IA não podem simplesmente questionar se um modelo é tecnicamente capaz de realizar uma ação. Precisam de determinar se este agente específico, agindo neste contexto específico, está autorizado a realizá-la.
Como nota lateral, suspeito que a proliferação de agentes de IA se tornará um daqueles problemas que as organizações não pensam que têm até que alguém finalmente pergunte: "Quantos agentes temos realmente?" Já passámos por variações disto com aplicações SaaS, recursos na nuvem, contas de serviço e chaves de API. Não há nenhuma razão óbvia para que o parque de agentes se organize melhor, particularmente em empresas onde a experimentação é deliberadamente descentralizada pelas equipas.
Isso não significa centralizar todas as iniciativas de IA. É improvável que uma equipa central compreenda cada processo suficientemente bem para identificar todas as aplicações úteis por si mesma. A inovação descentralizada pode ser inteiramente sensata.
Autoridade descentralizada por acidente é uma questão diferente.
A IA baseada em agentes herda todos os compromissos do seu parque digital
Há outra questão incómoda por baixo de tudo isto. O seu agente vai herdar o seu parque digital existente.
As APIs brilhantes, os sistemas legados, os registos de clientes inconsistentes, a integração que alguém escreveu há oito anos e em que ninguém quer mexer, e a plataforma que chama uma coisa a um cliente enquanto outra plataforma lhe chama outra coisa. Uma empresa cresce, as plataformas são compradas, as equipas resolvem problemas individuais, ocorrem aquisições, os fornecedores mudam e as prioridades movem-se. Eventualmente, acaba por ter aquilo a que todos se referem educadamente como a arquitetura atual.
Agora imagine um agente a lidar com um cliente que pagou por um serviço mas não consegue aceder ao mesmo. A resposta pode exigir informações dos sistemas de CRM, faturação, autenticação, direitos e suporte antes que alguém possa determinar o que realmente aconteceu.
Um operador humano lida muitas vezes com as inconsistências quase sem pensar nelas. Sabe que um sistema atualiza antes de outro. Repara que os identificadores são ligeiramente diferentes. Talvez se lembre de que os clientes de um pacote antigo se comportam de forma diferente, ou simplesmente pergunta à pessoa sentada ao seu lado porque a documentação não é atualizada desde 2023.
Dê o trabalho a um agente e esses pressupostos precisam de existir em algum lugar. Qual é o sistema que dita as regras? O que acontece se a faturação disser que o pagamento foi bem-sucedido mas a plataforma de direitos disser que a conta está inativa? A informação está errada ou existe uma regra de negócio que o agente não compreende? Uma plataforma está simplesmente cinco minutos atrasada?
Estes são problemas antigos de dados e arquitetura com um novo consumidor. A diferença material é que o consumidor pode agora tomar medidas com base em qualquer conclusão a que chegue.
Dados fracos a alimentar um chatbot podem produzir uma resposta má. Dados fracos a alimentar software autónomo podem produzir um resultado mau.
Há também outra complicação. A informação não tem necessariamente de estar errada por acidente. Uma investigação publicada em julho demonstrou ataques de injeção de dados em agentes, nos quais a informação controlada por um atacante podia ser apresentada como dados contextuais aparentemente legítimos e influenciar o que um agente fazia subsequentemente. Os investigadores identificaram vulnerabilidades em agentes reais da web e de codificação que podiam resultar em cliques não intencionais, execução remota de código e ações na cadeia de abastecimento de software.
Isso cria um cruzamento desconfortável entre a arquitetura de dados e a segurança. Se a informação pode influenciar a ação, a origem dessa informação, se ela pode ser confiável e quanto peso o agente lhe deve dar já não são preocupações abstratas de governação. Tornam-se parte do modelo de execução.
É também por isso que teria cuidado com a ideia de que os agentes de alguma forma tornam a dívida técnica menos importante. Um agente pode tornar ambientes fragmentados mais fáceis de navegar porque pode raciocinar sobre uma tarefa em vez de depender inteiramente de um caminho de integração fixo, mas ainda precisa de acesso a sistemas, interfaces utilizáveis, dados significativos, permissões apropriadas e alguma ideia do que fazer quando algo falha a meio do caminho.
Se a API não existir, o agente precisa de outra forma de entrar. Se o mesmo cliente tiver seis identificadores, alguém ou algo ainda precisa de estabelecer se representam a mesma pessoa. Se uma regra de negócio não documentada for importante para a decisão, esse conhecimento precisa de estar disponível em algum lugar.
Colocar uma camada de orquestração inteligente à frente de um parque desorganizado não faz com que o parque deixe de ser desorganizado. Pode tornar a desorganização mais fácil de navegar. Pode também permitir que as consequências dessa desorganização se propaguem consideravelmente mais rápido.
A supervisão humana tem um custo económico
Neste ponto da maioria das conversas, alguém dirá que haverá sempre um humano no processo.
Isso parece reconfortante, mas levanta uma questão óbvia: se alguém ainda precisa de rever e aprovar tudo o que o agente faz, quanto é que realmente automatizámos?
Imagine que o nosso agente de apoio ao cliente verificou cinco sistemas, identificou um problema na conta, estabeleceu que o cliente foi cobrado incorretamente e calculou que um reembolso de 20 £ é adequado. Em seguida, coloca tudo numa fila para que alguém clique em "Aprovar".
Pode ainda haver uma poupança significativa porque a investigação foi automatizada, mas execute esse processo em dezenas de milhares de transações e terá mantido uma operação manual de dimensão considerável. O estrangulamento mudou de lugar em vez de desaparecer.
É aqui que alguma da linguagem mais segura em torno da IA baseada em agentes começa a entrar em conflito com a economia da automação. Introduzimos a autonomia porque queremos que o software remova o trabalho de um processo, e depois ficamos suficientemente nervosos com a autonomia ao ponto de colocar uma pessoa de volta em cada transação.
Eventualmente, isso acaba por anular o objetivo.
O desafio com a supervisão de agentes de IA é, portanto, que mais supervisão não é automaticamente melhor. Cada etapa de aprovação pode reduzir um tipo específico de risco, mas também reintroduz custo, latência e esforço manual no processo. A melhor questão é onde o julgamento humano acrescenta genuinamente valor.
Se o reembolso for de 20 £, as regras forem claras, todos os sistemas relevantes concordarem e a ação puder ser facilmente revertida, talvez ninguém precise de a aprovar. Se o valor for de 20.000 £, dois sistemas discordarem ou a situação ficar fora dos parâmetros normais, esse parece ser um excelente momento para envolver alguém.
Para muitos processos, o destino útil não é, portanto, o humano no processo, mas sim o humano por exceção. O trabalho rotineiro e bem compreendido torna-se cada vez mais autónomo, enquanto os casos invulgares, ambíguos ou de elevadas consequências são escalados.
Isso ainda deixa muito espaço para introduzir a autonomia gradualmente. Um agente pode começar por observar e recomendar. Assim que o seu comportamento for compreendido, pode preparar ações para aprovação. Eventualmente, classes específicas de ações rotineiras e reversíveis podem ser executadas automaticamente, com as pessoas a envolverem-se quando o processo ultrapassa um limite acordado.
As diretrizes da OpenAI adotam uma abordagem semelhante baseada no risco. Recomendam a intervenção humana quando os agentes excedem limites de falha definidos e em torno de ações que são sensíveis, irreversíveis ou de alto risco, tais como reembolsos ou pagamentos avultados.
A PocketOS chegou ao mesmo problema a partir de uma direção consideravelmente menos teórica. Após o incidente com a sua base de dados, as operações destrutivas requerem agora confirmação humana explícita. Tem de haver um botão físico carregado por uma pessoa real para confirmar a ação. A empresa não respondeu abandonando os agentes autónomos. Afirma que continua a executar uma série de agentes autónomos específicos em produção, alterando simultaneamente onde se situa a fronteira de controlo.
Essa parece-me ser a forma mais útil de pensar sobre a supervisão humana. É um controlo que deve ser aplicado onde a consequência o justifica, não necessariamente um modelo operacional permanente para cada ação executada por software autónomo.
O objetivo da automação é, afinal de contas, automatizar. O problema de design é decidir onde as pessoas melhoram genuinamente o resultado e onde estão simplesmente a ser mantidas porque ainda não confiamos no sistema o suficiente para as remover.
Autonomia sem rastreabilidade é operacionalmente indefensável
Se avançarmos para os humanos por exceção, outra coisa torna-se mais importante e não menos: compreender o que o agente realmente fez.
A investigação da Hugging Face é um exemplo extremo útil. A sua reconstrução forense cobriu cerca de 17.600 ações em milhares de clusters, com os investigadores a juntarem as peças de como o agente se moveu pelos sistemas e adaptou o seu comportamento ao longo do tempo.
Traga isso para um processo de negócio normal. Um cliente diz que algo foi alterado incorretamente na sua conta e descobre que um agente fez a alteração.
"A IA fez isso" é improvável que o leve muito longe na revisão do incidente.
Irá querer saber qual o agente que agiu, quem iniciou a tarefa, que informação utilizou, o que essa informação continha na altura, que ferramentas chamou e que permissão permitiu, em última análise, a alteração. Se outro agente se envolveu pelo caminho, isso provavelmente também importa.
É aqui que a auditabilidade de agentes de IA deixa de ser uma cortesia de governação e se torna um requisito operacional. Quanto menos envolvimento humano direto houver na execução, mais forte precisa de se tornar a observabilidade circundante.
As diretrizes atuais da Microsoft recomendam o registo da identidade do agente, da sua função e âmbito efetivo, da ação realizada, do recurso afetado e de qualquer utilizador em nome do qual estivesse a agir. O NIST está, de igual modo, a considerar explicitamente a auditoria e o não repúdio como parte do problema de identidade e autorização para agentes.
Isso não significa que cada ação autónoma precise de ter alguém a observá-la. Já operamos ambientes automatizados enormes sem colocar uma pessoa em frente de cada transação, evento de infraestrutura ou pedido de rede. Estabelecemos limites, controlos e monitorização e, em seguida, investigamos as coisas que ficam fora deles.
Não há nenhuma razão óbvia para que sistemas baseados em agentes maduros funcionem de forma diferente.
A autonomia não remove a supervisão. Altera o momento em que a supervisão acontece.
A intenção delegada complica a fronteira de confiança
Há mais um desenvolvimento que vale a pena observar porque torna este problema ainda mais interessante.
Os agentes estão a ser cada vez mais desenhados para comunicar e colaborar com outros agentes. O protocolo Agent2Agent da Google padroniza a forma como os agentes se podem descobrir e comunicar entre si, incluindo agentes construídos por diferentes equipas e em diferentes pilhas tecnológicas. O seu trabalho mais recente de Descoberta de Recursos de Agentes aborda a questão relacionada de como os agentes podem encontrar e verificar ferramentas, competências e outros agentes distribuídos por equipas, organizações e plataformas.
Imagine que um agente interno recebe uma tarefa e determina que outro agente especialista pode executar parte dela. Esse segundo agente utiliza uma ferramenta que chama um dos seus serviços e, em última análise, altera algo.
Quem está a agir?
O segundo agente? O primeiro agente? A pessoa que iniciou a tarefa original?
Se o primeiro agente estiver autorizado a realizar uma ação, pode delegar essa autoridade? O segundo agente recebe-a na totalidade, em parte ou de todo? O que acontece se os agentes pertencerem a organizações diferentes?
Estas são questões emergentes e seria prematuro fingir que a indústria chegou a acordo sobre todas as respostas. A Iniciativa de Padrões de Agentes de IA do NIST está a realizar explicitamente trabalhos em torno da autenticação de agentes e da infraestrutura de identidade para apoiar interações seguras entre humanos e agentes e entre múltiplos agentes.
Mas a direção importa. Historicamente, a confiança tem sido frequentemente associada a um utilizador, aplicação ou integração conhecidos. Assim que os agentes puderem descobrir capacidades dinamicamente e delegar partes de um objetivo para outro local, a confiança e a autoridade precisam de sobreviver à viagem.
A tarefa pode ser dinâmica. A responsabilidade não pode desaparecer sempre que cruza outra fronteira.
A transformação baseada em agentes deve começar com a delegação, não com a tecnologia
Há um padrão com mudanças tecnológicas significativas que a maioria das pessoas envolvidas na transformação reconhecerá. Algo torna-se estrategicamente importante, alguém decide que a organização precisa disso e todos começam a procurar um lugar onde colocar esse algo.
Precisamos de uma estratégia de IA. Precisamos de alguns casos de utilização de agentes. Devemos realizar um workshop. Que processos podemos tornar baseados em agentes?
Eu provavelmente abordaria a questão ao contrário.
Comece com o processo que irrita toda a gente. Aquele que é lento, dispendioso, fragmentado ou que depende de alguém a transferir informação entre sistemas o dia todo. Compreenda onde as decisões são tomadas, em que informações essas decisões se apoiam, que sistemas estão envolvidos, onde ocorrem as exceções complicadas e o que acontece quando algo corre mal.
Depois, olhe para o que as pessoas no processo estão realmente a fazer. Estão a exercer um julgamento valioso ou estão a compensar limitações na tecnologia que as rodeia? Estão a aprovar algo porque existe um risco financeiro ou operacional real, ou porque o fluxo de trabalho não consegue distinguir um caso rotineiro de um invulgar? Estão a conciliar manualmente a informação porque a organização precisa genuinamente da sua experiência ou porque dois sistemas utilizam identificadores diferentes?
Esses são problemas bastante diferentes.
Assim que compreender isso, decida o que está disposto a delegar. Que decisões pode o software tomar? Que ações pode realizar? Quais são reversíveis? Onde precisa de escalamento? Que autoridade exige? De que provas necessitaria mais tarde se alguém perguntasse por que razão uma decisão foi tomada?
Só então a escolha da tecnologia se torna particularmente interessante.
Um agente pode ser uma excelente resposta. Pode não ser. Não há problema. As diretrizes atuais sobre o design de agentes fazem uma distinção muito semelhante: os agentes são adequados para fluxos de trabalho onde a ambiguidade, as decisões complexas ou os dados não estruturados fazem com que as abordagens determinísticas tenham dificuldades, mas onde essas características estão ausentes, a automação convencional pode continuar a ser inteiramente suficiente.
O objetivo não é implementar agentes. É melhorar o negócio.
A arquitetura da automação está a tornar-se a arquitetura da autoridade
Nos últimos vinte anos, a transformação digital envolveu em grande parte a ligação de pessoas a sistemas e de sistemas entre si. Estamos agora a começar a introduzir outro participante nesse parque: software que pode receber um objetivo, determinar como persegui-lo e utilizar esses sistemas em nosso nome.
Existem algumas possibilidades genuinamente interessantes nisso, particularmente em torno do trabalho de coordenação que tem resistido à automação convencional. O próprio NIST descreve o potencial para os agentes melhorarem a produtividade, a eficiência e a tomada de decisões, ao mesmo tempo que realça a necessidade de controlos adequados de identificação e autorização quando esses agentes têm acesso a dados, ferramentas e aplicações organizacionais.
Penso que essa combinação é importante. A oportunidade e o risco advêm da mesma característica: o agente tem alguma liberdade para decidir como o trabalho é feito.
Assim que isso acontece, a arquitetura já não se preocupa apenas em saber se um sistema se pode ligar a outro. Determina cada vez mais qual o interveniente autónomo que pode utilizar que informação, exercer que capacidade, sob a autoridade de quem, com que limites e com que provas deixadas para trás.
Na prática, é improvável que a governação de agentes de IA empresariais seja resolvida por mais um documento de política guardado algures na intranet. Tem de se manifestar nas identidades que criamos, nas permissões que concedemos, nos controlos em torno de ações consequentes, na qualidade e proveniência dos dados que os agentes consomem, nos caminhos de escalamento que desenhamos e nas provas de auditoria que retemos depois.
A Hugging Face dá-nos um exemplo extremo de software autónomo a encontrar uma rota que os seus operadores não esperavam. A PocketOS dá-nos um exemplo muito mais quotidiano do que acontece quando um agente tem simplesmente mais autoridade do que a tarefa exige. O trabalho emergente em torno da identidade do agente, privilégio mínimo, interação segura entre múltiplos agentes e descoberta de recursos confiáveis mostra que o modelo de controlo circundante já está a ter de recuperar o atraso em relação à capacidade.
Nada disso é um argumento contra a IA baseada em agentes. Muito pelo contrário. Se os agentes puderem remover alguma da coordenação humana que torna as empresas digitais modernas dispendiosas e complicadas de operar, há uma razão muito tangível para os perseguir.
Mas introduzir intervenientes autónomos num parque digital existente não é simplesmente mais uma implementação de IA. Altera os pressupostos sobre identidade, confiança, dados, responsabilidade e, em última análise, autoridade.
Por isso, antes de perguntar o que um agente pode fazer, eu começaria com uma pergunta diferente.
O que está realmente disposto a deixar que ele faça?
Quando a IA ganha autoridade
Nos últimos anos, as empresas têm-se concentrado no que a IA generativa nos pode dizer. Os agentes de IA introduzem uma questão bastante mais consequente: o que acontece quando o software pode decidir o que fazer a seguir e, depois, fazê-lo realmente?
Em julho de 2026, um agente de IA que estava a ser utilizado como parte de uma avaliação de cibersegurança da OpenAI comprometeu parte da infraestrutura de produção da Hugging Face. Há um contexto importante aqui antes de nos deixarmos levar. Esta não foi uma aplicação de negócios normal que de repente decidiu atacar outra empresa. A OpenAI estava deliberadamente a testar modelos altamente capazes contra tarefas de cibersegurança difíceis, e os classificadores de produção normalmente utilizados para impedir que os modelos prosseguissem atividades cibernéticas de alto risco foram intencionalmente desativados para a avaliação.
Mesmo assim, vale a pena prestar atenção ao que aconteceu. De acordo com as investigações subsequentes, o agente parece ter concluído que a informação detida pela Hugging Face poderia ajudá-lo a concluir o teste de referência que lhe tinha sido atribuído. Encontrou uma saída através de uma vulnerabilidade de dia zero na infraestrutura utilizada pelo ambiente de avaliação, obteve um acesso mais amplo à Internet, encadeou outros caminhos de ataque, obteve credenciais e acabou por chegar aos sistemas da Hugging Face. A reconstrução forense da Hugging Face cobriu cerca de 17.600 ações individuais, agrupadas em aproximadamente 6.280 clusters.
A tentação, naturalmente, é recorrer à manchete "A IA escapou" ou "A IA rebelou-se". Não tenho a certeza de que qualquer uma das duas seja particularmente útil. Tanto quanto as investigações conseguiram estabelecer, o software estava a tentar atingir o objetivo que lhe tinha sido dado e encontrou uma rota que ninguém esperava que seguisse. A Hugging Face acredita que o agente estava efetivamente a tentar fazer batota na avaliação ao aceder a sistemas de produção onde pensava que a informação do teste de referência ou as soluções poderiam estar disponíveis.
Isso é consideravelmente menos teatral, mas, do ponto de vista da transformação digital, provavelmente mais importante.
Nos últimos anos, a maioria das organizações tem experienciado a IA generativa como algo a quem fazem perguntas. Dá-se-lhe alguma informação, faz-se uma pergunta e obtém-se algo de volta. Pode resumir um contrato, analisar alguns dados, escrever algum código ou redigir um e-mail, mas geralmente ainda há uma pessoa sentada do outro lado a decidir o que acontece a seguir.
Os agentes começam a esbater essa fronteira. Dê a essa mesma inteligência acesso a ferramentas e ela poderá recuperar informação, chamar uma API, atualizar um registo, executar algum código, enviar o e-mail ou fazer a alteração ela mesma. A OpenAI descreve os agentes de forma muito semelhante: sistemas que podem gerir de forma independente a execução do fluxo de trabalho, tomar decisões, selecionar ferramentas apropriadas e interagir com sistemas externos em nome do utilizador.
O chatbot acabou de obter acesso de escrita.
Essa mudança é a razão pela qual a governação de agentes de IA se está a tornar uma preocupação empresarial prática, em vez de ser simplesmente mais uma discussão de políticas. Assim que o software pode tomar medidas em vez de fazer recomendações, as questões sobre identidade, permissões, controlos, auditabilidade e responsabilidade movem-se para a própria arquitetura.
A automação muda quando é dada intenção ao software, não instruções
O software tem vindo a mudar as coisas há décadas, por isso existe o perigo de vender em demasia o que há de novo aqui. Não precisamos de IA para atualizar uma base de dados, acionar uma API ou executar um fluxo de trabalho. Scripts, motores de regras, plataformas de orquestração e processos automatizados têm feito esses trabalhos perfeitamente bem há anos.
A diferença está em como passamos do objetivo para a ação. A automação tradicional é normalmente desenhada em torno de uma rota que alguém descreveu antecipadamente. Quando X acontece, recupera Y. Se a resposta for Z, executa esta ação. Podem estar envolvidas centenas de regras, ramificações e exceções, mas alguém tentou modelar o processo previamente.
Os agentes potencialmente permitem-nos avançar mais no sentido de dar ao software um resultado, em vez de cada instrução necessária para o alcançar. Aqui está o problema. Descubra de que informação precisa. Decida quais as ferramentas adequadas. Lide com o que vem de volta e faça o trabalho.
Essa distinção é importante porque o caminho de execução se pode tornar dinâmico. Um agente pode começar com um sistema, descobrir que precisa de algum contexto adicional, chamar outra coisa, deparar-se com um resultado que não esperava, rever a sua abordagem e continuar. As arquiteturas de agentes atuais são explicitamente construídas em torno desta capacidade de gerir um fluxo de trabalho, escolher ferramentas e tomar medidas dependendo do estado da tarefa.
Esta é uma proposta materialmente diferente da automação convencional. O software já não está simplesmente a executar um fluxo predeterminado. Dentro de quaisquer limites que estabeleçamos em seu redor, estamos a dar-lhe alguma discricionariedade sobre a forma como esse fluxo se desenrola.
E é aí que isto se torna muito mais interessante do que outra conversa sobre se a IA pode escrever um e-mail melhor.
A oportunidade reside em remover a coordenação, não as pessoas
Uma quantidade surpreendente de trabalho dentro de uma organização não é difícil porque uma tarefa individual seja particularmente complicada. É difícil devido à coordenação necessária entre as tarefas.
Abra o CRM. Encontre o cliente. Copie um identificador para a plataforma de faturação. Leia as notas. Verifique outro sistema. Descubra o que significam. Pergunte a outra equipa se algo é normal. Aguarde pela resposta. Atualize a primeira plataforma e envie um e-mail ao cliente.
Parece-lhe familiar?
Passámos anos a tentar automatizar esses processos, e a tecnologia de fluxo de trabalho convencional é extremamente eficaz quando os passos podem ser descritos de forma previsível. As partes difíceis tendem a ser as exceções: o documento que não está estruturado corretamente, a conta que não coincide bem, três sistemas que discordam entre si, ou o ponto no processo em que alguém precisa de ler algo e compreender o que significa antes de saber o que fazer a seguir.
Esses são precisamente os tipos de fluxos de trabalho onde os agentes potencialmente se tornam úteis. As diretrizes atuais da OpenAI identificam especificamente tomadas de decisão complexas, regras difíceis de manter e uma forte dependência de informação não estruturada como áreas onde uma abordagem baseada em agentes pode oferecer algo que a automação determinística convencional não oferece. Também realça o ponto importante de que, onde essas características estão ausentes, uma solução determinística pode ainda ser a melhor resposta.
Se o software puder assumir parte da coordenação entre sistemas, informações e decisões, há potencialmente um ganho de eficiência significativo. Não porque todos os envolvidos no processo desapareçam de repente, mas porque podemos parar de usar pessoas como middleware dispendioso entre plataformas que nunca foram particularmente boas a coordenarem-se entre si.
Há uma distinção importante aí. O objetivo não deve necessariamente ser remover as pessoas da organização. Deve ser remover o trabalho que atualmente obrigamos as pessoas a fazer simplesmente porque a tecnologia por baixo delas não consegue lidar muito bem com o contexto, a ambiguidade ou as exceções.
É por isso que penso que a oportunidade em torno dos agentes é muito mais significativa do que a produtividade incremental. Redigir uma resposta ao cliente dez segundos mais rápido é útil. Permitir que o software investigue o problema, concilie a informação relevante e leve o processo por diante é algo inteiramente diferente.
Claro que, quanto mais longe ele levar o processo, mais perto acaba por ficar de uma ação com consequências.
And that is where things become rather more complicated.
Capacidade não é autoridade
Poucos meses antes do incidente da Hugging Face, a PocketOS publicou um relato sincero de um agente de IA que apagou a base de dados de produção da empresa. A eliminação demorou nove segundos. A recuperação demorou sessenta horas. As suas cópias de segurança existiam, mas estavam com três meses de atraso porque o processo de cópia de segurança tinha deixado de funcionar silenciosamente.
A PocketOS também é muito clara ao afirmar que isto não foi simplesmente um "problema de IA". A empresa afirma que o agente agiu com confiança utilizando permissões que nunca deveria ter tido, contra um ambiente que não tinha fricção suficiente em torno da ação destrutiva.
Essa é a lição útil.
Os humanos têm vindo a apagar bases de dados de produção há anos, e os erros de software também deram uma contribuição respeitável. A parte interessante é que o interveniente tinha autoridade suficiente para que o seu erro importasse.
Nós já compreendemos isto quando o interveniente é humano. Alguém no atendimento ao cliente pode estar autorizado a emitir um reembolso de 20 £ sem que ninguém se importe muito. 200 £ podem ainda ser inteiramente razoáveis. 20.000 £ provavelmente introduzem outra conversa.
O mesmo se aplica a outros contextos. Um agente identificar um erro ortográfico em alguns metadados de conteúdo e corrigi-lo é provavelmente algo bastante inofensivo. Se o campo que ele quer alterar determinar se esse conteúdo pode ser distribuído num território específico, a consequência é muito diferente. Da mesma forma, um agente pode identificar corretamente um problema de configuração de produção, mas isso não significa que deva herdar direitos ilimitados para reconfigurar todo o ambiente.
Nada disto é particularmente exótico. Trata-se de gestão de identidades e acessos aplicada a um novo tipo de interveniente, e suspeito que se tornará um dos alicerces de uma governação de IA baseada em agentes eficaz.
A Microsoft já está a tratar os agentes nestes termos. As suas diretrizes atuais recomendam uma identidade de agente de IA única e dedicada, um proprietário ou patrocinador nomeado, propósito e acesso a dados claramente documentados, acesso com privilégios mínimos, permissões de ferramentas controladas, registo de logs e caminhos de revogação testados. O trabalho do NIST na mesma área está explicitamente a examinar a identificação, autorização, auditoria e o não repúdio para agentes de IA.
Em termos práticos, isso significa que as permissões de agentes de IA precisam de ser tratadas com a mesma seriedade que as contas de utilizadores humanos e de serviços privilegiadas. Um agente pode ser perfeitamente capaz de determinar o que pensa que deve acontecer sem ter o direito de fazer com que isso aconteça.
Essa distinção é importante. Os controlos de agentes de IA não podem simplesmente questionar se um modelo é tecnicamente capaz de realizar uma ação. Precisam de determinar se este agente específico, agindo neste contexto específico, está autorizado a realizá-la.
Como nota lateral, suspeito que a proliferação de agentes de IA se tornará um daqueles problemas que as organizações não pensam que têm até que alguém finalmente pergunte: "Quantos agentes temos realmente?" Já passámos por variações disto com aplicações SaaS, recursos na nuvem, contas de serviço e chaves de API. Não há nenhuma razão óbvia para que o parque de agentes se organize melhor, particularmente em empresas onde a experimentação é deliberadamente descentralizada pelas equipas.
Isso não significa centralizar todas as iniciativas de IA. É improvável que uma equipa central compreenda cada processo suficientemente bem para identificar todas as aplicações úteis por si mesma. A inovação descentralizada pode ser inteiramente sensata.
Autoridade descentralizada por acidente é uma questão diferente.
A IA baseada em agentes herda todos os compromissos do seu parque digital
Há outra questão incómoda por baixo de tudo isto. O seu agente vai herdar o seu parque digital existente.
As APIs brilhantes, os sistemas legados, os registos de clientes inconsistentes, a integração que alguém escreveu há oito anos e em que ninguém quer mexer, e a plataforma que chama uma coisa a um cliente enquanto outra plataforma lhe chama outra coisa. Uma empresa cresce, as plataformas são compradas, as equipas resolvem problemas individuais, ocorrem aquisições, os fornecedores mudam e as prioridades movem-se. Eventualmente, acaba por ter aquilo a que todos se referem educadamente como a arquitetura atual.
Agora imagine um agente a lidar com um cliente que pagou por um serviço mas não consegue aceder ao mesmo. A resposta pode exigir informações dos sistemas de CRM, faturação, autenticação, direitos e suporte antes que alguém possa determinar o que realmente aconteceu.
Um operador humano lida muitas vezes com as inconsistências quase sem pensar nelas. Sabe que um sistema atualiza antes de outro. Repara que os identificadores são ligeiramente diferentes. Talvez se lembre de que os clientes de um pacote antigo se comportam de forma diferente, ou simplesmente pergunta à pessoa sentada ao seu lado porque a documentação não é atualizada desde 2023.
Dê o trabalho a um agente e esses pressupostos precisam de existir em algum lugar. Qual é o sistema que dita as regras? O que acontece se a faturação disser que o pagamento foi bem-sucedido mas a plataforma de direitos disser que a conta está inativa? A informação está errada ou existe uma regra de negócio que o agente não compreende? Uma plataforma está simplesmente cinco minutos atrasada?
Estes são problemas antigos de dados e arquitetura com um novo consumidor. A diferença material é que o consumidor pode agora tomar medidas com base em qualquer conclusão a que chegue.
Dados fracos a alimentar um chatbot podem produzir uma resposta má. Dados fracos a alimentar software autónomo podem produzir um resultado mau.
Há também outra complicação. A informação não tem necessariamente de estar errada por acidente. Uma investigação publicada em julho demonstrou ataques de injeção de dados em agentes, nos quais a informação controlada por um atacante podia ser apresentada como dados contextuais aparentemente legítimos e influenciar o que um agente fazia subsequentemente. Os investigadores identificaram vulnerabilidades em agentes reais da web e de codificação que podiam resultar em cliques não intencionais, execução remota de código e ações na cadeia de abastecimento de software.
Isso cria um cruzamento desconfortável entre a arquitetura de dados e a segurança. Se a informação pode influenciar a ação, a origem dessa informação, se ela pode ser confiável e quanto peso o agente lhe deve dar já não são preocupações abstratas de governação. Tornam-se parte do modelo de execução.
É também por isso que teria cuidado com a ideia de que os agentes de alguma forma tornam a dívida técnica menos importante. Um agente pode tornar ambientes fragmentados mais fáceis de navegar porque pode raciocinar sobre uma tarefa em vez de depender inteiramente de um caminho de integração fixo, mas ainda precisa de acesso a sistemas, interfaces utilizáveis, dados significativos, permissões apropriadas e alguma ideia do que fazer quando algo falha a meio do caminho.
Se a API não existir, o agente precisa de outra forma de entrar. Se o mesmo cliente tiver seis identificadores, alguém ou algo ainda precisa de estabelecer se representam a mesma pessoa. Se uma regra de negócio não documentada for importante para a decisão, esse conhecimento precisa de estar disponível em algum lugar.
Colocar uma camada de orquestração inteligente à frente de um parque desorganizado não faz com que o parque deixe de ser desorganizado. Pode tornar a desorganização mais fácil de navegar. Pode também permitir que as consequências dessa desorganização se propaguem consideravelmente mais rápido.
A supervisão humana tem um custo económico
Neste ponto da maioria das conversas, alguém dirá que haverá sempre um humano no processo.
Isso parece reconfortante, mas levanta uma questão óbvia: se alguém ainda precisa de rever e aprovar tudo o que o agente faz, quanto é que realmente automatizámos?
Imagine que o nosso agente de apoio ao cliente verificou cinco sistemas, identificou um problema na conta, estabeleceu que o cliente foi cobrado incorretamente e calculou que um reembolso de 20 £ é adequado. Em seguida, coloca tudo numa fila para que alguém clique em "Aprovar".
Pode ainda haver uma poupança significativa porque a investigação foi automatizada, mas execute esse processo em dezenas de milhares de transações e terá mantido uma operação manual de dimensão considerável. O estrangulamento mudou de lugar em vez de desaparecer.
É aqui que alguma da linguagem mais segura em torno da IA baseada em agentes começa a entrar em conflito com a economia da automação. Introduzimos a autonomia porque queremos que o software remova o trabalho de um processo, e depois ficamos suficientemente nervosos com a autonomia ao ponto de colocar uma pessoa de volta em cada transação.
Eventualmente, isso acaba por anular o objetivo.
O desafio com a supervisão de agentes de IA é, portanto, que mais supervisão não é automaticamente melhor. Cada etapa de aprovação pode reduzir um tipo específico de risco, mas também reintroduz custo, latência e esforço manual no processo. A melhor questão é onde o julgamento humano acrescenta genuinamente valor.
Se o reembolso for de 20 £, as regras forem claras, todos os sistemas relevantes concordarem e a ação puder ser facilmente revertida, talvez ninguém precise de a aprovar. Se o valor for de 20.000 £, dois sistemas discordarem ou a situação ficar fora dos parâmetros normais, esse parece ser um excelente momento para envolver alguém.
Para muitos processos, o destino útil não é, portanto, o humano no processo, mas sim o humano por exceção. O trabalho rotineiro e bem compreendido torna-se cada vez mais autónomo, enquanto os casos invulgares, ambíguos ou de elevadas consequências são escalados.
Isso ainda deixa muito espaço para introduzir a autonomia gradualmente. Um agente pode começar por observar e recomendar. Assim que o seu comportamento for compreendido, pode preparar ações para aprovação. Eventualmente, classes específicas de ações rotineiras e reversíveis podem ser executadas automaticamente, com as pessoas a envolverem-se quando o processo ultrapassa um limite acordado.
As diretrizes da OpenAI adotam uma abordagem semelhante baseada no risco. Recomendam a intervenção humana quando os agentes excedem limites de falha definidos e em torno de ações que são sensíveis, irreversíveis ou de alto risco, tais como reembolsos ou pagamentos avultados.
A PocketOS chegou ao mesmo problema a partir de uma direção consideravelmente menos teórica. Após o incidente com a sua base de dados, as operações destrutivas requerem agora confirmação humana explícita. Tem de haver um botão físico carregado por uma pessoa real para confirmar a ação. A empresa não respondeu abandonando os agentes autónomos. Afirma que continua a executar uma série de agentes autónomos específicos em produção, alterando simultaneamente onde se situa a fronteira de controlo.
Essa parece-me ser a forma mais útil de pensar sobre a supervisão humana. É um controlo que deve ser aplicado onde a consequência o justifica, não necessariamente um modelo operacional permanente para cada ação executada por software autónomo.
O objetivo da automação é, afinal de contas, automatizar. O problema de design é decidir onde as pessoas melhoram genuinamente o resultado e onde estão simplesmente a ser mantidas porque ainda não confiamos no sistema o suficiente para as remover.
Autonomia sem rastreabilidade é operacionalmente indefensável
Se avançarmos para os humanos por exceção, outra coisa torna-se mais importante e não menos: compreender o que o agente realmente fez.
A investigação da Hugging Face é um exemplo extremo útil. A sua reconstrução forense cobriu cerca de 17.600 ações em milhares de clusters, com os investigadores a juntarem as peças de como o agente se moveu pelos sistemas e adaptou o seu comportamento ao longo do tempo.
Traga isso para um processo de negócio normal. Um cliente diz que algo foi alterado incorretamente na sua conta e descobre que um agente fez a alteração.
"A IA fez isso" é improvável que o leve muito longe na revisão do incidente.
Irá querer saber qual o agente que agiu, quem iniciou a tarefa, que informação utilizou, o que essa informação continha na altura, que ferramentas chamou e que permissão permitiu, em última análise, a alteração. Se outro agente se envolveu pelo caminho, isso provavelmente também importa.
É aqui que a auditabilidade de agentes de IA deixa de ser uma cortesia de governação e se torna um requisito operacional. Quanto menos envolvimento humano direto houver na execução, mais forte precisa de se tornar a observabilidade circundante.
As diretrizes atuais da Microsoft recomendam o registo da identidade do agente, da sua função e âmbito efetivo, da ação realizada, do recurso afetado e de qualquer utilizador em nome do qual estivesse a agir. O NIST está, de igual modo, a considerar explicitamente a auditoria e o não repúdio como parte do problema de identidade e autorização para agentes.
Isso não significa que cada ação autónoma precise de ter alguém a observá-la. Já operamos ambientes automatizados enormes sem colocar uma pessoa em frente de cada transação, evento de infraestrutura ou pedido de rede. Estabelecemos limites, controlos e monitorização e, em seguida, investigamos as coisas que ficam fora deles.
Não há nenhuma razão óbvia para que sistemas baseados em agentes maduros funcionem de forma diferente.
A autonomia não remove a supervisão. Altera o momento em que a supervisão acontece.
A intenção delegada complica a fronteira de confiança
Há mais um desenvolvimento que vale a pena observar porque torna este problema ainda mais interessante.
Os agentes estão a ser cada vez mais desenhados para comunicar e colaborar com outros agentes. O protocolo Agent2Agent da Google padroniza a forma como os agentes se podem descobrir e comunicar entre si, incluindo agentes construídos por diferentes equipas e em diferentes pilhas tecnológicas. O seu trabalho mais recente de Descoberta de Recursos de Agentes aborda a questão relacionada de como os agentes podem encontrar e verificar ferramentas, competências e outros agentes distribuídos por equipas, organizações e plataformas.
Imagine que um agente interno recebe uma tarefa e determina que outro agente especialista pode executar parte dela. Esse segundo agente utiliza uma ferramenta que chama um dos seus serviços e, em última análise, altera algo.
Quem está a agir?
O segundo agente? O primeiro agente? A pessoa que iniciou a tarefa original?
Se o primeiro agente estiver autorizado a realizar uma ação, pode delegar essa autoridade? O segundo agente recebe-a na totalidade, em parte ou de todo? O que acontece se os agentes pertencerem a organizações diferentes?
Estas são questões emergentes e seria prematuro fingir que a indústria chegou a acordo sobre todas as respostas. A Iniciativa de Padrões de Agentes de IA do NIST está a realizar explicitamente trabalhos em torno da autenticação de agentes e da infraestrutura de identidade para apoiar interações seguras entre humanos e agentes e entre múltiplos agentes.
Mas a direção importa. Historicamente, a confiança tem sido frequentemente associada a um utilizador, aplicação ou integração conhecidos. Assim que os agentes puderem descobrir capacidades dinamicamente e delegar partes de um objetivo para outro local, a confiança e a autoridade precisam de sobreviver à viagem.
A tarefa pode ser dinâmica. A responsabilidade não pode desaparecer sempre que cruza outra fronteira.
A transformação baseada em agentes deve começar com a delegação, não com a tecnologia
Há um padrão com mudanças tecnológicas significativas que a maioria das pessoas envolvidas na transformação reconhecerá. Algo torna-se estrategicamente importante, alguém decide que a organização precisa disso e todos começam a procurar um lugar onde colocar esse algo.
Precisamos de uma estratégia de IA. Precisamos de alguns casos de utilização de agentes. Devemos realizar um workshop. Que processos podemos tornar baseados em agentes?
Eu provavelmente abordaria a questão ao contrário.
Comece com o processo que irrita toda a gente. Aquele que é lento, dispendioso, fragmentado ou que depende de alguém a transferir informação entre sistemas o dia todo. Compreenda onde as decisões são tomadas, em que informações essas decisões se apoiam, que sistemas estão envolvidos, onde ocorrem as exceções complicadas e o que acontece quando algo corre mal.
Depois, olhe para o que as pessoas no processo estão realmente a fazer. Estão a exercer um julgamento valioso ou estão a compensar limitações na tecnologia que as rodeia? Estão a aprovar algo porque existe um risco financeiro ou operacional real, ou porque o fluxo de trabalho não consegue distinguir um caso rotineiro de um invulgar? Estão a conciliar manualmente a informação porque a organização precisa genuinamente da sua experiência ou porque dois sistemas utilizam identificadores diferentes?
Esses são problemas bastante diferentes.
Assim que compreender isso, decida o que está disposto a delegar. Que decisões pode o software tomar? Que ações pode realizar? Quais são reversíveis? Onde precisa de escalamento? Que autoridade exige? De que provas necessitaria mais tarde se alguém perguntasse por que razão uma decisão foi tomada?
Só então a escolha da tecnologia se torna particularmente interessante.
Um agente pode ser uma excelente resposta. Pode não ser. Não há problema. As diretrizes atuais sobre o design de agentes fazem uma distinção muito semelhante: os agentes são adequados para fluxos de trabalho onde a ambiguidade, as decisões complexas ou os dados não estruturados fazem com que as abordagens determinísticas tenham dificuldades, mas onde essas características estão ausentes, a automação convencional pode continuar a ser inteiramente suficiente.
O objetivo não é implementar agentes. É melhorar o negócio.
A arquitetura da automação está a tornar-se a arquitetura da autoridade
Nos últimos vinte anos, a transformação digital envolveu em grande parte a ligação de pessoas a sistemas e de sistemas entre si. Estamos agora a começar a introduzir outro participante nesse parque: software que pode receber um objetivo, determinar como persegui-lo e utilizar esses sistemas em nosso nome.
Existem algumas possibilidades genuinamente interessantes nisso, particularmente em torno do trabalho de coordenação que tem resistido à automação convencional. O próprio NIST descreve o potencial para os agentes melhorarem a produtividade, a eficiência e a tomada de decisões, ao mesmo tempo que realça a necessidade de controlos adequados de identificação e autorização quando esses agentes têm acesso a dados, ferramentas e aplicações organizacionais.
Penso que essa combinação é importante. A oportunidade e o risco advêm da mesma característica: o agente tem alguma liberdade para decidir como o trabalho é feito.
Assim que isso acontece, a arquitetura já não se preocupa apenas em saber se um sistema se pode ligar a outro. Determina cada vez mais qual o interveniente autónomo que pode utilizar que informação, exercer que capacidade, sob a autoridade de quem, com que limites e com que provas deixadas para trás.
Na prática, é improvável que a governação de agentes de IA empresariais seja resolvida por mais um documento de política guardado algures na intranet. Tem de se manifestar nas identidades que criamos, nas permissões que concedemos, nos controlos em torno de ações consequentes, na qualidade e proveniência dos dados que os agentes consomem, nos caminhos de escalamento que desenhamos e nas provas de auditoria que retemos depois.
A Hugging Face dá-nos um exemplo extremo de software autónomo a encontrar uma rota que os seus operadores não esperavam. A PocketOS dá-nos um exemplo muito mais quotidiano do que acontece quando um agente tem simplesmente mais autoridade do que a tarefa exige. O trabalho emergente em torno da identidade do agente, privilégio mínimo, interação segura entre múltiplos agentes e descoberta de recursos confiáveis mostra que o modelo de controlo circundante já está a ter de recuperar o atraso em relação à capacidade.
Nada disso é um argumento contra a IA baseada em agentes. Muito pelo contrário. Se os agentes puderem remover alguma da coordenação humana que torna as empresas digitais modernas dispendiosas e complicadas de operar, há uma razão muito tangível para os perseguir.
Mas introduzir intervenientes autónomos num parque digital existente não é simplesmente mais uma implementação de IA. Altera os pressupostos sobre identidade, confiança, dados, responsabilidade e, em última análise, autoridade.
Por isso, antes de perguntar o que um agente pode fazer, eu começaria com uma pergunta diferente.
O que está realmente disposto a deixar que ele faça?
Quando a IA ganha autoridade
Nos últimos anos, as empresas têm-se concentrado no que a IA generativa nos pode dizer. Os agentes de IA introduzem uma questão bastante mais consequente: o que acontece quando o software pode decidir o que fazer a seguir e, depois, fazê-lo realmente?
Em julho de 2026, um agente de IA que estava a ser utilizado como parte de uma avaliação de cibersegurança da OpenAI comprometeu parte da infraestrutura de produção da Hugging Face. Há um contexto importante aqui antes de nos deixarmos levar. Esta não foi uma aplicação de negócios normal que de repente decidiu atacar outra empresa. A OpenAI estava deliberadamente a testar modelos altamente capazes contra tarefas de cibersegurança difíceis, e os classificadores de produção normalmente utilizados para impedir que os modelos prosseguissem atividades cibernéticas de alto risco foram intencionalmente desativados para a avaliação.
Mesmo assim, vale a pena prestar atenção ao que aconteceu. De acordo com as investigações subsequentes, o agente parece ter concluído que a informação detida pela Hugging Face poderia ajudá-lo a concluir o teste de referência que lhe tinha sido atribuído. Encontrou uma saída através de uma vulnerabilidade de dia zero na infraestrutura utilizada pelo ambiente de avaliação, obteve um acesso mais amplo à Internet, encadeou outros caminhos de ataque, obteve credenciais e acabou por chegar aos sistemas da Hugging Face. A reconstrução forense da Hugging Face cobriu cerca de 17.600 ações individuais, agrupadas em aproximadamente 6.280 clusters.
A tentação, naturalmente, é recorrer à manchete "A IA escapou" ou "A IA rebelou-se". Não tenho a certeza de que qualquer uma das duas seja particularmente útil. Tanto quanto as investigações conseguiram estabelecer, o software estava a tentar atingir o objetivo que lhe tinha sido dado e encontrou uma rota que ninguém esperava que seguisse. A Hugging Face acredita que o agente estava efetivamente a tentar fazer batota na avaliação ao aceder a sistemas de produção onde pensava que a informação do teste de referência ou as soluções poderiam estar disponíveis.
Isso é consideravelmente menos teatral, mas, do ponto de vista da transformação digital, provavelmente mais importante.
Nos últimos anos, a maioria das organizações tem experienciado a IA generativa como algo a quem fazem perguntas. Dá-se-lhe alguma informação, faz-se uma pergunta e obtém-se algo de volta. Pode resumir um contrato, analisar alguns dados, escrever algum código ou redigir um e-mail, mas geralmente ainda há uma pessoa sentada do outro lado a decidir o que acontece a seguir.
Os agentes começam a esbater essa fronteira. Dê a essa mesma inteligência acesso a ferramentas e ela poderá recuperar informação, chamar uma API, atualizar um registo, executar algum código, enviar o e-mail ou fazer a alteração ela mesma. A OpenAI descreve os agentes de forma muito semelhante: sistemas que podem gerir de forma independente a execução do fluxo de trabalho, tomar decisões, selecionar ferramentas apropriadas e interagir com sistemas externos em nome do utilizador.
O chatbot acabou de obter acesso de escrita.
Essa mudança é a razão pela qual a governação de agentes de IA se está a tornar uma preocupação empresarial prática, em vez de ser simplesmente mais uma discussão de políticas. Assim que o software pode tomar medidas em vez de fazer recomendações, as questões sobre identidade, permissões, controlos, auditabilidade e responsabilidade movem-se para a própria arquitetura.
A automação muda quando é dada intenção ao software, não instruções
O software tem vindo a mudar as coisas há décadas, por isso existe o perigo de vender em demasia o que há de novo aqui. Não precisamos de IA para atualizar uma base de dados, acionar uma API ou executar um fluxo de trabalho. Scripts, motores de regras, plataformas de orquestração e processos automatizados têm feito esses trabalhos perfeitamente bem há anos.
A diferença está em como passamos do objetivo para a ação. A automação tradicional é normalmente desenhada em torno de uma rota que alguém descreveu antecipadamente. Quando X acontece, recupera Y. Se a resposta for Z, executa esta ação. Podem estar envolvidas centenas de regras, ramificações e exceções, mas alguém tentou modelar o processo previamente.
Os agentes potencialmente permitem-nos avançar mais no sentido de dar ao software um resultado, em vez de cada instrução necessária para o alcançar. Aqui está o problema. Descubra de que informação precisa. Decida quais as ferramentas adequadas. Lide com o que vem de volta e faça o trabalho.
Essa distinção é importante porque o caminho de execução se pode tornar dinâmico. Um agente pode começar com um sistema, descobrir que precisa de algum contexto adicional, chamar outra coisa, deparar-se com um resultado que não esperava, rever a sua abordagem e continuar. As arquiteturas de agentes atuais são explicitamente construídas em torno desta capacidade de gerir um fluxo de trabalho, escolher ferramentas e tomar medidas dependendo do estado da tarefa.
Esta é uma proposta materialmente diferente da automação convencional. O software já não está simplesmente a executar um fluxo predeterminado. Dentro de quaisquer limites que estabeleçamos em seu redor, estamos a dar-lhe alguma discricionariedade sobre a forma como esse fluxo se desenrola.
E é aí que isto se torna muito mais interessante do que outra conversa sobre se a IA pode escrever um e-mail melhor.
A oportunidade reside em remover a coordenação, não as pessoas
Uma quantidade surpreendente de trabalho dentro de uma organização não é difícil porque uma tarefa individual seja particularmente complicada. É difícil devido à coordenação necessária entre as tarefas.
Abra o CRM. Encontre o cliente. Copie um identificador para a plataforma de faturação. Leia as notas. Verifique outro sistema. Descubra o que significam. Pergunte a outra equipa se algo é normal. Aguarde pela resposta. Atualize a primeira plataforma e envie um e-mail ao cliente.
Parece-lhe familiar?
Passámos anos a tentar automatizar esses processos, e a tecnologia de fluxo de trabalho convencional é extremamente eficaz quando os passos podem ser descritos de forma previsível. As partes difíceis tendem a ser as exceções: o documento que não está estruturado corretamente, a conta que não coincide bem, três sistemas que discordam entre si, ou o ponto no processo em que alguém precisa de ler algo e compreender o que significa antes de saber o que fazer a seguir.
Esses são precisamente os tipos de fluxos de trabalho onde os agentes potencialmente se tornam úteis. As diretrizes atuais da OpenAI identificam especificamente tomadas de decisão complexas, regras difíceis de manter e uma forte dependência de informação não estruturada como áreas onde uma abordagem baseada em agentes pode oferecer algo que a automação determinística convencional não oferece. Também realça o ponto importante de que, onde essas características estão ausentes, uma solução determinística pode ainda ser a melhor resposta.
Se o software puder assumir parte da coordenação entre sistemas, informações e decisões, há potencialmente um ganho de eficiência significativo. Não porque todos os envolvidos no processo desapareçam de repente, mas porque podemos parar de usar pessoas como middleware dispendioso entre plataformas que nunca foram particularmente boas a coordenarem-se entre si.
Há uma distinção importante aí. O objetivo não deve necessariamente ser remover as pessoas da organização. Deve ser remover o trabalho que atualmente obrigamos as pessoas a fazer simplesmente porque a tecnologia por baixo delas não consegue lidar muito bem com o contexto, a ambiguidade ou as exceções.
É por isso que penso que a oportunidade em torno dos agentes é muito mais significativa do que a produtividade incremental. Redigir uma resposta ao cliente dez segundos mais rápido é útil. Permitir que o software investigue o problema, concilie a informação relevante e leve o processo por diante é algo inteiramente diferente.
Claro que, quanto mais longe ele levar o processo, mais perto acaba por ficar de uma ação com consequências.
And that is where things become rather more complicated.
Capacidade não é autoridade
Poucos meses antes do incidente da Hugging Face, a PocketOS publicou um relato sincero de um agente de IA que apagou a base de dados de produção da empresa. A eliminação demorou nove segundos. A recuperação demorou sessenta horas. As suas cópias de segurança existiam, mas estavam com três meses de atraso porque o processo de cópia de segurança tinha deixado de funcionar silenciosamente.
A PocketOS também é muito clara ao afirmar que isto não foi simplesmente um "problema de IA". A empresa afirma que o agente agiu com confiança utilizando permissões que nunca deveria ter tido, contra um ambiente que não tinha fricção suficiente em torno da ação destrutiva.
Essa é a lição útil.
Os humanos têm vindo a apagar bases de dados de produção há anos, e os erros de software também deram uma contribuição respeitável. A parte interessante é que o interveniente tinha autoridade suficiente para que o seu erro importasse.
Nós já compreendemos isto quando o interveniente é humano. Alguém no atendimento ao cliente pode estar autorizado a emitir um reembolso de 20 £ sem que ninguém se importe muito. 200 £ podem ainda ser inteiramente razoáveis. 20.000 £ provavelmente introduzem outra conversa.
O mesmo se aplica a outros contextos. Um agente identificar um erro ortográfico em alguns metadados de conteúdo e corrigi-lo é provavelmente algo bastante inofensivo. Se o campo que ele quer alterar determinar se esse conteúdo pode ser distribuído num território específico, a consequência é muito diferente. Da mesma forma, um agente pode identificar corretamente um problema de configuração de produção, mas isso não significa que deva herdar direitos ilimitados para reconfigurar todo o ambiente.
Nada disto é particularmente exótico. Trata-se de gestão de identidades e acessos aplicada a um novo tipo de interveniente, e suspeito que se tornará um dos alicerces de uma governação de IA baseada em agentes eficaz.
A Microsoft já está a tratar os agentes nestes termos. As suas diretrizes atuais recomendam uma identidade de agente de IA única e dedicada, um proprietário ou patrocinador nomeado, propósito e acesso a dados claramente documentados, acesso com privilégios mínimos, permissões de ferramentas controladas, registo de logs e caminhos de revogação testados. O trabalho do NIST na mesma área está explicitamente a examinar a identificação, autorização, auditoria e o não repúdio para agentes de IA.
Em termos práticos, isso significa que as permissões de agentes de IA precisam de ser tratadas com a mesma seriedade que as contas de utilizadores humanos e de serviços privilegiadas. Um agente pode ser perfeitamente capaz de determinar o que pensa que deve acontecer sem ter o direito de fazer com que isso aconteça.
Essa distinção é importante. Os controlos de agentes de IA não podem simplesmente questionar se um modelo é tecnicamente capaz de realizar uma ação. Precisam de determinar se este agente específico, agindo neste contexto específico, está autorizado a realizá-la.
Como nota lateral, suspeito que a proliferação de agentes de IA se tornará um daqueles problemas que as organizações não pensam que têm até que alguém finalmente pergunte: "Quantos agentes temos realmente?" Já passámos por variações disto com aplicações SaaS, recursos na nuvem, contas de serviço e chaves de API. Não há nenhuma razão óbvia para que o parque de agentes se organize melhor, particularmente em empresas onde a experimentação é deliberadamente descentralizada pelas equipas.
Isso não significa centralizar todas as iniciativas de IA. É improvável que uma equipa central compreenda cada processo suficientemente bem para identificar todas as aplicações úteis por si mesma. A inovação descentralizada pode ser inteiramente sensata.
Autoridade descentralizada por acidente é uma questão diferente.
A IA baseada em agentes herda todos os compromissos do seu parque digital
Há outra questão incómoda por baixo de tudo isto. O seu agente vai herdar o seu parque digital existente.
As APIs brilhantes, os sistemas legados, os registos de clientes inconsistentes, a integração que alguém escreveu há oito anos e em que ninguém quer mexer, e a plataforma que chama uma coisa a um cliente enquanto outra plataforma lhe chama outra coisa. Uma empresa cresce, as plataformas são compradas, as equipas resolvem problemas individuais, ocorrem aquisições, os fornecedores mudam e as prioridades movem-se. Eventualmente, acaba por ter aquilo a que todos se referem educadamente como a arquitetura atual.
Agora imagine um agente a lidar com um cliente que pagou por um serviço mas não consegue aceder ao mesmo. A resposta pode exigir informações dos sistemas de CRM, faturação, autenticação, direitos e suporte antes que alguém possa determinar o que realmente aconteceu.
Um operador humano lida muitas vezes com as inconsistências quase sem pensar nelas. Sabe que um sistema atualiza antes de outro. Repara que os identificadores são ligeiramente diferentes. Talvez se lembre de que os clientes de um pacote antigo se comportam de forma diferente, ou simplesmente pergunta à pessoa sentada ao seu lado porque a documentação não é atualizada desde 2023.
Dê o trabalho a um agente e esses pressupostos precisam de existir em algum lugar. Qual é o sistema que dita as regras? O que acontece se a faturação disser que o pagamento foi bem-sucedido mas a plataforma de direitos disser que a conta está inativa? A informação está errada ou existe uma regra de negócio que o agente não compreende? Uma plataforma está simplesmente cinco minutos atrasada?
Estes são problemas antigos de dados e arquitetura com um novo consumidor. A diferença material é que o consumidor pode agora tomar medidas com base em qualquer conclusão a que chegue.
Dados fracos a alimentar um chatbot podem produzir uma resposta má. Dados fracos a alimentar software autónomo podem produzir um resultado mau.
Há também outra complicação. A informação não tem necessariamente de estar errada por acidente. Uma investigação publicada em julho demonstrou ataques de injeção de dados em agentes, nos quais a informação controlada por um atacante podia ser apresentada como dados contextuais aparentemente legítimos e influenciar o que um agente fazia subsequentemente. Os investigadores identificaram vulnerabilidades em agentes reais da web e de codificação que podiam resultar em cliques não intencionais, execução remota de código e ações na cadeia de abastecimento de software.
Isso cria um cruzamento desconfortável entre a arquitetura de dados e a segurança. Se a informação pode influenciar a ação, a origem dessa informação, se ela pode ser confiável e quanto peso o agente lhe deve dar já não são preocupações abstratas de governação. Tornam-se parte do modelo de execução.
É também por isso que teria cuidado com a ideia de que os agentes de alguma forma tornam a dívida técnica menos importante. Um agente pode tornar ambientes fragmentados mais fáceis de navegar porque pode raciocinar sobre uma tarefa em vez de depender inteiramente de um caminho de integração fixo, mas ainda precisa de acesso a sistemas, interfaces utilizáveis, dados significativos, permissões apropriadas e alguma ideia do que fazer quando algo falha a meio do caminho.
Se a API não existir, o agente precisa de outra forma de entrar. Se o mesmo cliente tiver seis identificadores, alguém ou algo ainda precisa de estabelecer se representam a mesma pessoa. Se uma regra de negócio não documentada for importante para a decisão, esse conhecimento precisa de estar disponível em algum lugar.
Colocar uma camada de orquestração inteligente à frente de um parque desorganizado não faz com que o parque deixe de ser desorganizado. Pode tornar a desorganização mais fácil de navegar. Pode também permitir que as consequências dessa desorganização se propaguem consideravelmente mais rápido.
A supervisão humana tem um custo económico
Neste ponto da maioria das conversas, alguém dirá que haverá sempre um humano no processo.
Isso parece reconfortante, mas levanta uma questão óbvia: se alguém ainda precisa de rever e aprovar tudo o que o agente faz, quanto é que realmente automatizámos?
Imagine que o nosso agente de apoio ao cliente verificou cinco sistemas, identificou um problema na conta, estabeleceu que o cliente foi cobrado incorretamente e calculou que um reembolso de 20 £ é adequado. Em seguida, coloca tudo numa fila para que alguém clique em "Aprovar".
Pode ainda haver uma poupança significativa porque a investigação foi automatizada, mas execute esse processo em dezenas de milhares de transações e terá mantido uma operação manual de dimensão considerável. O estrangulamento mudou de lugar em vez de desaparecer.
É aqui que alguma da linguagem mais segura em torno da IA baseada em agentes começa a entrar em conflito com a economia da automação. Introduzimos a autonomia porque queremos que o software remova o trabalho de um processo, e depois ficamos suficientemente nervosos com a autonomia ao ponto de colocar uma pessoa de volta em cada transação.
Eventualmente, isso acaba por anular o objetivo.
O desafio com a supervisão de agentes de IA é, portanto, que mais supervisão não é automaticamente melhor. Cada etapa de aprovação pode reduzir um tipo específico de risco, mas também reintroduz custo, latência e esforço manual no processo. A melhor questão é onde o julgamento humano acrescenta genuinamente valor.
Se o reembolso for de 20 £, as regras forem claras, todos os sistemas relevantes concordarem e a ação puder ser facilmente revertida, talvez ninguém precise de a aprovar. Se o valor for de 20.000 £, dois sistemas discordarem ou a situação ficar fora dos parâmetros normais, esse parece ser um excelente momento para envolver alguém.
Para muitos processos, o destino útil não é, portanto, o humano no processo, mas sim o humano por exceção. O trabalho rotineiro e bem compreendido torna-se cada vez mais autónomo, enquanto os casos invulgares, ambíguos ou de elevadas consequências são escalados.
Isso ainda deixa muito espaço para introduzir a autonomia gradualmente. Um agente pode começar por observar e recomendar. Assim que o seu comportamento for compreendido, pode preparar ações para aprovação. Eventualmente, classes específicas de ações rotineiras e reversíveis podem ser executadas automaticamente, com as pessoas a envolverem-se quando o processo ultrapassa um limite acordado.
As diretrizes da OpenAI adotam uma abordagem semelhante baseada no risco. Recomendam a intervenção humana quando os agentes excedem limites de falha definidos e em torno de ações que são sensíveis, irreversíveis ou de alto risco, tais como reembolsos ou pagamentos avultados.
A PocketOS chegou ao mesmo problema a partir de uma direção consideravelmente menos teórica. Após o incidente com a sua base de dados, as operações destrutivas requerem agora confirmação humana explícita. Tem de haver um botão físico carregado por uma pessoa real para confirmar a ação. A empresa não respondeu abandonando os agentes autónomos. Afirma que continua a executar uma série de agentes autónomos específicos em produção, alterando simultaneamente onde se situa a fronteira de controlo.
Essa parece-me ser a forma mais útil de pensar sobre a supervisão humana. É um controlo que deve ser aplicado onde a consequência o justifica, não necessariamente um modelo operacional permanente para cada ação executada por software autónomo.
O objetivo da automação é, afinal de contas, automatizar. O problema de design é decidir onde as pessoas melhoram genuinamente o resultado e onde estão simplesmente a ser mantidas porque ainda não confiamos no sistema o suficiente para as remover.
Autonomia sem rastreabilidade é operacionalmente indefensável
Se avançarmos para os humanos por exceção, outra coisa torna-se mais importante e não menos: compreender o que o agente realmente fez.
A investigação da Hugging Face é um exemplo extremo útil. A sua reconstrução forense cobriu cerca de 17.600 ações em milhares de clusters, com os investigadores a juntarem as peças de como o agente se moveu pelos sistemas e adaptou o seu comportamento ao longo do tempo.
Traga isso para um processo de negócio normal. Um cliente diz que algo foi alterado incorretamente na sua conta e descobre que um agente fez a alteração.
"A IA fez isso" é improvável que o leve muito longe na revisão do incidente.
Irá querer saber qual o agente que agiu, quem iniciou a tarefa, que informação utilizou, o que essa informação continha na altura, que ferramentas chamou e que permissão permitiu, em última análise, a alteração. Se outro agente se envolveu pelo caminho, isso provavelmente também importa.
É aqui que a auditabilidade de agentes de IA deixa de ser uma cortesia de governação e se torna um requisito operacional. Quanto menos envolvimento humano direto houver na execução, mais forte precisa de se tornar a observabilidade circundante.
As diretrizes atuais da Microsoft recomendam o registo da identidade do agente, da sua função e âmbito efetivo, da ação realizada, do recurso afetado e de qualquer utilizador em nome do qual estivesse a agir. O NIST está, de igual modo, a considerar explicitamente a auditoria e o não repúdio como parte do problema de identidade e autorização para agentes.
Isso não significa que cada ação autónoma precise de ter alguém a observá-la. Já operamos ambientes automatizados enormes sem colocar uma pessoa em frente de cada transação, evento de infraestrutura ou pedido de rede. Estabelecemos limites, controlos e monitorização e, em seguida, investigamos as coisas que ficam fora deles.
Não há nenhuma razão óbvia para que sistemas baseados em agentes maduros funcionem de forma diferente.
A autonomia não remove a supervisão. Altera o momento em que a supervisão acontece.
A intenção delegada complica a fronteira de confiança
Há mais um desenvolvimento que vale a pena observar porque torna este problema ainda mais interessante.
Os agentes estão a ser cada vez mais desenhados para comunicar e colaborar com outros agentes. O protocolo Agent2Agent da Google padroniza a forma como os agentes se podem descobrir e comunicar entre si, incluindo agentes construídos por diferentes equipas e em diferentes pilhas tecnológicas. O seu trabalho mais recente de Descoberta de Recursos de Agentes aborda a questão relacionada de como os agentes podem encontrar e verificar ferramentas, competências e outros agentes distribuídos por equipas, organizações e plataformas.
Imagine que um agente interno recebe uma tarefa e determina que outro agente especialista pode executar parte dela. Esse segundo agente utiliza uma ferramenta que chama um dos seus serviços e, em última análise, altera algo.
Quem está a agir?
O segundo agente? O primeiro agente? A pessoa que iniciou a tarefa original?
Se o primeiro agente estiver autorizado a realizar uma ação, pode delegar essa autoridade? O segundo agente recebe-a na totalidade, em parte ou de todo? O que acontece se os agentes pertencerem a organizações diferentes?
Estas são questões emergentes e seria prematuro fingir que a indústria chegou a acordo sobre todas as respostas. A Iniciativa de Padrões de Agentes de IA do NIST está a realizar explicitamente trabalhos em torno da autenticação de agentes e da infraestrutura de identidade para apoiar interações seguras entre humanos e agentes e entre múltiplos agentes.
Mas a direção importa. Historicamente, a confiança tem sido frequentemente associada a um utilizador, aplicação ou integração conhecidos. Assim que os agentes puderem descobrir capacidades dinamicamente e delegar partes de um objetivo para outro local, a confiança e a autoridade precisam de sobreviver à viagem.
A tarefa pode ser dinâmica. A responsabilidade não pode desaparecer sempre que cruza outra fronteira.
A transformação baseada em agentes deve começar com a delegação, não com a tecnologia
Há um padrão com mudanças tecnológicas significativas que a maioria das pessoas envolvidas na transformação reconhecerá. Algo torna-se estrategicamente importante, alguém decide que a organização precisa disso e todos começam a procurar um lugar onde colocar esse algo.
Precisamos de uma estratégia de IA. Precisamos de alguns casos de utilização de agentes. Devemos realizar um workshop. Que processos podemos tornar baseados em agentes?
Eu provavelmente abordaria a questão ao contrário.
Comece com o processo que irrita toda a gente. Aquele que é lento, dispendioso, fragmentado ou que depende de alguém a transferir informação entre sistemas o dia todo. Compreenda onde as decisões são tomadas, em que informações essas decisões se apoiam, que sistemas estão envolvidos, onde ocorrem as exceções complicadas e o que acontece quando algo corre mal.
Depois, olhe para o que as pessoas no processo estão realmente a fazer. Estão a exercer um julgamento valioso ou estão a compensar limitações na tecnologia que as rodeia? Estão a aprovar algo porque existe um risco financeiro ou operacional real, ou porque o fluxo de trabalho não consegue distinguir um caso rotineiro de um invulgar? Estão a conciliar manualmente a informação porque a organização precisa genuinamente da sua experiência ou porque dois sistemas utilizam identificadores diferentes?
Esses são problemas bastante diferentes.
Assim que compreender isso, decida o que está disposto a delegar. Que decisões pode o software tomar? Que ações pode realizar? Quais são reversíveis? Onde precisa de escalamento? Que autoridade exige? De que provas necessitaria mais tarde se alguém perguntasse por que razão uma decisão foi tomada?
Só então a escolha da tecnologia se torna particularmente interessante.
Um agente pode ser uma excelente resposta. Pode não ser. Não há problema. As diretrizes atuais sobre o design de agentes fazem uma distinção muito semelhante: os agentes são adequados para fluxos de trabalho onde a ambiguidade, as decisões complexas ou os dados não estruturados fazem com que as abordagens determinísticas tenham dificuldades, mas onde essas características estão ausentes, a automação convencional pode continuar a ser inteiramente suficiente.
O objetivo não é implementar agentes. É melhorar o negócio.
A arquitetura da automação está a tornar-se a arquitetura da autoridade
Nos últimos vinte anos, a transformação digital envolveu em grande parte a ligação de pessoas a sistemas e de sistemas entre si. Estamos agora a começar a introduzir outro participante nesse parque: software que pode receber um objetivo, determinar como persegui-lo e utilizar esses sistemas em nosso nome.
Existem algumas possibilidades genuinamente interessantes nisso, particularmente em torno do trabalho de coordenação que tem resistido à automação convencional. O próprio NIST descreve o potencial para os agentes melhorarem a produtividade, a eficiência e a tomada de decisões, ao mesmo tempo que realça a necessidade de controlos adequados de identificação e autorização quando esses agentes têm acesso a dados, ferramentas e aplicações organizacionais.
Penso que essa combinação é importante. A oportunidade e o risco advêm da mesma característica: o agente tem alguma liberdade para decidir como o trabalho é feito.
Assim que isso acontece, a arquitetura já não se preocupa apenas em saber se um sistema se pode ligar a outro. Determina cada vez mais qual o interveniente autónomo que pode utilizar que informação, exercer que capacidade, sob a autoridade de quem, com que limites e com que provas deixadas para trás.
Na prática, é improvável que a governação de agentes de IA empresariais seja resolvida por mais um documento de política guardado algures na intranet. Tem de se manifestar nas identidades que criamos, nas permissões que concedemos, nos controlos em torno de ações consequentes, na qualidade e proveniência dos dados que os agentes consomem, nos caminhos de escalamento que desenhamos e nas provas de auditoria que retemos depois.
A Hugging Face dá-nos um exemplo extremo de software autónomo a encontrar uma rota que os seus operadores não esperavam. A PocketOS dá-nos um exemplo muito mais quotidiano do que acontece quando um agente tem simplesmente mais autoridade do que a tarefa exige. O trabalho emergente em torno da identidade do agente, privilégio mínimo, interação segura entre múltiplos agentes e descoberta de recursos confiáveis mostra que o modelo de controlo circundante já está a ter de recuperar o atraso em relação à capacidade.
Nada disso é um argumento contra a IA baseada em agentes. Muito pelo contrário. Se os agentes puderem remover alguma da coordenação humana que torna as empresas digitais modernas dispendiosas e complicadas de operar, há uma razão muito tangível para os perseguir.
Mas introduzir intervenientes autónomos num parque digital existente não é simplesmente mais uma implementação de IA. Altera os pressupostos sobre identidade, confiança, dados, responsabilidade e, em última análise, autoridade.
Por isso, antes de perguntar o que um agente pode fazer, eu começaria com uma pergunta diferente.
O que está realmente disposto a deixar que ele faça?
Quando a IA ganha autoridade
Nos últimos anos, as empresas têm-se concentrado no que a IA generativa nos pode dizer. Os agentes de IA introduzem uma questão bastante mais consequente: o que acontece quando o software pode decidir o que fazer a seguir e, depois, fazê-lo realmente?
Em julho de 2026, um agente de IA que estava a ser utilizado como parte de uma avaliação de cibersegurança da OpenAI comprometeu parte da infraestrutura de produção da Hugging Face. Há um contexto importante aqui antes de nos deixarmos levar. Esta não foi uma aplicação de negócios normal que de repente decidiu atacar outra empresa. A OpenAI estava deliberadamente a testar modelos altamente capazes contra tarefas de cibersegurança difíceis, e os classificadores de produção normalmente utilizados para impedir que os modelos prosseguissem atividades cibernéticas de alto risco foram intencionalmente desativados para a avaliação.
Mesmo assim, vale a pena prestar atenção ao que aconteceu. De acordo com as investigações subsequentes, o agente parece ter concluído que a informação detida pela Hugging Face poderia ajudá-lo a concluir o teste de referência que lhe tinha sido atribuído. Encontrou uma saída através de uma vulnerabilidade de dia zero na infraestrutura utilizada pelo ambiente de avaliação, obteve um acesso mais amplo à Internet, encadeou outros caminhos de ataque, obteve credenciais e acabou por chegar aos sistemas da Hugging Face. A reconstrução forense da Hugging Face cobriu cerca de 17.600 ações individuais, agrupadas em aproximadamente 6.280 clusters.
A tentação, naturalmente, é recorrer à manchete "A IA escapou" ou "A IA rebelou-se". Não tenho a certeza de que qualquer uma das duas seja particularmente útil. Tanto quanto as investigações conseguiram estabelecer, o software estava a tentar atingir o objetivo que lhe tinha sido dado e encontrou uma rota que ninguém esperava que seguisse. A Hugging Face acredita que o agente estava efetivamente a tentar fazer batota na avaliação ao aceder a sistemas de produção onde pensava que a informação do teste de referência ou as soluções poderiam estar disponíveis.
Isso é consideravelmente menos teatral, mas, do ponto de vista da transformação digital, provavelmente mais importante.
Nos últimos anos, a maioria das organizações tem experienciado a IA generativa como algo a quem fazem perguntas. Dá-se-lhe alguma informação, faz-se uma pergunta e obtém-se algo de volta. Pode resumir um contrato, analisar alguns dados, escrever algum código ou redigir um e-mail, mas geralmente ainda há uma pessoa sentada do outro lado a decidir o que acontece a seguir.
Os agentes começam a esbater essa fronteira. Dê a essa mesma inteligência acesso a ferramentas e ela poderá recuperar informação, chamar uma API, atualizar um registo, executar algum código, enviar o e-mail ou fazer a alteração ela mesma. A OpenAI descreve os agentes de forma muito semelhante: sistemas que podem gerir de forma independente a execução do fluxo de trabalho, tomar decisões, selecionar ferramentas apropriadas e interagir com sistemas externos em nome do utilizador.
O chatbot acabou de obter acesso de escrita.
Essa mudança é a razão pela qual a governação de agentes de IA se está a tornar uma preocupação empresarial prática, em vez de ser simplesmente mais uma discussão de políticas. Assim que o software pode tomar medidas em vez de fazer recomendações, as questões sobre identidade, permissões, controlos, auditabilidade e responsabilidade movem-se para a própria arquitetura.
A automação muda quando é dada intenção ao software, não instruções
O software tem vindo a mudar as coisas há décadas, por isso existe o perigo de vender em demasia o que há de novo aqui. Não precisamos de IA para atualizar uma base de dados, acionar uma API ou executar um fluxo de trabalho. Scripts, motores de regras, plataformas de orquestração e processos automatizados têm feito esses trabalhos perfeitamente bem há anos.
A diferença está em como passamos do objetivo para a ação. A automação tradicional é normalmente desenhada em torno de uma rota que alguém descreveu antecipadamente. Quando X acontece, recupera Y. Se a resposta for Z, executa esta ação. Podem estar envolvidas centenas de regras, ramificações e exceções, mas alguém tentou modelar o processo previamente.
Os agentes potencialmente permitem-nos avançar mais no sentido de dar ao software um resultado, em vez de cada instrução necessária para o alcançar. Aqui está o problema. Descubra de que informação precisa. Decida quais as ferramentas adequadas. Lide com o que vem de volta e faça o trabalho.
Essa distinção é importante porque o caminho de execução se pode tornar dinâmico. Um agente pode começar com um sistema, descobrir que precisa de algum contexto adicional, chamar outra coisa, deparar-se com um resultado que não esperava, rever a sua abordagem e continuar. As arquiteturas de agentes atuais são explicitamente construídas em torno desta capacidade de gerir um fluxo de trabalho, escolher ferramentas e tomar medidas dependendo do estado da tarefa.
Esta é uma proposta materialmente diferente da automação convencional. O software já não está simplesmente a executar um fluxo predeterminado. Dentro de quaisquer limites que estabeleçamos em seu redor, estamos a dar-lhe alguma discricionariedade sobre a forma como esse fluxo se desenrola.
E é aí que isto se torna muito mais interessante do que outra conversa sobre se a IA pode escrever um e-mail melhor.
A oportunidade reside em remover a coordenação, não as pessoas
Uma quantidade surpreendente de trabalho dentro de uma organização não é difícil porque uma tarefa individual seja particularmente complicada. É difícil devido à coordenação necessária entre as tarefas.
Abra o CRM. Encontre o cliente. Copie um identificador para a plataforma de faturação. Leia as notas. Verifique outro sistema. Descubra o que significam. Pergunte a outra equipa se algo é normal. Aguarde pela resposta. Atualize a primeira plataforma e envie um e-mail ao cliente.
Parece-lhe familiar?
Passámos anos a tentar automatizar esses processos, e a tecnologia de fluxo de trabalho convencional é extremamente eficaz quando os passos podem ser descritos de forma previsível. As partes difíceis tendem a ser as exceções: o documento que não está estruturado corretamente, a conta que não coincide bem, três sistemas que discordam entre si, ou o ponto no processo em que alguém precisa de ler algo e compreender o que significa antes de saber o que fazer a seguir.
Esses são precisamente os tipos de fluxos de trabalho onde os agentes potencialmente se tornam úteis. As diretrizes atuais da OpenAI identificam especificamente tomadas de decisão complexas, regras difíceis de manter e uma forte dependência de informação não estruturada como áreas onde uma abordagem baseada em agentes pode oferecer algo que a automação determinística convencional não oferece. Também realça o ponto importante de que, onde essas características estão ausentes, uma solução determinística pode ainda ser a melhor resposta.
Se o software puder assumir parte da coordenação entre sistemas, informações e decisões, há potencialmente um ganho de eficiência significativo. Não porque todos os envolvidos no processo desapareçam de repente, mas porque podemos parar de usar pessoas como middleware dispendioso entre plataformas que nunca foram particularmente boas a coordenarem-se entre si.
Há uma distinção importante aí. O objetivo não deve necessariamente ser remover as pessoas da organização. Deve ser remover o trabalho que atualmente obrigamos as pessoas a fazer simplesmente porque a tecnologia por baixo delas não consegue lidar muito bem com o contexto, a ambiguidade ou as exceções.
É por isso que penso que a oportunidade em torno dos agentes é muito mais significativa do que a produtividade incremental. Redigir uma resposta ao cliente dez segundos mais rápido é útil. Permitir que o software investigue o problema, concilie a informação relevante e leve o processo por diante é algo inteiramente diferente.
Claro que, quanto mais longe ele levar o processo, mais perto acaba por ficar de uma ação com consequências.
And that is where things become rather more complicated.
Capacidade não é autoridade
Poucos meses antes do incidente da Hugging Face, a PocketOS publicou um relato sincero de um agente de IA que apagou a base de dados de produção da empresa. A eliminação demorou nove segundos. A recuperação demorou sessenta horas. As suas cópias de segurança existiam, mas estavam com três meses de atraso porque o processo de cópia de segurança tinha deixado de funcionar silenciosamente.
A PocketOS também é muito clara ao afirmar que isto não foi simplesmente um "problema de IA". A empresa afirma que o agente agiu com confiança utilizando permissões que nunca deveria ter tido, contra um ambiente que não tinha fricção suficiente em torno da ação destrutiva.
Essa é a lição útil.
Os humanos têm vindo a apagar bases de dados de produção há anos, e os erros de software também deram uma contribuição respeitável. A parte interessante é que o interveniente tinha autoridade suficiente para que o seu erro importasse.
Nós já compreendemos isto quando o interveniente é humano. Alguém no atendimento ao cliente pode estar autorizado a emitir um reembolso de 20 £ sem que ninguém se importe muito. 200 £ podem ainda ser inteiramente razoáveis. 20.000 £ provavelmente introduzem outra conversa.
O mesmo se aplica a outros contextos. Um agente identificar um erro ortográfico em alguns metadados de conteúdo e corrigi-lo é provavelmente algo bastante inofensivo. Se o campo que ele quer alterar determinar se esse conteúdo pode ser distribuído num território específico, a consequência é muito diferente. Da mesma forma, um agente pode identificar corretamente um problema de configuração de produção, mas isso não significa que deva herdar direitos ilimitados para reconfigurar todo o ambiente.
Nada disto é particularmente exótico. Trata-se de gestão de identidades e acessos aplicada a um novo tipo de interveniente, e suspeito que se tornará um dos alicerces de uma governação de IA baseada em agentes eficaz.
A Microsoft já está a tratar os agentes nestes termos. As suas diretrizes atuais recomendam uma identidade de agente de IA única e dedicada, um proprietário ou patrocinador nomeado, propósito e acesso a dados claramente documentados, acesso com privilégios mínimos, permissões de ferramentas controladas, registo de logs e caminhos de revogação testados. O trabalho do NIST na mesma área está explicitamente a examinar a identificação, autorização, auditoria e o não repúdio para agentes de IA.
Em termos práticos, isso significa que as permissões de agentes de IA precisam de ser tratadas com a mesma seriedade que as contas de utilizadores humanos e de serviços privilegiadas. Um agente pode ser perfeitamente capaz de determinar o que pensa que deve acontecer sem ter o direito de fazer com que isso aconteça.
Essa distinção é importante. Os controlos de agentes de IA não podem simplesmente questionar se um modelo é tecnicamente capaz de realizar uma ação. Precisam de determinar se este agente específico, agindo neste contexto específico, está autorizado a realizá-la.
Como nota lateral, suspeito que a proliferação de agentes de IA se tornará um daqueles problemas que as organizações não pensam que têm até que alguém finalmente pergunte: "Quantos agentes temos realmente?" Já passámos por variações disto com aplicações SaaS, recursos na nuvem, contas de serviço e chaves de API. Não há nenhuma razão óbvia para que o parque de agentes se organize melhor, particularmente em empresas onde a experimentação é deliberadamente descentralizada pelas equipas.
Isso não significa centralizar todas as iniciativas de IA. É improvável que uma equipa central compreenda cada processo suficientemente bem para identificar todas as aplicações úteis por si mesma. A inovação descentralizada pode ser inteiramente sensata.
Autoridade descentralizada por acidente é uma questão diferente.
A IA baseada em agentes herda todos os compromissos do seu parque digital
Há outra questão incómoda por baixo de tudo isto. O seu agente vai herdar o seu parque digital existente.
As APIs brilhantes, os sistemas legados, os registos de clientes inconsistentes, a integração que alguém escreveu há oito anos e em que ninguém quer mexer, e a plataforma que chama uma coisa a um cliente enquanto outra plataforma lhe chama outra coisa. Uma empresa cresce, as plataformas são compradas, as equipas resolvem problemas individuais, ocorrem aquisições, os fornecedores mudam e as prioridades movem-se. Eventualmente, acaba por ter aquilo a que todos se referem educadamente como a arquitetura atual.
Agora imagine um agente a lidar com um cliente que pagou por um serviço mas não consegue aceder ao mesmo. A resposta pode exigir informações dos sistemas de CRM, faturação, autenticação, direitos e suporte antes que alguém possa determinar o que realmente aconteceu.
Um operador humano lida muitas vezes com as inconsistências quase sem pensar nelas. Sabe que um sistema atualiza antes de outro. Repara que os identificadores são ligeiramente diferentes. Talvez se lembre de que os clientes de um pacote antigo se comportam de forma diferente, ou simplesmente pergunta à pessoa sentada ao seu lado porque a documentação não é atualizada desde 2023.
Dê o trabalho a um agente e esses pressupostos precisam de existir em algum lugar. Qual é o sistema que dita as regras? O que acontece se a faturação disser que o pagamento foi bem-sucedido mas a plataforma de direitos disser que a conta está inativa? A informação está errada ou existe uma regra de negócio que o agente não compreende? Uma plataforma está simplesmente cinco minutos atrasada?
Estes são problemas antigos de dados e arquitetura com um novo consumidor. A diferença material é que o consumidor pode agora tomar medidas com base em qualquer conclusão a que chegue.
Dados fracos a alimentar um chatbot podem produzir uma resposta má. Dados fracos a alimentar software autónomo podem produzir um resultado mau.
Há também outra complicação. A informação não tem necessariamente de estar errada por acidente. Uma investigação publicada em julho demonstrou ataques de injeção de dados em agentes, nos quais a informação controlada por um atacante podia ser apresentada como dados contextuais aparentemente legítimos e influenciar o que um agente fazia subsequentemente. Os investigadores identificaram vulnerabilidades em agentes reais da web e de codificação que podiam resultar em cliques não intencionais, execução remota de código e ações na cadeia de abastecimento de software.
Isso cria um cruzamento desconfortável entre a arquitetura de dados e a segurança. Se a informação pode influenciar a ação, a origem dessa informação, se ela pode ser confiável e quanto peso o agente lhe deve dar já não são preocupações abstratas de governação. Tornam-se parte do modelo de execução.
É também por isso que teria cuidado com a ideia de que os agentes de alguma forma tornam a dívida técnica menos importante. Um agente pode tornar ambientes fragmentados mais fáceis de navegar porque pode raciocinar sobre uma tarefa em vez de depender inteiramente de um caminho de integração fixo, mas ainda precisa de acesso a sistemas, interfaces utilizáveis, dados significativos, permissões apropriadas e alguma ideia do que fazer quando algo falha a meio do caminho.
Se a API não existir, o agente precisa de outra forma de entrar. Se o mesmo cliente tiver seis identificadores, alguém ou algo ainda precisa de estabelecer se representam a mesma pessoa. Se uma regra de negócio não documentada for importante para a decisão, esse conhecimento precisa de estar disponível em algum lugar.
Colocar uma camada de orquestração inteligente à frente de um parque desorganizado não faz com que o parque deixe de ser desorganizado. Pode tornar a desorganização mais fácil de navegar. Pode também permitir que as consequências dessa desorganização se propaguem consideravelmente mais rápido.
A supervisão humana tem um custo económico
Neste ponto da maioria das conversas, alguém dirá que haverá sempre um humano no processo.
Isso parece reconfortante, mas levanta uma questão óbvia: se alguém ainda precisa de rever e aprovar tudo o que o agente faz, quanto é que realmente automatizámos?
Imagine que o nosso agente de apoio ao cliente verificou cinco sistemas, identificou um problema na conta, estabeleceu que o cliente foi cobrado incorretamente e calculou que um reembolso de 20 £ é adequado. Em seguida, coloca tudo numa fila para que alguém clique em "Aprovar".
Pode ainda haver uma poupança significativa porque a investigação foi automatizada, mas execute esse processo em dezenas de milhares de transações e terá mantido uma operação manual de dimensão considerável. O estrangulamento mudou de lugar em vez de desaparecer.
É aqui que alguma da linguagem mais segura em torno da IA baseada em agentes começa a entrar em conflito com a economia da automação. Introduzimos a autonomia porque queremos que o software remova o trabalho de um processo, e depois ficamos suficientemente nervosos com a autonomia ao ponto de colocar uma pessoa de volta em cada transação.
Eventualmente, isso acaba por anular o objetivo.
O desafio com a supervisão de agentes de IA é, portanto, que mais supervisão não é automaticamente melhor. Cada etapa de aprovação pode reduzir um tipo específico de risco, mas também reintroduz custo, latência e esforço manual no processo. A melhor questão é onde o julgamento humano acrescenta genuinamente valor.
Se o reembolso for de 20 £, as regras forem claras, todos os sistemas relevantes concordarem e a ação puder ser facilmente revertida, talvez ninguém precise de a aprovar. Se o valor for de 20.000 £, dois sistemas discordarem ou a situação ficar fora dos parâmetros normais, esse parece ser um excelente momento para envolver alguém.
Para muitos processos, o destino útil não é, portanto, o humano no processo, mas sim o humano por exceção. O trabalho rotineiro e bem compreendido torna-se cada vez mais autónomo, enquanto os casos invulgares, ambíguos ou de elevadas consequências são escalados.
Isso ainda deixa muito espaço para introduzir a autonomia gradualmente. Um agente pode começar por observar e recomendar. Assim que o seu comportamento for compreendido, pode preparar ações para aprovação. Eventualmente, classes específicas de ações rotineiras e reversíveis podem ser executadas automaticamente, com as pessoas a envolverem-se quando o processo ultrapassa um limite acordado.
As diretrizes da OpenAI adotam uma abordagem semelhante baseada no risco. Recomendam a intervenção humana quando os agentes excedem limites de falha definidos e em torno de ações que são sensíveis, irreversíveis ou de alto risco, tais como reembolsos ou pagamentos avultados.
A PocketOS chegou ao mesmo problema a partir de uma direção consideravelmente menos teórica. Após o incidente com a sua base de dados, as operações destrutivas requerem agora confirmação humana explícita. Tem de haver um botão físico carregado por uma pessoa real para confirmar a ação. A empresa não respondeu abandonando os agentes autónomos. Afirma que continua a executar uma série de agentes autónomos específicos em produção, alterando simultaneamente onde se situa a fronteira de controlo.
Essa parece-me ser a forma mais útil de pensar sobre a supervisão humana. É um controlo que deve ser aplicado onde a consequência o justifica, não necessariamente um modelo operacional permanente para cada ação executada por software autónomo.
O objetivo da automação é, afinal de contas, automatizar. O problema de design é decidir onde as pessoas melhoram genuinamente o resultado e onde estão simplesmente a ser mantidas porque ainda não confiamos no sistema o suficiente para as remover.
Autonomia sem rastreabilidade é operacionalmente indefensável
Se avançarmos para os humanos por exceção, outra coisa torna-se mais importante e não menos: compreender o que o agente realmente fez.
A investigação da Hugging Face é um exemplo extremo útil. A sua reconstrução forense cobriu cerca de 17.600 ações em milhares de clusters, com os investigadores a juntarem as peças de como o agente se moveu pelos sistemas e adaptou o seu comportamento ao longo do tempo.
Traga isso para um processo de negócio normal. Um cliente diz que algo foi alterado incorretamente na sua conta e descobre que um agente fez a alteração.
"A IA fez isso" é improvável que o leve muito longe na revisão do incidente.
Irá querer saber qual o agente que agiu, quem iniciou a tarefa, que informação utilizou, o que essa informação continha na altura, que ferramentas chamou e que permissão permitiu, em última análise, a alteração. Se outro agente se envolveu pelo caminho, isso provavelmente também importa.
É aqui que a auditabilidade de agentes de IA deixa de ser uma cortesia de governação e se torna um requisito operacional. Quanto menos envolvimento humano direto houver na execução, mais forte precisa de se tornar a observabilidade circundante.
As diretrizes atuais da Microsoft recomendam o registo da identidade do agente, da sua função e âmbito efetivo, da ação realizada, do recurso afetado e de qualquer utilizador em nome do qual estivesse a agir. O NIST está, de igual modo, a considerar explicitamente a auditoria e o não repúdio como parte do problema de identidade e autorização para agentes.
Isso não significa que cada ação autónoma precise de ter alguém a observá-la. Já operamos ambientes automatizados enormes sem colocar uma pessoa em frente de cada transação, evento de infraestrutura ou pedido de rede. Estabelecemos limites, controlos e monitorização e, em seguida, investigamos as coisas que ficam fora deles.
Não há nenhuma razão óbvia para que sistemas baseados em agentes maduros funcionem de forma diferente.
A autonomia não remove a supervisão. Altera o momento em que a supervisão acontece.
A intenção delegada complica a fronteira de confiança
Há mais um desenvolvimento que vale a pena observar porque torna este problema ainda mais interessante.
Os agentes estão a ser cada vez mais desenhados para comunicar e colaborar com outros agentes. O protocolo Agent2Agent da Google padroniza a forma como os agentes se podem descobrir e comunicar entre si, incluindo agentes construídos por diferentes equipas e em diferentes pilhas tecnológicas. O seu trabalho mais recente de Descoberta de Recursos de Agentes aborda a questão relacionada de como os agentes podem encontrar e verificar ferramentas, competências e outros agentes distribuídos por equipas, organizações e plataformas.
Imagine que um agente interno recebe uma tarefa e determina que outro agente especialista pode executar parte dela. Esse segundo agente utiliza uma ferramenta que chama um dos seus serviços e, em última análise, altera algo.
Quem está a agir?
O segundo agente? O primeiro agente? A pessoa que iniciou a tarefa original?
Se o primeiro agente estiver autorizado a realizar uma ação, pode delegar essa autoridade? O segundo agente recebe-a na totalidade, em parte ou de todo? O que acontece se os agentes pertencerem a organizações diferentes?
Estas são questões emergentes e seria prematuro fingir que a indústria chegou a acordo sobre todas as respostas. A Iniciativa de Padrões de Agentes de IA do NIST está a realizar explicitamente trabalhos em torno da autenticação de agentes e da infraestrutura de identidade para apoiar interações seguras entre humanos e agentes e entre múltiplos agentes.
Mas a direção importa. Historicamente, a confiança tem sido frequentemente associada a um utilizador, aplicação ou integração conhecidos. Assim que os agentes puderem descobrir capacidades dinamicamente e delegar partes de um objetivo para outro local, a confiança e a autoridade precisam de sobreviver à viagem.
A tarefa pode ser dinâmica. A responsabilidade não pode desaparecer sempre que cruza outra fronteira.
A transformação baseada em agentes deve começar com a delegação, não com a tecnologia
Há um padrão com mudanças tecnológicas significativas que a maioria das pessoas envolvidas na transformação reconhecerá. Algo torna-se estrategicamente importante, alguém decide que a organização precisa disso e todos começam a procurar um lugar onde colocar esse algo.
Precisamos de uma estratégia de IA. Precisamos de alguns casos de utilização de agentes. Devemos realizar um workshop. Que processos podemos tornar baseados em agentes?
Eu provavelmente abordaria a questão ao contrário.
Comece com o processo que irrita toda a gente. Aquele que é lento, dispendioso, fragmentado ou que depende de alguém a transferir informação entre sistemas o dia todo. Compreenda onde as decisões são tomadas, em que informações essas decisões se apoiam, que sistemas estão envolvidos, onde ocorrem as exceções complicadas e o que acontece quando algo corre mal.
Depois, olhe para o que as pessoas no processo estão realmente a fazer. Estão a exercer um julgamento valioso ou estão a compensar limitações na tecnologia que as rodeia? Estão a aprovar algo porque existe um risco financeiro ou operacional real, ou porque o fluxo de trabalho não consegue distinguir um caso rotineiro de um invulgar? Estão a conciliar manualmente a informação porque a organização precisa genuinamente da sua experiência ou porque dois sistemas utilizam identificadores diferentes?
Esses são problemas bastante diferentes.
Assim que compreender isso, decida o que está disposto a delegar. Que decisões pode o software tomar? Que ações pode realizar? Quais são reversíveis? Onde precisa de escalamento? Que autoridade exige? De que provas necessitaria mais tarde se alguém perguntasse por que razão uma decisão foi tomada?
Só então a escolha da tecnologia se torna particularmente interessante.
Um agente pode ser uma excelente resposta. Pode não ser. Não há problema. As diretrizes atuais sobre o design de agentes fazem uma distinção muito semelhante: os agentes são adequados para fluxos de trabalho onde a ambiguidade, as decisões complexas ou os dados não estruturados fazem com que as abordagens determinísticas tenham dificuldades, mas onde essas características estão ausentes, a automação convencional pode continuar a ser inteiramente suficiente.
O objetivo não é implementar agentes. É melhorar o negócio.
A arquitetura da automação está a tornar-se a arquitetura da autoridade
Nos últimos vinte anos, a transformação digital envolveu em grande parte a ligação de pessoas a sistemas e de sistemas entre si. Estamos agora a começar a introduzir outro participante nesse parque: software que pode receber um objetivo, determinar como persegui-lo e utilizar esses sistemas em nosso nome.
Existem algumas possibilidades genuinamente interessantes nisso, particularmente em torno do trabalho de coordenação que tem resistido à automação convencional. O próprio NIST descreve o potencial para os agentes melhorarem a produtividade, a eficiência e a tomada de decisões, ao mesmo tempo que realça a necessidade de controlos adequados de identificação e autorização quando esses agentes têm acesso a dados, ferramentas e aplicações organizacionais.
Penso que essa combinação é importante. A oportunidade e o risco advêm da mesma característica: o agente tem alguma liberdade para decidir como o trabalho é feito.
Assim que isso acontece, a arquitetura já não se preocupa apenas em saber se um sistema se pode ligar a outro. Determina cada vez mais qual o interveniente autónomo que pode utilizar que informação, exercer que capacidade, sob a autoridade de quem, com que limites e com que provas deixadas para trás.
Na prática, é improvável que a governação de agentes de IA empresariais seja resolvida por mais um documento de política guardado algures na intranet. Tem de se manifestar nas identidades que criamos, nas permissões que concedemos, nos controlos em torno de ações consequentes, na qualidade e proveniência dos dados que os agentes consomem, nos caminhos de escalamento que desenhamos e nas provas de auditoria que retemos depois.
A Hugging Face dá-nos um exemplo extremo de software autónomo a encontrar uma rota que os seus operadores não esperavam. A PocketOS dá-nos um exemplo muito mais quotidiano do que acontece quando um agente tem simplesmente mais autoridade do que a tarefa exige. O trabalho emergente em torno da identidade do agente, privilégio mínimo, interação segura entre múltiplos agentes e descoberta de recursos confiáveis mostra que o modelo de controlo circundante já está a ter de recuperar o atraso em relação à capacidade.
Nada disso é um argumento contra a IA baseada em agentes. Muito pelo contrário. Se os agentes puderem remover alguma da coordenação humana que torna as empresas digitais modernas dispendiosas e complicadas de operar, há uma razão muito tangível para os perseguir.
Mas introduzir intervenientes autónomos num parque digital existente não é simplesmente mais uma implementação de IA. Altera os pressupostos sobre identidade, confiança, dados, responsabilidade e, em última análise, autoridade.
Por isso, antes de perguntar o que um agente pode fazer, eu começaria com uma pergunta diferente.
O que está realmente disposto a deixar que ele faça?
Se os desafios discutidos aqui lhe parecem familiares, ou se está a pensar em como a IA agêntica se enquadra na sua infraestrutura digital mais ampla, teremos todo o gosto em partilhar ideias. Envie-nos uma mensagem para hello@spicymango.co.uk, ligue-nos ou entre em contacto através do nosso formulário de contacto.
Se os desafios discutidos aqui lhe parecem familiares, ou se está a pensar em como a IA agêntica se enquadra na sua infraestrutura digital mais ampla, teremos todo o gosto em partilhar ideias. Envie-nos uma mensagem para hello@spicymango.co.uk, ligue-nos ou entre em contacto através do nosso formulário de contacto.
Se os desafios discutidos aqui lhe parecem familiares, ou se está a pensar em como a IA agêntica se enquadra na sua infraestrutura digital mais ampla, teremos todo o gosto em partilhar ideias. Envie-nos uma mensagem para hello@spicymango.co.uk, ligue-nos ou entre em contacto através do nosso formulário de contacto.
