Operating principles

Consistency is a decision you pay for

Whether AI work runs the same way across the company or differently per team is a real choice, and both answers are legitimate. The failure is not picking the wrong one. It is never picking, so the boundary sits unstated, responsibilities fall into the gap, and whoever built the first thing accidentally set the standard for everyone.

Decision rights

The question people ask is "should we standardise". Wrong question. The right one is "where does the boundary sit": which layers are shared and which belong to teams. Leadership makes that one call, once, so the shared layer is chosen rather than inherited from whoever moved first.

Four shapes come up. Embedded: AI people inside product teams, fast on features, inconsistent on deployment. Platform: one central AI team, consistent governance, a bottleneck. Hybrid: central infrastructure with domain expertise spread out, which only works if the split of decisions is written down. Everyone-AI: no specialists, which needs AI-native hiring and culture from day one. A company can run different shapes in different parts of the business and stay coherent. What it cannot do is hold one shape in the org chart and another in practice.

Memory and context

A boundary agreed in a room is not a boundary. It gets written at the crossing point itself: in the repo, the runbook, the exceptions page. Not in a slide. Undocumented boundaries decay into three conflicting interpretations within a quarter.

Execution

Standardise narrow and defensible. Let multiple implementations coexist first, then extract what is actually common, rather than predicting the standard before anyone has built anything. A standard written before the second implementation exists is a guess with authority.

Governance

Response time decides whether a standard sticks. Any control slower than the workaround gets bypassed, silently. Exceptions have to be cheap to request and written down when granted. An expensive approval process does not stop divergence, it just hides it.

Observability

Count duplicate implementations of the same capability, especially evaluation. Three teams with three ways to measure whether the model is any good is the clearest signal the boundary was never set. Be honest that the benefits of consistency show up as absences (the migration you did not need, the audit that closed quickly) and absences do not report themselves. The costs stay visible. That asymmetry is why this decision keeps getting deferred.