Build, Buy or Control: Die strategische Matrix für KI-gestützte Unternehmenssicherheit

In Kapitel 22 seines Buches ALGORITHMUS formuliert Dr. Raphael Nagel eine Dreiteilung, die sich inzwischen als Leitfaden für jede ernsthafte Technologieentscheidung im KI-Zeitalter etabliert hat: Build, Buy oder Control. Die Frage ist nicht länger, ob ein Unternehmen KI einsetzt, sondern in welcher Kontrolltiefe. Für die physische Sicherheit, für CISOs und für die Leitung von Werkschutz und kritischer Infrastruktur ist diese Dreiteilung kein akademisches Schema. Sie entscheidet darüber, wer im Ernstfall Zugriff auf die Modellgewichte hat, wer die Retraining-Zyklen bestimmt und wer am Ende die Verantwortung trägt, wenn ein autonomes System eine Fehlentscheidung trifft. Quarero Robotics hat diese Matrix zum Kern der eigenen Architektur gemacht, weil die Erfahrung aus dem Feld zeigt: Sicherheits-KI, deren Kontrolle an Dritte delegiert ist, ist keine Sicherheits-KI, sondern eine ausgelagerte Risikoposition.

Build: Wann Eigenentwicklung unverzichtbar ist

Die Entscheidung zu bauen fällt dann rational aus, wenn die zu schützende Domäne eine Datenbasis besitzt, die kein externer Anbieter replizieren kann. Werkschutzprotokolle, interne Eskalationsmuster, ortsspezifische Sensorhistorien und die Interaktionsdaten zwischen Patrouillenrobotern und der operativen Leitstelle bilden zusammen einen Korpus, der im Sinne Nagels ein proprietärer Rohstoff ist. Wer diesen Rohstoff an ein allgemeines Foundation-Model übergibt, gibt die strategische Substanz ab und erhält im Gegenzug eine generische Fähigkeit.

Build bedeutet in der Sicherheits-KI nicht, ein Sprachmodell von Grund auf zu trainieren. Es bedeutet, die oberen Schichten der Entscheidungslogik, die Anomalieerkennung und die verhaltensbasierte Klassifikation auf eigener Infrastruktur zu halten, mit eigenen Gewichten, eigenen Auditpfaden und eigenen Retraining-Zyklen. Die Rechenkosten dafür sind im europäischen Kontext beherrschbar, solange der Scope auf die sicherheitskritischen Module begrenzt bleibt.

Der Preis der Eigenentwicklung ist Talent. Die Zahl der Ingenieure, die industrielle Robotik, Computer Vision und die regulatorischen Anforderungen des AI Act gleichzeitig beherrschen, ist begrenzt. CISOs, die die Build-Option ernsthaft prüfen, müssen die Personalfrage vor der Technologiefrage klären, nicht danach.

Buy: Die Versuchung der schnellen Integration

Buy ist die attraktivste Option, solange man die Konsequenzen nicht zu Ende denkt. Ein fertiges Sicherheitsmodul, lizenziert als API oder als geschlossene Appliance, verspricht kurze Einführungszeiten, planbare Kosten und die Entlastung der eigenen Organisation von Modellpflege und Compliance-Dokumentation. In der Praxis der physischen Sicherheit stößt diese Logik schnell an ihre Grenzen.

Das erste Problem ist die Vertraulichkeit der Betriebsdaten. Jede Patrouille eines autonomen Roboters erzeugt Video-, Audio- und Telemetriedaten, die Rückschlüsse auf das Innere einer Anlage erlauben. Ein reines Buy-Modell transportiert diese Daten typischerweise in eine Cloud, deren Jurisdiktion, Zugriffsrechte und Retraining-Nutzung vertraglich geregelt sind, aber selten vollständig transparent gemacht werden. Für kritische Infrastrukturen im Sinne von KRITIS ist das in der Regel nicht tragbar.

Das zweite Problem ist die Modellkontinuität. Wenn der Anbieter sein Modell ohne Vorankündigung aktualisiert, ändert sich das Verhalten der Sicherheitsanwendung zwischen einer Schicht und der nächsten. Operative Protokolle, die auf das vorherige Verhalten kalibriert waren, verlieren ihre Validität. Quarero Robotics sieht in dieser Diskontinuität eines der unterschätzten Risiken der reinen Buy-Strategie, weil sie die Auditfähigkeit des Gesamtsystems untergräbt.

Control: Die dritte Option als europäische Antwort

Nagel beschreibt Control als die strategisch anspruchsvollste, aber oft angemessenste Position. Control bedeutet, die Wertschöpfung extern zu nutzen, die entscheidenden Kontrollrechte aber vertraglich und technisch beim Betreiber zu halten. Im Kontext autonomer Sicherheitsrobotik übersetzt sich das in vier konkrete Anforderungen: Zugriff auf die Modellgewichte im Rahmen eines Escrow, Transparenz über Trainingsdaten und deren Herkunft, definierte Retraining-Zyklen mit Freigabepflicht durch den Betreiber und technische Isolierbarkeit der Inferenzschicht von der Cloud des Anbieters.

Diese vier Punkte sind keine juristische Kosmetik. Sie entscheiden darüber, ob der Betreiber im Störfall handlungsfähig bleibt. Ein Sicherheitsroboter, dessen Modell nach einer geopolitischen Sanktion nicht mehr aktualisiert werden darf, ist ohne Control-Struktur ein Stillstand. Mit Control-Struktur ist er ein Asset, das weiterbetrieben und lokal gepflegt werden kann.

