Compliance auf einer Seite
Wie Cogeto die technische Seite der Compliance belegbar macht, statt sie nur zu behaupten
Zuletzt aktualisiert: 2026-08-01
Cogeto macht aus den Dokumenten einer Organisation verifiziertes institutionelles Wissen: jeder Fakt auf seine Quelle zurückgeführt, vor der Speicherung verifiziert, gegen alles andere Gespeicherte auf Widersprüche geprüft und gegenüber Dritten belegbar. Jede Vertrauensaussage ist durch ein Artefakt gedeckt, das Sie einsehen können. Diese Seite fasst zusammen, wo Daten liegen, wie sie isoliert und geschützt sind, wie Löschung, Export und der signierte Befundbericht funktionieren, wer die Unterauftragsverarbeiter sind und wie sich das Design der EU-Regulierung zuordnen lässt. Wo eine Kontrolle organisatorisch oder vertraglich statt technisch ist, sagen wir das offen. Architektur allein ist keine Compliance: Sie ist der Teil der Compliance, den ein System beweisen kann.
Einseiter als PDF herunterladen(44 KB)PDF auf Englisch
Cogeto wird von MVT Solutions Group d.o.o. und MCTO Advisory d.o.o. entwickelt und betrieben, beide gegründet in Kroatien, in der Europäischen Union.
Bei einem verwalteten Deployment ist der Kunde der Verantwortliche, und das betreibende Unternehmen handelt als Auftragsverarbeiter im Auftrag des Kunden. Bei einem selbst gehosteten oder vollständig offline betriebenen Deployment betreibt der Kunde die Instanz selbst, und es findet keine Verarbeitung durch den Betreiber statt.
- Rollen: Die Rollen von Verantwortlichem und Auftragsverarbeiter werden je Deployment im Auftragsverarbeitungsvertrag festgelegt.
- Kontakt: hi@cogeto.eu
Jedes Deployment ist eine einzelne isolierte Instanz, die genau einen Kunden bedient und auf EU-Infrastruktur nach Wahl des Betreibers aufgesetzt wird. Pro Kunde gibt es eine Komposition aus Anwendungsprozessen, relationaler Datenbank, Vektorindex, Objektspeicher und Edge-Proxy.
- Verwaltete EU-Cloud: Betrieb auf EU-Infrastruktur unter EU-Datenbedingungen.
- Ihre Server: Hosten Sie den vollständigen Stack selbst auf Ihrer eigenen Infrastruktur.
- Offline-Betrieb: Vollständig isoliert, nur lokale Modelle, nichts verlässt die Maschine.
- Modellresidenz: Der Standardanbieter für gehostete Modelle ist europäisch; die Modellschicht kann vollständig auf lokale Modelle umgestellt werden, sodass externer Modellverkehr auf null sinkt.
Die Isolation ist Single-Tenant per Konstruktion, keine Konfigurationsoption. Weil jeder Kunde eine eigene Instanz betreibt, gibt es keinen geteilten Index, keinen geteilten Cache und keine geteilte Warteschlange, in denen die Daten eines Kunden je neben denen eines anderen liegen könnten, und keinen Sammelspeicher, dessen Zugriffskontrolle man vertrauen müsste.
Das Restrisiko benennen wir offen: Ein kompromittierter Host kompromittiert seine eigene Instanz, wie in jedem Single-Tenant-Design. Der Wirkungsradius eines solchen Ereignisses ist ein Kunde, und genau das ist der Sinn des Isolationsmodells.
- Kein Mitmieter: Ein Kunde pro Instanz; es existiert kein mandantenübergreifender Datenpfad, den man absichern müsste.
Bei der Übertragung endet die Transportsicherheit am Edge-Proxy der Instanz, und jeder Anwendungsendpunkt verlangt Authentifizierung, bevor er antwortet.
Im Ruhezustand sind Originaldokumente im Objektspeicher und auf den Volumes des Hosts verschlüsselt, und Konnektor-Zugangsdaten werden vor der Speicherung zusätzlich auf Anwendungsebene verschlüsselt.
- Schlüsselhandhabung: Objektspeicher-Schlüssel sind nach Organisation, Benutzer und Sichtbarkeit begrenzt, und Originale sind nur über kurzlebige signierte URLs erreichbar, die durch die Sensibilitätsmarkierung geschützt sind.
Eine Löschquittung ist ein ablagefähiger, verifizierbarer Nachweis, dass eine Löschung stattgefunden hat und was genau sie entfernt hat. Das Löschen einer Quelle führt ein kompensierendes Protokoll in fünf Schritten über den relationalen Speicher, den Vektorindex und den Objektspeicher aus und endet in einer signierten Quittung.
Jede Quittung hält die Quelle fest, die Zahl der entfernten Wissenseinträge, Vektorpunkte und Bytes sowie die Zeitstempel für Einleitung und Bestätigung. Sie ist mit dem Instanzschlüssel signiert und mit ihrer Vorgängerin verkettet, sodass keine Quittung nachträglich verändert oder entfernt werden kann, ohne die Kette zu brechen. Ein nächtlicher Lauf prüft erneut, dass nichts Gelöschtes noch existiert, und macht so aus jeder Quittung statt einer Absichtserklärung eine fortlaufend neu verifizierte Tatsachenfeststellung.
Ehrliche Einschränkung. Quittungen belegen die Entfernung aus den eigenen Speichern des Systems. Sie können Inhalte, die ein externer Modellanbieter unter dessen Bedingungen bereits verarbeitet hat, nicht rückwirkend zurückholen, und genau deshalb ist die Löschung mit der Option der lokalen Modellisolation gekoppelt, die von vornherein begrenzt, was die Instanz überhaupt verlässt.
{
"id": "55555555-5555-4555-8555-555555555555",
"source_type": "user_note",
"source_id": "note-old",
"counts_json": {
"requested_by": "ana",
"enumerated_at": "2026-06-30T12:00:00.000Z",
"memory_count": 2,
"object_keys": []
},
"signed_at": "2026-06-30T12:00:03.000Z",
"confirmed_at": "2026-06-30T12:00:03.000Z",
"prev_hash": "cogeto:deletion-receipt-chain:genesis",
"hash": "0000000000000000000000000000000000000000000000000000000000000000",
"signature": "c2FtcGxlLXBsYWNlaG9sZGVyLXNpZ25hdHVyZS1ub3QtcmVhbA=="
}Es gibt keinen Lock-in. Jeder Benutzer kann alles exportieren, was er hält, von Fakten und ihren Status über Quellen und die vollständige Gültigkeitshistorie bis zu Löschquittungen, als ein einziges signiertes Archiv in einem offenen, dokumentierten, versionierten Format.
Das Format ist vollständig veröffentlicht. Ein Passport lässt sich allein mit den öffentlichen Schemas und dem im Archiv enthaltenen öffentlichen Instanzschlüssel lesen und auf Integrität prüfen, ohne jeden Cogeto-Code oder -Dienst.
- Offenes Format: Eine einzelne .zip-Datei mit JSON je Dokument, jedes durch ein öffentliches JSON-Schema abgedeckt, plus eine separate Signatur über das Manifest.
Ein Befundbericht ist ein signierter, druckbarer Nachweis über eine ausdrücklich ausgewählte Menge von Quellen. Sein Kopf nennt die Instanz, den Korpusumfang, den Datumsbereich, die Modellkonfiguration und deren gemessene Genauigkeitswerte, sodass das Artefakt selbst die Genauigkeit des Systems ausweist, das es erzeugt hat.
Jeder Widerspruch erscheint mit beiden Aussagen, beiden wörtlichen Quellsätzen, dem Dokument mit Revision und Fundstelle für jede Seite, dem Erkennungsdatum und dem Auflösungsstatus. Ersetzte Aussagen erscheinen mit ihren Ketten, gefolgt von einer Zusammenfassung dessen, was die Verifikation verworfen hat. Befunde, die auf ein Dokument außerhalb des gewählten Umfangs verweisen, erscheinen in einem klar gekennzeichneten Randabschnitt, statt stillschweigend aufgenommen oder verworfen zu werden.
- Zwei Formate: PDF für Menschen, JSON für Qualitätssysteme, beide über denselben Pfad signiert wie Löschquittungen.
- Definierter Umfang: Die Signatur deckt eine ausdrücklich ausgewählte Dokumentenmenge ab, sodass auch das Geprüfte Teil des Nachweises ist.
Eingehende E-Mail ist standardmäßig deaktiviert und wird je Deployment nur aktiviert, wenn der Kunde es wünscht. Ist sie aktiviert, gelangt E-Mail ausschließlich per Weiterleitung in Cogeto: Das Deployment stellt eine dedizierte Eingangsadresse bereit, und der Benutzer oder sein Mailsystem leitet Nachrichten dorthin weiter. Cogeto verbindet sich nie mit einem Postfach.
Eine Absender-Positivliste steuert, welche Absender Material hineinleiten dürfen; Nachrichten von Absendern, die nicht auf der Liste stehen, werden nicht aufgenommen. Der Kanal ist reiner Empfang: kein Postfachzugriff, keine IMAP-Verbindung und kein OAuth-Scope für das Postfach, und Cogeto kann im Postfach des Benutzers nichts senden, löschen oder verändern.
- Standardmäßig aus: Der Dienst für eingehende E-Mail läuft nur, wenn er für das Deployment ausdrücklich aktiviert ist.
- Nur Empfang: Weiterleitung hinein ist der einzige Weg; nichts liest oder verändert das Quellpostfach.
- Absender-Positivliste: Nur freigegebene Absender können Material in das Wissen weiterleiten.
Die Liste der Unterauftragsverarbeiter hängt vom Deployment ab. Eine selbst gehostete oder vollständig offline betriebene Instanz kann ohne externe Unterauftragsverarbeiter jenseits der eigenen Infrastruktur des Kunden auskommen.
- Modell- und Embedding-Inferenz: Mistral AI, Paris, Frankreich (EU), für die gehostete Standardstufe. Es gelten Optionen europäischer Datenresidenz, die genauen Bedingungen werden je Deployment festgelegt. In einem vollständig isolierten Deployment wird kein externer Modellanbieter genutzt.
- Hosting und Infrastruktur: Die vom Betreiber für die Single-Tenant-Instanz gewählte EU-Cloud oder eigene Infrastruktur.
Wir behaupten nicht, dass Architektur allein Compliance darstellt, denn Compliance hat immer auch organisatorische und vertragliche Bestandteile. Wir behaupten, dass diese Architektur den technischen Anteil belegbar macht, statt ihn nur zu behaupten.
- DSGVO Art. 17, Recht auf Löschung: Das Löschprotokoll und seine hash-verketteten Quittungen geben der betroffenen Person nicht nur die Löschung, sondern auch den Nachweis darüber.
- DSGVO Art. 25, Datenschutz durch Technikgestaltung und durch datenschutzfreundliche Voreinstellungen: Single-Tenant-Isolation, verpflichtende Herkunftsnachweise, harte Sichtbarkeitsgrenzen, die im Speicher selbst durchgesetzt werden, Verschlüsselung im Ruhezustand und minimaler externer Datenfluss sind Eigenschaften der Architektur, keine Einstellungen darüber.
- AI Act, Transparenzhaltung: Das System ist gebaut, um seine Arbeit offenzulegen: ein Quellenlink an jedem Fakt, ein expliziter Status an jeder Aussage, ein Audit-Eintrag zu jeder Aktion, veröffentlichte Prompts und veröffentlichte Genauigkeit auf der Seite der Genauigkeitswerte.
Jede Aussage auf dieser Seite entspricht einem Mechanismus im Produkt oder einer Datei im öffentlichen Repository. Lesen Sie das Whitepaper für das vollständige Design, die Seite der Genauigkeitswerte für die gemessene Genauigkeit und den Quellcode für den Code, der all das durchsetzt.