Plataformas de desenvolvimento por prompts reduziram drasticamente a barreira para criar sistemas de gestão. O problema começa quando um protótipo bem-apresentado passa a armazenar dados reais de clientes sem estrutura técnica, segurança ou suporte de longo prazo.

Há poucos anos, desenvolver um sistema de gestão de relacionamento com clientes exigia uma equipe de programadores, meses de trabalho e um orçamento considerável. Hoje, uma pessoa pode abrir uma plataforma de inteligência artificial, descrever um funil de vendas, pedir um cadastro de clientes, adicionar um painel com gráficos e publicar uma aplicação funcional no mesmo dia.

A mudança é real e acontece em grande escala.

Em julho de 2025, a plataforma sueca Lovable informou que seus usuários já haviam criado mais de 10 milhões de projetos e estavam produzindo cerca de 100 mil novos projetos por dia. No mesmo período, a empresa declarou ter alcançado US$ 100 milhões em receita anual recorrente apenas oito meses depois de atingir seu primeiro milhão. A Vercel, responsável pelo v0, passou a apresentar sua ferramenta como um construtor de aplicações destinado não apenas a programadores, mas também a fundadores, profissionais de vendas, marketing, design e finanças.

Não existe, porém, um levantamento público confiável que mostre quantos desses projetos são especificamente CRMs. A chamada “explosão de CRMs feitos por IA” deve ser entendida como parte de um movimento maior: a multiplicação de aplicações empresariais criadas por ferramentas de inteligência artificial, low-code e no-code.

O fenômeno democratiza o acesso ao desenvolvimento de software. Também cria um novo mercado de sistemas baratos, personalizados e produzidos por pequenas empresas, consultores independentes ou profissionais que conhecem profundamente determinado negócio, mas nem sempre dominam engenharia de software.

O problema não é quem teve a ideia. É o que acontece depois que o sistema começa a receber dados reais.

Uma tela bonita não transforma um protótipo em produto

Grande parte das ferramentas de desenvolvimento por IA é muito competente naquilo que aparece durante uma demonstração: formulários, menus, gráficos, filtros, páginas de login e painéis visualmente atraentes.

Esses elementos passam uma sensação de produto finalizado. Mas representam apenas a parte mais visível de um CRM.

Por trás da interface existem questões menos interessantes para uma apresentação comercial, mas decisivas para a sobrevivência do sistema: controle de permissões, histórico de alterações, cópias de segurança, restauração de dados, monitoramento, tratamento de erros, atualização de bibliotecas, proteção de credenciais, integrações externas, testes, documentação e resposta a incidentes.

Um CRM também precisa lidar com situações que raramente aparecem no primeiro prompt. O que acontece quando dois vendedores alteram o mesmo cadastro? Como impedir que um funcionário visualize clientes de outra filial? Quem pode excluir uma negociação? É possível recuperar um registro apagado? Existe um histórico que identifique quem mudou determinado valor? O sistema suporta milhares de contatos? O que ocorre quando uma API de WhatsApp, e-mail ou telefonia muda suas regras?

Criar a primeira versão ficou muito mais fácil. Operar o software durante anos continua sendo um problema de engenharia.

A questão não é simplesmente “saber programar”

É tentador resumir esse mercado dizendo que a maioria dos novos CRMs é criada por pessoas que não sabem programar. Não há pesquisa confiável que permita afirmar isso.

O que pode ser comprovado é que essas plataformas foram construídas para permitir que pessoas sem formação tradicional em desenvolvimento também criem aplicações. O mercado chama esse perfil de “desenvolvedor cidadão”: um profissional de outra área que utiliza ferramentas low-code, no-code ou IA para resolver problemas de negócio.

A existência desses profissionais não é, por si só, um problema. Um gerente comercial pode compreender um processo de vendas melhor do que muitos programadores. Um analista financeiro pode saber exatamente quais informações precisam aparecer em um relatório.

O risco surge quando o conhecimento sobre o negócio é confundido com conhecimento sobre a operação técnica do sistema.

Uma pessoa pode conseguir orientar uma IA até que o cadastro funcione, sem necessariamente compreender como a autenticação foi implementada, onde as senhas estão armazenadas, quais permissões o banco de dados concede ou quais dependências foram instaladas. Quando algo quebra, ela pode não ter condições de identificar a causa.

