Deployment Safety Board

A Deployment Safety Board is a standing group of experts within a company. It decides whether a new artificial intelligence computer program may be delivered to customers. The English term literally means something like “rollout safety council.” Before a release, the body reviews test reports and weighs possible harms. In the end, there is a decision: approve, approve with conditions, or block. It is important that this group operates independently of the development team and is not measured by sales success.

Why companies build their own brakes

In the software industry, the rule for years has been: release quickly, fix errors later. For a misplaced button, that works well. For a language model used by millions of people at the same time, it works poorly. An error can be rolled back, but the resulting harm cannot.

That is why large AI companies separate the decision to release from the team that built the product. Whoever has worked on a model for months wants to release it. This desire is understandable, but it is not a good advisor on questions of risk. A separate body does not have this pressure and can judge more soberly.

On top of that comes pressure from outside. The EU’s legal act on artificial intelligence, the AI Act for short, requires documented review processes for particularly risky systems. A board produces exactly this documentation. Companies can thus prove, in case of a dispute, that they have systematically examined their risks and not merely claimed that everything is safe.

The path from review to decision

It begins with the evaluation of the model. Testers deliberately try to provoke the system into missteps. They ask, for example, for instructions on weapons, for malicious software, or for insulting statements about certain groups. This intentional attacking of one’s own software is called red teaming. The results are counted and summarized in a report.

Many companies then assign each model to a risk level. Depending on the provider, such tiered models are called Preparedness Framework or Responsible Scaling Policy. The basic idea is always the same: the more dangerous a capability could be, the stricter the requirements. From a certain level onward, the development team’s approval alone is no longer sufficient.

Then the board convenes. Typically, safety research, the legal department, product leadership, and sometimes external experts sit together there. They discuss the open issues and reach a decision. A frequent outcome is not a clear approval but an approval with conditions: initially only a few test users, certain features disabled, additional filters active. One can imagine this like the approval of a medication that is first tried out in a small group.

When approvals become headlines

Such a body is rarely directly visible to users. You notice it indirectly when an announced model appears later than planned, or when a feature is initially available only in the US. Staggered launches, in which only paying customers get access at first, are also often due to such conditions.

In the news, the term mostly appears in cases of dispute. When safety researchers leave a company and publicly state that their concerns were overridden, it is almost always about such release decisions. Reports about shortened testing phases before a major product launch also concern exactly this process.

A common misconception is that a Deployment Safety Board is a government authority. As a rule, it is not. It is a voluntary self-commitment by a company, one that can also change its own rules again. That is exactly why the decisive question for any such body is always: who sits on it, and can it really stop a finished product?