A tese numa frase: a escolha entre IA open source e API fechada quase nunca se joga onde as pessoas pensam. Não é uma batalha de princípios entre «liberdade» e «lock-in». É uma decisão de engenharia com dois relógios —custo à escala e sensibilidade do dado— e para a esmagadora maioria das empresas a resposta certa no primeiro dia não é a ideológica. Este artigo é sobre quando importa de verdade e quando, sinceramente, é indiferente.
IA open source vs API fechada na tua empresa: a maioria põe a pergunta ao contrário
A conversa chega quase sempre viciada. Alguém da equipa leu que Llama, Mistral ou DeepSeek são modelos abertos, que podes descarregá-los e pô-los a correr «em casa», e de repente a pergunta deixa de ser «do que precisa o meu negócio?» para passar a «somos dos que dependem da OpenAI ou dos que se auto-alojam?». Isto não é uma decisão técnica: é identidade. E as decisões de identidade defendem-se com orgulho, não com dados.
A pergunta útil é bem mais aborrecida: para o problema concreto que queres resolver, o que te dá cada opção e o que te custa cada uma —em dinheiro, em tempo da tua equipa, em risco? Posta assim, a bandeira cai sozinha e aparece o que de facto decide: o volume a que vais chamar o modelo e o quão delicado é o dado que lhe vais dar.
O que cada opção te dá de verdade (sem a bandeira)
API fechada: velocidade e zero manutenção
Uma API fechada —OpenAI, Anthropic, Google— é uma chamada de rede. Não aprovisionas GPUs, não fazes patch a drivers, não te preocupas que o modelo caia às três da manhã. Pagas ao token, arrancas em minutos, e o fornecedor melhora o modelo por baixo sem que toques em nada. Em troca, o dado sai do teu perímetro para o dele (com contrato pelo meio), o custo unitário fixa-o outro e ficas preso ao roadmap dele e à sua política de preços. Compras velocidade e tranquilidade; alugas o controlo.
Open source: controlo e custo à escala, em troca de canalização
Um modelo aberto que corres tu —na tua cloud ou no teu hardware— dá-te o contrário: o dado não sai de onde tu disseres, o custo por milhão de tokens a alto volume pode desabar, e ninguém te deprecia o modelo de surpresa. O preço disto é que agora a infraestrutura é tua: servir o modelo, escalá-lo, monitorizá-lo, atualizá-lo e responder quando parte é trabalho da tua equipa, para sempre. Não é «mais barato»: estás a trocar uma fatura de fornecedor por um salário de engenharia. Para quem tem volume e pessoal, compensa; para quem não tem, é um poço.
| Eixo | API fechada | Open source (auto-alojado) |
|---|---|---|
| Arranque | Minutos | Semanas de setup |
| Onde vive o dado | No fornecedor (com contrato) | Onde decidires |
| Custo | Ao token, fixa-o o fornecedor | Fixo (infra + equipa), barato à escala |
| Manutenção | Zero, melhora sozinho | Tua, para sempre |
| Controlo / lock-in | Pouco controlo, alto lock-in | Alto controlo, sem lock-in |
| A quem compensa | Quase todas ao começar | Alto volume ou dado sensível |
Porque para 90% das PME a resposta é arrancar com uma API fechada
Não é preguiça nem pragmatismo cobarde: é aritmética. A maioria dos projetos de IA de uma PME morre não por escolher o modelo errado, mas por nunca chegar a produção. E tudo o que alonga o caminho até produção sobe a probabilidade de morte. Auto-alojar um modelo aberto acrescenta, à partida, um projeto de infraestrutura inteiro antes sequer de teres validado que a ideia funciona. É otimizar o custo por token de algo que ainda não sabes se vais usar.
- O teu volume é baixo ao início. A poupança ao token do open source só compensa a partir de muito tráfego. Com poucas chamadas por dia, a tua infraestrutura própria sai mais cara do que a API, não mais barata.
- Não tens —nem queres— uma equipa de MLOps. Servir um modelo em produção com alta disponibilidade é um ofício. Se não o tens em casa, o que poupas em tokens pagá-lo em contratações ou em quedas.
- O modelo aberto de hoje não é a tua vantagem. O teu diferencial não é que pesos corres, é o teu processo e o teu dado. Arrancar numa API deixa-te focar nisso em vez de em drivers de GPU.
- Migrar depois é barato; enganares-te ao início é caro. Se desenhas a aplicação desacoplada do fornecedor, passar de uma API fechada ao teu próprio modelo mais tarde é uma mudança de configuração, não uma reescrita.
A jogada sensata é arrancar com uma API fechada, validar que o caso funciona na tua operação e deixar a porta aberta para descer para open source no dia em que os números o pedirem. Se o projeto é sério e vai crescer, essa arquitetura —desacoplada, com encaminhamento de modelos e o dado sob o teu controlo— é exatamente o que montamos em infraestrutura de IA empresarial: não para te casar com um fornecedor, mas para o poderes trocar sem dor.
Quando descer para open source faz sentido
A regra não é «nunca open source». É «open source quando um gatilho real o justificar», não quando o orgulho o exigir. Estes são os gatilhos que movem mesmo a balança:
- O dado não pode sair do teu perímetro. Saúde, banca, jurídico, segredo industrial: se por contrato ou por regulação o dado não pode tocar num servidor de terceiros, o auto-alojar deixa de ser preferência e passa a ser requisito. Antes de dares por garantido que é o teu caso, arruma o que pode e o que não pode sair com uma política de uso de ChatGPT e modelos externos na empresa; muitas vezes o dado sensível é uma fração pequena e o resto passa muito bem por API.
- O volume é grande e sustentado. Quando chamas o modelo milhões de vezes por mês de forma estável, o custo ao token da API começa a doer e o teu próprio modelo amortiza. Aqui sim a aritmética favorece o open source —desde que já tenhas quem o opere—.
- Precisas de afinar o modelo com o teu conhecimento. Se o teu caso exige um modelo especializado no teu domínio e nos teus dados, controlar os pesos ajuda. Mas atenção: antes do fine-tuning, o remédio real é quase sempre a recuperação sobre a tua informação, algo que destrinçamos em treinar o agente com a tua própria informação.
- Latência ou offline. Se precisas de resposta local, sem rede, ou de latência mínima garantida, o modelo tem de viver perto de onde se usa. Aí nenhuma API fechada aguenta.
O custo que ninguém te conta: manter não é grátis
O erro clássico ao comparar é olhar só para o preço ao token e concluir que o open source é «grátis». Não é. Um modelo auto-alojado tem um custo que não aparece em nenhuma tarifa: alguém tem de o servir com alta disponibilidade, vigiar que não se degrada, atualizá-lo quando sair uma versão melhor e estar de prevenção quando cai. Esse custo é um salário, não uma linha de fatura, e é recorrente. A API fechada esconde esse custo dentro do preço ao token; o open source passa-o inteiro à tua equipa.
Por isso a comparação honesta não é «API cara contra open source barato». É «custo variável que não geres contra custo fixo que geres». Para volume baixo ou médio, o variável ganha quase sempre. Para volume alto com equipa dedicada, o fixo. A mesma lógica de fundo que separa comprar de construir para qualquer peça de IA, que já defendemos em comprar ou construir agentes IA.
O que fazer segunda-feira
- Arranca com uma API fechada e valida que o caso funciona na tua operação real, não numa demo. Otimizar o custo ao token antes disso é otimizar algo que não existe.
- Desacopla desde o primeiro dia. Desenha a aplicação para que o fornecedor de modelo seja configuração, não cablagem. Assim migrar depois custa uma tarde, não um trimestre.
- Marca os teus gatilhos. Escreve, preto no branco, que dado não pode sair e a que volume a fatura começaria a doer. No dia em que um se cumprir, tens o teu sinal para descer para open source —e só nesse dia—.