Por que as empresas devem começar com agentes de IA no local

O apelo dos agentes dentro e fora do navegador é óbvio. Eles prometem descoberta, escala e automação que você não precisa construir ou manter por conta própria. Um agente fora do navegador pode comparar seus preços com os de todos os concorrentes e continuar trabalhando depois que sua equipe de suporte voltar para casa. Uma extensão de co-navegação pode atuar dentro de uma sessão já autenticada de um usuário sem exigir qualquer integração especial de sua parte.

Mas um agente que você não controla ainda está falando em nome do seu negócio.

Um agente fora do navegador conversando com suas APIs ou raspando seu DOM é executado em um modelo que você não escolheu, segue proteções que você não escreveu e representa sua marca em uma conversa que você não pode ver. Se cotar incorretamente um preço, distorcer uma política ou iniciar uma transação que crie uma disputa com o cliente, o fato de o agente pertencer a outra pessoa pode não fazer com que o problema resultante desapareça.

Há também um problema de segurança mais profundo. Os agentes que usam computadores interagem com conteúdo não confiável desde o início. A orientação da Anthropic para agentes que usam navegadores e computadores observa que páginas da web e interfaces de aplicativos podem conter instruções adversárias e recomenda permissões com escopo definido, confirmação humana para ações de alto risco e monitoramento do comportamento do agente. A folha de dicas de segurança do agente de IA da OWASP vai além, identificando riscos específicos do agente, incluindo injeção imediata, abuso de ferramentas e escalonamento de privilégios, exfiltração de dados e envenenamento de memória.

Os agentes no navegador são um negócio melhor, porque um humano está observando a mesma tela e pode detectar um erro antes que ele chegue. Mas o modelo, o tom e a lógica de decisão ainda estão fora das suas mãos. Para qualquer outro setor regulamentado, esse não é um risco a ser assumido levianamente apenas para alcançar o alcance que você ainda não aprendeu a governar.

Um agente no local é menos glamoroso do que a ideia de seu produto ser descoberto por agentes itinerantes na web aberta. Mas é o único lar onde a empresa mantém governança plena.

Você escolhe o modelo. Você define os guarda-corpos. Você decide o tom, os caminhos de escalação e exatamente o que o agente pode ou não prometer ao cliente. Como o agente tem acesso direto aos seus sistemas, ele não precisa fazer engenharia reversa no seu fluxo de checkout como faria um agente externo. Pode ser fornecido seu conhecimento real de domínio e suas APIs reais.

Isso é importante porque as empresas já resolveram este problema antes. Eles não expuseram os bancos de dados diretamente na Internet; eles introduziram APIs. As APIs não tratavam apenas de integração. Eles criaram contratos, autenticação, auditoria e aplicação de políticas. Os agentes locais representam uma evolução semelhante. Em vez de forçar um agente externo a inferir o comportamento a partir de uma interface de utilizador, uma empresa pode expor capacidades governadas através de ferramentas com contratos explícitos.

O WebMCP é um passo promissor nessa direção. Torna mais fácil para um site publicar ações que um agente pode invocar, em vez de forçar o agente a adivinhar a página. A mudança importante não é que o agente possa clicar em um botão. É que cada ação se torna observável, governada por políticas e reproduzível.

A demonstração WebMCP Sports da equipe do Chrome é uma boa prévia de como isso pode parecer bem feito: um assistente no local chamando as ferramentas WebMCP do próprio site, com cada chamada visível no registro de bate-papo. Essa não é uma caixa preta que você espera que se comporte. É uma interação auditável, com ferramentas nomeadas e contratos definidos.

A maneira mais clara de pensar sobre isso é como um espectro.

• No local. O agente mora no seu site. Você envia. Você possui o modelo, as ferramentas, o tom, as políticas e a telemetria. Ele tem acesso primário aos seus sistemas e fluxos de trabalho. A desvantagem é o alcance: ele está acoplado ao seu site e não se destina a acompanhar a jornada do usuário pela web.
• No navegador. O agente reside dentro da sessão do navegador do usuário, geralmente como uma extensão de co-navegação ou um assistente integrado ao navegador. Ele se beneficia do estado logado do usuário e pode atuar com o usuário presente. Isso lhe confere um alcance real e uma forte rede de segurança humana. Mas a empresa não controla o modelo nem as proteções, e o agente ainda pode deturpar a marca.
• Fora do navegador. O agente é executado em outro lugar — na nuvem, em um servidor ou na máquina local de um usuário e chega ao seu negócio conversando com APIs ou acionando um navegador remotamente. Este é o modelo de maior alcance, mas também o menos governado do ponto de vista empresarial. Ele pode comparar concorrentes, cruzar fluxos de trabalho e agir em escala, mas você não controla a experiência.

