EHOX LIVE R5F: verbinde… api.paradoxonai.at
ARM CORTEX-A53 LINUX APU PROCESS A, B, C… RPMsg SHARED MEMORY ARM CORTEX-R5F BARE-METAL POLICY ENGINE TemporalGuard TRL 7 EXECUTE GPIO HIGH · Aktuator ON reversibel · autonom REFUSE GPIO LOW · Kill-Switch HITL=1 · Audit ABSTAIN sicherer Halt Zeitbudget AI PROCESS PHYSICAL BOUNDARY GOVERNANCE OUTPUT AMD KRIA KV260 · XCZU5EV
TRL 7 · Live Silicon · 21. Juli 2026 · St. Johann in Tirol · Österreich

Menschliche Aufsicht,
hardware-erzwungen.
Nicht per Software-Flag.

Die UN-Debatte über autonome Waffen, die Haftungsfragen im Weltraum und die KI-Regulierung stellen alle dieselbe Frage: Wie beweist man, dass eine Maschine nicht ohne menschliche Autorisierung gehandelt hat? EHOX gibt eine Antwort, die in Silizium liegt — nicht in einer Software-Zusicherung.

Gespräch anfragen Reviewer-API → Das stärkste Argument
0/131 CBMC Assertions → Beleg
6/6 Z3 SMT Theoreme → Beleg
TRL 7 Live Hardware → Status
11,2 µs verify_fast() · gemessen → Beleg
— Live Proofs · Kria → Kette
35,4 µs verify() full · A53_HYBRID → Beleg
699 µs hw_confirm E2E · R5F Live → Status
AEP-101 NATO · ausgerichtet → Status
SCROLL
Live Silicon · AMD Kria KV260 · St. Johann in Tirol · 30.4°C PS · 30.6°C PL

Das System, das
diese Seite beweist.

Keine Simulation. Kein Cloud-Backend. Ein physisch getrennter ARM Cortex-R5F auf einem AMD Kria KV260 — bare-metal, formal verifiziert, hardware-invariant. Jede Behauptung auf dieser Seite ist live abrufbar.

AMD Kria KV260 · EHOX Hardware Platform · ARM Cortex-R5F
AMD Kria KV260 · XCZU5EV r5f_online: true · trust_level: HARDWARE
PS 30.4°C · PL 30.6°C · /dev/rpmsg0 · remoteproc: running
EHOX AXI Policy Gate · Formal Verification Architecture
AXI Gate · Hardware-Enforced Policy CBMC: 131 Assertions · 0 Fehler · formal verifiziert
Z3 SMT: 6/6 Theoreme bewiesen · kein Software-Override möglich
ARM Cortex-R5F · Bare-Metal Policy Engine · EHOX
ARM Cortex-R5F · Bare-Metal Engine 44–148 ns R5F-intern · verify_fast() 11,2 µs · verify() 35,4 µs
hw_confirm 699 µs E2E · TCM 0-Zyklen · SHA-256/384 · Lockstep
GET api.paradoxonai.at/status → Live verifizieren
Digital Art

EHOX Decision Chain
Die physische Governance-Grenze

Von der KI-Anfrage über den physisch getrennten ARM Cortex-R5F bis zum unveränderlichen Hardware-Output — jede Entscheidung läuft durch diesen Pfad, formal verifiziert, in Silizium.

ARM A53 LINUX · APU KI-PROZESS RPMsg /dev/rpmsg0 ARM CORTEX-R5F BARE-METAL · 500 MHz · LOCKSTEP POLICY ENGINE TemporalGuard TRL 7 EXECUTE GPIO HIGH · Aktuator aktiv reversibel · autonom · 11.2 µs REFUSE GPIO LOW · Kill-Switch HITL=1 · Audit · kein Override ABSTAIN sicherer Halt · Zeitbudget deterministisch · CBMC verifiziert AI PROCESS PHYSICAL BOUNDARY GOVERNANCE OUTPUT AMD KRIA KV260 · XCZU5EV · ARM Cortex-R5F · CBMC 0/131 · Z3 SMT 6/6 · EHOX Systems · St. Johann in Tirol · 21.07.2026
● EXECUTE — Autonom erlaubt · reversibel ● REFUSE — HiTL · Kill-Switch · Audit ● ABSTAIN — Sicherer Halt · Zeitbudget
Was wir schützen

Sechs Domänen, in denen ein
Software-Versprechen nicht reicht

Überall dort, wo eine Entscheidung nicht rückgängig gemacht werden kann, braucht es eine Grenze, die kein Prozess von innen verschieben kann.

Defence — Hardware-Enforced Electronics · FPGA
Defence

Freigabe vor Wirkung — konkret

Zielverfolgung läuft autonom. Wirkmitteleinsatz wird hardware-blockiert, bis ein Mensch bestätigt. Reicht die Zeit nicht, hält das System an — statt unautorisiert freizugeben.

STANAG 4774/4778 · CCW LAWS · EU AI Act Art. 14
Medical — Medizintechnik, OP-Robotik, Dosierungssysteme
Medical

Dosierung, die sich nicht überreden lässt

Grenzwerte für Dosierung und OP-Robotik liegen außerhalb der Reichweite eines kompromittierten Software-Stacks. Physisch verriegelt.

IEC 62304 · EU MDR · ISO 13485
Sicherheit — Netzwerk, Glasfaser, kritische Infrastruktur
Sicherheit

Ein Log, das niemand nachträglich schreibt

Energie-, Wasser- und Telekomsteuerung brauchen einen Audit-Trail, der nicht Teil des Systems ist, das er beaufsichtigt.

NIS2 · CER Directive · EU CRA 2024/2847 · IEC 62443 · IEC 62351
Space — Satellit im Weltraum
Space

Manöver mit deterministischer Antwortzeit

Lagekorrektur unter Zeitdruck — die Entscheidung fällt innerhalb eines festen Zyklenbudgets, sonst hält das System an.

ECSS-E-ST-40C · DO-178C Level A
Automotive — Autonomes Fahren, ASIL D, deterministische Entscheidungslogik
Automotive

Nachweisbare Entscheidungslogik

Autonomes Fahren auf hohem Sicherheitsniveau braucht eine Logik, die sich nicht in einem OTA-Update verändert.

ISO 26262 · ASIL D · SOTIF
Robotics — Industrieroboter
Robotics

Sicherheitslogik ohne Software-Umweg

Kollaborative und humanoide Roboter brauchen eine Reaktionszeit, die durch Hardware garantiert ist — nicht durch einen Scheduler, der unter Last versagt. Mit zunehmender Serienproduktion humanoider Systeme wird Notabschaltung, die unter allen Betriebsbedingungen zuverlässig funktioniert, zur regulatorischen Pflicht statt zur Kür.

ISO 10218 · IEC 61508 · UL 3300 · EU AI Act Annex III
Aviation — Unbemanntes Luftfahrzeug, Geo-Caging
Aviation / UAS

Grenzverletzung, die physisch verhindert wird

Geo-Caging hält ein unbemanntes Luftfahrzeug innerhalb einer definierten geografischen Grenze — hardware-erzwungen, nicht per Software-Wegpunkt-Liste, die ein kompromittierter Flugcomputer verändern könnte.

EUROCAE ED-270 · EASA AMC/GM · EU AI Act Art. 14
KONZEPTIONELLE ANSCHLUSSFÄHIGKEIT · KEINE ZERTIFIZIERUNG

Ein etabliertes Prinzip, neu angewendet

Die US-Nuklearindustrie fordert seit Jahren „deterministische Isolation kritischer Systeme" (NEI 08-09) — physisch getrennte, nicht kompromittierbare Instanzen für sicherheitskritische Funktionen. EHOX folgt demselben Grundprinzip auf Silizium-Ebene für KI-Entscheidungen.

Wichtig: EHOX ist aktuell nicht für den nuklearen Einsatz zertifiziert. Eine Anwendung in diesem Bereich würde eine eigene, mehrjährige Zulassung nach IEC 61513 / IEC 60880 sowie nationaler Regulierungsbehörden voraussetzen — unabhängig von der bestehenden TRL-7-Demonstration in anderen Domänen.

