AXYON in Action

Der Superheld ist kein Modell — es ist die Kontrolle drumherum.

Ein Sachbearbeiter stellt eine Anfrage. Im Hintergrund schlägt eine KI vor, was zu tun ist — einen Vertrag ändern, eine Zahlung anstoßen, einen Datensatz schreiben. In den meisten Systemen würde genau jetzt etwas passieren, unkontrolliert. Bei AXYON läuft der Vorschlag zuerst durch die Mitte.

Der Command Core prüft in Millisekunden: Wer fragt an — und ist er überhaupt angemeldet? Wie vertraulich sind die Daten, und darf diese Verarbeitung das Haus verlassen? Versucht jemand, die KI zu manipulieren? Verändert die Handlung etwas — und braucht sie deshalb eine menschliche Freigabe? Erst wenn jede Station grünes Licht gibt, wird gehandelt. Im Zweifel handelt AXYON nicht.

Und was auch immer geschieht: Es steht danach lückenlos und fälschungssicher im Protokoll. Aus einer Blackbox-KI wird ein kontrollierter, prüfbarer Geschäftsprozess — beweisbar statt plausibel.

KI schlägt vor, das System entscheidet

Die KI darf vorschlagen, erklären, ausführen — aber nie eigenständig über eine relevante Handlung entscheiden. Die Entscheidung trifft AXYON nach festen, erklärbaren Regeln. Immer gleich, immer protokolliert.

Vier-Augen-Freigabe, verbindlich

Verändernde Handlungen brauchen eine menschliche Freigabe: an genau diesen Auftrag gebunden, einmalig verwendbar, Freigeber ≠ Antragsteller. Ohne frische, fremde Freigabe wird verweigert.

Souverän im Standard

Lokales Modell im Haus (Ollama: Gemma, Qwen, Llama). Keine Daten verlassen das Netz. Der Cloud-Pfad ist doppelt abgesichert und standardmäßig abgeschaltet. Sensible Datenklassen bleiben strukturell lokal.

Prüffähig auf Knopfdruck

Manipulationssicher verketteter Audit-Trail, Not-Halt über den ganzen Cluster, Anbindung an vorhandenes SSO, Annex-IV-Doku für den EU AI Act — vorbereitet, verschlüsselt, exportierbar.

Auslieferung

Ein Kern, zwei Hüllen

AXYON wird in zwei Formen ausgeliefert: als Appliance im Container für den Unternehmensbetrieb und als macOS-App für den einzelnen Arbeitsplatz. Das sind nicht zwei Produkte und auch keine große und keine kleine Version — es ist derselbe Kern in zwei Hüllen. Die Hülle bestimmt nur, wo AXYON läuft und wie man es anspricht. Was es tut, ist in beiden Fällen identisch.

Was in beiden Hüllen exakt gleich ist

Die deterministische Weiche, die Guards gegen Prompt-Injection, das Eval-Gate beim Start, die bindende Vier-Augen-Freigabe, der Not-Halt, das verkettete und verschlüsselte Audit-Protokoll und der Annex-IV-Export. Alles davon sitzt im gemeinsamen Kern, nicht in der Hülle. Die macOS-App ist deshalb ausdrücklich keine abgespeckte Variante — ein Auftrag, der in der Appliance eine menschliche Freigabe braucht, braucht sie auf dem Notebook genauso.

Hülle 1 · Unternehmen

Appliance im Docker-Container

Für Organisationen mit eigener IT: mehrere Fachbereiche, zentrale Anmeldung, Betrieb im eigenen Rechenzentrum, in der privaten Cloud oder On-Premise.

Ein einzelnes Container-Image, das vollständig innerhalb der Grenze des Kunden läuft. Die IT startet es wie jeden anderen Dienst — per Docker Compose oder in Kubernetes —, hängt es an das vorhandene Single Sign-On und bindet es in die bestehende Überwachung ein. Es gibt keine Verbindung nach außen, die dafür nötig wäre.

