A Red Hat lançou o Red Hat AI 3.5 com um conjunto de controlos pensado para transformar a infraestrutura de IA num serviço de produção partilhado, em vez de uma coleção de pontos de acesso isolados a modelos. O EvalHub passou a disponibilidade geral, a validação adversarial dos modelos foi reforçada, os mecanismos de partilha de GPU evoluíram e a plataforma ganhou maior visibilidade sobre consumo, além de novas ferramentas para aplicações com agentes.
A principal mudança não está na extensão da lista de funcionalidades. Vários controlos passam a fazer parte do próprio funcionamento da plataforma: é possível produzir evidência de avaliação antes da entrada em produção, ligar o acesso aos modelos à identidade empresarial, estabelecer prioridades para pedidos de inferência e atribuir consumo a utilizadores. A governação de IA aproxima-se, assim, das responsabilidades normais de uma equipa de plataforma.
A avaliação aproxima-se da decisão de lançamento
O EvalHub é uma das alterações mais claras do OpenShift AI 3.5. A documentação da Red Hat indica que o serviço está agora em disponibilidade geral e pode orquestrar avaliações de modelos, aplicações, agentes, ferramentas e testes de vulnerabilidade. A versão inclui ainda SDK, linha de comandos, testes adversariais automatizados com Garak e cartões estruturados de avaliação.
Para as equipas de engenharia, isto permite integrar a avaliação no processo de entrega. Em vez de deixar resultados num notebook ou num painel separado, torna-se possível guardar evidência estruturada com cada versão e utilizá-la numa decisão de promoção para produção.
Há, porém, uma limitação importante. Um cartão de avaliação não demonstra que o conjunto de testes escolhido é suficiente para um processo de negócio, que o avaliador não tem enviesamentos ou que determinada pontuação garante segurança. A Red Hat facilita a produção e conservação da evidência; a organização continua responsável por definir os critérios de aceitação e quem os pode aprovar.
Identidade, prioridade e custo entram no serviço de modelos
O OpenShift AI 3.5 permite ligar Models-as-a-Service a um fornecedor externo de identidade através de OpenID Connect. Os grupos podem ser associados a subscrições e direitos de acesso. A Red Hat descreve também partilha equitativa de GPU, encaminhamento de pedidos por prioridade, visibilidade do consumo de tokens por utilizador e maior isolamento entre entidades que partilham a infraestrutura.
Em conjunto, estas funções alteram a fronteira de controlo. A plataforma passa a responder melhor a três perguntas: quem pode utilizar determinado modelo, que pedido deve ter prioridade quando falta capacidade e a quem deve ser atribuído o consumo. São problemas conhecidos das equipas que já gerem bases de dados, clusters e API internas.
Nos sistemas de IA, contudo, uma política de recursos pode alterar diretamente o comportamento da aplicação. Uma avaliação em segundo plano pode ser atrasada para favorecer um agente interativo; uma quota pode interromper uma tarefa; uma regra de identidade pode impedir o acesso a um modelo que o código sabe utilizar. Por isso, os cenários de falha e recuperação precisam de ser testados explicitamente.
Os agentes passam a ser também uma preocupação da plataforma
O Red Hat AI 3.5 amplia o AutoRAG, acrescenta modelos de arranque para casos como revisão de código e processamento documental, suporta Responses API e aproxima os mecanismos de proteção da execução. Os serviços de avaliação e teste de segurança também podem ser aplicados a agentes.
Esta evolução é relevante porque muitas equipas ainda montam permissões, recuperação de informação, avaliação e rastreio separadamente em cada aplicação. Levar parte dessas responsabilidades para uma camada partilhada permite estabelecer padrões comuns.
O preço dessa normalização é maior dependência da plataforma. O comportamento de um agente pode mudar por causa da configuração do cluster, de uma regra de identidade, do encaminhamento ou do serviço de avaliação, mesmo quando o código da aplicação não mudou. As políticas e configurações operacionais devem, por isso, ser versionadas juntamente com as aplicações.
Nem tudo o que pertence à versão 3.5 tem o mesmo nível de suporte
O anúncio afirma que o Red Hat AI 3.5 está disponível de forma geral, mas isso não significa que todas as funcionalidades associadas à versão 3.5 tenham o mesmo grau de maturidade. A documentação oficial ainda classifica várias capacidades como Technology Preview. A observabilidade centralizada, com métricas, rastreio distribuído e alertas, é um desses casos; algumas formas de acesso aos registos do EvalHub também continuam em pré-visualização.
Esta diferença é importante numa arquitetura de produção. Uma equipa não deve concluir que todos os painéis, caminhos de telemetria ou integrações recentes têm o mesmo compromisso de suporte que o EvalHub em disponibilidade geral ou outras funções estabilizadas.
A leitura prática da Aipolix é criar uma matriz de maturidade antes da adoção. Os componentes em disponibilidade geral podem entrar num processo crítico depois de validados; funcionalidades em Technology Preview ou Developer Preview devem permanecer opcionais, isoladas ou substituíveis. Um processo de auditoria ou resposta a incidentes não deve depender sem salvaguardas de uma peça que o próprio fornecedor ainda não recomenda como plenamente suportada em produção.
A infraestrutura executa a política, mas não a define
O Red Hat AI 3.5 aproxima avaliação, controlo de acesso, gestão de capacidade, atribuição de custos e ferramentas para agentes numa única camada operacional. Isso ajuda a tratar a IA como um serviço interno governado, em vez de um conjunto de integrações diferentes em cada equipa.
A decisão de governação continua, no entanto, fora da plataforma. O EvalHub executa testes, o OIDC identifica o utilizador e o serviço de inferência aplica prioridades, mas nenhuma dessas peças decide que testes são obrigatórios, que resultado é aceitável, quem aprova uma exceção ou que funcionalidade experimental pode ser usada num processo regulado.
Para responsáveis de engenharia, o passo seguinte não é ativar tudo o que aparece na versão 3.5. Cada controlo deve ter um responsável e um nível de suporte claramente registados, e os componentes estáveis devem ser ligados aos processos existentes de lançamento, identidade, resposta a incidentes e FinOps. A Red Hat colocou mais mecanismos de governação dentro da infraestrutura; os contratos que esses mecanismos aplicam continuam a ter de ser definidos pela organização.