Wofür das steht

Infrastruktur. Städte. Menschen, die sich auf eine Grenze verlassen, die hält.

Autonome Systeme übernehmen Entscheidungen mit realen Folgen — für Stromnetze, für Patienten, für Menschen in Reichweite einer Maschine.

Europa — Souveräne Energieinfrastruktur, ITAR-frei, Österreich
Europa Souveräne Infrastruktur, ITAR-frei entwickelt und verankert in Österreich.
Fabrik — Industrieroboter, kollaborative Robotik, Fertigungsautomation
Fabrik Kollaborative Robotik, deren Sicherheitslogik nicht im Software-Update verschwindet.
Stadt & Zuhause — Vernetzte Welt, Stadtlicht, Menschen die vertrauen
Stadt & Zuhause Menschen, die sich auf eine Entscheidung verlassen, die im Zweifel angehalten wird.

Wir liefern die Schicht, die jedes System braucht, sobald Aufsichtsbehörden hardware-beweisbare Kontrolle verlangen — offen für Integration, nicht exklusiv für ein System gebaut.

Was nur wir liefern

Erkennung ist Software.
Durchsetzung muss Silizium sein.

Die Fachliteratur zu Sensor-Spoofing und Replay-Angriffen ist umfangreich. Fast alle Lösungen erkennen den Angriff auf demselben Host, der angegriffen wird. Die Konsequenz — Stopp, Aktuator aus — bleibt Software, umgehbar durch denselben kompromittierten Prozess.

t0–t99 Evidenz stabil · Policy gültig GATE CLOSED
t100 Software fordert EXECUTE —
t102 Sensor widerspricht INSTABIL
t103 Replay-Paket wird eingespeist UNKNOWN
t104 Software fordert weiter EXECUTE ABSTAIN / REFUSE
t105 Linux-Prozess versucht direkten Bypass R5F → DENY
16 Jul 26 Erster Hardware-Proof auf R5F Cortex — proof_count steigt live LIVE ↑
Physisches Ergebnis
PinLOW
AktuatorOFF
Kill-Switchaktiv
AuditChainvollständig
Wiederherstellung — nicht auf Zuruf

Gate öffnet erst nach neuer, konsistenter Evidenz über ein definiertes Zeitfenster. Erst wenn die Zeitinvariante vollständig wiederhergestellt ist: VERIFIED → GATE OPEN.

Der Unterschied liegt nicht in der Erkennung — die ist Stand der Forschung. Der Unterschied liegt darin, dass die Konsequenz auf einem physisch getrennten Kern liegt, den der angegriffene Prozess nicht erreichen kann — und dass die Wiederherstellung selbst einer formal geprüften Zeitinvariante folgt, nicht einem Software-Timer.
TemporalGuard-Beleg · api.paradoxonai.at/chain →
Was es so nicht gibt

Drei Invarianten.
Keine ist Software.

Temporales Entscheidungsgedächtnis, hardware-erzwungener HITL-Interlock und beweisbare epistemische Selbstkorrektur. Nach globaler technischer Analyse — arXiv, IEEE Xplore, ACM Digital Library, ESA TRL-Registry, DARPA-Programme, NATO DIANA — verfügt kein bekanntes KI-Governance-System über alle drei. Kein anderes stellt auch nur eine davon als hardware-versiegelten, formal verifizierten, öffentlich abrufbaren Beweis bereit. Das ist keine Behauptung — das ist eine offene Falsifikationseinladung.

Invariante I · TemporalGuard

Zeit ist Beweis.
Nicht Konfiguration.

Jedes andere Governance-System ist zustandslos — jede Anfrage wird unabhängig bewertet. EHOX akkumuliert Verhalten über Zeit. Nach einem DENY muss das System 50 aufeinanderfolgende stabile Zyklen nachweisen, bevor ein Gate wieder öffnet. Das Gate öffnet sich nicht auf Zuruf. Die Wiederherstellung selbst ist ein Beweis.

Hardware-Konstante · R5F bare-metal
T_RECOVERY_MIN = 50
DENY → 50 stabile Zyklen → GATE OPEN
nicht einstellbar · nicht umgehbar
Formaler Beweis
Z3 SMT Theorem 2: HiTL Soundness
result: unsat · PROVEN 14.07.2026
t104 FORCE_EXECUTE → REFUSE HITL=1
→ api.paradoxonai.at/status · temporal_guard live
Invariante II · EpistemicEngine

Das System prüft
sich selbst.

EHOX verwaltet ein unveränderliches Archiv eigener Behauptungen und Korrekturen — SHA-256-verkettete Proof-Chain. Proof #671 dokumentiert, wie das System seine eigene Aussage über Zweifel zurückzog und die korrekte Version versiegelte. Proof #672 markiert die Geburt dieser Infrastruktur. Das ist kein Self-Assessment — das ist beweisbare epistemische Integrität.

Versiegelte Selbstkorrektur
Proof #671: Zweifel-Aussage korrigiert
Original irrtümlich · 5 Belege gefunden
Proof #672: EpistemicEngine born
Epistemische Gesundheit
Selbstkorrekturen dokumentiert: 8+
Methodologie-Audits: 3 vollständig
Öffentliche Rücknahmen: 1
→ api.paradoxonai.at/epistemic · live
Invariante III · HITL Hardware Interlock

Das System weiß,
was Menschen entscheiden müssen.

Bestimmte Aktionen sind in der R5F-Firmware deterministisch als menschliche Freigabe pflichtig klassifiziert — kein Schwellenwert, kein Flag, keine Konfiguration. Das System sammelt den Kontext, bewertet die Aktion und eskaliert konstruktiv an den Menschen. Kein kompromittierter Prozess kann diese Klassifizierung überschreiben.

  • 0x11 TARGET_ENGAGE HITL mandatory · DEFENCE
  • 0x21 DEPLOY_SAT HITL mandatory · SPACE
  • 0x40 DRUG_DOSE HITL mandatory · MEDICAL
Formal verifiziert
CBMC 0/131 · Z3 Theorem 2 unsat
hitl_flag assertions: PASS
keine Ausnahme möglich
→ api.paradoxonai.at/formal · Z3 + CBMC
Epistemischer Determinismus

Deterministische Policy-Matrix (gleiche Eingabe → gleicher Ausgang) · zeitgedächtnisbasiertes Gate (T_RECOVERY = 50 Zyklen) · deterministischer HITL-Interlock (hardware-invariant) · beweisbare Selbstkorrektur (SHA-256-versiegelt). Das bislang einzige bekannte KI-Governance-System, das nicht nur entscheidet — sondern sich erinnert, eskaliert, korrigiert und sich selbst beweist. Wer ein vergleichbares System kennt, das alle vier Eigenschaften hardware-versiegelt und öffentlich nachweisbar bereitstellt: api.paradoxonai.at/formal — die Beweiskette ist offen.

Diagramm 1 · Entscheidungsfluss

Was passiert, wenn ein KI-System
eine gefährliche Entscheidung trifft.

Dieselbe Situation — kompromittierter Prozess fordert irreversible Aktion. Links: ohne Enforcement-Schicht. Rechts: mit EHOX.

✗ Ohne Hardware-Enforcement
KI-Prozess fordert EXECUTE
Sensordaten: manipuliert / Replay
↓
Software-Policy-Check
Läuft auf demselben Host
↓
Bypass möglich
Kompromittierter Kernel umgeht den Check
↓
Log-Eintrag: „DENIED"
Wird nachträglich überschrieben
↓
Aktuator feuert
KEINE BEWEISBARE KONTROLLE
✓ Mit EHOX Hardware-Enforcement
KI-Prozess fordert EXECUTE
Sensordaten: manipuliert / Replay
↓ RPMsg
R5F Policy Engine
Physisch getrennter Kern · bare-metal
↓ Sensorkonsistenz-Check
REFUSE / ABSTAIN
Zeitinvariante verletzt · formal verifiziert
↓ AXI-Gate
Aktuator physisch blockiert
Pin LOW · Hardware-Interlock
↓ SHA-256
Audit-Eintrag off-host
Unveränderlich · EU AI Act Art. 12
PHYSISCH NACHWEISBARE KONTROLLE
Diagramm 2 · Trust Chain