Nenhuma dessas casas é inerentemente ruim. Eles resolvem problemas diferentes. Mas se a sua primeira prioridade for governação, responsabilidade e integridade da marca, a presença no local é o ponto de partida certo.

Para as equipes que decidem onde colocar seu primeiro investimento, três movimentos fazem a diferença entre uma interface real e um chatbot colado a uma página inicial.

Primeiro, envie o agente local como uma interface oficial, não como um substituto. Ele deve ter acesso de primeira classe às suas próprias APIs e conhecimento de domínio – os mesmos sistemas que sua equipe de suporte e fluxo de checkout já usam – em vez de receber uma versão raspada de sua própria página.

Em segundo lugar, instrumente cada chamada de ferramenta que ela fizer. Se o seu agente ligar para uma ferramenta WebMCP para verificar o estoque ou aplicar um desconto, registre-o da mesma forma que registraria uma chamada de API de qualquer outro cliente. Esse registro é sua trilha de auditoria, sua ferramenta de depuração e, eventualmente, sua evidência quando um regulador ou cliente pergunta o que aconteceu.

Terceiro, projetar para a escalada humana desde o primeiro dia. Mesmo um agente bem governado não deveria tomar todas as decisões de forma autónoma. Crie caminhos de transferência explícitos para operadores humanos em situações ambíguas ou de alto risco.

Juntas, essas escolhas transformam um agente no local em uma interface governada, em vez de um recurso inovador. Essa distinção é importante. A primeira é algo que uma empresa pode operar com segurança; a segunda é algo que eventualmente terá de defender.

Há outra razão para construir primeiro o agente no local: é pouco provável que as três casas permaneçam isoladas.

Imagine que o agente navegador de um usuário chegue ao site de uma companhia aérea. Já conhece as preferências do viajante, as restrições de calendário, os programas de fidelidade e talvez o seu orçamento. O agente local da companhia aérea conhece algo completamente diferente: rotas, disponibilidade de assentos, regras tarifárias, elegibilidade para upgrade e as políticas operacionais da companhia aérea.

Por que o agente visitante deveria fazer engenharia reversa de tudo isso em um site?

Uma arquitetura mais natural pode ser a comunicação entre os dois agentes.

Isso não é mais puramente hipotético. O protocolo Agent2Agent (A2A) foi explicitamente projetado para permitir que agentes independentes criados por diferentes fornecedores e estruturas descubram recursos, troquem informações, deleguem trabalho e coordenem tarefas.

Nesse mundo, o agente do usuário traz a intenção e o contexto do usuário. O agente do site traz conhecimento de domínio e execução governada.

E, de repente, o alcance limitado do agente no local não parece tão limitante. Ele não precisa viajar pela web se outros agentes puderem acessá-lo.

Há uma questão mais difícil por trás da questão técnica: para quem o agente local realmente trabalha?

Um agente visitante, co-navegador ou não, está agindo em nome do usuário. Um agente local, por mais bem constituído que seja, é o funcionário da empresa. E no momento em que os dois negociam um desconto, um upgrade ou uma substituição, essa troca deixa de parecer uma transferência neutra e passa a parecer uma conversa de vendas com uma IA em cada lado da mesa.

Essa tensão vai importar.

As empresas que criam agentes no local devem agora conceber as suas barreiras de proteção com esse escrutínio em mente, em vez de tratar “o agente decidiu” como um escudo. Vale a pena ter controle. Também é uma responsabilidade. E construir o agente que responde a você é a única forma de exercê-lo.

A história do software empresarial sugere um padrão familiar. As organizações adotam novos modelos de interação, primeiro colocando-os sob a sua própria governação. Os sistemas internos tornam-se APIs. APIs se tornam plataformas. As plataformas tornam-se ecossistemas.

Os agentes de IA provavelmente seguirão o mesmo caminho.

É por isso que acho que o primeiro agente que sua empresa constrói não deve ser aquele que consegue alcançar toda a web. Deve ser aquele cujo comportamento você pode compreender, medir e melhorar. Uma vez que essa base exista, a expansão para fora torna-se uma escolha arquitetônica em vez de um ato de fé.

O alcance é tentador. Mas para empresas regulamentadas e sensíveis à marca, o controlo tem de vir em primeiro lugar.