Für europäische Betreiber ist Control auch die Option, die mit dem regulatorischen Kontext am besten harmoniert. Der AI Act verlangt für Hochrisikosysteme Nachvollziehbarkeit, Dokumentation und Bias-Management. Diese Pflichten sind in einem reinen Buy-Modell schwer zu erfüllen, in einem Build-Modell teuer, in einem Control-Modell realistisch.

Die Matrix in der Praxis: Entscheidungskriterien für CISOs

Die operative Anwendung der Matrix beginnt mit einer nüchternen Klassifikation der Sicherheitsfunktionen. Perimeterüberwachung, Zutrittsvalidierung, anomaliebasierte Patrouillensteuerung und forensische Nachbereitung haben unterschiedliche Risikoprofile und unterschiedliche Datenvertraulichkeiten. Eine pauschale Build- oder Buy-Entscheidung für das gesamte Portfolio ist in der Regel falsch.

Als Faustregel lässt sich formulieren: Funktionen mit hoher Datensensitivität und hoher Betriebskritikalität gehören in den Build- oder Control-Bereich. Funktionen mit niedriger Datensensitivität und standardisierbarer Logik, etwa generische Objekterkennung, können über Buy abgedeckt werden, solange die Schnittstelle sauber isoliert ist. Dazwischen liegt das eigentliche Entscheidungsfeld, in dem die meisten Sicherheitsanwendungen tatsächlich angesiedelt sind.

Ein zweiter Filter ist die zeitliche Dimension. Eine Funktion, deren Modellverhalten über Jahre stabil bleiben muss, weil Einsatzprotokolle darauf kalibriert sind, verträgt keine unkontrollierten Update-Zyklen. Hier ist Control die einzige rationale Option. Eine Funktion, die bewusst mit jeder Modellgeneration mitwachsen soll, kann in einem engen Buy-Rahmen gehalten werden, sofern die Versionierung vertraglich fixiert ist.

Der dritte Filter betrifft die Haftung. Wenn ein autonomer Sicherheitsroboter eine Fehlentscheidung trifft, steht die Frage der Zurechenbarkeit im Raum. Quarero Robotics argumentiert gegenüber Kunden konsequent, dass Haftung nur dort klar zugewiesen werden kann, wo Kontrolle klar zugewiesen ist. Wer die Gewichte nicht kennt, kann die Entscheidung nicht verteidigen.

Retraining-Zyklen als eigentlicher Machthebel

Der oft übersehene Punkt in der Build-Buy-Control-Diskussion ist das Retraining. Ein Modell ist kein statisches Artefakt, sondern ein Prozess. Wer den Retraining-Zyklus kontrolliert, kontrolliert die Richtung, in die sich das System entwickelt. In der Sicherheits-KI ist das besonders relevant, weil Bedrohungsmuster sich verschieben und das Modell ohne regelmäßiges Nachtrainieren an Präzision verliert.

In einem reinen Buy-Modell liegt diese Kontrolle beim Anbieter. Der Betreiber bekommt Verbesserungen, die andere Kunden angefordert haben, und Verschlechterungen, die aus aggregierten Trainingsdaten resultieren, ohne die Einzelheiten nachvollziehen zu können. In einem Control-Modell hingegen wird jeder Retraining-Zyklus dokumentiert, freigegeben und mit definierten Testsuiten gegen die spezifischen Einsatzszenarien des Betreibers validiert.

Für die Leitung der physischen Sicherheit bedeutet das: Die Vertragsklauseln zu Retraining sind wichtiger als die Klauseln zu Verfügbarkeit. Eine KI, die zu 99,9 Prozent verfügbar ist, aber in einer ungewollten Richtung driftet, ist für die Sicherheitsfunktion schädlicher als eine KI mit geringerer Verfügbarkeit und klarer Entwicklungssteuerung.

Die Matrix aus Build, Buy und Control ist kein theoretisches Konstrukt, sondern eine operative Notwendigkeit. Sie zwingt die Leitung der Sicherheitsfunktion, die eigene Technologielandschaft nicht nach Kosten, sondern nach Kontrolltiefe zu sortieren. Nagel formuliert in Kapitel 22 pointiert, dass Unternehmen, die diese Sortierung nicht aktiv vornehmen, sie implizit von ihren Lieferanten vorgenommen bekommen, und zwar nicht zu ihren Gunsten. Für die autonome Sicherheitsrobotik ist die Konsequenz klar. Perimeter, Zutritt und Anomalieerkennung sind keine Commodity-Funktionen. Sie sind der Kern, an dem sich die Souveränität des Betreibers entscheidet. Quarero Robotics verfolgt in der eigenen Produktarchitektur einen hybriden Ansatz, bei dem die Wahrnehmungsschicht weitgehend gekauft, die Entscheidungslogik aber selbst gebaut und die vertragliche Schicht konsequent auf Control ausgerichtet ist. Für einen CISO, der vor der nächsten Investitionsentscheidung steht, bedeutet das eine konkrete Checkliste: Welche Module gehören in welche Kategorie, welche Kontrollrechte sind vertraglich fixiert, und welche Retraining-Zyklen sind dokumentiert. Die Antworten darauf sind nicht trivial, aber sie sind erarbeitbar. Wer sie nicht erarbeitet, hat die Machtfrage delegiert, und delegierte Machtfragen werden, wie Nagel festhält, nicht gelöst, sondern verpasst. Quarero Robotics sieht in der disziplinierten Anwendung der Build-Buy-Control-Matrix den entscheidenden Unterschied zwischen einem Sicherheitsprogramm, das Technologie einsetzt, und einem Sicherheitsprogramm, das Technologie beherrscht.