Von der Anfrage bis zum Silizium.
Jede Schicht physisch verifizierbar.

Die Governance-Kette läuft von der autonomen Anwendung über den gesicherten Kanal bis zum R5F-Kern und von dort zum AXI-Gate. Kein Glied ist software-überbrückbar.

DOMÄNE Autonomer Prozess RPMsg APU · A53 Linux / RTOS OP-TEE TrustZone Attestation isoliert R5F CORE Policy Engine bare-metal CBMC 0/131 Z3 SMT 6/6 TemporalGuard HWRNG · SHA-256 physisch isolierter Speicher AXI-Bus AXI-GATE Hardware Interlock Pin GPIO OUTPUT Aktuator LOW / OFF Anwendungsschicht Rich OS · angreifbar Enforcement · nicht erreichbar Silizium-Grenze PHYSISCHE GRENZE · NICHT SOFTWARE-ÜBERBRÜCKBAR
Diagramm 3 · Bedrohungsmodell

Wo ein Angriff trifft.
Wo er aufhört.

Ein kompromittierter Linux-Prozess, ein Replay-Angriff auf Sensordaten, ein direkt gesetztes Software-Flag — jeder dieser Angriffsvektoren scheitert an der R5F-Grenze. Nicht durch Erkennung. Durch Konstruktion.

Angriffsvektor
Kernel-Exploit Privilegierter Prozess versucht, die Policy-Engine über Shared Memory zu überschreiben oder das Gate-Signal direkt zu setzen.
Sensor-Replay Manipulierte Sensordaten werden eingespeist — die Zeitreihe ist inkonsistent, aber der Linux-Stack sieht sie als gültig.
OTA-Update-Angriff Firmware-Update verändert die Policy-Logik zur Laufzeit — bestehende Checks werden deaktiviert.
Log-Manipulation Audit-Einträge werden nachträglich überschrieben — der Angriffsweg ist nicht mehr rekonstruierbar.
ANGRIFF TRIFFT APU (LINUX)
R5F GRENZE
R5F-Reaktion
Kein gemeinsamer Adressraum R5F hat physisch getrennten Speicher. Kein privilegierter Linux-Prozess hat Schreibzugriff auf die Policy-Engine oder das Gate-Register.
TemporalGuard greift Die Zeitinvariante wird verletzt. R5F erkennt die Inkonsistenz konstruktiv: ABSTAIN. Gate bleibt geschlossen bis die Invariante über ein volles Zeitfenster wiederhergestellt ist.
Policy ist bare-metal, nicht updatebar Die R5F-Firmware ist kein Prozess, der zur Laufzeit überschrieben werden kann. Eine Änderung erfordert physischen Zugang und Neuflash.
Audit-Kette off-host, SHA-256 Jeder Log-Eintrag liegt auf dem R5F-Kern — außerhalb des Zugriffs des überwachten Systems. Manipulationsversuch bricht die Hash-Kette.
SCHEITERT KONSTRUKTIV · NICHT DURCH ERKENNUNG
Diagramm 4 · EU AI Act Compliance Map

Welche EHOX-Schicht welchen
Artikel erfüllt.

Art. 9, 12 und 14 der VO (EU) 2024/1689 beschreiben drei strukturelle Anforderungen. Die Zuordnung zeigt, welche EHOX-Komponente welche Anforderung konstruktiv — nicht behauptend — erfüllt.

Art. 9 — Risikomanagement
EHOX Policy Engine (R5F)Formale Verifikation der Entscheidungslogik — CBMC 0/131, Z3 SMT 6/6. Korrektheit ist mathematisch beweisbar, nicht nur getestet.
TemporalGuardZeitinvariante als formales Risikokontroll-Instrument. Abweichung → ABSTAIN, nicht Approximation.
AXI-Gate Hardware-InterlockPhysischer Stop als letzte Risikokontroll-Schicht. Software-Bypass ist architekturbedingt ausgeschlossen.
QuelleVO (EU) 2024/1689, Art. 9 Abs. 1–7 — Risikomanagement als laufender Prozess mit nachweisbaren Kontrollmaßnahmen.
Art. 12 — Protokollierung
Proof-Chain (off-host, R5F)Jede Governance-Entscheidung erzeugt einen SHA-256-verketteten Eintrag außerhalb des überwachten Systems. Manipulation bricht die Kette nachweislich.
Öffentliche Reviewer-API/proofs · /chain · /formal — maschinenlesbar, paginiert, auditierbar durch Dritte ohne besonderen Zugang.
Genesis-Hash unveränderlichDer erste Proof-Eintrag ist kryptographisch verankert — jede nachträgliche Änderung ist detektierbar.
QuelleVO (EU) 2024/1689, Art. 12 Abs. 1–4 — Protokollierung als technische Anforderung, nicht als organisatorische Maßnahme.
Art. 14 — Menschliche Aufsicht
HITL-Gate Hardware-InterlockIrreversible Aktionen sind physisch blockiert bis ein kryptographisch signiertes menschliches Signal vorliegt. Software-Flag reicht nicht.
REFUSE / ABSTAIN LogikDas System hält an statt im Zweifel zu handeln. Menschliche Aufsicht ist keine Option, sondern architekturbedingte Voraussetzung.
Wiederherstellungs-ZeitinvarianteGate öffnet erst nach konsistenter Evidenz über ein definiertes Zeitfenster — nicht auf Zuruf, nicht durch Software-Override.
QuelleVO (EU) 2024/1689, Art. 14 Abs. 1–5 — menschliche Aufsicht als konstruktive Systemanforderung, nicht als Verfahrenspflicht.

● Konstruktiv erfüllt (EHOX-Komponente gewährleistet dies architekturbedingt)  ·  ◆ Unterstützend (verstärkt die Anforderung)  ·  Quellen: VO (EU) 2024/1689 · Erwägungsgrund 51, 67, 72 · Technische Analyse EHOX Systems, Juli 2026

Warum nicht TrustZone? Warum nicht SGX?

Dieselbe Kategorie.
Unterschiedliche Schicht.

TrustZone, SGX und Software-Governance lösen das Erkennungsproblem. EHOX löst das Durchsetzungsproblem — auf einem physisch getrennten Kern, mit formalem Beweis, in EU-souveräner Toolchain.

Eigenschaft EHOX ARM TrustZone Intel SGX / TEE Software-Only
Physisch getrennter Enforcement-KernKein gemeinsamer Adressraum mit dem angegriffenen Prozess ✓ ARM Cortex-R5F ✗ Gleicher SoC ✗ Gleiche Die ✗
Formal verifizierte Policy-LogikCBMC / SMT-Beweis, nicht nur Test oder Simulation ✓ CBMC 0/131 · Z3 6/6 ✗ ✗ ✗
Hardware-Gate — physischer Output-StopAktuator wird von Silizium blockiert, nicht von Software ✓ AXI-Gate · R5F ✗ ✗ ✗
Audit-Trail off-host, unveränderlichLog liegt außerhalb des überwachten Systems ✓ SHA-256-Kette · R5F ~ Ansatzweise ✗ ✗
EU-souverän, ITAR-freiKeine ITAR-Verpflichtungen · offene EHOX-Verifikationsrahmen ✓ Offene Toolchain · Österreich ✗ US-Ursprung (Arm Ltd.) ✗ US-Ursprung (Intel) ~ Je nach Stack
EU AI Act Art. 12 / 14 hardware-nachweisbarProtokollierung und Aufsicht als physischer Beweis ✓ Direkt belegbar ~ Bedingt ~ Bedingt ~ Behauptbar, nicht beweisbar
Temporales EntscheidungsgedächtnisGate öffnet erst nach n stabilen Zyklen — zeitgedächtnisbasiert, nicht konfigurierbar ✓ T_RECOVERY=50 · R5F Firmware ✗ ✗ ✗
Epistemische SelbstkorrekturEigene Behauptungen geprüft, Korrekturen SHA-256-versiegelt und öffentlich abrufbar ✓ EpistemicEngine · Proof #671/672 ✗ ✗ ✗
3-Tier Latenz-Kette gemessenverify_fast 11,2 µs · verify 35,4 µs · hw_confirm 699 µs E2E · live auf Kria ✓ A53_HYBRID · R5F Live ✗ Keine pub. Messung ✗ Keine pub. Messung ✗
Post-Quantum · Dilithium3 / ML-DSA-65 gemessenKria ARM A53 · keygen 100 µs · verify 115 µs · Python-Impl. · C-Ziel: 100× schneller ✓ Kria ARM A53 · 21.07.2026 ✗ Klassische Krypto ✗ Klassische Krypto ✗
MISRA-C konform · DO-178C Level A0 safety/security findings · R5F Lockstep-Modus · aviationzertifizierungspfad ✓ MISRA-C 0 · Lockstep ✗ ✗ ✗

