Sprache:
immo.quick Serverless Edition · Logo

immo.quick Serverless Edition · Einfach erklärt

Bevor Software handelt, muss sie es dürfen.

Ein Login, eine Freigabe oder ein erfolgreicher Prüfschritt sagt noch nicht, ob eine Handlung jetzt stattfinden darf. Die immo.quick Serverless Edition setzt genau dort an: unmittelbar vor einer Zahlung, einer Datenweitergabe oder einer anderen geschützten Handlung. Sie führt die erforderlichen Grundlagen zusammen und lässt die Handlung nur über den angebundenen, kontrollierten Weg zu.

Geschützte Handlung besprechenPrüfpfad für Auditoren

Für Revision und Aufsicht

Die institutionelle Artefakt-Kette: jede Aussage einzeln prüfen.

Ein bestandener Prüfschritt ist noch keine Handlungserlaubnis. Die folgenden sechs Stufen erklären, welche Frage ein Artefakt beantwortet und wo seine Aussage endet.

  1. 1

    Fachliche Feststellung

    Was wurde geprüft und mit welchem Ergebnis?

  2. 2

    Institutionelle Übernahme

    Darf unsere Institution diesen Beleg für diesen Zweck verwenden?

  3. 3

    Aktuelles Ausführungsrecht

    Tragen Befugnis, Regel, Rechtsraum, Zeit und Voraussetzungen gemeinsam?

  4. 4

    Technische Berechtigung

    Welche genau begrenzte Handlung darf die Software ausführen?

  5. 5

    Tatsächliche Ausführung

    Was wurde am kontrollierten Ausführungsweg tatsächlich getan?

  6. 6

    Nachweis der Wirkung

    Welcher Beleg bindet die Entscheidung und die beobachtete Wirkung?

Positiver Prüfzustand

Der Beleg dokumentiert einen fachlichen Zustand, keine Ausführungserlaubnis.

Beleg öffnen

Spätere Zustandsänderung

Ein späterer Sanktionstreffer verändert die Grundlage. Der ältere Beleg bleibt historisch erhalten.

Beleg öffnen

Übernahme verweigert

Ein vorhandener Beleg muss nicht für den Zweck einer anderen Institution genügen.

Beleg öffnen

Die Artefakte belegen ihren jeweiligen Zustand und ihre Bindung. Sie sind kein vollständiger Nachweis einer produktiven Ausführung. Historische Gültigkeit ersetzt keine gegenwärtige Ausführbarkeit.

Zwei Systeme. Klare Architekturgrenzen.

Die immo.quick Serverless Edition nutzt keine Trusted Execution Environments (TEEs) und keine Enclaves. TEE- und Enclave-Technologien werden ausschließlich in immo.quick Core genutzt. Beide Produkte sind eigenständige Systeme. Core ist keine Voraussetzung für die Serverless Edition.

Die Serverless Edition prüft definierte Bedingungen am integrierten Ausführungspfad und dokumentiert die Entscheidung kryptografisch nachvollziehbar. Eine TEE-Attestierung ist kein Bestandteil ihrer Architektur. Hardwaregestützte Isolation und Enclave-Attestierung gehören zum Core-Architekturprofil.

immo.quick Serverless Edition · immo.quick Core

Interner Prüfstand · 14. Oktober 2026

Vom Ausführungsrecht zum nachgelesenen Ergebnis.

Eine Freigabe kann richtig gewesen sein und später ihre Grundlage verlieren. Im intern geprüften Ablauf bindet die Serverless Edition Ausstellung, Entzug und Verbrauch an dieselbe verbindliche Ordnung. Ein vor dem Ausführungsschnitt eingeordneter Entzug sperrt den Verbrauch; eine Wiederholung erzeugt keine zweite interne Testwirkung.

  1. Ausführungsrecht binden

    Handlung, Schutzbereich, Raum und Epoche gehören zum gebundenen Gegenstand.

  2. Aktuellen Stand entscheiden

    Entzug und Verbrauch werden innerhalb derselben maßgeblichen Ordnung entschieden.

  3. Einmalig ausführen

    Ein dauerhafter Auftrag führt zum internen Empfänger und zur konkreten Testhandlung.

  4. Ergebnis nachlesen

    Auftrag, Quittierung und nachgelesenes Ergebnis werden getrennt dokumentiert.

Interner Wirkungspfad geprüft. Betriebsfreigabe noch offen.

