Risk tiers, identity, owners and the promotion path

Architecture enforces decisions. Someone still has to make them. Here are the four every AI-built app inherits. You can make all of them with or without a product.

Risk tiers

Decide what’s allowed, what needs review and what’s prohibited, by business criticality and data sensitivity. A finance analyst’s personal report and the same analyst’s app that writes back to the general ledger are different tiers, even with the same builder.

Gartner’s guidance on governing citizen development describes this kind of tiering, with escalation triggered by a threshold of users, by sensitive data or by a connection to a core system.¹

Tiers put controls where the risk is and keep them away from where it isn’t, so the ones you apply stay credible. Govern a team’s lunch-order app like a payments system and people will stop telling you about either.

Watch for drift. An app starts as one person’s tool, picks up a team, then a department, then a connection to a system of record. Nothing marked the moment it moved, so it never got re-reviewed. So the tier decision includes the trigger: what event forces a re-review, and what records that it happened.

Identity

Decide what every app inherits for sign-in and access, and who administers it. An app your analyst built has no login unless someone gives it one. Anyone with the URL is in.

Pick the identity provider every app sits behind, the roles it may use, and who grants access. Then decide who owns that setup: the builder, the app’s owner, or a central team.

On Helix, every app inherits your enterprise SSO from its first request, with no public mode. The organization roles are Admin and Contributor. Each app’s Access Control setting decides who can open it: its workspace (the default), only people invited by name, or the whole organization, which only an admin can choose. You decide who holds Admin and which setting each tier allows.

Ownership

Decide who’s named as the owner of every app, and what happens when that changes. The person who prompted an app is rarely the one accountable for running it at 3am.

The rule to adopt: no app enters production without a named owner. The harder half is the handover. When the owner changes roles or leaves, who inherits the app, and who decides to retire it?

On Helix, each deployed app shows in the dashboard with who created it. And because the code holds only an alias, handing the app to someone new hands over no secret. You still write the handover rule.

The promotion path

Decide how an app moves from personal, to team, to enterprise use, and what each step asks for. This is where tiers get real.

Be honest about where the line sits. Gartner advises keeping vibe-coded software out of customer-facing production and confining it to sandboxes.² Most internal apps sit well inside that. For anything beyond a sandbox, Gartner’s answer is a governed platform with a promotion pipeline, so the step up follows a defined route.³

Wherever you draw the line, draw it in advance, so builders know what each step asks before they take it.

If a tier needs a person to sign off before production, put that step in your deploy pipeline, for example as required reviewers on a GitHub environment. GitHub holds the sign-off, and the deploy runs once it’s given.

Do this week

Take five real apps and place each one on your tiers. Then ask each builder where they’d put it. Where you disagree, write down what should have triggered a re-review. People tend to place an app a level lower than it belongs, so expect to move a couple up.

What you have now

Four decisions, each with an owner. Next: evidence, the record that proves they’re holding.