Resposta rápida: Existem cinco opções de hospedagem para a IA de uma empresa: a API pública do fornecedor de modelo, a nuvem regional com contrato corporativo, a nuvem privada dedicada, o on-premise no data center da própria empresa, e o modelo aberto rodando em infraestrutura própria. Elas variam muito mais em custo de operação e em time necessário do que em capacidade técnica. Quatro perguntas separam uma da outra na prática: que dado passa por ali, quem opera aquilo no dia seguinte, qual é a conta quando o uso dobrar, e o que acontece se você quiser trocar.
A pergunta quase nunca nasce dentro da área de tecnologia. Ela chega do jurídico depois de uma conversa sobre proteção de dados, ou chega no questionário de segurança de um cliente grande, com uma linha pedindo em que região a informação é processada. O executivo repassa para o time e descobre que ninguém tinha decidido isso: a ferramenta foi contratada, funciona bem, e onde ela roda nunca foi uma escolha, foi um padrão aceito.
Eu escrevo isto porque a conversa costuma degringolar para dois extremos igualmente ruins. De um lado, o pânico que manda trazer tudo para dentro de casa, o que multiplica custo e prazo para resolver um risco que às vezes nem existe naquele caso. Do outro, o encolher de ombros que trata a pergunta como burocracia, o que funciona até o dia em que trava uma venda ou aparece um incidente.
O critério: o que muda de verdade entre as cinco
A capacidade do modelo quase não entra nesta decisão. As cinco opções abaixo conseguem rodar modelos bons o bastante para a esmagadora maioria dos casos corporativos, e a diferença de qualidade entre elas é menor do que a diferença entre um processo bem desenhado e um mal desenhado.
O que muda de verdade são três coisas. A primeira é onde o dado fica em repouso e em trânsito, que é a pergunta do jurídico e do cliente. A segunda é quem precisa acordar de madrugada quando aquilo cair, que é a pergunta que ninguém faz e que determina o custo real. A terceira é a curva de custo, que se comporta de forma muito diferente entre pagar por uso e pagar por infraestrutura parada.
Existe uma quarta variável que aparece só no segundo ano: quanto custa sair. Ela não pesa na assinatura e pesa na renovação, e é a que produz mais arrependimento.
A ordem abaixo vai da opção mais leve para a mais pesada em operação. Como regra geral, cada degrau só compensa quando existe uma exigência concreta que o degrau anterior não atende, e exigência concreta significa um contrato, uma norma ou um regulador, e não uma preocupação genérica com segurança.
Opção 1: a API pública do fornecedor de modelo
O que é: a empresa consome o modelo direto do fornecedor, pela interface pública ou por API, no plano corporativo. Nenhuma infraestrutura própria, nenhum time de operação, e a conta chega por uso ou por assento.
Quando ganha: em praticamente todo começo, e em muito mais casos do que o mercado admite. É a opção com menor tempo até o primeiro resultado, e o contrato corporativo dos grandes fornecedores já traz cláusula de não treinamento com o dado do cliente e compromisso de retenção curta, que resolve boa parte da preocupação real.
Onde quebra: quando existe exigência formal de que o dado não saia de determinada jurisdição, ou quando o cliente contratante proíbe subprocessador fora da lista dele. Também aperta quando o volume cresce muito e o custo por uso passa a superar o custo de uma infraestrutura dedicada, o que acontece mais tarde do que a maioria imagina.
Para quem não serve: empresa em setor regulado com regra explícita de localidade, e empresa cujo contrato com o cliente final já veda esse arranjo. Fora esses dois casos, sair daqui cedo demais costuma ser uma decisão de ansiedade, e não de risco. Vale conferir uma coisa antes de descartar: o plano corporativo e o plano individual do mesmo fornecedor têm termos muito diferentes sobre uso do dado, e boa parte das empresas que acha estar na opção um está na verdade com o time inteiro em contas pessoais, que é um arranjo pior que qualquer um dos cinco. Migrar de conta pessoal para contrato corporativo resolve mais risco, mais rápido e mais barato do que qualquer mudança de arquitetura desta lista. Vale ler proteção de dados na adoção de IA.
Opção 2: a nuvem regional com contrato corporativo
O que é: o mesmo modelo, servido a partir de uma região específica escolhida pela empresa, com garantia contratual de que processamento e armazenamento acontecem ali. Continua sendo serviço gerenciado, sem infraestrutura própria.
Quando ganha: quando a exigência é de jurisdição e não de isolamento. Resolve a pergunta do questionário de segurança e a conversa com o jurídico sem trazer nenhum peso operacional, porque a empresa segue consumindo um serviço pronto. É o degrau que mais empresas deveriam estar usando e menos empresas conhecem.
Onde quebra: nem todo modelo está disponível em toda região, e a defasagem pode ser de meses entre o lançamento e a disponibilidade regional. O time descobre isso no meio de um projeto, quando pede uma capacidade nova e ela ainda não chegou ali. O preço também costuma ser um pouco maior que o da opção anterior. Existe ainda uma armadilha de leitura no contrato: garantir a região de processamento é diferente de garantir a região de armazenamento de log e de dado de telemetria, e são cláusulas separadas. Já vi empresa fechar a opção dois convencida de que resolveu a pergunta do cliente e descobrir na auditoria seguinte que os registros de uso ficavam em outro lugar. Peça as duas garantias por escrito, com o nome da região em cada uma.
Para quem não serve: quem precisa da versão mais recente do modelo no dia do lançamento, e quem tem exigência de isolamento físico ou lógico que serviço compartilhado não atende por definição. Vale ler soberania de dados e IA, onde o dado é processado.
Leia também
Opção 3: a nuvem privada dedicada
O que é: capacidade reservada para a empresa dentro da nuvem do provedor, com isolamento de rede e, em alguns arranjos, hardware dedicado. Ainda é nuvem, e já exige decisão de arquitetura e alguém acompanhando.
Quando ganha: quando existe exigência de isolamento que o serviço compartilhado não cobre, ou quando o volume é alto e constante o suficiente para que capacidade reservada saia mais barata que consumo avulso. O segundo caso é uma conta objetiva, e vale refazê-la a cada semestre, porque tanto o preço quanto o padrão de uso mudam.
Onde quebra: o custo passa a existir mesmo quando ninguém usa, o que inverte a lógica do consumo variável e pune uso irregular. E aparece a necessidade de alguém dimensionar capacidade, tarefa que exige competência que a maioria das empresas médias não tem em casa.
Para quem não serve: empresa com uso irregular ou sazonal, que vai pagar por capacidade ociosa boa parte do ano. Também não serve para quem está no primeiro projeto, porque a decisão de dimensionar exige um histórico de consumo que ainda não existe. O sinal de que chegou a hora deste degrau é numérico e observável: o consumo mensal ficou previsível dentro de uma faixa estreita por três meses seguidos, e a conta de capacidade reservada para essa faixa sai menor que o gasto por uso. Sem esses dois fatos na mão, subir aqui é apostar, e a aposta é paga em ociosidade todo mês. Vale ler custo unitário de IA e FinOps para o CFO.
Opção 4: on-premise no data center da empresa
O que é: o modelo roda em servidores da própria empresa, dentro do perímetro dela. Nenhum dado sai, e toda a operação é interna, incluindo hardware, atualização, disponibilidade e segurança.
Quando ganha: em regulação pesada, em operação de segurança nacional ou defesa, e em empresa que já tem data center próprio maduro, com time de operação em regime de plantão. Nesses contextos, o custo marginal de somar mais uma carga é razoável, e o benefício de conformidade é imediato.
Onde quebra: quase em todo o resto. Hardware acelerado é caro, tem fila de entrega e envelhece rápido. Manter disponibilidade exige plantão, e manter o modelo atualizado exige uma competência que compete no mercado com quem paga muito mais. A empresa entra achando que compra independência e descobre que comprou uma operação nova.
Para quem não serve: empresa sem data center próprio já operando e sem time de plantão. A conta que engana aqui é comparar o custo do servidor com a fatura da nuvem, esquecendo pessoas, energia, redundância e o tempo até o primeiro resultado, que passa de semanas para trimestres. Há um efeito colateral que raramente entra na decisão e cobra caro depois: quando a infraestrutura é própria, cada atualização de modelo vira um projeto interno com fila e janela de manutenção, em vez de uma melhoria que chega sozinha. A empresa congela numa versão e leva meses para acompanhar o que o mercado já tem, o que corrói exatamente a vantagem que motivou o investimento.
Opção 5: modelo aberto na infraestrutura da empresa
O que é: um modelo de pesos abertos, hospedado pela empresa em nuvem própria ou em servidor local. Combina a liberdade de escolher e adaptar o modelo com a responsabilidade inteira de operá-lo.
Quando ganha: quando existe um caso de altíssimo volume e escopo estreito, em que um modelo menor e ajustado entrega o suficiente por uma fração do custo por chamada. Ganha também quando a empresa precisa de controle total sobre versão, porque não pode aceitar que o comportamento mude sem aviso, o que acontece com modelo gerenciado.
Onde quebra: exige competência de engenharia de aprendizado de máquina que é escassa e cara, e exige mantê-la, porque o campo muda rápido. O modelo aberto de hoje fica atrás do gerenciado de amanhã, e alcançar de novo custa trabalho. Sem alguém dedicado, o ativo envelhece em silêncio.
Para quem não serve: qualquer empresa cuja vantagem não esteja na tecnologia em si. Para a maioria, adaptar modelo é o tipo de trabalho que parece estratégico e é infraestrutura. Vale separar duas coisas que costumam vir embaladas juntas nesta conversa: usar um modelo aberto e ajustar um modelo aberto. Usar é relativamente simples e cabe em times pequenos. Ajustar exige dado rotulado, ciclo de avaliação e alguém que saiba dizer se a versão nova ficou melhor ou pior, e é a segunda parte que consome orçamento e some do escopo original. Vale ler treinar modelo com dado da empresa vale a pena.
Leia também
Como as cinco convivem na mesma empresa
Nenhuma empresa madura fica em uma opção só, e tratar a decisão como escolha única é o que trava a conversa. O arranjo mais comum e mais saudável combina duas: a opção um ou dois para o uso geral do time, que é a maior parte do volume e o menor risco, e um degrau acima apenas para o punhado de processos que carrega dado sensível ou exigência contratual.
Essa separação exige uma coisa que a maioria não tem: a classificação de qual processo usa qual caminho, escrita e visível para quem trabalha. Sem isso, o degrau caro é contratado e ninguém sabe quando usá-lo, então ou fica ocioso ou o time usa o caminho errado por conveniência.
A pergunta de gestão que sustenta o arranjo é simples de fazer e desconfortável de responder: hoje, uma pessoa da operação sabe dizer em qual dos caminhos ela deve rodar a tarefa que tem na mão? Quando a resposta é não, o problema mora na comunicação e não na arquitetura, e comprar outro degrau não resolve nada.
O mapa em uma tabela
| opção | quando ganha | onde quebra | time que exige |
|---|---|---|---|
| API pública | começo e maioria dos casos | exigência de jurisdição ou de subprocessador | nenhum dedicado |
| Nuvem regional | jurisdição sem isolamento | modelo novo demora a chegar ali | nenhum dedicado |
| Nuvem privada dedicada | isolamento ou volume alto e constante | uso irregular paga ociosidade | quem dimensiona capacidade |
| On-premise | regulação pesada com data center pronto | custo, fila de hardware e plantão | operação em regime de plantão |
| Modelo aberto próprio | volume altíssimo com escopo estreito | envelhece sem alguém dedicado | engenharia de aprendizado |
As quatro perguntas que decidem entre elas
Guarde estas quatro para a reunião em que a decisão for tomada. Elas funcionam porque tratam de consequência prática, que é o terreno onde argumento genérico sobre segurança não sustenta.
Anote as respostas antes de olhar preço. Quase toda escolha ruim desta lista foi feita começando pela planilha de custo, e a planilha é justamente a parte que muda com mais facilidade depois.
Pergunta 1: que dado passa por ali de verdade?
Não o dado que poderia passar em teoria, e sim o que passa nos processos que já estão desenhados. Em boa parte dos casos corporativos, o que trafega é texto de trabalho sem identificador de pessoa, e a exigência que justificaria os degraus três a cinco simplesmente não existe.
Quando existe dado sensível de verdade, a pergunta seguinte é se ele precisa passar. Mascarar identificador antes de enviar resolve mais casos que trocar de arquitetura, e custa infinitamente menos.
Leia também
Pergunta 2: quem opera isso no dia seguinte?
Peça o nome do cargo. Se a resposta for a área de tecnologia genericamente, o degrau escolhido provavelmente está acima do que a casa sustenta. Operação de infraestrutura de IA não é a mesma competência de manter um ERP, e a diferença aparece no primeiro incidente.
A resposta boa é específica e desconfortável, do tipo dois analistas com plantão revezado e um fornecedor de retaguarda com prazo contratado. Quando ela vem vaga, o risco deixa de ser técnico e passa a ser organizacional.
Pergunta 3: qual é a conta quando o uso dobrar?
Consumo variável e capacidade reservada se comportam de forma oposta quando o uso cresce, e o ponto de cruzamento entre os dois é o número que decide entre a opção dois e a opção três. Peça a projeção em três cenários, com a premissa de cada um declarada.
O erro comum é projetar a partir do piloto, em que poucas pessoas usavam pouco. Uso maduro não é uso inicial multiplicado por gente, porque quem fica bom pede tarefas maiores.
Pergunta 4: o que acontece se você quiser trocar?
Pergunte em que formato a empresa leva embora o que construiu: as instruções, os fluxos, o histórico e as avaliações de qualidade. Arquitetura que prende costuma prender pelo redesenho de processo em volta dela, e não pelo dado em si.
Quanto mais pesado o degrau, maior o custo de reverter. Essa assimetria é o argumento mais forte para começar leve e subir só com exigência na mão. Vale ler dependência de fornecedor de IA e o lock-in.
Leia também
Os três erros de escolha que eu mais vejo
O primeiro é escolher pelo pior cenário imaginável em vez do dado real. A empresa desenha a arquitetura para o caso mais sensível que ela consegue imaginar, e paga por isso em todos os outros, que são a maioria absoluta do uso.
O segundo é trazer para dentro por desconfiança genérica. Trazer para dentro transfere o risco de terceiro para o risco próprio, e o risco próprio depende de um time de plantão que precisa existir. Em várias empresas médias, a infraestrutura interna é menos segura que a do provedor, e ninguém faz essa comparação em voz alta.
O terceiro é decidir uma vez e nunca revisar. As cinco opções mudam de preço e de disponibilidade em ritmo trimestral, e a escolha certa do ano passado pode estar cara agora. Vale reabrir a conta a cada renovação, mesmo satisfeito.
Quando nenhuma destas cinco opções resolve a sua pergunta
Existe um caso em que a lista inteira não ajuda: quando a preocupação real não é de hospedagem, e sim de comportamento. Empresa que teme o que o modelo pode responder ao cliente não resolve isso mudando de região nem trazendo servidor para dentro. Isso se resolve com revisão humana, monitoria por amostra e limite de escopo, que são decisões de processo e independem de onde a máquina está.
O segundo caso é a empresa em setor regulado com regra explícita do regulador. Ali a escolha já foi feita por quem regula, e o trabalho é de conformidade e não de arquitetura. Começar pelas cinco opções nesse contexto atrasa a conversa que importa. Vale ler agente de IA em setor regulado.
E vale nomear o caso mais frequente de todos: a empresa que ainda não tem nada em produção. Escolher arquitetura antes de existir uso real é planejar para uma operação imaginária, e a decisão vai ser refeita quando a operação aparecer de verdade.
A régua que eu deixo com o líder
Antes da próxima reunião sobre isso, responda as quatro perguntas por escrito, em três linhas cada. Se você não conseguir responder a primeira com o dado real que trafega hoje, essa é a tarefa, e ela vem antes de qualquer decisão de arquitetura. Levantar isso costuma tomar uma tarde de trabalho com duas pessoas da operação, e o resultado quase sempre reduz o degrau necessário em vez de aumentar.
E aplique a regra do degrau: só suba quando existir uma exigência escrita que o degrau atual não atende. Exigência escrita significa cláusula de contrato, norma setorial ou determinação de regulador. Preocupação sem documento é uma conversa legítima e não é motivo para multiplicar custo e prazo por três.
Uma última observação sobre o timing desta decisão. Ela parece urgente porque chegou por uma pergunta externa, e a urgência aparente empurra para o degrau mais pesado como forma de encerrar o assunto de uma vez. O caminho que se sustenta é o oposto: responder a pergunta externa com o que já existe hoje, documentar honestamente o que falta, e mudar de degrau depois, com número na mão. Cliente grande aceita muito bem uma resposta precisa sobre um arranjo simples, e desconfia de uma resposta vaga sobre um arranjo sofisticado.