Modelos de IA open source ou proprietários para empresas: o que muda

A escolha entre modelos de IA open source ou proprietários para empresas define, em essência, três coisas: quem assume o trabalho de operação, por onde os seus dados circulam e quão difícil será mudar de rota mais adiante. Modelos proprietários, usados por meio do serviço de um provedor, são mais rápidos para começar e mais leves de manter. Modelos abertos dão controle sobre a hospedagem e a localização dos dados, ao custo de operá-los e protegê-los por conta própria ou com um parceiro. Nenhum dos dois é melhor em geral, e uma arquitetura bem montada mantém a decisão reversível.

Principais pontos

• Modelos proprietários transferem ao provedor o trabalho de hospedagem e de execução, mas avaliação, permissões e os efeitos de mudanças feitas pelo provedor no modelo continuam com você.
• Modelos abertos (geralmente de pesos abertos) dão controle sobre onde os dados são processados, mas esse controle só ajuda se alguém operar, proteger e atualizar a infraestrutura.
• A maior parte da dependência está fora do modelo: nos prompts, nas definições de ferramentas, na memória e em recursos específicos do provedor. Mantenha tudo isso em formatos que pertencem à sua empresa.
• Recuperar informações dos próprios documentos torna a troca de modelo bem menos dolorosa do que embutir o conhecimento da empresa nos pesos do modelo.
• Decida com um pequeno conjunto de testes feito com tarefas reais e escreva o plano de troca no primeiro dia, não no dia em que precisar dele.

O que significam modelos de IA open source e proprietários na prática?

Um modelo proprietário é aquele que você acessa pelo serviço de um provedor. Você envia uma solicitação, o provedor executa o modelo na infraestrutura dele e devolve o resultado. Não é possível baixar o modelo nem inspecionar seu funcionamento interno, e você não decide quando ele muda. O provedor escolhe quando as versões são atualizadas e descontinuadas.

Um modelo aberto é aquele cujos pesos você pode baixar e executar na infraestrutura que escolher. A rigor, muitos deles são de pesos abertos (open-weight) e não totalmente open source: os pesos estão disponíveis, mas os dados de treinamento e o código podem não estar, e a licença pode limitar uso comercial, redistribuição ou escala. Leia a licença como leria um contrato com fornecedor, porque, na prática, é isso que ela é.

Há ainda um terceiro arranjo que gera confusão: modelos abertos executados por um host de terceiros e usados por API. Operacionalmente, parece um serviço proprietário e levanta as mesmas dúvidas sobre dados que qualquer provedor. A diferença é que o mesmo modelo pode ser levado depois para outro host ou para a sua própria infraestrutura.

Vale lembrar também que o modelo é um componente de um sistema que funciona. Um agente precisa ainda de instruções, memória, ferramentas, permissões e monitoramento, o que separamos em Prompt engineering ou harness engineering: por onde começar. A escolha entre aberto e proprietário vale para uma camada. O modo como você constrói as outras camadas determina o quanto essa escolha pesa.

Quanto esforço de operação cada opção acrescenta?

Com um modelo proprietário, o provedor cuida da capacidade, do escalonamento, do hardware e da segurança da camada de execução. O seu trabalho fica acima dessa linha: escrever e testar instruções, definir o que o agente pode fazer, monitorar o comportamento e tratar erros e limites de uso que vêm do provedor.

O esforço que mais surpreende é o da mudança. Um provedor pode atualizar ou aposentar uma versão do modelo, e o comportamento pode mudar mesmo que as suas instruções continuem iguais. Sem um conjunto de tarefas reais que possa ser executado de novo, você descobre pela reclamação de um usuário, e não por um teste.

Com um modelo aberto, você é dono de mais partes da infraestrutura. Alguém precisa escolher o hardware ou um ambiente hospedado, executar o software de inferência, planejar a capacidade para períodos de pico, aplicar correções de segurança, vigiar falhas e decidir quando atualizar. Essa pessoa também precisa estar acessível quando algo quebrar. A vantagem é que nada muda a menos que você decida, e é possível fixar uma versão pelo tempo que ela servir.

O custo acompanha o esforço, mas de uma forma fácil de não notar. Eliminar a cobrança por uso não elimina o custo. Ele passa para a infraestrutura, para as horas da equipe e para a responsabilidade de plantão. Para aprofundar a questão da hospedagem, veja Agentes de IA em nuvem ou hospedagem própria: como decidir.

Para qualquer lado que você incline, faça estas perguntas antes de se comprometer:

• Quem fica de plantão quando o serviço do modelo falha, e o que essa pessoa faz primeiro?
• Quem decide quando a versão do modelo muda, e quem aprova?
• Como vamos saber que o comportamento mudou depois de uma atualização?
• Qual é o plano alternativo se o modelo ficar indisponível por um dia?
• Quem revisa as correções de segurança da camada de execução, e com que frequência?

O que acontece com os seus dados em cada opção?

