Jede Zeile spiegelt eine Domäne wider, die Vergabestellen und CISOs prüfen. Links die Beschaffungsanforderung, rechts der konkrete AIonicOS-Mechanismus — prüfbar, nicht behauptet.
Kriterium
Anforderung
AIonicOS
Datenresidenz & Inferenz in der EU
Alle Daten und jede Modellinferenz müssen physisch in der EU/Deutschland liegen und ausgeführt werden — at rest, in transit und während der Inferenz (DSGVO Art. 44–49, BSI C5, Schrems II).
Single-Tenant-Architektur: der vollständige Stack wird pro Kunde auf einem dedizierten EU-Host betrieben, mit eigener isolierter Postgres/Apache-AGE, Qdrant, Valkey und SeaweedFS — kein geteilter Datenpfad. Die Residency-Gate (`residency.py`) erzwingt unter `data_residency=eu` eine strikte Provider-Allow-List samt vollständig-EU-Pfad (Mistral FR + selbstgehostetes Ollama); eine Per-Modell-Sperrliste fängt nicht abgedeckte Modelle ab.
Betriebsautonomie & Schutz vor Drittstaaten-Zugriff
Kein Anbieter-Betreiber, Hyperscaler oder Drittstaat darf ohne Ihre Autorisierung Zugriff erlangen oder Herausgabe erzwingen — das System darf kein stilles Operator-Override zulassen (CLOUD Act / FISA 702, BSI „Cyber Dominance“).
Fail-closed-Residency-Gate, durchgesetzt bei Preflight (HTTP 409 vor jeder Ausgabe) und zur Laufzeit (`DataResidencyViolation`) — ohne Operator-Bypass: `?preflight=skip` kann Residency-FATALs nicht umgehen, jeder Skip wird auditiert. Der dedizierte Host bietet keine anbieterseitige Control Plane zum Vorladen; der vollständig-EU-Modellpfad entfernt jeden CLOUD-Act-Nexus für die Inferenz. Modelle chinesischer Jurisdiktion sind unter `eu` hart blockiert.
Exit & Portabilität (EU Data Act Kap. VI)
Voller Daten- und Workflow-Export sowie ein vertraglich und technisch gestützter Exit-Pfad — kein Vendor Lock-in (EU Data Act, Wechsel- und Portabilitätsrechte).
Workflows sind deklarative, menschenlesbare YAML-DAG-Vorlagen — portierbare, prüfbare Artefakte im Besitz des Kunden, keine undurchsichtige Anbieter-Konfiguration. Daten liegen in offenen, exportierbaren Stores (PostgreSQL/Apache-AGE, Qdrant, Valkey, SeaweedFS); Artefakte sind über stabile `/api/v1/artifacts/<wf>/<label>`-JSON-Endpunkte adressierbar. Multi-Provider-Routing (LiteLLM) verhindert Modell-Lock-in; die gesamte Plattform ist das dedizierte Deployment des Kunden (git pull + docker compose).
Transparenz & Auditierbarkeit
Jede KI-Aktion, jeder Modellaufruf, jede Kosten- und Policy-Entscheidung muss als belastbare Nachweisspur protokolliert und abfragbar sein — geeignet für die Aufzeichnungspflichten des EU AI Act (Art. 12) und die DSGVO-Rechenschaftspflicht (Art. 5 Abs. 2).
SQL-abfragbares `notification_log` erfasst jedes Governance-Ereignis mit strukturierten Kategorien (Residency-Block, Laufzeit-Verstoß, Skip-Veto, MCP-Connector). Ein Kosten-Ledger schreibt jeden LLM-Aufruf nach `llm_cost_events` (Modell, Kosten in EUR, Latenz); Temporal liefert vollständiges Event-Replay; Prometheus-Counter exponieren die Durchsetzungsmetriken. Langfuse, Temporal-UI und Grafana sind vorverdrahtet.
Modell- & Lieferketten-Kontrolle
Der Käufer muss steuern, welche Modelle und Provider seine Daten verarbeiten — mit dokumentierter EU-Allow-List und Pfad zu einer vollständig-EU/selbstgehosteten Lieferkette ohne Drittstaaten-Abhängigkeit (BSI C3A, NIS2-Lieferantenrisiko).
Multi-LLM-Routing über mehrere Provider mit erzwungener EU-Allow-List unter `eu` und einem vollständig-EU-Pfad (Mistral FR managed + selbstgehostetes Ollama auf dem Kunden-Host). Neue Modell-IDs werden gegen offizielle Provider-Dokumentation verifiziert und vor Nutzung registriert — keine halluzinierten Endpunkte. Eine Per-Modell-Sperrliste fängt von Regional Processing nicht abgedeckte Modelle ab; Managed Failover hält Verfügbarkeit, ohne Residency zu verletzen.
Abwehr KI-spezifischer Angriffe
Das System muss KI-spezifische Bedrohungen erkennen und melden — Prompt Injection, Jailbreaks, Datenexfiltration über Outputs, Tool-Missbrauch, Package-Halluzination (OWASP GenAI Top-10, EU AI Act Art. 15 Robustheit, BSI).
PromptGuard, eine Defense-in-Depth-Architektur (sieben Schichten live), erkennt und markiert über eine typisierte Middleware: Input-Scanner, Injection-Klassifizierer, Output-Rogue-String-Detektor, Package-Halluzinations-Validator (PyPI/npm-Abgleich) und Egress-Sanitiser, ergänzt um Memory-Write-Quarantäne und SHA256-Integritätsprüfung der MCP-Tool-Beschreibungen. Eine kontinuierliche Garak-Red-Team-CI prüft die Wirksamkeit. Ehrliche Einordnung: mehrere Phasen laufen aktuell im Observe-only-Modus (erkennen/melden); die Kennzahlen stammen aus internen Benchmarks.