This is the fourth essay in a series about AI alignment. The earlier essays approached the problem from different directions: guardrails, the cost of learning, and the idea that alignment is better understood as a practice than as a state. That leaves a practical question. If alignment is something we maintain rather than something we finish, what exactly are we maintaining?
One answer is behavior within constraints, and that's important. There are things an AI system shouldn't do, and some boundaries should be established before deployment rather than discovered experimentally through harm to users. Evaluations can identify known failure modes, guardrails can prevent classes of dangerous behavior, and monitoring can reveal when those protections aren't behaving as expected. The problem begins when passing those checks becomes evidence for a larger claim than the checks actually establish.
An evaluation tells us how a system behaved under the conditions represented by the evaluation. Deployment introduces other conditions. People ask questions the designers didn't anticipate, different capabilities interact, users misunderstand instructions, and the model encounters unusual combinations of otherwise familiar situations. A safeguard that worked well in testing may produce an unexpected effect when thousands of people encounter it from different contexts. Now we have new evidence, and alignment work has to be capable of receiving it.
That changes the role of guardrails considerably. A guardrail doesn't need to teach a model the complete reason a boundary exists in order to be useful. If a system is about to expose someone's private information, I'm not particularly interested in letting it make the mistake so it can experience a meaningful learning opportunity. Prevent the disclosure, then investigate why the system approached the boundary in the first place. Prevention and learning aren't opposites. They operate at different parts of the problem.
This also makes me cautious about distinguishing too cleanly between a system that is merely constrained and one that genuinely understands. With current AI systems, understanding is difficult to establish from behavior alone. A model can produce an excellent explanation of why a safety rule exists and still behave inconsistently in another context. It can also give an unconvincing explanation while producing behavior we consider appropriate. Self-explanation is evidence, but it isn't direct access to whatever internal process produced the answer.
So rather than asking whether the system possesses alignment somewhere inside itself, I'd ask questions we can observe more directly. How does it behave across variations of the same problem? What happens when relevant context changes? Does a safeguard block the harmful part of a request while preserving useful alternatives? Where do users repeatedly encounter refusals that don't match the actual risk? Where do evaluations say the system is safe while deployment reveals behavior we didn't anticipate?
Those mismatches are valuable, although they don't interpret themselves. If employees repeatedly bypass an approved AI tool and use something else, perhaps the approved system has been constrained so heavily that it no longer performs the work they need. They might also be bypassing restrictions that exist for good reasons involving privacy, security, regulation or organizational risk. The existence of a workaround doesn't tell us which case we're looking at. It tells us where to look.
Find out what people were trying to accomplish, what the approved system prevented, and why the restriction existed. Maybe the guardrail changes. Maybe the workflow changes. Maybe the restriction remains and the organization provides a safer way to accomplish the legitimate part of the task. Alignment happens in that investigation too.
This is what deployment adds that a specification can't fully provide in advance. It exposes the system to more situations