O time de finanças está construindo agentes em Lovable. Para o ERP, é shadow IT da era da IA
A Lovable atravessou US$ 400M de ARR em fev/2026, com 8 milhões de usuários e 100 mil projetos novos por dia. 87% das Fortune 500 já rodam pelo menos uma plataforma de vibe coding. Em times de finanças, alguém da operação já construiu o próprio agente. A tese deste post: o ERP que não se tornar o núcleo agêntico próprio da organização poderá enfrentar custos significativos, especialmente em incidentes fiscais ou processos de auditoria, ao constatar que agentes externos não respeitam necessariamente os limites do seu perímetro de controle.
O fenômeno em números:
- A Lovable, plataforma de vibe coding (a categoria de software que deixa qualquer pessoa descrever em linguagem natural e gerar app ou agente funcional), atravessou US$ 400 milhões de ARR em fevereiro de 2026, depois de sair de US$ 200 milhões em novembro de 2025. Só em março de 2026, somou US$ 100 milhões de receita.
- 8 milhões de usuários em finais de 2025; mais de 100 mil projetos novos criados por dia.
- Klarna e HubSpot já são clientes enterprise.
- 87% das empresas Fortune 500 rodam pelo menos uma plataforma de vibe coding em começo de 2026, segundo pesquisa de mercado.
Para a maioria dos leitores desta publicação, esse número de 87% se traduz em uma frase só: alguém do seu time de operação já construiu um agente próprio, em alguma plataforma de vibe coding, que está lendo ou escrevendo dado do seu ERP. Não pediu permissão. Não passou por TI. Está rodando. Funciona até o dia em que não funciona.
A tese deste post: o vibe coding é genuinamente útil no escopo apropriado e continuará crescendo, mas, no contexto do ERP, configura uma forma de shadow IT da era da inteligência artificial. A saída estrutural passa por fazer o ERP se tornar o núcleo agêntico próprio da organização, com uma plataforma de agentes nativa ao dado, à identidade e à política do sistema. Tentativas de proibir o Lovable raramente funcionam, conforme discutido adiante.
Por que o time de finanças constrói o próprio agente
A motivação é honesta. Olhe da cadeira de quem faz fechamento mensal, conciliação bancária ou classificação de despesa em mid-market:
- O ERP não automatiza um detalhe específico do fluxo. O analista pediu ao TI faz três anos. A resposta foi "está no roadmap".
- Em duas tardes na Lovable, o analista descreve o que precisa, conecta o sistema via API do ERP, cola a credencial dele, e gera um app web que faz o que ele queria. Inclui dashboard, automação, notificação por e-mail.
- O CFO vê o resultado, gosta, pede para replicar em outro fluxo. Outro analista entra na onda. Em três meses, são cinco a dez agentes pequenos, cada um construído individualmente, cada um tocando dado do ERP.
Em escopo limitado, isso funciona. Lovable é boa tecnologia, e o problema que ela resolve (a velocidade de criação de software simples) é real. A frustração do time de finanças com o ritmo do TI é real. A vontade de fazer o trabalho com mais alavanca é positiva.
O problema está em o que esses agentes começam a fazer quando passam de duas semanas no ar.
Os sete problemas estruturais quando o agente externo encosta no ERP
Cada um desses problemas existe individualmente. Quando se acumulam, viram a versão de 2026 do shadow IT que TI já conhece há vinte anos, com risco multiplicado.
1. Identidade quebrada (Zero-Trust Agent Identity, ZTAI). O padrão emergente de 2026 (citado pela Gartner como categoria de produto de governance e pela ServiceNow no anúncio do AI Control Tower na semana passada) é simples: toda chamada de agente tem que ser autenticada, autorizada e auditada por identidade própria. Agente no Lovable usa, na imensa maioria dos casos, a credencial pessoal do funcionário que o construiu. Quando o funcionário sai, o agente herda o vazio. Quando o funcionário ganha acesso novo a um módulo do ERP, o agente herda também, sem aprovação. Auditoria não distingue ação humana de ação do agente.
2. Audit trail fragmentado. O ERP tem trilha por transação. O agente fora dele tem trilha por chamada da API. Reconciliar as duas no momento de uma auditoria fiscal exige ferramenta que ninguém tem em mid-market. Para SPED, eSocial, contas a pagar regulamentadas, isso é exposição direta.
3. Conhecimento de domínio duplicado. Política fiscal, regra contábil, hierarquia de aprovação, regime tributário: tudo isso está codificado no ERP. O agente em Lovable replica essa lógica fora, em código gerado por IA. No dia em que o ERP atualiza a regra (por exemplo, IBS/CBS em 2027), o agente externo continua usando a regra antiga até alguém perceber. O ERP é uma fonte de verdade; o agente passa a ser uma segunda, divergente.
4. Latência e ponto de falha cumulativos. Cada agente externo adiciona camadas: API do ERP, modelo LLM, runtime do Lovable, integração da credencial, callback. Cada camada é falha potencial. O fluxo de fechamento mensal não tolera quatro pontos de falha em série quando antes tinha um.
5. Vácuo de responsabilidade regulatória. Quando o agente em Lovable aplica a regra fiscal errada e gera autuação, quem responde? O analista que construiu? A Lovable como plataforma? O ERP que entregou a API? O fornecedor do LLM? Cada um aponta para o outro. Para o ERP brasileiro, regulado pela Receita Federal, isso é alta exposição. Para o ERP integrado com agente próprio dentro, o fornecedor do ERP responde, contratualmente.
6. Soberania de dado. Dado fiscal e financeiro de empresa atravessa o perímetro do ERP a cada chamada do agente externo. Cada travessia é ponto de governança LGPD (no Brasil), GDPR (na Europa), sigilo bancário, política interna. Agente dentro do ERP nunca sai do perímetro. Auditoria de fluxo de dado simplifica.
7. Descompasso de estado. O agente em Lovable mantém estado próprio (memória, cache, snapshots). O ERP é fonte de verdade transacional. Os dois desincronizam ao longo do tempo, em casos sutis (resultado de re-cálculo de retroativo, lançamento de ajuste, reclassificação contábil). O agente fica confiantemente errado.
Gartner projetou em novembro de 2025 que mais de 40% das empresas vão ter incidente de segurança ou compliance ligado a shadow AI não autorizado até 2030. AI governance spending vai sair de US$ 492 milhões em 2026 para mais de US$ 1 bilhão em 2030. O pull do mercado existe, e cada incidente público vai reforçá-lo.
A tese: o ERP precisa se tornar o núcleo agêntico próprio
A primeira reação de TI ao detectar shadow agent é proibir. Não funciona, por dois motivos. Lovable é boa tecnologia em escopo correto (produtividade pessoal, dashboard individual, prototipagem rápida em Camada 1 (ERP Aumentado, copilot)), e a Gartner projeta que essa categoria vai dominar a produtividade pessoal corporativa nos próximos anos. E a demanda do time de finanças é real: o ritmo do TI não atende. Proibir Lovable empurra o problema para WhatsApp.
A solução estrutural é diferente: o ERP precisa se tornar o núcleo agêntico próprio, plataforma de agentes nativa ao dado, à identidade e à política do sistema. Em vocabulário concreto:
- A identidade do agente é gerenciada pelo ERP, herda contexto de permissão por módulo, opera dentro do ZTAI.
- A trilha de auditoria do agente é a mesma trilha de auditoria da transação. Não tem reconciliação entre dois sistemas.
- A regra fiscal, contábil ou de aprovação é compartilhada com o agente por construção. Quando atualiza no ERP, atualiza para o agente.
- O agente roda no mesmo runtime ou em runtime co-localizado, com latência baixa e dependência única do ERP.
- A responsabilidade contratual pelo erro do agente está com o fornecedor do ERP, como já está pela exatidão da transação.
- O dado nunca atravessa o perímetro do ERP em fluxo regular. Quando atravessa (relatório enviado a terceiro, integração externa autorizada), o atravessamento é evento auditável de primeira classe.
- O estado do agente é o estado do ERP. Não há drift por construção.
Lovable e similares viram clientes do ERP, não peers. Pedem dado ao ERP via API governada, recebem com escopo, devolvem resultado para o ERP gravar. O centro do fluxo agêntico permanece dentro.
Quem está construindo isso
A categoria existe e está em produto, em múltiplos fornecedores, em maturidades diferentes. Sem ordem específica:
- SAP com a Autonomous Suite anunciada no Sapphire 2026 (Joule + Joule Studio + Joule Work, 224 agentes e mais de 50 assistants nativos)
- Sankhya com Deploy Agent, focada em setup inicial de ERP por enquanto
- Senior com SARA Studio, plataforma de criação de agentes para o cliente final usar
- Nasajon com plataforma agêntica nativa, em construção, com primeiros fluxos em produção em clientes piloto
- TOTVS com LYNN como foundation para agentes nativos
- Oracle Fusion com AI Agent Studio, lançado em março de 2026
- Workday com Workday Illuminate
- NetSuite com NetSuite Next
- ContaAzul, Omie, Conta Simples ainda em Camada 1, com roadmap declarado para 2027
Cada um desses está em estágio diferente, e a barra que vale (conforme estabelecemos na Edição 3) é "caso público com cliente nomeado e número quantificado". Quem chegar primeiro nessa barra ganha a narrativa do mid-market. Quem ficar só em PowerPoint perde.
A pergunta operacional para o CFO
Ao terminar de ler este post, o leitor que dirige operação financeira pode fazer uma pergunta ao time, dois caminhos práticos:
Primeiro caminho, inventário. "Nos últimos 30 dias, alguém aqui construiu um agente, automação ou aplicativo em Lovable, Bolt.new, v0, Replit ou similar, que toca dado do nosso ERP de alguma forma?" Se a resposta for "sim", o leitor tem shadow agent já em produção. O passo seguinte é catalogar, avaliar risco (qual dado, qual fluxo, qual credencial), e decidir caso a caso o que fica, o que migra para a plataforma agêntica do ERP, o que precisa ser desligado.
Segundo caminho, fornecedor. Na próxima reunião com o fornecedor do ERP, perguntar diretamente: "vocês têm plataforma de agentes nativa ao ERP, com identidade própria, audit unificado, regra fiscal compartilhada, e responsabilidade contratual pelo erro do agente?" Se a resposta for vaga ou for "estamos no roadmap", o vendor está atrás. Se for concreta, com caso público nomeado, vale comparar com a barra.
A previsão, sem três cenários
Em 2028, o CFO médio de empresa entre R$ 50 milhões e R$ 500 milhões poderá ter entre 5 e 20 agentes shadow construídos por times de operação, tocando dado do ERP via integração ad-hoc. A questão deixa de ser se isso acontecerá, e passa a ser quanto custará quando alguém errar uma apuração fiscal por dentro de um agente Lovable que ninguém auditou. Para o CFO, a pergunta operacional importa por dois ângulos simultâneos: reduzir a superfície de risco enquanto o ERP constrói o núcleo agêntico próprio. As duas frentes precisam andar em paralelo.
O fornecedor de ERP que entregar a plataforma agêntica primeiro tenderá a ganhar três anos de vantagem em uma janela na qual o competidor está sendo escolhido por outros critérios. O cliente que optar por essa plataforma pagará mais em 2026 do que pagará em 2028, e economizará no incidente que não aconteceu.
Nas próximas duas leituras desta edição: em Produto, a ServiceNow na Knowledge 2026, com a expansão do AI Control Tower como camada externa de governance que tenta operar sobre agentes de qualquer fornecedor. Em Mercado, o hardware de IA que chegou ao notebook do CFO em 2026, com Nvidia RTX Spark, Apple M5 e Qualcomm, e o que muda concretamente para o early adopter, com os números de adoção que recomendam moderação.
Fontes: TechCrunch, Lovable adicionou US$ 100M de receita em um mês com 146 funcionários (11/mar/2026) · Stripe, Lovable case study · AI Funding Tracker, Lovable Revenue US$ 200M ARR · GetPanto, Lovable Statistics 2026 · FindSkill, State of Vibe Coding 2026 · Gartner, AI governance spending forecast 2026 · The Hacker News, Hidden Security Risks of Shadow AI · CIO, Shadow AI morphs into shadow operations · Produto desta edição, ServiceNow AI Control Tower · Mercado desta edição, chip de IA no notebook do CFO · Sankhya Deploy Agent (Edição 3) · Senior SARA Studio (Edição 4) · TOTVS LYNN (Edição 2) · Taxonomia de camadas