A team can settle on an AI model and still face a larger infrastructure question: how will the surrounding workflows fit into the organization’s platform? Decisions about platform ownership, existing services, and dedicated infrastructure shape the environment in which AI work is supported. That makes AI infrastructure adoption a platform-engineering concern as well as a model-selection decision.
A recent CNCF and SlashData report focuses on this connection. Its findings offer a useful snapshot of how platform approaches relate to choices around AI workflows—but they should be read as reported associations, not proof that one operating model causes teams to choose a particular design.
What the report examines
The CNCF Technology Radar Q3 2026 report, published on November 10, 2026, examines developer perceptions of cloud-native technologies and how platform-engineering models relate to AI infrastructure choices.[2][3] CNCF’s announcement describes the choices as extending an existing platform, building dedicated AI infrastructure, or using hybrid approaches for AI workflows.[3]
That framing moves the discussion beyond the model itself. A model is one element in a wider technical environment; teams also need to decide how AI-related work fits with the platforms and infrastructure they already manage. The report provides context for considering those choices, rather than a universal prescription for making them.
The announcement and report page refer to the same research. They are useful for different details—the announcement for the study’s framing and the report page for its displayed figures—but they should not be treated as two independent studies confirming the same results.
AI infrastructure adoption: what the figures show
One comparison on the report page concerns developers’ AI workflow approaches. It states that 54% of developers at organizations with independently managed tooling report hybrid AI workflows, compared with 5% at organizations building custom internal platforms.[2][3]
The comparison is notable because the reported percentages differ across the two described groups. It does not, on its own, explain why they differ. Nor does it establish that independently managed tooling leads to hybrid workflows, or that custom internal platforms prevent them. The figures describe an association in the report; they are not a causal test.
That distinction matters for teams interpreting research. A percentage can help identify a question worth asking internally—such as whether a platform model affects how teams combine existing and dedicated infrastructure—without supplying the answer for every organization. The cited figures should also remain attached to their stated populations; they should not be generalized beyond what the report says.
The report page also presents developer assessments of specific cloud-native technologies. These technology-specific findings are not direct measures of AI infrastructure adoption and do not establish which platform approach an organization should take.[2]
Why platform engineering matters alongside model selection
The report’s framing points to a practical consideration: AI workflows do not exist apart from the organization’s platform. Teams may need to consider how those workflows relate to existing infrastructure and who is responsible for supporting the platform around them.
This is editorial analysis, not a conclusion proven by the report. Still, it is a useful way to interpret the distinction between extending a platform, building dedicated infrastructure, or combining approaches. Each represents a different relationship between AI work and existing platform ownership. The report’s 54% versus 5% comparison makes that relationship worth examining, but it does not identify a best-fit option.
For example, a team evaluating a model for an internal application might also ask whether the workflow can be supported through its current platform arrangements, or whether the organization sees a need for a more specialized environment. Those questions are about organizational fit and responsibility as much as model capability. They do not require assuming that all AI work must follow the same infrastructure pattern.
The report announcement also identifies observability, infrastructure as code, and storage as areas it covers.[3] These categories help show that the discussion extends beyond model choice into the broader infrastructure context. Their presence is not, by itself, evidence that every organization needs a particular technology or platform design.
Questions for teams evaluating platform choices
Rather than turning the report into a universal selection framework, teams can use its framing to sharpen an internal discussion:
- Who owns the platform and the AI-related workflows it supports?
- How do those workflows fit with the organization’s current platform approach?
- What observed needs might lead the team to extend existing infrastructure, create a more specialized environment, or combine approaches?
These are prompts for discussion, not implementation steps. A team’s answers will depend on its own operating context; the supplied findings do not establish a single choice that applies across organizations.
For decision-makers, the distinction is important. Model evaluation can answer questions about the model, while platform discussions address how AI workflows relate to infrastructure ownership. Bringing both into the conversation gives engineering and business stakeholders a clearer view of what the adoption decision encompasses—without treating a report statistic as a forecast for their own organization.
The decision extends beyond the model
The CNCF and SlashData report makes platform-engineering models part of the conversation about AI infrastructure, and its figures offer specific points for further discussion. But the reported comparison does not show that one platform model causes a particular workflow choice, or that one approach is universally preferable.
For teams assessing AI infrastructure adoption, the practical takeaway is to consider platform ownership and workflow fit alongside model selection. The report can inform that discussion; the decision still needs to reflect the organization’s own needs and context.