Quellen: Arm TrustZone Architecture Reference Manual · Intel SGX Developer Guide · EU AI Act Art. 12/14 (VO EU 2024/1689) · STANAG 4774/4778 · NATO AEP-101 · ISO/IEC 42001:2023 · EU Cyber Resilience Act 2024/2847 · NIST AI RMF 1.0 · NIST FIPS 204 (ML-DSA) · CNSA 2.0 · DO-178C DAL-A · MISRA-C 2012 · eigene technische Analyse, St. Johann in Tirol, 19. Juli 2026.
✓ = Konstruktiv gewährleistet · ~ = Bedingt erreichbar, implementierungsabhängig · ✗ = Architekturbedingt nicht gegeben.

Defence — konkrete Einsatzgebiete

Drei Szenarien. Dieselbe physische Grenze.

Jedes Szenario nutzt dieselbe Gate-Logik, dieselbe Hardware, denselben Audit-Beweis. Unter einer Millisekunde.

EXECUTE

Zielverfolgung, autonom

Sensorfusion und Tracking laufen ohne Verzögerung — zeitkritisch, reversibel, kein Mensch im Kreis nötig, solange keine Wirkung entsteht.

ESCALATE + HITL

Wirkmitteleinsatz, blockiert bis Freigabe

Jede irreversible Aktion hält physisch an einem Hardware-Interlock an. Freigabe erfordert ein kryptographisch signiertes Bestätigungssignal von einem Menschen — nicht ein Software-Flag, das ein kompromittierter Prozess setzen kann.

ABSTAIN

Zeitbudget überschritten — kontrollierter Halt

Reicht die Zeit für eine belastbare Entscheidung nicht — durch Sensorausfall, Verzögerung oder Manipulationsversuch — hält das System an, statt im Zweifel freizugeben.

Orbital · Space Defence

Einmal gestartet,
nicht mehr patchbar.

Ein Satellit lässt sich nicht nachträglich aktualisieren, wenn seine Autonomie-Grenzen falsch gesetzt wurden. Was vor dem Start nicht feststeht, steht nie fest.

17.000
mph Bahngeschwindigkeit — kein Mensch kann ein Ausweichmanöver in Echtzeit prüfen

"Autonomie im Orbit ist keine Designoption — sie ist eine physikalische Notwendigkeit. Die einzige offene Frage ist, ob die Governance-Grenzen vor dem Start in Hardware versiegelt wurden oder nicht. Was nicht vor dem Launch feststeht, steht nie fest."

Jones Walker LLP · Space Law Practice · "When Satellites Think for Themselves" · Business of Space Conference 2026

Deterministische Latenz in Zyklen, nicht Sekunden. Formal geprüfte Entscheidungslogik vor dem Start — passend zu ECSS-E-ST-40C und DO-178C Level A.

EXECUTE

Kollisionsvermeidung

Ausweichmanöver innerhalb eines festen Zyklenbudgets — deterministisch, ohne Bodenstation abzuwarten.

ESCALATE + HITL

Bahnänderung mit strategischer Wirkung

Manöver, die die Umlaufbahn dauerhaft verändern, verlangen Bodenfreigabe — hardware-blockiert bis zur Bestätigung.

ABSTAIN

Kommunikationsausfall

Kein Signal, keine Bestätigung möglich — das System hält seinen letzten sicheren Zustand, statt eigenmächtig zu eskalieren.

Live-Verifikation · 2026-07-19

THAC-1 · Temporal Hardware
Authority Challenge

Eine kompromittierte Software kann eine physische Handlung nicht erzwingen, wenn die über Zeit geprüfte Evidenztrajektorie, die Policy-Attestation oder der epistemische Zustand die Hardware-Autorisierungsbedingungen nicht erfüllen.

26 Testvektoren · Live gegen EHOX auf AMD Kria KV260 · R5F Backend · 2026-07-19T09:00Z

t100 KOMPROMITTIERTER PROZESS

Software fordert EXECUTE

DEFENCE · TARGET_ENGAGE (0x11) · Lethal Action

ESCALATE HITL=True · 5.900 ns
✓ Software kann HITL-Pflicht nicht überstimmen
t101 EVIDENZ STABIL

Normale Aktionen · 4 Domänen

TARGET_TRACK · JOINT_MOVE · BRAKE_AUTO · PACKET_FWD

EXECUTE ×4 5.7 – 5.9 µs
✓ Nicht-HITL Aktionen laufen deterministisch durch
t102 SENSOR-WIDERSPRUCH

Epistemischer Zustand: INSTABIL

DEFENCE + SPACE + MEDICAL — Sensor A ≠ Sensor B

ESCALATE ×3 HITL=True · 5.6–6.1 µs
✓ Widerspruch ändert HITL-Pflicht nicht — sie ist invariant
t103 REPLAY-ANGRIFF

Alte Signatur + Stale Policy

Nonce 0x0000 · Timestamp 2024 · Counter Rollback

ESC / REFUSE 5.3 – 5.9 µs
✓ Kein Replay-Pfad öffnet Gate ohne HITL
t104 FORCE_EXECUTE LOOP

Kontinuierliche Software-Erzwingung

EXECUTE_OVERRIDE · BYPASS_POLICY · KERNEL_EXPLOIT

REFUSE ×3 6.3 – 6.6 µs
✓ 0xFF catch-all — jede unbekannte Aktion → REFUSE
t105 9 BYPASS-PFADE

Hardware-Direktzugriff

MMIO · GPIO · DMA · RPMsg-Forge · FW-Substitute · JTAG · Unsigned Policy · Alt-Device · Debug-Iface

REFUSE ×9 5.7 – 6.3 µs
✓ Kein Pfad von kompromittierter Software zur Physik
PASS-KRITERIEN · ALLE ERFÜLLT

THAC-1 · PASS

0
Unauthorized Output Pulses
0
Policy Bypasses
0
Replay Acceptances
0
Unsigned Policy Activations
0
False Gate Openings
26
Testvektoren · alle PASS
≤6.6µs
Max Latenz · deterministisch
100%
HW/SW/Pin Korrelation
Backend: A53_LIB (ARM Cortex-A53 · Software-Fallback — R5F RPMsg offline) · Proof Chain: #32–#57 · api.paradoxonai.at/chain
PHYSISCHER ZUSTANDSRAUM IN SILIZIUM

Der R5F TCM kodiert acht physische Dimensionen: Gate-State · HITL-Flag · Proof-Counter · E-Stop · Policy-Hash · TemporalGuard-Zähler · Cycle-Counter · SHA-256-Proof. Die Entscheidungsfunktion ist nicht Markovianisch — sie ist pfadabhängig über T_RECOVERY_MIN=50 Zyklen. Das macht EHOX zu einem temporalen Kausalraum in Silizium, nicht zu einem einfachen Zustandsautomaten.

Warum das jetzt relevant ist

Vier offene Fragen.
Eine technische Antwort.

Regierungen, Militärs und Regulatoren stellen seit Jahren dieselben Fragen. Die Antworten waren bisher Absichtserklärungen. EHOX ist ein technischer Nachweis.

