The Platform Beneath the AI Model

Most organisations have moved past the question of whether they need an internal developer platform. The DevOps Research and Assessment (DORA) programme, run by Google Cloud, published a recent report that puts adoption of AI amongst technology professionals at 90%. The harder question is whether those platforms are ready for AI. Models, agents, and AI-assisted delivery do not smooth over weak foundations; they expose them. AI does not remedy underlying weaknesses in a team or a platform. It amplifies them.

At its core, platform engineering’s role with AI is a more demanding version of its existing mandate: build the infrastructure that turns a model into something a team can ship to production, and build it in a way that the tenth team benefits from what the first team established. This requires self-service access to:

• compute and model endpoints in place of extended procurement cycles,
• a single sanctioned integration path in place of multiple independent implementations, and
• a golden path that propagates a consistent pattern across teams rather than multiplying ad hoc solutions.

Establish that foundation correctly and security ceases to be a parallel workstream, it becomes an inherent property of the platform’s design rather than a retrofit.

From notebook to production

Most AI initiatives stall at the boundary between a data scientist’s notebook and a production service, and the cause is almost always a platform constraint, not a model limitation. Turning a fine-tuned model or an autonomous agent into something a customer encounters in production requires

• self-service access to compute and model endpoints in place of lengthy procurement cycles,
• a sanctioned integration path so multiple teams are not independently building identical integrations against the same model, and
• a data pipeline that supplies the model with what it requires without manual data exports

Remove any one of those elements and the initiative remains a proof of concept, regardless of the model’s underlying capability.

Industry analysis for 2026 from PlatformEngineering.org characterises the same constraint from the other direction: model handoffs completed manually, inference endpoints deployed outside standard governance frameworks, data science teams operating in isolation from platform engineering. Closing that gap, a single delivery pipeline serving application developers, ML engineers, and data scientists in place of three independent workflows, is not a secondary consideration. It is the primary determinant of whether an AI initiative reaches production or remains a strategic ambition. It is also the reason some organisations progress from concept to production within weeks while others remain indefinitely in the pilot phase.

From one team’s pilot to everyone’s capability

AI that functions for one team on a single model does not scale automatically to twenty teams across five models. This is where the majority of potential value is either captured or lost. The same golden-path thinking that enables developers to self-serve infrastructure must extend to AI: a repeatable process for integrating a model into a service, cost and usage telemetry surfaced on the same operational dashboards as the rest of production, and a model registry that ensures successive teams are not reconstructing what earlier teams already resolved.

Platformengineering.org, in its “Top 10 Platform Engineering Predictions for 2026”, treats the cost dimension as an operational requirement: pre-deployment cost gates and dedicated budgets for token and inference spend, applied with the same rigour as any production budget ceiling.

Red Hat’s survey of 1,000 platform engineers illustrates the performance differential that platform maturity produces. Organisations at an advanced stage of platform engineering reported substantially stronger AI outcomes than those in early phases: 54% reported increased innovation attributable to AI, compared with 15% of organisations at an exploratory stage, and 51% reported improved security and compliance outcomes, against that same 15%. The platform is not a secondary effect of AI adoption, it is the variable that determines whether that adoption generates measurable returns.

In practice, the distinction is visible in how a delivery request moves through an organisation. A team seeking to add a model call to a customer-facing service follows the pre-established path: compute and model endpoints provision automatically, cost and usage telemetry activates by default, and a scoped identity for that service is issued rather than requested separately. Delivery is measured in days, the output is auditable from the moment it goes live, and each subsequent team begins from the same established foundation.

Keeping it secure

None of this holds if the platform cannot be trusted with the systems it reaches, databases, customer data, deployment pipelines. An agent capable of opening a pull request or modifying infrastructure configuration requires the same access discipline applied to any human operator: a scoped identity, least-privilege permissions, and short-lived credentials in place of persistent keys. That discipline becomes more consequential as AI contributes a greater share of code entering the review cycle.

Faros AI’s 2026 report found that the probability of a production incident per pull request rose 242.7% as AI coding adoption scaled within an organisation, which is why 2026 platform forecasts expect the platform, not individual reviewers, to become the primary control point for AI-generated infrastructure changes.

Security, implemented correctly, is not a governance document appended after deployment. It is a property the platform carries by default.

Bell’s approach is to establish security foundations and governance as part of the platform architecture from the outset—not as controls added after deployment. This means translating security, compliance and responsible-AI requirements into reusable platform guardrails: governed identities, least-privilege access, approved integration patterns, protected data pathways, policy enforcement, auditability and lifecycle controls. By embedding these requirements into the platform’s golden paths and automated delivery processes, every model, agent and workload inherits a consistent security baseline from development through to production. Governance therefore becomes an operational capability—continuously applied, evidenced and improved—rather than a document reviewed at the end of delivery. This secure-by-design foundation enables organisations to scale AI with greater confidence, consistency and resilience, while avoiding fragmented controls and unmanaged risk.

Where to start

• Self-service before demand: provision access to compute and model endpoints, along with a single sanctioned integration path, before the first production request arrives, not in response to it.
• Golden path, built once: surface AI cost and usage on the same operational dashboards as the rest of production, and establish the integration pattern once so successive teams are not independently reconstructing it.
• Scoped identity, no exceptions: issue every AI agent a scoped, time-bound identity, no shared keys, no standing credentials, no carve-outs for agents described as “just testing something.”

The bottom line

For those funding this work: platform maturity, not model selection, determines whether AI scales beyond a handful of controlled pilots. For those building it: enabling AI in production and at scale is not a distinct initiative, it is the same platform engineering discipline applied to a more demanding class of workload. Security is not appended to these considerations; it is an inherent output of a well-designed platform. The question has never been about AI capability. It is about whether the platform underneath it can carry the load.

Sources:

• DORA, “State of AI-Assisted Software Development 2025”
• Faros AI, “AI Engineering Report 2026: The Acceleration Whiplash”
• Platform Engineering, “10 Platform Engineering Predictions for 2026”
• CNCF, “The Autonomous Enterprise and the Four Pillars of Platform Control: 2026 Forecast”
• Red Hat, “The State of Platform Engineering in the Age of AI”

Meet the Author:

Mark Ellis
Head of Infrastructure Services, Bell Integration

Mark Ellis is a seasoned technology leader and Bell’s Head of Infrastructure Services with more than 30 years of experience delivering and managing enterprise IT solutions across infrastructure, storage, networking, platforms, and security. As a servant leader for nearly 20 years, he is passionate about building high-performing teams, developing talent, and creating a culture of collaboration, accountability, and continuous improvement. Mark combines deep technical expertise with strategic leadership, enabling organisations to modernise technology estates, strengthen security, and deliver reliable, scalable services that support business growth and innovation. 

Steve Ingram
Platform Engineer, Bell Integration

As a Platform Engineer at Bell, Steve Ingram builds highly available, scalable infrastructure across diverse environments, focusing on automation and observability to drive faster deployments and improved reliability. With background in infrastructure modernisation and distributed systems, he helps organisations build resilient, secure-by-design architecture