Positiver Prüfzustand
Der Beleg dokumentiert einen fachlichen Zustand, keine Ausführungserlaubnis.
Beleg öffnen
immo.quick Serverless Edition · Einfach erklärt
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 AuditorenFür Revision und Aufsicht
Ein bestandener Prüfschritt ist noch keine Handlungserlaubnis. Die folgenden sechs Stufen erklären, welche Frage ein Artefakt beantwortet und wo seine Aussage endet.
Was wurde geprüft und mit welchem Ergebnis?
Darf unsere Institution diesen Beleg für diesen Zweck verwenden?
Tragen Befugnis, Regel, Rechtsraum, Zeit und Voraussetzungen gemeinsam?
Welche genau begrenzte Handlung darf die Software ausführen?
Was wurde am kontrollierten Ausführungsweg tatsächlich getan?
Welcher Beleg bindet die Entscheidung und die beobachtete Wirkung?
Der Beleg dokumentiert einen fachlichen Zustand, keine Ausführungserlaubnis.
Beleg öffnenEin späterer Sanktionstreffer verändert die Grundlage. Der ältere Beleg bleibt historisch erhalten.
Beleg öffnenEin vorhandener Beleg muss nicht für den Zweck einer anderen Institution genügen.
Beleg öffnenDie 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.
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.
Interner Prüfstand · 14. Oktober 2026
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.
Handlung, Schutzbereich, Raum und Epoche gehören zum gebundenen Gegenstand.
Entzug und Verbrauch werden innerhalb derselben maßgeblichen Ordnung entschieden.
Ein dauerhafter Auftrag führt zum internen Empfänger und zur konkreten Testhandlung.
Auftrag, Quittierung und nachgelesenes Ergebnis werden getrennt dokumentiert.
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.
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.
Für Auditoren
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.
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.
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?
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.
Die konkrete Zahlung wird an Person, Betrag, Empfänger und Zweck gebunden.
Befugnis, geltende Regeln, Rechtsraum, Zeitpunkt und erforderliche Nachweise müssen zusammenpassen.
Fehlt eine Voraussetzung oder ist sie unklar, bleibt der geschützte Ausführungsweg gesperrt.
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.
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.
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.
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.
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.
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 besprechenDie aktuellen Grundlagen, aus denen folgt, dass genau diese Handlung erlaubt ist. Der technische Fachbegriff lautet Execution Right.
Eine eng begrenzte Erlaubnis für die angebundene Software. Sie gilt nur für die festgelegte Handlung und ihre Bedingungen. Der Fachbegriff lautet Capability.
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.
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.
Der beschriebene Prüfweg arbeitet mit festgelegten Bedingungen. Eine KI-Antwort oder eine Wahrscheinlichkeit ersetzt keine fehlende Befugnis und keinen vorgeschriebenen Nachweis.
Der Ansatz ist die Einbindung in bestehende Systeme. Entscheidend ist, dass alle Wege zur geschützten Handlung die Prüfung tatsächlich durchlaufen.
Nein. Architektur, implementierte Funktionen und der nachgewiesene Betrieb einer konkreten Installation sind getrennte Aussagen. Die vorhandenen Belege nennen ihren jeweiligen Umfang und ihre Grenzen.
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
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.
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
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
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.
Ein fachlicher, regulatorischer oder technischer Zustand wird deterministisch festgestellt.
PASS ≠ AUSFÜHRUNGSERLAUBNISDie empfangende Institution entscheidet, ob sie auf ein vorhandenes Artefakt für ihren konkreten Zweck überhaupt vertrauen darf.
EVIDENZ ≠ RELIANCEAuthority, Rule, Jurisdiction, Time und material Dependencies müssen für die konkrete Konsequenz aktuell schließen.
RELIANCE ≠ EXECUTION RIGHTErst ein gültiges Execution Right kann eine eng begrenzte, gebundene und gegebenenfalls Single-Use Capability erzeugen.
RIGHT ≠ AUSGEFÜHRTE HANDLUNGUnmittelbar vor der Wirkung wird der aktuelle autoritative Zustand erneut geprüft. Änderungen vor dem Execution Cut können die Ausführung verhindern.
CONTINUING AUTHORITYDer tatsächlich maßgebliche Zustand, die erlaubte oder verweigerte Wirkung und die Beweiskette werden getrennt festgehalten.
PROOF ≠ LEGITIMITÄTSQUELLEEin Banking-Domain-Receipt dokumentiert einen versiegelten fachlichen Zustand und erklärt zugleich ausdrücklich, dass keine Execution Permission entsteht.
Artefakt ansehenBANKING_SEALED · execution_permission=falseEin 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=VALIDEin eigener Reliance Decision Record zeigt, dass selbst ein vorhandener Proof nicht automatisch institutionell übernommen werden muss.
Reliance-Artefakt ansehendecision=REFUSE · reliance_granted=false