AI platform engineering should standardise the dangerous parts, not just the easy ones

Introduction

The platform team has done the visible work well.

A developer can create a new AI service from a template. The repository appears quickly, the CI pipeline is attached, an approved SDK is already installed, logging starts automatically and deployment needs little more than a command.

Production reveals a different picture.

One application still runs with a development-oriented execution role. Another can reach outbound systems that were never declared as part of its production design. A third has no repeatable release evaluation because its responses looked convincing during testing. A fourth produces traces, but those traces cannot reliably establish which deployed configuration sat behind an incident.

The enterprise has standardised the path developers see most clearly while leaving some of the highest-consequence decisions to each application team.

That is the deeper problem behind AI platform engineering governance standards.

Platform engineering is rightly associated with self-service, golden paths and lower developer cognitive load. AI does not make those goals less valuable. It changes where standardisation should become strongest.

The platform team should be most opinionated where variation can expand production authority, expose data, permit consequential actions or leave the organisation unable to reconstruct what happened. Elsewhere, application teams can retain much more freedom.

At a glance

• AI platform engineering should standardise high-consequence production controls, not only developer conveniences such as templates, shared SDKs and deployment pipelines.
• Production invariants should cover workload identity, network access, consequential tool permissions, release evidence and traceability across AI applications.
• Application teams can retain flexibility in model selection, frameworks, retrieval architectures and domain-specific quality checks without weakening common production controls.
• Golden paths should make essential safeguards easy to inherit while supporting validated alternatives, documented exceptions and controlled policy rollouts.
• Platform maturity should be measured by how consistently production workloads inherit required safeguards, rather than by the number of standards, templates or tools published.

Platform engineering naturally starts with friction

There is a sensible reason the easier parts are often standardised first.

Developer friction is visible. Teams complain about provisioning, copy deployment scripts, maintain slightly different pipelines and wait for infrastructure tickets.

CNCF material describes platform engineering in terms of shared tooling, workflows, self-service and opinionated golden paths that reduce cognitive load while improving consistency.

That operating model solves a real problem.

Difficulty begins when the enterprise equates a standardised developer interface with a standardised production posture.

Two AI services may start from the same template and use the same deployment mechanism while carrying completely different privileges, data access, action capability and release risk. One may only summarise public product information. Another may update customer records or invoke a fulfilment system.

Infrastructure similarity does not make those workloads operationally equivalent.

The platform team therefore needs to look beyond what is easy to template and ask where inconsistent choices create consequences the enterprise will later have to absorb.

Standardise authority and exposure before standardising implementation

Identity, network access and action-capable resources belong together because they determine what a production workload can actually reach and do.

This is where development convenience can quietly survive longer than intended.

AWS makes the risk explicit in its current AgentCore guidance. IAM policies created by the AgentCore CLI are intended for development and testing, grant broad access to support rapid prototyping and are not suitable for production. AWS recommends custom least-privilege policies and supports IAM conditions that can require runtimes to use approved VPC configurations.

Microsoft Foundry follows the same general production principle through its separation of resource and project scopes, managed identities and least-privilege RBAC. Its authentication guidance recommends Microsoft Entra ID for production workloads where managed identity, conditional access and fine-grained access control are required.

These examples point to a more durable platform standard than a preferred agent framework.

Every production workload should have an identifiable principal whose authority is appropriate to the workload. The exact framework used to build the reasoning loop can vary. The meaning of the production identity should not disappear merely because one team prefers LangGraph and another uses a vendor-native agent runtime.

Network posture fits the same model.

Not every AI workload needs identical connectivity, but each should fall into an approved posture rather than inventing one application by application. A low-risk internal assistant may have one connectivity class. A workload handling sensitive information may require private connectivity. An action-capable system may need declared outbound destinations.

Tool and resource access deserves similar treatment.

Google’s Gemini Enterprise Agent Platform uses Agent Registry and Agent Gateway to place registered agents, MCP servers and endpoints inside centrally governed access policies. Its documentation describes communication being evaluated against policy rather than assuming that a discoverable resource is automatically permitted.

The detailed enforcement mechanisms can differ by platform.

The platform-engineering standard is simpler: a consequential resource should not become part of a production workload merely because a developer can connect to it.

The resource should be identifiable, the authority to reach it should be bounded and the production path should make that relationship visible enough to govern later.

That is a stronger enterprise standard than requiring every team to use the same tool wrapper.

Release evidence and observability should be required outcomes

The next dangerous gap appears after the application has been built correctly enough to deploy.

A shared SDK can make code easier to support, but it says little about whether a changed AI system deserves promotion into production.

Microsoft’s current Foundry evaluation guidance treats evaluation as part of release quality. It allows teams to establish baselines and acceptance thresholds before releasing an agent and supports using evaluation as a quality gate inside CI/CD.