O tratamento de dados é onde as duas opções mais se distinguem, e também onde as suposições mais falham. Com um modelo proprietário, cada prompt e cada documento recuperado passa pelo provedor para ser processado. O que acontece depois depende do contrato e das configurações da conta: retenção, se as entradas podem ser usadas para treinamento, em quais regiões os dados são processados, quais subprocessadores participam e o que é registrado em log.

Com um modelo aberto em infraestrutura sob seu controle, prompts e documentos ficam dentro de um perímetro que você define. Isso é uma vantagem real para material sensível. Mas controle não é o mesmo que segurança. Um modelo hospedado por conta própria, com regras de acesso fracas, logs sem criptografia ou um endpoint exposto, pode ser pior do que um provedor bem governado. Você passa a ser responsável pelo trabalho de segurança que o provedor faria.

Com um modelo aberto em um host de terceiros, voltam as perguntas sobre provedor. O fato de o modelo ser aberto não muda quem enxerga os seus dados.

Um ponto costuma passar despercebido: em um agente que recupera informações de documentos da empresa, o modelo vê os trechos recuperados a cada solicitação. Ou seja, o lugar onde o modelo roda importa tanto quanto o lugar onde os documentos ficam guardados. Uma base de conhecimento mantida no seu ambiente ainda envia fragmentos para o modelo que responde à pergunta.

Perguntas úteis para qualquer provedor, ou para a sua própria equipe, se você hospeda:

• Os dados são usados para treinamento, e isso pode ser desativado por escrito?
• Por quanto tempo prompts, respostas e logs são mantidos, e quem pode lê-los?
• Em quais regiões os dados são processados e armazenados?
• Quais outras empresas processam os dados em nome do provedor?
• O que acontece com os nossos dados quando encerrarmos a relação?

Uma abordagem estruturada de riscos ajuda a manter essas respostas consistentes entre ferramentas. O NIST AI Risk Management Framework é uma referência prática para organizá-las. As obrigações de proteção de dados previstas em leis como a LGPD ou o GDPR continuam dependendo da sua situação, então envolva o jurídico quando houver dados regulados.

Qual é a portabilidade do que você constrói em torno do modelo?

Muita gente acha que a dependência de fornecedor está no modelo. Na prática, ela mora nas coisas construídas ao redor dele. Um modelo costuma poder ser trocado em uma tarde. O que leva semanas é tudo o que dependia dele sem que ninguém percebesse.

As fontes mais comuns de dependência são estas:

• Instruções ajustadas aos hábitos de um modelo, que se comportam de outro jeito em outro.
• Definições de ferramentas escritas no formato de um provedor ou apoiadas em recursos proprietários dele.
• Memória ou estado de conversa guardados dentro do serviço hospedado do provedor.
• Modelos ajustados (fine-tuning) que existem apenas em uma plataforma.
• Índices de busca e embeddings criados com um modelo que você pode abandonar depois.
• Nenhum conjunto de tarefas de teste, de modo que ninguém sabe dizer se o substituto é igual ou pior.

Modelos abertos reduzem parte disso. Você tem os pesos, então um ajuste fino é seu, dentro do que a licença permitir. Mas uma infraestrutura de execução sob medida pode prender tanto quanto um provedor, porque o conhecimento de como ela funciona fica na cabeça de uma pessoa.

A defesa prática é a mesma nas duas opções. Mantenha instruções, memória e definições de ferramentas em formatos simples e versionados, que pertençam a você. Use padrões abertos para conexão de ferramentas quando existirem, como o Model Context Protocol, para que uma ferramenta não precise ser reescrita a cada modelo. E prefira recuperação a treinamento. Como a AWS explica em sua comparação entre recuperação (RAG) e fine-tuning, a recuperação mantém o conhecimento em documentos que você pode atualizar e levar para outro lugar, enquanto o fine-tuning o embute em um único modelo. Para aprofundar o tema, leia Como evitar dependência de fornecedor de IA em agentes.

Qual opção combina com qual situação?

Use isto como guia de decisão, não como regra. A maioria das empresas se reconhece em algumas linhas de cada lado, e isso é um sinal para começar com uma opção e projetar a estrutura já pensando na outra.

Inclina-se para um modelo proprietário quando:

• Você precisa de um papel funcionando rápido e não tem ninguém para operar infraestrutura de modelo.
• Os dados envolvidos podem ser compartilhados com um provedor sob termos revisados.
• A tarefa exige o melhor raciocínio geral disponível e você ainda não sabe quanta qualidade pode abrir mão.
• O uso é irregular, e um hardware dedicado ficaria ocioso boa parte do tempo.

Inclina-se para um modelo aberto quando:

• Contratos, regulação ou expectativas de clientes exigem que os dados fiquem em um ambiente sob seu controle.
• A tarefa é estreita e repetitiva, e um modelo menor pode ser suficiente.
• Você precisa fixar uma versão por meses para manter o comportamento estável.
• Você tem, ou pode contratar, pessoas que vão operar a infraestrutura com responsabilidade real.

