A McKinsey publicou o State of AI 2026 e o número que saltou do relatório não foi sobre um modelo — foi sobre compra. 32% das organizações já deixaram de comprar pelo menos um software ou funcionalidade porque conseguiram construir por conta própria com ferramentas de código agêntico. Entre os high performers, o índice vai a cerca de 48% (contra 31% dos pares); por setor, tecnologia lidera com 41%, seguida de saúde (39%) e serviços profissionais e energia (38%). No mesmo estudo, a fatia de grandes empresas (acima de US$ 1 bi) escalando agentes em uma ou mais funções saltou de 27% para 40% em um ano. É o clássico build-vs-buy virando, de fato, build. Mas há um recorte que precisa entrar em toda reunião de arquitetura: construir e gerar código viraram baratos — só que o software que você constrói não nasce integrado, governado nem operável. Este artigo explica, no nível do problema, por que "build em vez de buy" não elimina o projeto: ele move o projeto de comprar-e-configurar para construir-integrar-operar — e a parte cara migrou para as duas últimas etapas.
O que a McKinsey State of AI 2026 achou (32% build-not-buy, agentes escalando 27%→40%)
O dado central do relatório é econômico, não técnico. Quase um terço das organizações relatou ter deixado de adquirir um software ou uma feature específica porque a barreira para construí-la internamente caiu o suficiente para tornar "a gente mesmo faz" a decisão racional. Não é um experimento isolado de um time de inovação — é uma escolha de aquisição que já aparece agregada num levantamento de mercado. Entre as empresas que a McKinsey classifica como high performers em IA, o número beira os 48%, sinalizando que quem opera IA com mais maturidade também é quem mais substitui compra por construção.
O segundo número reforça a direção: as grandes empresas escalando agentes em pelo menos uma função passaram de 27% para 40% no intervalo de um ano. Somados, os dois indicadores desenham uma tendência ampla e transversal de setor — não a manchete de um fornecedor. A queda no custo de gerar e montar software com agentes de código tornou a construção interna uma rota de rotina, não de exceção.
Por que agora: o código agêntico tornou "a gente faz" a rota padrão
A razão de o gráfico ter virado agora é a mesma que vem barateando toda a fronteira: as ferramentas de código agêntico — como categoria, com os principais laboratórios (Claude, Gemini, GPT e afins) em pé de igualdade — reduziram drasticamente o tempo entre "preciso de uma ferramenta interna" e "tenho um protótipo funcional". Gerar um CRUD, um painel interno, um conector inicial ou um fluxo de automação deixou de ser uma tarefa de semanas para se tornar uma de horas.
Quando o custo de produzir a primeira versão despenca, a matemática de build-vs-buy se inverte para uma classe inteira de necessidades que antes só compensava comprar. É natural e esperado. O ponto de atenção não é o entusiasmo — é o que a euforia da construção rápida esconde: um protótipo que roda na máquina de quem o gerou está a uma distância enorme de um sistema que a empresa inteira usa, que escreve nos sistemas de registro e que sobrevive a um plantão às três da manhã.
O outro lado do dado: 17% implantaram, 11% em produção — o gap de escala
O contraponto que ancora o entusiasmo vem do próprio ecossistema de dados. Enquanto a construção sobe, a colocação em produção não acompanha: levantamentos recentes apontam que apenas cerca de 17% das organizações de fato implantaram agentes de forma efetiva (Gartner) e que só 11% têm sistemas agênticos rodando em produção (Deloitte). A leitura conjunta é desconfortável e reveladora: construir subiu; colocar de pé, não.
Essa distância entre "eu construí" e "está em produção" não é aleatória — ela tem nome, e o nome é integração mais operação. O app interno que o agente gerou ainda precisa falar com o ERP, o CRM e os canais com contrato de API e garantia; ainda precisa de dado reconciliado para ler; ainda precisa de observabilidade, segurança e uma conta de custo sob controle para rodar 24 horas por dia. É exatamente esse trecho que o número de 11% expõe.
Construir ≠ integrar: o app interno ainda precisa falar com ERP, CRM e canais
A primeira metade cara que o "build" não entrega sozinho é a integração. Um software interno só cria valor quando participa dos processos reais da empresa — e isso significa ler e escrever nos sistemas de registro. É aqui que a maioria dos protótipos empaca. Escrever num ERP com garantia exige uma porta de escrita contratada: um contrato de API que valida, autoriza e registra cada ação, em vez de o app tocar direto no banco. Exige idempotência, para que um retry não vire dois pedidos ou dois estornos. Exige uma arquitetura orientada a eventos, com filas como Kafka ou RabbitMQ, que desacople o app dos sistemas de destino e garanta entrega mesmo quando o ERP está lento ou fora do ar.
Nenhuma dessas peças aparece quando você gera o app. Elas são engenharia de integração — a mesma engenharia que o SaaS que você deixou de comprar resolvia por baixo, invisível, embutida no preço da assinatura. Ao trocar buy por build, você ganhou a velocidade de construir a interface e a lógica; e recuperou, por inteiro, o problema de conectar tudo isso ao resto da empresa.
Construir ≠ operar: o run cost do que você criou (observabilidade, segurança, SRE)
A segunda metade cara é a operação. Depois de integrado, o software precisa rodar de forma confiável — e alguém precisa saber quando ele cai. Isso é observabilidade (métricas, logs, tracing distribuído, alertas), é segurança (conector com menor privilégio, escopo, trilha de auditoria, gestão de segredos) e é a disciplina de SRE que mantém um sistema de pé sob carga real.
Há também a conta que ninguém projeta no entusiasmo inicial: o run cost. Um agente ou app interno que roda continuamente consome computação, chamadas de modelo e infraestrutura — e essa despesa, que no SaaS estava diluída na mensalidade, agora aparece nominalmente na sua fatura de nuvem. Operar o que você construiu tem custo recorrente e exige gente que saiba mantê-lo. É a parte menos glamorosa de "a gente mesmo faz" e, não por acaso, a que mais separa os 11% que estão em produção dos demais.
Build-not-buy sem integração = o novo shadow IT
Quando a construção interna escala sem a camada de integração e operação, o resultado previsível é uma versão moderna do shadow IT: um acúmulo de ferramentas internas meio-integradas, cada uma resolvendo um pedaço, nenhuma verdadeiramente conectada aos sistemas de registro, e ninguém claramente responsável por operá-las. No começo parece produtividade. Com o tempo, vira um cemitério de apps que dependem de uma pessoa específica, quebram silenciosamente e duplicam dado.
O risco não está em construir — está em construir sem tratar a construção como o início de um sistema, e não como o fim. Uma ferramenta interna que não é observável, não é segura e não conversa com o resto do negócio é passivo, não ativo. E passivos meio-integrados se multiplicam com a mesma facilidade com que agora se constroem.
A decisão real não é build vs buy: é construir-integrar-operar vs comprar pronto
O enquadramento honesto da escolha, em 2026, não é "construir ou comprar". É construir-integrar-operar de um lado e comprar pronto do outro. Quando você compra um SaaS, está pagando não só pela funcionalidade, mas pela integração mantida, pela operação 24/7, pela segurança e pela evolução contínua — tudo embutido. Quando decide construir, assume conscientemente essas três frentes.
Isso não torna o "build" errado — em muitos casos é a decisão certa, e o dado da McKinsey mostra por que virou tão comum. Torna, sim, obrigatório dimensionar o projeto pelo custo real: a construção é a ponta barata; integração e operação são o corpo do investimento. Quem decide construir olhando só para a velocidade de gerar o protótipo está subestimando exatamente a parte que os números de produção revelam ser a mais difícil.
Checklist: 7 perguntas antes de trocar um SaaS por um agente interno
- 1. O app interno vai precisar escrever num sistema de registro (ERP, CRM, financeiro)? Se sim, existe porta de escrita contratada e idempotente?
- 2. Há arquitetura event-driven (Kafka/RabbitMQ) prevista entre o app e os sistemas de destino, ou ele vai chamar tudo de forma síncrona e frágil?
- 3. O dado que o app precisa ler está unificado e reconciliado, ou espalhado por vários sistemas?
- 4. Existe reconciliação conferindo que o que o app decidiu de fato aconteceu no sistema de registro?
- 5. Quem vai operar isso em produção — observabilidade, alertas, plantão — quando o time que construiu passar para o próximo projeto?
- 6. O run cost (nuvem, chamadas de modelo, infraestrutura) foi estimado e comparado com a assinatura do SaaS que você deixaria de pagar?
- 7. O conector respeita menor privilégio, com escopo e trilha de auditoria — ou vai virar um risco de segurança silencioso?
Se a maioria das respostas for "ainda não pensamos nisso", o "build" está sendo dimensionado só pela ponta barata. As perguntas 1 a 7 descrevem, na prática, o projeto que resta depois que o código fica pronto.
Como a CCX constrói, integra e opera o que você decidiu não comprar
A CCX trata "build em vez de buy" como o que ele realmente é: uma decisão de assumir integração e operação, não apenas construção. Na frente de Integrações & APIs Enterprise, montamos a camada que o "build" não cobre — porta de escrita contratada e idempotente sobre arquitetura event-driven com Kafka e RabbitMQ, conectando o seu app interno a ERP, CRM, gateways de pagamento e canais via REST, GraphQL e gRPC. É a metade cara que transforma um protótipo gerado em software que age no seu processo com garantia.
Quando falta capacidade de engenharia para construir, integrar e operar sem virar shadow IT, as Squads Dedicadas e On-Demand entram com engenheiros sêniores full-stack e onboarding em 48h, com escala elástica conforme o projeto. E para a operação 24/7 do que você criou, a Observabilidade 360° instrumenta tudo com Datadog, Grafana, Prometheus, Sentry e tracing distribuído via OpenTelemetry — para o run cost ser medido e o sistema não cair no escuro.
Construir ficou barato; integrar e operar o que você construiu, não. Implementar IA no meu negócio → A CCX entrega a metade que o "build" não cobre — a integração com contrato de API e event-driven, o squad sênior que constrói, conecta e roda em produção, e o dado reconciliado e o run cost sob controle.
FAQ (People Also Ask)
O que o McKinsey State of AI 2026 diz sobre build vs buy? Que 32% das organizações já deixaram de comprar pelo menos um software ou feature porque conseguem construir internamente com ferramentas de código agêntico — chegando a cerca de 48% entre os high performers. E que grandes empresas escalando agentes passaram de 27% para 40% em um ano.
Se construir ficou tão barato, por que só 11% dos agentes chegam à produção? Porque a construção é a etapa barata. O que separa o protótipo da produção é integração (escrever nos sistemas de registro com garantia, ler dado reconciliado) e operação (observabilidade, segurança, run cost) — e essas duas não barateiam quando a construção barateia.
Quando faz sentido construir em vez de comprar? Quando a necessidade é específica o suficiente para não ter um SaaS que a resolva bem, e quando a empresa está disposta a dimensionar o projeto pelo custo real: construir-integrar-operar, não só construir. Se não houver plano para integração e operação, comprar pronto costuma sair mais barato no total.