Antes de deixar os agentes de IA soltos, é melhor você saber do que eles são capazes

Para as empresas, os sistemas de IA de agência permitem potencialmente que as responsabilidades do pessoal passem da execução para o julgamento, a supervisão e a estratégia. Isto cria novas oportunidades, mas está repleto de riscos:

1. Perda de supervisão e controle humano: os sistemas agênticos podem realizar sequências de ações autônomas, como navegar na web, executar código, chamar APIs e gerenciar arquivos, muitas vezes com pontos de verificação humanos mínimos. Isso cria riscos crescentes: um erro precoce pode causar danos significativos antes que alguém perceba. As empresas podem ter dificuldade em auditar quais as ações que foram tomadas, quando e porquê, dificultando a responsabilização e a remediação.
2. Vulnerabilidades de segurança e injeção imediata: Agentes que consomem dados externos (páginas web, e-mails, documentos) são suscetíveis a ataques de injeção imediata, onde conteúdo malicioso no ambiente sequestra o comportamento do agente. Em um contexto empresarial, um agente comprometido com acesso a sistemas internos, bancos de dados ou APIs pode exfiltrar dados confidenciais, aumentar privilégios ou executar ações destrutivas enquanto parece operar normalmente.
3. Ações imprevisíveis e difíceis de reverter: Ao contrário dos chatbots que apenas geram texto, os sistemas de agente realizam ações no mundo real: enviar e-mails, modificar registros, fazer compras e implantar código. Os erros podem ser difíceis ou impossíveis de desfazer. A combinação de amplo acesso a ferramentas, longos horizontes de tarefas e instruções ambíguas cria cenários nos quais um agente persegue um objetivo de uma forma tecnicamente correta, mas operacionalmente catastrófica.

Além disso, o uso agente pode levar a uma dependência excessiva do julgamento do agente para decisões confidenciais, a riscos de privacidade de dados decorrentes da ingestão de contexto confidencial pelos agentes e ao risco da cadeia de suprimentos de terceiros quando os agentes ligam para serviços externos.

“Um erro precoce pode causar danos significativos antes que alguém perceba. As empresas podem ter dificuldades para auditar o que, quando e por que as ações foram tomadas.”

Como a IA agente é tão nova, não temos padrões ou práticas recomendadas para nos basearmos. Em vez disso, como profissionais de TI, precisamos descobrir as mitigações de risco entre nós e, esperançosamente, compartilhar publicamente o que estamos aprendendo à medida que avançamos. Kin Lanecofundador e diretor comunitário (CCO) da a empresa de API de código aberto Naftikovê a mitigação do risco agente no pensamento sistêmico termos. Sua tese ampla é que testar e simular é a forma como uma empresa pode se preparar com confiança e segurança para sistemas de agente.

O comportamento é a especificação

Uma das heurísticas mais conhecidas no pensamento sistêmico foi cunhada pelo falecido Cerveja Staffordum teórico britânico, consultor e professor da Manchester Business School. Ele usava frequentemente a frase: “O propósito de um sistema é o que ele faz” – significando que um sistema muitas vezes funciona de uma forma que está em desacordo com as intenções daqueles que o concebem, operam e promovem. “Afinal de contas”, observou Beer, “não há sentido em afirmar que o propósito de um sistema é fazer o que ele constantemente falha em fazer”.

Se o propósito de um sistema é de fato revelado através de seu comportamento e não de seu design, então entender o que Donella Prados refere-se como “e” – as relações entre os componentes – requer ser capaz de observar o sistema de forma confiável.

“O propósito de um sistema é o que ele faz. Afinal, não faz sentido afirmar que o propósito de um sistema é fazer o que ele constantemente falha em fazer.” – Cerveja Stafford

Ferramentas de observabilidade como Favo de mel use rastreamento distribuído e dados de eventos de alta cardinalidade para fornecer insights sobre o comportamento do sistema na produção, permitindo que os engenheiros consultem e explorem dimensões arbitrárias de telemetria (extensões, rastreamentos e campos de log estruturados) em tempo real. Mas para os sistemas agentes, também precisamos de confiança antes da produção.

Lane acredita que isso pode ser encontrado no conjunto de testes; o teste, diz ele, permite moldar intencionalmente o comportamento e, por sua vez, o futuro de uma API.