Considere usar os dois quando:

• Etapas sensíveis (como ler registros internos) podem rodar em um modelo controlado, e etapas menos sensíveis (como redigir um texto público) usam um modelo hospedado mais forte.
• Você quer uma alternativa para que a queda de um provedor não pare um processo do negócio.

A escolha do modelo deve seguir o trabalho, e não o contrário. Como escolher modelo de IA para empresa: guia para agentes mostra como associar um modelo a uma função bem definida.

O que é preciso para trocar de modelo depois?

Trocar é mais fácil quando o trabalho foi organizado para isso desde o início. Eis um cenário ilustrativo. Um pequeno escritório de contabilidade usa um agente que redige respostas a dúvidas rotineiras de clientes, com um modelo proprietário. Um cliente pede que seus documentos nunca saiam de uma região específica. O escritório decide levar o fluxo desse cliente para um modelo aberto hospedado nessa região.

Se as instruções, as definições de ferramentas, a memória e um conjunto de perguntas de exemplo estavam em arquivos que pertencem ao escritório, a mudança é um projeto delimitado: executar as perguntas de exemplo no novo modelo, comparar, ajustar as instruções e então fazer a virada. Se essas coisas só existiam dentro do console do provedor anterior, o escritório precisa antes reconstruí-las de memória.

Um plano de troca, em ordem:

• Faça o inventário do que o agente utiliza: modelo, instruções, ferramentas, memória, índices, contas e credenciais.
• Exporte ou espelhe cada item em um formato que pertença a você e registre onde ele está.
• Monte um conjunto de testes com tarefas reais e o resultado que você aceitaria em cada uma, incluindo alguns casos difíceis.
• Execute o conjunto no modelo atual para definir uma linha de base.
• Execute-o no modelo candidato e registre as diferenças de qualidade, velocidade, custo por tarefa concluída e comportamento em falhas.
• Ajuste instruções e definições de ferramentas para o novo modelo e repita os testes até que o resultado atinja o seu critério.
• Faça a virada primeiro em um escopo limitado, com uma pessoa revisando as respostas e um caminho claro para voltar ao modelo anterior.
• Revise após um curto período, aposente a configuração antiga e remova os acessos que não são mais necessários.

A mesma disciplina ajuda se um provedor mudar os termos ou descontinuar uma versão. Plano de saída de fornecedor de IA: o que manter e documentar trata do que preservar antes de precisar.

Como a Be Human lida com essa escolha?

A Be Human trata o modelo como um componente substituível dentro de uma infraestrutura que o cliente controla. Em um primeiro projeto, definimos um papel, a memória e as ferramentas de que ele precisa, os limites de aprovação e um critério de sucesso observável. Depois testamos modelos candidatos, abertos ou proprietários, com tarefas reais desse papel. Instruções, memória, contratos de ferramentas e o conjunto de testes ficam em formatos documentados e de propriedade do cliente, de modo que uma troca futura seja uma mudança planejada, e não uma reconstrução. Na operação gerenciada, monitoramos o comportamento, repetimos as avaliações quando uma versão do modelo muda, revisamos permissões e fazemos melhorias de forma controlada.

Perguntas frequentes

IA open source é mais barata do que IA proprietária? Não automaticamente. Eliminar a cobrança por uso move o custo para hospedagem, segurança, monitoramento e o tempo das pessoas que operam o modelo. Para cargas estáveis e estreitas, pode sair mais barato, e para cargas irregulares ou complexas um serviço hospedado costuma ter o menor custo total. Compare as duas opções pelo custo por tarefa concluída, não pelo preço por solicitação.

Podemos usar modelos abertos e proprietários juntos? Sim, e muitas arquiteturas fazem isso. Um padrão comum envia as etapas sensíveis ou repetitivas para um modelo sob seu controle e as etapas de raciocínio mais difícil para um modelo hospedado. Isso exige regras claras sobre quais dados podem ir para onde e um conjunto de testes que cubra os dois caminhos.

Modelos abertos são mais seguros para dados confidenciais? Podem ser, se você os executar em um ambiente que proteja e monitore bem. Rodar o modelo por conta própria mantém os dados dentro do seu perímetro, mas também o torna responsável por controle de acesso, correções e logs. Um contrato revisado com um provedor pode ser mais seguro do que um servidor mal administrado.

Devemos fazer fine-tuning de um modelo com os dados da empresa? Em geral, não como primeiro passo. A recuperação a partir dos seus próprios documentos é mais fácil de atualizar, de auditar e de levar para outro modelo. Considere o fine-tuning depois, para uma lacuna específica e medida, como um estilo ou formato consistente que as instruções não conseguem entregar.

Orientação editorial Be Human. Exemplos são ilustrativos, salvo atribuição explícita. Fontes oferecem contexto; a implementação depende do seu processo.