Das Image ist bewusst karg gebaut: Es enthält keine Shell und keinen Paketmanager, läuft nicht als Administrator und schreibt nicht in sein eigenes Dateisystem. Wer in den Container einbricht, findet dort schlicht keine Werkzeuge vor.

  • Aufbau: distroless, non-root (UID 10001), read-only Dateisystem, alle Linux-Capabilities entzogen, no-new-privileges
  • Ansprache: HTTP-Fassade auf Port 8080 hinter fail-closed Authentifizierung
  • Anmeldung: OIDC gegen Entra ID oder Keycloak, mit automatischer Schlüsselrotation im laufenden Betrieb
  • Betrieb: /healthz, /readyz und /metrics für Monitoring; mehrere Instanzen parallel, wobei Freigaben und Not-Halt über alle Knoten hinweg gemeinsam gelten
  • Lieferumfang: Image samt Stückliste (SBOM) und Build-Herkunftsnachweis (SLSA-Provenance) über die Registry
  • Fail-closed: ohne konfigurierte Anmeldung nimmt die Appliance keinen Auftrag an — sie startet nicht „halb offen"
Hülle 2 · Arbeitsplatz

Native macOS-App

Für den einzelnen Arbeitsplatz und kleine Teams: Beratung, Fachbereich, Pilotbetrieb — überall dort, wo keine Container-Infrastruktur bereitsteht.

Eine native Desktop-Anwendung für Apple Silicon. Der Governance-Kern läuft dabei direkt im Programm — nicht als lokaler Server, den die App anspricht. Das ist eine bewusste Entscheidung: Ein offener Netzwerk-Port auf einem Arbeitsgerät wäre zusätzliche Angriffsfläche ohne jeden Nutzen. Die App öffnet keinen.

Damit ist der souveräne Fall vollständig: Auftrag, Prüfung, Freigabe, Modell und Protokoll bleiben auf dem Gerät. Es gibt keinen Weg, auf dem Daten das Notebook verlassen, solange der Cloud-Pfad nicht ausdrücklich freigeschaltet ist.

  • Aufbau: Tauri-App mit dem Kern in-process — kein HTTP, kein offener Port
  • Modell: lokal auf dem Gerät über Ollama (etwa Gemma, Qwen oder Llama), per Konfiguration austauschbar
  • Vertrieb: Developer-ID-Direktvertrieb, signiert und von Apple notarisiert — kein Mac App Store, Auslieferung als DMG
  • Prüfbar: Gatekeeper meldet auf dem Zielrechner „Notarized Developer ID"
  • Voraussetzung: macOS 12 oder neuer
  • Souverän: keine Serverkomponente, kein Konto, keine Registrierung nötig
 Appliance (Container)macOS-App
Läuftim Rechenzentrum, privater Cloud oder On-Premiseauf dem Gerät selbst
Angesprochen überHTTP-Fassade hinter Authdirekt im Programm, ohne Netz
Nutzerkreisviele, über zentrale Anmeldungein Arbeitsplatz bzw. kleines Team
Anmeldungvorhandenes SSO (Entra ID, Keycloak)lokal, ohne zweite Benutzerverwaltung
Betrieben durchdie IT des Kundenden Anwender selbst
Ausgeliefert alsContainer-Image mit SBOM und Herkunftsnachweissigniertes, notarisiertes DMG
Ausfallsicherheitmehrere Instanzen im VerbundEinzelgerät
Governanceidentisch — gleiche Regeln, gleiche Freigabe, gleicher Not-Halt, gleiches Protokoll, gleicher Prüf-Export

Ehrlich zum Stand: Beide Hüllen sitzen auf demselben geprüften Kern und sind auslieferungsfertig vorbereitet. Der Signier- und Notarisierungslauf der macOS-App ist ein Schritt, der zwingend auf einem Mac mit hinterlegtem Entwicklerzertifikat ausgeführt wird — er ist eingerichtet und dokumentiert. Wir schreiben das hier hin, statt es zu verschweigen: beweisbar statt plausibel gilt auch für die eigene Produktseite.

Häufige Fragen