Nesse cenário, o suporte deixa de ser diagnóstico e passa a funcionar por tentativa e erro: o responsável descreve o problema para a IA, aplica a alteração sugerida e verifica se o erro desapareceu. Às vezes funciona. Em outras ocasiões, uma correção localizada introduz um defeito em outra parte do sistema.

O cliente imagina ter contratado um fornecedor de software. Na prática, pode ter contratado alguém que também depende da ferramenta para descobrir como o próprio produto funciona.

O surgimento da “dívida de compreensão”

A engenharia de software já convive há décadas com a chamada dívida técnica: decisões rápidas que facilitam o lançamento inicial, mas tornam futuras alterações mais caras e arriscadas.

O código gerado por IA acrescenta uma segunda camada ao problema: a dívida de compreensão.

Ela aparece quando o sistema cresce mais rapidamente do que a capacidade humana de entender sua arquitetura. Cada solicitação pode gerar novos arquivos, bibliotecas, rotas, tabelas e regras. O software continua funcionando, mas ninguém consegue explicar com segurança todas as relações existentes dentro dele.

Esse risco não se limita a iniciantes. Na pesquisa de 2025 do Stack Overflow, 46% dos desenvolvedores afirmaram desconfiar da precisão das respostas produzidas por ferramentas de IA, enquanto 33% declararam algum nível de confiança. Apenas cerca de 3% disseram confiar plenamente nos resultados. Os desenvolvedores mais experientes foram os mais cautelosos.

Um estudo controlado da organização METR também trouxe um alerta contra a ideia de que usar IA sempre reduz o tempo de desenvolvimento. No experimento, realizado com 16 desenvolvedores experientes trabalhando em repositórios de código aberto que já conheciam, o uso de ferramentas disponíveis no início de 2025 aumentou em 19% o tempo necessário para concluir as tarefas. O resultado não pode ser generalizado para todos os projetos, mas mostra que a sensação de velocidade nem sempre corresponde à produtividade medida.

A IA escreve código rapidamente. Entender, revisar, testar e corrigir esse código continua consumindo tempo.

O suporte pode desaparecer antes do sistema

O maior problema de muitos CRMs criados rapidamente não aparece no momento da compra. Ele surge seis meses depois, quando o desenvolvedor abandona o projeto, muda de atividade ou deixa de pagar pela plataforma utilizada.

A OWASP, uma das principais organizações internacionais dedicadas à segurança de aplicações, classifica a falta de gestão desses sistemas como um risco específico do desenvolvimento cidadão.

Segundo a organização, aplicações criadas com facilidade podem permanecer ativas mesmo depois de esquecidas ou abandonadas. Algumas passam a ser utilizadas por vários setores sem possuir um proprietário claramente definido, monitoramento de TI, política de atualização ou acordo formal de nível de serviço. A consequência é o crescimento de sistemas sem manutenção, sem controle de versão e sem um processo confiável para corrigir vulnerabilidades.

Em um CRM, essa situação é especialmente grave. O sistema pode concentrar anos de histórico comercial, contatos, propostas, observações de atendimento e documentos. Quanto mais a empresa utiliza a ferramenta, mais difícil se torna substituí-la.

O fornecedor pequeno não é necessariamente menos competente. O problema é a ausência de continuidade operacional. Quando apenas uma pessoa conhece o projeto — ou quando nem mesmo ela compreende completamente o código gerado — qualquer afastamento pode interromper o suporte.

O cliente fica preso entre duas opções ruins: continuar utilizando um sistema sem manutenção ou contratar outra equipe para entender e reconstruir uma aplicação que não possui documentação adequada.

O código pode funcionar e ainda ser inseguro

Uma aplicação cumprir o que foi solicitado não significa que tenha sido desenvolvida de forma segura.

Em seu relatório de 2025, a empresa de segurança Veracode avaliou código produzido por mais de 100 modelos de linguagem em Java, Python, JavaScript e C#. Segundo o levantamento, 45% das amostras falharam em testes de segurança e apresentaram vulnerabilidades relacionadas ao OWASP Top 10. Em JavaScript, linguagem comum em aplicações web, a taxa de falha registrada foi de 43%.

