Platform engineering for AI development

Give prototypes a route to production

People can explore ideas with different AI tools while the organization provides a common route to production. The platform team makes that route clear, supported, and repeatable.

For a useful prototype, collect the user task, example workflow, source code where available, and intended data. Assess whether to adapt the code or rebuild from the learned requirements. Before live credentials or confidential inputs, verify the application, development tools, and runtime against the required controls.

If the service must run in your infrastructure, offer a supported deployment into your cloud accounts or networks. Include identity, secret handling, release evidence, monitoring, and recovery. Review model data flows separately; owning the runtime does not control every development service.

Treat the platform as a product for its users

A platform gives teams supported capabilities for building and operating software. These can include identity, environments, delivery pipelines, databases, monitoring, and policy checks. The useful unit is a complete workflow that meets a recurring need.

CNCF describes platforms as capabilities designed around internal users, with consistent interfaces and self-service where appropriate. A portal can expose these capabilities, but a portal alone is not the platform. CNCF Platforms White Paper.

Start with a real demand. For a fictional company, several teams need an internal web service with employee sign-in and a managed database. Build a supported route for that demand before adding a broad catalogue of rarely used features.

Include agents among the platform’s users

An AI agent can generate infrastructure code quickly. Without current platform context, it can also select an unsupported region, identity pattern, or deployment method. Faster generation does not resolve missing organizational constraints.

Give the agent a reliable interface. Define inputs, permitted values, outputs, and failure behavior. Provide examples that match the installed version. Return actionable errors without exposing secrets. Apply the same authorization checks to human and agent callers.

For the internal service, the request might identify the owner, data category, environment, recovery requirement, and supported runtime. The platform can then select a reviewed configuration or explain why the request needs a separate decision.

Define the supported route and its limits

This is an example split. Confirm it with the actual teams and providers. Unnamed responsibility does not disappear because a platform exists.

Publish an exception route for requirements outside the default. Identify the decision owner and the evidence required. A difficult exception process can encourage teams to create unsupported systems outside the platform.

Maintain services after creation

A template is a starting version. It does not automatically patch the applications created from it. Decide how platform changes reach existing services and how compatibility is checked.

Version shared interfaces and modules. Announce removal conditions. Provide a supported migration where needed. Track which services remain on affected versions when a security correction is required.

Avoid making the platform team a manual approval queue for every routine operation. Automate repeatable checks and reserve human decisions for unresolved consequences. Measure successful use, waiting time, recovery outcomes, and maintenance effort.

Connect the platform to the software factory

Platform engineering defines supported capabilities and operational boundaries. A software factory connects requirements, planning, implementation, evidence, and delivery. They can complement each other when the factory plans against the actual platform.

Include ongoing operations in the evaluation. Verify who scans for new vulnerabilities, deploys corrections, responds to incidents, and maintains compliance evidence. These capabilities need an agreed scope and owners; the term “software factory” does not guarantee them.

Evaluate the integration at a concrete point: can a generated change use the existing deployment path and preserve its controls? Can the team inspect why an exception was needed? Who updates the shared context when the platform changes?

DORA’s research places AI capability within the surrounding organization. Use that perspective to assess the complete workflow, including the work that remains with the platform team. DORA 2025 report.