Imagine uma situação bastante banal daqui a poucos meses.

Um comercial liga o ChatGPT ao CRM para preparar reuniões. Outro cria um agente para pesquisar contas e atualizar propriedades. Marketing liga um agente a uma ferramenta externa através de MCP. Customer Success experimenta outro para resumir tickets e criar tarefas.

Ninguém comprou um novo CRM. Ninguém abriu um projeto de integração. Em alguns casos, nem sequer foi necessário escrever código.

Mas a empresa acabou de ganhar quatro novos atores com acesso a contexto operacional — e alguns deles podem executar ações.

No RevOpsHubs chamamos a isto Shadow Agents.

Tese RevOpsHubs

O risco deixou de ser apenas “que software estamos a usar sem controlo?”. Passa a ser “que agentes conseguem ver, decidir e agir dentro dos nossos sistemas — e quem é responsável por eles?”.

O que é um Shadow Agent?

Não estamos a usar o termo como se já fosse uma categoria formal da indústria. É uma forma útil de nomear um problema operacional que está a começar a aparecer.

Um Shadow Agent é um agente, assistente ou aplicação de IA com acesso a sistemas, dados ou ferramentas da empresa que foi colocado em utilização sem existir uma definição clara de owner, âmbito, permissões, aprovações, monitorização e critérios de sucesso.

O ponto importante é este: um Shadow Agent não precisa de ser malicioso, clandestino ou sequer tecnicamente “não autorizado”. Pode ter sido criado por alguém com permissões legítimas. O problema é a ausência de um modelo operacional à volta dele.

FenómenoO que fica fora de controlo
Shadow ITSoftware e serviços usados fora do catálogo ou processo formal.
Shadow AIModelos e assistentes usados com dados ou tarefas da empresa sem governance suficiente.
Shadow AgentsAgentes com contexto e ferramentas capazes de tomar decisões ou executar ações sem contrato operacional claro.

Porque é que isto começa a ser um problema agora?

Porque a fronteira entre “assistente que responde” e “sistema que age” está a desaparecer depressa.

Em abril de 2026, o HubSpot Remote MCP Server passou a General Availability com capacidades de escrita em vários objetos do CRM. Isso significa que ferramentas compatíveis com MCP podem, respeitando as permissões existentes do utilizador, não só consultar contactos, empresas ou deals, mas também atualizar parte dessa informação.

A HubSpot também permite ligar agentes criados no Agent Builder a sistemas externos através do MCP Client, para aceder a dados em tempo real e executar ações noutros sistemas.

Do lado do ChatGPT, o suporte completo de MCP para ambientes Business e Enterprise/Edu já inclui ações de escrita e modificação, com controlos de administração, aprovação e acesso.

Nada disto é um problema em si. Pelo contrário: é precisamente isto que torna os agentes úteis.

O problema aparece quando a organização continua a governá-los como se fossem apenas mais uma licença de software.

Uma licença dá acesso. Um agente pode transformar esse acesso em ação.

O Shadow Agent Risk Model

Quando avaliamos um agente, a pergunta “está autorizado?” é demasiado curta. Propomos sete perguntas.

01

Identity — quem está realmente a agir?

O agente usa as permissões de um utilizador? Uma conta de serviço? Credenciais partilhadas? Se uma ação correr mal, conseguimos atribuí-la a uma identidade clara?

02

Context — o que consegue ver?

Contactos, deals, emails, documentos, notas internas, dados financeiros? Um agente não deve herdar automaticamente todo o contexto disponível só porque tecnicamente consegue aceder-lhe.

03

Tools — que ferramentas pode chamar?

Pesquisar é diferente de atualizar. Criar uma tarefa é diferente de enviar um email. Eliminar um registo é diferente de o resumir. A superfície de ferramentas define a superfície real de risco.

04

Write — o que pode alterar?

Que propriedades, objetos ou sistemas podem ser modificados? Há ações irreversíveis? Há ações que afetam o cliente diretamente?

05

Approval — onde é obrigatório parar?

Que ações podem ocorrer autonomamente e quais exigem aprovação humana? A OpenAI, por exemplo, permite configurar aprovações para ações de escrita e recomenda revisão humana em ações com efeitos sensíveis.

06

Audit — conseguimos reconstruir o que aconteceu?

Precisamos de saber que contexto foi usado, que ferramenta foi chamada, que ação foi tomada e com que resultado. Sem logs ou traces, não existe aprendizagem operacional.

07

Cost — quanto pode consumir?

Com modelos de pricing por consumo, autonomia também tem impacto financeiro. Um agente mal delimitado pode não só executar trabalho errado como consumir créditos a fazê-lo.

Os sete pontos formam aquilo a que chamamos a superfície operacional do agente. Quanto maior for essa superfície, maior tem de ser a qualidade da governance.

Revenue Systems Brief

Uma ideia útil. Um sistema para melhorar.

Uma nota semanal concisa para quem é responsável por receita, operações e crescimento.

