← Todos os textos

Os agentes de IA não vão matar o teu sistema de registo. Os teus limites de pedidos vão.

Nesta página

Zain Hoda, cofundador da Vanna AI, escreveu há pouco uma thread certeira a defender que os agentes de IA vão esvaziar os sistemas de registo.1 A tese: quando um agente consegue clonar o teu CRM inteiro em segundos, o fosso dos dados evapora-se. O sistema de registo passa a ser um endpoint de escrita burro e o agente passa a ser a interface a sério.

Ele tem razão quanto ao problema. Acho que está errado quanto ao desfecho.

Os sistemas de registo não vão colapsar. Mas os que resistirem a esta mudança vão ser substituídos, sem hipótese, pelos que não resistirem.

O paralelo com a cibersegurança que ninguém faz

Na cibersegurança há um princípio fundamental: autorizar o mais perto possível do recurso. Não ponhas toda a confiança no perímetro e rezes para correr bem. Empurra o controlo de acesso para onde os dados realmente vivem.

Os sistemas de registo já fazem isto, e há décadas. Juntam duas coisas que são mesmo difíceis de separar: os dados da empresa e as regras de acesso que decidem quem os pode ver e alterar. Quem pode ver este registo de cliente? Quem pode aprovar esta despesa? Quem mudou este campo e quando?

Isto não são funcionalidades acessórias. São a razão toda pela qual as indústrias reguladas não podem despejar tudo na janela de contexto de um agente e dar o assunto por encerrado.2

Hoda reconhece-o de passagem (governação, permissões, sincronização entre vários utilizadores), mas despacha-o como “um negócio muito mais pequeno”. Acho que isso o subestima enormemente.

Os limites de pedidos são a luta errada

Onde concordo a sério: os sistemas de registo que respondem à IA fechando o acesso à API estão a jogar um jogo perdido. Um jogo estúpido, até.

Os limites de pedidos não protegem o teu fosso. Só tornam o teu produto pior. Um agente suficientemente motivado vai guardar em cache localmente, sincronizar de tempos a tempos e contornar-te por completo. Parabéns: ensinaste os teus clientes a tratar-te como uma dependência a montante pouco fiável, em vez de seres o centro do fluxo de trabalho deles.

É o equivalente, no software empresarial, à indústria da música a processar o Napster. Não estás errado quanto à propriedade. Estás só catastroficamente errado quanto à estratégia.

O MCP é a adaptação que conta

Aqui é que fica interessante.

O Model Context Protocol é um padrão aberto que deixa os agentes de IA falar com o software empresarial de forma estruturada.3 Não é só mais uma camada de integração. É uma forma de os sistemas de registo continuarem competitivos precisamente porque lhes permite manter o controlo onde interessa.

Um servidor MCP fica à frente dos teus dados e expõe-nos aos agentes de IA de forma estruturada e governada. Pensa numa receção de hotel. O agente não recebe a chave-mestra de todos os quartos. Faz um pedido, a receção verifica se o pedido é permitido e entrega apenas o que é adequado. Cada interação tem âmbito definido, é autenticada e fica registada.

É o princípio de “autorizar no recurso”, aplicado à IA. Em vez de combateres o acesso dos agentes, canalizas esse acesso por uma camada que controlas.

O sistema de registo que abraça o MCP diz: “Sim, os agentes podem interagir com os nossos dados. Aqui está o protocolo. Aqui estão as permissões. Aqui está o rasto de auditoria.” O que o combate diz: “Não, não podes fazer mais de dez chamadas à API por minuto.” Em qual dos dois estás a construir?

Claro que o MCP não é magia. Se lançares um endpoint MCP sem autenticação nem controlo de acesso, acabaste de abrir a porta a todos os agentes da internet.4 O incidente do Clawdbot, em janeiro, provou-o: mais de mil instalações expostas, a maioria com a configuração por defeito e sem autenticação. A receção só funciona se alguém estiver mesmo a verificar credenciais.

Tratar alterações como transferências bancárias

Há outro ângulo que não recebe atenção suficiente: a reversibilidade.

Os agentes de IA vão cometer erros. Vão atualizar o registo errado, fundir duplicados que não deviam ser fundidos, criar entradas com base em contexto alucinado. Não é uma hipótese. É o custo inevitável da ação autónoma à escala.

Os sistemas de registo estão em posição única para lidar com isto, mas só se tratarem cada alteração iniciada por uma IA como uma transferência bancária. Quando o teu banco processa um pagamento, não se limita a subtrair de uma conta e somar a outra. Cria um registo da transferência: o que mudou, quando, quem a fez e quais eram os saldos antes e depois. Se algo correr mal, o banco consegue reverter a transferência sem desalinhar tudo o resto.

Cada alteração feita por um agente de IA devia funcionar da mesma maneira. Discreta, registada, com um estado antes e depois bem definido. Se o agente atualizar mal um registo de cliente, deves poder carregar em desfazer sem te preocupares com o que se parte a jusante.

Facilita a reversão. Torna visível o raio de impacto. Dá aos humanos um desfazer com um clique que não se transforma em caos em cascata.

É aqui que o argumento de que “a governação é só uma funcionalidade” desmorona por completo. Construir este tipo de rastreio de alterações e reversão segura numa plataforma de dados não é um acessório. É engenharia difícil a sério, no coração do sistema. E é exatamente o tipo de coisa que uma cache de agente isolada não consegue fazer bem, porque não é dona do estado canónico.

A divisão real

O que está de facto a acontecer não é “os sistemas de registo colapsam”. É uma bifurcação.

Os sistemas de registo que se adaptam vão expor interfaces MCP ricas, manter controlo de acesso com autoridade, oferecer auditabilidade ao nível de cada alteração e fazer da IA um cidadão de primeira classe da plataforma.5 Vão valer mais, não menos, porque são a camada de confiança numa stack cada vez mais autónoma.

Os sistemas de registo que não se adaptam vão limitar, restringir e litigar até à irrelevância. Os clientes vão migrar para plataformas que trabalham com o paradigma dos agentes e não contra ele.

O fosso nunca foi “guardamos os teus dados”. Foi “somos o sistema em que confias para guardar os teus dados”. A confiança exige governação, auditabilidade e controlo. Essas coisas não vão desaparecer. Vão passar a importar muito mais.

Resumindo

Os sistemas de registo não estão a morrer. Mas os que tratam o acesso da IA como uma ameaça e não como uma restrição de desenho vão perder para os que não o fazem. O MCP dá a estas plataformas uma forma de continuarem a ter autoridade enquanto se abrem aos agentes. Vão ganhar as plataformas que tornarem a interação com a IA rastreável, reversível e auditável por defeito.

Vão perder as que ainda estiverem a discutir limites de pedidos.


Footnotes

  1. Zain Hoda (co-founder, Vanna AI), “The Agent Will Eat Your System of Record” (X/Twitter, 2025). Link ↩

  2. Cerbos, “MCP Permissions: Securing AI Agent Access to Tools” (September 2025). Detailed treatment of access control enforcement via MCP servers. Link ↩

  3. Anthropic, “Model Context Protocol” (November 2024). The protocol was donated to the Agentic AI Foundation under the Linux Foundation in December 2025. Wikipedia ↩

  4. PointGuard AI, “Clawdbot MCP Vulnerability Exposes AI Agents” (January 2026). Over a thousand exposed MCP deployments with no authentication, a real-world example of what happens when the concierge desk has no one behind it. Link ↩

  5. Microsoft, “Dynamics 365 ERP Model Context Protocol” (November 2025). Microsoft’s framing of the shift “from systems of record to systems of action.” Link ↩