Sistema de IA sob medida ou pronto: como decidir entre comprar e construir

A pergunta chega quase sempre na mesma forma: 'existe uma ferramenta que faça isso ou a gente precisa desenvolver?'. Ela parece uma decisão técnica, mas é uma decisão de estratégia. Comprar significa aceitar o processo que o fornecedor desenhou. Construir significa assumir, para sempre, a responsabilidade de manter aquilo funcionando. As duas escolhas custam caro quando feitas pelo motivo errado.

O erro mais comum não é escolher o lado errado — é decidir sem critério, por entusiasmo ou por medo. Empresas constroem do zero o que poderiam ter assinado por uma fração do custo, e empresas assinam ferramentas que jamais vão se encaixar no jeito como elas realmente trabalham. Este texto propõe critérios objetivos para separar os dois casos.

Quando a ferramenta pronta resolve e você não deve construir nada

A regra de partida é simples: se o processo é igual ao do resto do mercado, comprar é quase sempre a decisão certa. Ninguém ganha vantagem competitiva por ter um transcritor de reuniões próprio. O valor está no resultado, não em quem escreveu o código.

• O processo é padrão de mercado: transcrição e resumo de reuniões, revisão de texto, geração de imagens, tradução, correção de código.
• O volume ainda é pequeno ou incerto — você está testando se o ganho existe antes de investir em algo permanente.
• A empresa não tem time técnico próprio nem quer criar dependência de um fornecedor de desenvolvimento.
• O dado envolvido não é sensível, ou a ferramenta oferece plano empresarial com garantia contratual de não uso para treinamento.
• O prazo importa mais que o encaixe perfeito: você precisa de 80% do resultado em duas semanas, não de 100% em seis meses.

Há também um argumento pouco lembrado a favor do pronto: fornecedores de SaaS de IA melhoram o produto sem cobrar por isso. Quando surge um modelo melhor, eles trocam. Quem construiu sozinho precisa fazer essa migração com as próprias mãos, e ela não é trivial — trocar de modelo muda o comportamento de todos os prompts que já estavam validados.

Quando o pronto não serve

Existem quatro situações em que insistir na ferramenta pronta gera frustração previsível. Elas não são exclusivas: quanto mais delas se aplicarem ao seu caso, mais forte fica o argumento por construir.

O processo é o seu diferencial competitivo

Se o jeito como sua empresa faz aquela etapa é parte do motivo pelo qual os clientes escolhem você, terceirizar isso para um produto de prateleira significa nivelar-se ao mercado. Uma seguradora com um método próprio de análise de risco, uma consultoria com uma metodologia de diagnóstico, uma indústria com um critério de qualidade que os concorrentes não replicam: nesses casos, o software precisa acompanhar o método, não o contrário.

Os dados não podem sair da empresa

Prontuários, dados financeiros de terceiros, informação sob sigilo contratual, segredo industrial. Em alguns setores, a restrição é regulatória; em outros, é cláusula de contrato com o cliente. Vale checar antes de descartar o pronto: muitos fornecedores oferecem processamento em região específica, retenção zero e acordos de confidencialidade que atendem à exigência. Mas quando a exigência é que o dado não trafegue para fora da infraestrutura da empresa, a lista de ferramentas prontas encolhe muito rápido.

A integração com o sistema legado é profunda

Este é o motivo mais subestimado. A IA só entrega valor quando tem acesso ao contexto real da operação — o ERP, o sistema de gestão feito sob medida em 2011, o banco de dados que ninguém documentou. Ferramentas prontas integram bem com o que é popular e mal com o que é seu. Se o valor depende de ler e escrever em um sistema que não tem API pública, a camada de integração vai precisar ser construída de qualquer forma.

O custo por usuário deixa de escalar

SaaS de IA costuma cobrar por assento. O modelo funciona bem para vinte pessoas e começa a incomodar em duzentas. Quando a ferramenta precisa chegar a toda a operação — inclusive a quem usa cinco minutos por semana — o preço por assento vira um imposto sobre a adoção, e as áreas passam a limitar quem tem acesso. Nesse ponto, o cálculo de construir muda: o custo de desenvolvimento é fixo, o de licença não.

O caminho híbrido, que é o mais comum na prática

A discussão 'comprar ou construir' é apresentada como binária e quase nunca é. O que a maioria das empresas efetivamente faz — e o que costuma dar mais certo — é comprar a infraestrutura e construir só a camada fina onde está o conhecimento próprio.

Na prática isso significa: o modelo de linguagem vem de um fornecedor (Claude, da Anthropic, ou outro provedor), a interface e os conectores vêm de uma plataforma pronta, e a empresa desenvolve o que ninguém pode desenvolver por ela — os prompts que codificam o método interno, a base de conhecimento com os documentos reais, as regras de quando escalar para uma pessoa e as integrações com os sistemas próprios.

• Compre: modelo, hospedagem, interface de conversa, controle de acesso, registro de uso, ferramentas de avaliação.
• Construa: prompts do seu método, base de conhecimento própria, regras de negócio, integrações com o legado, critérios de escalonamento humano.
• Nunca construa do zero: autenticação, infraestrutura de modelo, interface de chat — isso é commodity resolvida.

A vantagem do híbrido é que ele preserva a possibilidade de mudar de ideia. A camada que você construiu — prompts, base de conhecimento, regras — é portátil. Se o fornecedor piorar, subir preço ou sair do mercado, você troca a infraestrutura e leva o seu conhecimento junto. É exatamente isso que o modelo puramente comprado não permite.

