BYOK: a chave é do cliente, e o modelo de negócio muda

No BYOK, o cliente contrata o modelo diretamente e o aplicativo cobra pelo que constrói ao redor dele. Essa separação muda custos, concorrência e o tipo de solução que pode existir.

Durante a primeira fase dos produtos de inteligência artificial, quase tudo vinha no mesmo pacote. O aplicativo escolhia o modelo, pagava pelos tokens, definia um limite de uso e repassava esse custo ao cliente dentro de uma assinatura. Para o usuário, havia uma única conta. Para a empresa, porém, cada conversa gerava uma despesa variável que precisava caber no preço do plano.

O BYOK propõe outra divisão. A sigla vem de Bring Your Own Key: traga sua própria chave. Em produtos de IA, isso normalmente significa que o usuário conecta ao aplicativo uma chave de API da OpenAI, Anthropic, Google ou outro provedor. O uso do modelo passa pela conta do próprio cliente, enquanto o aplicativo cobra separadamente pela interface, pelo fluxo de trabalho e pelo conhecimento especializado que oferece.

Essa mudança parece técnica, mas seu efeito principal é econômico. Quando o modelo deixa de ser um insumo escondido dentro da assinatura, fica mais claro o que pertence ao provedor da inteligência artificial e o que pertence ao produto construído sobre ela.

Como o BYOK funciona

Em uma implementação típica, o caminho é este:

  1. O cliente abre uma conta no provedor do modelo.
  2. Cria uma chave de API específica para o aplicativo ou projeto.
  3. Cadastra essa chave no produto que deseja utilizar.
  4. O produto usa a credencial para enviar as solicitações ao modelo.
  5. O provedor cobra do cliente o consumo de tokens; o produto cobra por sua própria camada de software.

A chave funciona como uma credencial de acesso e faturamento. Quem a possui pode consumir a API dentro das permissões e dos limites configurados. Por isso, BYOK não significa simplesmente copiar uma sequência de caracteres em qualquer formulário. A maneira como o aplicativo armazena, transmite, utiliza e permite revogar essa credencial é parte central do produto.

Também não existe uma única implementação comercial. A Vercel, por exemplo, documenta o BYOK como o uso das credenciais do cliente em seu gateway, sem acréscimo sobre o preço do modelo. Já o OpenRouter permite cadastrar chaves de vários provedores, definir prioridade e fallback e cobra sua própria taxa de roteamento em determinadas condições. A ideia comum é a separação entre a credencial do modelo e a aplicação que organiza seu uso; preços, armazenamento e rotas de contingência variam de produto para produto.

O modelo tradicional junta software e consumo

Quando uma aplicação fornece a inteligência artificial dentro de uma assinatura única, ela compra capacidade dos provedores e a revende como parte do serviço. Isso tem vantagens: o usuário não precisa entender APIs, configurar faturamento ou administrar chaves. Basta criar uma conta e começar.

Mas o fornecedor assume riscos importantes. Uma pessoa que usa pouco custa quase nada; outra que processa milhares de páginas pode consumir mais do que paga. Para proteger a margem, o produto adota franquias, créditos, filas, limites de tamanho ou planos difíceis de comparar. Parte da equipe passa a administrar a economia dos tokens, mesmo quando o verdadeiro valor do produto está em outro lugar.

Essa estrutura também pode misturar duas margens: a do modelo e a do software. O cliente nem sempre consegue saber quanto está pagando pela inferência e quanto corresponde à pesquisa, às integrações, ao suporte, ao armazenamento e à experiência de uso.

BYOK separa duas compras diferentes

Com BYOK, o cliente passa a comprar duas coisas:

  • capacidade de modelo, contratada do provedor e medida por uso;
  • produto, contratado de quem constrói o fluxo de trabalho.

