Red Hat has released Red Hat AI 3.5 with a set of controls aimed at turning AI platforms into shared production infrastructure rather than collections of isolated model endpoints. The release brings EvalHub to general availability, adds automated adversarial scanning for validated models, expands multi-tenant GPU controls, introduces per-user usage visibility, and adds agent-oriented templates and retrieval tooling. Red Hat says the release is generally available.
The useful part for platform teams is not the breadth of the feature list by itself. Several capabilities now sit directly in the infrastructure path: model evaluation can produce structured evidence before deployment, identity can be tied to model access through external OIDC, priority-aware serving can decide which inference traffic gets capacity, and usage can be attributed to users. That combination starts to make AI governance an operating-system concern for the platform team rather than a separate policy document.
Evaluation moves closer to a release gate
EvalHub is one of the clearest production changes in OpenShift AI 3.5. Red Hat's release notes mark EvalHub as generally available and describe support for models, applications, agents, tools, vulnerability assessment and scanning. The release also adds an SDK and CLI, automated red teaming powered by Garak, and standardized evaluation cards that can preserve metadata, results, provenance and pass/fail outcomes.
That matters because evaluation becomes easier to attach to CI/CD and deployment decisions. A team can treat an evaluation job as evidence that travels with a model or agent release instead of keeping benchmark results in a notebook or dashboard that is disconnected from the deployment process.
There is still an important boundary. A generated evaluation card does not prove that the chosen benchmark is sufficient, that the judge is unbiased, or that a model is safe for a specific business process. Red Hat is making the evidence easier to produce and operationalize; organizations still have to define what evidence is required and who is allowed to accept it.
Identity, priority and cost become part of model serving
OpenShift AI 3.5 can connect Models-as-a-Service access to an external OpenID Connect identity provider. Groups can be mapped to subscriptions and API keys can be scoped through those memberships. Red Hat also describes fair-share GPU scheduling, priority-aware serving, token-consumption showback and stronger tenant isolation using hosted control planes and virtualization.
Taken together, these features change the control boundary. The platform can increasingly answer who is allowed to call a model, which workload should win when capacity is scarce, and who consumed the resources. Those are the same questions that mature infrastructure teams already ask of databases, clusters and internal APIs.
For AI, however, resource policy and model policy can interact. A low-priority batch evaluation may be delayed while a user-facing agent receives capacity; a quota can constrain an agent even when its application logic would otherwise continue; an identity rule can block access to a model that the code knows how to call. Platform teams therefore need to test failure behavior around these controls, not just confirm that the happy path works.
Agent tooling is becoming a platform feature
Red Hat AI 3.5 adds AutoRAG enhancements, agent templates for patterns such as code review and document processing, support for the Responses API, and guardrail integration. The release also promotes automated red teaming and evaluation services that can be used around agents rather than only around base models.
This is a useful architectural shift. Agent frameworks often begin as application dependencies, with permissions, retrieval, evaluation and tracing assembled independently by each development team. Red Hat is moving more of those concerns into a shared platform layer where they can be standardized.
The trade-off is coupling. Standardized platform controls reduce duplicated engineering, but they also make agent behavior depend on cluster configuration, routing, identity and evaluation services. Teams adopting these capabilities should version the platform policy and runtime configuration alongside application releases so that an agent regression can be distinguished from an infrastructure-policy change.
The release is not uniformly production-ready
The headline "Red Hat AI 3.5 is generally available" can hide an important detail: not every capability associated with the 3.5 line has the same support status. Red Hat's own documentation lists several features under Technology Preview. Centralized platform observability with its dedicated metrics, tracing and alerting stack is one example, and some EvalHub log-access capabilities are also preview features.
That distinction matters for architecture decisions. A platform team should not infer that every dashboard, telemetry path or experimental integration mentioned around the 3.5 release carries the same production support commitment as EvalHub GA or other supported features.
Aipolix's practical reading is to build a support-status matrix before adoption. Separate GA controls that can be placed on a production critical path from Technology Preview or Developer Preview capabilities that should remain optional, replaceable or isolated. This avoids designing a governance process whose audit trail or incident response depends on a component that Red Hat itself does not yet recommend as a fully supported production feature.
Governance is becoming infrastructure, but evidence still needs ownership
Red Hat AI 3.5 is significant because it combines evaluation, access control, workload scheduling, cost attribution and agent tooling in one operational layer. That makes it easier to treat AI as a governed internal service instead of a collection of team-specific integrations.
The harder organizational question does not disappear. EvalHub can run the test, OIDC can identify the caller and serving controls can enforce capacity policy, but someone still has to decide which tests are mandatory, what score is acceptable, how exceptions are approved, and which preview components may be used in a regulated path.
For engineering leaders, the useful next step is therefore not simply to enable every 3.5 feature. Map each control to an owner and a support tier, then connect the GA pieces to existing release, identity, incident and FinOps processes. Red Hat has moved more governance mechanisms into the platform; organizations still need to define the contracts those mechanisms enforce.