Modelos abertos e proprietários

O que significa “aberto” em inteligência artificial

Em software, código aberto tem definições consolidadas. Em IA, um sistema pode envolver código de treino, código de inferência, arquitetura, pesos, tokenizer, dados, processo de preparação, documentação e licença. Um fornecedor pode liberar pesos e manter dados e treinamento fechados. Por isso, dizer apenas “modelo aberto” esconde diferenças importantes.

A Open Source AI Definition 1.0, da Open Source Initiative, exige liberdades para usar, estudar, modificar e compartilhar o sistema, além do acesso à forma preferida para realizar modificações. Nem todo modelo anunciado como open source satisfaz esses requisitos. “Open weights” é um termo mais preciso quando os pesos estão disponíveis sob determinada licença, mas o processo completo não está.

Abertura é um espectro técnico, mas licença é uma condição jurídica concreta. Pesos disponíveis podem restringir uso comercial, número de usuários, setores, redistribuição, derivados ou hospedagem. Leia a versão exata da licença e os termos associados.

As camadas que precisam ser comparadas

O modelo-base é apenas uma camada. Produto inclui interface, RAG, ferramentas, filtros, moderação, memória, monitoramento, SLA e suporte. Um modelo aberto implantado por uma plataforma gerenciada pode ter experiência semelhante a uma API proprietária. Um serviço proprietário pode oferecer instalação dedicada ou políticas empresariais específicas.

Compare acesso ao artefato, liberdade de modificação, localização da inferência, controle de versão, telemetria, retenção de dados, capacidade de auditoria e responsabilidade operacional. Separe promessas comerciais de evidências contratuais e técnicas.

A unidade de decisão deve ser o sistema completo na tarefa real. Rankings públicos ajudam a selecionar candidatos, mas não medem sua linguagem, documentos, latência, risco e custo de revisão.

• Artefatos: pesos, tokenizer, configuração, código e adaptadores.
• Licença: uso, modificação, redistribuição, derivados e restrições.
• Dados: origem documentada, idiomas, opt-out, privacidade e direitos.
• Operação: hardware, nuvem, região, disponibilidade, observabilidade e suporte.
• Produto: contexto, ferramentas, multimodalidade, segurança e experiência.
• Governança: documentação, testes, incidentes, atualização e saída.

Pontos fortes e limitações dos modelos abertos

Pesos disponíveis permitem rodar em infraestrutura própria, inspecionar comportamento, quantizar, ajustar, combinar adaptadores e controlar atualização. Isso favorece ambientes offline, latência local, pesquisa, soberania tecnológica e aplicações especializadas. A comunidade pode criar ferramentas e avaliações rapidamente.

O controle traz responsabilidade. A organização precisa dimensionar GPUs, servir o modelo, aplicar atualizações, proteger endpoints, implementar moderação e responder a incidentes. Documentação e cobertura de idiomas variam. Pesos podem ser grandes, licenças incompatíveis e versões comunitárias difíceis de verificar.

Transparência de pesos não revela automaticamente dados de treino nem torna o modelo explicável. Um modelo aberto pode conter vieses, vulnerabilidades e material problemático. Abertura facilita inspeção e modificação, mas segurança depende de processo.

Pontos fortes e limitações dos modelos proprietários

Serviços proprietários reduzem o esforço inicial: API, escalabilidade, modelos atualizados, filtros, ferramentas, suporte e recursos multimodais podem vir integrados. Para equipes pequenas ou demanda variável, pagar por uso evita investimento em infraestrutura e acelera experimentação.

A contrapartida é dependência. Preço, limite, modelo, comportamento, região e termos podem mudar. O usuário não controla pesos nem todo o pipeline. Atualizações silenciosas podem afetar resultados. Observabilidade e explicação são limitadas ao que o provedor expõe.

Privacidade varia por plano e contrato. É preciso verificar retenção, uso para treinamento, localização, subprocessadores, exclusão, logs e resposta a incidente. Não presuma que um produto de consumo oferece as mesmas garantias de uma oferta empresarial.

• Vantagens comuns: início rápido, elasticidade, documentação, suporte e recursos de ponta.
• Limitações comuns: lock-in, menor controle, caixa-preta, variação de preço e versão.
• Pergunte se há versão fixa, SLA, região, exportação, logs e política de descontinuação.
• Teste limites de taxa, indisponibilidade e comportamento de fallback.
• Mantenha contrato e avaliação alinhados à modalidade realmente usada.

Desempenho: não existe vencedor universal

Modelos variam por texto, código, visão, contexto, idioma, instruções e uso de ferramentas. Um modelo maior pode liderar benchmark geral e perder em extração de campo específico. Ajuste, quantização e servidor alteram resultado. A comparação deve usar a mesma tarefa, prompt, dados, temperatura, limite e critério.

Crie conjunto de avaliação com casos normais, difíceis, sem resposta, adversariais e representativos do português brasileiro. Meça correção, formato, segurança, latência e custo total. Faça análise cega quando possível. Reexecute após qualquer mudança de versão.

Modelos abertos permitem escolher tamanho e quantização para hardware. Serviços proprietários podem oferecer roteamento e cache. A melhor opção pode ser um modelo pequeno para tarefas simples e um modelo mais capaz para exceções.

1. Definir tarefa, risco, população e critério de aceite.
2. Selecionar candidatos compatíveis com licença, contexto e modalidade.
3. Padronizar prompts, ferramentas, dados e parâmetros de teste.
4. Medir qualidade global e por categoria, idioma e dificuldade.
5. Medir latência, disponibilidade, custo e revisão humana.
6. Testar segurança, recusa, vazamento e entradas maliciosas.
7. Fazer piloto e registrar versão antes da decisão.