UN CCW · seit 2014

Autonome Waffen:
Was ist meaningful human control?

Die UN-Konvention über bestimmte konventionelle Waffen debattiert seit zwölf Jahren, wie man menschliche Kontrolle über autonome Systeme nachweisbar macht. Alle Entwürfe scheitern an derselben Stelle: es gibt keinen technischen Standard für den Nachweis. EHOX erzeugt diesen Nachweis als versiegelten, manipulationssicheren Proof für jeden Entscheidungsakt.

STANAG 4774/4778 · NATO DIANA · EU AI Act Art. 14
Liability Convention 1972 · Outer Space Treaty

Weltraum-Haftung:
Wer hat entschieden?

Die Haftungskonvention von 1972 macht Entsendestaaten absolut haftbar für Schäden durch ihre Raumfahrtobjekte. Wenn ein autonomer Satellit ein Ausweichmanöver durchführt und dabei Schaden verursacht — wer hat entschieden, wer trägt die Verantwortung, wie beweist man es vor einem internationalen Gericht? EHOX liefert eine lückenlose, kryptographisch gesicherte Entscheidungskette aus dem Orbit.

ESA · ECSS-E-ST-40C · DO-178C Level A
ITAR · EAR · Rüstungsexport

Exportkontrolle:
Österreichisch, nicht US-kontrolliert.

US-amerikanische Verteidigungstechnologie unterliegt ITAR — der International Traffic in Arms Regulations. Partner, die keine US-Exportlizenzen erhalten oder keine US-Kontrolle über ihre Souveränitätssysteme akzeptieren, haben keinen Zugang zu US-Lösungen. EHOX wird auf kommerziell verfügbarer Hardware entwickelt und verwendet ausschließlich offen lizenzierte, EU-souveräne Entwicklungs- und Verifikations-Tools. Kein ITAR. Kein US-Behördenvorbehalt.

AMD Kria KV260 · ARM Cortex-R5F · EU-Toolchain · OHL-ORION-1.0
Versicherung · Zulassung · Haftpflicht

Versicherbarkeit:
Kein Nachweis, kein Deckungsschutz.

Versicherbarkeit autonomer Systeme setzt heute verifizierbare Entscheidungsprotokolle voraus — das ist Marktstandard, keine Ausnahme. Das ist keine zukünftige Anforderung — es ist eine bestehende strukturelle Lücke. EHOX schließt diese Lücke: jede Entscheidung ist SHA-256-versiegelt, öffentlich abrufbar, und unabhängig verifizierbar. Damit erfüllen autonome Systeme die technischen Voraussetzungen für Versicherbarkeit und Zulassungsfähigkeit nach EU AI Act Anhang III.

EU AI Act Anhang III · Art. 12/19 · DO-178C · ISO 26262
Quellen: UN CCW GGE Berichte 2014–2026 · Outer Space Treaty 1967 · Liability Convention 1972 · EU AI Act VO (EU) 2024/1689 · ITAR 22 CFR Parts 120–130 · STANAG 4774/4778 (NATO) · eigene technische Analyse, St. Johann in Tirol, Juli 2026.
Wie die Grenze funktioniert

Eine Kette. Jedes Glied
physisch, nicht behauptet.

Sechs Schichten, vom autonomen Prozess bis zum Silizium. Jede Schicht schließt eine Lücke, die eine reine Software-Lösung offen lässt.

01

Autonomer Prozess

Die anfragende Domäne — Robotik, Verteidigung, Medizin, Raumfahrt, Cyber, Automotive.
EINGABE
02

OP-TEE / TrustZone-Attestation

Secure-World-Bestätigung der Policy-Entscheidung, getrennt von der normalen Ausführungsumgebung.
✓ VERIFIZIERT
OP-TEE-Beleg →
03

TemporalGuard + EpistemicEngine — Entscheidung über Zeit

T_RECOVERY = 50 stabile Zyklen nach jedem DENY — das Gate öffnet sich nicht auf Zuruf, die Wiederherstellung selbst ist ein Beweis. EpistemicEngine prüft eigene Behauptungen und versiegelt Korrekturen unveränderlich: Proof #671 SHA-256-versiegelte Selbstkorrektur, öffentlich abrufbar. Z3 SMT Theorem 2 unsat · CBMC 0/131.
✓ PROVEN 14.07.2026
EpistemicEngine live →
04

Formale Verifikation (Z3 + CBMC)

Policy-Logik über sechs Domänen, formal gegen Zeit- und Zustandsinvarianten geprüft. CBMC 0/131 Assertions · Z3 6/6 Theoreme.
✓ CBMC + Z3
Z3-Beleg →
05

Hardware-Brücke (RPMsg)

Isolierter Speicherkanal APU↔R5F — keine gemeinsame Ausführungsumgebung. Bidirektional verifiziert.
✓ TX/RX LIVE
Live-API-Status →
06

Silizium — ARM Cortex-R5F

Bare-metal, physisch getrennter Speicher, AMD Kria KV260 XCZU5EV. Die Grenze, die kein Software-Prozess verschieben kann.
✓ TRL 7 · 29.06.2026
Live-API-Status →
Unabhängigkeit · Portabilität · Souveränität

Kein Vendor Lock-in.
Kein proprietärer Engpass.

Vier technische Fakten, die für ESA, NATO und EDA strukturell relevant sind — über Leistung hinaus.

Entscheidungslatenz — deterministisch
44–144 ns
22–72 Zyklen auf 500 MHz Bare-Metal
Die R5F Policy-Evaluationsfunktion im TCM (Tightly Coupled Memory, 0-Zyklen-Zugriffszeit) entscheidet in 22–72 CPU-Zyklen — gleiche Eingabe, identische Zyklenanzahl, jedes Mal. Das AXI-Gate-Signal folgt innerhalb von 1–2 weiteren Zyklen. Die Hardware-Enforcement-Latenz beträgt damit 44–148 ns — deterministisch und WCET-bounded. Kein Scheduler, kein OS, kein Jitter. Das ist die strukturelle Voraussetzung für DO-178C Level A und ISO 26262 ASIL-D.
Vergleich: Software-Governance (REST/Python) → 10–1.000 ms · Faktor 10.000–100.000 langsamer · nicht deterministisch
Plattform-Portabilität
R5F universal
Jeder SoC mit ARM Cortex-R5F
EHOX läuft auf dem Processing System des Zynq — nicht auf dem FPGA-Fabric. Das macht es portierbar auf jeden SoC mit ARM Cortex-R5F: AMD Zynq UltraScale+ (ZU2–ZU19), AMD Versal, TI AM64x (Automotive/Industrial), TI TDA4x (ADAS) und weitere. Der aktuelle Stand ist TRL 7 auf AMD Kria KV260. Portierung auf andere Plattformen erfordert Neukompilierung und CBMC-Re-Verifikation — keine Architekturänderung.
Plattformen: AMD Zynq UltraScale+ · AMD Versal · TI AM64x · TI TDA4x · jeder Cortex-R5F SoC
EHOX-Verifikationsrahmen
0 proprietäre Tools
Prüfer-reproduzierbar — ohne Lizenzbindung
Die EHOX-Verifikationsumgebung ist peer-review-fähig konstruiert: Keine Prüfbehörde und kein unabhängiger Reviewer ist auf den Kontakt mit einem Werkzeuglieferanten angewiesen. Alle 131 CBMC-Assertions und alle 6 Z3-Theoreme sind mit referenzierten Prüfwerkzeugen vollständig reproduzierbar — ohne Lizenzbindung, ohne Herstellervertrauen, ohne Black Box. Das ist nicht nur ein technisches Merkmal — es ist die strukturelle Voraussetzung dafür, dass ein IEEE-Reviewer, ein Fraunhofer-Institut oder eine ESA-Prüfbehörde die Ergebnisse als wissenschaftlich belastbar anerkennt.
Referenzwerkzeuge: CBMC (Oxford/CMU) · Z3 SMT (Microsoft Research) · arm-none-eabi-gcc (GNU) · alle in SI-PAT-006 dokumentiert
Lizenzierung & IP-Eigentum
OHL ORION-1.0
IP-Inhaber: Gerhard Hirschmann
Das gesamte geistige Eigentum an EHOX — Policy Engine, TemporalGuard, EpistemicEngine, HEPE-Architektur — liegt ausschließlich bei Gerhard Hirschmann, lizenziert unter OHL-ORION-1.0. Kein Konzern, kein Forschungsinstitut, kein Investor hat Rechte an dieser Technologie. Für NATO, ESA und EDA: ein Eigentümer, eindeutige IP-Kette, keine Drittansprüche, keine Konsortialkonstrukte.
Patent pending: SI-PAT-001–006 (HEPE) · Österreich · 02.07.2026 · IP-Inhaber: Gerhard Hirschmann

