Build vs buy para features de IA

O roadmap tinha seis features de IA. Engenharia queria construir pipelines RAG custom, classificadores fine-tuned e um framework de eval in-house. Vendas queria demos enviadas no trimestre passado. Finanças rodou os números: inferência no uso projetado apagou quarenta pontos de margem bruta no tier onde a IA era o destaque. Build vs buy para features de IA não é religião tecnológica. É cálculo de margem e moat — construir o que diferencia e compõe; comprar ou empacotar o que usuários esperam como table stakes; nunca construir inteligência commodity sobre infraestrutura custom salvo que a economia unitária prove sustentabilidade.

Cada feature de IA carrega custo contínuo — tokens, GPUs, labeling, eval, resposta a incidentes quando modelos se comportam mal. Build multiplica esse custo com headcount de engenharia. Buy concentra em faturas de vendor. Nenhum é grátis. A pergunta é onde vive a vantagem competitiva e se preço por uso deixa margem para lucro.

O frame de decisão: moat, margem e controle

Factor	Build lean	Buy lean
Differentiation	Core na história do produto	Commodity ("resumo com IA")
Gross margin at scale	Margem absorve inferência + eng	Preço vendor × uso encaixa no modelo COGS
Data advantage	Flywheel proprietário justifica custom	Capacidade genérica, sem dados únicos
Time to market	Pode esperar trimestres	Precisa shipped neste trimestre
Compliance	Dados não podem sair do boundary	Vendor atende certificações
Customization depth	Workflow único ao domínio	Tarefa LLM padrão

O reset da margem bruta em IA aplica antes de decisões de build — se o COGS de inferência quebra o modelo de pricing, construir mais superfície de IA aprofunda o buraco. Corrigir pricing e economia unitária antes de debater build vs buy.

Construir um wrapper sobre OpenAI não é moat. É conta de hosting com logo.

O que "buy" significa em IA (espectro)

Buy não é só "usar SaaS de vendor." Espectro:

1. Raw model API. Mais rápido; menos diferenciado. Apropriado para ferramentas internas, protótipos, features não core.

2. Managed AI services. Parsing de documentos, moderação, speech — o vendor possui o ciclo de vida do modelo. Apropriado quando a capacidade é padrão e SLAs importam.

3. Platform bundles. Suites de IA do cloud provider — troca portabilidade por billing integrado e compliance.

4. Acquisition / OEM. Embed white-label do vendor — velocidade com risco de marca.

5. Partner integration. Listing em marketplace — revenue share, controle limitado.

Build fica no final: modelos custom, pipelines proprietários, orquestração de agentes única atada a data loops de produto que competidores não podem replicar.

O que merece investimento em build

Build quando todos os seguintes se cumprem:

• A feature está no caminho crítico de por que clientes escolhem este produto sobre alternativas.
• Dados ou feedback proprietários melhoram a feature de formas que vendors não podem acessar.
• A economia unitária funciona a 3× do uso projetado — não uso de demo.
• O time pode possuir eval, safety e regressão — não ship v1 e ir embora.
• Opções de buy exigiriam customização inaceitável ou lock-in pior que o custo interno.

Exemplos que frequentemente justificam build: agente específico de domínio que executa workflows core do produto, recomendação impulsionada por dataset comportamental único, pipeline sensível a compliance onde o manejo de dados do vendor falha auditoria.

Exemplos que raramente justificam build: resumo genérico, chatbot padrão sobre docs públicos, geração de imagens para assets de marketing, correção ortográfica.

Custos ocultos de build que equipes subestimam

Cost line	Build impact
Inference at scale	Frequentemente 10–100× o custo do protótipo
Eval and regression	Labeling contínuo, revisão humana
Model deprecation	Upgrades do modelo base quebram prompts/tuning
Incident response	Respostas erradas são incidentes de produto
Security review	Prompt injection, rotas de vazamento de dados
Opportunity cost	Os mesmos engenheiros não enviam produto core

Qualidade de retrieval em RAG antes de training custom — decisões de build frequentemente assumem que o stack custom é necessário quando retrieval e prompts não estão esgotados.

Fine-tuning como último recurso — build raramente começa com training; quando build inclui fine-tuning, orçar retraining como linha recorrente.

Padrão híbrido: comprar infraestrutura, construir workflow

A maioria do SaaS aterrissa aqui:

• Comprar API de inferência de modelo.
• Construir workflow de produto, UI, permissões, auditoria, integrações.
• Construir eval em tarefas proprietárias.
• Comprar monitoring para a camada de modelo onde for suficiente.

A diferenciação é workflow + dados + confiança, não hospedar o transformer. Clientes pagam por outcomes dentro do produto, não por rodar pesos de forma ligeiramente diferente de um vendor.

Como produto e engenharia devem decidir build vs buy?

Estas perguntas forçam tradeoffs explícitos antes do compromisso de roadmap.

Quando "build" significa fine-tune vs full stack?

Fine-tuning é build-light; ownership de pipeline completo é build-heavy. Ajustar investimento à força do moat — fine-tune para estabilidade de formato em dados proprietários; não fine-tunar resumo commodity.

O pricing absorve IA comprada em escala?

Modelar COGS do vendor de modelo no pricing antes da reunião build vs buy. Se buy quebra margem, build costuma quebrar pior salvo que build reduza materialmente o custo de inferência por unidade.

Qual é o plano de saída se os termos do vendor mudarem?

Para buy: portabilidade de dados, routing alternativo de modelos, termos contratuais. Para build: dependência do modelo base, ownership de training data, rollback para modelo API se o stack interno falhar.

Uma visão oposta

Um argumento persistente sustenta que buy cria dependência de vendor e homogeneidade de features — que toda empresa de produto séria deve possuir o stack de IA para vencer.

A dependência é real — mitigar com camadas de abstração e routing multi-modelo. A homogeneidade é real para features commodity — exatamente por isso buy é racional ali. O moat vem de dados, distribuição, embedding de workflow e confiança — não de self-hostear o mesmo modelo open-weight que competidores podem hospedar.

Empresas que constroem tudo em IA frequentemente enviam mais devagar e com pior margem que competidores que compraram camadas commodity e investiram orçamento de build em produto core.

O que importa lembrar

• Build vs buy para IA é margem e moat — não preferência de engenharia.
• Comprar capacidades commodity; construir onde dados proprietários e workflow diferenciam.
• O COGS de inferência deve encaixar no pricing a 3× do uso projetado antes de construir.
• Custos ocultos de build: eval, incidentes, depreciação de modelo, segurança, custo de oportunidade.
• Híbrido é o default: comprar inferência, construir workflow, permissões e integração de produto.
• Fine-tuning e RAG custom são paths de build — esgotar primeiro alavancas mais baratas.

Conclusão

Build vs buy para features de IA se resume a uma pergunta: se um competidor usasse o mesmo vendor amanhã, os clientes ainda escolheriam este produto? Sim — construir o workflow e o data loop. Não — está-se debatendo infraestrutura para um checkbox commodity.

Rodar o modelo de margem antes da revisão de arquitetura. A reunião de build que pula finanças se repete como emergência de margem bruta no próximo ano fiscal.