O problema não é a alucinação. É a ação plausível.

Um exemplo simples: um agente de prospeção recebe acesso ao CRM, pesquisa na web, identifica empresas, atualiza propriedades e cria tarefas para os comerciais.

É fácil pensar que o principal risco é o agente “inventar” informação.

Mas os problemas mais difíceis podem ser muito menos óbvios:

  • classifica corretamente uma empresa, mas usa uma definição de ICP que já mudou;
  • atualiza uma propriedade legítima, mas essa propriedade alimenta um workflow que ninguém considerou;
  • cria tarefas válidas, mas para contas que pertencem a outro território;
  • repete uma ação centenas de vezes porque o trigger está demasiado amplo;
  • usa uma ferramenta nova adicionada ao MCP server que nunca foi revista pelo owner do processo.

Nenhuma destas falhas exige uma “IA descontrolada”. Basta uma decisão plausível dentro de um sistema mal delimitado.

É por isso que AI readiness começa antes da camada de IA. O agente herda definições, ownership, qualidade de dados e regras que já existiam — ou que nunca foram formalizadas.

Governance útil não significa bloquear agentes

A resposta errada seria transformar cada experiência com IA num projeto de seis semanas com cinco aprovações.

Isso só empurra novamente a utilização para fora do processo formal.

O objetivo é autonomia delimitada: permitir que equipas experimentem e obtenham valor, mas dentro de limites explícitos.

Inventário

Registe agentes, não apenas aplicações

Nome, owner, objetivo, sistemas ligados, ferramentas disponíveis, dados usados e estado: teste, piloto ou produção.

Privilégio mínimo

Dê apenas o acesso necessário

A própria HubSpot recomenda selecionar apenas as ferramentas MCP necessárias para a tarefa do agente. Comece por leitura e abra escrita quando existir razão operacional.

Aprovação

Separe recomendação de execução

Enviar, editar, eliminar ou assumir compromissos perante clientes não deve ter a mesma política de aprovação que pesquisar ou resumir.

Teste

Simule antes de dar autonomia

Teste casos normais, exceções e inputs maus. A HubSpot permite simular execuções de agentes sem alterar o CRM e sem consumir créditos.

Observabilidade

Guarde traces e reveja falhas

O objetivo não é vigiar pessoas. É perceber como o sistema decide e melhorar prompts, ferramentas, dados e guardrails.

Kill switch

Saiba como parar

Quem consegue desativar o agente, revogar a ligação, retirar ações de escrita ou reduzir limites de utilização? Isso tem de estar definido antes do incidente.

Uma auditoria de 30 minutos para RevOps

Se gere CRM, automação ou RevOps, eu começaria com uma folha simples. Não com uma política de 40 páginas.

  1. Liste os agentes e assistentes que a equipa usa com dados da empresa. Inclua ChatGPT, HubSpot, automações próprias e ferramentas externas.
  2. Assinale quais estão ligados a sistemas operacionais. CRM, email, Slack, suporte, ERP, data warehouse.
  3. Separe read de write. O que só consulta? O que pode alterar, criar, enviar ou eliminar?
  4. Identifique o owner. Uma pessoa concreta, não “Sales” ou “Marketing”.
  5. Marque ações que exigem aprovação. Especialmente ações externas, irreversíveis ou com impacto financeiro.
  6. Verifique logs, limites e forma de revogação. Se ninguém sabe como desligar rapidamente, há trabalho por fazer.

Se um agente falhar em três ou quatro destes pontos, não significa que tenha de ser desligado. Significa que ainda não está pronto para produção.

Da lista de agentes para um contrato operacional

O inventário resolve visibilidade. Não resolve comportamento.

Para cada agente que entra em produção, precisamos de responder a uma pergunta adicional: qual é o contrato sob o qual este agente pode operar?

É o tema do nosso próximo framework: o Agent Operating Contract. Em vez de começar pelo prompt, começamos por objetivo, contexto, ferramentas, permissões, aprovações, orçamento, métricas, escalamento e rollback.

Esta distinção vai tornar-se importante. Uma empresa pode ter excelentes prompts e péssima governance.

RevOps vai ter de governar atores, não apenas sistemas

Durante muito tempo, a stack era relativamente estática. Comprávamos ferramentas, dávamos acessos, criávamos integrações e auditávamos utilizadores.

Os agentes mudam essa geometria. Podem juntar contexto de vários sistemas, selecionar ferramentas e executar sequências de ações que antes exigiam pessoas.

É exatamente por isso que são interessantes.

Mas também significa que a pergunta de governance muda:

Não é apenas “quem tem acesso ao CRM?”. É “quem — humano ou agente — pode fazer o quê, com que contexto, sob que limites e com que responsabilidade?”.

Essa pergunta já pertence a Revenue Operations.

Fontes públicas

Continue a explorar

Semantic Debt: governar o significado antes da autonomia →O Agent Operating Contract →AI readiness começa antes da IA →O novo modelo de créditos da HubSpot →O que é um Revenue System? →