IA já não é um projeto experimental

O Red Hat AI 3.5 aponta para uma mudança importante na forma como as empresas terão de gerir inteligência artificial. À medida que os projetos abandonam a fase experimental, modelos, agentes e os  GPU começam a exigir as mesmas regras de segurança, controlo de custos, isolamento e auditoria aplicadas ao resto da infraestrutura tecnológica.
10 de Setembro, 2026
Imagem gerada por IA

A discussão empresarial sobre inteligência artificial começa a mudar de natureza. Durante os últimos ciclos de adoção, grande parte da atenção esteve concentrada em colocar modelos a funcionar, testar casos de utilização e demonstrar que a tecnologia conseguia produzir resultados. Com o Red Hat AI 3.5, a Red Hat coloca o problema noutro nível: quando a IA entra efetivamente em produção, deixa de ser apenas uma aplicação e passa a comportar-se como infraestrutura crítica.

É esta transição que explica boa parte das funcionalidades agora introduzidas. A plataforma permite avaliar modelos antes da entrada em produção através do EvalHub, acompanhar desempenho, consumo dos GPU e utilização de tokens, criar métricas de utilização por utilizador e aplicar mecanismos de governação sobre agentes de IA. Para um CIO, isto aproxima a gestão da inteligência artificial de disciplinas já conhecidas nas operações de TI: saber quem utiliza recursos, quanto consome, quais as cargas prioritárias, que riscos existem e como demonstrar que determinados controlos foram aplicados.

O custo computacional é uma das peças centrais deste problema. À medida que diferentes equipas passam a partilhar infraestrutura de IA, a GPU deixa de ser apenas hardware especializado e transforma-se num recurso empresarial que precisa de ser distribuído, medido e prioritizado. O Red Hat AI 3.5 introduz mecanismos de agendamento entre diferentes utilizadores, controlo de prioridades e capacidade de ajustar dinamicamente os recursos utilizados de acordo com a complexidade dos pedidos. Na prática, a gestão financeira da IA começa a aproximar-se do FinOps: é necessário relacionar utilização, capacidade computacional e custo com equipas, serviços e cargas de trabalho concretas.

A multi-tenancy reforça essa lógica. Organizações que utilizem a mesma infraestrutura para diferentes departamentos, clientes ou serviços podem separar ambientes através de planos de controlo dedicados, mantendo a consolidação do hardware subjacente. O suporte de workloads de IA em máquinas virtuais sobre OpenShift Virtualization acrescenta isolamento ao nível da VM, procurando responder a uma questão que se torna mais relevante à medida que as GPU são partilhadas: como aumentar a utilização de um recurso caro sem misturar ambientes que precisam de permanecer separados.

A segurança deixa igualmente de estar limitada ao perímetro tradicional da infraestrutura. Os modelos validados passam a incluir indicadores de segurança, exposição de informação pessoal e risco de toxicidade, enquanto mecanismos como o EvalHub procuram tornar auditável a avaliação realizada antes da entrada em produção. Nos agentes, o problema estende-se às ações que o software pode executar. A integração de mecanismos de controlo sobre chamadas a ferramentas procura impedir que um agente transforme uma instrução maliciosa numa ação efetiva sobre os sistemas a que tem acesso. Quanto maior for a autonomia concedida aos agentes, maior será a necessidade de tratar as suas permissões e comportamento como uma questão de governação tecnológica.

O mesmo princípio surge no RAG, a técnica que permite ligar modelos de IA a informação interna das organizações. O AutoRAG aproxima repositórios empresariais das aplicações baseadas em agentes e acrescenta suporte para documentos multilingues, testes conversacionais e mecanismos de recuperação contextual. A existência de uma pipeline visual para testar estas configurações antes da implementação procura reduzir uma das dificuldades da passagem dos protótipos para produção: garantir que um sistema continua a responder sobre a informação correta quando começa a operar com dados empresariais reais.

A Red Hat acrescenta ainda modelos previamente validados, modelos preparados para utilização de ferramentas e templates de agentes para tarefas como revisão de código, processamento documental e investigação. Ao mesmo tempo, expande a execução distribuída para ambientes Kubernetes de terceiros e introduz mecanismos para gerir atualizações de modelos e tráfego durante essas transições. O objetivo comum é reduzir a distância entre desenvolver uma experiência de IA e operar continuamente esse sistema dentro de uma arquitetura híbrida.

Para os CIO, talvez seja essa a parte mais relevante do Red Hat AI 3.5. A questão já não é apenas saber que modelo utilizar, mas definir quem o pode usar, com que dados, sobre que infraestrutura, com que nível de isolamento, a que custo e segundo que regras. Segurança, observabilidade, consumo dos GPU, contabilização de tokens e governação de agentes começam a convergir na mesma camada operacional.

A inteligência artificial empresarial está, assim, a entrar numa fase menos visível do que a corrida aos modelos, mas potencialmente mais determinante para a sua adoção. Depois dos pilotos vem a infraestrutura. E, quando isso acontece, a IA passa a ter de responder às mesmas perguntas que qualquer outro sistema crítico: quanto custa, quem controla, quem utiliza e o que acontece quando alguma coisa corre mal.

Opinião