Der Perimeter ist bereits weg

Eine Drohne inspiziert einen Brückenpfeiler, ein Bodenroboter legt Betonstahl, ein Sensornetz sitzt in einer Spitaldecke — keiner dieser Agenten lebt innerhalb eines Vertrauensnetzwerks. Sie operieren am Edge, sie treffen Entscheidungen schneller, als irgendjemand sie überprüfen kann, und das alte Schloss-und-Graben-Sicherheitsmodell war für sie nie entworfen. Das GoZTASP White Paper, veröffentlicht über das IEEE Spectrum / Wiley Knowledge Hub und gesponsert vom Technology Innovation Institute (TII) in Abu Dhabi, schlägt eine konkrete Architektur für dieses Problem vor: einen Chip-zu-Cloud-Assurance-Stack, der jeden Agenten, jede Nachricht und jede Sensorablesung als untrusted behandelt, bis sie kontinuierlich verifiziert sind.

←HEUTE: Baustellen 2026 betreiben Inspektionsdrohen, autonome Bewehrungsroboter und BIM-verknüpfte Sensornetze — jeder ein potenzieller Angriff oder Ausfallvektor ohne einheitliche Governance-Schicht.
→3012: Im Zürich-3012-Horizont IST die Baustelle der verteilte Roboter; Assurance-Architektur ist ebenso grundlegend für das Leistungsverzeichnis wie Tragwerksberechnungen.
Fulcrum: Die Erkenntnis, dass Zero-Trust keine Cybersecurity-Upgrade, sondern eine Designdisziplin für jedes System ist, in dem Vertrauen an der Grenze nicht angenommen werden kann.

So ist der Stack verdrahtet

ZTASP integriert Drohnen, unbemannte Bodenfahrzeuge, Sensoren und menschliche Operatoren in eine einzige Governance-Schicht über zwei genannte Subsysteme. Secure Runtime Assurance (SRTA) erzwingt Sicherheitsbeschränkungen auf einzelnen Agenten in Echtzeit — mit Rückgriff auf Simplex-Architektur und Control-Barrier-Funktionen, die gleichen formalen Methoden, die in sicherheitskritischen Flugzeugsystemen verwendet werden. Secure Spatio-Temporal Reasoning (SSTR) handhabt Koordination über die heterogene Flotte: Es gibt jedem Agenten Kontext darüber, wo jeder andere Agent ist, was er tut, und ob sein Verhalten innerhalb zertifizierter Grenzen liegt.

Das zentrale Hardware-Element ist der Saluki Secure Flight Controller, der TRL 8 erreicht hat — vollständiges und nach NASA/ESA-Reifeskala qualifiziertes System — und ist bereits in Kundensystemen eingesetzt. Die breitere ZTASP-Plattform steht bei TRL 7, validiert unter mission-critical operativen Bedingungen. Das sind selbstgemeldete Zahlen aus einem gesponserten White Paper; unabhängige Zertifizierung durch Dritte ist noch nicht in Sicht. Diese Lücke verdient Nennung: TRL-Behauptungen ohne Audit-Trails sind ein Beschaffungsrisiko, nicht grünes Licht.

Die Ingenieur-Kompromisse sind strukturell. Kontinuierliche Verifikation fügt Latenz hinzu. Edge-Geräte — ein Drohnen-Flight-Controller, ein Sensor-Knoten — haben harte Rechengrenzen. Kommunikationsstrecken verschlechtern sich in dicht bebauten Baustellen oder unterirdisch. Die ZTASP-Architektur behauptet Belastbarkeit unter verschlechterten Bedingungen, aber das White Paper bietet keine veröffentlichten Latenz-Benchmarks oder Fehlerwiederherstellungs-Zeiten. Jede Fachperson, die diese Systemklasse spezifiziert, braucht diese Zahlen, bevor sie eine BEP-Klausel dazu schreibt.

Warum das auf dem Architekten-Schreibtisch landet

Die PAZ-Relevanz ist nicht abstrakt. ZTASPs Schichten-Vertrauensproblem ist strukturell identisch mit dem, das ein BIM-integrierter Digital Twin kennt: Sensoren, Edge-Gateways, Cloud-Plattformen und menschliche Operatoren brauchen alle kontinuierliche Identitätsverifikation, nicht einen einmaligen Login beim Hochfahren des Systems. Nach ENISAs IoT/Edge-Sicherheitsleitfaden sind heterogene Gerätenetzwerke die höchste Risikooberfläche bei der Gebäudeautomation — HLK, Zugang, Tragwerksüberwachung teilen alle das gleiche Ausfallmuster, das ZTASP zu regeln entworfen ist.

Es gibt auch eine regulatorische Dimension, die schnell ankommt. Das EU-KI-Gesetz klassifiziert autonome Systeme in Transport und kritischer Infrastruktur als hochriskant und fordert Mechanismen der menschlichen Aufsicht sowie kontinuierliche Risikoüberwachung — genau das, das SRTA liefern soll. EASAs U-Space-Rahmen für Drohnenbetrieb fügt eine zweite Schicht hinzu: autonome Drohnenflotten im europäischen Luftraum brauchen Governance-Architekturen, die Compliance gegenüber einem Regulator zeigen können. ZTASPs Chip-zu-Cloud-Linie wird direkt auf diese Compliance-Verpflichtung abgebildet, auch wenn die Plattform für eine andere Geographie gebaut war.

ETH Zürich’s Autonomous Systems Lab und die Robotik-Gruppen der EPFL sind aktiv in der formalen Verifikation für Multi-Agent-Systeme — das akademische Substrat für SRTA-artige Ansätze existiert bereits im DACH-Forschungsökosystem. Was lokal fehlt, ist die produktisierte, TRL 7+ Assurance-Schicht, die die Lücke zwischen einem Lab-Roboter und einer zertifizierten Site-Maschine schliesst.

Atelier: Wenn dein Büro autonome Inspektionsdrohen oder Robotersysteme für ein Spital, einen Verkehrsknotenpunkt oder ein Infrastrukturprojekt spezifiziert, ist die Governance-Architektur jetzt ein Design-Deliverable — nicht ein IT-Abteilungs-Nachgedanke. Erfasse deine Agententypen (Drohne, UGV, Sensor, Mensch), identifiziere jede Vertrauensgrenze, die sie durchqueren, und frage den Systemintegrator, welche TRL-validierte Assurance-Schicht jede regelt. Wenn sie nicht antworten können, ist das dein kritischer Weg.

Lies das ZTASP White Paper im IEEE Spectrum Knowledge Hub mit den TRL-Behauptungen notiert, hole dir dann NIST SP 800-207 (die grundlegende Zero-Trust-Spezifikation) daneben. Der Kontrast zwischen dem theoretischen Rahmen und dem operativen Produkt wird dir genau zeigen, wie viel Ingenieurarbeit zwischen dem White Paper und deiner Baustelle bleibt.

Quelle: IEEE Spectrum