Rodar um modelo próprio sai mais barato?

Só em volume alto e constante. Modelo próprio troca custo variável por custo fixo de GPU, que você paga mesmo com a máquina ociosa. Abaixo de um uso intenso e previsível, a API costuma custar menos, e a conta precisa incluir as horas de engenharia para manter tudo.

Usar API significa entregar meus dados para treinar o modelo de outra empresa?

Depende do contrato. Os principais provedores oferecem planos empresariais que não usam as requisições para treinamento e permitem definir retenção. Verifique isso no contrato e no termo de uso, não no material de marketing.

Modelos abertos já são bons o suficiente?

Para muitas tarefas, sim. Classificação, extração estruturada, resumo e reformulação funcionam bem em modelos abertos de porte médio. Em raciocínio longo, uso de ferramentas encadeadas e código, os modelos comerciais de topo ainda mantêm vantagem.

LLM próprio ou API o que escolher para a empresa

Para a maioria das empresas, API de modelo comercial é a escolha certa. Ela entrega a melhor qualidade disponível, com custo variável, sem investimento inicial e sem infraestrutura para manter. Modelo próprio se justifica em três situações específicas: exigência regulatória de o dado não sair do ambiente, volume alto e constante, ou latência crítica. É uma decisão tomada por restrição, não por preferência técnica.

O que realmente muda entre as duas opções

Critério	API comercial	Modelo próprio (self-hosted)
Investimento inicial	Praticamente zero	GPU, ambiente e engenharia
Custo por uso	Variável, por token	Fixo, paga ocioso também
Qualidade de topo	Sim, atualizada	Defasada em relação ao topo
Dado sai do ambiente	Sim, para o provedor	Não
Manutenção	Nenhuma	Sua (atualização, escala, falha)
Latência	Rede + fila do provedor	Controlada por você
Previsibilidade de custo	Menor, cresce com uso	Maior, teto conhecido
Risco de mudança externa	Preço, política e descontinuação	Nenhum
Tempo até o primeiro resultado	Dias	Semanas

Quando modelo próprio se justifica

Exigência regulatória ou contratual real. Não "seria bom se ficasse dentro de casa", mas uma cláusula ou norma que proíbe o tráfego do dado para fora. Setores de saúde, defesa e algumas operações financeiras vivem isso de verdade. Antes de assumir que é o seu caso, leia a norma: muita restrição percebida se resolve com um contrato de processamento adequado, região de processamento definida e política de retenção zero.

Volume alto, constante e previsível. Uma GPU só se paga quando fica ocupada. Se o uso é intenso durante todo o expediente, todos os dias, o custo fixo dilui bem. Se é um pico às segundas e silêncio no resto da semana, você está pagando por ociosidade.

Latência crítica. Aplicações em tempo real, com resposta em dezenas de milissegundos, ou operação com conectividade instável. Aqui o modelo local resolve um problema que a API não resolve.

Tarefa estreita com modelo pequeno. Classificação, extração de campos, moderação, roteamento. Um modelo de porte pequeno ajustado para a tarefa roda barato, rápido e com qualidade suficiente. Esse é o caso mais subestimado e o que mais compensa na prática.

O custo que ninguém coloca na planilha do modelo próprio

Quem compara "preço por milhão de tokens" contra "aluguel de GPU" está comparando errado. O custo real de rodar modelo próprio inclui:

GPU ociosa. Você paga 24 horas, usa poucas.
Redundância. Uma máquina só significa indisponibilidade quando ela cai.
Engenharia de inferência. Servidor de inferência, batching, quantização, gestão de contexto. É trabalho especializado e contínuo.
Atualização de modelo. Modelo aberto novo sai a cada poucos meses. Migrar exige reavaliar tudo o que dependia do comportamento do anterior.
Avaliação própria. Sem um conjunto de avaliação seu, você não sabe se a troca melhorou ou piorou.
Plantão. Alguém precisa atender quando cai fora do horário.

A conta honesta compara custo total anual, incluindo horas de engenharia, contra a fatura da API no volume real medido, não no volume estimado do piloto.

O que fazer sobre privacidade sem sair para o modelo próprio

Boa parte da preocupação com privacidade se resolve com arquitetura, não com hospedagem:

Não mande o que não precisa. Mascare CPF, e-mail, telefone e nome antes de enviar. Muitas tarefas funcionam perfeitamente com o dado anonimizado e a reidentificação feita depois, do seu lado.

Contrato certo. Planos empresariais dos principais provedores oferecem ausência de uso para treino e retenção configurável. Isso está no contrato, leia e guarde.

Região de processamento. Alguns provedores permitem restringir a região. Verifique se atende à sua política.

Separação por sensibilidade. Fluxos com dado sensível vão para um modelo local pequeno; o resto usa API. Arquitetura híbrida é comum e legítima.

Log do seu lado. Guarde o que trafegou, para auditoria. Não dependa do log do provedor.

A arquitetura que evita a decisão irreversível

O erro estratégico não é escolher errado, é escolher de um jeito que trave você.

Isole a chamada ao modelo atrás de uma interface própria da sua aplicação. O resto do sistema não deve saber qual provedor está por trás. Com isso:

Trocar de provedor vira mudança de configuração, não reescrita
Dá para rotear tarefas diferentes para modelos diferentes por custo
Dá para testar um modelo novo contra o conjunto de avaliação sem mexer no produto
Um provedor fora do ar não derruba o sistema, se houver alternativa configurada

Essa camada custa pouco para construir e é o que mais preserva liberdade ao longo do tempo. É prática padrão nos sistemas que a Retti Tech mantém em produção, justamente porque o mercado de modelos muda mais rápido que o ciclo de vida de um sistema corporativo.

A recomendação prática

Comece com API. Valide se o problema tem solução antes de investir em infraestrutura.
Meça o custo real por caso resolvido durante três meses de uso normal.
Isole a chamada ao modelo desde o primeiro dia.
Se o custo variável incomodar, procure primeiro as otimizações óbvias: prompt menor, cache, modelo mais barato para as tarefas simples, resposta curta. A economia costuma ser grande.
Considere modelo próprio apenas se, depois disso, o volume ainda justificar ou se a restrição regulatória for real.

A pergunta certa quase nunca é "próprio ou API". É "qual modelo, para qual tarefa, com qual custo por caso resolvido". Uma arquitetura bem feita usa modelos diferentes em pontos diferentes do mesmo sistema, e troca qualquer um deles sem drama.