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 funktioniert es
Schrittplan für sichere, dezentrale Wissenserschließung aus Sicht einer Beschäftigten bzw. eines Beschäftigten im öffentlichen Dienst.
Suchanfrage in natürlicher Sprache
Die nutzende Person stellt eine Frage in der eigenen gesicherten Arbeitsumgebung.
Föderierte Suche
Teilnehmende Knoten durchsuchen unabhängig ihre eigenen lokalen Indizes. Die Daten bleiben an der Quelle: Dokumente und Indizes verlassen die besitzende Organisation nicht.
Lokale Relevanz- und Rechteprüfung
Jeder Knoten prüft je Dokument aus den lokalen Suchergebnissen, ob es für die Frage der nutzenden Person relevant ist und ob die anfragende Person RBAC/ReBAC-Rechte hat, es zu sehen.
Drei mögliche Ausgänge
Je nach Relevanz und Rechten folgt einer dieser Pfade. Wichtig: Für die nutzende Person sehen ‚kein Treffer‘ und ‚kein Zugang‘ gleich aus, sodass nicht erkennbar wird, dass etwas existiert, das sie nicht sehen darf.
1.Relevante Dokumente mit Zugang
Autorisierte Treffer werden mit Quellenangabe angezeigt.
Endpunkt: Die nutzende Person erhält den Inhalt im Arbeitskontext.
2.Keine relevanten Dokumente
Es gibt keinen Treffer. Die nutzende Person erhält kein Ergebnis.
Endpunkt: Ende der Sucherfahrung für die nutzende Person.
3.Relevante Dokumente ohne Zugang
Es gibt einen relevanten Treffer, aber die anfragende Person darf ihn nicht sehen. Die nutzende Person erhält dasselbe wie bei Ausgang 2: kein Ergebnis.
Fortsetzung: Im Hintergrund startet der Eigentümerpfad (Schritt 4.3).
Eigentümerentscheidung und Bereitstellung nach Genehmigung
Die KI entscheidet, welche geschützten Dokumente relevant genug sind, um Zugang dafür anzufordern. Die Dokumenteneigentümerseite erhält eine KI-generierte Zugriffsanfrage mit Erklärung, warum die anfragende Person Zugang braucht—ohne dass die anfragende Person von der Existenz des Dokuments erfährt. Die Eigentümerseite kann genehmigen, ablehnen oder um Klärung bitten (bei der anfragenden Person oder der zugrunde liegenden KI, ohne weitere Existence Leakage), ohne das Dokument freizugeben. Erst nach ausdrücklich erteiltem Zugang erscheint das Ergebnis in der Arbeitsumgebung der anfragenden Person.
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.