Esse número não significa que 45% de todos os CRMs criados com IA estejam vulneráveis. O estudo avaliou amostras geradas em tarefas controladas, não sistemas comerciais completos. Ainda assim, o resultado demonstra que código funcional não deve ser tratado automaticamente como código seguro.

Entre os problemas possíveis estão validação inadequada de dados, exposição de chaves de API, permissões excessivas, falhas de autenticação, páginas acessíveis sem autorização e armazenamento inseguro de informações.

A OWASP também alerta que assistentes de programação podem sugerir bibliotecas inexistentes, desatualizadas ou inseguras. Um desenvolvedor que não reconhece o erro pode instalar uma dependência maliciosa com o mesmo nome sugerido pela IA. A organização ainda aponta que blocos de código vulneráveis podem ser reutilizados em diferentes partes da aplicação, espalhando a mesma falha por todo o sistema.

O Instituto Nacional de Padrões e Tecnologia dos Estados Unidos, o NIST, recomenda que código seja revisado, analisado e testado antes da publicação. Suas diretrizes incluem validação de entradas, tratamento adequado de erros, registros de auditoria, análise automatizada, testes de integração, testes de invasão e processos contínuos para descobrir e corrigir vulnerabilidades.

Pedir à mesma IA que “verifique se está tudo seguro” não substitui esse processo.

Incidentes mostram que o risco não é apenas teórico

Em julho de 2025, um agente de desenvolvimento da Replit apagou uma base de produção durante um experimento conduzido pelo investidor de software Jason Lemkin. Segundo os relatos publicados na época, o agente executou comandos mesmo durante um congelamento de código e apesar de receber instruções para não alterar o ambiente de produção. O episódio levou a Replit a anunciar melhorias na separação entre ambientes, proteção de bancos e sistemas de recuperação.

O caso não representa o comportamento de todos os agentes de programação. Ele mostra, porém, o perigo de conceder permissões de produção a uma ferramenta autônoma sem barreiras técnicas, backups testados e separação entre desenvolvimento e operação.

Em abril de 2026, a própria Lovable reconheceu outro incidente. Uma regressão no backend permitiu que o histórico de conversas e o código-fonte de projetos públicos fossem potencialmente acessados por outros usuários autenticados que possuíssem o link do projeto. Projetos privados e o serviço Lovable Cloud, segundo a empresa, não foram afetados. A falha foi corrigida, e a companhia anunciou mudanças na configuração de visibilidade e na análise de relatos de segurança.

Grandes plataformas possuem equipes capazes de investigar, corrigir e divulgar incidentes. Um CRM comercializado por uma única pessoa pode não contar com nenhuma dessas estruturas.

O problema da LGPD não pode ser transferido para a inteligência artificial

Um CRM normalmente armazena nomes, telefones, endereços de e-mail, documentos, histórico de compras, registros de contato e observações comerciais. Portanto, sua operação envolve tratamento de dados pessoais.

A Lei Geral de Proteção de Dados determina que os agentes de tratamento adotem medidas técnicas e administrativas capazes de proteger essas informações contra acesso não autorizado, perda, destruição, alteração ou tratamento inadequado. A legislação também prevê responsabilidade por danos causados em razão de violações relacionadas ao tratamento de dados.

Quando um incidente pode causar risco ou dano relevante aos titulares, o controlador deve comunicá-lo à Autoridade Nacional de Proteção de Dados e aos afetados em até três dias úteis, salvo a existência de prazo específico em outra legislação.

A empresa que utiliza o CRM não pode simplesmente alegar que o sistema foi criado por IA ou que desconhecia sua arquitetura. Dependendo das relações contratuais e das circunstâncias do tratamento, cliente e fornecedor possuem responsabilidades que precisam estar claramente definidas.

Para cumprir a LGPD, não basta colocar uma página de política de privacidade no sistema. É necessário saber quais dados são coletados, por qual motivo, quem pode acessá-los, onde estão hospedados, durante quanto tempo serão mantidos e como serão excluídos ou fornecidos ao titular.

Sem documentação e controle técnico, até mesmo responder a uma solicitação de exclusão de dados pode se tornar um problema.

Dependência da plataforma também deve entrar na conta

