Decision rights: who gets to say the AI ships
The moment before an AI feature goes live is a decision, and someone has to own it. Teams that never assign that decision end up shipping by drift or stalling by default. Neither is a choice anyone made.
Decision rights: who gets to say the AI ships
A CTO at a healthcare software company told me about a launch that almost did not happen, not because the feature was not ready, but because no one was sure they were allowed to say it was. Engineering thought product decided. Product thought compliance had a veto. Compliance thought the CTO owned the call. The feature sat finished for three weeks while four capable people each waited for someone else to pull the trigger. When he finally asked in a meeting who actually holds this decision, the honest answer was that no one had ever been given it.
He learned something he now applies to every AI project. The authority to ship is a specific thing that has to be handed to a specific person on purpose. It does not assign itself, and when it is left implicit, a finished feature can stall as easily as an unfinished one.
Ambiguous authority stalls in both directions
Unclear decision rights are quietly one of the most expensive org problems in AI delivery. When no one clearly holds the go decision, two bad outcomes compete. Either the feature stalls because everyone defers, or it ships by drift because someone assumes they can and no one stops them. Both come from the same root. The decision existed and the authority for it did not.
AI makes this sharper because the go decision carries more judgment than usual. Shipping means accepting a known rate of wrong answers, an ongoing cost, and a set of edge cases you have chosen to live with. That is a real decision with real accountability attached, and it needs an owner who can be pointed to afterward. Splitting it across a committee means splitting the accountability into nothing.
Settling the go decision in advance
- Name the single person who says ship. One owner of the go decision, chosen before the feature is done, not discovered when it is.
- List the real vetoes explicitly. If compliance or security can block launch, say so up front and name who holds each veto. Hidden vetoes surface at the worst moment.
- Define what the decision accepts. Shipping means accepting a stated error rate and cost. Write that down so the go decision is informed, not blind.
- Make deferral cost something. If the default is everyone waits, a ready feature rots. The owner is expected to decide, and not deciding is itself a call they answer for.
How we approach it at Density Labs
In our AI Opportunity Assessment ($2,500), we settle decision rights while the feature is still on paper. We name who owns the go decision, list who genuinely holds a veto, and make explicit what shipping accepts in error and cost. It is a short conversation that prevents a specific and common failure: a finished AI feature sitting untouched because four people each assumed it was someone else’s call.
Building the feature is the visible work. Deciding who is allowed to ship it is the work that gets skipped, and it is the work that decides whether anything reaches a user at all.