KI-Agenten absichern — die wichtigsten Fragen

Wie kann man KI-Agenten im Unternehmen absichern?
Indem kein Agent direkt mit Modellen oder Fremdsystemen spricht, sondern jede Handlung durch eine Kontrollschicht läuft. AXYON prüft jeden Auftrag regelbasiert, begrenzt die Werkzeuge pro Auftrag auf das Nötigste, verlangt für verändernde Handlungen eine menschliche Freigabe und schreibt jeden Schritt in ein manipulationssicheres Protokoll. Fehlt eine Freigabe oder ist eine Prüfung nicht bestanden, wird die Handlung verweigert statt geraten.
Ist AXYON ein KI-Modell?
Nein. AXYON ist kein KI-Modell und ersetzt keines — es ist die Kontroll- und Nachweisschicht um beliebige Modelle herum. Das Sprachmodell ist über einen einheitlichen Steckplatz jederzeit austauschbar, während Freigabe, Kontrolle und Nachweis unverändert bleiben.
Bleiben unsere Daten im eigenen Haus?
Ja. AXYON ist souverän im Standard: Externe KI-Dienste sind abgeschaltet, solange sie nicht bewusst freigeschaltet werden — was zusätzlich eine bestätigte vertragliche Grundlage erfordert. Das Modell läuft lokal über Ollama auf eigener Hardware. Die Vertraulichkeitsstufe wird serverseitig erzwungen und lässt sich vom Anfragenden nur verschärfen, nie unterlaufen.
Wie funktioniert die Vier-Augen-Freigabe bei KI-Handlungen?
Sobald eine KI-Handlung etwas verändern würde, verlangt AXYON eine verbindliche menschliche Freigabe. Sie ist an genau diesen einen Auftrag gebunden, nur einmal verwendbar und mandantengebunden. Wer einen Auftrag stellt, kann ihn nicht selbst freigeben — Freigeber und Antragsteller müssen verschiedene Personen sein.
Wie lässt sich nachweisen, was eine KI getan hat?
Jede Weichenstellung, Freigabe, ausgeführte Handlung und Ablehnung wird in ein fortlaufendes, hash-verkettetes und verschlüsseltes Protokoll geschrieben; nachträgliche Änderungen fallen auf. Daraus lässt sich auf Knopfdruck ein prüffähiger Auszug erzeugen — etwa für ein internes Audit, eine Aufsichtsbehörde oder die technische Dokumentation nach Anhang IV der EU-KI-Verordnung.
Läuft AXYON on-premise oder auf dem Mac?
Beides — zwei Hüllen auf einem Kern: als self-hosted Container-Appliance im eigenen Rechenzentrum, in der privaten Cloud oder On-Premise, und als native macOS-App für den einzelnen Arbeitsplatz, bei der der Kern ohne offenen Netzwerk-Port direkt im Programm läuft. Die Governance ist in beiden Formen identisch.
Worin unterscheidet sich AXYON von GARION?
GARION beantwortet die Frage, ob eine Organisation für EU AI Act und NIS2 führungsfähig ist: Reifegrad, Risiko-Klassifikation, KI-Inventar, prüffähiges Board-Pack. AXYON wirkt eine Ebene tiefer, zur Laufzeit, und kontrolliert die einzelne KI-Handlung im Moment ihrer Ausführung. Kurz: GARION steuert das Programm, AXYON kontrolliert den Vollzug.

AXYON im eigenen Haus evaluieren

Als self-hosted Unternehmens-Appliance oder als notarisierte macOS-App am Arbeitsplatz — derselbe kontrollierte, nachweisbare Kern.

Gespräch anfragen AI Business Applications ZERYON Systems
ZERYON-Ökosystem ZERYON Systems· GARION — EU AI Act & NIS2· KAIRON — KI-ROI· ZERYON — Learning Intelligence· ORTYON
AXYON — beweisbar statt plausibel. Kontrollierte KI, die im Haus bleibt und sich lückenlos nachweisen lässt.
© ZERYON Systems · Predrag Gasic · Marke der ZERYON-Familie