Stand der internen Berichte vom 14. Oktober 2026: Die beiden Personenfreigaben und der interne Betriebsnachweis sind noch offen. Die dokumentierten Prüfläufe sind keine Freigabe für alle Sektoren und keine Bestätigung fremder Zielsysteme. Ein historisch gültiger Beleg ersetzt kein gegenwärtiges Ausführungsrecht.

Für Auditoren: Registerexport und Nachweisgrenzen

Nach dem internen Exportbericht wurden 21 signierte Teile aus 15 Registern mit insgesamt 1.811 Zeilen gesichert. Der gemeinsame Index führt die Prüfsummen; eine außerhalb der Anwendung nachgerechnete Stichprobe stimmte mit ihrer SHA-256-Prüfsumme überein. Das ist der dokumentierte Registerexport. Die Vollständigkeit des gesamten Quellbestands ist davon getrennt zu beurteilen.

Prüfgrundlage: interne Lauf- und Exportberichte. Die privaten Rohbelege werden hier nicht veröffentlicht. Die folgenden Angaben sind eine Zusammenfassung dieser Berichte und keine externe Zertifizierung.

Fehlende oder leere Betriebsschlüssel werden abgewiesen; S5 mit eigenem Abnahmeschlüssel ist als bestanden berichtet. HSM und externe Zeitautorität werden für diesen internen Umfang nicht als erfüllt behauptet und sind keine zusätzliche Voraussetzung.

Prüfunterlagen im vereinbarten Umfang anfragen

Für Auditoren

Zwischen Prüfung und Wirkung darf der Zustand nicht unbemerkt wechseln.

Diese Zeitlücke wird als Time-of-Check to Time-of-Use, kurz TOCTOU, beschrieben. Eine erneute Prüfung allein schließt sie nicht. Maßgebliche Zustandsänderungen und Ausführungsentscheidung müssen derselben verbindlichen Ordnung folgen; auch der Empfänger muss in den geschützten Wirkungspfad eingebunden sein. Die internen Prüfläufe belegen ihren benannten Umfang, keine allgemeine Schließung aller möglichen Zielsysteme.

Technischer Hintergrund: MITRE CWE-367

Das Problem: Die Freigabe bleibt. Die Wirklichkeit ändert sich.

Eine Zahlung wurde am Morgen genehmigt. Am Nachmittag wird die Befugnis zurückgenommen, ein Nachweis läuft ab oder der Empfänger ändert sich. In einem System, das nur die frühere Freigabe betrachtet, kann die Zahlung trotzdem weiterlaufen. Genau diese Lücke zwischen Entscheidung und Wirkung soll geschlossen werden.

Eine Zahlung. Drei Minuten. Eine entscheidende Frage.

Im Modellfall aus „Der Moment davor“ ist eine Überweisung über 25 Millionen Euro vorbereitet. Um 16:44 Uhr endet die entscheidende Befugnis. Um 16:47 Uhr soll das Geld abfließen. Die Frage ist deshalb nicht nur, wer die Zahlung ursprünglich freigegeben hat. Die Frage lautet: Darf genau diese Zahlung jetzt noch ausgeführt werden?

Was das System Schritt für Schritt tut.

Die Prüfung beginnt bei einer konkreten Handlung, nicht bei einem allgemeinen Risikowert. Wer handelt, was geschehen soll, wohin es wirkt und zu welchem Zweck: Diese Angaben werden fest miteinander verbunden. Änderungen verlangen eine neue Prüfung.

  1. 1 · Handlung festlegen

    Die konkrete Zahlung wird an Person, Betrag, Empfänger und Zweck gebunden.

  2. 2 · Grundlagen prüfen

    Befugnis, geltende Regeln, Rechtsraum, Zeitpunkt und erforderliche Nachweise müssen zusammenpassen.

  3. 3 · Vor der Wirkung entscheiden

    Fehlt eine Voraussetzung oder ist sie unklar, bleibt der geschützte Ausführungsweg gesperrt.

  4. 4 · Entscheidung belegen

    Ein prüfbarer Beleg hält fest, welche Grundlagen die Entscheidung getragen haben. Eine tatsächliche Ausführung wird gesondert nachgewiesen.

Grundlagen gültig: Die genau gebundene Handlung kann über den kontrollierten Weg zugelassen werden.

Grundlage fehlt oder ist unklar: Keine Ausführung über diesen Weg. Der Grund wird festgehalten.

Was daran anders ist.