Comparação direta pelos critérios que importam

O risco de lock-in do fornecedor

Lock-in não aparece no primeiro ano. Ele aparece quando a ferramenta já virou parte da operação, o histórico de dois anos está lá dentro, quarenta pessoas aprenderam a usar e o preço de renovação sobe. A partir daí, negociar fica difícil porque o custo de sair é real.

• Lock-in de dados: seu histórico, suas configurações e sua base de conhecimento estão em um formato que só aquela ferramenta lê.
• Lock-in de processo: a equipe reorganizou o trabalho ao redor do produto, e mudar significa retreinar todo mundo.
• Lock-in de modelo: a ferramenta esconde qual modelo usa e você não controla quando ele muda — nem consegue avaliar se piorou.
• Lock-in de integração: outros sistemas passaram a depender daquela ferramenta como fonte de dados.

O risco oposto: construir e não conseguir manter

O cemitério de projetos internos de IA está cheio de sistemas que funcionaram muito bem por três meses. O problema quase nunca é o código. É que sistemas de IA se degradam de um jeito silencioso e específico: a base de conhecimento envelhece, a política mudou e ninguém atualizou o documento, o modelo foi trocado e os prompts passaram a se comportar diferente, alguém entrou com um caso de uso novo que nunca foi testado.

Diferente de um software tradicional, um sistema de IA que degrada não quebra — ele continua respondendo, só que pior. Ninguém abre um chamado, as pessoas simplesmente param de usar. Quando alguém percebe, a confiança já se perdeu.

Por isso o critério de decisão mais honesto não é 'temos orçamento para construir?', e sim 'temos alguém que vai ser dono disso daqui a um ano?'. Se não houver nome e sobrenome para essa função, com tempo alocado, a ferramenta pronta é a escolha mais responsável — mesmo que se encaixe pior.

Como decidir na prática

Atue como consultor de tecnologia, cético e direto. Vou descrever um processo da minha empresa e quero uma recomendação entre comprar uma ferramenta pronta, construir sob medida ou adotar um modelo híbrido.

CONTEXTO:
- Processo: [descreva como o trabalho acontece hoje]
- Quem executa e com que frequência: [descreva]
- Sistemas envolvidos: [liste, indicando quais têm API]
- Sensibilidade dos dados: [descreva restrições legais ou contratuais]
- Pessoas que precisariam de acesso hoje e em 2 anos: [números]
- Time técnico interno disponível: [descreva ou diga que não existe]

TAREFA:
1. Classifique o processo como commodity de mercado ou diferencial competitivo, e justifique.
2. Liste as restrições duras que eliminam alguma das opções.
3. Recomende um caminho e explique em que condição a recomendação mudaria.
4. Se a recomendação for híbrido, diga exatamente o que comprar e o que construir.
5. Aponte os três maiores riscos da sua própria recomendação.
6. Liste as perguntas que eu ainda não sei responder e que mudariam a análise.

Não suavize. Se a informação que dei for insuficiente, diga isso antes de recomendar.

O que perguntar a um fornecedor de SaaS de IA antes de assinar

A demonstração comercial sempre funciona — ela foi ensaiada com os casos que dão certo. As perguntas abaixo servem para descobrir o que a demonstração não mostra. Anote as respostas e peça que as relevantes entrem no contrato.

1. 1Meus dados são usados para treinar modelos de vocês ou de terceiros? Isso está escrito no contrato ou só na página de marketing?
2. 2Onde os dados são processados e armazenados, em que país, e por quanto tempo ficam retidos após eu apagar?
3. 3Qual modelo está por trás do produto? Vocês avisam quando trocam, e eu posso testar antes da troca valer para todos?
4. 4Como eu exporto tudo — histórico, configurações, base de conhecimento — em formato aberto, e quanto custa fazer isso?
5. 5Que controle eu tenho sobre o que o sistema pode e não pode responder? Consigo definir regras próprias ou só ligar e desligar recursos?
6. 6Como funciona a integração com sistemas sem API pública? Existe caso real de cliente com legado parecido com o meu?
7. 7Como o preço evolui com o número de usuários e com o volume de uso? Qual foi o reajuste médio praticado nas últimas renovações?
8. 8Que métricas de qualidade vocês expõem para eu auditar as respostas — e consigo ver os casos em que o sistema errou?
9. 9Qual o compromisso de disponibilidade e o que acontece na prática quando o serviço cai no meio do expediente?
10. 10Quem é o subprocessador de IA e como isso aparece no meu mapeamento para a LGPD?

A decisão que quase sempre está certa

Comece comprando. Use por tempo suficiente para descobrir onde a ferramenta pronta encosta no limite — e ela vai encostar, sempre no mesmo lugar: onde o seu processo é diferente do processo genérico. Construa só ali, e mantenha essa camada portátil.

Essa sequência protege contra os dois erros caros. Evita construir do zero algo que já existia melhor e mais barato, e evita ficar preso a um produto que nunca vai acomodar o que a sua empresa tem de próprio. A pergunta final não é 'comprar ou construir', é 'em que parte específica deste processo mora a nossa vantagem?'.

“Tecnologia genérica entrega paridade. Vantagem competitiva vem do que você faz em cima dela.”

— Inteligência Artificial para Negócios