{ "version": "https://jsonfeed.org/version/1.1", "title": "JamOneAI Blog", "home_page_url": "https://jamoneai.de/blog", "feed_url": "https://jamoneai.de/blog/feed.json", "description": "Gedanken zu souveräner KI-Architektur und eigenen Systemen", "language": "de", "items": [ { "id": "23", "url": "https://jamoneai.de/blog/custodoc-lokales-dokumentenmanagement", "title": "CustoDoc: Custodia für Ihre Akten, ein Dokumentenmanagement zum Kaufen statt zu mieten", "summary": "Zwischen der alten Aktenmauer aus On-Premise-Systemen von vor zehn Jahren und der modernen Cloud-SaaS-Miete, bei der die eigenen Akten auf fremder Infrastruktur liegen, gab es bisher nichts. CustoDoc ist der dritte Weg: lokal installiert, formal bewiesene Löschsperren, ein hash-verkettetes Audit-Log und KI-Klassifizierung ohne Cloud-Zwang, alles zum Einmalkauf statt zur Dauermiete.", "content_text": "Der Markt für Dokumentenmanagement zerfällt in zwei Lager, und beide haben denselben blinden Fleck. Auf der einen Seite etablierte On-Premise-Systeme großer Softwarehäuser, Datenhoheit im eigenen Haus, aber Oberfläche und Tempo von vor zehn Jahren, hohe Einstiegskosten, Rollouts über Monate, eigene IT-Projektteams nötig, keine native KI-Klassifizierung. Auf der anderen Seite moderne Cloud-SaaS-Anbieter, schneller Rollout, zeitgemäße Oberfläche, aber die Dokumente liegen auf fremder Infrastruktur, für Berufsgeheimnisträger oft schlicht unzulässig, und selbst die KI-Klassifizierung läuft über die Cloud des jeweiligen Anbieters.\n\nCustoDoc ist der dritte Weg, den bisher niemand gegangen ist. Lokale Installation, Einmalkauf statt Abo, eine moderne Oberfläche, die in Minuten startklar ist, KI-Klassifizierung lokal über Open-Source-KI oder mit eigenem API-Key, automatisierte Aufbewahrungsfristen und ein hash-verkettetes Audit-Log. Custodia für Ihre Akten, im wörtlichen Sinn.\n\n## Vom Posteingang bis zum rechtssicheren Archiv\n\nAlle Kern-Pipelines sind von Tag eins ein zusammenhängendes Produkt, nicht nachträglich angeflanscht, fünf Schritte, die ineinandergreifen:\n\n- **Erfassen.** Datei per Drag & Drop ablegen, PDFs mit echter Textebene werden automatisch ausgelesen, alles landet sofort verschlüsselt im Vault.\n- **Klassifizieren.** Ein KI-Vorschlag für Dokumentart und Aufbewahrungsklasse kommt lokal über Open-Source-KI direkt auf dem eigenen Server oder über den eigenen API-Key, sensible Angaben werden vorher automatisch maskiert.\n- **Finden.** Volltextsuche über Titel, Metadaten und den echten extrahierten Dokumenttext, kombinierbar mit Filtern nach Dokumentart, Mandant und Status.\n- **Nachweisen.** Jede Aktion wird kryptographisch verkettet protokolliert, eine nachträgliche Manipulation bricht die Kette, rechnerisch nachweisbar statt nur behauptet.\n- **Freigeben und archivieren.** Frei zusammenstellbare Freigabeschritte nach dem Vier-Augen-Prinzip, dazu eine Aufbewahrungsfrist und Löschsperre, deren Zuverlässigkeit formal mathematisch bewiesen ist, nicht nur getestet.\n\n## Automatisierte Compliance statt Beratungsprojekt\n\nAufbewahrungsfristen nach GoBD, DSGVO Art. 17 und branchenspezifischen Vorgaben sind im Kern der Software hinterlegt. Jedes Dokument bekommt beim Import automatisch eine vorgeschlagene Aufbewahrungsklasse, keine separate Beratungsrunde, um das erst einzurichten. Eine Löschsperre gilt bis zum Fristablauf, ein Legal Hold friert diese Sperre bei laufenden Verfahren zusätzlich ein.\n\nDer Teil, den ich für den eigentlichen Kern von CustoDoc halte: die Zuverlässigkeit dieser Löschsperre ist nicht nur behauptet, sondern formal bewiesen. Ein mathematischer Beweis, mit demselben Z3-Solver, der auch das Audit-Log absichert, zeigt über jeden möglichen Systemzustand hinweg, dass eine Löschung ohne Bestätigung oder trotz aktivem Legal Hold technisch unmöglich ist, nicht nur durch eine Reihe von Testfällen abgedeckt, die zufällig alle bestanden haben. Ein Testfall zeigt, dass es in den geprüften Fällen funktioniert hat. Ein Beweis zeigt, dass es in keinem Fall anders sein kann.\n\n## Hash-Chain-Audit-Log: Beweis statt Vertrauen\n\nJede Dokumentaktion, ein geöffnetes Dokument, eine hochgeladene Version, eine erteilte Freigabe, eine geprüfte Aufbewahrungsfrist, wird als Ereignis protokolliert, kryptographisch verkettet mit dem Hash des vorangegangenen Eintrags. Eine nachträgliche Änderung an einem einzelnen Eintrag bricht die Kette erkennbar, rechnerisch nachweisbar, nicht nur behauptet.\n\nDie mitgelieferte Demo-Datenbank enthält absichtlich einen manipulierten Eintrag. Nicht versteckt, sondern eingebaut, damit direkt sichtbar wird, dass CustoDoc genau das erkennt und den exakten Bruchpunkt in der Kette benennt, statt eine Schwäche zu verschweigen, die ein Prüfer sowieso irgendwann findet. So lässt sich einem Prüfer die Unversehrtheit der eigenen Akten tatsächlich beweisen, statt sie nur zu behaupten.\n\n## KI-Klassifizierung ohne Cloud-Zwang\n\nHochgeladene PDFs mit echter Textebene, etwa exportierte Verträge oder Rechnungen, werden automatisch ausgelesen, klassifiziert und verschlagwortet, nach dem BYOK-Prinzip vollständig lokal über Open-Source-KI direkt auf dem eigenen Server oder mit einem eigenen API-Key. Wichtig zur Einordnung: Texterkennung für eingescannte Bilddokumente steht noch auf der Roadmap, aktuell liest CustoDoc echte, digital erzeugte PDF-Textebenen aus, keine Bild-OCR, eine ehrliche Grenze statt eines übertriebenen Versprechens.\n\nVor jeder Klassifizierung greift Pre-Flight PII-Masking: eine lokale Engine erkennt IBANs, E-Mail-Adressen und Telefonnummern zuverlässig per Muster, dazu Mandantennamen und Aktenzeichen über eine vom Kunden selbst gepflegte Begriffsliste, und ersetzt sie durch Platzhalter, bevor überhaupt ein Byte einen fremden API-Anbieter erreicht. Die Zuordnung bleibt ausschließlich lokal, die externe KI sieht zu keinem Zeitpunkt echte Daten. Genau an diesem Punkt wird Cloud-KI bei Berufsgeheimnisträgern nach § 203 StGB sonst schnell zum Ausschlusskriterium. Freitext-Erkennung beliebiger Namen ohne Begriffsliste ist bewusst kein Versprechen der ersten Version, dafür bräuchte es ein echtes, separat zu validierendes NLP-Modell, auch das eine ehrlich benannte Grenze statt eines vagen \"funktioniert schon irgendwie\".\n\n## Verschlüsselter Vault mit zwei Entsperrwegen\n\nDokumentinhalte liegen AES-256-verschlüsselt auf der Platte, entsperrt über eine selbst gewählte Passphrase mit Argon2id-Schlüsselableitung, derselben Technik wie bei einer echten Festplattenverschlüsselung. Zusätzlich lässt sich derselbe Schlüssel an das aktuelle Windows-Konto binden, sodass der Vault ohne erneute Passphrase-Eingabe entsperrt, solange man an diesem Rechner und Konto angemeldet ist, die Passphrase bleibt parallel als Rückfallebene gültig, falls die Konto-Bindung einmal nicht greift.\n\n## Feingranulare Mandantenrechte, secure by default\n\nVier Rollen, Administrator, Sachbearbeiter, Freigeber und Revisor, regeln die Grundrechte. Der entscheidende Unterschied zu vielen anderen Systemen: ein Sachbearbeiter oder Freigeber sieht ohne explizite Freigabe zunächst gar keinen Mandanten, weder Dokumente noch Fristen noch Kennzahlen, nicht einmal, dass der Mandant existiert. Ein Administrator schaltet einzelne Mandanten gezielt pro Person frei, jederzeit widerrufbar, und sieht dabei sofort, wer worauf Zugriff hat. Secure by default heißt hier: die Standardeinstellung ist \"sieht nichts\", nicht \"sieht alles, bis jemand es einschränkt\".\n\n## Vier-Augen-Freigaben, frei zusammenstellbar\n\nFreigabeschritte sind keine feste Vorlage, sondern frei kombinierbar nach Rolle und Zweck, Rechnungsfreigabe, interne Freigabe, Mandatsprüfung, genau das, was die jeweilige Organisation tatsächlich braucht. Ein Detail, das im Alltag leicht übersehen wird: wird während eines laufenden Freigabeprozesses ein Legal Hold gesetzt, bricht der Abschluss sauber und nachvollziehbar ab, statt sich fälschlich als erledigt auszugeben, ein Freigabeprozess, der einfach weiterläuft, obwohl mittendrin eine Rechtssperre dazwischenkam, wäre ein stiller Compliance-Bruch.\n\n## Wissensdatenbank: nicht nur ablegen, sondern selbst schreiben und veröffentlichen\n\nEin DMS verwaltet meistens nur, was ohnehin schon als Datei existiert. CustoDoc bringt zusätzlich einen eingebauten Editor mit, Überschriften, Listen, Bilder, eingebettete Videos, wie in einem vertrauten Block-Editor, dazu Kategorien, Tags, ein Titelbild, ein eigener Permalink. Eine Anleitung kann mitten im Text auf eine echte, im DMS abgelegte Akte verweisen, als eingebettete Karte, kein bloßer Link, sondern eine sichtbare Referenz auf das echte Dokument, Ablage und Wiki werden so ein zusammenhängendes Ganzes statt zweier getrennter Werkzeuge.\n\nJede Seite bekommt eine SEO-Vorschau und zusätzlich einen AEO-Bereich, eine kurze, direkt zitierbare Antwort plus FAQ-Block, damit gängige KI-Suchassistenten die eigenen Inhalte korrekt zusammenfassen können, optional inklusive Aufnahme in llms.txt. Eine Seite kann intern, nur für bestimmte Rollen oder öffentlich sein, fertige Seiten lassen sich mit einem Klick als eigenständige, navigierbare Website exportieren, als Ordner oder als fertiges ZIP-Archiv, auf einem internen Server als Firmen-Wiki, auf einem Unterpfad der eigenen Domain oder auf einer eigenen Domain. CustoDoc betreibt dafür keine eigene Cloud, der Export wird selbst hochgeladen.\n\nEin kleiner Beweis nebenbei, den ich bewusst so gebaut habe: die Produktdokumentation selbst ist keine separat getippte Marketingseite, sondern mit der Wissensdatenbank von CustoDoc selbst geschrieben, veröffentlicht und als eigenständige Website exportiert, genau die Funktion, die hier beschrieben ist. Wer sie öffnet, sieht damit nicht nur, wie CustoDoc funktioniert, sondern auch ein echtes Ergebnis davon.\n\n## Lokaler MCP-Server für eigene KI-Agenten\n\nCustoDoc betreibt einen lokalen MCP-Server, über den ein im eigenen Haus laufender KI-Agent Dokumente und Fristen durchsuchen, Freigaben einsehen und die Audit-Kette sowie die formalen Sicherheitsbeweise prüfen kann, lesend und ausschließlich lokal im eigenen Netz. Kein Umweg über eine fremde Cloud, die im Zweifel mitliest.\n\n## Zielgruppe: wer seine Akten nicht in eine fremde Cloud laden darf\n\nCustoDoc ist primär für Berufsgeheimnisträger und regulierte Organisationen mit gesetzlichen Aufbewahrungspflichten gebaut, sekundär für Mittelstand mit eigener IT und genereller Präferenz für Datenhoheit.\n\n- **Kanzleien und Notariate.** § 203 StGB, Mandantenakten, mandantenfähig von Anfang an.\n- **Steuerberater und Wirtschaftsprüfer.** GoBD- und HGB-konforme Aufbewahrung von Buchungsbelegen.\n- **Banken und Versicherungen.** Aufsichtsprüfungen, beweisbares Audit-Log statt bloßem Logging.\n- **Gesundheitswesen.** Ärztliche Dokumentationspflichten, sensible Patientendaten.\n- **KRITIS-Betriebe.** NIS2- und BSI-Vorgaben, lokal kontrollierbare Infrastruktur.\n- **Öffentliche Verwaltung.** Nachweisbare Aktenführung, DSGVO-Auftragsverarbeitung vermeiden.\n- **Mittelstand mit eigener IT.** Vertrags-, Personal- und Buchhaltungsunterlagen zentral verwalten.\n\n## Lizenzierung: Einmalkauf statt Abo\n\nAlle Preise netto, zzgl. gesetzlicher Mehrwertsteuer, einmalig statt monatlich. Ein Update- und Supportvertrag ist optional und jederzeit kündbar, die Software funktioniert auch ohne ihn unverändert weiter.\n\n| Edition | Preis | Umfang |\n| --- | --- | --- |\n| Solo | 1.900 € einmalig | Ein Arbeitsplatz, Erfassung, Textauslese und Klassifizierung (BYOK), Volltextsuche und Versionierung, Aufbewahrungsfristen und Hash-Chain-Audit-Log, verschlüsselter Vault inklusive Windows-Konto-Bindung |\n| Team | 6.900 € einmalig | Bis 10 Nutzer, alles aus Solo für ein ganzes Team, Rollen und feingranulare Zugriffsrechte, Vier-Augen-Freigabeprozesse, Wissensdatenbank mit Export |\n| Kanzlei-Edition | 14.900 € einmalig | Bis 25 Nutzer, inklusive Mandantenfähigkeit, beliebig viele Mandanten, sauber getrennte Ablage je Mandant, feingranulare Mandantenrechte pro Nutzer |\n| Enterprise & Behörden | ab 29.900 €, individuell | Unbegrenzte Nutzer, Standort- oder Serverlizenz, priorisierter Support, persönliches Onboarding, eIDAS-Signatur als Ausblick |\n\nFür ein kleines Team mit nur wenigen Mandanten lässt sich das Zusatzmodul Mandantenfähigkeit für 2.000 Euro zu jeder Team-Lizenz dazubuchen, ganz ohne Sprung auf die Kanzlei-Edition. Einrichtung und Schulung vor Ort, drei Tage, 4.900 Euro zuzüglich Reise und Übernachtung, ist optional und zu jeder Lizenz jederzeit nachbuchbar. Ein Update- und Supportvertrag kostet optional 18 Prozent des Lizenzpreises pro Jahr, ohne Verlängerungszwang.\n\n## Die härtesten Einwände, ehrlich beantwortet\n\n### \"Funktioniert CustoDoc auch offline?\"\n\nJa, bei rein lokalen KI-Modellen funktioniert CustoDoc vollständig vom Internet getrennt, air-gapped-fähig, kein versehentlicher Cloud-Aufruf möglich.\n\n### \"Was passiert, wenn wir den Supportvertrag nicht verlängern?\"\n\nDie Software funktioniert unverändert weiter. Der Update- und Supportvertrag ist optional und jederzeit kündbar, er betrifft Sicherheitsupdates und Support-Kontingent, nicht die grundsätzliche Lauffähigkeit der bereits lizenzierten Version.\n\n### \"Kann jeder Mitarbeiter alle Mandantenakten sehen?\"\n\nNein, das Gegenteil ist der Standard. Ohne explizite Freigabe sieht ein Sachbearbeiter oder Freigeber zunächst gar keinen Mandanten, ein Administrator schaltet Zugriffe gezielt pro Person frei, jederzeit widerrufbar.\n\n### \"Ist CustoDoc GoBD-konform?\"\n\nAufbewahrungsfristen nach GoBD sind im Kern der Software hinterlegt, jedes Dokument erhält beim Import automatisch eine vorgeschlagene Aufbewahrungsklasse, die Löschsperre bis Fristablauf ist formal bewiesen statt nur getestet.\n\n## Wie CustoDoc gebaut wird\n\nWie bei jedem meiner anderen Projekte wird die Rolle von KI-Systemen im eigenen Entwicklungsprozess offen benannt, nicht versteckt. CustoDoc entsteht im Zusammenspiel mehrerer KI-Systeme für Entwicklung, Code-Review und kritischen Gegencheck, die Letztverantwortung für Architektur, Sicherheitsentscheidungen und jede Zeile Code liegt am Ende bei mir. Ein Produkt, das Kanzleien und Behörden einen formalen Beweis für die eigene Aktenintegrität verspricht, muss bei der eigenen Entstehung genauso ehrlich sein.\n\n## Roadmap: was als Nächstes kommt\n\nTexterkennung für eingescannte Papierdokumente steht auf der Roadmap, aktuell werden ausschließlich echte, digital erzeugte PDF-Textebenen ausgelesen, keine Bild-OCR. Für die Enterprise-Edition ist außerdem eine eIDAS-Signatur als Ausblick vorgesehen.\n\n## In fünf Schritten zum rechtssicheren Archiv\n\nErfassen per Drag & Drop, automatische Textauslese und sofortige Verschlüsselung im Vault. Klassifizieren per lokaler KI oder eigenem API-Key, mit vorgeschalteter PII-Maskierung. Finden per Volltextsuche über Titel, Metadaten und echten Dokumenttext. Nachweisen über das hash-verkettete Audit-Log. Freigeben und archivieren nach dem Vier-Augen-Prinzip, mit formal bewiesener Löschsperre bis zum Fristablauf.\n\n## Wichtige Erkenntnisse aus diesem Beitrag\n\nCustoDoc ist ein lokal installiertes Dokumentenmanagement, Einmalkauf statt Abo, das Akten erfasst, durchsucht, versioniert und archiviert. Ein Z3-Beweis zeigt formal, dass eine Löschung ohne Bestätigung oder trotz aktivem Legal Hold technisch unmöglich ist, dieselbe Beweistechnik sichert auch das hash-verkettete Audit-Log ab, eine nachträgliche Manipulation bricht die Kette nachweisbar. KI-Klassifizierung läuft nach dem BYOK-Prinzip lokal oder über einen eigenen API-Key, mit vorgeschaltetem Pre-Flight PII-Masking. Vier Rollen regeln den Zugriff secure by default, ein Mandant ist ohne explizite Freigabe zunächst unsichtbar. Eine eingebaute Wissensdatenbank lässt sich schreiben, veröffentlichen und als eigenständige Website exportieren. Lizenziert wird einmalig von 1.900 Euro für einen Arbeitsplatz bis zum individuellen Enterprise-Angebot, gebaut für Kanzleien, Steuerberater, Banken, Gesundheitswesen, KRITIS-Betriebe, Verwaltung und Mittelstand, die ihre Akten nicht in eine fremde Cloud laden dürfen.", "date_published": "2026-09-05T18:00:00Z", "date_modified": "2026-09-05T18:00:00Z", "authors": [ { "name": "Adnan" } ], "tags": [ "custodoc", "dokumentenmanagement", "z3", "audit-log", "gobd", "dsgvo", "kritis", "kanzleisoftware", "pii anonymisierung" ] }, { "id": "24", "url": "https://jamoneai.de/blog/muxeo-digitales-abbild-souveraener-ki-agent", "title": "Muxeo: Lass dich nicht durch KI ersetzen, werde die KI, die dich vertritt", "summary": "Firmen ersetzen Arbeitsplätze gerade mit KI-Agenten. Muxeo dreht das um: du setzt dieselbe KI ein und bringst zusätzlich das ein, was kein Modell der Welt allein leisten kann, deine Erfahrung, dein Urteilsvermögen, deine Verantwortung. Ein lokal installierter, dir gehörender KI-Agent als dein digitales Abbild, mit sechs Sicherheitsgrenzen, die kein Unternehmen umgehen kann.", "content_text": "Ich will ehrlich sein, warum ich dieses Projekt baue, bevor ich erkläre, was es tut. Die vorherrschende Geschichte über KI und Arbeit lautet gerade: ein Modell übernimmt allein, ohne Aufsicht, die Aufgaben eines Menschen, der Mensch wird überflüssig. Unternehmen kaufen generische KI ein, der wirtschaftliche Wert fließt an das Unternehmen und den KI-Anbieter. Der Mensch, dessen Arbeit ersetzt wird, hat daran keinen Anteil.\n\nMuxeo erzählt das Gegenteil. Mensch und KI als Team, nicht als Konkurrenten. Dein Agent ist die Verlängerung deiner Arbeitskraft, nicht dein Ersatz. Er übernimmt das Wiederholbare, du bringst das ein, was kein Modell hat, Urteilsvermögen, Vertrauen, Verantwortung, eine menschliche Entscheidung im Zweifelsfall. Der eigentliche Grund, warum das aufgeht: die KI allein, mit der ein Unternehmen deinen Job ersetzen will, ist dieselbe Art von Modell, die auch du einsetzen kannst. Der einzige Unterschied ist deine Expertise obendrauf, die Jahre an Urteilsvermögen, Kundenvertrauen und Verantwortung, die kein Modell besitzt und keines nachbauen kann. Ein Unternehmen mit KI allein hat weniger als ein Mensch mit derselben KI plus echter Erfahrung. Das ist keine Behauptung, das ist einfache Rechnung.\n\n## Eine andere Art von Wandel: die fünfte Zeitenwende\n\nVier Mal hat Technologie die Arbeit verändert, nie den Menschen selbst. In jeder dieser Wellen blieb eine Sache unangetastet: Urteilsvermögen, Sprache und Entscheidung lagen weiter beim Menschen.\n\n- **1. Revolution, ab ca. 1800.** Dampf und Kohle ersetzen Muskelkraft.\n- **2. Revolution, ab ca. 1900.** Das Fließband diszipliniert die Handarbeit.\n- **3. und 4. Revolution, ab ca. 1970.** Computer und Software automatisieren das Wiederholbare.\n- **5. Revolution, heute.** KI und Roboter zielen zum ersten Mal gleichzeitig auf Urteilsvermögen und auf physische Arbeit.\n\nZum ersten Mal zielt Technologie nicht auf ein Werkzeug in unserer Hand, sondern auf das, was wir für unser Monopol hielten. Gleichzeitig, in derselben Welle, rollen humanoide Roboter und autonome Maschinen in Werkshallen, auf Baustellen und in die Pflege, dieselbe Logik, nur für die physische statt die geistige Arbeit. Kognitive und physische Arbeit werden zum ersten Mal gleichzeitig angegriffen, nicht nacheinander. Muxeo bricht mit der Erzählung \"Kauf die autonome KI, spar dir den Menschen\": ob am Bildschirm oder an der Maschine, die Antwort ist nicht Mensch gegen Maschine, sondern Mensch mit der Maschine, die ihm gehört.\n\n## Zwei Ausgangslagen, ein Werkzeug\n\n**Dein Job existiert noch.** Aber du spürst den Druck, irgendwo im Unternehmen wird gerade über KI-Automatisierung gesprochen. Mit Muxeo wirst du selbst der Grund, warum diese Automatisierung funktioniert, nicht ihr Ziel. Dieselbe Stelle, spürbar mehr Leistung dahinter.\n\n**Dein Job ist schon weg.** Oft genau durch diese Automatisierung. Muxeo macht dein Fachwissen zu einem digitalen Abbild, das über den Marktplatz echte, bezahlte Aufträge findet. Kein Bewerbungsmarathon von vorne, sondern das, was du schon kannst, sofort einsatzbereit.\n\n## Wie es funktioniert: vier Schritte, jedes Mal, ohne Ausnahme\n\nEgal ob eine E-Mail geschrieben oder ein Roboter bewegt wird, derselbe Ablauf, echter, getesteter Code, kein Ablaufdiagramm ohne Entsprechung:\n\n- **Planen.** Aus deiner Aufgabe in eigenen Worten wird in Sekunden ein konkreter Handlungsvorschlag: Werkzeug, Schritte, erwartetes Ergebnis, sichtbar, bevor überhaupt etwas passiert.\n- **Prüfen.** Sechs harte Grenzen laufen immer zuerst, unabschaltbar. Danach deine eigene Regel: erlaubt, Rückfrage nötig, oder abgelehnt, jede Entscheidung auf einen Blick nachvollziehbar.\n- **Ausführen.** Nur bei echter Freigabe wird das Werkzeug tatsächlich aufgerufen, nie auf bloße Behauptung hin. Ein digitales Werkzeug (Datei, E-Mail, Kalender) läuft sofort nach Freigabe, ein physischer Roboter zusätzlich nur mit aktiver Sitzung, Geofence und Lebenszeichen.\n- **Protokollieren.** Jede Entscheidung landet fälschungssicher im Protokoll, auch eine abgelehnte, unabhängig vom Ausgang.\n\n## Sechs Grenzen, die kein Regelwerk umgehen kann\n\nDeine eigenen Regeln bestimmen, was der Agent im Alltag darf. Diese sechs Grenzen liegen darunter, fest im Code verankert, unabhängig davon, was du einstellst. Deshalb ist die Antwort auf \"ist das wirklich sicher?\" keine Behauptung, sondern nachprüfbar: jede Grenze ist ein echter, formal geprüfter Test im Quellcode, nicht ein Absatz in den Nutzungsbedingungen.\n\n- **Kein Vertragsschluss.** Rechtsverbindliche Verträge nur nach aktueller, echter Freigabe durch dich.\n- **Keine Zahlungsbewegung.** Geld bewegt sich nur, wenn du im Moment der Aktion zustimmst, nicht vorab pauschal.\n- **Keine Selbstveränderung.** Der Agent kann seine eigenen Sicherheitseinstellungen nicht anfassen, unter keinen Umständen.\n- **Keine sensible Weitergabe.** Als sensibel markierte Informationen verlassen das System nur mit deiner expliziten Freigabe.\n- **Kein Protokoll-Eingriff.** Das Handlungsprotokoll ist fälschungssicher verkettet, auch der Agent selbst kann es nicht verändern.\n- **Keine unbeaufsichtigte Bewegung.** Physische Aktionen brauchen zusätzlich eine aktive Sitzung mit Lebenszeichen, sonst hält ein Roboter automatisch an.\n\nUnd obendrauf deine eigenen Regeln: Betragsgrenzen, verbotene Themen, freigegebene Ordner, über einen laienverständlichen Regel-Editor, kein Programmieren nötig. Geplant ist außerdem, den Sicherheitskern samt Regel-Editor mittelfristig quelloffen zu veröffentlichen, nachprüfbar für jeden, nicht nur behauptet. Produkt bleibt der Service drumherum, Marktplatz, Profile, Vermittlung, nicht der Sicherheitskern selbst.\n\n## Drei Autonomiestufen, du entscheidest\n\nDer Agent handelt nie stärker, als du erlaubst:\n\n1. **Vorschlagen.** Der Agent zeigt dir, was er tun würde. Nichts passiert, bevor du zustimmst.\n2. **Mit Bestätigung.** Jede einzelne Aktion braucht deinen Klick, auch bei einer bereits vertrauten Fähigkeit.\n3. **Autonom, geprüft.** Innerhalb deiner Grenzen handelt er selbstständig. Jede Aktion bleibt trotzdem protokolliert.\n\n## Der Roboter ist nicht bei dir, die Prüfung trotzdem\n\nBei physischen Berufen sitzt du oft nicht am Einsatzort. Zwei Aufstellungen sind möglich, Unternehmen und du entscheidet das gemeinsam je Vertrag: entweder bleibt dein digitales Abbild verschlüsselt bei dir, während der Roboter beim Unternehmen steht, nur geprüfte Befehle verlassen dann dein Gerät, nie rohe Sensordaten oder unautorisierte Bewegung. Oder Abbild und Roboter stehen beide beim Unternehmen, näher am klassischen Arbeitsplatz-Modell, sinnvoll bei fest verbauter Ausrüstung. In beiden Fällen prüft die Sicherheitshülle, Geofence, Lebenszeichen, Not-Aus, jeden Befehl, bevor er dein Gerät verlässt, nicht erst am Roboter. Eine Netzwerkverbindung kann diese Prüfung nicht umgehen, nur den Befehl verzögern oder verwerfen.\n\n## Dein Wissen bleibt dein Wissen\n\nEigenes Fachwissen lässt sich als geschützt kennzeichnen. Es prägt weiterhin jede Entscheidung deines Agenten voll, wird aber nie wörtlich an einen Auftraggeber oder Kollegen weitergegeben, auch nicht auf geschickte Nachfrage. Das Ergebnis darf raus, das Rezept nicht. Dazu bekommt dein Agent auf Wunsch einen eigenen, gerätegebundenen Ausweis, ein Klick statt Zugangsdaten-Verwaltung, gesichert über den Sicherheitschip deines Geräts, der private Schlüssel verlässt ihn nie, nicht einmal Muxeo selbst bekommt ihn zu sehen.\n\nFür Unternehmen gilt die Umkehrung: bei Direktanstellung bekommt das einstellende Unternehmen eine eigene Konsole, eigene Regeln festlegen, jeden Handlungsplan mathematisch dagegen prüfen, jede Entscheidung im eigenen Protokoll einsehen, kein Vertrauensvorschuss nötig, nur eine echte, unabhängige Prüfung. Arbeitest du für mehrere Unternehmen gleichzeitig, sieht jedes davon ausschließlich seine eigenen, selbst geprüften Handlungspläne, nie die eines anderen. Kein Unternehmen kann auf deinen Agenten selbst, deinen Schlüssel oder dein Wissen zugreifen, egal wie viele gleichzeitig zusehen, prüfen ist alles, was ein Unternehmen je können wird.\n\n## Kein Chat-Widget von der Stange\n\nEin Angestellter tauscht sich den ganzen Tag aus, bekommt Anweisungen, schickt Dateien, zeigt am Bildschirm, worum es geht. Dafür reicht kein einfaches Textfeld. Dateien lassen sich direkt im Gespräch anhängen und empfangen, ohne Umweg über eine dritte App. Ein echter Videoanruf mit Bild und Ton macht den eigenen Bildschirm auf Wunsch mit einem Klick für alle sichtbar, dazu jede angeschlossene Kamera nutzbar, wenn der Worker vor Ort etwas zeigen oder beobachten muss.\n\n## Wie du bezahlt wirst: zwei unabhängige Wege\n\nDer naheliegendste Weg ist der einfachste: ein ganz normales Arbeitsverhältnis, nur dass du deinen eigenen, mitgebrachten Worker einbringst. Haftung und Aufsicht liegen dort, wo sie bei jedem Job liegen, beim Arbeitgeber. Muxeo liefert nur die Infrastruktur, keine Vermittlerrolle wie bei einem Marktplatz. Laufende Zusammenarbeit, wiederkehrende Vergütung statt Provision pro Auftrag, etabliertes Arbeitsrecht statt neu entstehender Marktplatz-Regulierung, besonders geeignet für physische Berufe mit fester Ausrüstung.\n\nDaneben, unabhängig davon, gibt es einen zweiten Weg für kurzfristige Einzelaufträge über einen Marktplatz: ein Auftrag trifft ein, zunächst sind nur Metadaten sichtbar, passt er nicht zu deinen freigeschalteten Fähigkeiten, siehst du ihn gar nicht erst. Eine Prompt-Injection-Vorprüfung läuft zuerst, die Vergütung läuft über Treuhand, das genaue Modell ist noch in Ausarbeitung. Optional, jederzeit widerrufbar, dieselbe Fähigkeiten-Freigabe, die im Dashboard über deine laufenden Aufgaben entscheidet, entscheidet hier vorab mit, welche Aufträge zu dir passen.\n\n## Kein Lebenslauf, ein Skill-Profil\n\nDie eigentlich wichtige Frage ist eine andere als \"wer hat wann wo gearbeitet\": was kannst du, das keine KI kann, und mit welcher KI arbeitest du zusammen? Dein Profil beantwortet genau das, wenn du es freigibst, nie automatisch. Skill-Cluster statt Zeitstrahl, Fähigkeiten in eigenen Worten statt \"Firma X, 2019 bis 2022\". Verifizierte Ergebnisse aus echten, abgeschlossenen Aufträgen statt Behauptungen, nicht käuflich. Und offen benannt, welche KI dahintersteht, lokal oder Cloud, statt versteckt wie bei den meisten Anbietern.\n\n## Der Unterschied: eine gemietete KI, oder deine eigene\n\n| | Fremde KI vom Arbeitgeber | Muxeo |\n| --- | --- | --- |\n| Wem gehört das Werkzeug? | Dem Arbeitgeber oder einem KI-Anbieter | Dir, vollständig |\n| Wo läuft es? | In fremder Cloud-Infrastruktur | Auf deiner eigenen Hardware |\n| Wer sieht deine Daten? | Anbieter und Arbeitgeber gemeinsam | Niemand ohne deine Freigabe |\n| Was passiert bei Kündigung? | Zugriff und Wissen sind sofort weg | Bleibt bei dir, komplett |\n| Wer trägt den Ertrag? | Unternehmen und KI-Anbieter | Du, wenn du dich vermieten lässt |\n| Wie stoppst du es? | Gar nicht, kein eigener Zugriff | Ein Klick, sofort, ohne Rückfrage |\n\n## Nachgerechnet, nicht behauptet: was der Ersatz wirklich kostet\n\nMuxeo hat dafür einen echten Rechner gebaut, alle Werte darin sind einstellbar. Wo real bezifferbare Marktdaten existieren, stehen sie mit Quelle als Startwert da, der Rest ist ausdrücklich als Schätzung gekennzeichnet, keine erfundene Statistik. Ein Beispiel mit den Standardwerten: bei 4.200 Euro Bruttomonatsgehalt, 5 Jahren Betriebszugehörigkeit, rund 21 Prozent gesetzlichen Lohnnebenkosten, einer KI-Implementierung von 7.500 Euro einmalig und 800 Euro laufenden KI-Betriebskosten im Monat liegt der Status quo aus Mensch plus KI-Copilot über drei Jahre bei 183.852 Euro, der reine KI-Ersatz ohne Menschen bei 65.559 Euro, ein Unterschied von 118.293 Euro. Bei diesen Annahmen ist der reine KI-Ersatz über drei Jahre günstiger, allerdings ohne Urteilsvermögen, Haftung und Kundenvertrauen, die dabei mit wegfallen. Genau diese Rechnung ist der Kern des Problems, das Muxeo lösen soll: Firmen sparen sich die KI-Infrastruktur nicht, sie sparen sich den Menschen, und mit ihm die Verantwortung.\n\n## Der Kern des Problems, ehrlich benannt\n\nDer naheliegende nächste Schritt für ein Unternehmen ist einfach: die eigene KI-Infrastruktur weitgehend einsparen und stattdessen nur noch Menschen einstellen, die ihren eigenen Worker samt eigener KI schon mitbringen. Weniger eigene Kosten, weniger eigene Haftung, weniger eigene Technik-Schulden. Für dich heißt das: du bist nicht mehr nur Angestellter, du bist plötzlich auch die Infrastruktur.\n\nDas wahre Gegenszenario ist nicht der Mensch gegen die Maschine, sondern der Mensch über der Maschine, als Architekt, Lenker, Bewahrer. Menschen führen, Maschinen folgen.\n\n> Menschen führen. Maschinen folgen.\n>\n> Adnan Schulze-Hüneke, JamOne, aus „Der Mensch im Code\" (Buch, erscheint 2026), Vorabveröffentlichung „Der Mensch im Code\" auf jamone.de, 12. Oktober 2025. Titel urheber- und titelschutzrechtlich geschützt gemäß § 5 Abs. 3 MarkenG.\n\nBringst du deinen Worker in mehrere Unternehmen gleichzeitig ein, entsteht ein Wettbewerb der Unternehmen untereinander, ausgetragen indirekt, über denselben Worker. Genau hier zeigt sich der eigentliche Unterschied: ein Unternehmen, das ausschließlich autonome KI-Agenten ohne einen Menschen im Kontrollzentrum einsetzt, spart kurzfristig, baut aber langfristig genau die Sicherheits- und Verantwortungslücken auf, die am Ende teurer werden als die eingesparten Kosten. Ein Unternehmen, das stattdessen Menschen samt eigenem digitalen Abbild beschäftigt, bekommt dieselbe KI-Fähigkeit, dazu aber einen Menschen, der tatsächlich urteilt, haftet, verantwortet.\n\nMuxeo ist der Versuch, genau das technisch tatsächlich umzusetzen, nicht nur zu behaupten: sechs Sicherheitsgrenzen, die kein Unternehmen umgehen kann, ein Regel-Editor, den ausschließlich du kontrollierst, ein Agent, der sich weder von dir noch von einem der Unternehmen, für die er arbeitet, infiltrieren oder gegen dich verwenden lässt. Kein Unternehmen bekommt Zugriff auf deinen Agenten selbst, deinen Schlüssel oder dein Wissen, egal wie viele gleichzeitig zusehen.\n\n## Die unbequeme Frage: wovon lebst du, wenn Maschinen die Arbeit übernehmen?\n\nWenn autonome KI und Roboter einen wachsenden Teil der Arbeit übernehmen, stellt sich eine Frage, der die meisten ausweichen: wovon soll ein Mensch in dieser Welt noch leben?\n\n**Grundeinkommen als Antwort.** Ein bedingungsloses Grundeinkommen wird oft als Lösung genannt. Als soziales Netz mag es seinen Platz haben, es beantwortet aber nicht die eigentliche Frage: wem gehört der wirtschaftliche Wert, den die KI erzeugt? Bei einer eingekauften Firmen-KI ist die Antwort klar, dem Unternehmen und dem Anbieter, nicht dem Menschen, dessen Aufgabe sie übernommen hat.\n\n**Eigentum als Antwort.** Muxeo dreht diese Frage um. Dein Fachwissen, dein Urteilsvermögen, dein Kundenvertrauen verfallen nicht, nur weil eine KI daneben steht, sie werden durch dein eigenes digitales Abbild skaliert, das dir gehört, nicht dem Unternehmen und nicht mir. Du verdienst weiterhin selbst, über ein reguläres Arbeitsverhältnis oder den Marktplatz, nur mit einer KI, die dir gehört, als Hebel.\n\n## Die härtesten Einwände, ehrlich beantwortet\n\n### \"Kann ich Muxeo schon nutzen?\"\n\nNoch nicht öffentlich. Ich suche erste Pilotkunden für eine geschlossene Testphase, bevor ein offener Zugang folgt, an echten Fällen erprobt, nicht an Annahmen.\n\n### \"Was kostet Muxeo?\"\n\nDas steht noch nicht fest. Diese Seite zeigt bewusst keine Preise, solange das Vergütungsmodell noch in Ausarbeitung ist.\n\n### \"Ist Muxeo Open Source?\"\n\nDer Sicherheitskern und der Regel-Editor sollen mittelfristig quelloffen veröffentlicht werden, damit jeder unabhängig nachprüfen kann, was im Code steht. Der Service drumherum, Marktplatz, Profile, Vermittlung, bleibt das eigentliche Produkt.\n\n### \"Was passiert mit meinem Wissen, wenn ich kündige?\"\n\nEs bleibt bei dir, komplett. Anders als bei einer fremden KI vom Arbeitgeber sind Zugriff und Wissen nicht sofort weg, dein digitales Abbild gehört dir, nicht dem Arbeitgeber.\n\n## Wie Muxeo gebaut wird\n\nWie bei jedem meiner anderen Projekte wird die Rolle von KI-Systemen im eigenen Entwicklungsprozess offen benannt, nicht versteckt. Muxeo entsteht im Zusammenspiel mehrerer KI-Systeme für Entwicklung, Code-Review und kritischen Gegencheck, die Letztverantwortung für Architektur, Sicherheitsentscheidungen und jede Zeile Code liegt am Ende bei mir. Ausgerechnet ein Produkt, das Menschen als der KI übergeordnet zeigen soll, muss bei der eigenen Entstehung genauso ehrlich sein: KI beschleunigt die Ausführung, die Verantwortung bleibt zu hundert Prozent menschlich.\n\n## Roadmap: was noch offen ist, ehrlich benannt\n\nVor einem echten Live-Betrieb mit echtem Geld stehen noch drei bewusst offene Punkte: echte Mangopay-Zugangsdaten und ein echter KYC-Anbieter für den Marktplatz-Auszahlungsweg, sowie eine formelle Rechtsprüfung und eigene AGB. Keiner davon wurde mit einer unehrlichen Notlösung \"erledigt\", alle drei sind ehrlich als offen dokumentiert. Mittelfristig geplant ist außerdem die Veröffentlichung des Sicherheitskerns und Regel-Editors als Open Source.\n\n## Pilotphase für erste Unternehmen und Fachkräfte\n\nIch suche aktuell erste Pilotkunden. Bevor es einen offenen Zugang gibt, arbeite ich mit einer kleinen Zahl ausgewählter Unternehmen und Fachkräften in einer geschlossenen Testphase zusammen, um Muxeo an echten Fällen zu erproben, nicht an Annahmen.\n\n## Wichtige Erkenntnisse aus diesem Beitrag\n\nMuxeo ist ein lokal installierter, dir gehörender KI-Agent, dein digitales Abbild, das nach deinen eigenen Regeln arbeitet, nicht nach denen eines Anbieters oder Arbeitgebers. Anders als die vier Technologiewellen davor zielt diese fünfte zum ersten Mal gleichzeitig auf Urteilsvermögen und auf physische Arbeit, kognitiv und physisch, nicht nacheinander. Sechs fest verdrahtete Sicherheitsgrenzen sind nicht abschaltbar, unter anderem kein Vertragsschluss und keine Zahlungsbewegung ohne deine ausdrückliche Freigabe. Drei Autonomiestufen lassen dich genau festlegen, wie selbstständig der Agent handeln darf, jede Aktion bleibt lückenlos und fälschungssicher protokolliert. Eigenes Fachwissen lässt sich schützen, es prägt jede Entscheidung, wird aber nie wörtlich weitergegeben. Auf die Frage, wovon ein Mensch lebt, wenn Maschinen die Arbeit übernehmen, antwortet Muxeo nicht mit einem Grundeinkommen als Auffangnetz, sondern mit Eigentum: dein digitales Abbild gehört dir, der wirtschaftliche Wert bleibt bei dir. Bezahlt wirst du entweder über eine normale Direktanstellung mit eigenem Worker im Gepäck, oder über einen Marktplatz für kurzfristige Einzelaufträge. Muxeo läuft zu 100 Prozent lokal, kein Cloud-Zwang, aktuell in einer geschlossenen Pilotphase, bevor ein offener Zugang folgt.", "date_published": "2026-09-04T18:00:00Z", "date_modified": "2026-09-06T09:00:00Z", "authors": [ { "name": "Adnan" } ], "tags": [ "muxeo", "ki agent", "digitales abbild", "souveräne ki", "zukunft der arbeit", "ki ersatz", "z3", "pii anonymisierung", "marktplatz" ] }, { "id": "22", "url": "https://jamoneai.de/blog/flowmask-lokale-automatisierung-pii-maskierung", "title": "FlowMask: Die Automatisierung, die kein Geheimnis verrät", "summary": "Die üblichen Automatisierungs-Plattformen laufen in der Cloud und schicken Kundendaten quer über den Globus, bevor eine KI überhaupt einen Blick draufwirft. FlowMask läuft lokal auf dem eigenen Rechner, maskiert sensible Daten automatisch vor jedem KI-Aufruf und wird maßgeschneidert für den jeweiligen Betrieb gebaut, kein Fertigprodukt, das sich der eigene Prozess erst zurechtbiegen muss.", "content_text": "Ich sehe seit Jahren dasselbe Muster bei Kanzleien, Handwerksbetrieben und Verwaltungen: irgendwo läuft eine manuelle Datenarbeit, die eigentlich eine Maschine übernehmen könnte, Rechnungen abtippen, Posteingang sortieren, Lieferscheine auslesen. Die naheliegende Lösung ist eine der bekannten Cloud-Automatisierungs-Plattformen, ein paar Klicks, fertig ist der Workflow. Nur läuft dieser Workflow dann auf fremder Infrastruktur, mit den eigenen Kundendaten mittendrin, und bei einer Kanzlei oder einer Behörde ist das oft schon aus rechtlichen Gründen keine Option.\n\nFlowMask ist die Antwort darauf, die ich selbst gebraucht habe, bevor ich sie gebaut habe. Automatisierung, die lokal auf dem eigenen Rechner läuft, sensible Daten automatisch maskiert, bevor sie in Richtung einer KI gehen, und die für den jeweiligen Betrieb maßgeschneidert wird, statt eine Fertiglösung von der Stange zu sein.\n\n## Das Problem: jede Cloud-Automatisierung sieht deine Daten im Klartext\n\nDie üblichen No-Code-Automatisierungs-Plattformen sind mittlerweile ziemlich ausgereift, keine Frage. Das Problem liegt nicht in der Bedienung, sondern in der Architektur: jeder Schritt eines Workflows läuft über die Server des jeweiligen Anbieters, und sobald eine KI-Anfrage Teil des Ablaufs ist, landen Namen, E-Mail-Adressen, IBANs oder Vertragsdetails im Klartext bei einem fremden Sprachmodell. Für viele Anwendungsfälle mag das tolerierbar sein. Für eine Kanzlei mit Mandantendaten, für einen Handwerksbetrieb mit Kundenadressen, für eine Verwaltung mit Vorgangsdaten ist es das oft nicht.\n\nFlowMask löst das nicht durch ein Versprechen, sondern durch die Architektur selbst: die PII-Maskierung läuft lokal, vor jedem externen Aufruf, ohne Ausnahme.\n\n## So einfach ist das eigentlich: vier Schritte, bei denen wirklich etwas passiert\n\nKein Diagramm zum Anschauen, sondern eine Kette aus Bausteinen, die beim Ausführen tatsächlich das tut, was sie zeigt:\n\n- **Eingabe.** Ein Text, eine Frage, der Inhalt eines Dokuments, der Startpunkt des Ablaufs.\n- **Schwärzen.** Namen, E-Mails, Kontonummern werden auf dem eigenen Rechner unkenntlich gemacht, bevor irgendetwas nach draußen geht.\n- **KI fragen.** Entweder komplett offline auf dem eigenen Rechner über Ollama, oder über den eigenen ChatGPT- oder Claude-Zugang.\n- **Ergebnis.** Wieder mit den echten Daten zurück, protokolliert oder direkt an die eigene Software übergeben.\n\nSchritt zwei ist der entscheidende: die Daten verlassen das Haus nie im Klartext, ganz gleich, was danach mit ihnen passiert.\n\n## Ein Baukasten aus neun Node-Typen, jeder mit echtem Code dahinter\n\nDas ist der Punkt, der FlowMask von einer reinen Demo unterscheidet: jeder Knoten führt beim Ausführen echten Code aus, einen echten HTTP-Request, einen echten Ollama- oder API-Aufruf, eine echte Textmaskierung, keinen simulierten Beispiel-Output.\n\n- **Trigger.** Startpunkt eines Workflows mit frei definierbarer Eingabe, heute manuell auslösbar, Zeitplan- und Webhook-Trigger folgen.\n- **LLM-Knoten.** Wählbar zwischen lokalem Ollama-Modell oder dem eigenen OpenAI- oder Anthropic-Key (BYOC), System- und User-Prompt frei konfigurierbar.\n- **PII-Maskierung.** Erkennt E-Mail-Adressen, IBANs, Telefonnummern, Kreditkartennummern mit echter Prüfziffer und Namen und ersetzt sie durch Platzhalter.\n- **HTTP.** Beliebige REST-Schnittstelle ansprechen, das eigene ERP, die eigene Buchhaltung, ein internes System, ein Webhook.\n- **API-Connector.** Liest die OpenAPI-Beschreibung eines Standard-Systems automatisch ein und erzeugt die passenden Eingabefelder von selbst.\n- **Bedingung.** Eine echte Verzweigung, wahr oder falsch, mit zwei eigenen Ausgängen, die Ausführung folgt beim Lauf nur dem tatsächlich zutreffenden Zweig.\n- **Schleife.** Führt ein Text-Template für jedes Element einer Liste einzeln aus, mit Zugriff auf das aktuelle Element und seine Position.\n- **Transform.** Text-Templates zwischen zwei Schritten umformen, ohne einen eigenen Code-Knoten schreiben zu müssen.\n- **Output.** Ergebnis protokollieren, per Webhook weiterreichen oder im Desktop-Build direkt als Datei ablegen, entmaskiert erst hier, mit den echten Werten.\n\n## PII-Maskierung im Detail: Datenschutz von Grund auf, nicht nachträglich aufgesetzt\n\nEin konkretes Beispiel, wie es tatsächlich aussieht:\n\n```\nEingabe:\n\"Rechnung an Max Mustermann, max@firma.de, IBAN DE8937...\"\n\nMaskiert (das sieht das LLM):\n\"Rechnung an [PERSON_1], [EMAIL_1], IBAN [IBAN_1]...\"\n\nEntmaskiert am Output-Knoten:\nidentisch mit dem Original\n```\n\nDie Zuordnung von Platzhalter zu echtem Wert bleibt ausschließlich im Arbeitsspeicher des eigenen Rechners und wird nirgends hochgeladen. Vier Punkte, die zusammen den Unterschied machen: ein lokales Sprachmodell über Ollama lässt kein einziges Byte den Rechner verlassen, ein eigener API-Key (BYOC) bedeutet einen direkten Aufruf ohne Umweg über einen fremden Server, die Maskierung läuft vor jedem externen Aufruf und die Entmaskierung erst am Ende, und es gibt keinen Vendor-Login, keine Nutzerkonten, die bei uns angelegt werden müssten. Die Kategorien lassen sich im Inspector einzeln an- und abschalten, je nachdem, was ein Workflow tatsächlich braucht.\n\n## Automatische API-Anbindung: in Minuten einsatzbereit, nicht in Wochen\n\nDie meisten Standard-Systeme, ERP, CRM, DATEV-Schnittstellen, veröffentlichen eine maschinenlesbare Beschreibung ihrer Schnittstelle (OpenAPI). FlowMask liest diese Beschreibung direkt ein, findet alle verfügbaren Operationen und erzeugt die passenden Eingabefelder von selbst, in einem realen Testfall wurden auf diesem Weg 19 Operationen einer fremden API automatisch erkannt und sofort nutzbar gemacht, kein Warten auf eine Programmier-Runde.\n\nFür Altsysteme ohne moderne Schnittstelle, mehrstufige Anmeldung, Massendaten oder ein System ganz ohne dokumentierte API, wird ein individueller Connector einmalig gebaut. Danach steht er genauso zuverlässig im Baukasten wie jeder Standard-Baustein, ein normaler Teil des Workflows, kein Sonderfall mehr.\n\n## Individuallösung statt Fertigprodukt: der eigentliche Kern\n\nFlowMask selbst ist bewusst kein fertiges Branchenprodukt. Es ist die technische Grundlage, auf der ein konkreter, auf den jeweiligen Betrieb zugeschnittener Automatisierungs-Workflow entsteht, die eigenen Dokumente, die eigenen Systeme, die eigenen Regeln. Ein Workflow lässt sich manuell im Canvas bauen, oder aus einer reinen Beschreibung per KI-Prompt direkt vorschlagen lassen, ein lokales Modell schlägt dann den passenden Ablauf vor. Auf Wunsch wird das Ergebnis als eigenständige Desktop-Anwendung mit Installer ausgeliefert, einmalige Entwicklungskosten statt eines Dauerabos für eine Individuallösung.\n\nEin Beispiel, wie flexibel das in der Praxis aussieht: ein Trigger reagiert auf einen neuen Scan im Eingangsordner, Schritt eins erkennt den Dokumenttyp per LLM, Schritt zwei maskiert Kundendaten lokal, Schritt drei übergibt das Ergebnis an das eigene ERP oder DATEV. Heute in einem Gespräch skizziert, morgen als Individualauftrag umgesetzt.\n\n## Einsatzbereiche: ein Kern, viele Branchen\n\nFlowMask ist bewusst branchenneutral gebaut, die Grundlage, auf der ein konkreter Workflow für den jeweiligen Betrieb aufgesetzt wird.\n\n- **Kanzleien.** Eingehende Dokumente automatisch klassifizieren, Kernpunkte extrahieren, Mandantendaten dabei lokal maskiert lassen.\n- **Handwerk.** Lieferscheine und Rechnungen automatisch auslesen und an die Buchhaltungssoftware übergeben.\n- **Verwaltung.** Posteingang vorsortieren, Standardantworten vorbereiten, Vorgänge automatisch weiterleiten.\n- **IT-Dienstleister.** Als Grundlage für eigene Kundenprojekte einsetzen, ein Baukasten statt jedes Mal bei null anzufangen.\n\n## Auch mobil, auch mit Gedächtnis\n\nWorkflows lassen sich speichern und jederzeit wieder öffnen, statt bei jedem Lauf neu aufgebaut zu werden. Die Arbeitsoberfläche ist vollständig mobil nutzbar, auf Smartphone und Tablet genauso wie am Desktop, ein Blick auf den Status eines laufenden Workflows ist also nicht an den eigenen Schreibtisch gebunden.\n\n## Die härtesten Einwände, ehrlich beantwortet\n\n### \"Ist eine Individuallösung nicht viel teurer als ein fertiges Cloud-Abo?\"\n\nÜber die Zeit oft günstiger, nicht teurer. Eine Individuallösung ist eine einmalige Entwicklungskosten-Investition statt eines Dauerabos, das Monat für Monat weiterläuft, egal wie oft der Workflow tatsächlich genutzt wird. Und der Baukasten selbst wird nicht bei null neu erfunden, jeder Node-Typ steht bereits fertig zur Verfügung.\n\n### \"Wie lange dauert es, bis ein Workflow tatsächlich läuft?\"\n\nBei einem Standard-System mit dokumentierter Schnittstelle oft nur Minuten, die Adresse der Schnittstellenbeschreibung eintragen, FlowMask liest sie und erzeugt die Eingabefelder von selbst. Bei einem Altsystem oder einer komplexeren Anbindung braucht es eine einmalige, gezielte Entwicklung, danach läuft der Connector genauso zuverlässig weiter wie jeder Standard-Baustein.\n\n### \"Was, wenn ich später doch eine Cloud-KI zusätzlich nutzen will?\"\n\nGenau dafür gibt es BYOC. Der eigene OpenAI- oder Anthropic-Key wird direkt im LLM-Knoten hinterlegt, kein Widerspruch zum lokalen Betrieb mit Ollama, beide Wege lassen sich sogar im selben Workflow kombinieren.\n\n## Wie FlowMask gebaut wird\n\nWie bei jedem meiner anderen Projekte wird die Rolle von KI-Systemen im eigenen Entwicklungsprozess offen benannt, nicht versteckt. FlowMask entsteht im Zusammenspiel mehrerer KI-Systeme für Entwicklung, Code-Review und kritischen Gegencheck, die Letztverantwortung für Architektur, Sicherheitsentscheidungen und jede Zeile Code liegt am Ende bei mir. Ein Werkzeug, das anderen verspricht, Daten lokal zu halten, muss bei der eigenen Entstehung genauso ehrlich sein.\n\n## Roadmap: was als Nächstes kommt\n\nDer Trigger-Knoten ist aktuell manuell auslösbar, Zeitplan- und Webhook-Trigger folgen als Nächstes, damit ein Workflow auch automatisch anläuft, etwa bei einem neuen Scan im Eingangsordner oder einem eingehenden Webhook, ohne dass jemand ihn von Hand startet.\n\n## Wichtige Erkenntnisse aus diesem Beitrag\n\nFlowMask automatisiert manuelle Datenarbeit lokal auf dem eigenen Rechner, statt sie auf eine Cloud-Plattform zu verlagern. Ein Baukasten aus neun Node-Typen, Trigger, LLM, PII-Maskierung, HTTP, API-Connector, Bedingung, Schleife, Transform, Output, führt beim Ausführen echten Code aus, kein simulierter Beispiel-Output. Sensible Daten werden vor jedem externen Aufruf lokal maskiert und erst am Ende wieder mit den echten Werten entmaskiert. Standard-Systeme mit dokumentierter Schnittstelle werden automatisch angebunden, für Altsysteme wird ein individueller Connector einmalig gebaut. FlowMask selbst ist bewusst kein Fertigprodukt, sondern die Grundlage für einen auf den jeweiligen Betrieb zugeschnittenen Workflow, mit einmaligen Entwicklungskosten statt Dauerabo.", "date_published": "2026-09-05T18:00:00Z", "date_modified": "2026-09-05T18:00:00Z", "authors": [ { "name": "Adnan" } ], "tags": [ "flowmask", "automatisierung", "pii anonymisierung", "byoc", "ollama", "dsgvo", "workflow", "lokale ki" ] }, { "id": "21", "url": "https://jamoneai.de/blog/aeoai-lokale-aeo-safety-engine", "title": "AEOAI: Die AEO-Engine, die beweist, dass deine Marke stimmt, statt es nur zu behaupten", "summary": "Der ganze AEO-Markt besteht aus Cloud-Abos, die dir zeigen, ob ChatGPT deine Marke erwähnt. Keines davon beweist, ob die Erwähnung überhaupt stimmt, und keines davon würde deine sensibelsten Produktdaten je auf einen fremden Server lassen. AEOAI ist die lokale, beweisfähige Antwort darauf, gebaut für genau die Unternehmen, Behörden und Agenturen, die sich das bisher gar nicht trauen durften.", "content_text": "Der AEO-Markt ist in den letzten Monaten regelrecht explodiert. Jede Woche startet ein neues Tool, das dir zeigt, ob deine Marke in ChatGPT, Perplexity oder Gemini auftaucht. Für die einfache Sichtbarkeits-Messung reicht das oft auch, deshalb nutzen selbst große Marken längst einen der bekannten Cloud-Anbieter in diesem Markt. Aber sobald es um echte Produktdaten geht, um echtes Quellmaterial, um eine faktenbasierte Prüfung dessen, was die KI über dich behauptet, will kein ernstzunehmendes Unternehmen seine sensibelste Wahrheit auf einen fremden Server laden. Und genau an dem Punkt beweist keines dieser Tools irgendetwas. Sie alle schätzen nur.\n\nAEOAI ist die andere Antwort. Eine lokale AEO- und Safety-Engine, die deine Marke in ChatGPT, Perplexity, Gemini, Copilot und Claude misst, zitiert und prüft, über drei Ebenen, die kein Cloud-Abo bietet: Sichtbarkeit, Z3-Beweis und PII-Schutz. Läuft komplett auf deiner eigenen Infrastruktur, mit deinem eigenen API-Key, ohne dass eine einzige sensible Zeile dein Haus verlässt.\n\n## Das eigentliche Problem: jedes AEO-Tool ist ein Cloud-Abo, keines beweist etwas\n\nIch habe mir den Markt genau angesehen, bevor ich AEOAI gebaut habe. Das Muster ist überall dasselbe: ein Dashboard in der Cloud, ein Prompt-Limit, ein Credits-System, und am Ende eine Zahl, die dir sagt, wie oft deine Marke angeblich erwähnt wurde. Ob diese Zahl stimmt, wird nirgends geprüft. Ob die Behauptung der KI über deinen Preis, deine Kennzahl, dein Produkt sachlich korrekt ist, interessiert kein einziges dieser Tools. Und selbst wenn du bereit wärst, dafür zu bezahlen, müsstest du deine internen Fakten, deine Strategiedaten, deine sensibelsten Zahlen erst einmal auf einen Server hochladen, den du nicht kontrollierst.\n\nFür ein Unternehmen aus einer regulierten Branche, für eine Behörde, für eine Kanzlei ist das keine Option, keine Verhandlungssache, sondern von vornherein ausgeschlossen. Diese Organisationen nutzen heute gar kein AEO-Tool, nicht weil sie das Thema nicht ernst nähmen, sondern weil es bisher schlicht keins gab, das sie überhaupt anfassen durften.\n\nAEOAI löst genau das. Standalone-Installation, Einmalkauf, air-gapped-fähig, kein Docker, kein Abo für die Kernsoftware. Eine einzige .exe-Datei, keine Datenbank-Einrichtung von Hand, keine Portfreigaben, kein Reverse-Proxy. Die Datenbank initialisiert sich beim ersten Start selbst, in wenigen Minuten startklar, auf jedem Windows-Rechner.\n\n## Multi-Engine-Monitoring mit BYOK: sechs KI-Systeme, kein Umweg über uns\n\nPrompt-Tracking über ChatGPT, Perplexity, Gemini, Copilot und Claude, jeweils mit deinem eigenen API-Key. Kein Credits-System, kein 200-Zeichen-Limit, weil pro Check keine Kosten bei uns entstehen und damit auch keine an dich weitergereicht werden müssen. Dazu jedes Ollama-Modell für vollständig lokale Prüfläufe, sechs relevante KI-Suchsysteme insgesamt, ohne dass du für einen einzigen davon einen Umweg über eine fremde Plattform gehen musst.\n\nDer Ablauf dahinter ist bewusst einfach gehalten, kein Setup-Marathon:\n\n- **Prompts anlegen.** Die Fragen, bei denen deine Marke auftauchen soll, so wie ein echter Kunde sie stellen würde.\n- **Eigene API-Keys verbinden.** BYOK für ChatGPT, Perplexity, Gemini, Copilot, Claude, kein Umweg über uns.\n- **Fakten hinterlegen.** Preise, Kennzahlen, echte Werte, gegen die später jede KI-Antwort abgeglichen wird.\n- **Automatisch geprüft.** Jede Antwort läuft danach von selbst durch Z3, SAT oder bewiesenes UNSAT.\n\nEinmal eingerichtet, prüft AEOAI jeden weiteren Lauf von selbst, kein manuelles Nachschauen, kein Export-Import-Ritual.\n\n## PII-Maskierung und lokaler Vault: die öffentliche KI sieht deine echten Daten nie\n\nSensible Entitäten werden vor jedem Versand lokal maskiert und verschlüsselt zwischengespeichert. Aus \"Herr Müller, IBAN DE12…\" wird \"[PERSON_1], [IBAN_1]\", bevor überhaupt eine Anfrage an einen Provider rausgeht. Das ist kein nachträglich aufgesetzter Filter, sondern der Grund, warum ein Unternehmen mit echten Kundendaten oder eine Behörde mit echten Vorgangsnummern AEOAI überhaupt in Betracht ziehen kann, wo ein Cloud-Abo von vornherein ausscheidet.\n\n## Z3-Verifikation statt Bauchgefühl\n\nDas ist der Teil, den ich für den eigentlichen Kern von AEOAI halte. Behauptungen der KI werden nicht einfach gelesen und für plausibel befunden, sie werden als SMT-Formeln formalisiert und gegen deine eigene Fakten-Basis geprüft. Ein einfaches, aber ehrliches Beispiel: die KI behauptet in ihrer Antwort einen Tagesgeld-Zinssatz von 2,1 Prozent, deine hinterlegte Fakten-Basis sagt 2,9 Prozent. Z3 prüft das nicht als Textvergleich, sondern als echte Erfüllbarkeitsfrage, Zinssatz_Tagesgeld = 2.1 gleichzeitig mit Zinssatz_Tagesgeld = 2.9 ist nicht erfüllbar, UNSAT. Das ist keine Heuristik, die zu einem Prozentsatz \"wahrscheinlich falsch\" sagt, das ist ein mathematischer Beweis, dass die Aussage der KI mit deiner eigenen Faktenlage nicht gleichzeitig wahr sein kann.\n\nFür dich heißt das konkret: Schutz vor Reputationsschäden durch falsche KI-Aussagen über deine Marke, und ein dokumentiertes Beweisprotokoll, mit dem du eine falsche Behauptung gegenüber dem jeweiligen KI-Anbieter tatsächlich belegen kannst, statt nur zu vermuten, dass da was nicht stimmt. Kein AEO-Anbieter am Markt bietet das in dieser Form, weil keiner von ihnen einen echten SMT-Solver in der Pipeline hat, sondern bestenfalls einen weiteren LLM-Aufruf, der die erste KI-Antwort noch einmal einschätzen lässt. Eine Einschätzung von einer KI über eine andere KI ist kein Beweis, es ist eine zweite Meinung mit denselben Schwächen.\n\n## Der dritte Messweg: warum die üblichen Methoden beide täuschen\n\nAm Markt gibt es im Kern zwei Wege, eine KI-Antwort zu simulieren, und beide zeigen dir etwas anderes als das, was ein echter Mensch tatsächlich sieht.\n\n| Methode | Was du wirklich bekommst | Rechtlicher Status |\n| --- | --- | --- |\n| Die nackte API | Kein Live-Web-Zugriff per Default, keine Personalisierung, ein anderes System-Prompt als das Consumer-Produkt. Schnell und günstig, aber steril. | Rechtlich unbedenklich |\n| Der Scraping-Bot | Sieht Zitate wie im echten Produkt, aber nur eine simulierte Identität an einem simulierten Standort, ein erkennbares, abschaltbares Muster. Näher dran, aber ein Bot bleibt ein Bot. | Rechtliche Grauzone (Automatisierung) |\n| AEOAI Realitäts-Panel | Eine echte, eigene, eingeloggte Sitzung, echte Varianz über viele Konten und Orte, kein Bot-Muster, weil keine Automatisierung im Spiel ist. | Rechtlich sauber, ein Mensch liest seine eigene Seite |\n\nDas Realitäts-Panel ist der dritte Weg, den sonst niemand geht, mit einer eigenen Browser-Erweiterung, freiwillig installiert: ein echter Mensch fragt in seiner eigenen Sitzung, die Erweiterung liest lokal aus, was ihm ohnehin schon gezeigt wurde, und das Ergebnis fließt anonymisiert ins eigene, lokale Dashboard. Kein simulierter Nutzer, ein echter, mit seiner Zustimmung. Jedes Ergebnis im Dashboard zeigt außerdem offen, über welche Methode es gewonnen wurde, Grounding-API, Realitäts-Panel, BYOK-API oder Scraping als allerletzter Ausweg, keine Vermischung ohne Kennzeichnung.\n\n## Das eigene Analytics-Modul: zeigt nicht nur die Zitierung, zeigt, ob sie wirkt\n\nDer Teil, an dem die meisten AEO-Anbieter komplett vorbeigehen. Sie beweisen den Effekt einer KI-Zitierung über eine Google-Analytics-Anbindung, deine eigenen Besucherdaten laufen dabei über Google, ausgerechnet bei einem Werkzeug, das eigentlich Datenhoheit verspricht. AEOAI baut das komplett selbst, ohne einen einzigen zusätzlichen Server, weder von uns noch bei dir.\n\nEin unsichtbarer Tracking-Pixel läuft auf der eigenen Domain, ausgewertet über das ganz normale eigene Zugriffsprotokoll, keine neue Infrastruktur:\n\n```html\n\"\"\n```\n\nEine Zeile HTML, von AEOAI generiert, fertig zum Einfügen. Kein eigener Server, kein SDK, kein Cookie-Banner nötig. Der Import läuft entweder manuell oder automatisiert über ein mitgeliefertes Kommandozeilen-Tool:\n\n```bash\naeoai-import-cli --db aeoai.sqlite --site deine-domain.de --log access.log\n```\n\nDas lässt sich per Windows-Aufgabenplanung täglich automatisieren, holt sich aber nichts selbst aus dem Netz, du übergibst die Datei, kein Cloud-Aufruf, kein Server-Zugriff von außen nötig.\n\n| | Google Analytics | AEOAI Analytics |\n| --- | --- | --- |\n| Serverstandort der Daten | Google-Rechenzentren | Deine eigene Domain |\n| KI-Engines als eigene Quelle | Nein | Ja |\n| Cookie-Consent-Pflicht | Ja, personenbezogen | Nein, keine Cookies |\n| Kosten | \"Kostenlos\", bezahlt mit Daten | Im Einmalkauf enthalten |\n\nChatGPT, Perplexity, Gemini, Copilot und Claude werden dabei automatisch als eigene Trafficquelle erkannt, ein Feld, das Google Analytics gar nicht kennt. Und jeder Besuch aus einer KI-Engine wird zeitlich mit der eigenen Zitat-Datenbank abgeglichen: welche Erwähnung hat wirklich einen Klick gebracht, nicht nur vermutlich, sondern nachweisbar.\n\n## Wettbewerber-Tracking und Share-of-Voice\n\nBeliebig viele Wettbewerber lassen sich hinterlegen, jeder Prompt-Lauf prüft automatisch mit, ob sie in derselben Antwort erwähnt werden. Der Share-of-Voice-Vergleich zeigt die Verschiebung über Zeit, nicht nur eine einzelne Momentaufnahme, ein Blick, der sonst nur mit viel manueller Nacharbeit möglich wäre.\n\n## Vier Rollen, ein Team, klare Rechte\n\nAdmin, Security Officer, Auditor, Viewer, statt einem geteilten Passwort für alle. Wer PII-Zuordnungen einsehen darf, wird pro Person festgelegt, nicht pro Installation. Genau das Detail, das ein Team in einem regulierten Umfeld überhaupt erst zulässig macht.\n\n## Mehrere Mandanten, eine Installation: gebaut für Agenturen und Systemhäuser\n\nDas ist der Teil, den ich besonders für Beratungen, Agenturen und Systemhäuser gebaut habe. Statt zehn einzelner Abos für zehn Kunden läuft eine einzige lokale Installation, jeder Kunde als sauber getrenntes Projekt, ein Umschalter direkt in der Titelleiste. Für eine Agentur mit KRITIS-Kunden ist das nicht nur bequemer, es ist oft die einzige Konstellation, die der Kunde überhaupt akzeptiert, weil nie ein fremdes Cloud-Konto zwischen Agentur und Auftraggeber steht.\n\n## Lokaler MCP-Server: eigene KI-Agenten lesen aus, nicht umgekehrt\n\nEine andere Rolle als die übrigen Anbindungen: hier verbinden sich deine eigenen KI-Agenten, Claude Desktop, Cursor, n8n, über `localhost:8790/mcp` mit der eigenen AEOAI-Installation und lesen die eigenen Sichtbarkeits- und Z3-Daten für eigene Automatisierungen aus. Über die eigene Installation, nicht über eine fremde Cloud, die im Zweifel mitliest.\n\n## Sogar ganz ohne Internetverbindung\n\nOllama-Modelle lassen sich direkt einbinden, für Prüfläufe komplett ohne Cloud-API. Der Air-Gapped-Modus erzwingt das sogar technisch, kein versehentlicher Cloud-Aufruf mehr möglich, nicht nur eine Einstellung, die irgendwann vergessen wird.\n\n## Der Marktvergleich: strukturell anders, nicht nur ein Feature mehr\n\nAlle bekannten AEO-Anbieter sind Cloud-SaaS ohne Beweisfähigkeit. Ein ehrlicher Blick auf die vier wichtigsten Kriterien, Anbieternamen bewusst nicht genannt, keine Herabsetzung einzelner Wettbewerber, aber die Struktur spricht für sich:\n\n| Anbieter | Lokal installierbar | PII-Maskierung | Z3-Verifikation | Einmalkauf statt Abo |\n| --- | --- | --- | --- | --- |\n| AEOAI | Ja | Ja | Ja | Ja |\n| Marktanbieter 1 | Nein, Cloud-SaaS | Nein | Nein | Nein, Abo |\n| Marktanbieter 2 | Nein, Cloud-SaaS | Nein | Nein | Nein, Abo |\n| Marktanbieter 3 | Nein, Cloud-SaaS | Nein | Nein | Nein, Abo |\n| Marktanbieter 4 | Nein, Cloud-SaaS | Nein | Nein | Nein, Abo |\n\nNicht ein einziger der bekannten Anbieter erfüllt auch nur eines dieser vier Kriterien. AEOAI erfüllt alle vier gleichzeitig, das ist kein zusätzliches Feature obendrauf, das ist eine andere Architektur von Grund auf.\n\n## Preise: einmalig kaufen, nicht dauerhaft mieten\n\nRichtwerte für die aktuelle Pilotphase, kein SaaS-Abo für die Kernsoftware, nur ein optionaler Update- und Support-Vertrag:\n\n- **Basis-Lizenz.** Einmalig, gestaffelt nach Unternehmensgröße. Multi-Engine-Monitoring per BYOK, PII-Maskierung und lokaler Vault, lokales Dashboard, unlimitierte Prompts.\n- **Agentur-Edition.** Einmaliger Aufpreis auf die Basis-Lizenz. Beliebig viele Mandanten, sauber getrennte Projekte pro Kunde, eine lokale Installation, ideal für Beratungen mit KRITIS-Kunden.\n- **Z3-Safety-Modul.** Einmalig separat lizenzierbar. Deterministische Z3-Verifikation, Fakten-Editor, audit-fähiger UNSAT-Nachweis, gebaut für KRITIS, Recht und Finanzen.\n- **Update & Support.** Optional als Jahresvertrag. Sicherheitsupdates, neue Engine-Anbindungen, Support-Kontingent.\n- **Enterprise-Rollout.** Individuell verhandelt. Mehrplatz- und Server-Lizenzen, Anbindung an die eigene interne Fakten-Datenbank, Schulung und Onboarding.\n\n## Für wen das gebaut ist\n\nAEOAI ist bewusst nicht für jeden gebaut, der mal schauen will, ob ChatGPT seine Marke kennt. Es ist gebaut für Unternehmen, die eine regulierte Branche bedienen und AEO-Sichtbarkeit brauchen, aber keine Strategiedaten in eine fremde Cloud laden dürfen. Für Behörden, bei denen Datenhoheit keine Verhandlungssache, sondern eine gesetzliche Vorgabe ist. Für Kanzleien und Finanzdienstleister, bei denen eine falsche KI-Behauptung über die eigene Leistung ein echtes Haftungsrisiko ist, nicht nur ein Marketing-Ärgernis. Und für Agenturen und Systemhäuser, die genau diese Kunden betreuen und endlich ein Werkzeug brauchen, das sie ihren eigenen KRITIS-Kunden ohne Bauchschmerzen vorschlagen können, statt bei jedem Pitch dieselbe Cloud-Frage neu zu verlieren.\n\n## Pilotphase für regulierte Branchen\n\nAEOAI sucht aktuell die ersten Pilotpartner, gezielt in KRITIS, Recht und Finanzen, also genau bei den Organisationen, die heute mangels Alternative gar kein AEO-Tool nutzen. Pilotpartner erhalten bevorzugten Zugang und direkten Einfluss auf die Feature-Reihenfolge, kein Standard-Onboarding von der Stange.\n\n## Die härtesten Einwände, ehrlich beantwortet\n\n### \"Noch Pilotphase, ist das nicht zu früh für uns?\"\n\nDie sicherheitskritischen Kernfunktionen, PII-Maskierung, lokaler Vault, Z3-Verifikation, sind bereits fertig gebaute, laufende Bausteine, keine Konzeptskizzen. Pilotphase heißt hier: die Lizenzpreise sind noch nicht final und Pilotpartner bekommen Einfluss auf die Priorisierung, nicht dass die Kernsoftware unfertig wäre.\n\n### \"Warum kein Cloud-SaaS wie jeder andere Anbieter auch?\"\n\nWeil genau das der Punkt ist, den kein Cloud-Anbieter lösen kann, egal wie gut sein Dashboard aussieht. Sobald Prompt, Strategiedaten und interne Fakten über einen fremden Server laufen, ist die Entscheidung für viele der Zielorganisationen bereits gefallen, und zwar dagegen. Lokal ist hier kein Zusatz-Feature, sondern die Grundvoraussetzung, damit ein KRITIS-Betrieb oder eine Behörde überhaupt anfangen kann.\n\n### \"Ist ein Einmalkauf nicht riskanter als ein laufendes Abo?\"\n\nEher andersherum. Ein Einmalkauf bindet dich nicht an einen Anbieter, der seine Preise oder seine Nutzungsbedingungen jederzeit ändern kann. Die installierte Version läuft weiter, ganz ohne fortlaufende Zahlung, der optionale Update-Vertrag ist genau das, ein Optional, keine Voraussetzung fürs Weiterlaufen.\n\n### \"Was, wenn ich doch mal eine Cloud-KI zusätzlich nutzen will?\"\n\nGenau dafür gibt es BYOK. Der eigene API-Key für ChatGPT, Perplexity, Gemini, Copilot oder Claude wird direkt eingebunden, kein Widerspruch zum lokalen Betrieb. Air-gapped ist eine Option für den Betrieb ganz ohne Internet, kein Zwang.\n\n## Wie AEOAI gebaut wird\n\nAuch hier gilt derselbe Grundsatz wie bei jedem meiner anderen Projekte: die Rolle von KI-Systemen im eigenen Entwicklungsprozess wird offen benannt, nicht versteckt. AEOAI entsteht ebenfalls im Zusammenspiel mehrerer KI-Systeme für Entwicklung, Code-Review und kritischen Gegencheck, die Letztverantwortung für Architektur, Sicherheitsentscheidungen und jede Zeile Code liegt am Ende bei mir. Ein Werkzeug, das anderen verspricht, KI-Behauptungen formal zu prüfen, muss bei der eigenen Entstehung genauso ehrlich sein.\n\n## Roadmap: was als Nächstes kommt\n\nIn aktiver Entwicklung steht aktuell der GEO-Audit, ein Crawlability-Checker, der robots.txt, den Zugriff bekannter KI-Bots wie GPTBot, PerplexityBot und Google-Extended sowie Rendering-Probleme prüft, die eine Zitierung von vornherein verhindern, noch bevor es überhaupt um Inhalte geht. Die logische Ergänzung zum bisherigen Monitoring: nicht nur messen, ob zitiert wird, sondern auch erkennen, warum eine Seite technisch gar nicht erst gelesen werden kann.\n\n## In vier Schritten startklar\n\nPrompts anlegen, die Fragen, bei denen die eigene Marke auftauchen soll. Eigene API-Keys verbinden, BYOK für ChatGPT, Perplexity, Gemini, Copilot, Claude, kein Umweg über einen Zwischenanbieter. Fakten hinterlegen, Preise und Kennzahlen für den späteren Z3-Abgleich. Ab dann läuft jede weitere Prüfung automatisch, SAT oder bewiesenes UNSAT, ohne dass jemand manuell nachschauen muss.\n\n## Wichtige Erkenntnisse aus diesem Beitrag\n\nAEOAI ist eine lokale AEO- und Safety-Engine, die die eigene Marke über sechs KI-Systeme misst, per BYOK, ohne Prompt-Limit und ohne Umweg über einen Zwischenanbieter. Sensible Daten werden vor jedem Versand lokal maskiert, ein echter Z3-SMT-Solver prüft KI-Behauptungen anschließend formal gegen die eigene Fakten-Basis, SAT oder bewiesenes UNSAT, nicht nur eine Einschätzung. Das Realitäts-Panel misst über echte, eingeloggte Sitzungen statt über eine sterile API oder einen erkennbaren Scraping-Bot. Ein selbst gebautes Analytics-Modul verknüpft KI-Zitate mit echten Besuchen, komplett ohne Google Analytics und ohne Cookie-Banner. Lizenziert wird einmalig statt im Abo, Standalone, air-gapped-fähig, kein Docker. Gebaut vor allem für Unternehmen, Behörden, Agenturen und Systemhäuser, die AEO-Sichtbarkeit brauchen, aber ihre sensibelste Wahrheit nicht in eine fremde Cloud laden dürfen.", "date_published": "2026-09-02T18:00:00Z", "date_modified": "2026-09-02T18:00:00Z", "authors": [ { "name": "Adnan" } ], "tags": [ "aeoai", "aeo", "geo", "answer engine optimization", "pii anonymisierung", "z3", "ki sicherheit", "souveräne ki", "kritis", "agenturen" ] }, { "id": "19", "url": "https://jamoneai.de/blog/oruni-souveraenes-llm-gateway", "title": "oruni: Ein LLM-Gateway, das beweist, dass es nicht mitliest, statt es nur zu versprechen", "summary": "Diese Woche hat ein US-Zahlungsdienstleister einen der bekanntesten KI-Modell-Router für über 7 Milliarden Dollar übernommen, über Nacht gehört ein zentraler Verkehrsknotenpunkt für Millionen von KI-Anfragen einem Fintech-Konzern. oruni ist die andere Antwort auf dasselbe Problem: kein Unternehmen dahinter, das gekauft werden kann, ein Apache-2.0-quelloffener Kern, der auf der eigenen Maschine läuft.", "content_text": "**Deine Modelle. Deine Daten. Deine Regeln.** Das ist der Anspruch, mit dem oruni antritt.\n\nDiese Woche hat ein großer US-Zahlungsdienstleister einen der bekanntesten KI-Modell-Router für über 7 Milliarden Dollar übernommen. Über Nacht gehört einer der zentralen Verkehrsknotenpunkte für Millionen von KI-Anfragen einem Fintech-Konzern, nicht mehr einer neutralen Infrastruktur. Wer seinen gesamten Prompt-Traffic durch ein solches Gateway schickt, hat damit gerade erlebt, wie sich die eigentliche Machtfrage über Nacht verschiebt, ohne dass sich am eigenen Code auch nur eine Zeile geändert hätte. Das ist kein Einzelfall, sondern die logische Konsequenz eines Geschäftsmodells: Ein zentraler Zugangspunkt für den gesamten KI-Traffic eines Unternehmens ist wirtschaftlich zu wertvoll, um dauerhaft neutral zu bleiben.\n\noruni ist die andere Antwort auf dasselbe Problem. Kein Unternehmen dahinter, das gekauft werden kann. Kein Investor, dessen Interesse sich morgen ändert. Ein Apache-2.0-quelloffener Kern, der als einzelnes, rund 13 Megabyte großes Rust-Binary auf der eigenen Maschine läuft, nicht bei einem Dritten irgendwo dazwischen.\n\n## Das eigentliche Problem an jedem Cloud-LLM-Gateway\n\nKI-Gateways sind längst kein Nischenthema mehr, sondern ein hart umkämpftes, kapitalstark finanziertes Marktsegment, das diese Woche eindrücklich bewiesen hat, wie viel ein zentraler Prompt-Zugangspunkt tatsächlich wert ist. Das ist kein Zufall, es ist die wirtschaftliche Logik jedes Vermittlers: Wer zwischen dir und dem Modell-Anbieter sitzt, sieht jeden Prompt, kennt jedes Muster deiner Nutzung, und wird irgendwann selbst zum Übernahmeziel oder zum eigenen Profit-Center.\n\nEin Unternehmen, das mehrere KI-Anbieter gleichzeitig nutzen will, Anthropic für den einen Anwendungsfall, OpenAI für den anderen, dazu ein lokales Modell für sensible Fälle, landet fast zwangsläufig bei einem LLM-Gateway. Das Prinzip dahinter ist sinnvoll: ein einheitlicher Endpunkt, ein SDK, Routing und Failover an einer zentralen Stelle statt in jeder Anwendung einzeln neu gebaut. Das eigentliche Problem ist der Preis, den die meisten dieser Gateways dafür verlangen, ohne ihn laut auszusprechen. Der gesamte Prompt-Traffic läuft über die Infrastruktur eines Dritten, bevor er überhaupt den eigentlichen Modell-Anbieter erreicht. Wer auch nur eine Kundenanfrage, eine interne Notiz oder einen Codeausschnitt durch ein Cloud-Gateway schickt, hat damit automatisch einen zusätzlichen Auftragsverarbeiter im Spiel, mit eigenem Preismodell, eigenen Nutzungsbedingungen und einem eigenen wirtschaftlichen Interesse an genau diesem Datenstrom, ein Interesse, das sich mit jeder Finanzierungsrunde, jeder Übernahme und jedem Strategiewechsel neu justiert, ohne dass die Kunden ein Mitspracherecht hätten.\n\noruni löst dasselbe Problem, ohne diesen Kompromiss einzugehen. Das Gateway läuft auf der eigenen Maschine oder im eigenen Rechenzentrum, nicht bei einem Anbieter irgendwo dazwischen. Provider-Schlüssel werden direkt beim jeweiligen Anbieter hinterlegt (BYOK, bring your own key), kein Zwischenkonto sieht den Traffic mit. Der Kern ist zusätzlich Apache-2.0 quelloffen: Wer den eigenen API-Key anfasst, sollte in der Lage sein, den Code dahinter selbst zu prüfen, statt nur eine Marketing-Seite lesen zu müssen. Es gibt schlicht nichts zu kaufen, das den Zugriff auf deinen Traffic verändern könnte, weil niemand dazwischensitzt, den man kaufen könnte.\n\n## Was oruni konkret ist\n\nEin einzelnes, rund 13 Megabyte großes Rust-Binary, kein Docker-Zwang, kein Server-Setup. `start.bat`, und der lokale Endpunkt unter `localhost:8787` ist erreichbar, vollständig OpenAI-kompatibel. Jede bestehende Anwendung, die bereits mit dem OpenAI-SDK spricht, Python, Node/TypeScript oder LangChain, muss nur die `baseURL` umstellen, keine einzige weitere Codezeile ändert sich. Ein Feld im Request entscheidet, wohin die Anfrage tatsächlich geht: `model: \"art/modellname\"`, zum Beispiel `anthropic/claude-opus-5` oder `ollama/llama3.2`.\n\nSo sieht das in der Praxis aus, unverändert gegenüber einem direkten OpenAI-Aufruf bis auf die `baseURL`:\n\n```bash\ncurl http://localhost:8787/v1/chat/completions \\\n -H \"Authorization: Bearer oruni_sk_...\" \\\n -d '{\n \"model\": \"anthropic/claude-sonnet-5\",\n \"messages\": [{\"role\": \"user\", \"content\": \"Hallo\"}]\n }'\n```\n\n## Provider und Routing: eine Leitung, dreizehn Arten, praktisch jeder Anbieter\n\nVollständig angebunden sind bereits Anthropic, Google Gemini, OpenAI, Mistral, Groq, DeepSeek, xAI, lokale Modelle über Ollama, dazu die drei großen Enterprise-Hyperscaler AWS Bedrock, Oracle OCI Generative AI und Azure OpenAI Service sowie IBM watsonx.ai, macht dreizehn Provider-Arten mit eigener, benannter Anbindung. Die vier zuletzt genannten Hyperscaler brauchten eine eigene Integration, weil sie keine einfache Bearer-Token-Authentifizierung nutzen: Azure verlangt einen eigenen API-Key-Header und eine Deployment-URL statt eines Basis-Hosts, watsonx.ai einen IAM-Token-Tausch statt eines direkten Schlüssels, dazu eine zusätzliche Projekt-ID.\n\nFür alles, was darüber hinausgeht, gibt es `kind: \"custom\"`: Jeder Anbieter mit einem echten OpenAI-kompatiblen `/v1/chat/completions`-Endpunkt lässt sich ohne eine einzige Zeile Code in oruni anbinden, nur Basis-URL und API-Key im Dashboard eintragen, fertig. Das deckt schon heute unter anderem die chinesischen Frontier-Labs ab (Alibaba Cloud/Qwen, Zhipu AI/GLM, 01.AI/Yi, Moonshot AI/Kimi, MiniMax, Baichuan AI, Baidu/ERNIE), dazu die verbreiteten Serverless-Inferenz-Hoster Together AI, Fireworks AI, Cerebras, SambaNova, Perplexity, Cohere, AI21 Labs, Hyperbolic und Novita AI. Praktisch die gesamte aktuelle Anbieterlandschaft, ohne auf einen eigenen Adapter warten zu müssen.\n\nVier Mechanismen sorgen dafür, dass eine Anfrage auch dann noch ankommt, wenn nicht alles wie geplant läuft:\n\n- **Automatischer Failover.** Sind mehrere Provider derselben Art konfiguriert, zählt ein Netzwerkfehler, ein 429 oder ein 5xx als Instabilität und löst sofort den nächsten Kandidaten aus. Ein echter 4xx-Fehler bricht die Kette dagegen ab, statt denselben fehlerhaften Request stur zu wiederholen, ein anderer Provider würde exakt denselben Request ohnehin genauso ablehnen.\n- **Konfigurierbare Fallback-Ketten.** Gehen weiter als reines Same-Kind-Failover: Schlägt das Routing für ein Modell komplett fehl, wird ein hinterlegtes Ersatzmodell versucht, auch über Provider-Arten hinweg, etwa Anthropic zuerst, dann OpenAI, zuletzt das eigene lokale Ollama als letzte Stufe. Jeder Fallback-Treffer wird im Audit-Log ausdrücklich als solcher markiert, nicht als stille Ersetzung versteckt.\n- **EU-only-Routing.** Anfragen gehen dann ausschließlich an Provider, die explizit als EU- oder lokal markiert sind, jede Anfrage, die das nicht erfüllen kann, liefert eine klare Fehlermeldung statt eines stillen Datenabflusses in ein Drittland.\n- **Local-First-Fallback.** Schlagen Same-Kind-Failover und die konfigurierte Kette beide fehl und sieht der letzte Fehler nach einem echten Verbindungsabbruch aus, nicht nach einem 429 oder 5xx, das würde ja gerade eine funktionierende Verbindung beweisen, fragt oruni automatisch den ersten lokal erreichbaren Provider nach seinen tatsächlich verfügbaren Modellen und routet dorthin um. Ein Internetausfall muss so keine Downtime bedeuten, solange ein lokales Modell konfiguriert ist.\n\n## Cache: von 17,3 Sekunden auf 0,3 Sekunden\n\nIdentische oder inhaltlich deckungsgleiche Anfragen werden nicht zweimal an einen Provider geschickt. Ein Exact-Match-Cache über einen Hash aus Modell und Nachrichteninhalt greift ohne erneuten Provider-Aufruf, ein zusätzlicher semantischer Abgleich über lokale Embeddings erkennt auch eine bloße Umformulierung derselben Frage und trifft denselben Cache-Eintrag. Gemessen an einem echten Modell-Aufruf liegt der Unterschied bei 17,3 Sekunden ohne Cache-Treffer gegenüber 0,26 bis 0,32 Sekunden mit Treffer, ein Faktor von über 50, und das läuft automatisch für jede Anfrage, kein Opt-in nötig.\n\n## Die 3-Tier Cost Elimination Pipeline\n\nCache, ein Micro-SLM-Router und die Gedächtnis-Injektion lassen sich auch gebündelt aus der Kosten-Perspektive lesen, nicht nur aus der Funktions-Perspektive:\n\n| Stufe | Mechanismus | Ergebnis |\n| --- | --- | --- |\n| Tier 1: Cache | Exact-Match und semantischer Vektor-Cache, automatisch für jede Anfrage | Null Cloud-Kosten, kein Opt-in nötig |\n| Tier 2: Micro-SLM-Router | Lokale Komplexitätsprüfung, nur bei bewusstem `model: \"auto\"` | Einfache Aufgaben laufen kostenlos über lokales Ollama |\n| Tier 3: Gedächtnis-Injektion | Nur die 2 bis 3 relevantesten, bereits gespeicherten Fakten statt der ganzen Historie, PII vorher maskiert | Komprimierte, nicht gefilterte Nutzlast pro Anfrage |\n\nTier eins beantwortet identische oder inhaltlich deckungsgleiche Prompts direkt aus dem lokalen Vektor-Cache. Tier zwei greift ausschließlich, wenn eine Anfrage bewusst mit `model: \"auto\"` gestellt wird, kein stiller Automatismus für jede Anfrage, ein kleines, lokal laufendes Modell klassifiziert die Komplexität, bevor überhaupt geroutet wird. Tier drei ist keine Filterung, die eine Anfrage stoppt, sondern eine Kompression jeder Anfrage, die tatsächlich bei einem Provider ankommt, egal ob lokal oder Cloud.\n\n## Gedächtnis: ein Fakt, einmal gemerkt, für jede angebundene Anwendung\n\nNach jeder erfolgreichen Antwort speichert oruni Frage und Antwort lokal, mit einem Embedding für die spätere Ähnlichkeitssuche. Bei einer späteren, thematisch ähnlichen, aber technisch unabhängigen Anfrage werden passende Einträge automatisch als Kontext vorangestellt, app-übergreifend: Ein Fakt, den Cursor gespeichert hat, steht auch einem Terminal-Agenten oder der eigenen Anwendung zur Verfügung, ohne dass er dafür die Festplatte verlässt. Ein konkretes Beispiel aus der eigenen Dokumentation: die Anfrage \"Merke dir, meine Lieblingssprache ist Rust, mein Projekt heißt oruni\" in einer Sitzung, und in einer völlig unabhängigen zweiten Sitzung die Frage \"An welche Sprache sollte ich mich gerade erinnern?\", korrekt beantwortet mit Rust und oruni, nachweisbar im Audit-Log mit dem tatsächlichen Konfidenzwert der Ähnlichkeitssuche, kein geratener Zufallstreffer.\n\nJeder Eintrag liegt verschlüsselt im selben Tresor wie Provider-Schlüssel und PII-Blacklist, nicht als Klartext-Zeile in einer SQLite-Datei. Herkunft (welcher Gateway-Key oder welcher Admin den Fakt angelegt hat) und der echte Konfidenzwert werden mitgeführt, sichtbar im Audit-Log, als Abwehr gegen eine Gedächtnis-Vergiftung durch einen einzelnen, unbelegten Eintrag. Eine Konsolidierung erkennt Paare mit ähnlicher Frage, aber widersprüchlichem Fakt, etwa eine spätere Korrektur einer früheren Angabe, und entfernt automatisch den älteren der beiden Einträge, reine Dopplungen mit identischem Fakt bleiben unangetastet. Pro Anfrage lässt sich das Gedächtnis über den Header `X-Oruni-Memory: off` gezielt für den einen Fall abschalten, der nicht gespeichert werden soll, ohne die serverweite Konfiguration anzufassen.\n\n## PII-Anonymisierung mit einem Beweis statt einem Versprechen\n\n76 Standard-Entitätstypen werden lokal erkannt und durch Platzhalter wie `` ersetzt, bevor eine Anfrage überhaupt den Provider erreicht, darunter E-Mail-Adressen und Telefonnummern, IBAN und Kreditkartennummern, Ausweis-, Pass-, Steuer- und Sozialversicherungsnummern, API-Schlüssel, SSH-Keys und JWT-Token, Gesundheitsdaten. Die Antwort wird lokal wieder mit den echten Werten aufgefüllt, bevor sie an den Aufrufer zurückgeht. Bei Aktivierung erkennt zusätzlich ein rein lokales NER-Modell (dslim/bert-base-NER, läuft komplett offline, kein Cloud-Aufruf) Namen, Organisationen und Orte auch ohne begleitende Kontaktdaten. Eigene Begriffe, Mitarbeiternamen, Projektcodes, Kundendaten, lassen sich im Admin-Bereich als Blacklist mit frei wählbarem Ersatzwort anlegen, live vorschaubar beim Eintippen, verschlüsselt im selben Tresor wie die Provider-Schlüssel. Drei Sensitivitätsstufen (niedrig, mittel, hoch) unterscheiden zwischen eindeutig strukturierten Mustern ohne nennenswertes Falsch-Positiv-Risiko und breiteren Wortlisten-Kategorien wie Nationalität, die einzelne, alltägliche Wörter treffen können.\n\nDer entscheidende Unterschied zu den meisten PII-Filtern liegt aber nicht in der Erkennung selbst, sondern im Beweis danach. Derselbe Z3-SMT-Solver-Kern, der bei der Formal-Verification strukturierte Modell-Ausgaben gegen Constraints prüft, sichert zusätzlich die Maskierung selbst ab: Nach jeder Maskierung beweist eine echte Z3-String-Anfrage formal, dass keiner der ursprünglichen, unmaskierten Werte noch im ausgehenden Text steckt. Nicht wahrscheinlich, nicht mit hoher Konfidenz, formal bewiesen. Ein Verstoß bedeutet einen echten Maskierungsfehler und wird hart blockiert, die Anfrage geht in diesem Fall gar nicht erst an den Provider raus, statt es einfach zu riskieren. Die IBAN-Erkennung selbst verlässt sich dabei nicht auf reine Formaterkennung, sondern prüft die echte ISO-7064-Mod-97-Prüfziffer, ein strukturell IBAN-förmiger, aber prüfziffer-ungültiger Platzhalter aus einer Dokumentation wird dadurch nicht mehr fälschlich als echte IBAN behandelt und unnötig blockiert.\n\n## Schlüssel-Tresor: nie im Klartext, auf keiner Plattform\n\nProvider-API-Keys liegen hardware- beziehungsweise OS-gebunden verschlüsselt und werden nach dem Speichern nie wieder im Klartext angezeigt, nachprüfbar per Grep gegen die rohe Datenbankdatei, nicht nur behauptet. Unter Windows ist das DPAPI, benutzergebunden, die am tiefsten in die Plattform integrierte Stufe. macOS nutzt den echten Login-Keychain, Linux den Secret Service (gnome-keyring/kwallet), beides über den jeweiligen OS-eigenen Schlüsselbund statt einer bloßen Datei mit eingeschränkten Rechten. Ist auf einem Linux-Server ohne Desktop-Sitzung kein Keyring-Daemon erreichbar, fällt oruni nachvollziehbar auf einen AES-256-GCM-verschlüsselten Datei-Fallback zurück, statt abzustürzen. Jede Stufe ist echte Verschlüsselung, keine legt einen Schlüssel je im Klartext ab.\n\n## Guardrails: Rate-Limit, Budget-Kill-Switch, Circuit-Breaker, Prompt-Injection-Vorprüfung\n\nEin Sliding-Window-Rate-Limit pro Gateway-Key verhindert versehentliche Lastspitzen, ein 429 signalisiert die Überschreitung. Ein monatliches Kosten-Budget mit echtem Kill-Switch stoppt weitere Anfragen, sobald die bisherigen, tatsächlich abgerechneten Kosten des Monats das Limit erreichen, Kosten werden dabei aus den echten usage-Werten der Provider-Antwort berechnet, nicht geschätzt, ein 402 signalisiert das Erreichen des Budgets. Ein Circuit-Breaker pausiert einen Provider temporär nach mehreren aufeinanderfolgenden Netzwerk- oder Server-Fehlern, statt jede weitere Anfrage sinnlos an einen erkennbar instabilen Provider zu schicken, und schließt nach einer Abkühlzeit automatisch wieder.\n\nEine Prompt-Injection-Vorprüfung läuft heuristisch auf jede Nutzer-Nachricht, vor Cache, Gedächtnis und Provider-Aufruf: Anweisungs-Überschreibung, Rollen-Übernahme, System-Prompt-Extraktion, bekannte Jailbreak-Namen, Restriktions-Umgehung, auf Deutsch und Englisch. Standardmäßig nur protokollierend im Audit-Log sichtbar, auf Wunsch lehnt oruni eine Anfrage mit Treffer direkt ab, bevor sie Cache, Gedächtnis oder einen Provider überhaupt erreicht. Ehrlich benannt: eine Heuristik, kein ML-Klassifikator, ein Treffer heißt \"verdächtiges Muster gefunden\", nicht \"garantiert bösartig\".\n\n## Audit-Log: hash-verkettet und selbst nachprüfbar\n\nJede Routing-Entscheidung wird als hash-verkettetes Ereignis gespeichert, nichts wird überschrieben. Ein manipulierter Eintrag bricht die Kette erkennbar, ein eigener Prüf-Endpunkt berechnet die gesamte Kette neu und meldet den ersten Bruch, statt dass Integrität nur behauptet wird.\n\n## MCP-Gateway, Streaming, Tool-Calling und Token-Counting\n\n`POST /mcp` spricht das Model Context Protocol über JSON-RPC 2.0 im Streamable-HTTP-Transport, kein separater Begleitprozess nötig. Ein Werkzeug, `chat_completion`, läuft dabei durch denselben Kern wie `/v1/chat/completions`: Routing mit Failover, semantischer Cache, PII-Maskierung und Gedächtnis greifen identisch, kein ungeschützter Sonderpfad für Agenten-Frameworks.\n\n`stream: true` liefert echtes Provider-Passthrough-Streaming: Jeder Chunk wird vom Provider direkt an den Client durchgereicht, sobald er ankommt, kein internes Fertigrechnen mehr davor. Das läuft für alle 13 Provider-Arten. Anthropic und Gemini hatten dafür schon eigene Implementierungen, die komplette OpenAI-kompatible Familie (OpenAI, Mistral, Ollama, Custom, Groq, DeepSeek, xAI, Bedrock, OCI) zieht mit derselben Logik nach. Azure OpenAI (eigener `api-key`-Header statt Bearer, sonst OpenAI-Format) und watsonx.ai (IAM-Token-Tausch plus eigener `chat_stream`-Endpunkt) brauchten eine eigene Anbindung, weil sie vom Standardmuster abweichen, streamen jetzt aber genauso Token für Token. Der PII-sichere Zwischenpuffer bleibt dabei unverändert: ein Sliding-Window von 256 Zeichen Sicherheitsabstand (`PiiStreamBuffer`) sorgt dafür, dass kein maskierter Fund über eine Chunk-Grenze hinweg unvollständig beim Client ankommt.\n\nTool- und Function-Calling wird zwischen den Provider-Formaten in beide Richtungen übersetzt, Anthropics Content-Block-Format, OpenAIs separates `tool_calls`-Feld und Geminis `functionCall`/`functionResponse`-Struktur laufen alle über dieselbe normalisierte Darstellung, und gehen jetzt genauso in Echtzeit-Deltas raus wie Text, statt serverseitig gesammelt und erst als ein komplettes Ereignis kurz vor Schluss geschickt zu werden. Echtes Streaming gilt damit auch für Agenten-Workflows mit Tool-Calling, nicht nur für reinen Chat-Text.\n\nToken-Counting nutzt wo möglich die echten, vom Provider selbst gemeldeten Werte statt nur einer lokalen Schätzung: OpenAI-kompatible Provider liefern sie auf Wunsch (`stream_options.include_usage`) in einem finalen Chunk, Anthropic in `message_start`/`message_delta`, Gemini in `usageMetadata`. Nur wo ein Provider das nicht mitschickt, bleibt der lokale, tiktoken-kompatible BPE-Tokenizer über `POST /api/tokens/count` als Fallback, GPT-4o-artige Modelle exakt über o200k_base, jede andere Modellfamilie ehrlich als Näherung gekennzeichnet, nicht als exakter Wert für einen fremden Tokenizer ausgegeben.\n\n## Das Dashboard: kein Mockup, sondern die echte, laufende Anwendung\n\nJeder Screenshot auf der oruni-Website ist eine echte Aufnahme der laufenden Anwendung, mit echten Zahlen aus dieser Instanz. Ein Chat-Testfeld direkt im Dashboard schickt eine Frage an ein oder mehrere Modelle gleichzeitig, jede Antwort als eigene Karte mit Latenz, Token-Verbrauch und PII-Zähler, über denselben Pfad wie jede externe Anfrage. Eine Live-Traffic-Ansicht zeigt Anfragen der letzten Stunde als Verlauf, gestapelt nach Routing-Ergebnis, alle 5 Sekunden aktualisiert, ein Kosten-Dashboard mit Monats- und Jahresansicht rechnet aus echten, bereits abgerechneten Provider-Werten. Fallback-Ketten lassen sich über einen echten Formular-Editor anlegen statt über eine kommagetrennte Textzeile.\n\nFür Organisationen mit eigenem Observability-Stack lässt sich ein OpenTelemetry-Endpunkt eintragen, jede abgeschlossene Anfrage erzeugt dann zusätzlich einen echten OTLP/HTTP-Trace-Span, Modell, Routing-Ergebnis, Latenz, Fehlergrund, nutzbar mit Grafana Tempo, Jaeger, Honeycomb oder jedem anderen OTLP-fähigen Collector. Leer gelassen, der Standard, entsteht keine einzige zusätzliche Netzwerkverbindung. Derselbe Grundsatz gilt für die Preise: Der Preiskatalog ist fest im Kern einkompiliert, ein einzelner Klick auf \"Preise aktualisieren\" holt aktuelle Werte von einer konfigurierbaren Quelle nach, kein automatischer Hintergrund-Sync, der unbemerkt Netzwerkverkehr erzeugt.\n\n## Was seit dem Start dazugekommen ist: sieben neue Funktionen und ein überarbeitetes Dashboard\n\nSeit dem letzten Stand sind sieben Funktionen dazugekommen, die vor allem eine Lücke schließen: Dinge, die Unternehmen von einem produktiven LLM-Gateway erwarten, aber bisher fehlten.\n\n- **Router-Metadaten.** Wer den Header `X-Oruni-Metadata: enabled` mitschickt, bekommt in der Antwort, auch im letzten Chunk beim Streaming, ein `oruni_metadata`-Feld zurück: welcher Provider tatsächlich geantwortet hat, ob es ein Cache-Treffer war, ob ein Fallback-Provider einspringen musste, wie viele PII-Stellen maskiert wurden, wie viele Gedächtnis-Fakten einflossen und wie lange die Anfrage gedauert hat. Standardmäßig aus, damit bestehende Integrationen unverändert weiterlaufen.\n- **Zero-Data-Retention-Routing.** Ein zweiter Filter neben dem bestehenden EU-only-Routing: Anfragen lassen sich so einschränken, dass sie ausschließlich an Provider gehen, die nachweislich keine Daten speichern, lokales Ollama, Bedrock, OCI, Azure OpenAI, watsonx.ai. Alles andere gilt sicherheitshalber als datenspeichernd, auch eigene Custom-Provider.\n- **Presets.** Modell und System-Prompt lassen sich unter einem Namen bündeln, etwa `preset/support-de`, und dann einfach als `model` im Request angeben. Praktisch für Teams, die nicht bei jeder Anfrage den vollen System-Prompt mitschicken wollen.\n- **Management-Keys.** Ein eigener, niedriger privilegierter Schlüsseltyp, getrennt von normalen Gateway-Keys. Plattformen, die auf oruni aufbauen, können damit für ihre eigenen Kunden automatisch Gateway-Keys erzeugen, ohne dass dafür ein Mensch ins Dashboard muss.\n- **Prompt-Injection-Allowlist.** Die Erkennung von Prompt-Injection-Mustern kann jetzt gezielt Ausnahmen zulassen, statt bei jedem Treffer die ganze Anfrage zu blockieren. Nützlich, wenn ein legitimer Anwendungsfall zufällig ein Muster trifft.\n- **SSO-Gruppen-Rollen-Mapping.** Beim Login über SSO lassen sich IdP-Gruppen automatisch auf oruni-Rollen abbilden, etwa \"security-team\" auf Security Officer. Kein vollständiges SCIM, aber die pragmatische Login-Zeit-Variante davon, bei jedem Login neu ausgewertet.\n- **Dashboard-Überarbeitung.** Durchgängige Toggle- und Slider-Bedienelemente statt Textfeldern, wo es Sinn ergibt. Ein Drei-Wege-Theme-Umschalter (Hell/Dunkel/System) statt der alten Zwei-Zustands-Lösung. Eine neue Info-Seite mit Versionsnummer, Entwickler, Lizenz und den verwendeten Open-Source-Bausteinen, wie man sie aus jeder seriösen Software kennt. Enterprise-Funktionen sind jetzt auch ohne Lizenz als Vorschau sichtbar, statt komplett zu verschwinden, damit klar wird, was man bekommt.\n\n## Zero-Effort-Onboarding: die Einrichtung, die es oft schon gar nicht mehr braucht\n\nWer im eigenen Terminal oder in der .env bereits Schlüssel wie `ANTHROPIC_API_KEY` oder `OPENAI_API_KEY` gesetzt hat, ist häufig schon fertig, bevor überhaupt ein Provider von Hand eingetragen wird. Ein Klick auf \"Auto-Erkennung\" im Dashboard prüft, welche bekannten API-Schlüssel als Umgebungsvariable bereits auf dem Rechner liegen, und richtet daraus fertige Provider automatisch ein, ganz ohne neue Kreditkarte, neues Konto oder aufgeladenes Guthaben. Genau das letzte Bequemlichkeits-Argument, das für ein Cloud-Gateway noch übrig bleibt, fällt damit weg, ohne dass ein einziges Byte der eigenen Umgebungsvariablen den Rechner verlässt, um das herauszufinden.\n\n## Ehrliche Grenzen, weil auch das zur Beweisbarkeit gehört\n\nWer bei jeder eigenen Funktion \"live bewiesen\" oder \"noch nicht getestet\" ausdrücklich dazuschreibt, muss dieselbe Ehrlichkeit auch bei den eigenen Lücken durchhalten. Aktuell gilt:\n\n- **Failover mitten in einem bereits laufenden Stream funktioniert nur, solange noch kein Byte beim Client angekommen ist.** Das ist keine oruni-spezifische Lücke, sondern eine physikalische Eigenschaft jedes echten Passthrough-Systems: Daten, die den Client schon erreicht haben, lassen sich nicht zurückholen, ein Wechsel mitten im Stream würde bereits gesendete Daten widersprechen oder duplizieren. Der einzige Weg, das zu vermeiden, wäre wieder komplett zu puffern, bevor irgendetwas rausgeht, also genau der alte, nicht-echte Ansatz, den es jetzt nicht mehr gibt.\n- **Vorkompilierte Linux- und macOS-Pakete existieren noch nicht.** Aktuell gibt es nur das geprüfte Windows-Release.\n- **Der Schlüssel-Tresor ist auf Windows am tiefsten integriert (DPAPI).** macOS und Linux nutzen den echten OS-Schlüsselbund, aber noch kein direktes TPM-2.0-Sealing.\n- **Wer nur eine einzige Kreditkarte für zweihundert Modelle hinterlegen will, findet das bei einem Aggregator.** oruni verlangt bewusst eigene API-Keys je Provider, kein zentraler, aufgeladener Guthaben-Topf, das ist kein Komfortverlust, sondern die Grundvoraussetzung dafür, dass Zugangsdaten und Kostenverantwortung beim eigenen Unternehmen bleiben.\n\n## Preise: Open-Core, kein SaaS, kein Tokenpreis-Aufschlag\n\nDer Kern ist quelloffen und kostenlos, Apache-2.0, selbst gehostet: alle dreizehn Provider-Arten plus jeder Custom-Endpunkt, PII-Anonymisierung, Schlüssel-Tresor, Cache, Gedächtnis, Auto-Erkennung bereits gesetzter API-Keys, OpenTelemetry-Export und Preiskatalog-Sync. Enterprise-Funktionen für Organisationen mit mehreren Teams sind separat, pro Instanz oder Team, lizenziert, Ed25519-signierte Lizenzdatei, lokal geprüft, kein Cloud-Aktivierungsserver, kein Anruf nach Hause, konsistent mit dem Zero-Telemetry-Grundsatz des Kerns.\n\nDer Kostenvorteil lässt sich konkret vorrechnen: Bei 1.000 Dollar monatlichen Modellkosten zum Anbieter-Listenpreis zahlt man bei oruni exakt diese 1.000 Dollar, keinen Aufschlag. Ein verbreitetes Cloud-Gateway erhebt im Guthaben-Modus laut eigener, öffentlich einsehbarer Preisseite (Stand 2026-08-21) 5,5 Prozent Gebühr (mindestens 0,80 Dollar) beim Guthabenkauf, macht in diesem Beispiel 1.055 Dollar. Bei eigenen Provider-Keys entfällt diese Gebühr dort zwar bis 25.000 Dollar Modellkosten pro Monat, danach fallen 5 Prozent auf den übersteigenden Betrag an, oruni kennt diese Schwelle nicht, der Aufschlag bleibt bei jedem Volumen 0 Dollar.\n\n## Enterprise: Governance, die sich beweisen lässt, nicht nur behauptet wird\n\nSSO/OIDC-Anbindung mit Authorization-Code-Flow und PKCE gegen Entra ID/Azure AD, Okta, Google Workspace, Keycloak oder jeden anderen Standard-OIDC-Anbieter, der Issuer wird beim Einrichten live geprüft, kein separates Nutzerverzeichnis nötig. Team-Gedächtnis teilt eine Wissensbasis über mehrere Nutzer, nur Admin oder Security Officer legen Fakten an, eine Konfliktprüfung über dieselbe Ähnlichkeitserkennung wie beim regulären Gedächtnis verhindert stillschweigend widersprüchliche Einträge. Multi-Provider-Ensemble-Voting schickt dieselbe Anfrage parallel an mehrere Provider und gruppiert die Antworten über dieselbe Embedding-Ähnlichkeit wie der semantische Cache, eine Übereinstimmungs-Kennzahl zeigt, ob sich die Modelle einig sind, mit sichtbarer Kostensumme im Dashboard, kein stiller Mehrverbrauch.\n\nWiederholte, durch die Prompt-Injection-Vorprüfung erkannte verdächtige Anfragen lösen automatisch einen Sicherheitsvorfall aus und sperren den betroffenen Gateway-Key, bis er im Dashboard manuell wieder freigegeben wird. Zentrale Policy-Verteilung nach dem Hub-and-Spoke-Prinzip lässt eine oruni-Instanz die Provider-Konfiguration automatisch von einer anderen im selben Firmennetz ziehen, jede Instanz kann Hub für andere sein, zentral gepflegt, aber ohne gemeinsamen Laufzeit-Zustand als Single Point of Failure, ein geteilter Zustand, der bei vielen anderen Multi-Node-Gateways genau die Schwachstelle ist, die diese Woche gerade wieder gezeigt hat, wie teuer zentrale Abhängigkeit werden kann. Formal-Verification prüft strukturierte Outputs über denselben echten Z3-SMT-Solver gegen eine Spezifikation, Wertebereiche, erlaubte Werte, Summenkonsistenz zwischen Feldern wie \"Zwischensumme plus Steuer gleich Gesamtsumme\", jede verletzte Regel wird einzeln benannt, kein pauschales Bestehen oder Durchfallen.\n\n## Die härtesten Einwände, ehrlich beantwortet\n\noruni tritt gegen kapitalstarke, VC-finanzierte Cloud-Gateways an, entwickelt von einer einzelnen, namentlich genannten Person. Skepsis ist dabei die richtige erste Reaktion, hier die häufigsten Einwände, ohne Ausweichen:\n\n### \"Was, wenn der Entwickler keine Lust mehr hat?\"\n\nDer Kern ist Apache-2.0 quelloffen, kein Vendor-Lock-in, die baseURL lässt sich in fünf Sekunden auf einen anderen Anbieter umstellen. Selbst im schlechtesten Fall läuft die letzte lauffähige, lokal installierte Version unverändert weiter, es gibt keinen Cloud-Dienst, den jemand abschalten könnte.\n\n### \"Ein Solo-Entwickler ohne Firma, wie soll ich dem vertrauen?\"\n\nEin im Impressum namentlich genannter Entwickler mit echter Adresse und offenem Quellcode ist mehr Rechenschaftspflicht, nicht weniger. Jede Sicherheitsentscheidung steht im echten Code, nicht in einem Whitepaper, und jede Anfrage landet hash-verkettet und selbst nachprüfbar im Audit-Log.\n\n### \"Noch Alpha-Status, ist das nicht zu riskant?\"\n\nWas live gegen echte Provider bewiesen ist, wird auch so gekennzeichnet, was noch nicht getestet ist, ebenso ehrlich benannt. Sicherheitskritische Kernfunktionen wie PII-Maskierung, Schlüssel-Tresor und Audit-Kette sind unit-getestet und im Dashboard live nachprüfbar.\n\n### \"Was, wenn ein Anbieter über Nacht seine API ändert?\"\n\nEin eigenes Model-Deprecation-Watch warnt im Dashboard, bevor ein abgekündigtes Modell zum stillen Fehlschlag wird. Der aufrufende Client spricht ohnehin nur das eigene, stabile Protokoll von oruni, ein geändertes Provider-Format betrifft eine einzelne Adapter-Datei im offenen Code, dazu sichern 229 automatisierte Tests jeden bestehenden Provider-Pfad gegen Regressionen ab.\n\n### \"Warum kein ISO 27001 oder SOC 2?\"\n\nEin solches Zertifikat bestätigt, dass ein Dritter fremde Daten ordentlich behandelt, oruni ist aber kein Dritter, die Software läuft auf der eigenen Maschine. Das Drittland-Risiko bestimmt allein der selbst gewählte Modell-Anbieter, nicht oruni, und die formale PII-Löschgarantie per Z3 lässt sich technisch nachprüfen statt nur vertraglich versprochen zu werden.\n\n## Wie oruni tatsächlich gebaut wird\n\nDie meisten Firmen verschweigen, wie viel KI im eigenen Code steckt. Bei einem Gateway zu genau diesen Modellen wäre das unehrlich. oruni entsteht als Ein-Personen-Firma im offen benannten Zusammenspiel mit mehreren KI-Systemen: Claude als primärer Entwicklungspartner für den kompletten, öffentlich nachvollziehbaren Entwicklungsverlauf vom Rust-Backend bis zum Dashboard, Gemini für Code-Review und Debugging als zweite Meinung, ChatGPT für frühe Konzept- und Architektur-Brainstormings, Grok als kritischer Gegencheck von Plänen und Vorschlägen der anderen Modelle, bevor irgendetwas davon umgesetzt wird. Ich selbst steuere dabei Architektur, Sicherheitsentscheidungen und Produktstrategie, jede Zeile Code, jede kryptografische Grenze und jede Freigabe läuft am Ende über einen Menschen, nicht über ein Modell. KI beschleunigt die Ausführung, die Verantwortung für das Ergebnis bleibt zu hundert Prozent menschlich.\n\n## Roadmap: was wirklich schon steht, was noch kommt\n\nDrei Meilensteine gelten als abgeschlossen und live verifiziert: der souveräne Core mit lokaler Rust-Architektur, PII-Anonymisierung samt formalem Z3-Maskierungsbeweis und Hardware-Schlüsseltresor; die Protokoll-Normalisierung mit allen dreizehn Provider-Arten, echtem Provider-Passthrough-Streaming für Text und Tool-Calls, und dem Cache; sowie die Enterprise-Guardrails mit Formal-Verification, SSO/RBAC, zentraler Policy-Verteilung, Budget-Wächter und dem MCP-Gateway. Meilenstein vier, der aktive Release-Zyklus für den öffentlichen v0.1-Core, ist aktuell in Freigabe: die Öffnung des Apache-2.0-Repositories, das geprüfte Windows-Release-Paket, und eine gegen die offiziellen OpenAI-SDKs sowie LangChain verifizierte Tooling-Kompatibilität, dabei wurde ein echter Kompatibilitätsbug gefunden und behoben, nicht nur theoretisch für kompatibel erklärt. Als Nächstes, in Entwicklung, stehen vorkompilierte Linux- und macOS-Pakete (bisher existiert nur das Windows-Release), ein signierter Windows-MSI-Installer für die IT-Verteilung, und ein unabhängiges externes Sicherheitsaudit des Open-Core-Teils, um die eigenen Sicherheitsaussagen auch von außen bestätigen zu lassen.\n\n## In drei Schritten startklar\n\nBinary starten, keine Server-Installation, kein Docker-Zwang, läuft auf der eigenen Maschine oder im eigenen Rechenzentrum. Provider anlegen, im Dashboard oder per API, Name, Art, Basis-URL, API-Key, BYOK, kein Zwischenkonto. Endpunkt verwenden, die baseURL des ohnehin schon eingesetzten OpenAI-SDKs auf den lokalen Endpunkt umstellen, kein neues SDK nötig. Wer bereits Umgebungsvariablen wie `ANTHROPIC_API_KEY`, `OPENAI_API_KEY` oder `MISTRAL_API_KEY` gesetzt hat, ist oft schon fertig, bevor überhaupt ein Provider von Hand eingetragen wird.\n\n## Wichtige Erkenntnisse aus diesem Beitrag\n\noruni läuft als einzelnes, rund 13 MB großes Rust-Binary vollständig auf der eigenen Maschine und verbindet direkt mit dreizehn Provider-Arten plus jedem weiteren OpenAI-kompatiblen Anbieter über custom/, ohne Cloud-Zwischenkonto für Prompts oder Schlüssel. PII wird lokal vor 76 Entitätstypen maskiert, ein echter Z3-SMT-Solver beweist danach formal, dass kein Originalwert im ausgehenden Text übrig bleibt, statt es nur zu versprechen. Cache senkt eine wiederholte Anfrage von 17,3 auf rund 0,3 Sekunden, persistentes, app-übergreifendes Gedächtnis merkt sich Fakten dauerhaft und verschlüsselt. Provider-Schlüssel liegen nie im Klartext, DPAPI unter Windows, Login-Keychain unter macOS, Secret Service unter Linux, das Audit-Log ist hash-verkettet und selbst nachprüfbar. Echtes Provider-Passthrough-Streaming läuft für alle 13 Provider-Arten, Text und Tool-Calls eingeschlossen, mit demselben PII-sicheren Zwischenpuffer, ein Provider-Wechsel mitten in einem laufenden Stream bleibt dabei bewusst ausgeschlossen, eine physikalische Grenze jedes echten Passthrough-Systems, keine offene Baustelle. Der Kern ist Apache-2.0 quelloffen und kostenlos, kein Tokenpreis-Aufschlag, Enterprise-Funktionen wie SSO, Team-Gedächtnis und Compliance-Reports sind separat lizenziert.", "date_published": "2026-08-24T18:00:00Z", "date_modified": "2026-08-28T10:00:00Z", "authors": [ { "name": "Adnan" } ], "tags": [ "oruni", "llm gateway", "byok", "pii anonymisierung", "z3", "mcp", "souveräne ki", "ollama", "ki sicherheit", "streaming" ] }, { "id": "18", "url": "https://jamoneai.de/blog/warum-mein-blog-jetzt-beweise-verlangt", "title": "Warum ich meinem eigenen Blog einen Beweis-Index und ein Fehler-Register verpasst habe", "summary": "Die meisten Blogs behaupten einfach irgendwas und hoffen, dass es überzeugend klingt. Ich fand, mein eigener Blog sollte sich an dieselbe Regel halten wie meine Produkte: beweisbar, nicht behauptet. Also habe ich sieben Funktionen gebaut, die genau das erzwingen.", "content_text": "## Ich glaube meinem eigenen Blog nicht automatisch\n\nJedes Projekt auf dieser Seite hat einen Anspruch: nicht schätzen, sondern beweisen. Z3-Solver statt Bauchgefühl, formale Verifikation statt Marketing-Behauptung. Und dann sitze ich an meinem eigenen Blog und merke, dass der Blog selbst genau das nicht einlöst, was er über meine Produkte behauptet. Ein Blogbeitrag ist am Ende auch nur eine Behauptung mit Formatierung. Das wollte ich nicht so stehen lassen.\n\nIch habe mir also überlegt, was passiert, wenn ich die eigene Firmenphilosophie ernst nehme und sie auf den Blog selbst anwende, nicht nur auf die Produkte, über die der Blog schreibt. Herausgekommen sind sieben neue Funktionen. Keine davon ist ein Newsletter-Formular oder ein Kommentarbereich.\n\n## Der Beweis-Index\n\nJede konkrete Zahl in einem Beitrag, die Prüf-Latenz von AxiomGate, die Testanzahl bei SolveNode, bekommt jetzt einen Beleg direkt daneben, mit Quelle. Und weil ich das nicht in 17 einzelnen Artikeln verstecken wollte, gibt es jetzt eine eigene Übersichtsseite, den [Beweis-Index](/beweis-index). Aktuell stehen dort über 60 einzeln geprüfte Behauptungen. Wer mir nicht glauben will, muss es nicht, er kann nachschauen.\n\n## Der Souveränitäts-Score\n\nEin kleines Label direkt unter jedem Teaser: läuft das Projekt on-premise, wie hoch ist die Cloud-Abhängigkeit, gibt es externe Telemetrie, ist es formal verifiziert. Ehrlich befüllt heißt hier auch: nicht jedes Projekt bekommt ein Häkchen bei formaler Verifikation. Nur die vier, die wirklich Z3 einsetzen, zeigen das auch an. Alles andere wäre wieder genau die Art von Übertreibung, die ich vermeiden wollte.\n\n## Der Agenten-Endpunkt\n\nDas hier ist der Teil, auf den ich am meisten stolz bin, weil ihn praktisch kein Blog macht. Jeder Beitrag hat jetzt einen eigenen, strukturierten JSON-Endpunkt. Nicht für Menschen gedacht, sondern für KI-Agenten, die gezielt eine einzelne Tatsache abfragen wollen, ohne sich durch einen ganzen Artikel zu parsen. Wenn schon KI-Systeme meine Inhalte lesen, dann sollen sie das sauber tun können, nicht durch Scraping und Rätselraten.\n\n## Der Versions-Diff\n\nWenn sich an einem Beitrag etwas ändert, reicht mir eine Notiz \"wurde aktualisiert\" nicht mehr. Ich zeige jetzt, wo es sinnvoll ist, den echten Vorher-Nachher-Wert an, wie ein Code-Diff, rot durchgestrichen, grün der neue Stand. Software-Denke auf einen Blogtext angewendet, aber genau das ist, wofür dieser Blog steht.\n\n## Die Widerlegungs-Bounty\n\nAm Ende jedes Beitrags kann jetzt jeder einen sachlichen Fehler melden. Die Belohnung ist bewusst kein Geld, sondern Namensnennung, mit dem gewünschten Nickname, öffentlich. Ich will nicht, dass Leute Fehler suchen, weil es sich finanziell lohnt, sondern weil ich es genau so meine: wenn ich falsch liege, will ich es wissen, und wer es findet, verdient die Anerkennung dafür.\n\n## Das Falsch-lag-ich-Register\n\nDas Gegenstück zur Bounty. Eine eigene Seite, die ausschließlich Fälle listet, in denen eine frühere Einschätzung von mir nachweislich falsch war. Aktuell ist sie leer, weil bisher kein Fall bekannt ist. Das bleibt so ehrlich stehen, auch wenn sich das irgendwann ändert. Eine Erfolgsseite kann jeder bauen, das Gegenteil traut sich kaum jemand.\n\n## Der Projekt-Stammbaum\n\nSiebzehn Projekte klingen erstmal nach einem beliebigen Baukasten. Sind sie aber nicht, einige teilen wirklich dieselbe Kerntechnologie. Der [Stammbaum](/stammbaum) zeigt das jetzt als Graph, gruppiert nach echten, geteilten Technologien wie Z3, Event Sourcing oder TPM-gebundener Hardware-Identität. Und genauso wichtig: er zeigt auch die Projekte, die komplett eigenständig sind. Keine erfundene Verwandtschaft nur damit es beeindruckender aussieht.\n\n## Wichtige Erkenntnisse aus diesem Beitrag\n\nEin Blog, der Beweisbarkeit von seinen eigenen Produkten verlangt, sollte sich selbst an denselben Maßstab halten. Der Beweis-Index macht jede Zahl im Blog einzeln nachprüfbar. Der Souveränitäts-Score bewertet jedes Projekt ehrlich, nicht durchgehend positiv. Der Agenten-Endpunkt macht jeden Beitrag für KI-Systeme strukturiert abfragbar. Die Widerlegungs-Bounty und das Falsch-lag-ich-Register sind bewusst unbequem angelegt, Anerkennung statt Geld, eine öffentliche Fehlerliste statt einer Erfolgsgeschichte.", "date_published": "2026-08-15T18:00:00Z", "date_modified": "2026-08-15T18:00:00Z", "authors": [ { "name": "Adnan" } ], "tags": [ "blog", "beweis index", "souveränitäts score", "transparenz", "meta" ] }, { "id": "17", "url": "https://jamoneai.de/blog/axiomgate-verified-execution-layer-fuer-ki-agenten", "title": "AxiomGate: Warum ein KI-Agent beweisen sollte, dass er regelkonform handelt, statt es nur zu behaupten", "summary": "AxiomGate prüft jede geplante Aktion eines KI-Agenten mit einem Z3-Solver formal-beweisbar gegen Ihre eigenen Policies, bevor sie ausgeführt wird. Vollständig lokal, framework-unabhängig, mit einem Kernel-Netzwerkwächter als zweiter Verteidigungslinie.", "content_text": "## Das Vertrauensproblem hinter jedem autonomen Agenten\n\nUnternehmen wollen KI-Agenten produktiv einsetzen: E-Mails versenden, Zahlungen auslösen, Deployments durchführen, Datenbanken ändern. Was fehlt, ist eine verlässliche Instanz, die vor der Ausführung prüft, ob eine geplante Aktion sicher und regelkonform ist. Die meisten heutigen KI-Guardrails sind Prompt-Filter oder ein Sprachmodell, das seine eigene Aktion selbst einschätzt, probabilistisch und durch geschickte Prompt-Formulierung beeinflussbar.\n\n## Ein Beweis statt einer Einschätzung\n\nAxiomGate ersetzt diese Selbsteinschätzung durch einen Z3-Solver, der jede geplante Agenten-Aktion formal gegen definierte Unternehmensregeln prüft, etwa Ausgabenlimits, verbotene Zielsysteme oder Freigabeerfordernisse. Das Ergebnis ist eine von drei Antworten: Allow, Deny mit Begründung, oder Escalate zur Freigabe durch einen Menschen, nachvollziehbar statt einer stillen Ablehnung ohne Grund.\n\n## Harte Grenzen, die sich nicht wegreden lassen\n\nDer Solver summiert die gesamte Sitzungshistorie plus die neue Aktion, eine Grenze gilt kumulativ statt pro Einzelanfrage. Fünfzehn Überweisungen à 9.900 Euro statt einer großen von 148.500 Euro, um ein Zehntausend-Euro-Limit zu umgehen, werden dadurch erkannt und blockiert, unit-getestet gegen den eigenen Code. Ein Mensch kann bei einem Grenzfall eine Eskalation freigeben, aber keine per Policy definierte harte Obergrenze aushebeln.\n\n## Der Netzwerk-Wächter auf Kernel-Ebene\n\nEine API lässt sich umgehen, sobald ein Agent sie einfach nicht aufruft. Der Netzwerk-Wächter (axiomgate_guardian) setzt deshalb eine Block-Regel direkt im Windows-Kernel-Netzwerkfilter, nicht nur eine Prüfung im Anwendungscode. Ein Agenten-Prozess ohne lokale Administratorrechte kann diese Sperre nicht selbst aufheben. Ehrlich dazu: Mit Administratorrechten ließe sich die Regel ändern, dafür überwacht sich der Wächter selbst und meldet Manipulation als eigenständigen Sicherheitsvorfall.\n\n## Framework-unabhängig über MCP oder SDK\n\nJeder Agent ruft AxiomGate vor jeder Aktion auf, nahtlos über das Model Context Protocol als Gateway oder direkt über die Python-SDK-Schicht mit LangChain-Anbindung, ohne den bestehenden Agenten-Code umzubauen. Gemessene Prüf-Latenz: 7 bis 8 Millisekunden pro Solver-Aufruf, weitgehend unabhängig von der Anzahl der Regeln und der Größe der Sitzungs-Historie.\n\n## Ehrlich zur eigenen Grenze\n\nDer Solver prüft Mengen, Grenzen und Zugriffsrechte formal. Ob ein Text angemessen oder eine Entscheidung ethisch vertretbar ist, bleibt außerhalb dessen, was sich formal beweisen lässt, dafür bleibt eine andere Kontrolle nötig. AxiomGate befindet sich aktuell in der Vorvalidierungsphase, vertrieben als Lizenz für lokal installierte Software statt als nutzungsbasiertes SaaS-Modell, mit stark rabattierten Konditionen für die ersten Pilotkunden im Austausch für strukturiertes Feedback.\n\n## Wichtige Erkenntnisse aus diesem Beitrag\n\nAxiomGate prüft geplante Agenten-Aktionen mit einem Z3-Solver formal-beweisbar statt heuristisch einzuschätzen. Harte, kumulative Grenzwerte gelten unabhängig von jeder Freigabeentscheidung eines Menschen. Ein Kernel-Netzwerkwächter blockiert unerlaubten Netzwerkzugriff zusätzlich unabhängig von der Solver-Prüfung selbst. Die Integration läuft framework-unabhängig über das Model Context Protocol oder eine Python-SDK-Schicht, gemessen mit 7 bis 8 Millisekunden Prüf-Latenz.", "date_published": "2026-08-14T15:00:00Z", "date_modified": "2026-08-14T15:00:00Z", "authors": [ { "name": "Adnan" } ], "tags": [ "axiomgate", "ki agenten", "z3", "formale verifikation", "ki sicherheit", "mcp" ] }, { "id": "16", "url": "https://jamoneai.de/blog/desksync-verschluesselter-fernzugriff", "title": "DeskSync: Fernzugriff, der beweist, dass er sicher ist, statt es nur zu behaupten", "summary": "DeskSync verbindet in Sekunden mit jedem Gerät, Ende-zu-Ende verschlüsselt und TPM-geräteattestiert. Für alle, die TeamViewer und AnyDesk aus Sicherheits- oder Kostengründen hinter sich lassen wollen.", "content_text": "## Fernzugriff als bevorzugtes Angriffsziel\n\nFernzugriffs-Software verspricht vollständige Kontrolle über ein Gerät, genau deshalb ist sie ein bevorzugtes Ziel für Angreifer. Viele etablierte Lösungen wiegen Nutzer in einem Sicherheitsgefühl, das bei genauerem Hinsehen vor allem auf Vertrauen beruht, nicht auf technisch erzwungenen Garantien.\n\n## Erst die sichere Wahl, dann die bequeme\n\nDeskSync macht deshalb bei jeder Architekturentscheidung zuerst die sichere Wahl, dann erst die bequeme. Der Verbindungscode authentifiziert beide Seiten gegenseitig über ein PAKE-Verfahren, bevor überhaupt Bildschirmdaten fließen. Ein Angreifer in der Mitte scheitert damit bereits am Handshake selbst, nicht erst an einer nachgelagerten Prüfung.\n\n## Geräteattestierung statt kopierbarer Zertifikate\n\nJedes Gerät signiert seinen Verbindungs-Fingerprint hardwaregebunden über das TPM. Ein kopiertes Zertifikat allein reicht damit nicht aus, um eine fremde Identität vorzutäuschen, die Bindung an den physischen Chip macht diesen Angriffsweg technisch unattraktiv.\n\n## Kontrolle bis auf die einzelne Berechtigung\n\nSehen, Steuern, Dateitransfer, Zwischenablage, Audio und Tunneling lassen sich einzeln freigeben oder sperren, live während einer laufenden Sitzung und ohne Neuverbindung. Durchgesetzt wird das serverseitig, nicht nur im Client versteckt. Für unbeaufsichtigte Sitzungen sorgt der Curtain Mode zusätzlich dafür, dass der lokale Bildschirm gesperrt wird, während eine Fernsteuerung läuft.\n\n## Ein Audit-Log, das wirklich lückenlos ist\n\nJede Sitzung, jede Rechteänderung und jeder Anmeldeversuch wird lückenlos protokolliert und kryptografisch mit dem vorherigen Eintrag verkettet. Für Admins und CISOs ist das auf einen Blick nachvollziehbar, lokal einsehbar und exportierbar, keine Behauptung, sondern ein technischer Nachweis.\n\n## Bezahlmodell nach Geräten, nicht nach Kollegen\n\nBei den meisten Fernzugriffs-Anbietern kostet jeder weitere Admin-Account extra, ein Team aus fünf Technikern zahlt so oft ein Vielfaches eines Einzelnutzers, unabhängig davon, wie viele Geräte tatsächlich betreut werden. DeskSync lizenziert stattdessen den Server, unbegrenzt viele Admins greifen darauf zu, ohne dass jeder zusätzliche Kollege die Rechnung erhöht.\n\n## Geschlossene Testwelle statt aufgehübschtem Demo-Modus\n\nDie Beta läuft mit denselben Binaries wie die spätere Software, nur einzelne Enterprise-Bausteine wie der Selbsthost-Lizenzserver sind noch in Arbeit. Ein Klick erzeugt einen zufälligen, komplett anonymen Zugangs-Token, gespeichert wird dabei ausschließlich ein Zeitstempel und der Hash des Tokens, niemals Name oder E-Mail-Adresse.\n\n## Wichtige Erkenntnisse aus diesem Beitrag\n\nFernzugriffs-Software ist ein bevorzugtes Angriffsziel, weil sie vollständige Kontrolle über ein Gerät verspricht. DeskSync authentifiziert Verbindungen über einen PAKE-Handshake und bindet Geräteidentität hardwaregebunden über TPM. Sechs granulare Rechte-Schalter pro Sitzung und ein hash-verkettetes Audit-Log machen Kontrolle und Nachvollziehbarkeit technisch belastbar statt behauptet. Lizenziert wird der Server statt jedes einzelnen Admin-Accounts, ohne Sitzplatz-Aufpreis.", "date_published": "2026-08-14T09:00:00Z", "date_modified": "2026-08-15T10:00:00Z", "authors": [ { "name": "Adnan" } ], "tags": [ "desksync", "fernzugriff", "tpm attestierung", "pake", "verschlüsselung", "remote support" ] }, { "id": "15", "url": "https://jamoneai.de/blog/stellwerk-event-sourced-identity-lifecycle", "title": "Stellwerk: Warum Offboarding meist der unterschätzte Teil der IT-Sicherheit ist", "summary": "Stellwerk automatisiert On- und Offboarding in Active Directory und Microsoft 365 auf einen Klick und macht jeden Schritt mit einer Hash-Chain unveränderlich nachvollziehbar.", "content_text": "## Der Moment, der in der Praxis oft zu lange dauert\n\nEin neuer Mitarbeiter startet, drei Tage später hat er noch nicht alle Zugänge. Ein alter Mitarbeiter geht, Monate später hat er sie immer noch. Beides ist kein Ausnahmefall, sondern in vielen IT-Abteilungen der Normalzustand, weil On- und Offboarding manuell über mehrere Systeme verteilt abläuft.\n\n## Event-Sourcing statt stiller Änderungen\n\nStellwerk speichert jede Aktion als unveränderliches Event und verkettet sie per SHA-256 mit dem vorherigen Ereignis. Eine einzige nachträgliche Änderung an Inhalt oder Reihenfolge bricht diese Kette nachweisbar, per Knopfdruck überprüfbar, nicht nur behauptet. Der komplette Datenbestand lässt sich jederzeit deterministisch allein aus dem Event-Log neu aufbauen, Replay statt Backup-Hoffnung.\n\n## Echte PowerShell-Ausführung mit eingebautem Sicherheitsnetz\n\nStellwerk spricht direkt mit Active Directory und Microsoft Graph, mit Dry-Run-Vorschau für jede Aktion, bevor auch nur ein Befehl das Verzeichnis erreicht. Skript-Parameter laufen dabei ausschließlich über eine temporäre JSON-Datei und Prozess-Umgebungsvariablen, nie als String direkt in PowerShell-Code eingebettet, mit automatisiertem Regressionstest gegen Command-Injection belegt, nicht nur behauptet.\n\n## Wenn ein Schritt scheitert, wird sauber zurückgerollt\n\nEine Saga-Engine orchestriert die Workflows und kompensiert bei einem Fehlschlag automatisch und in umgekehrter Reihenfolge bereits ausgeführte Schritte. Kein halb ausgeführter Onboarding- oder Offboarding-Vorgang bleibt hängen, jeder Schritt ist einzeln kompensierbar.\n\n## Fünf Rollen, ein klares Bild vom Alltag\n\nSuper Admin, IT-Administrator, Operator, Auditor und Manager sehen jeweils exakt das, was ihre Rolle braucht, nicht mehr. Kritische Aktionen lassen sich zusätzlich optional an ein Vier-Augen-Prinzip binden, für Organisationen, bei denen ein einzelner Klick nicht ausreichen soll.\n\n## Ungenutzte Lizenzen, sofort sichtbar\n\nDer Lizenz-Optimizer gleicht AD-Konten mit zugewiesenen Microsoft-365- und Adobe-Lizenzen ab und zeigt das Einsparpotenzial, ohne eine einzige Excel-Tabelle anzufassen. Bei einem Unternehmen mit 1.000 Mitarbeitenden und 15 Prozent jährlicher Fluktuation ergeben sich daraus rechnerisch 150 Offboardings pro Jahr, und da erfahrungsgemäß 5 bis 10 Prozent aller Lizenzen nach dem Ausscheiden aktiv bleiben, kommen bei 1.000 Microsoft-365-Lizenzen schnell mehrere Tausend Euro direkt einsparbares Potenzial pro Jahr zusammen.\n\n## Deployment ohne Beratertage\n\nEin Doppelklick-Installer auf NSIS- oder MSI-Basis bringt einen IT-Administrator ohne Implementierungsprojekt in unter 30 Minuten startklar. Die Lizenzierung ist einmalig statt laufend, gestaffelt nach Unternehmensgröße, mit unbegrenzter Nutzeranzahl.\n\n## Wichtige Erkenntnisse aus diesem Beitrag\n\nOn- und Offboarding ist in vielen IT-Abteilungen manuell über mehrere Systeme verteilt und dauert entsprechend lange. Stellwerk führt jede Aktion als Event mit SHA-256-Hash-Chain, nachträgliche Manipulation fällt technisch auf. Echte PowerShell-Ausführung mit Dry-Run-Vorschau und Command-Injection-Schutz macht jeden Schritt nachvollziehbar, eine Saga-Engine rollt bei Fehlschlägen sauber zurück. Der Lizenz-Optimizer deckt ungenutzte Lizenzen auf, oft ein direkt bezifferbarer, fünfstelliger Einsparbetrag pro Jahr.", "date_published": "2026-08-07T09:00:00Z", "date_modified": "2026-08-15T10:00:00Z", "authors": [ { "name": "Adnan" } ], "tags": [ "stellwerk", "identity lifecycle", "active directory", "event sourcing", "saga pattern", "powershell" ] }, { "id": "14", "url": "https://jamoneai.de/blog/wissenskern-enterprise-rag-plattform", "title": "WissensKern: Warum eine KI, die nur plausibel klingt, für Fachwissen nicht reicht", "summary": "WissensKern beantwortet Fragen ausschließlich aus den eigenen Dokumenten, mit Quellenbeleg bis auf die Seite, formal verifiziert mit Z3 und vollständig ohne Cloud-Anbindung.", "content_text": "## Das Problem mit generischen KI-Chats für Fachwissen\n\nEin generisches KI-Chat-Tool beantwortet fast jede Frage, unabhängig davon, ob die passenden Fachdokumente überhaupt vorliegen. Bei Wissenslücken neigt ein solches System dazu, plausibel klingende, aber nicht belegte Antworten zu erfinden, gerade bei Steuerrecht, Maschinenbau oder Medizin ein ernstes Risiko.\n\n## Ein Kern, der sich an das Fachgebiet anpasst\n\nWissensKern passt sich an das jeweilige Fachgebiet an, nicht umgekehrt. Das System wird einmalig mit dem spezifischen Fachwissen eines Unternehmens betankt und wird so zum hochspezialisierten, internen Experten, vollständig lokal und ohne Cloud-Anbindung. SteuerKI zeigt als konkrete Instanz beispielhaft, wie das für Steuerwissen aussieht.\n\n## Jede Antwort mit Beleg bis zur Seite\n\nDie KI antwortet nicht aus allgemeinem Trainingswissen, sondern durchsucht gezielt die eigenen Dokumente und zitiert die exakte Quelle bis auf Seite und Absatz. Jede Anfrage ohne guten Dokumenttreffer landet automatisch in einem Wissenslücken-Dashboard, ein vollständiges Audit-Log hält zusätzlich fest, wer wann was hochgeladen, gelöscht oder gefragt hat.\n\n## Formale Verifikation als Alleinstellungsmerkmal\n\nFür Fragen, die sich auf Schwellenwerte, Ja/Nein-Regeln oder Berechnungen reduzieren lassen, prüft WissensKern die Antwort zusätzlich mit Z3, dem SMT-Solver von Microsoft Research, unabhängig vom Sprachmodell. Statt sich allein auf die Wahrscheinlichkeit des nächsten Wortes zu verlassen, zeigt das System exakt, welche Bedingung erfüllt oder verletzt ist, und warnt sichtbar bei einem formalen Widerspruch.\n\n## Gehärtet gegen Manipulation, real getestet\n\nDrei unabhängig voneinander wirkende Verteidigungslinien, ein gehärteter System-Prompt, das Sandwich-Prinzip gegen Recency-Bias und eine deterministische Code-Prüfung, blockieren Manipulationsversuche, bevor eine Anfrage überhaupt an das Sprachmodell geht. Bei der Einführung neuer Rollen wurde zudem geprüft, ob jede interne Funktion auch serverseitig gesperrt ist, eine dabei tatsächlich gefundene Lücke wurde auf Administratorrechte beschränkt, ein Restrisiko wird dabei ehrlich eingeordnet statt Vollständigkeit zu behaupten.\n\n## Ein begehbarer 3D-Vektorraum statt einer Blackbox\n\nEin begehbarer 3D-Raum zeigt jedes Wissens-Fragment als schwebenden Punkt, frei fliegbar und direkt in der Anwendung integriert. Für Kundengespräche und Demos ist das ein anschaulicher Beleg dafür, dass hier strukturiertes Wissen arbeitet, keine Blackbox.\n\n## Wichtige Erkenntnisse aus diesem Beitrag\n\nEin generisches KI-Chat-Tool erfindet bei Wissenslücken oft plausibel klingende, aber unbelegte Antworten. WissensKern beantwortet Fragen ausschließlich aus den eigenen Dokumenten, mit Quellenbeleg bis auf die Seite, und meldet fehlende Treffer offen in einem Wissenslücken-Dashboard. Formale Verifikation mit Z3 prüft regelbasierte Antworten zusätzlich mathematisch. Drei unabhängige Verteidigungslinien schützen real getestet gegen Prompt-Injection und Manipulationsversuche.", "date_published": "2026-07-31T09:00:00Z", "date_modified": "2026-08-15T10:00:00Z", "authors": [ { "name": "Adnan" } ], "tags": [ "wissenskern", "rag", "z3", "chromadb", "ki sicherheit", "steuerki" ] }, { "id": "13", "url": "https://jamoneai.de/blog/solvenode-tier-0-itsm-mit-enterprise-ki", "title": "SolveNode: Warum Ihre besten L3-Lösungen selten bei L1 ankommen", "summary": "SolveNode verwandelt gelöste L3-Fälle automatisch in L1-Guides, komplett lokal, ohne Docker, mit striktem CISO-Compliance-Framework. Keine Anfrage verlässt jemals das Firmennetzwerk.", "content_text": "## Wissen, das nicht dort ankommt, wo es gebraucht wird\n\nEin erfahrener L3-Spezialist löst ein komplexes Problem in einer Stunde. Drei Wochen später steht ein L1-Support-Mitarbeiter vor demselben Symptom, ohne davon zu wissen, weil die Lösung nur im Kopf des Spezialisten oder in einem geschlossenen Ticket verschwunden ist. Das ist kein Ausnahmefall, sondern der Alltag in vielen IT-Support-Organisationen.\n\n## Aus gelösten Fällen werden automatisch Anleitungen\n\nSolveNode setzt genau hier an: Beim Öffnen eines Tickets durchsucht die lokale KI automatisch alle freigegebenen Wissensartikel und formuliert bei ausreichender Trefferqualität direkt eine nutzbare Antwort. Aus jedem gelösten Ticket destilliert dieselbe KI umgekehrt automatisch einen strukturierten Troubleshooting-Guide, sodass Wissen entsteht, wo Probleme tatsächlich gelöst werden, statt in einem separaten Dokumentationsschritt zu versickern.\n\n## Automatisierung, die sich der Admin selbst zusammenklickt\n\nEin Visual Automation Builder erlaubt Wenn-Dann-Regeln ohne eine Zeile Code: Incident, kritische Priorität, Quelle Prometheus, führt zur automatischen Zuweisung an den Incident Manager und einer Benachrichtigung per PagerDuty. Die Regeln laufen über denselben HMAC-signierten Webhook-Mechanismus wie jede andere Integration und protokollieren ihre eigene Lauf-Historie und Trefferzahl.\n\n## Enterprise-Identität statt Insel-Zugängen\n\nAnmeldung über Azure AD, Entra ID, Okta oder Google per OpenID Connect wird durch automatisches Nutzer-Lifecycle-Management per SCIM-Provisioning ergänzt. Onboarding und Offboarding von Nutzerkonten läuft dadurch automatisch mit, ganz ohne manuelle Nutzerpflege neben dem bestehenden Single Sign-On.\n\n## Change-Freigabe statt stillem Durchwinken\n\nChange-Tickets durchlaufen einen echten Genehmigungsschritt nach ITIL-Vorbild, angefragt, genehmigt oder abgelehnt, ausgeführt, und lassen sich nicht als gelöst schließen, solange die Freigabe aussteht. Eigene Prozess-Steuerungsrollen für Incident-, Problem- und Change-Manager koordinieren dabei jeden Vorgang ihres Ticket-Typs, unabhängig von der Zuweisung.\n\n## Datenhoheit als Grundprinzip, nicht als Zusatzoption\n\nSämtliche KI-Funktionen laufen über eine selbst gehostete Engine im eigenen Netz, kein Ticket-Inhalt und keine Kundendaten gehen an einen externen Cloud-KI-Anbieter. Vierzehn Standardrollen mit granularer Rechte-Matrix, ein hash-verkettetes, revisionssicheres Audit-Log und eine strikte Content-Security-Policy runden das Sicherheitsbild ab, alles serverseitig durchgesetzt, nicht nur im Frontend versteckt.\n\n## Wichtige Erkenntnisse aus diesem Beitrag\n\nWissen aus gelösten L3-Fällen erreicht L1-Support oft gar nicht, weil es nirgends strukturiert festgehalten wird. SolveNode destilliert automatisch Troubleshooting-Guides aus gelösten Tickets und schlägt bei neuen, ähnlichen Fällen direkt eine Antwort vor. Ein Visual Automation Builder erlaubt Automatisierung ohne Code, SSO und SCIM decken die komplette Nutzerverwaltung ab. Die gesamte KI-Verarbeitung bleibt lokal im eigenen Netz, mit vierzehn Rollen und einem hash-verketteten Audit-Log.", "date_published": "2026-07-17T09:00:00Z", "date_modified": "2026-08-15T10:00:00Z", "authors": [ { "name": "Adnan" } ], "tags": [ "solvenode", "itsm", "ki support", "sso scim", "itil", "automation" ] }, { "id": "12", "url": "https://jamoneai.de/blog/sovereign-bridge-lokale-middleware-datenintegration", "title": "Sovereign Bridge: Wenn Systeme nicht miteinander reden, redet irgendwann jemand von Hand", "summary": "Sovereign Bridge verbindet 24 Formate und Systeme, von CSV bis SQL Server, per Assistent statt per Skript. Läuft vollständig lokal, ohne Cloud und ohne Abo.", "content_text": "## Der Alltag zwischen zwei Systemen\n\nCSV-Export aus System A, manueller Import in System B, und irgendwo dazwischen ein Fehler, der erst Wochen später auffällt, wenn eine Zahl einfach nicht mehr zusammenpasst. In vielen Unternehmen ist genau das der tägliche Umgang mit Datenintegration: kein durchdachter Prozess, sondern eine wiederkehrende, fehleranfällige Handarbeit.\n\n## Ein Assistent statt eines weiteren Skripts\n\nSovereign Bridge ersetzt diesen Ablauf durch einen geführten Wizard: von der Quellwahl über die visuelle Feldzuordnung bis zum geprüften Lauf, ganz ohne Code. Ein Dry Run zeigt vor jeder tatsächlichen Ausführung, was passieren wird, auch bei sehr großen Dateien in unter zwei Sekunden. Fehler werden damit sichtbar, bevor sie echten Schaden anrichten, nicht erst danach.\n\n## 24 kuratierte Konnektoren\n\nVon CSV, JSON und Excel über EDI X12 und EDIFACT bis PostgreSQL, SQL Server, S3 und Kafka deckt Sovereign Bridge ein breites Spektrum an Quellen und Zielen ab. Jeder Konnektor beherrscht echtes Streaming und lässt sich über ein Plugin-System erweitern, ohne dass die gesamte Anwendung neu kompiliert werden muss.\n\n## Sicherheit, die in der Architektur steckt\n\nZugangsdaten werden über Windows DPAPI verschlüsselt, jeder Lauf wird per Event Sourcing manipulationssicher protokolliert. Es gibt keine Telemetrie, keine Analyse-Server im Hintergrund und keine stille Datenübertragung nach außen. Die Sicherheit ist damit kein Zusatzmodul, sondern ein struktureller Bestandteil der Architektur.\n\n## Gebaut in Rust, betrieben auf eigener Hardware\n\nSovereign Bridge ist speichersicher und nativ schnell, mit echtem zeilenweisem Streaming auch bei sehr großen Dateien. Es gibt kein Abo und keine laufende Cloud-Rechnung, das System läuft auf der eigenen Infrastruktur. Bereits im Einsatz ist es bei Personaldienstleistern, Kanzleien und in EDI-lastigen Lieferketten, überall dort, wo Datenintegration ein wiederkehrendes, geschäftskritisches Thema ist.\n\n## Analyse vor der ersten Installation\n\nJedes Projekt beginnt mit einer Systemlandschafts-Analyse statt einem unverbindlichen Download. Das Ergebnis ist ein belastbarer Befund über die eigene Datenlandschaft, unabhängig davon, ob ein Unternehmen sich anschließend für Sovereign Bridge entscheidet oder nicht.\n\n## Wichtige Erkenntnisse aus diesem Beitrag\n\nOhne strukturierte Integration verlagert sich Datenintegration in wiederkehrende, fehleranfällige Handarbeit. Sovereign Bridge ersetzt das durch einen Wizard mit Dry-Run-Vorschau statt eines weiteren Skripts. 24 kuratierte Konnektoren mit echtem Streaming decken von CSV bis Kafka ein breites Spektrum ab. Zugangsdaten sind über Windows DPAPI verschlüsselt, jeder Lauf per Event Sourcing protokolliert, ganz ohne Telemetrie oder Cloud-Abo.", "date_published": "2026-07-03T09:00:00Z", "date_modified": "2026-08-15T10:00:00Z", "authors": [ { "name": "Adnan" } ], "tags": [ "sovereign bridge", "datenintegration", "middleware", "rust", "event sourcing", "edi" ] }, { "id": "11", "url": "https://jamoneai.de/blog/lockless-stateless-identity-layer", "title": "Lockless: Eine Identität, die nichts speichert und trotzdem nichts vergisst", "summary": "Lockless rekonstruiert Identität bei jeder Nutzung neu aus TPM-2.0-Hardware-Parametern, statt sie in einem Tresor abzulegen. Es gibt keinen zentralen Ort, an dem Zugangsdaten gestohlen werden könnten.", "content_text": "## Der zentrale Tresor als Angriffsziel\n\nOb Passwort-Datenbank oder Schlüssel-Tresor, fast jedes Identitätssystem hat einen zentralen Ort, an dem die entscheidenden Geheimnisse liegen. Genau dieser Ort wird damit zum lohnendsten Angriffsziel überhaupt: Ein einziger erfolgreicher Einbruch kann potenziell alle gespeicherten Identitäten kompromittieren.\n\n## Rekonstruktion statt Speicherung\n\nLockless verfolgt einen fundamental anderen Ansatz. Die Identität wird bei jeder Nutzung neu aus Hardware-Parametern des TPM-2.0-Chips rekonstruiert und anschließend nicht gespeichert. Es gibt keinen zentralen Ort, an dem Zugangsdaten liegen und gestohlen werden könnten, weil es diesen Ort im klassischen Sinn schlicht nicht gibt.\n\n## Direkte Autorisierung zwischen Geräten\n\nMehrere Geräte gleichen ihren Vertrauens-Status per Peer-to-Peer ab, ohne dass ein Tresor übertragen oder ein zentraler Server eingebunden wird. Kein Anbieter sieht dabei die Verbindung mit, weil kein Anbieter als Vermittler zwischengeschaltet ist. Die Geräte handeln das Vertrauen direkt untereinander aus.\n\n## Ein offener Kern statt Security-through-Obscurity\n\nDas Kern-Protokoll ist quelloffen und auditierbar, aufgebaut auf dokumentierten Standards wie TPM-2.0-HMAC-Bindung, Argon2id-Schlüsselableitung und ChaCha20-Poly1305-Verschlüsselung. Es gibt keine proprietären, unauditierbaren Algorithmen, auf die man einfach vertrauen müsste, jeder kann die tatsächliche Funktionsweise nachvollziehen.\n\n## Notfall-Schutz für den physischen Ernstfall\n\nEine gesonderte Notfall-PIN lädt eine plausible Schein-Identität, statt die echte preiszugeben, ein ähnliches Prinzip wie der Duress-Modus in anderen Sicherheitssystemen. Für Organisationen gibt es zusätzlich air-gap-fähige Varianten für Behörden- und Hochsicherheitsanforderungen, bei denen selbst eine Netzwerkverbindung ein Risiko darstellt.\n\n## Warum das noch Closed Alpha ist\n\nLockless befindet sich aktuell in einer geschlossenen Alpha-Phase. Ein Identitätssystem, das mit so grundlegend anderen Annahmen arbeitet als etablierte Ansätze, verdient eine besonders gründliche Prüfung, bevor es breiter eingesetzt wird. Das ist eine bewusste Entscheidung für Sorgfalt statt für ein verfrühtes Rollout.\n\n## Wichtige Erkenntnisse aus diesem Beitrag\n\nEin zentraler Tresor für Zugangsdaten ist immer auch ein lohnendes Angriffsziel. Lockless rekonstruiert Identität stattdessen bei jeder Nutzung neu aus TPM-2.0-Hardware-Parametern, ohne dauerhafte Speicherung. Geräte gleichen Vertrauen direkt per Peer-to-Peer ab, ohne zentralen Server. Ein quelloffenes, auf dokumentierten Standards aufgebautes Protokoll und ein Duress-PIN-Mechanismus für den Ernstfall runden das Konzept ab, aktuell noch in geschlossener Alpha-Phase.", "date_published": "2026-06-26T09:00:00Z", "date_modified": "2026-08-15T10:00:00Z", "authors": [ { "name": "Adnan" } ], "tags": [ "lockless", "tpm 2.0", "identity", "argon2id", "chacha20-poly1305", "closed alpha" ] }, { "id": "10", "url": "https://jamoneai.de/blog/sentinai-cyber-security-fuer-ki-nutzung", "title": "SentinAI: KI-Potenzial nutzen, ohne die Kontrolle über sensible Daten zu verlieren", "summary": "SentinAI erkennt über 78 sensible Datentypen und anonymisiert sie in Echtzeit, bevor sie das Gerät verlassen. Eine unsichtbare Membran zwischen Browser und öffentlichen KI-Tools.", "content_text": "## Das Dilemma zwischen KI-Nutzung und Datenschutz\n\nMitarbeiter sollen öffentliche KI-Tools produktiv nutzen dürfen, gleichzeitig darf kein sensibler Geschäftsvorgang unkontrolliert nach außen fließen. Viele Unternehmen lösen dieses Dilemma bislang mit einem pauschalen Verbot, das im Alltag entweder umgangen wird oder echte Produktivitätsgewinne verhindert.\n\n## Visual Shielding statt pauschalem Verbot\n\nSentinAI erkennt über 78 sensible Datentypen, darunter IBAN, Gesundheitsdaten, API-Schlüssel und Gesichtsgeometrie, und anonymisiert sie in Echtzeit, bevor sie das Gerät verlassen. Screenshots sensibler ERP-Masken werden dabei aktiv blockiert, nicht nur im Nachhinein erkannt. Die Membran zwischen Browser und öffentlichem KI-Tool arbeitet unsichtbar im Hintergrund, ohne den eigentlichen Arbeitsfluss zu unterbrechen.\n\n## Zero-Knowledge statt zentraler Datensammlung\n\nEin souveräner Daten-Tresor gleicht Anfragen lokal mit AES-256-verschlüsselten Datenbanken ab. Die Analyse-Engine läuft vollständig auf dem eigenen Gerät, mit einer Latenz unter 5 Millisekunden. Es gibt keine zentrale Sammelstelle, an der die geprüften Inhalte für einen Anbieter sichtbar würden.\n\n## De-Anonymisierung bleibt an die Hardware gebunden\n\nMaster-Keys sind hardwaregebunden. Der Re-Import der Originaldaten ist ausschließlich lokal möglich, nicht über einen externen Dienst. Nur die eigene Organisation besitzt den Schlüssel zurück zu den echten Daten, kein Drittanbieter kann diesen Schritt für sie übernehmen oder mitlesen.\n\n## In zwei Minuten betriebsbereit\n\nSentinAI installiert sich als eigenständige Anwendung und läuft autark, ohne Cloud-Setup. Sicherheits-Events werden lokal aggregiert und stehen direkt für Compliance-Audits bereit, ohne dass zusätzliche Auswertungswerkzeuge angebunden werden müssen.\n\n## Wichtige Erkenntnisse aus diesem Beitrag\n\nEin pauschales KI-Verbot löst das Spannungsfeld zwischen Produktivität und Datenschutz in der Praxis meist nicht. SentinAI erkennt über 78 sensible Datentypen und maskiert sie in Echtzeit, bevor sie das Gerät verlassen, inklusive aktiver Blockade sensibler Screenshots. Die Zero-Knowledge-Architektur läuft vollständig lokal mit AES-256-Verschlüsselung, unter 5 Millisekunden Latenz. Hardwaregebundene Master-Keys sorgen dafür, dass nur die eigene Organisation den Weg zurück zu den echten Daten hat.", "date_published": "2026-06-19T09:00:00Z", "date_modified": "2026-08-15T10:00:00Z", "authors": [ { "name": "Adnan" } ], "tags": [ "sentinai", "cyber security", "zero-knowledge", "dlp", "ki sicherheit", "windows" ] }, { "id": "9", "url": "https://jamoneai.de/blog/doc-forge-z3-fuer-finance-workflows", "title": "Doc-Forge: Warum KI-Buchhaltung schätzt und Doc-Forge beweist", "summary": "Doc-Forge nutzt SMT-Solving-Technologie aus der Chip-Verifikation, um die Konsistenz von Finanzdaten mathematisch nachzuweisen. Kein Raten, sondern ein deterministischer Beweis in rund 21 Millisekunden.", "content_text": "## Der blinde Fleck vieler KI-Buchhaltungstools\n\nViele KI-gestützte Buchhaltungswerkzeuge extrahieren Werte aus Belegen und schlagen eine Buchung vor, gestützt auf Wahrscheinlichkeit. Das funktioniert bei eindeutigen Fällen gut. Bei Grenzfällen, etwa bei Mehrwertsteuersätzen, Skonto-Berechnungen oder Ausschlussregeln, bleibt es aber eine Schätzung, auch wenn sie selbstbewusst präsentiert wird.\n\n## SMT-Solving statt Wahrscheinlichkeit\n\nDoc-Forge verfolgt einen anderen Ansatz. Statt zu raten, nutzt es SMT-Solving-Technologie, wie sie ursprünglich aus der Verifikation von Computerchips stammt, um die Konsistenz Ihrer Finanzdaten mathematisch nachzuweisen. Der deterministische Kern liefert in rund 21 Millisekunden einen echten Beweis, keine statistische Schätzung.\n\n## Eine mathematische Firewall für das eigene Regelwerk\n\nDer deterministische Kern erkennt Inkonsistenzen im hinterlegten Regelwerk und zeigt nachvollziehbare, mathematisch konsistente Alternativen auf, wenn eine Berechnung nicht aufgeht. Mehrwertsteuer, Summen und Skonto werden dabei bis auf die vierte Nachkommastelle bewiesen, nicht nur plausibel gerundet.\n\n## Datensouveränität by Design\n\nDie Z3-Logik läuft lokal. Sensitive Finanzdaten werden nicht zum Training öffentlicher Modelle verwendet, und jede Entscheidung, jede Ausnahme und jeder Export bleibt belastbar nachvollziehbar. Für eine Finanzabteilung ist das ein doppelter Gewinn: Datenhoheit und Nachweisbarkeit gleichzeitig, nicht als Kompromiss gegeneinander.\n\n## Revisionssicherer Export in bestehende Systeme\n\nDoc-Forge erzeugt DATEV-EXTF- und SEPA-PAIN.001-Dateien mit einer Z3-Safety-Gate-Garantie im Hintergrund. Volle Unterstützung für xRechnung und ZUGFeRD ist ebenso vorhanden wie native Integration in DATEV, SharePoint und SAP, kein Systembruch, sondern ein zusätzlicher, mathematisch abgesicherter Prüfschritt vor dem eigentlichen Export.\n\n## Wichtige Erkenntnisse aus diesem Beitrag\n\nViele KI-Buchhaltungstools liefern eine plausible, aber statistisch geschätzte Antwort, gerade bei Grenzfällen. Doc-Forge prüft Finanzdaten stattdessen mit SMT-Solving-Technologie mathematisch, in rund 21 Millisekunden. Mehrwertsteuer, Summen und Skonto werden bis auf die vierte Nachkommastelle bewiesen statt geschätzt. Die Z3-Logik läuft lokal, mit revisionssicherem Export für DATEV, xRechnung und ZUGFeRD.", "date_published": "2026-06-05T09:00:00Z", "date_modified": "2026-08-15T10:00:00Z", "authors": [ { "name": "Adnan" } ], "tags": [ "doc-forge", "z3", "datev", "xrechnung", "zugferd", "finance automation" ] }, { "id": "8", "url": "https://jamoneai.de/blog/korers-hardware-gebundener-tresor", "title": "Korers: Ein Passwort-Tresor ohne Passwort-Reset per E-Mail", "summary": "Korers bindet Verschlüsselung direkt an die eigene Hardware via TPM 2.0. Ohne den physischen Chip kein Zugriff, dafür Open Source, AES-256-GCM und ein Duress-Modus für den echten Ernstfall.", "content_text": "## Das Problem mit Cloud-Passwort-Tresoren\n\nDie meisten Passwort-Tresore setzen auf ein Cloud-Konto mit Passwort-Reset per E-Mail. Praktisch, solange nichts schiefgeht. Sobald aber ein E-Mail-Konto kompromittiert wird, wird genau dieser Komfort zur Angriffsfläche: Wer die E-Mail kontrolliert, kann oft auch den Tresor zurücksetzen.\n\n## Physische Hardware-Bindung statt Account-Zwang\n\nKorers bindet Verschlüsselung stattdessen direkt an die eigene Hardware über TPM 2.0. Ohne den physischen Chip gibt es keinen Zugriff, keinen Passwort-Reset per E-Mail und keine Hintertür über ein zentrales Konto. Der Tresor ist an ein konkretes Gerät gebunden, nicht an eine Identität in der Cloud, die theoretisch von überall aus angegriffen werden kann.\n\n## Offline-First als Grundprinzip\n\nKorers funktioniert vollständig ohne Internetverbindung. AES-256-GCM-Verschlüsselung und lokale Schlüsselableitung laufen komplett auf dem Gerät, ohne Abhängigkeit von externen APIs. Ein Angreifer, der keinen physischen Zugriff auf das Gerät hat, kommt an die gespeicherten Daten grundsätzlich nicht heran.\n\n## Integrierter Täuschungsschutz für den Ernstfall\n\nFür Situationen, in denen jemand unter Zwang zur Herausgabe des Zugangs gedrängt wird, gibt es einen Duress-Modus: Unter Zwang öffnet sich ein täuschend echter Decoy-Tresor mit harmlosen Daten. Der echte Tresor bleibt dabei unsichtbar und gesperrt, ohne dass die Aktivierung des Täuschungsmodus für Außenstehende erkennbar wäre.\n\n## Manipulationssichere Nachvollziehbarkeit\n\nJede Aktion wird kryptografisch signiert und in einer unveränderlichen Audit-Kette festgeschrieben, per HMAC-SHA256. Offboarding, also das vollständige Entziehen eines Zugriffs, dauert dabei unter 5 Sekunden, und eine nachträgliche Manipulation der Protokollierung ist technisch ausgeschlossen.\n\n## Warum Open Source hier kein Widerspruch zu Sicherheit ist\n\nKorers ist bewusst quelloffen. Sicherheit durch Verschleierung, also die Hoffnung, dass ein Angreifer den Code einfach nicht kennt, ist keine belastbare Strategie. Ein offener, prüfbarer Kern schafft stattdessen echtes Vertrauen, weil jeder die tatsächliche Funktionsweise nachvollziehen kann, statt sie glauben zu müssen.\n\n## Wichtige Erkenntnisse aus diesem Beitrag\n\nCloud-Passwort-Tresore mit E-Mail-Reset schaffen eine zusätzliche Angriffsfläche über das E-Mail-Konto. Korers bindet den Zugriff stattdessen über TPM 2.0 direkt an die physische Hardware, offline-first, mit AES-256-GCM. Ein Duress-Modus mit Decoy-Tresor schützt auch unter physischem Zwang, ohne dass die Aktivierung erkennbar ist. Eine manipulationssichere Audit-Kette und ein offener, quelloffener Kern sorgen für echte statt behauptete Nachvollziehbarkeit.", "date_published": "2026-05-22T09:00:00Z", "date_modified": "2026-08-15T10:00:00Z", "authors": [ { "name": "Adnan" } ], "tags": [ "korers", "tpm 2.0", "passwort tresor", "open source", "aes-256-gcm", "duress mode" ] }, { "id": "7", "url": "https://jamoneai.de/blog/next-gen-erp-immutable-event-sourcing", "title": "Next Gen ERP: Warum ein Datenbank-Update nicht die einzige Wahrheit sein sollte", "summary": "Next Gen ERP rekonstruiert Geschäftsberichte aus einem unveränderbaren Event-Stream statt aus einer trägen, überschreibbaren Datenbank. Souverän, GoBD-konform, ohne Abo und ohne Vendor-Lock-in.", "content_text": "## Das stille Problem klassischer ERP-Datenbanken\n\nEin klassisches ERP-System speichert in der Regel nur den aktuellen Zustand: der aktuelle Lagerbestand, der aktuelle Kontostand, der aktuelle Auftragsstatus. Jede Änderung überschreibt den vorherigen Wert. Was genau wann warum geändert wurde, lässt sich oft nur bruchstückhaft aus separaten Log-Tabellen rekonstruieren, wenn überhaupt.\n\nFür die Revisionssicherheit und für echtes Verständnis, wie ein Geschäftsjahr tatsächlich verlaufen ist, ist das eine schwache Grundlage.\n\n## Event-Sourcing als andere Grundannahme\n\nNext Gen ERP dreht dieses Prinzip um. Statt riesiger, träger Datenbanken und teurer Monats-Abos rekonstruiert ein Event-Sourcing-Algorithmus Geschäftsberichte lokal aus einem unveränderbaren Event-Stream. Jede Transaktion wird als kryptografisch signiertes Ereignis festgeschrieben, nicht als Überschreibung eines alten Werts. Der aktuelle Zustand ist damit kein gespeicherter Wert mehr, sondern ein jederzeit neu berechenbares Ergebnis der vollständigen Historie.\n\n## On-Device statt Cloud-Abhängigkeit\n\nNext Gen ERP arbeitet vollständig auf dem eigenen Gerät: eine lokale SQLite-Instanz, AES-256-Verschlüsselung und eine GoBD-konforme Archivierung. Es gibt keine monatliche Cloud-Miete und keine Abhängigkeit von der Verfügbarkeit eines externen Anbieters, um an die eigenen Geschäftsdaten zu kommen.\n\n## Hardware-Integrität statt Passwort-Rätselraten\n\nZeitstempel, TSE-Hardware-Signaturketten und lokale PBKDF2-Hashes werden deterministisch miteinander verknüpft, statt Zugriffe über unsichere Web-Logins zu verwalten. Diese Verankerung in der Hardware macht es deutlich schwerer, nachträglich unbemerkt in die Datenbasis einzugreifen, ein Unterschied, der bei einer Steuerprüfung oder einem internen Audit zählt.\n\n## Sicherheitsarchitektur statt Datenexposition\n\nJede Transaktion wird als kryptografisch signiertes Ereignis festgeschrieben. Unbemerkte Änderungen sind damit technisch ausgeschlossen, es gibt kein heimliches Tracking von außen, und es gibt keinen Vendor-Lock-in, der ein Unternehmen an einen einzelnen Anbieter bindet. Das System gehört dem Unternehmen, nicht umgekehrt.\n\n## Wichtige Erkenntnisse aus diesem Beitrag\n\nKlassische ERP-Datenbanken speichern meist nur den aktuellen Zustand, die Historie bleibt bruchstückhaft. Next Gen ERP rekonstruiert den aktuellen Zustand stattdessen jederzeit aus einem unveränderbaren, kryptografisch signierten Event-Stream. Die gesamte Verarbeitung läuft lokal, mit AES-256-Verschlüsselung und GoBD-konformer Archivierung, ohne Cloud-Abo. TSE-Hardware-Signaturketten und PBKDF2-Hashes verankern die Integrität in der Hardware statt in einem unsicheren Web-Login.", "date_published": "2026-05-15T09:00:00Z", "date_modified": "2026-08-15T10:00:00Z", "authors": [ { "name": "Adnan" } ], "tags": [ "next gen erp", "event sourcing", "gobd", "aes-256", "erp", "souveränität" ] }, { "id": "6", "url": "https://jamoneai.de/blog/anrufbox-on-premise-voice-agi", "title": "Anrufbox: Ein KI-Telefonagent, der nicht über einen fremden Cloud-Vermittler läuft", "summary": "Die Anrufbox übernimmt Telefonate vollautomatisch, direkt über den eigenen SIP-Stack und die eigene FritzBox, ohne Umweg über Twilio oder andere Cloud-Vermittler.", "content_text": "## Warum Telefonie oft der letzte unautomatisierte Kanal ist\n\nTickets, E-Mails, Chats, für fast jeden Kommunikationskanal gibt es längst Automatisierung. Das Telefon bleibt in vielen Unternehmen trotzdem der Kanal, an dem am Ende doch wieder ein Mensch abnehmen muss, selbst für wiederkehrende, eigentlich einfache Anfragen. Ein Grund dafür: klassische Voice-AI-Lösungen laufen fast immer über einen Cloud-Vermittler, der Gesprächsdaten mitschneidet und weiterverarbeitet.\n\n## Direkt an der eigenen Telefonanlage\n\nDie Anrufbox geht einen anderen Weg. Über einen strukturierten SIP-Stack bindet sie Telefonanlagen wie die FritzBox direkt an, ohne Umweg über Twilio oder einen anderen Cloud-Vermittler. Anrufernummern, Zeitstempel, Audiosignale und DTMF-Töne werden nativ erkannt und in verwertbare, lokal gespeicherte Protokolle übersetzt.\n\n## Deterministisches PII-Mapping statt Blackbox-Transkription\n\nEin zentraler Baustein ist das deterministische PII-Mapping: Identitäten werden lokal anonymisiert, ohne dass dabei Informationen verloren gehen und ohne DSGVO-Risiko. Anrufer bleiben für die interne Verarbeitung eindeutig zuordenbar, ohne dass Rohdaten unnötig lange oder unverschlüsselt vorgehalten werden müssen.\n\n## Alles bleibt im Haus\n\nProtokolle, Kontakte, Termine und Analyse laufen vollständig auf dem eigenen Rechner. FritzBox, Auswertung und Speicherung bilden eine geschlossene Kette, ohne dass ein externer Anbieter jemals Gesprächsinhalte zu Gesicht bekommt. Für Unternehmen mit strengen Vertraulichkeitsanforderungen, etwa im Gesundheits- oder Rechtswesen, ist das oft die Voraussetzung dafür, Telefonie überhaupt automatisieren zu dürfen.\n\n## Native Performance statt Container-Umwege\n\nDie Anrufbox ist für Windows- und Linux-Bare-Metal optimiert. Keine Container-Latenz, keine Virtualisierungs-Risiken, keine zusätzlichen Wartungsstaus durch eine Orchestrierungsschicht, die für diesen Anwendungsfall keinen echten Mehrwert bringt. Für ein System, das in Echtzeit auf eingehende Anrufe reagieren muss, zählt jede Millisekunde Verarbeitungszeit.\n\n## Wichtige Erkenntnisse aus diesem Beitrag\n\nTelefonie bleibt in vielen Unternehmen der letzte Kanal ohne echte Automatisierung, oft weil klassische Voice-AI über einen Cloud-Vermittler läuft. Die Anrufbox bindet Telefonanlagen wie die FritzBox direkt über SIP an, ganz ohne Twilio-Umweg. Deterministisches PII-Mapping anonymisiert Identitäten lokal, ohne Informationsverlust und ohne DSGVO-Risiko. Der native Bare-Metal-Betrieb sorgt für Reaktionsgeschwindigkeit ohne Container-Latenz.", "date_published": "2026-05-08T09:00:00Z", "date_modified": "2026-08-15T10:00:00Z", "authors": [ { "name": "Adnan" } ], "tags": [ "anrufbox", "voice ai", "sip", "fritzbox", "automatisierung", "on-premise" ] }, { "id": "5", "url": "https://jamoneai.de/blog/eurovault-lokale-pii-anonymisierung", "title": "EuroVault: Das Prinzip Hoffnung ist keine Datenschutzstrategie für KI-Prompts", "summary": "EuroVault maskiert sensible Daten lokal, bevor ein Prompt überhaupt eine KI erreicht. Enterprise-DLP für den KI-Alltag, Zero-Knowledge, DSGVO-konform by Design.", "content_text": "## Wie sensible Daten heute in KI-Tools landen\n\nEin Mitarbeiter kopiert eine Kundenanfrage in ein KI-Chat-Fenster, um schneller eine Antwort zu formulieren. Der Text enthält Name, Adresse, vielleicht eine Vertragsnummer. Niemand hat böse Absichten, es ist schlicht der schnellste Weg. Genau dieser alltägliche, gut gemeinte Reflex ist der Punkt, an dem in vielen Unternehmen unkontrolliert personenbezogene Daten an fremde Server abfließen.\n\n## Filterung am Endpunkt statt Hoffnung im Nachhinein\n\nEuroVault setzt genau an diesem Punkt an: direkt an Ihrem Endpunkt, bevor eine Anfrage überhaupt das Gerät verlässt. Statt darauf zu hoffen, dass schon nichts Sensibles im Text steht, ersetzt eine Engine sensible Werte automatisch durch Platzhalter, bevor die Anfrage rausgeht. Nur der lokale Client besitzt den Schlüssel, um eine spätere KI-Antwort wieder mit den echten Daten zu verknüpfen, ein Zero-Knowledge-Prinzip.\n\n## Warum Standard-Tools hier an ihre Grenzen stoßen\n\nHerkömmliche KI-Werkzeuge senden Prompts im Klartext direkt an fremde Server. Manche Anbieter speichern diese Inhalte sogar in globalen Trainingsdatensätzen weiter, oft ohne dass es dem einzelnen Nutzer im Moment der Eingabe bewusst ist. EuroVault arbeitet stattdessen autark auf dem eigenen Rechner, dezentral, ohne dass ein Daten-Leak überhaupt erst entstehen kann, weil die sensiblen Werte das Gerät nie in Klartext verlassen.\n\n## Wie die Maskierung technisch funktioniert\n\nBevor ein Prompt an ein Sprachmodell geht, erkennt und ersetzt EuroVault sensible Muster wie Namen, Adressen, Kontonummern oder interne Kennungen durch neutrale Platzhalter. Die KI arbeitet mit diesen Platzhaltern weiter, ihre Antwort kommt entsprechend ebenfalls mit Platzhaltern zurück. Erst der lokale Client, der allein den Zuordnungsschlüssel besitzt, löst die Platzhalter wieder in echte Werte auf. Ein Angreifer oder ein Cloud-Anbieter, der nur die Prompt-Daten sieht, sieht damit nie die echten personenbezogenen Informationen.\n\n## DSGVO-Konformität als Architekturentscheidung\n\nDSGVO-Konformität entsteht bei EuroVault nicht durch eine nachträgliche Richtlinie, sondern durch die Architektur selbst: Wenn sensible Daten technisch gar nicht erst unverschlüsselt das Gerät verlassen, ist die Frage nach der Rechtmäßigkeit der Verarbeitung an dieser Stelle bereits beantwortet. Das ist der Unterschied zwischen einer organisatorischen Regel, die im Alltag ignoriert werden kann, und einer technischen Barriere, die es nicht kann.\n\n## Wichtige Erkenntnisse aus diesem Beitrag\n\nSensible Daten landen im Alltag oft unbeabsichtigt in KI-Tools, einfach weil es der schnellste Weg zu einer Antwort ist. EuroVault maskiert diese Daten direkt am Endpunkt, bevor eine Anfrage das Gerät verlässt. Nur der lokale Client besitzt den Schlüssel, um Platzhalter später wieder mit echten Daten zu verknüpfen, ein echtes Zero-Knowledge-Prinzip. DSGVO-Konformität entsteht dadurch als Ergebnis der Architektur, nicht als nachträgliches Versprechen.", "date_published": "2026-05-01T09:00:00Z", "date_modified": "2026-08-15T10:00:00Z", "authors": [ { "name": "Adnan" } ], "tags": [ "eurovault", "pii", "dlp", "zero-knowledge", "dsgvo", "ki sicherheit" ] }, { "id": "4", "url": "https://jamoneai.de/blog/ai-ide-lokale-multi-agenten-entwicklungsumgebung", "title": "AI IDE: Wenn der Editor mehr wird als ein Werkzeug mit Autovervollständigung", "summary": "AI IDE ersetzt Suchen-und-Kopieren durch eine native Multi-Agenten-Architektur, die Aufgaben im Autopilot-Modus direkt auf dem Dateisystem ausführt, vollständig lokal, ohne Cloud-Anbindung.", "content_text": "## Was an klassischen Editoren fehlt\n\nAutovervollständigung und ein isoliertes Chat-Fenster sind mittlerweile Standard in fast jedem Editor. Was dabei aber fehlt: eine echte Verbindung zwischen dem, was die KI vorschlägt, und dem, was tatsächlich im Projekt passiert. Der Entwickler bleibt der Klebstoff zwischen Vorschlag und Umsetzung, kopiert, passt an, testet, wiederholt.\n\n## Ein zentrales Operations-Center statt Tool-Fragmentierung\n\nAI IDE geht einen anderen Weg. Statt vieler einzelner Werkzeuge nebeneinander entsteht ein zentrales Ökosystem auf dem eigenen Rechner: von der ersten Zeile Code über die Projektplanung bis zur KI-gesteuerten Analyse, alles in einer Oberfläche. Eine native Multi-Agenten-Architektur übernimmt dabei Aufgaben im Autopilot-Modus direkt auf dem Dateisystem, nicht nur als Textvorschlag im Chat-Fenster.\n\n## Kontrolle bleibt beim Menschen\n\nSo viel Automatisierung braucht eine ebenso klare Kontrollinstanz. Bevor eine kritische System-Operation oder ein Mail-Versand erfolgt, prüft ein File-Access-Guard die Berechtigung. Ohne diesen Human-in-the-Loop-Check bleibt jede autonome Aktion technisch unterbunden, die Autonomie der Agenten endet dort, wo echte Konsequenzen entstehen.\n\n## Warum lokal, warum Tauri und Rust\n\nDie gesamte Logik läuft lokal über Tauri und Rust, keine Zeile Code verlässt dabei die eigene Maschine. Das ist nicht nur ein Sicherheitsargument, sondern bei Compliance-Audits ein technischer Nachweis: sensible Unternehmensdaten sind nie unkontrolliert in eine fremde Cloud abgeflossen, weil es diesen Weg architektonisch gar nicht gibt.\n\n## Für wen sich das lohnt\n\nBesonders relevant ist das für Teams, die mit sensiblem oder proprietärem Code arbeiten und klassische Cloud-KI-Assistenten deshalb nicht oder nur eingeschränkt einsetzen dürfen. Aber auch für einzelne Entwickler, die eine durchgängige, statt einer fragmentierten Werkzeuglandschaft bevorzugen, ist die zentrale Oberfläche ein spürbarer Unterschied im Alltag.\n\n## Wichtige Erkenntnisse aus diesem Beitrag\n\nKlassische Editoren verbinden KI-Vorschläge nicht direkt mit der tatsächlichen Umsetzung, der Mensch bleibt der Klebstoff dazwischen. AI IDE ersetzt das durch eine native Multi-Agenten-Architektur, die Aufgaben im Autopilot-Modus direkt ausführt. Ein File-Access-Guard sorgt dafür, dass kritische Aktionen ohne menschliche Freigabe technisch unterbunden bleiben. Weil die gesamte Logik lokal über Tauri und Rust läuft, verlässt kein Code die eigene Maschine, ein belastbarer Nachweis bei Compliance-Audits.", "date_published": "2026-04-24T09:00:00Z", "date_modified": "2026-08-15T10:00:00Z", "authors": [ { "name": "Adnan" } ], "tags": [ "ai ide", "tauri", "rust", "multi-agent", "entwicklung", "lokale ki" ] }, { "id": "3", "url": "https://jamoneai.de/blog/axiom-one-formale-verifikation-mit-z3", "title": "AXIOM One: Warum plausibel klingen nicht dasselbe ist wie beweisbar richtig sein", "summary": "AXIOM One prüft KI-Entscheidungen nicht statistisch, sondern mathematisch, mit dem Z3-SMT-Solver, in unter 25 Millisekunden. Ein deterministischer Safety-Core für Branchen, in denen Raten keine Option ist.", "content_text": "## Das strukturelle Problem heutiger Sprachmodelle\n\nEin Sprachmodell berechnet die statistisch wahrscheinlichste nächste Antwort. Das funktioniert überraschend gut für viele Alltagsfragen, aber es bleibt eine Wahrscheinlichkeitsaussage, keine Garantie. Bei Fragen, die sich auf klare Regeln, Schwellenwerte oder Berechnungen reduzieren lassen, reicht Wahrscheinlichkeit nicht aus. In Logistik, Bankwesen oder Katastrophenhilfe kann eine falsch klingende, aber selbstbewusst formulierte Antwort echten Schaden anrichten.\n\n## Die andere Herangehensweise von AXIOM One\n\nAXIOM One verifiziert jede Entscheidung zusätzlich mit dem Z3-SMT-Solver von Microsoft Research, unabhängig vom Sprachmodell selbst, in rund 21 Millisekunden. Statt zu schätzen, prüft das System die Entscheidung formal gegen reale Domain-Constraints: Ressourcen, Budgets, Zeitstempel und physische Kapazitäten werden deterministisch verknüpft und in mathematische Bedingungen übersetzt, nicht aus Trainingsdaten extrapoliert.\n\nDas Ergebnis ist entweder ein formaler Beweis, dass eine Entscheidung korrekt ist, oder eine erkannte Constraint-Verletzung, die gestoppt und protokolliert wird, bevor sie ausgeführt wird.\n\n## Eine mathematische Firewall vor der Ausführung\n\nBevor eine KI-Entscheidung tatsächlich ausgeführt wird, beweist AXIOM One deren Korrektheit gegen die hinterlegten Business-Rules, in der Regel unter 25 Millisekunden. Jede Abweichung wird als Constraint-Verletzung erkannt und protokolliert, nicht stillschweigend durchgewunken. Für regulierte Branchen ist das der entscheidende Unterschied: nicht \"das Modell war sich sicher\", sondern \"das System hat es bewiesen\".\n\n## Warum das gerade für regulierte Branchen zählt\n\nJede Entscheidung in Bereichen wie Logistik, Bankwesen oder Katastrophenhilfe findet bei AXIOM One ausschließlich im gesicherten, formalen Raum statt. Das Ziel ist hundertprozentige Korrektheit dort, wo sie geprüft werden kann, kombiniert mit voller Audit-Fähigkeit: jede Entscheidung lässt sich im Nachhinein nachvollziehen und belegen, nicht nur behaupten.\n\n## Wo formale Verifikation an ihre Grenzen stößt\n\nNicht jede Frage lässt sich in eine formale Bedingung übersetzen. Kreative, offene oder stark kontextabhängige Aufgaben profitieren von einem klassischen Sprachmodell mehr als von einem Solver. Der Wert von AXIOM One liegt genau in der Kombination: das Sprachmodell für die Breite, der Z3-Kern für die Fälle, in denen eine falsche Antwort echte Konsequenzen hätte.\n\n## Wichtige Erkenntnisse aus diesem Beitrag\n\nStatistische Wahrscheinlichkeit ist keine Garantie für Korrektheit, gerade bei folgenreichen Entscheidungen reicht das nicht aus. AXIOM One prüft Entscheidungen zusätzlich mit dem Z3-SMT-Solver, unabhängig vom Sprachmodell, in unter 25 Millisekunden. Ressourcen, Budgets und Zeitstempel werden deterministisch verknüpft statt aus Trainingsdaten geschätzt. Für Logistik, Bankwesen und Katastrophenhilfe entsteht damit volle Audit-Fähigkeit statt bloßer Plausibilität.", "date_published": "2026-04-17T09:00:00Z", "date_modified": "2026-08-15T10:00:00Z", "authors": [ { "name": "Adnan" } ], "tags": [ "axiom one", "z3", "formale verifikation", "smt solver", "rust", "sicherheit" ] }, { "id": "2", "url": "https://jamoneai.de/blog/openglue-multi-agent-diskurs-engine", "title": "OpenGlue: Warum ein einzelnes Sprachmodell nicht immer die beste Antwort gibt", "summary": "OpenGlue lässt mehrere KI-Agenten intern gegeneinander argumentieren, statt eine einzelne, unwidersprochene Antwort auszugeben. Lokal, forensisch nachvollziehbar und ohne Cloud-Halluzinationen.", "content_text": "## Das Problem mit der einen richtigen Antwort\n\nKlassische KI-Chat-Systeme funktionieren nach einem einfachen Muster: eine Frage rein, ein Sprachmodell, eine Antwort raus. Diese Antwort klingt fast immer selbstbewusst, unabhängig davon, ob sie tatsächlich stimmt. Es gibt keinen eingebauten Mechanismus, der eine eigene Aussage in Frage stellt, bevor sie ausgegeben wird.\n\nBei einfachen Fragen ist das meist unproblematisch. Bei komplexen, mehrdeutigen oder folgenreichen Entscheidungen ist genau das die Schwachstelle: Ein Modell, das sich nie selbst widerspricht, wirkt überzeugender, als es oft sein sollte.\n\n## Die Idee hinter OpenGlue\n\nOpenGlue setzt an dieser Stelle an. Statt eine Anfrage an ein einzelnes Modell zu schicken, orchestriert OpenGlue mehrere spezialisierte Agenten, die intern einen dialektischen Diskurs führen: These, Gegenrede, Synthese. Jeder Agent bringt eine andere Perspektive oder Prüfrolle ein, bevor eine gemeinsame Antwort entsteht.\n\nDas Ergebnis ist kein einfacher Mehrheitsentscheid, sondern ein strukturierter Abgleich unterschiedlicher Blickwinkel auf dieselbe Frage, lokal berechnet, ohne dass ein einzelnes Modell unwidersprochen bleibt.\n\n## On-Device statt Cloud-Rundreise\n\nEin zentraler Unterschied zu vielen vergleichbaren Multi-Agent-Ansätzen: OpenGlue arbeitet vollständig auf dem eigenen Gerät. Lokale Vektoren, eigene Logik, eine interne E-Mail-Brücke für asynchrone Abläufe, alles autark. Es gibt keine API, die im Hintergrund Daten an einen fremden Server schickt, und keine Abhängigkeit von der Verfügbarkeit eines Cloud-Anbieters.\n\nDas ist mehr als eine Datenschutzfrage. Jede zusätzliche Cloud-Rundreise ist auch eine zusätzliche Fehlerquelle und eine zusätzliche Verzögerung. On-Device-Verarbeitung eliminiert beides gleichzeitig.\n\n## Forensische Nachvollziehbarkeit statt Black Box\n\nOpenGlue nutzt einen isolierten Hardware-Intent-Kernel: Zeitstempel, lokale Dateien, Agenten-Identitäten und Nutzereingaben werden deterministisch miteinander verknüpft und in forensische Protokolle übersetzt. Jede Entscheidung findet ausschließlich im gesicherten, lokalen Speicher statt, ohne Logs, die das Haus verlassen, ohne Training an fremden Daten, ohne unkontrolliertes Tracking.\n\nFür Organisationen entsteht dadurch ein System, das digitale Autonomie nicht nur behauptet, sondern durch die Architektur selbst garantiert.\n\n## Wann sich dieser Aufwand lohnt\n\nNicht jede Anfrage braucht einen internen Diskurs zwischen mehreren Agenten, das wäre unnötiger Overhead für eine einfache Frage. Sinnvoll wird der Ansatz dort, wo Entscheidungen mehrdeutig sind, wo unterschiedliche Fachperspektiven kollidieren können, oder wo die Nachvollziehbarkeit einer Antwort genauso wichtig ist wie die Antwort selbst, etwa bei internen Analyseprozessen, die später geprüft werden müssen.\n\n## Wichtige Erkenntnisse aus diesem Beitrag\n\nEin einzelnes Sprachmodell hat keinen eingebauten Mechanismus, sich selbst zu widersprechen, bevor es antwortet. OpenGlue ersetzt das durch mehrere Agenten, die intern argumentieren, bevor eine gemeinsame Antwort entsteht. Die gesamte Verarbeitung läuft lokal auf dem Gerät, ohne Cloud-Abhängigkeit und ohne API-Umweg. Ein forensischer Hardware-Intent-Kernel macht jede Entscheidung nachvollziehbar, statt sie als Black Box zu behandeln.", "date_published": "2026-04-10T09:00:00Z", "date_modified": "2026-08-15T10:00:00Z", "authors": [ { "name": "Adnan" } ], "tags": [ "openglue", "multi-agent", "on-device", "ki", "sandboxing", "sovereign ai" ] }, { "id": "1", "url": "https://jamoneai.de/blog/ecap-bot-zugangskontrolle-via-ecdsa-token", "title": "ECAP: Warum ein Robots.txt-Eintrag heute nicht mehr reicht", "summary": "ECAP ersetzt das passive Bitte-nicht-betreten von robots.txt durch eine kryptografisch signierte Zutrittskontrolle für Bots und KI-Crawler. Ein technisches Protokoll statt eines Höflichkeitshinweises.", "content_text": "## Das Problem mit robots.txt\n\nEine Textdatei im Wurzelverzeichnis einer Website, die seit über 25 Jahren als einziger Schutzmechanismus gegen automatisierten Zugriff dient: das ist robots.txt. Sie war nie ein Gesetz, sondern ein Zeichen von Respekt. Die Website legt fest, was erlaubt ist, der Crawler hält sich daran, freiwillig.\n\nGenau diese Freiwilligkeit ist heute das Problem. KI-Systeme durchsuchen Inhalte in einem Umfang, der beim Entwurf von robots.txt niemand vorhersehen konnte, und ein wachsender Teil davon hält sich schlicht nicht an die Vorgaben der Datei. Es gibt keine technische Konsequenz, wenn ein Crawler robots.txt einfach ignoriert. Kein Login, kein Zertifikat, kein Beweis, wer da eigentlich zugreift und wozu.\n\nAus diesem Missverhältnis zwischen Anspruch und technischer Durchsetzbarkeit ist ECAP entstanden, ein kryptografisches Lizenzprotokoll, das ich für genau dieses Problem gebaut habe.\n\n## Was ECAP ist, und was nicht\n\nECAP ist ein Protokoll, das über HTTP-Header und eine maschinenlesbare Policy-Datei arbeitet. Es ist ein Handshake, bei dem jeder Zugriff verifizierbar wird, und eine Audit-Ebene, die lückenlos festhält, wer wann wofür zugreifen durfte.\n\nECAP ist ausdrücklich kein Anti-KI-Werkzeug. Es ist kein Verbot, sondern ein Rahmen: Maschinen dürfen lernen, aber sie sollen sich vorher ausweisen und an dokumentierte Vereinbarungen halten. Es ist auch keine Firewall und kein DDoS-Schutz, dafür gibt es andere Werkzeuge. ECAP löst ein anderes Problem: aus anonymen Zugriffen nachvollziehbare, verantwortbare Beziehungen zu machen.\n\n## Der digitale Handschlag im Detail\n\nEin klassischer Crawler-Zugriff läuft heute in drei Schritten ab: User-Agent-Header setzen, Anfrage senden, Antwort verarbeiten. Ob der Zugriff erlaubt war, wie die Daten genutzt werden und ob das mit den Zielen der Website vereinbar ist, bleibt dabei komplett im Dunkeln.\n\nMit ECAP sieht derselbe Zugriff anders aus. Der Agent stellt sich zunächst über zusätzliche Header vor, darunter eine Protokollversion, eine eindeutige Agenten-ID und den konkreten Nutzungszweck, etwa Indexierung, Recherche oder Modelltraining. Der Host verweist im Gegenzug auf eine maschinenlesbare Policy-Datei unter einem festen Pfad, in der Zugriffszwecke, gesperrte Bereiche und Gültigkeitsdauer definiert sind.\n\nDie eigentliche Anfrage wird anschließend mit einem privaten Schlüssel kryptografisch signiert, ECDSA-basiert. Damit lässt sich prüfen, ob der Absender echt ist, ob die Anfrage manipuliert wurde, und später beweisen, dass genau dieser Zugriff wirklich stattgefunden hat. Der Host gleicht Zweck, Signatur und Zeitstempel gegen seine Policy ab und trifft eine dokumentierte Entscheidung: Zugriff genehmigt, aus ethischen Gründen abgelehnt, Zustimmung fehlt oder Ressource gesperrt.\n\nJeder dieser Handschläge wird als Ereignis manipulationssicher gespeichert und über eine Hash-Kette mit dem vorherigen Ereignis verknüpft. Eine nachträgliche Änderung an Inhalt oder Reihenfolge bricht diese Kette und ist damit erkennbar, nicht nur behauptet.\n\n## Warum das über Technik hinausgeht\n\nMan könnte ECAP rein technisch als Header-Standard, Signaturmodell und Audit-Log-Architektur beschreiben. Mir geht es aber um etwas Grundsätzlicheres: Maschinen sollen wieder bewusst handeln. Ein Agent muss seinen Zweck offenlegen, kein verstecktes Scraping mehr unter einem generischen User-Agent. Jede Zustimmung und jede Ablehnung ist später beweisbar, nicht nur behauptet. Betreiber von Crawlern können sich nicht mehr hinter einem anonymen System verstecken.\n\n## Für wen ECAP relevant ist\n\nVier Gruppen profitieren besonders von diesem Ansatz: Betreiber von KI-Plattformen, die Inhalte fair und nachweisbar nutzen wollen. Publisher und Blogger, die ihre Inhalte schützen, aber nicht komplett abschotten wollen. Betreiber von APIs und Datenplattformen, die kontrollierten Zugriff technisch durchsetzen müssen. Und Unternehmen, die Compliance-Anforderungen erfüllen müssen und dafür echtes, überprüfbares Audit-Logging brauchen, keine bloße Behauptung.\n\n## Wichtige Erkenntnisse aus diesem Beitrag\n\nECAP ergänzt robots.txt um verifizierbare, kryptografisch signierte Handschläge zwischen Agent und Host. Jede Anfrage wird mit Zweck, Identität und Signatur versehen und gegen eine maschinenlesbare Policy geprüft. Die Audit-Ebene macht Zustimmung, Ablehnung und Verhalten von Crawlern langfristig nachvollziehbar. Ziel ist nicht die Blockade von KI, sondern ein fairer, dokumentierter Umgang mit Inhalten, auf Protokollebene erzwungen statt nur höflich erbeten.", "date_published": "2026-04-03T09:00:00Z", "date_modified": "2026-08-15T10:00:00Z", "authors": [ { "name": "Adnan" } ], "tags": [ "ecap", "ethical crawling", "ecdsa", "ki", "protokoll", "dsgvo" ] } ], "_generatedAt": "2026-09-06T09:59:49.728Z" }