Custo total: API, GPU e trabalho humano

API costuma cobrar por tokens, imagens, áudio, armazenamento ou ferramentas. Hospedagem própria envolve GPU, servidor, energia, rede, engenharia, observabilidade, redundância e ociosidade. Download sem preço não elimina esses custos. O ponto de equilíbrio depende de volume, comprimento do contexto, concorrência e nível de serviço.

Inclua custos menos visíveis: preparação de dados, RAG, ajuste, testes, segurança, revisão humana, indisponibilidade, migração e conformidade. Um modelo mais barato que exige dobro de correção pode custar mais por resultado aprovado. Use custo por tarefa bem-sucedida, não por token isolado.

Em carga irregular, API elástica pode ser eficiente. Em volume alto e previsível, modelo otimizado pode justificar operação própria. Reservar capacidade, batch, cache, quantização e roteamento alteram a conta. Faça simulação com dados reais e margem de crescimento.

Privacidade, segurança e conformidade

Hospedagem própria pode manter dados no ambiente, mas também transfere segurança para a organização. Endpoint exposto, modelo adulterado, dependência vulnerável ou log sem proteção podem causar incidente. Verifique procedência do artefato, hash, assinatura, dependências, isolamento e atualizações.

Em API, avalie contrato, finalidade, retenção, uso para treinamento, região, subprocessadores, criptografia, controles de acesso e exclusão. Em ambos os modelos, minimize dados enviados, proteja prompts e saídas, separe clientes e registre uso proporcional ao risco.

Modelos e licenças não garantem conformidade automática. LGPD e regras setoriais dependem do tratamento realizado. Classifique casos de uso, faça avaliação de impacto quando apropriado e mantenha responsável, documentação e canal de incidente.

• Inventarie modelo, origem, licença, versão, hash e dependências.
• Restrinja rede, identidade, recursos, dados e ferramentas.
• Não exponha diretamente um servidor de inferência sem autenticação e limites.
• Proteja logs, cache, embeddings, datasets e checkpoints.
• Execute testes de segurança e monitore uso anômalo.
• Defina atualização, correção, rollback e descontinuação.
• Exija no contrato as garantias necessárias ao caso de uso.

Lock-in, portabilidade e estratégia híbrida

Lock-in aparece quando prompts, ferramentas, formatos, embeddings e avaliações ficam acoplados a um fornecedor. Ele não é sempre ruim; recursos exclusivos podem gerar valor. O risco é não conseguir migrar quando preço, qualidade ou política muda. Identifique dependências deliberadamente.

Camada de abstração pode padronizar chamadas, mas não apaga diferenças de contexto, tool calling, multimodalidade e segurança. Prompts portáveis ainda precisam de nova avaliação. Guarde seus dados, conjunto de testes, templates, schemas e métricas fora do provedor.

Estratégia híbrida roteia tarefas: modelo local para dados sensíveis ou alto volume; API avançada para casos complexos; modelo pequeno para classificação; busca e regras para funções determinísticas. Roteamento aumenta complexidade e deve respeitar política de dados.

1. Mapear recursos proprietários usados e alternativas possíveis.
2. Separar lógica de negócio, dados e avaliação da camada do modelo.
3. Padronizar schemas e adaptadores sem esconder diferenças relevantes.
4. Manter conjunto de regressão executável em todos os candidatos.
5. Definir exportação, prazo, custo e responsável pelo plano de saída.
6. Testar fallback e migração antes de uma emergência.

Checklist de escolha e contratação

A decisão deve partir do caso de uso e do risco, não de uma preferência ideológica por aberto ou fechado. Forme uma lista curta de opções juridicamente e tecnicamente viáveis. Teste em ambiente representativo, estime custo total e verifique como cada solução falha.

Peça documentação de modelo, licença, dados, segurança, disponibilidade, suporte e mudanças. Para aberto, confirme capacidade operacional. Para proprietário, confirme garantias contratuais e plano de saída. Registre a decisão, as condições que a sustentam e a data de revisão.

Escolher modelo é decisão recorrente. Novas versões surgem, custos mudam e seu tráfego evolui. Reavaliação programada e por evento evita tanto migrações impulsivas quanto dependência invisível.

• A licença permite o uso, ajuste, distribuição e volume pretendidos?
• A qualidade foi comprovada em dados próprios e português brasileiro?
• Onde entradas, saídas, logs, embeddings e ajustes são processados?
• Quem opera, monitora, corrige, atualiza e responde por incidentes?
• Qual é o custo por tarefa aprovada, incluindo revisão e infraestrutura?
• Há SLA, suporte, versionamento, rollback e prazo de descontinuação?
• Como exportar dados e migrar prompts, ferramentas e avaliações?
• A solução menor e mais simples atende ao risco e ao desempenho?

Uma matriz de decisão prática

Atribua pesos conforme o caso: privacidade pode valer mais em saúde; elasticidade pode dominar um produto sazonal; operação offline pode ser requisito industrial. Pontue evidências, não percepções. Se uma condição obrigatória falhar — licença, região, segurança — elimine a opção antes de somar notas.

Faça análise de sensibilidade: se o volume dobrar, o vencedor muda? Se o provedor aumentar preço, existe alternativa? Se uma GPU ficar indisponível, há fallback? A decisão robusta continua adequada em cenários plausíveis.

Inclua a alternativa de não usar um modelo generativo. Busca, regras ou um modelo clássico podem ser mais baratos, explicáveis e confiáveis. A comparação correta é entre soluções para o problema, não apenas entre LLMs.