“As pessoas tendem a ver os testes de API como uma garantia de que estão fazendo o que deveriam”, diz ele A nova pilha. “Mas a combinação de ter uma área restrita forte e usar testes de contrato para obter um forte ciclo de feedback com seus consumidores permite iterar sobre o que o futuro reserva. As empresas com boas práticas de testes são muito melhores em inventar e lidar com o futuro. E são capazes de dar vida às coisas de maneiras confiáveis ​​e reproduzíveis com as quais produtores e consumidores concordam.”

É esta mentalidade que ele traz para o trabalho de definição de capacidades de negócios – essencialmente, unidades discretas e combináveis ​​que descrevem o que um sistema pode fazer por uma empresa (como “processar pagamentos” ou “gerenciar estoque”) – para seus clientes. Ele constrói sandboxes e simulações, permitindo assim que seus agentes de IA tenham um lugar seguro para brincar.

Para sua abordagem de trabalho, as simulações precisam ser representações precisas da realidade. “Devo ser capaz de mudar o URL da simulação para produção e obter respostas ao vivo de maneira confiável com a mesma estrutura”, diz ele. “Isso funciona como um teste; posso passar da simulação sintética para a produção sem quebrar?”

Bem feitos, simulações e testes de contrato reforçam-se mutuamente. Simulações frágeis e irrealistas indicam testes de contrato ruins ou inexistentes, e não uma falha na zombaria em si. Sem visibilidade compartilhada entre produtores e consumidores de APIs, as simulações e as APIs reais evoluem de forma independente, e isso pode quebrar a confiança. Quando os fornecedores publicam especificações e exemplos formais e os utilizam em seus próprios testes de contrato, todos permanecem alinhados.

Para conseguir isso, Lane prefere ferramentas de código aberto, especificamente Microcks e API abertacom Bruno para scripts.

Simulações compartilhadas, realidade compartilhada

Microcks é uma plataforma de simulação e teste de API de código aberto construída em Java que está em execução há dez anos e foi doada à Cloud Native Computing Foundation (CNCF) há mais de três anos. Construído para escala empresarial, é independente de linguagem, suportando REST/OpenAPI, AsyncAPI, Kafka, MQTT, WebSockets, gRPC, GraphQL e muito mais.

Essa amplitude é inestimável, já que os ambientes corporativos normalmente colocam vários padrões de API em camadas — aos quais me referi em um artigo anterior desta série como sedimento de API — em vez de padronizarem um. Sem uma ferramenta como a Microcks, “você acaba com uma ferramenta dedicada para cada tipo de protocolo ou especificação, o que é um pesadelo”, cofundador da Microcks, Yacine Kheddacheme disse. “Para fins de simulação, os desenvolvedores estão criando suas próprias simulações que não são representativas do serviço comercial real.”

A plataforma é construída em torno de uma filosofia de contrato em primeiro lugar. Um artefato primário (como uma especificação OpenAPI) é importado e Microcks o utiliza para gerar automaticamente endpoints simulados sem a necessidade de código. Para evitar o inchaço da especificação primária com centenas de exemplos, Microcks oferece suporte a artefatos secundários, conjuntos de exemplos adicionais provenientes de coleções do Postman, gravações de arquivos HTTP, um copiloto de IA ou arquivos YAML feitos à mão. O agrupamento de artefatos primários e secundários gera sandboxes dinâmicos que os adotantes descreveram como “sandbox como serviço”.

Um aspecto notável é como a Microcks incentiva a colaboração em toda a organização. “Não são apenas os desenvolvedores que mantêm simulações locais descartáveis ​​para testes de unidade. As equipes constroem conjuntos de dados de exemplo compartilhados e versionados, com os quais todos globalmente em torno do serviço de API contribuem e reutilizam.”

Kheddache diz. Isso permite o desenvolvimento paralelo entre equipes de microsserviços: os desenvolvedores simulam suas dependências, trabalham de forma independente e simplesmente trocam o serviço real quando ele estiver disponível.

Grandes adotantes, incluindo Amadeus, que usam Microcks para shift-left sua abordagem de simulação e teste de contrato relataram ganhos significativos na velocidade de desenvolvimento.

Microcks no BNP Paribas

O modelo colaborativo e de propriedade compartilhada que Kheddache descreve não é teórico. No BNP Paribas, 32 equipes da divisão bancária de varejo francesa agora usam Microckscom mais de 500 desenvolvedores e testadores ativos na plataforma e mais de 2,5 milhões de chamadas de API processadas semanalmente.