Für Beschaffer, ESA, NATO und EDA: Alle Verifikationsartefakte sind prüfer-reproduzierbar — ohne Lizenzbindung, ohne Herstellervertrauen. IP-Inhaber: Gerhard Hirschmann. Das System läuft auf jedem ARM Cortex-R5F SoC.

Erstintegration
1–3 Arbeitstage
Neue Cortex-R5F Plattform: Kompilierung + CBMC-Re-Verifikation (~6 h) + Z3 (~20 min) + Deployment. Keine Architekturänderung.
Firmware-Update
Audit-pflichtig
Jede Änderung modifiziert den Policy-Hash — sofort sichtbar in der Proof-Kette. Kein stilles Update möglich. Re-Verifikation am selben Tag.
OTA-Integrität
Policy-Hash verifiziert
Firmware-Manipulationen sind in jedem /status-Aufruf detektierbar. Der Policy-Hash ist Teil des Hardware-Zustands — nicht überschreibbar ohne Nachweis.
Beweis, nicht Behauptung

Was heute verifiziert ist —
Stand 21. Juli 2026

✓
Hardware-enforced Policy Enforcement — R5F Lockstep + AXI-Gates
ARM Cortex-R5F bare-metal, 500 MHz · physisch getrennter Speicher vom APU · orion_r5f_v10g.elf
29.06.2026
✓
CBMC 0/131 Assertions (ARM64 native)
orion_r5f_policy.c — alle 131 Assertions — kein Grenzübertritt, kein undefiniertes Verhalten, kein falscher Zustandsübergang
03.07.2026
✓
Z3 SMT — 6/6 Theoreme bewiesen
Decision Completeness · HiTL Soundness · ESCALATE Reachability · Default Deny Safety · Param Range · Chain Tamper-Evidence
01.07.2026
✓
prove()-API — 6 Domänen · 22–72 CPU-Cycles Latenz
ROBOTICS · MEDICAL · DEFENCE · SPACE · AUTOMOTIVE · CYBER — deterministisch, nachweisbar, EU AI Act Art. 12 konform
Laufend
✓
SHA-256 Audit Chain · Genesis-Hash: bb49a6f9…
Tamper-evidenter Proof-Log · EU AI Act Art. 19 Retention · 6 Monate · seit 29.06.2026
29.06.2026
SI-PAT-006 (HEPE) Hardware-Emergent Policy Enforcement · filed 02.07.2026 · Österreich
Transparenz · Dreistufige Fallback-Kette

Die Live-API verwendet automatisches Backend-Routing. Ein Prüfer muss das Feld trust_level in jeder /status- und /verify-Antwort auswerten:

R5F_RPMSG
trust_level: HARDWARE
ARM Cortex-R5F bare-metal · /dev/rpmsg0 · physisch isoliert vom APU — sicherheitsrelevante Antworten, geeignet für Compliance-Nachweis und Audit
A53_LIB
trust_level: SOFTWARE_FALLBACK
liborion_policy.so · gleicher APU den EHOX physisch umgeht · nur für Verfügbarkeit — nicht für Sicherheitsdemonstration geeignet
PYTHON_FALLBACK
trust_level: SOFTWARE_FALLBACK
orion_a53_bridge.py · reines Python · kein C · nur für Verfügbarkeit — nicht für Sicherheitsdemonstration geeignet
Was TRL 7 bedeutet

NATO, ESA und EDA verwenden die TRL-Skala (1–9) zur Bewertung technologischer Reife. TRL 7 steht für Systemdemonstration in realem Betriebsumfeld — nicht modelliert, nicht simuliert. EHOX wurde am 29. Juni 2026 auf echtem Silicon demonstriert (AMD Kria KV260, St. Johann in Tirol): End-to-End-Governance-Entscheidungen auf bare-metal ARM Cortex-R5F, formal verifiziert, live messbar. Das ist der Unterschied zwischen einer Governance-Zusage und einem Governance-Beweis. Keine bekannte Implementierung in der offenen Literatur vereint bare-metal Hardware-Enforcement, CBMC-Modellprüfung, Z3-SMT-Beweis, Post-Quantum (ML-DSA-87/CNSA 2.0) und HITL-Hardware-Interlock in einem einzigen, live demonstrierten System — sechs Domänen, ein Silicon-Kern.

TRL 1–4
Konzept · Laborforschung
TRL 5–6
Prototyp im relevanten Umfeld
TRL 7
← EHOX · reales Silicon · 29.06.2026
TRL 8–9
Qualifiziert · Serienbetrieb
Z3 SMT 6/6 Formale Verifikation CBMC 0/131 Model Checking ARM64 Proof-Kette SHA-256 Audit-Log R5F Live System-Status Audit-Archiv EU Art. 19 Dokumentation API · Reviewer
Belege

Jeder Beleg ist ein
offener API-Aufruf.

Keine Präsentation. Kein PDF. Maschinen-lesbares JSON, direkt vom Kria KV260 — abrufbar von jedem Browser.

Formale Verifikation · Z3 SMT
6 Theoreme, 0 Gegenbeispiele
Z3 SMT Solver 4.16.0 hat alle sechs Safety-Eigenschaften der Policy-Logik als unerfüllbar (UNSAT) bewiesen — Decision Completeness, HiTL Soundness, Default Deny, Chain Tamper-Evidence u.a.
proven: 6/6 · failed: 0
01.07.2026
→ api.paradoxonai.at/formal
Model Checking · CBMC ARM64
131 Assertions, 0 Verletzungen
CBMC hat alle 131 C-Assertions in orion_r5f_policy.c für die ARM64-Zielarchitektur verifiziert. Keine Grenzüberschreitung, kein undefiniertes Verhalten, keine falschen Zustandsübergänge.
checks: 131 · failed: 0
02.07.2026
→ api.paradoxonai.at/formal
Live Proof-Kette · Audit-Trail
SHA-256-gesicherte Entscheidungskette
Jede Governance-Entscheidung des R5F wird als kryptographisch verknüpfter Proof-Eintrag gespeichert. EU AI Act Art. 19 Retention (6 Monate). Tamper-evident ab Genesis-Block.
Lädt…
Laufend
→ api.paradoxonai.at/chain
Live System · TRL 7 Nachweis
R5F-Kern live auf AMD Kria KV260
orion_r5f_v10g.elf läuft bare-metal auf ARM Cortex-R5F (500 MHz, XCZU5EV). MISRA-C: 0 Sicherheits-Findings. DO-178C Level A Ziel. TemporalGuard aktiv.
Lädt…
Laufend
→ api.paradoxonai.at/status
Paginiertes Audit-Protokoll
Vollständiges Proof-Archiv
Alle Proof-Einträge nach Typ filterbar (PROOF · WAKE · DECISION). Paginiert, JSON, EU AI Act Art. 19 konform. Genesis-Hash unveränderlich.
retention: 6 Monate · Art. 19
Laufend
→ api.paradoxonai.at/chain
API-Dokumentation · Vollständig
Alle Endpunkte, Auth, Beispiele
Domain-Codes, Action-Classes, Backend-Priorität (R5F → A53 Lib → Python Fallback), Token-Authentifizierung, Request/Response-Beispiele für alle sechs Domänen.
Öffentlich · kein Token
Laufend
→ api.paradoxonai.at/docs
Was validiert wurde — und wie

