Six decisions to make before the next vibe-coded app ships

Most of the writing about governing AI-built apps, including the earlier posts in this series, is about architecture: why policy alone cannot govern them, what the surface, control and foundation layers contain, and why builders should never hold a credential. Architecture is the answer. Before you can build it, someone has to make six decisions, and most organizations haven’t asked anyone to.

Here are those six decisions, and a ninety-day way to start on them. Each one needs an owner, and you can make all six with or without a product.

Why now: proving control

The usual way to raise urgency is the fine. The EU AI Act allows penalties of up to €35 million or 7% of global turnover for prohibited practices, and up to €15 million or 3% for breaches of the obligations on providers, deployers and others.¹ Most security leaders have heard those numbers and tuned them out, so I’ll start with what you’ll be asked to show.

The Act was amended this year by the Digital Omnibus on AI, Regulation (EU) 2026/1744, which entered into force on 27 July 2026.² It’s law. Among other changes, it moved the date for stand-alone high-risk systems under Annex III from August 2026 to 2 December 2027.

From that date, deployers of those systems have to keep the logs the systems generate for at least six months, to the extent the logs are under their control.³ The transparency duties in Article 50 and the fining powers for general-purpose AI models already applied from 2 August 2026, so the first gate has closed.

Six months is a floor, and it says nothing about how you meet it. That makes it an architecture requirement: you can’t retain logs an app never emitted. An app that an analyst deployed to a personal cloud account last spring has no log you can produce, and no amount of policy written in 2027 will create one retroactively.

The pressure reaches past Europe. Colorado repealed its 2024 AI Act before it took effect and replaced it with SB 26-189, a disclosure law signed on 14 May 2026, with duties from 1 January 2027.⁴ The common thread is evidence. The question regulators, auditors and your own board will ask is whether you can show which apps exist, who owns them and what they did.

The six decisions

1. Risk tiers

Decide what’s allowed, what needs review and what’s prohibited, and decide it 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 though the builder is the same person.

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 have two purposes. They put controls where the risk is, and they keep controls away from where it isn’t, so the controls you do apply stay credible. Govern a team’s lunch-order app like a payments system and people will stop telling you about either.

The risk most organizations miss is drift. An app starts as one person’s tool, picks up a team, then a department, then a connection to a system of record, and it never gets re-reviewed because nothing marked the moment it moved. Ask anyone to place a real app on their tiers and most will put it a level lower than it belongs.

So the decision includes the trigger: what event forces a re-review, and what records that the event happened.

2. Identity model

Decide what every app inherits for sign-in and access, and who administers it. The app your analyst built has no login unless someone gives it one; anyone with the URL is inside. Choose the identity provider every app sits behind, the roles an app may define, and who can grant access to whom. Then decide who owns that configuration over time: the builder, the app’s owner, or a central team.

3. Credential policy

Decide where secrets live and who rotates them. This is the decision that constrains the rest. If an app holds its own key, scoped roles in front of it can’t narrow what the key behind it can do, the app’s life is tied to the employment of whoever generated the key, and your audit trail has a hole wherever a copy went.

The previous post covers the design in full; the decision is whether you commit to it, and whether you refuse to deploy apps that carry raw secrets.

4. Ownership rules

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 person accountable for running it at 3am, and everyone who’s run production knows who usually ends up holding it.

The rule worth adopting is simple: no app enters production without a named owner. The harder half is the transfer: what happens when the owner changes roles or leaves, who inherits the app, and who decides to retire it.

5. Promotion path

Decide how an app moves from personal, to team, to enterprise use, and what review each step triggers. This is where the tiers become real. A personal app may need nothing beyond sign-in. A team app may need an owner and a credential through the broker. An enterprise app touching sensitive data may need a security review before it goes further.

Be honest about where the line sits. Gartner advises prohibiting vibe-coded software in customer-facing production and confining it to sandboxes.⁶ That caution is reasonable, and most internal apps sit well inside it. For anything that goes beyond a sandbox, Gartner’s remedy is a governed platform with a promotion pipeline, so the step up follows a defined route.⁷ Whichever line you draw, draw it in advance, so builders know what each step will ask of them before they take it.

6. Signals you watch

Decide which measures you’ll review, and on what cadence. Counting apps and users is the obvious choice and the misleading one: Gartner notes that those counts hide rising rework and security exposure.⁸ Four signals say more:

• Governed adoption rate: the share of what got built that went through the governed path. This is the one to put in front of an executive.
• Time to safe delivery: how long the governed path takes from a working build to a live app with identity, an owner and a record. If the workaround is faster, you have built a gate and called it a road.
• Prototype-to-production conversion: how much of what gets built actually reaches the people it was built for.
• Reuse rate: how often a new need is met by an existing app or component, with no near-duplicate built beside it.

Pick the four, name who reviews them, and hold the review.

A ninety-day start

You can make all six decisions without buying anything, and the same goes for the first ninety days. Gartner’s research on scaling vibe coding lays out a staged rollout, which in paraphrase runs like this:⁹

Almost every organization is in the first stage, and most haven’t done the inventory. Start there, ahead of any platform decision. The inventory tells you which tiers you actually need, which systems apps are already reaching, and how many of them have no owner. Every later decision is easier with that list in hand.

Where Tray Helix fits

Tray Helix is one implementation of the model these decisions describe. Apps go live from the AI assistant with one command, behind enterprise SSO with scoped roles, reaching your systems through Tray auth aliases so no credential sits in the code. Each app has a named owner, its connections, activity and logs, and its AI and compute spend on record from its first request. Helix doesn’t scan or test the generated code, and it governs what’s deployed through it; an app hosted elsewhere stays outside the line.

It’s one of several ways to act on these six decisions. If you already run an internal developer platform, have a handful of apps and engineers to look after them, or have residency or audit rules that require apps to run in your own environment (Helix runs on Tray’s managed cloud only), building it yourself may be the better call. We set out that trade honestly in Helix vs building it yourself.