Deployment Safety Board

Ein Deployment Safety Board ist eine feste Gruppe von Fachleuten in einem Unternehmen. Sie entscheidet darüber, ob ein neues Computerprogramm für künstliche Intelligenz an Kunden ausgeliefert werden darf. Der englische Begriff bedeutet wörtlich etwa „Ausrollungs-Sicherheitsrat“. Das Gremium schaut sich vor der Veröffentlichung Testberichte an und wägt mögliche Schäden ab. Am Ende steht ein Beschluss: freigeben, mit Auflagen freigeben oder blockieren. Wichtig ist, dass diese Gruppe unabhängig vom Entwicklungsteam arbeitet und nicht am Verkaufserfolg gemessen wird.

Warum Firmen sich selbst eine Bremse einbauen

In der Softwarebranche gilt seit Jahren die Regel: schnell veröffentlichen, Fehler später beheben. Bei einem verrutschten Button funktioniert das gut. Bei einem Sprachmodell, das Millionen Menschen gleichzeitig nutzen, funktioniert es schlecht. Ein Fehler lässt sich zwar zurücknehmen, die entstandenen Schäden aber nicht.

Deshalb trennen große KI-Firmen die Entscheidung über eine Veröffentlichung vom Team, das das Produkt gebaut hat. Wer monatelang an einem Modell gearbeitet hat, will es veröffentlichen. Dieser Wunsch ist verständlich, aber er ist kein guter Ratgeber bei Risikofragen. Ein separates Gremium hat diesen Druck nicht und kann nüchterner urteilen.

Dazu kommt der Druck von außen. Der EU-Rechtsakt über künstliche Intelligenz, kurz AI Act, verlangt für besonders riskante Systeme dokumentierte Prüfprozesse. Ein Board erzeugt genau diese Dokumentation. Firmen können damit im Streitfall belegen, dass sie ihre Risiken systematisch untersucht haben und nicht nur behauptet, alles sei sicher.

Der Weg von der Prüfung zum Beschluss

Am Anfang steht die Bewertung des Modells. Testerinnen und Tester versuchen gezielt, das System zu Fehltritten zu bewegen. Sie fragen etwa nach Anleitungen für Waffen, nach Schadsoftware oder nach beleidigenden Aussagen über bestimmte Gruppen. Dieses absichtliche Angreifen der eigenen Software nennt man Red Teaming. Die Ergebnisse werden gezählt und in einem Bericht zusammengefasst.

Viele Firmen ordnen jedes Modell danach einer Risikostufe zu. Solche Stufenmodelle heißen je nach Anbieter Preparedness Framework oder Responsible Scaling Policy. Die Grundidee ist immer gleich: Je gefährlicher eine Fähigkeit sein könnte, desto strenger die Auflagen. Ab einer bestimmten Stufe reicht die Zustimmung des Entwicklungsteams nicht mehr aus.

Dann tagt das Board. Typischerweise sitzen dort Sicherheitsforschung, Rechtsabteilung, Produktleitung und manchmal externe Fachleute zusammen. Sie diskutieren die offenen Punkte und beschließen. Ein häufiges Ergebnis ist keine klare Freigabe, sondern eine Freigabe mit Bedingungen: zuerst nur wenige Testnutzer, bestimmte Funktionen abgeschaltet, zusätzliche Filter aktiv. Man kann sich das wie die Zulassung eines Medikaments vorstellen, das erst in einer kleinen Gruppe erprobt wird.

Wenn Freigaben zur Schlagzeile werden

Direkt sichtbar ist so ein Gremium für Nutzer selten. Man merkt es indirekt, wenn ein angekündigtes Modell später erscheint als geplant, oder wenn eine Funktion zunächst nur in den USA verfügbar ist. Auch gestaffelte Starts, bei denen erst zahlende Kunden Zugang bekommen, gehen oft auf solche Auflagen zurück.

In den Nachrichten taucht der Begriff meist im Streitfall auf. Wenn Sicherheitsforscher ein Unternehmen verlassen und öffentlich sagen, ihre Bedenken seien übergangen worden, geht es fast immer um solche Freigabeentscheidungen. Auch Berichte über verkürzte Testphasen vor einem großen Produktstart betreffen genau diesen Prozess.

Ein verbreiteter Irrtum ist, ein Deployment Safety Board sei eine staatliche Behörde. Das ist es in der Regel nicht. Es handelt sich um freiwillige Selbstverpflichtung eines Unternehmens, das seine eigenen Regeln auch wieder ändern kann. Genau deshalb ist die entscheidende Frage bei jedem solchen Gremium immer: Wer sitzt darin, und darf es ein fertiges Produkt wirklich stoppen?