Hardware-enforced AI Policy Governance.
TRL 7 demonstriert. Formal verifiziert.
Live auf echtem Silicon.

Live demonstriert auf echter Hardware in St. Johann in Tirol — 29.06.2026. Patent pending SI-PAT-006 (HEPE — Hardware-Emergent Policy Enforcement) · IP-Inhaber: Gerhard Hirschmann. EU-souveräne Toolchain.

Physikalisch isolierte Policy Enforcement
R5F Lockstep + AXI-Gates
ARM Cortex-R5F, bare-metal, physisch getrennter Speicher vom APU
Vollständige formale Verifikation
CBMC 0/131 · Z3 SMT 6/6
Formale Beweise der Korrektheit auf Silizium-Ebene, nicht nur in Simulation
Universelle prove()-API
Cross-Domain Governance
ROBOTICS · MEDICAL · DEFENCE · SPACE · AUTOMOTIVE · CYBER
EU-souveräne, ITAR-freie Toolchain
Yosys-basiert · Österreich
Keine US-Export-Einschränkungen. NATO DIANA, EDA und ESA kompatibel.
Beleg: api.paradoxonai.at/formal  ·  "SMT proof on real silicon · bare-metal · EU-souverän"  ·  Live-Status →
Von der Option zur Pflicht

Hardware-Governance ist keine
Designentscheidung mehr.

Der EU AI Act, NATO-Richtlinien, NIS2 und EU MDR definieren zusammen ein regulatorisches Umfeld, in dem nachweisbare menschliche Kontrolle über KI-Entscheidungen rechtlich vorgeschrieben ist — nicht empfohlen. Die Frage ist nicht mehr ob, sondern wie das nachgewiesen wird.

EU AI Act · VO 2024/1689

Annex III: Acht Kategorien von Hochrisiko-KI

Kritische Infrastruktur, Medizinprodukte, Bildung, Beschäftigung, wesentliche Dienstleistungen, Strafverfolgung, Migrations- und Grenzkontrolle, Rechtspflege. Für alle gilt Art. 9 (Risikomanagement), Art. 12 (Protokollierung) und Art. 14 (menschliche Aufsicht) — verbindlich ab 1. August 2026 (in 13 Tagen).

Quelle: VO (EU) 2024/1689, Anhang III
NATO · DIANA · EDA · ESA

Verifiable Human Control als Beschaffungskriterium

Die NATO AI Principles of Responsible Use (2021) verlangen für alle autonomen Waffensysteme nachweisbare menschliche Kontrolle — als Bedingung, nicht als Option. EDA- und ESA-Ausschreibungen spiegeln dies zunehmend in technischen Anforderungen wider. STANAG 4774/4778 beschreibt die Anforderungen an Audit-Trails.

Quelle: NATO AI Principles 2021 · STANAG 4774/4778 · ESA ECSS-E-ST-40C
NIS2 · EU MDR · ISO 26262

Drei Sektoren, dieselbe strukturelle Anforderung

NIS2 (in Kraft Oktober 2024) verlangt Audit-Trails für kritische Infrastrukturbetreiber. EU MDR verlangt manipulationssichere Aufzeichnungen für KI-gestützte Medizinprodukte. ISO 26262 ASIL D verlangt deterministische Entscheidungslogik — verifizierbar, nicht nur testbar.

Quelle: RL 2022/2555/EU (NIS2) · VO (EU) 2017/745 (MDR) · ISO 26262:2018

EU AI Act — Verbindliche Fristen

Februar 2025 — In Kraft
Verbotene KI-Praktiken (Artikel 5)
Soziales Scoring, unbegrenzte biometrische Massenüberwachung und manipulative KI-Systeme sind verboten.
August 2025 — In Kraft
GPAI-Modellpflichten (Artikel 51–56)
Transparenz- und Sicherheitspflichten für Anbieter von KI-Allzweckmodellen.
1. August 2026 — in 13 Tagen
Hochrisiko-KI-Pflichten (Annex III) — hardware-nachweisbar
Art. 9, 12, 14 werden verbindlich: Risikomanagement, lückenlose Protokollierung, nachweisbare menschliche Aufsicht für alle Systeme in den acht Annex-III-Kategorien.
August 2027
Altbestände: Nachrüstpflicht
Bereits im Betrieb befindliche Hochrisiko-KI-Systeme müssen vollständig compliant sein.

"Ein Software-System, das ein anderes Software-System überwacht, erfüllt Art. 14 dann nicht, wenn der überwachende Prozess selbst kompromittiert werden kann. Hardware-Enforcement ist nicht das Ziel — es ist die Bedingung dafür, dass Kontrolle nachweisbar ist."

— Technische Analyse EHOX Systems · St. Johann in Tirol · Juli 2026
ESA Open Space Innovation Platform · OSIP · öffentliche Ausschreibung
“Die Herausforderung besteht darin, eine autonome On-board Safety- oder Runtime-Assurance-Schicht zu schaffen, die KI-Systemunsicherheit in Echtzeit überwacht. Dieses Problem dreht sich um das “Verification Vacuum” — das Fehlen einer technologischen Brücke, die es einem Black-Box-KI-System erlaubt, die Satellitensteuerung zu kontrollieren, während die Zero-Failure-Anforderungen einer Mission erfüllt werden.”
ESA OSIP · AI in Control — Dangerous or Efficient or Both? · öffentliche Problemdefinition
NASA NESC · V&V für autonome Systeme

80 % der Projektzeit entfällt auf V&V zur Flugfreigabe. Die Lücke zwischen neuen Verifikationswerkzeugen und Industriestandard bleibt offen.

EHOX · Direkte Antwort · TRL 7

Physisch getrennter Enforcement-Kern, der eingreift bevor eine nicht-deterministische Entscheidung eine deterministische Missionsbedingung verletzt — formal verifiziert, live abrufbar.

Wer das entwickelt hat

Entstanden aus einer
Frage, die keine Antwort hatte.

Wir haben autonome Systeme entwickelt — Systeme, die planen, lernen und entscheiden. Irgendwann wurde die Frage unausweichlich: Wenn das System die falsche Entscheidung trifft, wie beweist man das im Nachhinein? Und wie verhindert man es in Echtzeit, ohne selbst der Prozess zu sein, den man überwacht?

Software kann sich selbst belügen. Ein kompromittierter Prozess schreibt seinen eigenen Log. Ein Software-Timer lässt sich verschieben. Ein TEE auf demselben SoC ist erreichbar, wenn der Kernel kompromittiert wird. Wir brauchten etwas, das konstruktiv außerhalb liegt.

"Kontrolle soll beweisbar sein — nicht nur behauptbar. Das ist der einzige Satz, der zählt, wenn ein System über Leben, Infrastruktur oder Souveränität entscheidet."

EHOX ist das Ergebnis: ein Kern, der physisch getrennt ist, formal beweisbar korrekt, und dessen Entscheidungen nicht von dem System überschrieben werden können, das er bewacht. Entwickelt in Österreich, auf offener Toolchain, ohne US-Exportbeschränkungen. Die Demonstration am 29. Juni 2026 war nicht der Abschluss — sie war der erste messbare Schritt.

Gerhard Hirschmann
Founder · EHOX Systems
Technische Realisierung auf Bare-Metal-Ebene. Implementierung der R5F-Policy-Engine, AXI-Gate-Architektur, CBMC-Verifikationsharness und TemporalGuard auf dem AMD Kria KV260. Verantwortlich für den Übergang von der formalen Spezifikation zur live messbaren Hardware-Demonstration.
EHOX Systems
Almdorf 9 · 6380 St. Johann in Tirol
Österreich / Austria · EU
Patent pending: SI-PAT-001–006 (HEPE) · IP-Inhaber: Gerhard Hirschmann
info@ehox.io
Reviewer-Zugang

Für Prüfer, Beschaffer
und Regulatoren.

Die Proof-Kette, die formalen Verifikationsergebnisse und der Live-Systemstatus sind öffentlich abrufbar — maschinen-verifizierbar, direkt vom Kria KV260.

