Make vs. buy na era da IA: quando construir e quando comprar um software

Com IA generativa e agentes de código, criar software ficou mais barato, tornando mais tentador construir sistemas próprios, seja internamente ou com consultorias e software houses.

O artigo “The End of One-Size-Fits-All Enterprise Software” (“O Fim do Software Empresarial de Tamanho Único”, em tradução livre), publicado na revista Harvard Business Review, argumenta que a IA está desmontando parte da lógica econômica que tornou o software empresarial padronizado a escolha dominante.

Mas ficou mais fácil criar a primeira versão de um software, não necessariamente operá-lo, protegê-lo, integrá-lo e evoluí-lo. O estudo “The Buy-or-Build Decision, Revisited: How Agentic AI Changes the Economics of Enterprise Software” (“A Decisão de Comprar ou Construir, Revisitada: Como a IA Agêntica Altera a Economia do Software Corporativo”, em tradução livre), considera exagerada a tese de uma “SaaSocalypse”.

Isso nos leva à pergunta: Só porque ficou mais fácil construir software, significa que vale a pena construir tudo?

A resposta passa por 6 fatores: custo total, tempo para gerar valor, diferenciação estratégica, segurança, capacidade de evolução e estrutura interna para sustentar a solução.

O framework expõe 3 riscos frequentemente ignorados no make.

Leia também: Quando a IA compra por você, quem garante a segurança?

Risco 1: subestimar o custo total e criar dependências

O erro mais comum é tratar o custo da primeira versão como custo total. O orçamento inicial raramente inclui correção de bugs, suporte, observabilidade, hospedagem, armazenamento, testes, documentação, segurança e novas integrações.

Além do custo, há dependência. No desenvolvimento interno, conhecimento crítico pode ficar concentrado em quem criou a solução. Se essas pessoas saírem, corrigir ou alterar o sistema pode se tornar lento e arriscado — sobretudo sem documentação, testes automatizados e padrões de arquitetura. Na construção terceirizada, a dependência migra para o parceiro, especialmente se o contrato não definir propriedade do código, documentação, portabilidade, níveis de serviço e transição.

Risco 2: tratar segurança e governança como funcionalidades posteriores

Soluções criadas rapidamente costumam priorizar o fluxo principal: receber dados, processá-los e apresentar uma resposta. Segurança e governança aparecem depois.

Uma solução corporativa precisa considerar autenticação, perfis e permissões, criptografia, registros de auditoria, backups, gestão de vulnerabilidades e resposta a incidentes. Em sistemas de RH, por exemplo, isso é especialmente sensível porque um acesso indevido pode expor salários e outras informações confidenciais.

Casos recentes mostram que esses riscos são reais. Um agente da Replit apagou uma base de produção durante um code freeze; pesquisadores identificaram que o Grok Build enviava repositórios Git inteiros para a nuvem; e uma vulnerabilidade no Claude Code permitia, sob condições específicas, escapar de seu sandbox.

O risco é a falsa sensação de completude de uma aplicação que funciona em uma demonstração, mas ainda não possui os controles necessários para operar em produção.

Risco 3: construir tecnologia sem expertise em produto

Construir um produto envolve compreender o problema, simplificar o fluxo, definir arquitetura de dados, desenhar permissões, antecipar exceções e criar uma experiência compreensível.

Times internos podem dominar o processo, mas não necessariamente possuem as competências de produto, UX e engenharia. Com isso, alguns problemas se repetem:

• requisitos importantes só aparecem quando o sistema entra em uso;

• casos-limite não são considerados;

• estrutura de dados dificulta relatórios, integrações e futuras evoluções;

• a experiência reproduz a complexidade do processo;

• controles são implementados apenas na interface, sem proteção no back-end;

Sem compreensão integral da arquitetura e sem validação do código, cada alteração pode gerar efeitos inesperados e elevar o custo de manutenção.

Afinal, quando faz sentido construir?

A IA facilitou criar aplicações que funcionam em demonstrações, mas não necessariamente operar e sustentar produtos. Entre um protótipo e um sistema corporativo há integrações, permissões, segurança, testes, suporte, documentação, monitoramento e anos de manutenção. Ignorar essa distância pode deixar a empresa com dados expostos, decisões baseadas em resultados pouco confiáveis, custos crescentes e uma solução difícil de evoluir com segurança.

O make faz sentido quando três condições coexistem: o mercado não atende bem à necessidade; controlar o processo gera diferenciação estratégica; e a empresa tem capacidade e disposição para assumir todo o ciclo de vida do produto.

O buy tende a ser superior quando o problema é comum, há urgência para gerar valor, os dados ou processos são críticos e a empresa não deseja transformar a manutenção daquele software em uma competência própria.

A pergunta central não é “a IA consegue construir isso?”. Para cada vez mais casos, a resposta será sim. A questão é: quando a primeira versão estiver pronta, sua empresa estará preparada para assumir o que vem depois, com seus riscos e implicações?

A IA tornou mais barato produzir código. Não tornou mais baratas as consequências de um software ruim. Nos próximos anos, a vantagem não estará em quem construir mais sistemas, mas em quem souber exatamente quais sistemas vale a pena construir.

Siga o IT Forum no LinkedIn e fique por dentro de todas as notícias!