Ein Dashboard macht Zustände sichtbar. Ein Alarm fordert jemanden zum Reagieren auf. Ein Protokoll hält fest, was geschehen ist. Die Serverless Edition ergänzt diese Werkzeuge um eine technische Entscheidung vor der geschützten Wirkung. Sie ersetzt nicht Ihre Fachsysteme, sondern wird in deren Ausführungswege eingebunden.

Wo diese Grenze gebraucht wird.

Bei Zahlungen schützt sie den Weg zum Geldabfluss. Bei KI-Agenten begrenzt sie die Handlungen, die ein Agent tatsächlich auslösen darf. Bei Datenweitergaben prüft sie Empfänger, Zweck und Voraussetzungen. In Verwaltung, Gesundheitswesen und Industrie betrifft sie Vorgänge, bei denen eine falsche Handlung mehr bewirkt als einen falschen Bildschirmtext.

Ein eigenständiges System.

Die Serverless Edition ist ein eigenständiges System. immo.quick Core ist ebenfalls eigenständig und keine vorgeschaltete Voraussetzung für Serverless. Die fachlichen Prüfungen, die Verwaltung der Befugnisse und die Belegbildung gehören zur Serverless Edition. Für den Einsatz wird sie mit den geschützten Handlungen Ihrer Organisation verbunden.

Was für einen wirksamen Einsatz stimmen muss.

Das System kann nur dort verhindern, wo der tatsächliche Ausführungsweg angebunden ist. Eine andere Schnittstelle, ein Hintergrundprozess oder ein administrativer Weg darf die Prüfung nicht umgehen. Außerdem müssen maßgebliche Befugnisse, Regeln und Nachweise verfügbar und aktuell sein. Ob das in einer konkreten Installation erfüllt ist, wird an genau diesen Wegen geprüft.

Der Einstieg beginnt mit einer Handlung.

Wir beginnen mit einer konkreten Frage: Welche Handlung Ihrer Organisation darf unter bestimmten Umständen keinesfalls stattfinden? Danach werden die zuständige Stelle, die Regeln, die benötigten Nachweise und sämtliche Wege zur Ausführung bestimmt. Daraus ergibt sich, welche Integration nötig ist und was die Abnahme nachweisen muss.

Geschützte Handlung besprechen

Drei Begriffe, die Sie kennen sollten.

Ausführungsrecht

Die aktuellen Grundlagen, aus denen folgt, dass genau diese Handlung erlaubt ist. Der technische Fachbegriff lautet Execution Right.

Technische Berechtigung

Eine eng begrenzte Erlaubnis für die angebundene Software. Sie gilt nur für die festgelegte Handlung und ihre Bedingungen. Der Fachbegriff lautet Capability.

Beleg

Ein überprüfbarer Nachweis zu einer Prüfung, Entscheidung oder Ausführung. Der Fachbegriff lautet Receipt. Ein Beleg beweist nicht automatisch die Wahrheit jeder verwendeten Quelle.

Häufige Fragen

Reicht eine normale Benutzerberechtigung nicht aus?

Sie sagt, welche Funktionen jemand grundsätzlich benutzen darf. Sie beantwortet nicht automatisch, ob eine konkrete Handlung unter den inzwischen geltenden Umständen noch erlaubt ist.

Entscheidet eine KI, ob etwas erlaubt ist?

Der beschriebene Prüfweg arbeitet mit festgelegten Bedingungen. Eine KI-Antwort oder eine Wahrscheinlichkeit ersetzt keine fehlende Befugnis und keinen vorgeschriebenen Nachweis.

Müssen wir unsere vorhandene Software ersetzen?

Der Ansatz ist die Einbindung in bestehende Systeme. Entscheidend ist, dass alle Wege zur geschützten Handlung die Prüfung tatsächlich durchlaufen.

Ist jede Installation bereits vollständig geprüft?

Nein. Architektur, implementierte Funktionen und der nachgewiesene Betrieb einer konkreten Installation sind getrennte Aussagen. Die vorhandenen Belege nennen ihren jeweiligen Umfang und ihre Grenzen.

Für die technische Prüfung

Wenn Sie die Architektur genauer prüfen möchten, finden Sie hier die Fachseiten und Belege. Prüfergebnisse gelten für den jeweils beschriebenen Umfang, nicht automatisch für jede Installation.

Kurz erklärt

Was kontrolliert die Serverless Edition?

Sie setzt am integrierten Ausführungsweg einer konkreten geschützten Handlung an. Befugnisse und erforderliche Bedingungen müssen im maßgeblichen Moment gelten. Die Wirksamkeit hängt von der tatsächlichen Einbindung und deren Abnahme ab.

