Historisierungs-Entscheidungs-Agent
Pro Tabelle entscheiden: migrieren, historisieren oder archivieren — mit nachvollziehbarer Compliance-Begründung statt PDF-Anhang.
Kurz gesagt: Bei einem Plattformwechsel muss pro Tabelle entschieden werden, ob Daten in das neue System gehen, archiviert werden, oder rein gesetzlich historisiert werden müssen. Der Agent klassifiziert Legacy-Daten in genau diese drei Kategorien — getrieben von GoBD- und Swiss-FADP-Anforderungen sowie branchenspezifischen Rahmen wie BankG, VAG und GMP. Stack: Claude (Anthropic direkt) oder Azure OpenAI Switzerland für Daten-Residenz, JiVS als Historisierungsplattform, strukturierter Output gegen ein hinterlegtes Compliance-Regelwerk. Resultat: Hunderte Entscheidungen in Stunden statt Wochen, jede mit Begründung und Audit-Trail. Der Compliance-Officer bleibt im Loop — der Agent schlägt vor, der Mensch signiert ab.
Historisierung ist Wochen Compliance-Arbeit
Bei einem Plattformwechsel müssen Unternehmen pro Tabelle entscheiden, ob die Daten in das neue System gehen, archiviert werden, oder rein gesetzlich historisiert werden müssen. Manuell ist das Wochen Compliance-Arbeit. Ein Datenmodell mit ein paar hundert Tabellen — typisch für gewachsene ERP-, Banken- oder Versicherungssysteme — bedeutet ein paar hundert Einzelentscheidungen, jede mit eigener regulatorischer Begründung. Die Entscheidung ist nicht technisch, sondern compliance-getrieben: dieselbe Tabelle kann in einem Unternehmen migriert und in einem anderen historisiert werden, je nach Geschäftskontext und Aufbewahrungspflicht.
Branchenspezifisch wird es noch komplexer. Im Bankensektor greifen das BankG sowie FINMA-Rundschreiben mit eigenen Aufbewahrungsfristen, die je nach Datentyp — Kundentransaktionen, KYC-Records, interne Beleg-Daten — unterschiedlich laufen. Versicherer arbeiten mit dem VAG und branchenspezifischen Vertragsdaten-Pflichten, in der Pharma kommt GMP-Aufbewahrung für Produktions- und Chargendaten dazu. Quer dazu wirken GoBD (DE-Bezug bei deutschen Mutterhäusern), Swiss FADP und DSGVO. Pro Tabelle braucht es eine begründbare Entscheidung — und die Begründung muss audittauglich sein, ohne dass sie zwei Jahre später aus E-Mails und Excel-Anhängen rekonstruiert werden muss.
Drei Kategorien, ein Decision-Register
Der Agent bekommt zwei Eingaben: das Quell-Schema (welche Tabellen mit welchen Feldern und welchen Datentypen) und ein strukturiertes Aufbewahrungs-Regelwerk (GoBD, Swiss FADP, plus die für das Unternehmen relevanten Branchenrahmen). Pro Tabelle prüft er das Regelwerk gegen die Datenmerkmale — Datentyp, Personenbezug, Geschäftsrelevanz aus Sample-Daten ableitbar — und klassifiziert in eine von drei Kategorien: migrieren (Daten leben im neuen System weiter), archivieren (raus aus dem aktiven System, abrufbar in einem Archivsystem) oder historisieren (nur noch gesetzlich aufbewahrt, kein aktiver Zugriff, oft mit Lösch-Datum). Jede Entscheidung wird als Decision-Record mit Begründung, herangezogenen Regelwerk-Klauseln und Sample-Datenbezug abgelegt — strukturiert, nicht als Freitext.
Modellseitig: Claude (über Anthropic direkt) für längere Reasoning-Ketten über Regelwerk-Kombinationen; Azure OpenAI Switzerland, wenn Daten-Residenz in der Schweiz vertraglich gefordert ist. Tool-seitig greift der Agent auf JiVS-Connectoren für Quell-Schema und Sample-Daten zu, schreibt Decision-Records in ein durchsuchbares Register und produziert pro Entscheidung einen Audit-Log-Eintrag. Guardrails: structured-output-Validierung gegen das Compliance-Schema, harte Eskalation bei Regelwerk-Konflikten (z. B. wenn BankG und Swiss FADP für dieselbe Tabelle in unterschiedliche Richtungen ziehen), Cost-Caps pro Klassifikations-Lauf, und ein kuratiertes Eval-Set mit historisch entschiedenen Fällen pro Branche.
Wichtig: Der Agent entscheidet nicht final. Er klassifiziert, begründet, legt ab. Historisierungs-Entscheidungen sind regulatorisch bindend — wer hier Black-Box-Automatisierung baut, riskiert Bussen, die kein Compliance-Officer rückwirkend übernehmen will. Stattdessen verschiebt der Agent die Compliance-Arbeit nach oben: weg vom Lesen einzelner Tabellen-Definitionen, hin zum Reviewen aggregierter Decision-Batches.
Bank mit 80 Legacy-Tabellen
Eine Schweizer Bank — Komposit, kein realer Klient — steht vor einem Plattform-Wechsel der Kernbanken-Software. Im Bestand: rund 80 Legacy-Tabellen aus dem Vorgänger-System, eine Mischung aus regulatorisch zwingend historisierbaren Daten (Kundentransaktionen mit zehnjähriger BankG-Aufbewahrungspflicht, KYC-Records, Belegdaten für die Steuerbehörde) und Daten mit Aufbewahrungs-Spielraum (interne Kalkulations-Hilfstabellen, archivierbare Reporting-Snapshots, technische Audit-Logs). Der Agent — Claude über Azure OpenAI Switzerland für Daten-Residenz, eingebunden in eine JiVS-Instanz — arbeitet das Tabellen-Inventar mit dem hinterlegten Regelwerk (BankG, FINMA-Rundschreiben, Swiss FADP) ab. Pro Tabelle entsteht ein Decision-Record: Klassifikation, herangezogene Regelwerk-Klauseln, Begründungs-Text, Lösch-Datum (falls historisiert), und ein Verweis auf die Sample-Daten, die der Agent für die Einordnung herangezogen hat. Der Compliance-Officer reviewt das Decision-Register im Batch, eskaliert die Regelwerk-Konflikte, signiert den Rest ab.
Stunden statt Wochen, mit Begründungsspur
Typischer Effekt: Historisierungs-Entscheidungen für mehrere hundert Tabellen entstehen in Stunden statt Wochen — directional, nicht als veröffentlichte Benchmark. Jede Entscheidung kommt mit einer nachvollziehbaren Compliance-Begründung, die auf konkrete Regelwerk-Klauseln verweist statt auf Excel-Erfahrungswerte. Auditoren bekommen ein durchsuchbares Decision-Register, in dem pro Tabelle die Klassifikation, das Regelwerk, die Begründung und die menschliche Bestätigung als zusammenhängender Datensatz vorliegt — statt PDF-Anhängen, die ein Compliance-Officer in Wochenarbeit zusammengestellt hat. Als Nebeneffekt entsteht ein wiederverwertbares Regelwerk: dieselbe Klassifikations-Logik trägt durch spätere Plattformwechsel oder Audit-Zyklen, ohne dass jemand nochmal von vorn anfängt.
Häufige Fragen
Was ist der Unterschied zwischen migrieren, archivieren, historisieren?
Migrieren heisst: das Datum wird aktiv ins neue System übernommen und lebt dort weiter — es ist Teil des laufenden Geschäftsprozesses. Archivieren heisst: das Datum wird aus dem aktiven System genommen und in ein Archiv-System verschoben, bleibt aber bei Bedarf abrufbar — typisch für Reporting-Snapshots oder Audit-Zugriff. Historisieren heisst: das Datum wird nur noch aus gesetzlicher Pflicht aufbewahrt, ohne Zugriff aus einem Geschäftsprozess, oft mit definiertem Lösch-Datum am Ende der Aufbewahrungsfrist. Die Entscheidung ist nicht technisch, sondern compliance-getrieben — dieselbe Kundentransaktions-Tabelle kann in einem Unternehmen migriert und in einem anderen historisiert werden, je nach Geschäftskontext und Aufbewahrungspflicht.
Welche regulatorischen Rahmen unterstützt der Agent?
Standardmässig abgedeckt: GoBD (Bezug bei deutschen Mutterhäusern oder DE-Vertriebsstrukturen), Swiss FADP (revidiertes Schweizer Datenschutzgesetz), DSGVO (EU-Geltungsbereich). Branchenspezifisch: BankG und FINMA-Rundschreiben für den Schweizer Bankensektor, VAG für Versicherungen, GMP-Aufbewahrung für Pharma- und Medizintechnik-Produktionsdaten. Das Regelwerk ist als strukturiertes DSL hinterlegt — neue Rahmen lassen sich ergänzen, ohne den Agent selbst neu zu bauen. Wichtiger Hinweis: Der Agent interpretiert das Regelwerk, das ein Compliance-Officer kuratiert und freigegeben hat. Er ersetzt diesen Compliance-Officer nicht — und die finale regulatorische Verantwortung bleibt beim Kunden, nicht beim Tool-Anbieter.
Wer prüft die Entscheidungen final?
Jede Agent-Entscheidung ist ein begründeter Vorschlag, keine bindende Klassifikation. Standard-Workflow: Der Compliance-Officer reviewt das Decision-Register batch-weise — typisch nach Branche, Datentyp oder Risk-Score gefiltert — und signiert ab. Bei Sonderfällen, in denen das Regelwerk widersprüchliche Anforderungen produziert (etwa BankG-Aufbewahrung versus FADP-Löschungsanspruch), eskaliert der Agent direkt an Datenschutz oder Rechtsabteilung statt selbst eine Klassifikation vorzuschlagen. Der Audit-Trail belegt für jede Tabelle: Wer hat wann was warum entschieden, welche Regelwerk-Klauseln waren herangezogen, welches Sample-Datum lag zugrunde. Das macht spätere Audits zur Lese-Übung statt zur Rekonstruktion.
Praktik und benachbarte Use Cases
Dieser Use Case sitzt in der Praktik Agentensysteme & Workflows und greift in benachbarte Migrations- und Audit-Use-Cases.
Agentensysteme & Workflows
Praktik: Wie Agenten in Produktionsumgebungen gebaut, betrieben und auditfähig gemacht werden — Patterns, Guardrails, Plattformwahl.
Agentische SAP-Migration
Migrations-Objekte pro Backlog-Eintrag vorbereiten — Schema parsen, Z-Tabellen erkennen, Mapping vorschlagen, sauber eskalieren.
Migrations-Audit & Sign-off
Auditfertige Diff-Reports mit Diskrepanz-Klassifikation und Sign-off-Paketen für Cut-over.
Custom-Field & Z-Tabellen-Reconciliation
Z-Felder, Z-Tabellen und modifizierte Customizing-Einträge automatisiert mit Standard-Datenmodell abgleichen.
Passt das zu Ihrer Historisierungs-Entscheidung?
Historisierung ist eine Compliance-Entscheidung, kein Tooling-Problem. In einem unverbindlichen 30-Minuten-Discovery-Call besprechen wir zuerst, ob ein Agent für Ihre Datenstruktur überhaupt der richtige Hebel ist.
Discovery-Call anfragen