O aplicativo não precisa ganhar dinheiro revendendo tokens. Ele pode cobrar pelaquilo que realmente desenvolveu: organização, busca, conectores, permissões, memória, avaliações, automações, colaboração, suporte e conhecimento de domínio.

Para entender como essa camada de software coordena contexto, ferramentas e verificações, leia o harness por trás dos agentes de IA, com Claude Code como exemplo.

Isso cria um modelo de negócio mais parecido com o de uma ferramenta profissional. Um editor de texto não precisa fabricar o computador no qual funciona. Do mesmo modo, uma aplicação de IA não precisa necessariamente ser a revendedora do modelo que utiliza.

O resultado pode ser uma estrutura de custos mais legível. O usuário vê o consumo no provedor e avalia a assinatura do aplicativo pelo valor da camada de software. A empresa, por sua vez, reduz a exposição a variações de preço, tarefas excepcionalmente longas e mudanças repentinas na preferência por modelos.

O que essa separação torna possível

O BYOK diminui a barreira para produtos que seriam difíceis de sustentar quando cada uso pesado gera uma despesa para o desenvolvedor.

Aplicações verticais menores

Uma equipe pequena pode construir uma ferramenta para um setor específico sem precisar financiar antecipadamente todo o consumo de IA dos clientes. Ela pode concentrar recursos no problema que conhece: contratos, pesquisa jurídica, engenharia, contabilidade ou atendimento técnico.

Escolha e troca de modelos

O mesmo produto pode aceitar credenciais de provedores diferentes. O cliente escolhe conforme preço, qualidade, localização, política de dados ou contrato corporativo. Essa portabilidade não é perfeita – modelos possuem ferramentas, limites e comportamentos diferentes –, mas reduz a dependência de uma única empresa.

Uso de contratos empresariais existentes

Organizações que já negociaram preços, limites ou condições de tratamento de dados com um provedor podem reutilizar essa relação em outras aplicações. A documentação da Vercel cita justamente créditos contratados, preços negociados e modelos disponíveis dentro da nuvem privada como razões para usar credenciais próprias.

Roteadores e camadas de governança

Uma aplicação pode escolher modelos diferentes para tarefas diferentes, mantendo políticas, observabilidade e limites em um só lugar. Um modelo rápido pode classificar documentos; outro, mais caro, pode revisar uma conclusão complexa. A conta continua pertencendo ao cliente.

Mercados de fluxos e especialização

Se o modelo é intercambiável, o produto precisa demonstrar valor em outro lugar. Isso favorece bibliotecas de procedimentos, agentes especializados, conectores e experiências voltadas a uma profissão. O diferencial deixa de ser apenas “temos acesso a um modelo poderoso” e passa a ser “sabemos transformar esse modelo em trabalho confiável”.

Por que isso importa no Direito

No trabalho jurídico, o modelo é apenas uma peça. Fontes, jurisdição, permissões, histórico, forma de citar e possibilidade de conferir o documento são componentes independentes da geração de texto.

Foi essa a principal conclusão da nossa análise sobre o Gemini Enterprise for Legal e o LexGPT: um bom modelo não substitui a infraestrutura ao redor dele. O BYOK torna essa distinção ainda mais visível.

Imagine uma aplicação jurídica na qual o escritório escolhe e paga pelo modelo, enquanto o produto especializado oferece:

  • fontes brasileiras organizadas;
  • pesquisa por tribunal, órgão julgador e período;
  • navegação pela estrutura de leis e regimentos;
  • citações ligadas ao documento correspondente;
  • projetos, permissões e memória institucional;
  • procedimentos de revisão definidos pela equipe.

Nesse cenário, trocar o modelo não elimina o produto. O acervo, os critérios de pesquisa e a forma de verificar o resultado continuam sendo valiosos. É a mesma razão pela qual fonte oficial e boa experiência de leitura não são a mesma coisa: a existência do documento não substitui o trabalho de estruturá-lo para uso profissional.

