The Most Dangerous Sentence in Engineering: “We’ll Add the Safeguards Later.”

There is a sentence that appears in technology projects whenever somebody points out an inconvenient safety requirement during the exciting part of building something:

“We’ll add that later.”

Authentication. Audit logging. Rate limits. Human approval. Rollback. Permission boundaries. Kill switches. Data retention. Abuse controls.

Later.

The problem is that many safeguards are not features. They are architecture.

If you build the system under the assumption that an agent is allowed to take an action autonomously, adding meaningful human authorization afterward is not necessarily a button you place on the screen. You may have to change the state machine, permissions, queues, failure behavior and every downstream assumption about who is allowed to do what.

Authority is structural

Imagine a system that evaluates something and immediately executes the resulting action. Later, somebody decides a human should approve high-impact actions.

Where does the work wait? What happens if nobody approves it? Can the underlying state change while approval is pending? What information does the reviewer see? Can the reviewer modify the proposed action? Does rejection terminate the workflow or cause the model to try again until it gets an answer somebody accepts?

Those are architecture questions.

“Put a confirmation dialog in front of it” is not the same thing.

A human has to be able to say no

I care particularly about this with AI because “human in the loop” has become an almost magical phrase. Put it on a slide and suddenly an autonomous system sounds responsible.

Meaningful human control requires more than human presence. The person needs the information necessary to understand what the system is proposing, enough time to evaluate it, authority to reject it and a workflow that accepts rejection as a normal outcome.

If saying no merely causes the software to nag the next person until somebody clicks yes, the human is not in control.

If the person cannot independently inspect the evidence, the review is ceremonial.

If the organization punishes reviewers for slowing throughput, the approval step may exist technically while being meaningless operationally.

Failing safely has to be designed

Another safeguard that is difficult to bolt on is safe failure.

What happens when the model is uncertain? What happens when a dependency disappears? What happens when contradictory data arrives? What happens when communication with the human reviewer fails?

A well-designed consequential system should have states in which it simply stops.

That can feel inefficient. Product teams hate screens that say “cannot determine.” Executives hate workflows that require intervention. Demonstrations look much better when everything completes automatically.

Reality, unfortunately, contains uncertainty whether the product roadmap likes it or not.

Ethics should compile

I increasingly think about ethics as something that should be visible in architecture.

If we say humans retain authority, show me where that authority exists in the workflow. If we say actions are auditable, show me the immutable record. If we say an agent cannot exceed its scope, show me the permission boundary. If we say a system is interruptible, show me what interruption actually does.

Values that exist only in policy documents are fragile.

Values enforced by the system are considerably harder to accidentally ignore.

This is also why there are categories of autonomous systems I simply will not build. If software is involved in decisions that can take a human life, “we’ll add meaningful human control later” is not an acceptable development plan. The moral decision has to remain with a human, and the technical architecture has to enforce that fact from the beginning.

Later is expensive

Safeguards added late compete against deadlines, sunk cost and an architecture optimized without them. Every existing assumption becomes an argument for weakening the safeguard so the rest of the system does not have to change.

That is backwards.

Decide what the system must never be allowed to do before celebrating what it can do.

Then build those boundaries into the bones of the product.

Because “we’ll add the safeguards later” has an uncomfortable tendency to become “we can’t change that now.”