Compre a velocidade, construa a vantagem: as três perguntas que resolvem o build vs. buy de IA

O debate "build vs. buy" em IA está sendo travado com a régua errada. Gestores comparam licença de SaaS com orçamento de squad e acham que fizeram análise. Não fizeram. Compararam preços de entrada de dois produtos diferentes — e ignoraram as três variáveis que realmente decidem o jogo: de quem é o dado, quem carrega o risco regulatório e quem paga o custo recorrente que não aparece na proposta.

A tese é simples: compre tudo que é commodity, construa apenas o que é vantagem competitiva — e trate os dois degraus do meio como o lugar onde a maioria das empresas deveria estar.

O espectro tem quatro degraus, não dois

A escolha binária morreu. Em 2026, o mercado opera num espectro de quatro caminhos, e cada um tem um caso emblemático.

No extremo do "comprar", a editora científica Wiley adotou o Salesforce Agentforce — agentes de IA nativos do CRM que já usava — e passou a resolver mais de 40% das dúvidas de suporte sem escrever uma linha de código. Um degrau acima, operações de logística de médio porte usam Make.com ou Power Automate com módulos de IA para extrair dados de CT-e recebidos por e-mail e jogar direto no ERP, sem desenvolvedor dedicado.

No terceiro degrau, a Klarna integrou a API da OpenAI aos seus sistemas internos de dados de clientes e políticas de reembolso. Não treinou modelo nenhum — e mesmo assim o assistente fez o trabalho equivalente a 700 agentes humanos no primeiro mês. No extremo do "construir", o JPMorgan desenvolveu o IndexGPT, plataforma proprietária de análise de investimentos, com patentes registradas — porque no negócio dele, o algoritmo é o produto.

Quatro empresas, quatro respostas corretas. O que muda não é a tecnologia. É a resposta a três perguntas.

Pergunta 1: isso é diferencial ou commodity?

A pergunta mais mal respondida do mercado. O teste é objetivo: se seu concorrente fizer exatamente igual, você perde dinheiro? Se a resposta for não, é commodity. Compre.

O Itaú aplica esse filtro com disciplina rara. Para produtividade geral e atendimento básico, o banco usa soluções prontas como o Microsoft Copilot. Para crédito e detecção de fraude — onde o modelo é a margem — desenvolve internamente, sobre nuvem híbrida, sob as regras do Banco Central e da LGPD. A Petrobras vai além: roda modelos proprietários de interpretação sísmica nos supercomputadores Dragão e Pégaso, porque dado geológico do Pré-Sal é o maior ativo comercial da companhia e não passa pela API de ninguém.

O erro comum é o inverso: construir atendimento ao cliente do zero (commodity) e comprar SaaS genérico para o processo que diferencia a empresa. É gastar caro onde não importa e terceirizar exatamente o que importa.

E atenção: "construir" em 2026 não significa treinar modelo. Segundo o Gartner, customizar um modelo existente via RAG ou fine-tuning custa em média 80% menos do que treinar um proprietário do zero — empreitada que passa fácil dos US$ 10 milhões só em poder computacional. Build hoje é arquitetura de agentes, pipeline de dados e integração proprietária sobre modelos que já existem.

Pergunta 2: quem carrega o risco regulatório?

Essa pergunta quase nunca entra na planilha — e no Brasil ela vale dinheiro. O PL 2338/2023 classifica sistemas de IA por nível de risco. Quem constrói solução própria para recrutamento, análise de crédito ou saúde assume integralmente a responsabilidade civil, os relatórios de impacto e as auditorias algorítmicas que a lei exige. Quem compra de um fornecedor consolidado consegue, contratualmente, transferir ou compartilhar parte dessa carga.

Isso inverte intuições. Um sistema de triagem de currículos parece candidato óbvio a build barato com API — até você perceber que acaba de assumir sozinho uma obrigação de auditoria algorítmica. Às vezes o SaaS mais caro é o seguro mais barato. E às vezes é o contrário: no caso do JPMorgan, a regulação severa do setor financeiro foi justamente um dos motivos para construir — porque dado confidencial de mercado em API de terceiro é risco que nenhum contrato mitiga.

A regra: risco regulatório alto com dado sensível proprietário empurra para o build. Risco alto com processo genérico empurra para o buy com contrato bem escrito.

Pergunta 3: você está comparando preço de entrada ou custo de ficar?

A McKinsey estima que colocar uma solução em produção via SaaS ou API leva de 1 a 3 semanas, contra 6 a 12 meses de um software AI-native interno. E a BCG encontrou algo mais brutal: cerca de 50% das iniciativas de build complexo morrem antes de sair da prova de conceito — não por falta de modelo, mas por débito de dados e escassez de talento.

Só que o buy também tem conta escondida. Quem integra via API fica exposto a atualizações silenciosas do provedor: o modelo muda, o comportamento muda, e sua equipe gasta horas refazendo testes de regressão e reajustando prompts. A manutenção de IA não é estática como a de software tradicional — e essa conta corrói parte da economia inicial do "customize". No Brasil, some a dolarização: inferência em nuvem americana oscila com o câmbio, o que explica o interesse crescente por modelos menores (SLMs) hospedados em datacenters nacionais.

O framework, condensado:

• Commodity + baixo risco: SaaS pronto. Velocidade acima de tudo.
• Commodity + processo específico seu: low-code com IA. A IDC projeta que 45% das empresas do G2000 usarão essa via para fluxos críticos até o fim de 2026.
• Diferencial moderado + dado proprietário: API + RAG. O melhor custo-benefício do espectro — desde que você orce o monitoramento contínuo.
• Diferencial central + dado que é seu ativo + regulação pesada: AI-native sob medida. Caro, lento, e às vezes a única resposta certa.

O que isso significa para empresas brasileiras

Primeiro: pare de fazer a pergunta "build ou buy" no plural da empresa. Faça-a por processo. O Itaú não escolheu um lado — segmentou. Sua empresa também deveria: Copilot para o e-mail, low-code para a nota fiscal, RAG para o conhecimento proprietário, build para o que — e só o que — sustenta sua margem.

Segundo: no Brasil, a Pergunta 2 pesa mais do que lá fora. Com o PL 2338 desenhando responsabilidades por nível de risco, a decisão de construir em RH, crédito ou saúde é também uma decisão jurídica. Envolva quem entende de compliance antes de envolver quem entende de Python.

Terceiro: a estatística da BCG — metade dos builds morre na PoC — não é argumento contra construir. É argumento contra construir sem dado governado e sem gente qualificada. Se seu diferencial exige build e você não tem o time, a resposta não é desistir nem comprar SaaS genérico: é construir com quem faz isso todo dia.

A vantagem competitiva em IA não está em qual degrau você escolhe. Está em escolher o degrau certo para cada processo — e em saber, antes de assinar qualquer contrato, quem fica com o dado, quem fica com o risco e quem fica com a conta.