Por Jorge Ramos
Contexto, motivações e limites
A adoção da inteligência artificial generativa começou, para muitas empresas, pela nuvem. Era o caminho mais simples: contratar um serviço, obter acesso a uma API e começar a testar. Em pouco tempo, equipes passaram a usar modelos de IA para resumir documentos, gerar código, apoiar o atendimento e automatizar tarefas.
Quando esses experimentos começam a se transformar em aplicações de uso contínuo, porém, aparecem perguntas que não eram tão importantes na fase inicial. Onde os dados estão sendo processados? Quem controla a versão do modelo? Como o custo se comportará quando o número de usuários crescer? O serviço pode depender inteiramente de um fornecedor externo? E como integrar o modelo a documentos, bancos de dados e sistemas internos sem ampliar desnecessariamente a exposição das informações?
É nesse contexto que a execução de modelos em infraestrutura própria – também chamada de on premises – volta à discussão. Não como substituta automática da nuvem, mas como mais uma opção dentro da arquitetura de tecnologia da empresa.
Uma alternativa que se tornou viável
Durante algum tempo, executar modelos de linguagem fora dos grandes provedores parecia uma possibilidade restrita a centros de pesquisa e empresas com datacenters de grande porte. O hardware era caro, os modelos disponíveis eram limitados e as ferramentas exigiam um trabalho considerável de integração.
Esse cenário mudou. Hoje existem modelos de pesos abertos em diferentes tamanhos, capazes de rodar em computadores pessoais, estações de trabalho ou servidores. OpenAI, Mistral e Qwen, por exemplo, disponibilizam famílias de modelos que podem ser executadas em ambientes controlados pela própria organização, embora com licenças, requisitos de hardware e características diferentes.
A camada de software também amadureceu. Projetos como o vLLM já oferecem recursos típicos de ambientes de produção, como gerenciamento eficiente da memória de atenção, processamento contínuo de requisições, quantização, execução distribuída e uma API compatível com a da OpenAI. Isso não elimina a complexidade, mas reduz a necessidade de construir toda a plataforma a partir do zero.
Ao mesmo tempo, fornecedores tradicionais passaram a oferecer plataformas empresariais para esse tipo de implantação. O NVIDIA AI Enterprise reúne frameworks, microsserviços de inferência, drivers, operadores para Kubernetes e ferramentas de gestão de clusters para ambientes de nuvem, datacenter e borda. O Red Hat OpenShift AI permite desenvolver e operar modelos em instalações próprias, nuvens públicas, ambientes de borda e até locais desconectados. A HPE, por sua vez, oferece uma solução integrada de hardware e software voltada a inferência, integração com dados corporativos e ajuste fino de modelos.
Esse conjunto de ofertas mostra que a IA em infraestrutura própria deixou de ser apenas uma montagem experimental. Já existe um mercado formado por modelos, ambientes de execução, plataformas de orquestração, servidores, aceleradores e serviços de suporte.
Isso não significa que qualquer empresa esteja pronta para operar seus próprios modelos, nem que todo caso de uso justifique o investimento. Significa apenas que a alternativa passou a ser tecnicamente possível para uma faixa bem maior de organizações.
Por que uma empresa consideraria esse caminho?
A resposta mais frequente é a proteção dos dados, mas ela precisa ser entendida com cuidado.
Executar um modelo em ambiente próprio pode dar à empresa maior controle sobre onde os dados são processados, quais sistemas podem acessá-los e como as interações são registradas. Para uma equipe jurídica que pretende pesquisar milhares de contratos, ou para uma instituição financeira que precisa analisar procedimentos internos e informações de clientes, esse controle pode ser decisivo.
No Brasil, a ANPD chama atenção para os riscos associados ao uso de dados pessoais em sistemas de IA generativa, incluindo compartilhamento de informações, geração de conteúdo sintético e uso de dados para finalidades diferentes das originalmente previstas. A autoridade também relaciona esses riscos aos princípios de transparência e necessidade previstos na LGPD.
Manter a inferência dentro do ambiente da empresa pode reduzir alguns fluxos de dados para terceiros, mas não torna a solução automaticamente segura ou aderente à legislação. Ainda é necessário definir finalidade, acesso, retenção, auditoria e proteção das informações. Além disso, algumas plataformas instaladas localmente continuam dependendo de serviços externos para licenciamento, atualização, telemetria ou administração. A arquitetura precisa ser verificada como um todo.
Outra motivação é o controle tecnológico. Ao operar os modelos diretamente, a empresa pode decidir quando atualizar uma versão, quais modelos estarão disponíveis, que limites serão aplicados e como as aplicações serão integradas aos sistemas internos. Isso reduz algumas dependências externas, mas transfere para a própria organização responsabilidades que antes estavam com o provedor.
O custo também entra na análise. Uma API em nuvem costuma ser atraente para testes e volumes moderados, pois não exige investimento inicial. Quando a utilização se torna intensa e previsível, uma infraestrutura dedicada pode se tornar competitiva. Mas não existe uma resposta geral.
A comparação precisa considerar o custo total: servidores, aceleradores, armazenamento, energia, refrigeração, espaço físico, licenças, suporte, equipe, substituição de equipamentos e períodos de baixa utilização. Do outro lado, também devem entrar consumo de tokens, transferência de dados, serviços auxiliares, compromissos de uso e variações tarifárias da nuvem. O FinOps Framework recomenda que decisões desse tipo sejam baseadas em uso, custo, valor de negócio e economia unitária, incluindo a escolha do ambiente mais adequado para cada carga de trabalho.
Portanto, infraestrutura própria não é necessariamente mais barata. Ela tende a ser mais previsível quando a demanda é relativamente estável e os equipamentos permanecem bem utilizados. Um cluster caro, ocioso durante boa parte do tempo, dificilmente será uma boa decisão financeira.
A latência é outro fator. Quando o modelo está próximo das aplicações e das fontes de dados, a empresa pode evitar parte do tráfego externo e reduzir atrasos de rede. Esse benefício pode ser importante em instalações industriais, ambientes com conectividade limitada e processos interativos. Ainda assim, manter o modelo local não garante automaticamente uma resposta mais rápida: o tamanho do modelo, o hardware, a quantidade de usuários e o software de inferência também influenciam o desempenho.
Por fim, existe a continuidade operacional. Uma empresa pode decidir que algumas aplicações não devem depender exclusivamente da disponibilidade, da política comercial ou da conectividade de um serviço externo. Nesse caso, manter capacidade própria reduz determinada forma de dependência.
Mas é importante não confundir independência com alta disponibilidade. Um único servidor local pode ser menos resiliente do que um serviço de nuvem distribuído. Para que a infraestrutura própria contribua de fato para a continuidade, ela precisa de redundância, capacidade de recuperação, monitoramento, manutenção planejada e procedimentos de contingência.
Onde a infraestrutura própria tende a fazer mais sentido
Não há uma regra única, mas alguns sinais ajudam.
O primeiro é a presença de dados sensíveis ou sujeitos a controle rigoroso. Documentos jurídicos, informações financeiras, propriedade intelectual, código-fonte, registros de saúde e dados pessoais são exemplos comuns.
O segundo é um volume de uso relativamente estável. Quanto mais previsível for a carga, mais fácil será dimensionar os equipamentos e comparar seu custo com o consumo de serviços externos.
O terceiro é a necessidade de integração profunda com sistemas internos. Um modelo que precisa consultar documentos, executar processos ou produzir respostas de acordo com as permissões de cada usuário não funciona isoladamente. Ele passa a fazer parte da arquitetura corporativa.
O quarto é a necessidade de customização. Em alguns projetos, a empresa quer escolher o modelo, controlar a versão, aplicar ajustes específicos, definir políticas próprias de segurança ou manter determinadas configurações em produção durante períodos mais longos.
O quinto é a capacidade operacional. Organizações que já administram contêineres, Kubernetes, monitoramento, segurança de redes e plataformas de dados partem de uma posição melhor. Mesmo assim, precisarão desenvolver conhecimentos específicos sobre modelos generativos, avaliação de respostas e uso de aceleradores.
Entre os casos de uso mais naturais estão pesquisa em documentos internos, assistentes especializados, apoio ao desenvolvimento de software, classificação e extração de informações, análise de contratos, atendimento interno e automação de atividades repetitivas.
As ofertas atuais dos fornecedores refletem esse tipo de demanda. O HPE Private Cloud AI, por exemplo, é direcionado principalmente a inferência, RAG e ajuste fino, e não à tentativa de reproduzir em pequena escala o treinamento de modelos de fronteira.
Os limites aparecem rapidamente
A primeira barreira é o investimento. A quantidade de memória necessária para executar um modelo, o número de usuários simultâneos e o tempo de resposta esperado podem levar a configurações muito diferentes. Comprar antes de medir é uma maneira eficiente de investir demais ou adquirir uma solução que não suporta a carga real.
A segunda é a operação. Não basta instalar um modelo e disponibilizar uma interface de conversa. Um serviço corporativo precisa de autenticação, autorização, limites de consumo, filas, monitoramento, atualização, testes, cópias de segurança e procedimentos de recuperação.
Também é necessário observar a qualidade das respostas. Modelos generativos podem produzir informações incorretas, variar a resposta diante de entradas semelhantes ou seguir instruções maliciosas contidas em documentos e mensagens. O NIST recomenda que os riscos da IA generativa sejam tratados ao longo de todo o ciclo de vida, com atividades de governança, medição, avaliação e gestão.
A segurança apresenta desafios próprios. O OWASP Top 10 para aplicações baseadas em modelos de linguagem inclui riscos como injeção de prompts, divulgação de informações sensíveis, tratamento inadequado das respostas e concessão excessiva de autonomia a agentes. Esses problemas existem tanto na nuvem quanto em ambientes próprios.
Por isso, a palavra “local” não deve ser confundida com “seguro”. Um servidor dentro da empresa continua sujeito a erros de configuração, credenciais expostas, dependências vulneráveis e acessos indevidos. Se o modelo puder executar ferramentas ou consultar sistemas internos, uma integração mal desenhada pode ampliar o impacto de um incidente.
A velocidade de evolução do mercado traz outro risco. Novos modelos, técnicas de quantização e ambientes de execução surgem em intervalos curtos. O equipamento adquirido hoje deverá permanecer em uso durante anos, mas a camada de software pode mudar em poucos meses. Arquiteturas excessivamente presas a um único modelo, formato ou fornecedor podem envelhecer cedo.
Há ainda o limite de qualidade. Modelos menores, executados localmente, podem atender muito bem a tarefas delimitadas, mas não necessariamente alcançam o desempenho dos modelos mais avançados disponíveis como serviço. A escolha deve ser feita com testes representativos do trabalho real da empresa, e não apenas com rankings públicos ou alegações do fornecedor.
A nuvem não deixa de fazer sentido
A discussão costuma ser apresentada como uma disputa entre nuvem e infraestrutura própria. Na prática, essa divisão raramente ajuda.
A nuvem continua oferecendo vantagens importantes: contratação rápida, elasticidade, acesso imediato a modelos avançados e ausência de investimento inicial em hardware. Para experimentos, cargas irregulares ou projetos que ainda não comprovaram valor, ela pode ser a escolha mais prudente.
A infraestrutura própria oferece outras qualidades: maior controle sobre o processamento, proximidade dos dados, possibilidade de operação desconectada e maior liberdade para escolher modelos e versões.
As próprias plataformas empresariais atuais são desenhadas para ambientes híbridos. NVIDIA AI Enterprise, Red Hat OpenShift AI e HPE Private Cloud AI preveem a coexistência entre datacenter, nuvem pública, borda e ambientes privados, em vez de tratar essas opções como excludentes.
Uma arquitetura híbrida pode, por exemplo, usar um modelo local para documentos confidenciais e recorrer a um serviço externo para tarefas genéricas. A empresa também pode manter a inferência cotidiana em seu ambiente e usar a nuvem durante picos de demanda ou em experimentos com modelos novos.
A pergunta mais útil, portanto, não é “nuvem ou infraestrutura própria?”. É “qual carga deve rodar em cada ambiente?”.
O projeto deve começar pelo problema
A compra do hardware é uma das últimas decisões, não a primeira.
O ponto de partida é identificar um problema concreto. Qual atividade será melhorada? Quem usará a solução? Quanto tempo ou dinheiro ela pode economizar? Que tipo de erro seria aceitável? Quais informações serão processadas?
Depois vêm as perguntas técnicas e operacionais. O modelo precisa consultar fontes internas? Deve informar de onde retirou cada resposta? Haverá revisão humana? Quantas pessoas usarão o sistema ao mesmo tempo? Qual tempo de resposta é aceitável? O serviço precisa continuar funcionando durante uma falha de internet ou de um componente?
Essas respostas ajudam a definir o tamanho do modelo, a arquitetura de integração, os requisitos de segurança, a disponibilidade necessária e a capacidade de processamento. Sem elas, qualquer dimensionamento será pouco mais que uma estimativa.
Um projeto inicial deve ser pequeno o suficiente para ser controlado, mas real o suficiente para produzir medidas úteis. Em vez de instalar uma plataforma ampla para “usar IA”, faz mais sentido escolher um processo, reunir dados representativos e avaliar qualidade, custo, desempenho e aceitação pelos usuários.
Conclusão
A execução de IA em infraestrutura própria voltou à agenda porque se tornou tecnicamente viável para um número maior de empresas. Há modelos de pesos abertos mais capazes, ambientes de execução mais maduros e plataformas comerciais que reduzem parte do trabalho de implantação.
Isso não transforma a infraestrutura própria em resposta universal. O investimento pode ser alto, a operação exige especialização e os modelos mais avançados nem sempre estão disponíveis para execução local. Além disso, manter os dados dentro da empresa aumenta o controle, mas não elimina os riscos de segurança, privacidade e governança.
O avanço está justamente na possibilidade de escolha. As empresas podem manter alguns modelos e dados sob controle direto, consumir outros como serviço e combinar as duas abordagens conforme o risco, o custo e a necessidade de cada aplicação.
Para arquitetos e gestores de tecnologia, esse é o ponto central: decidir conscientemente o que deve permanecer dentro da organização, o que pode ser processado fora dela e quais capacidades precisam ser construídas para sustentar essa divisão.
Referências
- ANPD (Agência Nacional de Proteção de Dados) – Radar Tecnológico: Inteligência Artificial Generativa
- FinOps Foundation – FinOps Framework
- HPE – HPE Private Cloud AI QuickSpecs
- NIST – Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile
- NVIDIA – NVIDIA AI Enterprise
- OpenAI – Apresentamos o gpt-oss
- OWASP – Top 10 for LLM Applications 2025
- Red Hat – Red Hat OpenShift AI
- vLLM – Documentação oficial