Idea to production

The last part of Build is the path itself: what a person actually does between having an idea and having something running that other people use. If that path is undocumented, every project rediscovers it, and most give up somewhere in the middle.

Make the compliant path the fast path

This is the whole of platform engineering compressed into one sentence, and it is the only governance strategy that survives contact with people under deadline.

If the approved way to ship an AI application involves a design review, a security questionnaire, a ticket for a database, a ticket for a secret, and a ticket for a hostname, then the unapproved way, which is a personal cloud account and a share link, will win. Not because anyone is reckless, but because it works today and the other one works in three weeks.

A golden path is the same set of controls delivered as a template instead of a queue. The review happened once, when the template was built. Using the template is how you inherit it.

What a golden path actually contains

A usable scaffold for AI work covers, at minimum:

• A runtime it deploys to, with the environment already wired. See Run.
• Model access through the gateway, with no key in the repository. See keys and models.
• Data access as the calling user, not as a service account. See data access.
• Telemetry on by default: traces, cost attribution, and errors, without the builder configuring anything. See Observe.
• Ingress and SSO so the thing has a URL and only the right people can open it. See Control.
• An eval harness, even a trivial one, so there is somewhere to put the first test case when quality becomes a question.

The list is unremarkable. The point is that it is one command rather than six tickets, and that the person shipping did not have to know any of it existed.

Lead time, measured honestly

Borrow the DORA metric directly and apply it to AI work: how long from a stated idea to something running that a real user can reach. Measure the whole thing, including the waiting, because the waiting is the finding.

Two refinements make it more useful:

Measure by population. The engineer’s lead time and the analyst’s lead time are different numbers, and the second one is usually the one nobody has looked at.

Measure the second change, not just the first. Getting something into production once is a project. Changing it on Thursday because a user complained on Wednesday is a platform. If the second number is much worse than the first, you have a demo pipeline rather than a production path.

Non-engineers building real things

The interesting growth in AI usage is not engineers writing code faster. It is people who were never going to write code producing working tools for their own team.

That is genuinely valuable and it is also where governance usually breaks, because the tools those people reach for are the ones with no organizational boundary at all. The answer is not to stop them. It is to provide a path with the same guardrails and a much lower floor:

• A builder surface they can actually use, where the hard parts are already decided.
• The same identity, data scoping, and telemetry as the engineering path, inherited from the template rather than configured.
• A clear line between “useful for my team” and “load-bearing for the company”, with a real process for crossing it. Something that starts as a personal tool and quietly becomes a dependency is a known way to acquire an outage.

Production means someone owns it

The last checkpoint is ownership. A running application with no named owner is an incident waiting for a trigger, and AI applications acquire this status faster than most, because the person who built it in an afternoon did not think of it as a system.

Ownership means a name, an escalation path, and alerts that reach that person. That is an Observe capability, and it is the difference between a pilot and production.