Para o LexGPT, BYOK representa uma possibilidade de arquitetura e de modelo de negócio – não uma funcionalidade que este texto esteja anunciando. O ponto é mostrar por que uma solução jurídica pode ser construída como uma camada especializada sobre modelos escolhidos pelo cliente, em vez de depender da revenda de um único modelo.

BYOK não significa automaticamente privacidade

Há um equívoco comum: imaginar que, porque a chave pertence ao cliente, a aplicação intermediária deixa de ter contato com os dados. Isso depende da arquitetura.

Se as solicitações passam pelo servidor do aplicativo, esse servidor pode tecnicamente receber a chave, o texto enviado e a resposta do modelo. Se a chamada acontece diretamente no dispositivo, a exposição pode ser diferente, mas surgem outros desafios de segurança. Além disso, gateways podem oferecer fallback para credenciais próprias quando a chave do cliente falha – comportamento útil para disponibilidade, mas que precisa estar claro porque altera faturamento e rota de dados.

Antes de conectar uma chave, o usuário deve saber:

  • onde ela é armazenada e se permanece criptografada;
  • se as chamadas passam pela infraestrutura do aplicativo;
  • quais dados são registrados;
  • se existe fallback para outra credencial ou outro provedor;
  • como revogar e substituir a chave;
  • como acompanhar consumo e estabelecer limites.

A própria OpenAI recomenda cautela com produtos de terceiros que solicitam chaves, além de armazenamento seguro, separação por projeto, monitoramento de gastos e rotação. O ideal é criar uma chave exclusiva para cada aplicação, com as menores permissões disponíveis e limites compatíveis com seu uso. Nunca se deve reutilizar uma chave pessoal ampla ou inseri-la em um produto que não explique como protege a credencial.

O usuário paga menos?

Não necessariamente. BYOK não quer dizer “IA gratuita”. O cliente continua pagando ao provedor pelo modelo e pode pagar ao aplicativo pela assinatura, infraestrutura ou roteamento.

A vantagem é outra: tornar as duas contas comparáveis e permitir que cada fornecedor seja remunerado pelo valor que entrega. Em alguns casos, isso reduz o preço. Em outros, melhora controle, previsibilidade ou liberdade de escolha. Também existe um custo de configuração que não combina com todo público. Para muitos usuários, uma assinatura integrada continuará sendo a experiência mais simples.

Por isso, BYOK pode coexistir com planos tradicionais. Um produto pode oferecer uma modalidade pronta para começar e outra destinada a equipes que desejam usar contratos, limites e modelos próprios.

Quando o modelo vira componente, o produto precisa provar seu valor

Durante algum tempo, bastava anunciar que um software “usa inteligência artificial”. À medida que modelos semelhantes ficam disponíveis por API, esse argumento perde força. Se o cliente pode trazer sua própria chave, a pergunta muda:

o que permanece quando retiramos do preço do aplicativo o custo do modelo?

Pode permanecer uma excelente interface. Pode permanecer uma base confiável, uma forma melhor de ler documentos, um conjunto de integrações, uma memória de projeto ou um procedimento que reduz erros. Pode não permanecer nada – e essa também é uma informação útil.

O BYOK não é apenas uma preferência técnica. Ele separa infraestrutura de inteligência de produto especializado. Ao fazer isso, abre espaço para empresas menores, soluções verticais e novas formas de cobrar pelo trabalho realizado ao redor do modelo.

A chave é do cliente. O modelo pode mudar. O produto precisa continuar fazendo sentido.

Para avaliar BYOK junto de fontes, sigilo, integrações e custo total, use nosso guia de compra de IA para advogados. Ele reúne critérios para testar as opções e decidir quando uma solução basta ou quando vale combinar ferramentas.

Experimente o LexGPT no seu trabalho.

Pesquise jurisprudência no Juris e confira as fontes que sustentam a resposta. Consulte os planos para escolher como usar o LexGPT.

O LexGPT está em beta.