Ist die Serverless Edition bereits für den internen Echtbetrieb freigegeben?

Nach dem dokumentierten Stand vom 14. Oktober 2026 noch nicht. Der interne Wirkungspfad und die Register-Nachlieferung sind berichtet; die beiden Personenfreigaben und der interne Betriebsnachweis stehen noch aus. Eine Freigabe gilt nur für die ausdrücklich geprüfte Basis und den benannten Umfang.

Das Buch zur Frage vor der Wirkung

Der Moment davor · Rami Cherri

Machine Law, KI-Governance und Ausführungsrechte verständlich erklärt. Die deutsche Fassung hat 386 Seiten. Hardcover, Softcover und E-Book sind mit eigenen ISBN und direkten Links zu tredition, Amazon und buecher.de auf der Buchseite aufgeführt.

Ausgaben, ISBN und Händler ansehen
Markensiegel immo.quick Serverless Edition
Institutionelle Artefakt-Kette · Serverless Edition

Von der Feststellung zur Wirkung. Kein Zustand darf den nächsten ersetzen.

immo.quick trennt fachliche Feststellung, institutionelle Übernahme, Ausführungsrecht, technische Capability, tatsächliche Ausführung und nachgelagerte Evidenz. Diese Trennung verhindert, dass ein positives Prüfergebnis automatisch zur Handlungserlaubnis wird oder ein früher gültiger Zustand später ungeprüft weiterwirkt. Jede Stufe beantwortet eine andere institutionelle Frage und besitzt eine eigene Beweisgrenze.

01

Domain Determination

Ein fachlicher, regulatorischer oder technischer Zustand wird deterministisch festgestellt.

PASS ≠ AUSFÜHRUNGSERLAUBNIS
02

Reliance Decision

Die empfangende Institution entscheidet, ob sie auf ein vorhandenes Artefakt für ihren konkreten Zweck überhaupt vertrauen darf.

EVIDENZ ≠ RELIANCE
03

Execution Rights Closure

Authority, Rule, Jurisdiction, Time und material Dependencies müssen für die konkrete Konsequenz aktuell schließen.

RELIANCE ≠ EXECUTION RIGHT
04

Capability

Erst ein gültiges Execution Right kann eine eng begrenzte, gebundene und gegebenenfalls Single-Use Capability erzeugen.

RIGHT ≠ AUSGEFÜHRTE HANDLUNG
05

Execution

Unmittelbar vor der Wirkung wird der aktuelle autoritative Zustand erneut geprüft. Änderungen vor dem Execution Cut können die Ausführung verhindern.

CONTINUING AUTHORITY
06

Evidence

Der tatsächlich maßgebliche Zustand, die erlaubte oder verweigerte Wirkung und die Beweiskette werden getrennt festgehalten.

PROOF ≠ LEGITIMITÄTSQUELLE
DOMAIN DETERMINATION ≠ RELIANCE ≠ EXECUTION RIGHT ≠ CAPABILITY ≠ EXECUTION ≠ EVIDENCE
1 · Positiver Banking-Zustand

Ein Banking-Domain-Receipt dokumentiert einen versiegelten fachlichen Zustand und erklärt zugleich ausdrücklich, dass keine Execution Permission entsteht.

Artefakt ansehenBANKING_SEALED · execution_permission=false
2 · Spätere materielle Zustandsänderung

Ein nachfolgendes Receipt dokumentiert einen Sanktionstreffer. Der frühere positive Zustand wird nicht überschrieben, darf aber nicht als dauerhafte Erlaubnis fortgeschrieben werden.

BLOCK-Receipt öffnenBLOCK_SANCTIONS_MATCH · chain_integrity=VALID
3 · Institutionelle Reliance verweigert

Ein eigener Reliance Decision Record zeigt, dass selbst ein vorhandener Proof nicht automatisch institutionell übernommen werden muss.

Reliance-Artefakt ansehendecision=REFUSE · reliance_granted=false
Claim Boundary: Diese Artefakte dokumentieren unterschiedliche Systemzustände und ihre kryptographische Bindung. Ein Domain Receipt beweist keine vollständige Execution Authorization. Ein Reliance Record erzeugt kein Execution Right. Rechtliche Wirkung und institutionelle Verwendbarkeit hängen vom konkreten Deployment, der Übernahme durch die Institution, dem einschlägigen Recht und dem jeweiligen Kontext ab.