Robo Parametric Standard · RPS-1 v0.1 Entwurf

Eine offene Sprache für das Risiko von KI-Agenten und Robotern

RPS beschreibt, was ein System tun darf, wie gefährlich es sein kann, wie es überwacht wird und wie ein Vorfall nachgewiesen wird. So sprechen Versicherer, Betreiber und Behörden über dasselbe.

1 · Systemklassen

Drei Klassen, typische Trigger

Klasse	Systeme	Beispiel-Trigger
1 · KI- & Software-Agenten	LLM-Agenten für Kunden und Betrieb; Finanz- und Trading-Agenten; Multi-Agenten- und Web3-Systeme	Handlung ausserhalb des Mandats (Zahlung über Limit); bestätigtes Datenleck; Überschreitung von Risikolimiten; Ausfall des Basismodells oder Anbieters länger als N Stunden
2 · Industrie- & Logistikrobotik	Industrieroboter; kollaborative Roboter; mobile AGV/AMR	Kontakt mit Menschen über dem Schwellenwert nach ISO/TS 15066 mit Notstopp; Kollision; ungeplanter Stillstand länger als N Stunden
3 · Systeme der nächsten Generation	Humanoide Roboter; unbemannte Luft-, Land- und Wassersysteme	Verbindungs- oder Navigationsverlust; Sturz; Verletzung einer Sperrzone; kinetischer Schaden bei Dritten

Flottenrisiko wird separat erfasst: gleichzeitiger Ausfall von mehr als X % der Systeme nach einem Software- oder Modell-Update.

2 · Core Parameter Matrix

Acht Parameter statt fehlender Schadenhistorie

Jedes System erhält ein Profil. Bis das Register genügend Statistik hat, ist das Profil die Grundlage der Prämie.

AUT

Autonomie

Anteil der Entscheidungen ohne Mensch, L0 bis L5.

MAN

Mandat

Was das System darf: Zahlungslimiten, Zugriffsrechte, Kraft, Geschwindigkeit.

KIN

Kinetische Energie

Der physische Schaden, den das System verursachen kann.

ENV

Umgebung

Geschlossene Zelle, gemeinsamer Bereich oder öffentlicher Raum.

OVS

Aufsicht

Human in the loop, on the loop oder nachträglich; Zeit bis zum Stopp.

PRV

Herkunft

Basismodell, Version und Anbieter, um Korrelationen zu erfassen.

EVL

Prüfung

ISO 10218, ISO 13482, ISO/IEC 42001, Ergebnisse von Red-Teaming.

LOG

Protokollierung

Fähigkeit zu beweisen, was geschah: von lokalen Logs bis zu signierten, attestierten Datensätzen.

3 · Trigger

Wann ein Trigger in den Standard aufgenommen wird

Eine parametrische Police zahlt, wenn ein definiertes Ereignis eintritt. Das funktioniert nur, wenn das Ereignis real und beweisbar ist.

Beobachtbar: Das Ereignis hinterlässt messbare Spuren.
Unabhängig bestätigbar: Mindestens eine Quelle ausserhalb des Betreibers kann es prüfen.
An realen Schaden gebunden: Der Trigger korreliert mit tatsächlichem Schaden; das verbleibende Basisrisiko wird vor dem Kauf offengelegt.

4 · Orakel und Nachweise

Anforderungen an Datenquellen

Hardware-Attestierung der Telemetrie (TPM oder TEE).
Vertrauenswürdige Zeit über PTP (IEEE 1588) oder GNSS, mit Zeitstempeln nach RFC 3161.
Quorum unabhängiger Orakel, M aus N.
Unabhängige Berechnungsstelle und ein Einwandfenster von 7 bis 30 Tagen.
Ein Ledger kann als manipulationssicheres Journal dienen, nie als Quelle der Wahrheit.

5 · Zertifizierung

Drei Stufen

Stufe 1

RPS Ready

Das RPS-Profil des Systems ist vollständig und dem Versicherer oder Partner zugänglich.

Stufe 2

RPS Verified

Eine akkreditierte Prüfstelle hat Profil, Protokollierung und Orakel-Setup geprüft.

Stufe 3

RPS Insured

Ein zugelassener Versicherer hat für dieses System eine Police auf RPS-Triggern ausgestellt.

6 · Governance des Standards

Öffentlich versioniert

Der Technische Rat hat Quoten für Versicherung, Betreiber und Hersteller, Wissenschaft und Zivilgesellschaft; keine Gruppe hat die Mehrheit. Versionen heissen RPS-1.0, 1.1 usw.; jede durchläuft mindestens 60 Tage öffentliche Vernehmlassung.

Kompatibel mit EU AI Act (Protokollierung, menschliche Aufsicht), NIST AI RMF, ISO/IEC 42001, ISO 10218, ISO/TS 15066 und AIUC-1.

RPS-1 v0.1 ist ein Arbeitsentwurf zur öffentlichen Kommentierung. Der vollständige Text und das Schema des Agent Incident Record sind auf GitHub veröffentlicht und mit der DOI 10.5281/zenodo.23476666 archiviert. Kommentare über GitHub-Issues oder an info@roboins.org.