That does not mean every AI workload should use the same evaluator.

A customer-service summariser and a claims recommendation system may need entirely different measures. Domain teams still have to define what acceptable behaviour means.

The platform team can standardise something more fundamental: consequential production releases should carry identifiable evidence.

That might include a versioned candidate, a known evaluation or evidence set, recorded results, an acceptance decision and enough linkage to establish which version those results actually approved.

The specific rubric can remain domain-owned.

The absence of any release evidence need not remain an application choice.

Observability has the same shape.

Platform teams sometimes standardise the backend and assume the problem is solved. Every workload sends logs to the same destination, so observability appears consistent.

Incident response exposes whether the data has consistent meaning.

AWS AgentCore, for example, provides runtime metrics around invocations, sessions, latency, resource use and errors and supports observability across runtime, memory, gateways, built-in tools and identity resources. Its runtime telemetry includes identifiers such as request, session and trace information that can be used for correlation.

An enterprise platform does not need one mandatory dashboard to learn from this.

It needs to decide which production facts should remain recoverable regardless of the observability implementation.

Which workload produced the event?

Which deployed version was running?

Which request, session or task does the event belong to?

Which dependency or tool was involved?

Did the platform reject the operation, or did the downstream system fail?

Those are questions the platform can standardise around.

A team may choose different dashboards or tracing products while still inheriting the identifiers required to investigate production behaviour.

Standardise production properties more aggressively than implementation choices

Once authority, release evidence and operational evidence are treated as platform concerns, the standardisation boundary becomes easier to draw.

An enterprise can require that production AI workloads have scoped identities, approved network postures, declared consequential resources, appropriate release evidence and common correlation fields without forcing every application into one technical design.

Teams can still choose different models.

They can use different agent frameworks.

They can organise prompts differently.

They can choose retrieval patterns suited to their workload.

They can implement domain-specific quality checks.

The platform standard describes the production properties the enterprise expects to survive those choices.

That distinction matters because AI implementation patterns are still moving quickly. A platform that standardises today’s preferred framework too aggressively can convert a temporary architectural preference into long-lived platform debt.

The more durable standards tend to sit closer to authority, exposure, evidence and recoverability.

Those requirements survive changes in frameworks much better than a mandated application architecture does.

Strong invariants need safe escape hatches and safe rollout

A stronger platform does not have to become a rigid one.

Golden paths are useful precisely because they package approved practices into a path teams can actually adopt. Problems appear when the path assumes there is only one valid implementation.

A September 2026 CNCF discussion of platform-engineering maturity argues for decoupled golden paths with parameterised options, validated choices and policy-based constraints rather than hard-coded assumptions that turn every exception into platform-team work.

That model fits AI particularly well.

A golden path can require an approved production identity while supporting several application frameworks.

It can require a declared network posture while allowing more than one valid environment.

It can require release evidence without choosing the domain’s evaluator.

It can require trace correlation without forcing one observability product.

The strongest invariants also need careful rollout because platform controls have their own blast radius.

Google recommends defining and applying Agent Gateway IAM policies through CI/CD so invalid references can be caught before deployment. It also recommends starting the gateway in dry-run mode in staging, where disallowed communications are logged without being blocked, before moving into enforcement.

That is a useful reminder that platform standards are themselves production systems.

A faulty permission rule can break many applications at once. A network restriction can disconnect workloads from legitimate dependencies. A required evaluation service can become a release bottleneck. A changed telemetry convention can undermine incident investigation across the estate.

Versioning, validation, staged rollout and rollback therefore apply to the standards as much as to the applications inheriting them.

Exceptions fit inside the same operating model.

Real enterprises contain legacy services, unusual regulatory constraints, specialised models and workloads with requirements the default path cannot anticipate.

The useful distinction is not standard versus exception.

It is whether variation is controlled and visible.

A legitimate exception has an owner, a reason and a defined scope. It can be rediscovered later. It does not silently become precedent for the next ten applications.

A platform that offers no escape route eventually encourages bypass. A platform that records nothing as an exception has no meaningful standard.

Prioritise standards by the cost of tolerating variation

Platform backlogs are easily pulled toward visible developer experience.

A faster scaffold gets noticed.

A better portal gets noticed.

A cleaner CLI gets noticed.

They are worthwhile investments, but developer visibility is a poor proxy for enterprise consequence.

A weak workload-identity standard can affect every application.

Inconsistent network treatment can create data-exposure paths.

Missing release evidence can allow behavioural change without a defensible promotion record.

Uncorrelated traces can turn a shared incident into days of reconstruction.

The more useful prioritisation question is: what happens if every team makes a different choice here?

Several conditions raise the case for a strong invariant:

• inconsistent implementation can expand authority or data access;
• the choice can lead to a consequential or difficult-to-reverse action;
• failure would be hard to investigate without common evidence;
• every application team would otherwise have to solve the same high-consequence problem independently;
• one incorrect standard or exception can create a broad estate-level blast radius.

Choices that sit far from those conditions can remain more flexible.

A platform does not need to prescribe how every prompt is structured if prompt structure is local, inexpensive to change and does not weaken a shared control boundary.

It should care much more about a production role that can reach ten business systems.

The resulting standardisation model is a gradient rather than a binary.

Area	Platform posture	Why
Production workload identity	Strong invariant	Inconsistent identity can expand authority and weaken investigation
Production network/egress posture	Bounded approved choices	Connectivity can create security and data consequences
Release evidence	Required outcome; domain-specific method	Serious releases need evidence, while quality criteria vary
Trace/correlation identifiers	Strong invariant	Incident reconstruction requires common reference points
Consequential tools/resources	Declared and governed	Action capability should not appear invisibly in production
Model/framework choice	Curated flexibility	Different workloads legitimately need different implementations
Prompt structure	Primarily application-owned	Uniformity usually creates little platform-level value
Local development workflow	Flexible within production gates	Variation is relatively cheap before production consequence

The table is not intended as a universal control framework.

Its purpose is to make the prioritisation principle explicit: standardisation should become stronger as inconsistent choices get closer to authority, data movement, consequential action or the evidence required to understand failure.

Measure inheritance, not publication

A platform team can publish excellent standards that production applications barely inherit.

Documentation alone does not reveal whether standardisation is working.

Operational measures do.

What proportion of production workloads use a scoped workload identity?

How many action-capable applications have declared the resources they can invoke?

How many releases preserve the required evidence?

How many workloads emit the correlation fields needed for investigation?

Which applications sit outside approved network postures?

How many exceptions exist, who owns them and how long have they remained open?

Those measures expose whether the platform has converted an architectural preference into an operating property.

Portal adoption still matters. So does developer satisfaction.

Neither should substitute for knowing whether the high-consequence standards survive contact with production.

Platform engineering should remove repeated risk decisions from application teams

Platform engineering creates leverage when it takes recurring infrastructure decisions out of individual product backlogs.

The same logic applies to recurring production-risk decisions.

An application team should decide what its AI system is for, how users interact with it, what domain quality means and which application architecture best fits the problem.

It should not have to invent an enterprise philosophy of workload identity.

It should not rediscover from first principles how much network access an action-capable agent should receive.

It should not independently decide whether an AI production release requires any recorded evidence.

It should not discover during an incident that the telemetry fields needed for reconstruction were optional.

Those are repeated problems whose consequences extend beyond one application.

The platform team adds value by solving them once, turning the solution into an inheritable production property and giving teams controlled ways to handle the legitimate cases that do not fit.

That is a different ambition from maximising the number of things the platform can standardise.

It is much closer to minimising the number of dangerous decisions every application team has to rediscover for itself.

FAQs

What should an AI platform engineering team standardise?

The strongest candidates are production properties where inconsistent implementation creates disproportionate enterprise risk: workload identity, permissions, network posture, consequential resource access, minimum release evidence and telemetry required for investigation. Models, frameworks and application-specific quality logic usually need more flexibility.

Are golden paths still useful for AI platforms?

Yes. Golden paths can reduce cognitive load and make approved production practices easier to inherit. They work best when they encode important constraints while allowing validated options and explicit exceptions instead of forcing every workload through one implementation.

Should every AI application use the same evaluation process?

No. Different applications need different quality criteria and risk tests. A platform can require appropriate release evidence without prescribing the same evaluation dataset, evaluator or threshold for every workload.

Does standardising AI governance mean centralising every decision?

No. Platform engineering should centralise repeatable infrastructure and control expectations. Domain teams still need to own application purpose, business quality, workflow logic and context-dependent decisions.

How should platform teams handle exceptions?

Exceptions should be visible and governed rather than hidden. A useful process records the workload, owner, rationale and scope so the enterprise can distinguish legitimate variation from silent bypass and revisit the exception when requirements or platform capabilities change.

Standardise where inconsistency becomes dangerous

The visible parts of platform engineering still matter.

Templates shorten setup.

Shared tooling reduces duplicated work.

Golden paths make good practice easier to adopt.

The harder value appears later, when a production AI workload begins carrying real authority.

At that point, the enterprise benefits from knowing that identity is scoped, network posture is deliberate, consequential resources are visible, releases carry evidence appropriate to what they can affect and incidents can be reconstructed because the necessary identifiers were never optional.

Those properties are less glamorous than a polished developer portal. They are also much harder to recreate after an incident exposes their absence.

The platform engineering question is therefore not:

How much of AI development can we standardise?

It is:

Where would allowing every team to make a different choice create a risk the enterprise cannot afford to rediscover application by application?