The alignment problem most companies have is organizational

Model alignment is the labs' job. The version that breaks production is an organization that never decided what its AI was for.

“AI alignment” usually points at the model: making a powerful system want what we want. That problem is real, and it is the labs’ job. It is not the one that breaks most enterprise deployments. The one that breaks them is quieter, and it sits inside the company buying the model, not the model itself.

Two alignment problems

A perfectly safe model dropped into a confused, contradictory organization produces confused, contradictory outcomes. The model did nothing wrong. The organization never agreed on what “good use” meant, so the system optimized for whatever was easiest to measure, and the gap showed up in production rather than in the evaluation.

Call the labs’ version model alignment and this one alignment of use. Aligning the model is necessary. It is not sufficient. The human system wielding the tool has to be pointed at the right thing too, and that pointing is a decision nobody on the engineering side is positioned to make alone.

Most failures are decisions that were never made

When an agent does something the business regrets, the post-mortem rarely lands on the weights. It lands on an absence: no one had said what the system was allowed to refuse, who was accountable for its spend, or what a good answer even looked like. The engineers encoded the defaults they had, because a default is what you ship when the decision is missing.

This is why “add more model” does not fix it. The bottleneck is not capability. It is judgment: not whether the organization can build the thing, but whether it has decided what the thing is for, for whom, and at what cost it would rather stop.

The decision comes before the control

The work, then, is sequenced. First, decide: translate between the executives who hold intent and the engineers who encode it, name the risk in concrete terms, and draw the line the system must not cross. Then, and only then, build the control that holds the company to that line. A decision with no control is a slide. A control with no decision behind it enforces an accident.

What it looks like in production

The test of whether this is philosophy or engineering is simple: can you point at the control? Each organizational decision should resolve into something a machine enforces.

What must the system refuse becomes a guardrail policy. Who may spend what, and through which path, becomes a governed gateway. Whether it is still behaving becomes observability. Who decides a good output, and on what evidence, becomes an evaluation suite with the domain experts’ judgment wired into the loop. The judgment never floats free. It lands in an audit trail.

The line that matters

Installing AI is not a software rollout. It is an alignment problem inside the company, and the companies that treat it as one ship systems that survive an audit and a year of production. The decision is the hard part. The controls are how you prove you meant it.