Modelo aberto ou fechado? A escolha empresarial começa fora do modelo

Custo total, criticidade do processo, customização, dados, governança e capacidade de saída dizem mais sobre a decisão do que o rótulo usado pelo fornecedor.

Nathan Lambert publicou em 11 de setembro e atualizou dois dias depois uma extensa [lista comentada de referências sobre modelos abertos](https://www.interconnects.ai/p/open-source-ai-reading-list). O material reúne textos sobre estratégia, competição entre Estados Unidos e China, adoção, segurança, distilação e economia.

É uma curadoria autoral, não uma pesquisa primária única. Ainda assim, ela expõe uma mudança importante no debate empresarial: a pergunta deixou de ser apenas qual modelo entrega a melhor resposta e passou a incluir quem controla a infraestrutura, os dados, as adaptações e a continuidade da operação.

É tentador resumir tudo a uma disputa simples: modelo aberto de um lado, modelo fechado do outro.

Essa simplificação atrapalha.

O trabalho da pesquisadora Irene Solaiman já descrevia, em 2023, [seis níveis de acesso](https://arxiv.org/abs/2302.04844), do sistema totalmente fechado ao totalmente aberto, passando por acesso gradual, serviço hospedado, nuvem ou interface de programação de aplicações (API) e download. Em outras palavras, abertura é um gradiente. Uma empresa pode ter acesso aos pesos de um modelo e, ainda assim, não ter os dados de treinamento, o código necessário para reproduzi-lo ou uma licença que permita todas as adaptações pretendidas.

Por isso, modelo aberto não é estratégia.

A estratégia está em decidir onde o controle cria valor para o negócio e onde a dependência pode ser aceita.

Antes da escolha, defina o que realmente está aberto

A [Open Source AI Definition 1.0](https://opensource.org/ai/open-source-ai-definition), publicada pela Open Source Initiative (OSI), associa IA de código aberto às liberdades de usar, estudar, modificar e compartilhar o sistema. Para que essas liberdades sejam praticáveis, a definição inclui acesso a informações sobre os dados, ao código e aos parâmetros necessários para modificar o sistema.

Isso cria uma distinção empresarial relevante. “Pesos disponíveis” não significa necessariamente “sistema aberto” no sentido completo. Também não significa uso irrestrito. A licença pode limitar finalidades, redistribuição, volume, territórios ou formas de exploração comercial.

Antes de comparar desempenho, a empresa precisa responder quatro perguntas básicas: o que está acessível, o que pode ser modificado, o que a licença permite e quais componentes continuam dependentes de terceiros.

Sem isso, a análise de abertura começa pelo nome de marketing, não pela arquitetura real.

Uma matriz para decidir

A escolha pode ser organizada em seis dimensões. As colunas abaixo não apontam um vencedor universal. Elas indicam em que condições cada arranjo tende a fazer mais sentido.

| Critério | Serviço gerenciado ou modelo fechado | Modelo com pesos acessíveis e operação própria | Pergunta decisiva | |---|---|---|---| | **Criticidade do processo** | Tende a acelerar usos periféricos ou facilmente substituíveis, desde que haja nível de serviço adequado. | Ganha relevância quando indisponibilidade, mudança unilateral ou perda de acesso afetam uma operação central. | Se esse fornecedor sair do ar amanhã, o processo para ou apenas perde eficiência? | | **Custo total** | Concentra custos em consumo, contrato e integração; reduz a necessidade inicial de infraestrutura e equipe especializada. | Troca parte do custo por computação, observabilidade, segurança, atualização e profissionais capazes de operar o ambiente. | O cálculo inclui três anos de operação ou apenas o preço por chamada? | | **Customização** | Atende bem quando prompts, busca em bases próprias e ajustes oferecidos pelo fornecedor resolvem o caso. | Faz mais sentido quando o diferencial exige alterações profundas, ajuste fino específico ou controle sobre a execução. | A customização é vantagem competitiva ou apenas preferência técnica? | | **Dados e privacidade** | Pode funcionar com controles contratuais e técnicos adequados sobre retenção, localização, acesso e uso dos dados. | Pode ampliar o controle sobre o fluxo de dados, mas transfere à empresa a responsabilidade por proteger infraestrutura, registros e versões do modelo. | Onde os dados entram, ficam registrados, são reutilizados e podem ser eliminados? | | **Governança e auditoria** | Pode oferecer documentação, salvaguardas e suporte, mas mantém componentes internos fora do alcance do cliente. | Pode ampliar a inspeção, desde que os artefatos existam e a empresa tenha competência para avaliá-los e monitorá-los. | A organização consegue provar como testa, aprova, monitora e interrompe o sistema? | | **Dependência e reversibilidade** | Cria dependência de API, contrato, preço, disponibilidade e mudanças do fornecedor. | Reduz algumas dependências, mas mantém outras: nuvem, chips, bibliotecas, mantenedores e equipe interna. | Quanto custa trocar de modelo sem reconstruir a aplicação inteira? |

Gratuito não é o mesmo que barato

O erro mais comum na dimensão financeira é comparar o preço de uma API com o preço de download de um modelo.

O download pode ser gratuito. A operação não é.

Uma arquitetura própria exige capacidade computacional, implantação, testes, monitoramento, correções de segurança, gestão de versões e resposta a incidentes. O serviço gerenciado incorpora parte desse trabalho no preço, mas cobra pela conveniência e mantém o cliente sujeito às regras do fornecedor.

O cálculo relevante, portanto, é o custo total de propriedade. Ele deve incluir consumo, infraestrutura, pessoas, segurança, integração, indisponibilidade, qualidade das respostas e custo de migração. Em processos de baixo volume ou baixa diferenciação, a API pode ser mais racional. Em volume elevado, demanda previsível ou casos que exigem controle fino, a operação própria pode ganhar sentido.

Pode.

Sem medir o caso concreto, qualquer conclusão vira torcida tecnológica.

Hospedar o modelo não resolve sozinho o problema dos dados

Há outra confusão frequente: tratar execução interna como sinônimo automático de privacidade.

Hospedar um modelo em ambiente próprio pode reduzir a exposição a um fornecedor externo, mas não resolve permissões excessivas, registros inseguros, anexos enviados sem necessidade, bases de treinamento mal governadas ou ausência de política de eliminação. Da mesma forma, contratar uma API não elimina a possibilidade de controle; tudo depende da arquitetura, do contrato e das práticas efetivas do fornecedor e da empresa.

O [Radar Tecnológico sobre IA generativa da Autoridade Nacional de Proteção de Dados](https://www.gov.br/anpd/pt-br/centrais-de-conteudo/documentos-tecnicos-orientativos/radar_tecnologico_ia_generativa_anpd.pdf/@@display-file/file) chama atenção para o tratamento de dados pessoais em prompts, compartilhamento, refinamento e eliminação. O documento também destaca a importância da documentação ao longo do ciclo de vida. A consequência prática é direta: soberania não se prova com o endereço do servidor. Ela depende de saber quais dados circulam, por qual finalidade, com quais controles e sob responsabilidade de quem.

O mesmo vale para governança. O [AI Risk Management Framework do NIST](https://airc.nist.gov/airmf-resources/airmf/5-sec-core/) orienta organizações a governar, mapear, medir e gerenciar riscos ao longo de todo o ciclo de vida. O framework inclui riscos de componentes e dados de terceiros, testes antes e durante a operação e planos de contingência para falhas em sistemas externos.

Nada disso desaparece quando o modelo é aberto.

Na União Europeia, por exemplo, o [AI Act](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R1689) prevê exceções específicas para certos modelos de propósito geral sob licenças livres e abertas, mas não trata a abertura como dispensa geral. Modelos classificados como de risco sistêmico continuam sujeitos a obrigações adicionais, e permanecem exigências relacionadas a direitos autorais e ao resumo do conteúdo de treinamento.

A arquitetura mais madura pode ser híbrida

Depois de preencher a matriz, muitas empresas não chegarão a uma resposta única. E tudo bem.

Processos administrativos de baixo risco podem usar um serviço gerenciado. Fluxos que lidam com informação sensível podem exigir ambiente controlado. Uma aplicação pode encaminhar tarefas simples para um modelo de menor custo e reservar um modelo mais capaz para casos difíceis. Outro sistema pode manter uma alternativa pronta para assumir quando o fornecedor principal falhar.

Essa arquitetura híbrida não é indecisão. É segmentação de risco.

O ponto é evitar que a aplicação inteira fique amarrada a uma escolha irreversível. Camadas de integração separadas do modelo, conjuntos próprios de testes, registro de versões, formatos exportáveis e um plano de substituição transformam reversibilidade em requisito de projeto. Sem esses mecanismos, até uma solução baseada em pesos abertos pode gerar dependência operacional difícil de desfazer.

O modelo vem depois do processo

A decisão começa pela classificação do processo: qual é sua criticidade, quais dados utiliza, quanto exige de customização, que risco aceita e como funcionará a saída. Só depois faz sentido comparar modelos e fornecedores.

Em uma atividade periférica, velocidade de implantação pode valer mais que controle profundo. Em uma capacidade central do negócio, entregar toda a operação a uma interface externa pode criar uma dependência que o preço inicial não mostra. Em outros casos, manter infraestrutura própria será apenas uma forma cara de resolver um problema comum.

Aberto e fechado não são estratégias prontas. São arranjos de controle e responsabilidade.

A pergunta útil não é qual lado vai vencer. É onde a empresa precisa capturar valor e onde pode aceitar dependência sem comprometer custo, dados, governança e continuidade.