Bewahren Sie die Nachweise auf, die eine KI-Entscheidung erklären, ohne jedem sensiblen Prompt dieselbe Lebensdauer zu geben. Klassifizieren Sie Artefakte, trennen Sie zugriffsbeschränkte Nutzdaten von Release-Manifesten und behandeln Sie Fristablauf, Aufhebung einer Aufbewahrungssperre, Löschauftrag und verifizierte Löschung als unterschiedliche Zustände. Eine abgelaufene Frist erlaubt die Prüfung einer Löschung – sie beweist nicht, dass Daten verschwunden sind.
Dies ist ein technischer Entwurf mit einem ausgeführten synthetischen Policy-Test, keine Rechtsberatung, kein verbindlicher Aufbewahrungsplan und kein Compliance-Zertifikat. Qualifizierte Rechts- und Datenschutzverantwortliche müssen anwendbares Recht, Akteursrollen, Zwecke, Aufbewahrungspflichten und Ausnahmen prüfen, bevor Sie produktive Fristen oder irreversible Speichersperren konfigurieren.
Der Fehler: ein Container, unvereinbare Zwecke
Betrachten Sie einen hypothetischen Wartungsassistenten. Sein Betriebsereignis verweist auf einen Modellstand und eine Freigabeentscheidung. Sein Roh-Prompt enthält die Beschwerde eines Beschäftigten. Sein Evaluationsbericht unterstützt die Release-Prüfung. Liegen alle drei in einem gesperrten Container, hängt ihre Aufbewahrung von derselben Speichergrenze ab. Gemeinsames Löschen kann benötigte Nachweise zerstören; gemeinsames Behalten kann sensible Inhalte unnötig konservieren.
Die Architektur für Logging und Dokumentation beschreibt, welche Nachweise entstehen sollen. Dieser Beitrag behandelt eine andere Entscheidung: Wann darf jedes Artefakt den Speicher verlassen, welche Sperre gilt noch und was belegt den Abschluss? Die Übung zur Vorfallsbeweissicherung behandelt Erfassung und Integrität. Anschließend braucht die Sicherung einen geregelten Lebenszyklus statt einer unbegrenzten Ausnahme.
Recht als geprüfte Eingabe, nicht als fest codierten Timer behandeln
Die von EUR-Lex verlinkte konsolidierte KI-Verordnung wurde für diesen Beitrag am 25. Oktober 2026 abgerufen. Artikel 12 behandelt die Protokollierungsfähigkeit von Hochrisiko-KI-Systemen. Artikel 19 und 26 behandeln die Aufbewahrung durch Anbieter beziehungsweise Betreiber im jeweiligen Anwendungs- und Kontrollbereich. Daraus folgt keine allgemeine Anweisung, jeden Chatbot-Prompt dauerhaft zu speichern. Protokollierungsfähigkeit während der Systemlebensdauer und Aufbewahrung jedes einzelnen Nutzdatenobjekts sind unterschiedliche Fragen.
Übernehmen Sie eine Frist aus einer einzelnen Vorschrift nicht als globalen Standard. Lassen Sie prüfen, welche Vorschrift für Akteur, System, Artefakt und Zweck gilt und wie anderes Recht die Bewertung verändert. Konsolidierungen dienen der Dokumentation; authentische Amtsblattfassungen und qualifizierte Prüfung sind für die rechtliche Auslegung maßgeblich. Dieser Beitrag bestimmt keine Anwendungsdaten.
Der DSGVO-Text enthält insbesondere in Artikel 5 die Grundsätze der Datenminimierung und Speicherbegrenzung. Artikel 17 enthält zudem Voraussetzungen und Ausnahmen zur Löschung. Das erfordert eine abgegrenzte Prüfung – nicht die automatische Behauptung, Audit-Nachweise hätten immer Vorrang oder müssten immer gelöscht werden. Auch ein Hashwert, eine pseudonyme Kennung oder ein beschränkt zugängliches Manifest kann personenbezogen bleiben, wenn eine Person weiterhin zugeordnet werden kann.
Aufbewahrung nach Artefaktklasse planen
Erfassen Sie Zweck, verantwortliche Person, Artefaktklasse, genaue Objekt- und Versionsgrenze, Fristbeginn, genehmigte Dauer, Freigabereferenz, Policy-Revision, Sperrbefugnis, Löschablauf und Verifikationszustand. Bewahren Sie die genehmigte Begründung neben der Konfiguration auf. Eine fehlende Dauer oder ein ungeklärter Fristbeginn bedeutet Prüfbedarf – weder sofortige Löschung noch unbegrenzte Speicherung.
Definieren Sie die Zeitsemantik ausdrücklich. Ereigniszeit, Erfassungszeit und Stilllegung eines Releases sind nicht austauschbar. Dokumentieren Sie Zeitzone und maßgebliche Uhr. Beginnt eine Frist mit einem anderen Ereignis als der Objekterstellung, bildet ein Objektspeicher-Timer sie möglicherweise nicht direkt ab. Berechnen Sie die wirksame Grenze in der Policy-Schicht und prüfen Sie die Speicherkonfiguration separat. Testen Sie auch den exakten Grenzzeitpunkt.
| Artefaktklasse | Zu prüfender Zweck und Fristbeginn | Abschlussnachweis |
|---|---|---|
| Betriebsereignis | Ausführung erklären; ereignisbezogene Policy | Begrenzter Löschbeleg für Ereignis/Version |
| Beschränkter Prompt oder Antwort | Erforderliche Untersuchung; geprüfter Erfassungs-/Nutzungsbeginn | Nutzdatenlöschung und Register offener Kopien |
| Release-Manifest und Testbericht | Bewerteten Release stützen; geprüfter Release-Lebenszyklus | Genehmigte Entsorgung oder geprüfte Weitergeltung |
| Vorfallsnachweise mit Sperre | Abgegrenzte Fallbelege sichern; separate Sperrprüfung | Befugte Aufhebung, dann normale Policy-Prüfung |
Diese Klassen sind vorgeschlagene technische Kategorien, keine gesetzlichen Kategorien. Minimieren Sie die Nutzdatenerfassung bereits an der Quelle. Geben Sie beschränkten Inhalten eine eigene Zugriffs- und Speichergrenze, damit ein Release-Manifest verfügbar bleiben kann, ohne nebenbei den ursprünglichen Beschwerdetext aufzubewahren. Verschieben Sie den sensiblen Satz nicht in Dateinamen, Objekt-Tags oder Löschbelege und nennen das Datenminimierung.
Zwei Lebenszyklen, eine kontrollierte Herkunftsbeziehung
Die Grafik zeigt einen vorgeschlagenen Anwendungsablauf. Beschränkte Nutzdaten und minimaler Prüfbeleg erhalten jeweils eine geprüfte Policy. Ihre Beziehung ist eine zugriffsgeschützte Herkunftsreferenz, keine Aufforderung zum Duplizieren von Inhalten. Das Manifest dokumentiert Prüfgegenstand, verwendete Version, relevante Entscheidungen und bekannte Lücken. Ein Hashwert kann später einen Vergleich mit vorhandenen Bytes unterstützen; nach deren Löschung rekonstruiert er weder den Inhalt noch beweist er die Wahrheit der ursprünglichen Beobachtung.
Bewahren Sie nach der Nutzdatenlöschung nur die genehmigten Abschlussnachweise auf: begrenzte Objekt-/Versionsreferenz, Policy-Revision, Löschauftrag, Ergebnis, Prüfinstanz und offene Kopien. Auch dieser Beleg benötigt einen eigenen Zweck und eine Aufbewahrungsentscheidung. Der Nachweisabgleich für Releases kann prüfen, ob vorhandene Berichte einen Release unterstützen. Strukturelle Konsistenz macht Inhalt und Aufbewahrungsdauer jedoch nicht rechtlich ausreichend.
Sperren einzeln verwalten
Modellieren Sie jede Sperre mit Befugnis, Fallreferenz, Objektumfang, Beginn, Prüfverantwortung und Aufhebungsentscheidung. Das Aufheben von Fall A darf Fall B nicht freigeben. Ebenso beendet eine aufgehobene Sperre keine noch laufende zeitbasierte Aufbewahrung. Bewerten Sie vor dem Löschauftrag sämtliche geltenden Regeln erneut.
Liegt eine genehmigte Mindestaufbewahrungsgrenze hinter einer genehmigten spätesten Löschgrenze, muss das Ergebnis POLICY_CONFLICT lauten. Eskalieren Sie ebenso eine Sperre, die eine geprüfte Löschfrist verhindert. Weder stillschweigendes Wählen der längeren Frist noch Löschen trotz Sperre ist eine sichere Rechtsentscheidung für ein Skript. Das vorübergehende Anhalten automatischer destruktiver Aktionen ist eine technische Sicherung; es löst den Konflikt nicht und erlaubt keine unbegrenzte Aufbewahrung. Leiten Sie ihn zeitnah an benannte Rechts-, Datenschutz- und Nachweisverantwortliche weiter.
Azure WORM: die tatsächliche Schutzgrenze prüfen
Microsofts Dokumentation zu unveränderlichem Speicher unterscheidet zeitbasierte Aufbewahrung und Legal Holds. Der Fristablauf erlaubt eine Löschung, führt sie aber nicht aus. Ein Legal Hold besteht bis zur ausdrücklichen Aufhebung. Ein unabhängiger Schutz kann die Löschung weiterhin verhindern, nachdem ein anderer endet.
| Azure-Modus | Schutzumfang | Löschgrenze |
|---|---|---|
| Zeitpolicy auf Containerebene | Alle Blobs im Container | Ablauf und kein weiterer Schutz |
| Zeitpolicy auf Versionsebene | Einzelversion; Konto-/Containerstandard kann vererbt werden | Wirksame Policy jeder Version prüfen |
| Legal Hold am Container | Alle Blobs im gesperrten Container | Ausdrückliche Aufhebung; Zeitschutz kann fortbestehen |
| Legal Hold an einer Version | Einzelne Blob-Version | Ausdrückliche Aufhebung; übrigen Schutz prüfen |
Sowohl gesperrte als auch noch nicht gesperrte zeitbasierte Policies schützen während ihrer Wirksamkeit vor Löschung. Laut Microsoft kann eine noch nicht gesperrte Policy verkürzt oder entfernt werden. Eine gesperrte Policy lässt sich dagegen weder löschen noch verkürzen; Verlängerungen bleiben innerhalb der dokumentierten Grenzen möglich. Nutzen Sie eine entbehrliche Testumgebung und einen genehmigten Änderungsprozess. Für diesen Beitrag wurden keine echten Cloud-Sperren gesetzt.
Versionierung, vorläufiges Löschen und ältere Versionen erschweren den Abschlussnachweis. Das Entfernen der aktuellen Objektreferenz beweist nicht, dass jede Version, Sicherung, jeder Export oder jede Anbieterkopie verschwunden ist. Inventarisieren Sie diese Grenzen ausdrücklich. Auch die Funktionskompatibilität hängt von der Kontokonfiguration ab; prüfen Sie den tatsächlich eingesetzten Speicher statt die Matrix als universellen Cloud-Vertrag zu verstehen.
Ausgeführter synthetischer Evaluator: Ablauf ist kein Abschluss
Ein lokaler Python-Test führte 14 Fälle mit Assertions, erfundenen ganzzahligen Zeitwerten und Entscheidungen im Arbeitsspeicher aus. Geprüft wurden Zeit vor und genau bei Ablauf, fortbestehende Sperren, Aufhebung vor und nach Ablauf, eine verbleibende Sperre, widersprüchliche Fristgrenzen, Sperre gegen Löschfrist, beauftragte aber unbestätigte Löschung, abgegrenzte Verifikation, veraltete Policy-Revision, fehlende Freigabe der Zeitgrenze, Speicherschutz und ein Beleg ohne Auftrag. Alle 14 Ergebnisse entsprachen der Erwartung. Dies sind Modelltests, keine Azure-Integration, Rechtsprüfung oder produktiven Löschnachweise.
| Eingespritzter Zustand | Beobachtetes Modellergebnis | Nächster notwendiger Schritt |
|---|---|---|
| Jetzt gleich Aufbewahrungsende; keine Sperre | ELIGIBLE_NOT_DELETED | Aktuelle Policy prüfen, begrenzten Auftrag erteilen |
| Frist abgelaufen; eine Sperre bleibt | PROTECTED | Verbleibende Sperre durch befugte Stelle klären |
| Aufbewahrungsende nach spätester Löschung | POLICY_CONFLICT | Eskalieren; Frist nicht automatisch wählen |
| Löschung beauftragt; Nachweis fehlt | DELETION_PENDING | Umfang und offene Kopien prüfen |
| Policy-Revision verändert | REVIEW_REQUIRED | Policy neu lesen, alte Zulassung verwerfen |
| Auftrag und vertrauenswürdige Verifikation | DELETION_VERIFIED_IN_SCOPE | Nicht über den geprüften Umfang hinaus verallgemeinern |
Der Algorithmus weist zunächst fehlende Policy-Eingaben oder eine veraltete Revision zurück. Er erkennt unvereinbare Grenzen sowie fällige Löschvorgaben, die durch Schutz blockiert werden. Danach prüft er aktive Sperren beziehungsweise Speicherschutz und anschließend laufende Aufbewahrung. Nur ein abgelaufenes, ungeschütztes und konfliktfreies Artefakt wird ELIGIBLE_NOT_DELETED. Ein Löschauftrag führt zu DELETION_PENDING. Verifikationsnachweise können zu DELETION_VERIFIED_IN_SCOPE führen; ein Beleg ohne Auftrag ist in diesem Lehrmodell ungültig.
Das Verifikations-Boolean wird im Test bewusst als vertrauenswürdig angenommen. Eine echte Prüfinstanz muss unabhängige Nachweise erheben, statt die Aussage eines Workers zu übernehmen. Binden Sie Auftrag und Beleg an genaue Versionen und Policy-Revisionen; weisen Sie veraltete Freigaben unmittelbar vor dem destruktiven Vorgang zurück. Prüfung und anschließendes separates Löschen sind nicht atomar. Serialisieren Sie Sperränderungen und Löschzulassung über einen kontrollierten Koordinator oder ein durchsetzbares Speicherprotokoll und testen Sie das Rennen. Der Test löst dieses Problem verteilter Systeme nicht.
Abnahmecheckliste für die Löschung
1. Ermitteln Sie die aktuelle Policy-Revision und alle aktiven Sperren für die genauen Artefaktversionen. Bestätigen Sie geprüften Fristbeginn und Befugnis; eskalieren Sie offene Konflikte.
2. Inventarisieren Sie Kopien: Primärobjekt, ältere Versionen, Ableitungen, Indizes, Exporte, Backups und Anbieterbestände. Ordnen Sie jeder Grenze Verantwortung und Verifikationsverfahren zu.
3. Erteilen Sie erst nach den Schutzprüfungen einen idempotenten, begrenzten Löschauftrag. Dokumentieren Sie abgelehnte Vorgänge und Wiederholungen getrennt von erfolgreichen Aktionen.
4. Verifizieren Sie das zugesagte Ergebnis über die passende Speicherschnittstelle oder Anbieternachweise. Unterscheiden Sie Abwesenheit im aktiven Namensraum, Wiederherstellbarkeit vorläufig gelöschter Daten und Abschluss des genehmigten Löschumfangs. Ein 404 allein beweist keine physische Vernichtung.
5. Dokumentieren Sie offene Kopien und deren geregelten Ablauf beziehungsweise Ausnahme. Testen Sie Wiederherstellung und erneute Übernahme separat; fassen Sie Teilabschlüsse nie zu einem globalen Gelöscht-Flag zusammen.
6. Bewahren Sie einen minimalen Abschlussbeleg nach eigener geprüfter Policy auf. Beschränken Sie den Zugriff und prüfen Sie, dass der Beleg die sensiblen Nutzdaten nicht erneut erzeugt.
Aufwand, Rechtsprüfung und der erste Umsetzungsschritt
Getrennte Speicher und ein Policy-Register verursachen zusätzlichen Betriebszustand, Berechtigungsverwaltung und Abgleicharbeit. Feingranulare Objektregeln verbessern die Trennung, erhöhen aber Inventarisierungs- und Prüfkosten. Lange unveränderliche Fristen können eine Fehlklassifikation teuer korrigierbar machen. Weniger Nutzdaten reduzieren zudem die Reproduzierbarkeit: Dokumentieren Sie, welche Untersuchungen nicht mehr möglich sind, statt vollständige Wiederholbarkeit zu behaupten.
Legen Sie für die Rechtsprüfung Artefaktklassen, Zwecke, Akteursrollen, Rechtsversionsreferenzen, vorgeschlagene Fristbeginne, Mindest-/Höchstgrenzen, Sperrbefugnisse, grenzüberschreitende beziehungsweise Anbieterbestände und Konfliktbeispiele vor. Lassen Sie ausdrückliche Regeln und Ausnahmen genehmigen. Die Technik testet anschließend diese Regeln; sie leitet sie nicht aus Speicherfunktionen ab.
Beginnen Sie mit einem Workflow und einer sensiblen Artefaktklasse. Testen Sie Ablauf, überlappende Sperren, veraltete Policies und Teillöschung vor einer Ausweitung. Bringen Sie für eine technische Prüfung des Nachweislebenszyklus Ihr Log-Schema, die Speicherschutzeinstellungen und ein Löschticket mit. Ich unterstütze Sie dabei, daraus ein abgegrenztes Aufbewahrungsregister und eine Abnahmesuite mit gezielten Fehlerfällen zu entwickeln. Rechts- und Datenschutzentscheidungen bleiben bei qualifizierten Verantwortlichen.
