Sovera
Konzeptphase: Suche nach Pilot- und F&E-Partnern
Öffentliches Wissen dort finden, wo es entsteht
Über Organisationsgrenzen hinweg—ohne es zu verschieben
Beschäftigte im öffentlichen Dienst sollten nicht in jeder Kommune, jedem Ministerium oder jeder Sicherheitsregion dieselbe Lösung neu bauen müssen. Sovera ist ein Konzept für eine souveräne, föderierte Such- und Arbeitsschicht, mit der berechtigte Mitarbeitende Wissen über teilnehmende Organisationen hinweg abfragen könnten—während Daten an der Quelle bleiben, unter lokaler Kontrolle.
Das strukturelle Problem
Öffentliche Organisationen verfügen über umfangreiches Politikwissen, Fallerfahrung und operatives Know-how—zersplittert über Systeme, Abteilungen und Zuständigkeiten. Die Folge: doppelte Arbeit, langsame Koordination und blinde Flecken bei komplexen Fällen.
Zweckbindung und Datenminimierung nach DSGVO Artikel 5, Vertraulichkeitspflichten und BIO-Sicherheitsanforderungen machen wahllose zentrale Kopien ungeeignet. Cloud-Copiloten und generische Suchtools fehlen die föderierte Autorisierung, die öffentliche Arbeit braucht.
Das Rad neu erfinden
Wenn eine Kommune eine Wohnungs-, Schulden- oder Jugendhilfeherausforderung löst, profitieren andere selten davon. Peers starten bei Problemen, die andernorts bereits gelöst wurden, wieder bei null.
Rechtliche Grenzen der Zentralisierung
Sensible öffentliche Daten lassen sich nicht einfach zusammenführen. Getrennte Transparenzregime wie das niederländische Woo regeln den öffentlichen Zugang zu Behördeninformationen und sind kein primärer Anti-Zentralisierungsrahmen.
Werkzeuge, die nicht zur Behördenarbeit passen
Cloud-KI-Copiloten können vieles von dem, womit Beschäftigte im öffentlichen Dienst täglich arbeiten, nicht verarbeiten. Generische Suche fehlt föderierte Autorisierung. Individuelle ETL-Pipelines sind langsam, teuer und schwer wartbar.
Vorgeschlagenes Design: Lokale Autorisierung und eigentümergesteuerter Zugang
Sovera schlägt rechtebewusste Orchestrierung an jedem lokalen Knoten vor. Suche könnte organisationsübergreifend reichen; Daten würden nur wandern, wenn die Policy das ausdrücklich erlaubt.
Daten bleiben an der Quelle
Quelldokumente und lokale Indizes bleiben unter Kontrolle der Organisation, der sie gehören. Nur autorisierte Abfrage- und Ergebnisdaten würden Organisationsgrenzen überschreiten.
Autorisierung vor Offenlegung
Jeder Knoten würde die RBAC/ReBAC-Rechte der anfragenden Person lokal prüfen. Ein passendes Ergebnis würde nur zurückgegeben, wenn die anfragende Person bereits Zugriffsberechtigung hat.
Kein Treffersignal im Kontext der Anfrage
Gibt es keinen Treffer, wird nichts zurückgegeben. Gibt es einen Treffer, aber keinen Zugriff, geschieht genau dasselbe: kein Inhalt, Titel, Metadaten, Trefferzahl oder Status gelangt in den Suchkontext der anfragenden Seite—keine Existenzoffenbarung auf Anfrageseite.
Separater Zugangsprozess auf Eigentümerseite
Bei einem unzugänglichen Treffer könnte ein separater KI-gestützter Prozess die Dokumenteneigentümerin bzw. den -eigentümer kontaktieren und erklären, wer Zugang braucht und warum. Die Eigentümerseite kann genehmigen, ablehnen oder um Klärung bitten. Eine Ablehnung bleibt in der ursprünglichen Suche unsichtbar; erst nach Genehmigung könnte das Ergebnis verfügbar werden.
So ist der Ablauf gedacht
Aus Sicht einer Beschäftigten bzw. eines Beschäftigten im öffentlichen Dienst würde das vorgeschlagene Design sichere, dezentrale Retrieval in sechs Schritten orchestrieren:
Natürliche Anfrage
Die nutzende Person stellt eine Frage in der eigenen gesicherten Arbeitsumgebung.
Föderierte Suche
Teilnehmende Knoten durchsuchen unabhängig ihre lokalen Indizes.
Lokale Rechteprüfung
Jeder Knoten prüft sowohl Relevanz als auch die RBAC/ReBAC-Berechtigungen der anfragenden Person.
Autorisiertes Ergebnis oder stille Antwort
Autorisierte Treffer werden mit Provenienz zurückgegeben. Kein Treffer und unzugänglicher Treffer liefern der anfragenden Seite jeweils nichts.
Separate Eigentümerentscheidung
Bei einem unzugänglichen Treffer kann die Dokumenteneigentümerseite eine separate KI-gestützte Zugriffsanfrage erhalten. Sie kann genehmigen, ablehnen oder um Klärung bitten, ohne das Dokument preiszugeben.
Bereitstellung nach Genehmigung
Erst nach erteiltem Zugang kann das Ergebnis die Arbeitsumgebung der anfragenden Person erreichen.
Kandidaten für Pilotszenarien
Der erste Sovera-Pilot ist noch nicht ausgewählt. Wir suchen Partner im öffentlichen Sektor, um gemeinsam einen konkreten, wertvollen und rechtlich handhabbaren Anwendungsfall zu identifizieren. Die Szenarien unten illustrieren mögliche Richtungen—keine bestehenden Sovera-Fähigkeiten.
Von Peer-Kommunen lernen
Eine Kommune steht vor einer neuen Herausforderung, etwa der Umsetzung einer neuen Sozialpolitik. Heute starten Teams oft bei null. In einem Sovera-Pilot könnte eine Fachkraft föderiert über opt-in kommunale Quellen suchen: interne Vermerke bleiben intern, während veröffentlichte Leitlinien und geteilte Praktiken anderer Gemeinden auftauchen könnten.
Gemeinsam mit einem Pilotpartner würden wir einen begrenzten Anwendungsfall auswählen—basierend auf öffentlichem Nutzen, verfügbaren Quellen, rechtlicher Machbarkeit, messbaren Ergebnissen und der Bereitschaft teilnehmender Dateneigentümer.
Was noch erforscht und validiert werden muss
Sovera ist ein Konzept. Vor jedem Produktivbetrieb müssten die folgenden Punkte gemeinsam mit Pilot- und F&E-Partnern validiert werden:
Föderierte Retrieval
Relevanz, Latenz und Zuverlässigkeit organisationsübergreifender Suche ohne zentrale Indizes oder Data Lakes.
RBAC/ReBAC am Knoten
Korrekte lokale Bewertung der Anfragerrechte, sodass nur autorisierte Treffer die besitzende Organisation verlassen.
Eigentümergesteuerte Zugangsworkflows
KI-gestützte Anfragen, die Eigentümer informieren, ohne Existenz oder Inhalt in den Suchkontext der anfragenden Seite zu leaken.
Privacy, rechtliche Eignung und Assurance
Zweckbindung, Protokollierung und eine gültige Rechtsgrundlage je Anwendungsfall—plus künftige Konformitätstests, Sicherheitsbewertung und Drittassurance. Technologie schafft keine Erlaubnis zum Teilen.
Bezug zu FDS und aktueller Politik
Das Konzept baut auf Prometheons bestehender Arbeit an souveräner, On-Premises-Wissenssuche auf. Die vorgeschlagene föderierte Schicht würde relevante FDS-Prinzipien und -Standards umsetzen—als Vereinbarungsrahmen, nicht als Netz oder Plattform—, sodass autorisierte Abfragen über Diginetwerk und andere freigegebene Netze nach außen reichen könnten, niemals über einen zentralen Datenbroker.
Die politische Richtung ist klar: Die Interadministrative Datenstrategie (IBDS) und der FDS-Vereinbarungsrahmen brauchen funktionierende Werkzeuge, nicht nur Papiervereinbarungen. Zugleich identifizierte die DPIA zu Microsoft 365 Copilot der Regierung erhebliche Risiken bei Transparenz und Kontrolle über die Verarbeitung personenbezogener Daten. Ein souveränes, föderiertes Konzept adressiert beide Lücken.
Ausgerichtet an relevanten FDS-Prinzipien
Teilnehmende Sovera-Knoten würden relevante FDS-Vereinbarungen und -Standards umsetzen in den Bereichen:
Identität
Identität der anfragenden Person und organisatorischer Kontext nach vereinbarten Trust-Mustern.
Sicherer Austausch
Abfrage- und autorisierter Ergebnisverkehr über freigegebene Behördennetze.
Metadaten
Minimale, zweckgebundene Discovery-Metadaten ohne Offenlegung geschützter Inhalte.
Lokale Kontrolle
Jede Dateneigentümerin bzw. jeder Dateneigentümer behält Policy, Indexierungsumfang und Autorisierung auf dem eigenen Knoten.
Protokollierung
Prüfbare Aufzeichnung von Abfragen, Zugangsentscheidungen und Anfragen auf Eigentümerseite.
Provenienz
Zurückgegebene Ergebnisse tragen klare Quellenattribution.
Vorgeschlagenes Open-Core-Modell
Um souveräne öffentliche Infrastruktur zu unterstützen und Vendor-Lock-in zu verhindern, soll Sovera einem Open-Core-Modell folgen. Bis Repositories veröffentlicht sind, beschreibt Open Source das beabsichtigte Modell—nicht heute verfügbare Komponenten.
Open-Source-Basisknoten
Basisknoten und REST-API-Profil sollen Open Source werden. Nach Veröffentlichung verlinkt diese Seite direkt auf das Repository.
Kommerzielle Enterprise-Module
Prometheon würde Premium-Komponenten lizenzieren, darunter fortgeschrittene KI-Orchestrierung, Adapter für Legacy-Daten und erweiterte ReBAC-Autorisierungsmodelle.
Künftige Konformitäts- und Assurance-Dienste
Künftige Konformitätstests, Sicherheitsbewertung und Drittassurance würden helfen sicherzustellen, dass ausgerollte Knoten dem Sovera-Standard und relevanten BIO-Anforderungen entsprechen.
Partnern Sie mit uns
Zwei Wege stehen offen—ausgehend von einem echten operativen Problem, nicht von einer Folienpräsentation.