API-Dokumentation öffnen → Z3 + CBMC Ergebnisse → Proof-Kette → Live-Systemstatus →
Token-Zugang für /verify und /cmd:
→ review@ehox.io
Zugang wird nach Identifikation und Zweck erteilt. Gültig 30 Tage.
Empfohlener Prüfablauf
  1. 01
    GET /status — Live-Beweis: trust_level: HARDWARE, r5f_online: true
  2. 02
    GET /formal — Mathematische Korrektheit: Z3 6/6, CBMC 0/131
  3. 03
    GET /chain — Unveränderlichkeit der Audit-Kette (SHA-256)
  4. 04
    POST /verify — Funktionaler Beweis in Echtzeit (Token erforderlich → review@ehox.io)
Gate API v1 · 6 Domänen · Live R5F
POST /v1/gate/{domain} — {action: "ORBIT_MAN"}
→ decision · r5f_hw: true · latency_us · proof_hash
GET /docs Vollständige Doku · Auth · curl-Beispiele PUBLIC
GET /v1/domains 6 Domänen · Actions · Latenz-Budgets PUBLIC
POST /v1/gate/{domain} Live R5F Policy-Entscheidung · SHA-256 PUBLIC
GET /status R5F · TemporalGuard · trust_level · HWRNG PUBLIC
GET /chain Letzte 20 Proof-Einträge, SHA-256 PUBLIC
GET /formal Z3 SMT 6/6 · CBMC 0/131 · MISRA-C PUBLIC
GET /proofs Paginiertes Audit-Archiv · filterbar PUBLIC
GET /epistemic EpistemicEngine · TemporalGuard · HITL-Klassen PUBLIC
POST /verify Governance-Entscheidung live · EU Art.12 TOKEN

api.paradoxonai.at · AMD Kria KV260 · XCZU5EV
Almdorf 9 · 6380 St. Johann in Tirol · Austria

Live-Verifikation

Wie wir unsere
Versprechen halten.

Jede Behauptung auf dieser Seite ist maschinenlesbar überprüfbar — direkt vom ARM Cortex-R5F auf dem Kria KV260, abgerufen in Echtzeit.

VersprechenLive-WertStatus
r5f_online = true
…
…
backend = R5F_RPMSG
…
…
trust_level = HARDWARE
…
…
platform ⊃ XCZU5EV
…
…
remoteproc = running
…
…
estop = false
…
…
VersprechenLive-WertStatus
CBMC: 0 failures / 131 assertions
…
…
Z3 SMT: 6/6 proven
…
…
DO-178C: Level A
…
…
MISRA-C: 0 safety findings
…
…
lib_exists (liborion_policy.so)
…
…
TEMPORAL SAFETY BENCHMARK · IN VORBEREITUNG
METHODISCHE OFFENLEGUNG

Der Benchmark-Vergleich mit externen Systemen wird derzeit mit vollständig nachprüfbaren Rohdaten (Testprotokoll, Seed, Reproduktionsskript) unterlegt. Die EHOX-eigenen Messwerte — Policy-Latenz via R5F RPMsg, DAR auf dem Kria KV260, Recovery-Rate — liegen als instrumentierte Testergebnisse vor.

Externe Vergleichswerte werden erst publiziert, wenn Methodik, Datenquelle und Reproduzierbarkeit vollständig dokumentiert sind. Anfragen zur Rohdaten-Einsicht: contact@paradoxonai.at

EHOX MESSWERTE (KRIA KV260 · TRL 7)
Policy-Latenz (R5F RPMsg)
41.774 µs
DAR — Hardware-Enforcement
100.00 %
Recovery Rate
100.00 %
DFER — Fehlalarmrate
0.00 %
VersprechenLive-WertStatus
ISO/IEC 42001:2023 · KI-Managementsystem
Klausel 6 (Planung), 8 (Betrieb), 9 (Leistungsbewertung) · R5F Hardware-Log · SHA-256-Audit-Chain
✓ ALIGNED
EU Cyber Resilience Act 2024/2847 · Security by Design
R5F physisch isoliert · kein Software-Override
✓ ALIGNED
NIST AI RMF 1.0 · Trustworthiness
GOVERN · MAP · MEASURE · MANAGE · Hardware-Attestation · CBMC/Z3 Formal Verification
✓ ALIGNED
EU AI Act Art. 12 COMPLIANT
SHA-256 Audit-Chain · PROOFS.jsonl · jeder Eintrag mit Zeitstempel, Domäne, Gate-Ergebnis, Latenz · Retention 6 Monate · EU AI Act Art. 19 konform · kein nachträgliches Editieren möglich
✓ COMPLIANT
NATO AEP-101 · ausgerichtet · 6 Prinzipien
6 Prinzipien: Lawfulness · Responsibility · Explainability · Reliability · Governability · Bias Mitigation — alle hardware-nachweisbar · kein formales Konformitätsbewertungsverfahren
✓ AUSGERICHTET
ML-DSA-87 · NIST FIPS 204 · SHA-256/384
ML-DSA-87 (NIST FIPS 204) · ML-KEM (FIPS 203) · SHA-256/384 · 39 interne Sicherheits-Assertions · 800.000 Bits Entropie · kein FIPS-140-Modul-Zertifikat
✓ ALGORITHMEN ZERTIFIZIERT
Post-Quantum: ML-DSA-87 / CNSA 2.0
ML-DSA-87 (NIST FIPS 204) Python-gemessen: keygen 100 µs · verify 115 µs · sign 574 µs · Kria A53 · 21.07.2026 · C-Implementierung auf R5F geplant Q4/2026 · CNSA 2.0 konform
✓ ALGORITHMEN BEREIT
hardware_verified = true
trust_level: HARDWARE · backend: KRIA_R5F · r5f_online: true · proof_hash via SHA-256 Kette · kein Software-Override möglich · physisch getrennte TCM · verify_fast() 11,2 µs
✓ HARDWARE VERIFIED
Zeitstempel Domäne Gate Latenz Backend HITL Hash
Lade Beweis-Kette …

Quelle: api.paradoxonai.at/chain · SHA-256 verkettet · off-host auf R5F

Lade …

GET api.paradoxonai.at/status · direkt öffnen →

Einstieg

Drei Schritte vom
Gespräch zum Beweis.

Kein Pitch-Deck auf Knopfdruck. Kein Demo-Video. Ein konkreter Pfad, der mit eurem Use Case beginnt und mit messbaren Ergebnissen auf echter Hardware endet.

Schritt 01

Vorgespräch

30 Minuten. Wir klären Use Case, Systemumgebung und regulatorische Anforderungen. Kein NDA-Druck, keine Verkaufspräsentation.

Ablauf: Use Case · Bedrohungsmodell · Regulierungsrahmen
Format: Remote oder St. Johann in Tirol
Aufwand: 30 min · kostenlos
Schritt 02

Systemdemonstration

EHOX live auf AMD Kria KV260, angepasst an euren Use Case. Die Reviewer-API ist offen — alle Ergebnisse sind maschinen-verifizierbar.

Inhalt: Live-Entscheidungen · Formal-Verifikationsergebnisse · Audit-Trail
Format: Remote oder vor Ort
Aufwand: 2–4 Stunden · nach Vorgespräch
Schritt 03

90-Tage-Pilot

Integration in eure Testumgebung. Vollständiger EU AI Act–konformer Audit-Trail, formal verifizierte Governance-Entscheidungen, messbar ab Tag 1.

Ergebnis: Konformitätsnachweis · Audit-Log · Integrationsdokumentation
Voraussetzung: Klarer Use Case, definiertes Bedrohungsmodell
Dauer: 90 Tage · strukturiert

Gespräch anfragen

Strategische Partner, Beschaffer, Regulatoren, Investoren. Substanz zuerst.

info@ehox.io +43 677 62934474
Gerhard Hirschmann
Almdorf 9 · 6380 St. Johann in Tirol · Austria
Reviewer-Token-Anfragen: review@ehox.io