O BNP tinha um enorme mainframe legado no centro das principais operações bancárias, com o qual cada equipe tinha que interagir diretamente sempre que precisava construí-lo ou testá-lo. Lento, caro e sobrecarregando desnecessariamente a infraestrutura cuja operação custa muito dinheiro.

Ao zombar dessas APIs apoiadas por mainframe no Microcks, as equipes do BNP poderiam desenvolver e testar em paralelo sem tocar no mainframe, e apenas conectar-se a serviços reais quando realmente necessário. O resultado, de acordo com o estudo de caso publicado, foi que os ciclos de desenvolvimento e testes foram reduzidos em dois terços.

Houve também um bônus inesperado: a redução significativa da carga do mainframe se traduziu diretamente em menor consumo de energia, uma contribuição significativa para as metas de sustentabilidade do banco e não o tipo de resultado que você normalmente associaria a uma ferramenta de teste. “A capacidade de implantar sandboxes simuladas em todos os lugares, prontas para uso”, observou a equipe do BNP, “foi fundamental para fazer essa escala funcionar”.

É o tipo de resultado que Kheddache tinha em mente quando descreveu a promessa mais ampla da plataforma. “Quando eles adotam nossa abordagem, as vitórias são incríveis”, ele me disse. “Eles são capazes de acelerar o desenvolvimento, simular todas as dependências e todos podem trabalhar em paralelo.”

Para testes de contrato, a Microcks pode atuar como um cliente API, disparando solicitações em um endpoint real e verificando se ele permanece compatível com seu contrato em várias versões. Isso é útil para detectar alterações importantes e certificar a compatibilidade com versões anteriores.

A Microcks também passou a apoiar desenvolvedores individuais, não apenas equipes de plataforma centralizadas. Um binário nativo leve (compilado via GraalVM) começa em menos de 200 milissegundos e Contêineres de teste existem ligações para Java, Node, Go e .NET (a última contribuída pela AXA Insurance). Os desenvolvedores agora podem executar testes completos de integração localmente, usando os mesmos conjuntos de dados de exemplo compartilhados que o ambiente central, fechando a lacuna do “funciona no meu laptop”.

Cada endpoint de simulação Microcks agora também expõe um link Model Context Protocol (MCP), tornando APIs simuladas acessíveis para LLMs e agentes de IA como ferramentas. Um segundo projeto, atualmente sem nome, está em desenvolvimento: um proxy de tempo de execução que traduz especificações OpenAPI, GraphQL e gRPC em servidores MCP para uso em produção, com gerenciamento de segredos e modelagem de ferramentas personalizadas para tornar as APIs utilizáveis ​​de forma mais confiável por modelos de linguagem.

IA fragmenta o ciclo de feedback

Normalmente, no contexto de testes e simulações, quanto mais partes interessadas usarem o sandbox, maior será a probabilidade de você obter uma simulação abrangente e confiável. Adicione IA generativa à mistura, no entanto, e como acontece com o ato de programando em siainda estamos tentando entender como é um ciclo de feedback saudável. “Historicamente, o feedback saudável veio de ter todas as partes interessadas em um espaço de trabalho, um repositório ou uma reunião na mesma sala no quadro branco. Mas a IA fragmenta ainda mais as coisas, então tenho que repensar isso, e ainda não tenho uma boa resposta”, diz Lane.

“Esse menu de APIs internas e externas é o que você é capaz como empresa. Se você não tiver isso em um catálogo, sandbox ou registro, para poder testar, jogar e entender, suas equipes não saberão do que você é capaz.” –Kin Lane

Ele está, no entanto, certo de que você deve ter simulações, não apenas do que está produzindo, mas também do que está consumindo. “Esse menu de APIs internas e externas é o que você é capaz como empresa. Se você não tiver isso em um catálogo, sandbox ou registro, para poder testar, jogar e entender, suas equipes não saberão do que você é capaz.”

Ferramentas como o Microcks facilitam a simulação baseada em contratos, mas a colaboração e a propriedade compartilhada são o que fazem com que funcione. À medida que os sistemas agentes adquirem mais autonomia, essa compreensão partilhada do que um sistema pode, e deve, fazer torna-se a base sobre a qual todo o resto assenta.