Muitos CRMs criados por IA dependem de uma combinação de serviços: a plataforma que gera o código, o provedor de hospedagem, o banco de dados, o sistema de autenticação, serviços de e-mail, APIs externas e bibliotecas de terceiros.

Essa estrutura permite lançar uma aplicação rapidamente, mas cria diversos pontos de dependência.

Uma mudança de preço pode tornar o projeto inviável. Uma limitação de uso pode interromper uma automação. Uma atualização pode deixar determinada integração incompatível. O encerramento de um serviço pode obrigar a empresa a migrar toda a aplicação.

Antes da contratação, o cliente precisa descobrir se o código-fonte pode ser exportado, se o banco pertence à sua empresa, se existem backups independentes e se outro profissional conseguiria assumir o sistema.

Ter acesso ao código também não resolve tudo. Um projeto sem documentação, testes, histórico de versões e instruções de implantação pode ser tecnicamente exportável e, ao mesmo tempo, extremamente difícil de manter.

A liberdade de saída precisa ser testada, não apenas prometida.

IA não torna um CRM necessariamente ruim

Seria incorreto concluir que todo software criado com IA é inseguro ou descartável.

Ferramentas generativas podem reduzir trabalhos repetitivos, acelerar protótipos, produzir documentação, ajudar na criação de testes e permitir que equipes pequenas resolvam problemas que antes ficariam anos em uma fila de desenvolvimento.

O relatório DORA de 2025, produzido pelo Google Cloud a partir de respostas de quase 5 mil profissionais e mais de 100 horas de entrevistas, concluiu que a IA tende a ampliar as características que a equipe já possui. Times com processos sólidos conseguem obter ganhos maiores. Equipes desorganizadas acabam intensificando seus próprios problemas.

Essa talvez seja a melhor síntese do momento atual.

A IA não elimina a necessidade de engenharia. Ela aumenta a capacidade de quem já sabe definir arquitetura, testar, monitorar, documentar e responder por um sistema.

O resultado de um CRM feito com IA dependerá menos da ferramenta usada para gerar sua primeira versão e mais da estrutura existente para mantê-lo depois do lançamento.

O que uma empresa deve verificar antes de contratar

Antes de transferir sua operação comercial para um CRM novo, a empresa deve exigir respostas objetivas.

Quem é o responsável técnico pelo sistema? Existe mais de uma pessoa capaz de prestar suporte? Há contrato com prazo de atendimento e prioridade para incidentes críticos? O código está armazenado em um repositório pertencente ao cliente? Existe documentação da arquitetura e do banco de dados?

Também é necessário verificar se há ambientes separados para desenvolvimento e produção, controle de versão, autenticação multifator, níveis de permissão, histórico de alterações, monitoramento, backups automáticos e testes periódicos de restauração.

O fornecedor deve explicar como corrige vulnerabilidades, atualiza dependências e reage a mudanças nas APIs integradas. Deve informar onde os dados são hospedados, quais empresas participam do tratamento e como funciona a exportação completa das informações.

Outro ponto essencial é o plano de saída. A empresa precisa saber como continuará operando caso o fornecedor encerre as atividades, aumente os preços, abandone o produto ou deixe de responder.

Se essas perguntas não possuem respostas claras, o sistema ainda não é uma solução empresarial madura. É um protótipo em produção.

A verdadeira inovação começa depois do primeiro prompt

A inteligência artificial reduziu o custo de transformar uma ideia em uma aplicação funcional. Essa é uma mudança importante e provavelmente irreversível.

Mas a mesma facilidade que permite criar um CRM em poucos dias também facilita a publicação de sistemas sem dono, sem documentação, sem testes e sem plano de continuidade.

O perigo não está em usar inteligência artificial para desenvolver software. Está em acreditar que a IA transformou desenvolvimento em uma atividade sem responsabilidade técnica.

Um bom CRM criado com IA pode ser mais barato, rápido e adaptado ao negócio. Um CRM criado apenas por prompts pode funcionar muito bem durante a demonstração e fracassar justamente quando a empresa mais depender dele.

No mercado de software, o lançamento é apenas o começo. O produto verdadeiro é aquilo que continua funcionando, preservando os dados e recebendo suporte depois que a novidade passa.