Datenprovenienz & Rückverfolgbarkeit
Wir entwickeln Datenlineage- und Provenienz-Infrastrukturen, die KI-Trainingsdaten von der Quelle über jede Transformation bis zu den Modellgewichten lückenlos rückverfolgen – für regulatorische Nachweise und operative Kontrolle.
Ihr KI-System hat eine Entscheidung getroffen. Können Sie die Daten dahinter rückverfolgen?
Datenprovenienz ist die Infrastruktur, die Fragen zu KI-Daten beantwortbar macht – kein Dashboard oder Katalogeintrag, sondern ein System, das erfasst, woher Trainingsdaten stammen, welche Transformationen sie durchlaufen haben, welche Modelle sie verarbeitet haben und ob diese Kette kryptografisch verifiziert werden kann (siehe unsere Forschung zur Architektur verifizierbarer KI für Unternehmen im Post-Trust-Zeitalter).
Ein Gericht ordnete kürzlich an, dass OpenAI 78 Millionen ChatGPT-Ausgabeprotokolle vorlegen muss, weil Kläger nachvollziehen mussten, wie urheberrechtlich geschützte Trainingsdaten das Modellverhalten beeinflusst haben. Das ist ein extremes Beispiel. Die alltägliche Variante ist unauffälliger, aber genauso folgenschwer:
- Eine Regulierungsbehörde fragt, mit welchen Daten Ihr Kreditvergabemodell trainiert wurde.
- Ein DSGVO-Löschersuchen, das Ihre Quelltabellen erreichte, nicht jedoch die sechs nachgelagerten Modelle, die die gelöschten Datensätze verarbeitet haben.
- Ein Data-Poisoning-Vorfall, bei dem Sie nicht identifizieren können, welche Trainings-Batches kompromittiert wurden, weil nichts in Ihrer Pipeline diese Information aufgezeichnet hat.
Unser Ansatz besteht darin, diese Provenienz-Schicht über die Pipeline-Tools hinweg aufzubauen, die Unternehmen bereits einsetzen: Spark, dbt, Airflow, Dagster und benutzerdefiniertes ETL.
Warum Katalog-Lineage nicht mit Trainingsdaten-Provenienz identisch ist
Die meisten Unternehmen besitzen bereits einen Metadaten-Katalog. Collibra, Alation, Atlan oder DataHub deckt Lineage auf Tabellenebene ab, was für die Auswirkungsanalyse von Schema-Änderungen nützlich ist. Es beantwortet jedoch nicht die Fragen, die Regulierungsbehörden, Prüfer und Prozessanwälte zu KI-Systemen stellen. Die Diskrepanz zeigt sich an drei Stellen:
| Dimension | Katalog-Lineage | Trainingsdaten-Provenienz |
|---|---|---|
| Granularität | Verfolgt Datasets, keine einzelnen Datensätze | Auf Datensatzebene – erforderlich gemäß DSGVO Artikel 17, um jedes nachgelagerte Artefakt zu identifizieren, das Daten einer betroffenen Person aufgenommen hat, einschließlich der Modellgewichte |
| Systemgrenze | Endet an der Modellgrenze; MLflow oder Weights and Biases kennen zwar die Dataset-Version, nicht aber, welche Datensätze und welche Vorverarbeitung verwendet wurden oder wie einzelne Beispiele das Verhalten beeinflussten | Reicht durch die gesamte Vorverarbeitung hindurch bis dahin, wie spezifische Beispiele das Modellverhalten beeinflusst haben |
| Integrität | Passiv, keine Integritätsgarantie – überschreibt ein Entwickler eine Staging-Tabelle, hinterlässt dies keine Spuren | Kryptografische Provenienz macht Manipulationen erkennbar |
Unser Ansatz funktioniert mit jedem Metadaten-Katalog, den Sie bereits besitzen. Die Provenienz-Schicht wird darunter angesiedelt und instrumentiert die tatsächliche Pipeline-Ausführung, um jene Details auf Datensatz- und Transformationsebene zu erfassen, für deren Bereitstellung Kataloge nicht konzipiert wurden.
Was wir instrumentieren und wie
Die zentrale Herausforderung besteht darin, Provenienz in der von Regulierungsbehörden geforderten Granularität zu erfassen, ohne den Pipeline-Durchsatz zu beeinträchtigen. SHA-256-Hashing pro Datensatz bei einem Spark-Job zur Verarbeitung von 500 Millionen Zeilen verursacht 15–40 % Overhead – im Produktivbetrieb selten akzeptabel. Unser Ansatz kalibriert die Provenienz-Granularität genau nach dem tatsächlichen Risikoprofil.
| Pipeline-Risikoprofil | Provenienz-Ansatz | Overhead |
|---|---|---|
| Hochrisiko-Pipelines für regulierte KI (Kreditwürdigkeitsprüfung, klinische Entscheidungsunterstützung, Betrugserkennung) | Batch-basierte Merkle-Bäume: inhaltsadressiertes Hashing auf Partitionsebene mit Merkle-Root-Verifikation über den gesamten Batch, was Manipulationssicherheit gewährleistet | 2–5 % Durchsatz-Overhead |
| Analytische Pipelines mit geringerem Risiko | Reine Metadaten-Provenienz: Quell-Identifikatoren, Transformationsparameter und Softwareversionen, ohne Hashing auf Datensatzebene | Nahezu null – liefert regulatorische Dokumentation |
Pipeline-Instrumentierung mit OpenLineage
Die Instrumentierung nutzt OpenLineage als Emissionsstandard dort, wo Integrationen existieren (Spark, Airflow, dbt und Dagster bieten hierfür unterschiedliche Grade an Unterstützung), ergänzt um benutzerdefinierte Facets zur Erfassung ML-spezifischer Metadaten: Feature-Engineering-Parameter, Konfigurationen zur Datenaugmentation, Sampling-Strategien sowie Kriterien für die Aufteilung in Trainings-, Validierungs- und Testdaten. Wo eine OpenLineage-Integration unvollständig ist oder Ereignisse verwirft – der Spark-Listener verliert bei hohen Partitionszahlen bekanntlich unbemerkt benutzerdefinierte Facets –, fügt der Ansatz eine ergänzende Instrumentierung hinzu, die genau das erfasst, was der Standardintegration entgeht; ausführlich dargelegt in unserem technischen Whitepaper zur Absicherung der ML-Lieferkette über den gesamten Lebenszyklus.
Provenienz für unstrukturierte Daten
Für unstrukturierte Trainingsdaten – Dokumente, Bilder, Audio und Video in Fine-Tuning- oder RAG-Pipelines – setzt der Ansatz Content-Fingerprinting mit perzeptuellem Hashing ein (pHash für Bilder, chromaprint für Audio) neben kryptografischen Hashes. Dies ermöglicht die Provenienz-Nachverfolgung selbst dann, wenn Inhalte verlustbehaftete Transformationen durchlaufen – siehe eine funktionierende Demo zur Audio-Provenienz-Verfolgung.
Das DSGVO-Löschungsproblem, das bislang niemand sauber gelöst hat
DSGVO Artikel 17 gewährt das Recht auf Löschung. Für traditionelle Datenbanken gilt: löschen und bestätigen. Für KI-Systeme ist es ein ungelöstes Problem, das als Compliance-Kontrollkästchen getarnt wird. Große Sprachmodelle speichern Daten nicht als diskrete Datensätze – sie speichern statistische Muster aus Trainingsdaten, verteilt über Milliarden von Parametern. Das Löschen der Daten einer Person aus der Quelltabelle entfernt deren Einfluss keineswegs aus den Modellgewichten, und die DSGVO bietet keinen Rahmen für die Interpretation dessen, was „Löschung“ bedeutet, sobald Daten in die Entscheidungsarchitektur eines Modells absorbiert wurden.
Die Forschung zum Machine Unlearning schreitet voran. Im September 2025demonstrierten Forscher der UC Riverside „Source-Free Unlearning“: eine zertifizierte Methode, die ohne die ursprünglichen Trainingsdaten auskommt und stattdessen Surrogat-Datensätze sowie Newton-Update-basierte Parameteranpassungen nutzt. Doch kein Unlearning-Verfahren ist im Enterprise-Maßstab produktionsreif. Aktuelle praxisnahe Ansätze kombinieren drei Schichten:
- Prävention – Fernhalten personenbezogener Daten aus Trainingsdaten durch Vorverarbeitungs-Gates.
- Schnelle Bereinigung – Löschen aus Retrieval-Indizes, Caches und Logs.
- Rechtssichere Dokumentation – Provenienz-Nachweise, die belegen, welche Daten in welche Modelle eingeflossen sind, um fundierte Nachtrainings-Entscheidungen zu stützen, wenn Unlearning unzureichend ist.
Die Provenienz-Infrastruktur schafft die Voraussetzung für jede Löschstrategie: eine abfragbare Zuordnung von der Kennung der betroffenen Person zu jedem Modell, jeder Pipeline und jedem Artefakt, die deren Daten verarbeitet haben. Damit beantworten Sie die Frage „Welche Modelle müssen neu trainiert werden?“ innerhalb von Minuten nach einem Löschersuchen – anstatt Monate später festzustellen, dass ein vergessener Fine-Tuning-Lauf die betroffenen Daten verwendet hat.
EU AI Act Artikel 10: Von Richtliniendokumenten zu Pipeline-Nachweisen
Artikel 10 des EU AI Act schreibt vor, dass Trainings-, Validierungs- und Testdaten „angemessenen Data-Governance- und Managementpraktiken für den vorgesehenen Zweck“ unterliegen müssen. Die Durchsetzung beginnt am 2. August 2026. Die praktische Anforderung ist kein Governance-Richtliniendokument. Es handelt sich um überprüfbare, mit Zeitstempeln versehene Nachweise, dass Governance genau in dem Moment angewandt wurde, als Daten in die Pipeline gelangten.
Die Diskrepanz ist real: Nur 3 % der Finanzinstitute haben KI effektiv im Produktivbetrieb implementiert (Ataccama 2025 Data Trust Report). Governance-Richtlinien existieren zwar, Nachweise über deren Einhaltung auf Pipeline-Ebene fehlen jedoch.
Unser Ansatz liefert die Compliance mit Artikel 10 als Pipeline-Fähigkeit. Jeder Durchlauf erzeugt einen Provenienz-Datensatz, der Folgendes erfasst: Datenquellen mit Herkunfts-Metadaten, Ergebnisse der Qualitätsvalidierung, Transformationsparameter, Sampling-Methodik, statistische Eigenschaften des Datasets (Repräsentativität, Vollständigkeit, Fehlerraten) sowie aktive Governance-Richtlinien. Dies ist das Artefakt, das ein Auditor prüft – automatisch generiert, nicht nachträglich zusammengestellt.
Für Organisationen, die zudem DSGVO Artikel 30 (Verzeichnis von Verarbeitungstätigkeiten) unterliegen, ist das Provenienz-System so ausgelegt, dass es beide Compliance-Artefakte über eine einzige Instrumentierungsschicht erstellt. Die Anforderungen überschneiden sich, sind jedoch nicht identisch: Artikel 30 konzentriert sich auf Verarbeitungszwecke und Rechtsgrundlagen, während Artikel 10 Datenqualität und Repräsentativität in den Mittelpunkt stellt. Ein einheitliches System vermeidet den doppelten Aufwand, der Organisationen mit getrennten Compliance-Verfahren belastet.
Trainingsdaten-Attribution und Erkennung von Data Poisoning
Regulierungsbehörden fordern zunehmend Transparenz darüber, welche Trainingsbeispiele eine bestimmte Vorhersage beeinflusst haben. Einflussfunktionen – das mathematische Rahmenwerk hierfür – waren für den Produktiveinsatz historisch zu rechenintensiv. Jüngste Fortschritte – LoGra-Gradientenprojektion und der ASTRA-Algorithmus – bringen die Einflussberechnung in eine praxistaugliche Größenordnung. Unser Ansatz implementiert Attribution als forensische Fähigkeit: vorberechnete Einflusswerte für kritisches Modellverhalten, zwischengespeichert für den Abruf, wenn ein Auditor oder Prozessanwalt die Verbindung zwischen einer bestimmten Ausgabe und den zugrunde liegenden Daten benötigt.
Provenienz dient zudem als primäre Verteidigung gegen Data Poisoning im Training (unsere Forschung zur Absicherung von Enterprise-Modellen gegen Poisoning). Forschungsergebnisse aus dem Jahr 2025 bestätigen, dass für ein Poisoning unabhängig von der Modellgröße nur eine konstante Anzahl von Datenpunkten erforderlich ist, und selbst 0,001 % manipulative Daten die Genauigkeit um 30 % verschlechtern können. Wenn jedes Datenelement über eine verifizierte Chain of Custody verfügt, werden anomale Provenienz-Muster erkennbar:
- Daten aus nicht verifizierten Quellen.
- Datensätze mit unterbrochenen Hash-Ketten.
- Beispiele, die die standardmäßige Ingestion-Pipeline umgehen.
Aufbauend auf dem Provenienz-Graphen fügt der Ansatz Erkennungsschichten hinzu, die solche Muster kennzeichnen, bevor kontaminierte Daten das Modelltraining erreichen.
Wann diese Investition die richtige ist
Sie benötigen eine Provenienz-Infrastruktur, wenn Ihre KI-Systeme Daten verarbeiten, die rechtlichen, regulatorischen oder sicherheitsrelevanten Risiken unterliegen:
- Finanzdienstleister im Anwendungsbereich von EU AI Act Artikel 10.
- Gesundheitsunternehmen unter FDA 21 CFR Part 11.
- Unternehmen mit DSGVO-Relevanz, die Modelle auf Nutzerdaten trainieren.
- Organisationen, deren Beschaffung von Trainingsdaten rechtlich überprüft wird.
Sie benötigen dies nicht, wenn Ihre KI ausschließlich unregulierte First-Party-Daten über eine einfache Pipeline verarbeitet. Wenn der Lineage-Graph von dbt zusammen mit einer DataHub-Instanz Ihre Anforderungen abdeckt, nutzen Sie diese – das sagen wir Ihnen bereits im ersten Gespräch.
Wichtigste Erkenntnisse
- Katalog-Lineage verfolgt Datasets bis an die Modellgrenze ohne Integritätsgarantie; regulierte KI erfordert kryptografisch verifizierbare Provenienz auf Datensatzebene unterhalb des bereits vorhandenen Katalogs.
- Unser Ansatz orientiert sich am tatsächlichen Risiko: reine Metadaten-Provenienz für Pipelines mit geringerem Risiko (nahezu null Overhead), vollständige kryptografische Ketten mit Merkle-Bäumen pro Batch für regulierte Systeme (2–5 % Overhead gegenüber 15–40 % bei SHA-256 pro Datensatz).
- Provenienz ist die unverzichtbare Voraussetzung für Löschungen nach DSGVO Artikel 17, Nachweise gemäß EU AI Act Artikel 10 (Durchsetzung ab 2. August 2026), Trainingsdaten-Attribution und Poisoning-Erkennung.
- Die Kosten des Nichttuns sind konkret: Strafen von bis zu 15 Millionen EUR oder 3 % des weltweiten Umsatzes, 40 % mehr Zeitaufwand beim Debugging ohne Lineage und über 51 Urheberrechtsklagen, die Provenienz zu einer zwingenden Voraussetzung in Rechtsstreitigkeiten machen.
Datenprovenienz & Rückverfolgbarkeit
KI-Audio-Lizenzierung, Wasserzeichen & Provenienz für Medien | Veriprajna
Wir bauen durchgängige Audio-Provenienz-Pipelines für Labels, DSPs, Distributoren und Werbeagenturen. Einbettung und Erkennung von Wasserzeichen, C2PA-Content-Credentials, DDEX-KI-Offenlegung, lizenzierte Stimm- konvertierung, Takedown-Workflows, indemnifizierungsfähige Chain of Title. Die Uhr für Artikel 50 läuft – noch 4 Monate.
KI-Lieferkettensicherheit & Modellintegrität | Veriprajna
Beratung für KI-Lieferkettensicherheit. Wir bauen Modell-Prüfpipelines, ML-BOM-Architektur und Schatten-KI-Governance für CISOs in regulierten Unternehmen. Konform mit NIST AI 100-2 und EU AI Act.
Häufig gestellte Fragen
Wie viel kostet die Implementierung einer Enterprise-Infrastruktur für Datenprovenienz?
Die Kosten hängen von Pipeline-Komplexität, Provenienz-Granularität und regulatorischer Exposition ab. Reine Metadaten-Provenienz (Quellverfolgung, Transformationsparameter, Softwareversionen) verursacht nahezu keinen Pipeline-Overhead und erfordert typischerweise 4–8 Wochen Instrumentierungsaufwand. Vollständige kryptografische Provenienz mit Batch-basierten Merkle-Bäumen und Rückverfolgbarkeit auf Datensatzebene erfordert 8–16 Wochen und verursacht 2–5 % Durchsatz-Overhead in instrumentierten Pipelines. Die alternativen Kosten sind weitaus höher: Strafen bei Nichteinhaltung des EU AI Act erreichen bis zu 15 Millionen EUR oder 3 % des weltweiten Jahresumsatzes, und Teams ohne Lineage benötigen 40 % mehr Zeit für das Debugging von Datenfehlern. Wir dimensionieren nach dem tatsächlichen Risikoprofil, nicht nach Plattform-Abonnements.
Was passiert, wenn ein DSGVO-Löschersuchen Daten betrifft, die bereits zum Trainieren eines KI-Modells verwendet wurden?
Dies ist das schwierigste ungelöste Problem der KI-Compliance. Das Löschen von Datensätzen aus Quelltabellen entfernt deren Einfluss nicht aus den Modellgewichten, in denen Daten als verteilte statistische Muster über Milliarden von Parametern gespeichert sind. Methoden des Machine Unlearning machen Fortschritte (Forscher der UC Riverside demonstrierten im September 2025 zertifiziertes „Source-Free Unlearning“), doch keine ist im industriellen Maßstab produktionsreif. Der praxisnahe Ansatz kombiniert drei Schichten: Prävention (Fernhalten personenbezogener Daten aus Trainingsdaten durch Vorverarbeitungs-Gates), schnelle Bereinigung (Löschen aus Retrieval-Indizes, Caches und Logs) sowie rechtssichere Dokumentation über Provenienz-Nachweise, die belegen, welche Daten in welche Modelle eingeflossen sind, um gezieltes Nachtraining zu ermöglichen, wenn Unlearning unzureichend ist. Das von uns entwickelte Provenienz-System schafft die Voraussetzung hierfür: eine abfragbare Zuordnung von der Kennung der betroffenen Person zu jedem Modell, jeder Pipeline und jedem Artefakt, die deren Daten verarbeitet haben.
Wie erfülle ich die Data-Governance-Anforderungen von Artikel 10 des EU AI Act?
Artikel 10 verlangt, dass Trainings-, Validierungs- und Testdaten für Hochrisiko-KI-Systeme angemessenen Data-Governance-Praktiken unterliegen. Die Durchsetzung beginnt am 2. August 2026. Die Anforderung besteht nicht in einem Richtliniendokument. Es handelt sich um verifizierbare, mit Zeitstempel versehene Nachweise, dass Governance beim Eintritt der Daten in die Pipeline angewandt wurde. Wir implementieren dies als Pipeline-Fähigkeit: Jeder Durchlauf erzeugt einen Provenienz-Datensatz, der Datenquellen mit Herkunfts-Metadaten, Ergebnisse der Qualitätsvalidierung bei der Ingestion, Transformationsparameter, Sampling-Methodik, statistische Eigenschaften des resultierenden Datasets und die zu diesem Zeitpunkt gültigen Governance-Richtlinien erfasst. Für Unternehmen, die zudem der DSGVO Artikel 30 unterliegen, werden beide Compliance-Artefakte über eine einzige Instrumentierungsschicht generiert.
Warum reicht die Lineage unseres Metadaten-Katalogs für die KI-Trainingsdaten-Provenienz nicht aus?
Kataloge wie Collibra, Alation, Atlan und DataHub verfolgen Lineage auf Tabellenebene: welche Tabellen welche Tabellen speisen. Das ist nützlich für die Auswirkungsanalyse von Schema-Änderungen, reicht jedoch für die regulatorische KI-Compliance nicht aus. Es bestehen drei Lücken: Erstens erfassen Kataloge Datasets und keine einzelnen Datensätze, sodass Sie die Daten einer bestimmten betroffenen Person für eine DSGVO-Löschung nicht bis zu den Modellgewichten zurückverfolgen können. Zweitens endet die Katalog-Lineage an der Modellgrenze: MLflow kennt die Dataset-Version, nicht aber, welche Datensätze verwendet oder welche Vorverarbeitung angewandt wurde. Drittens ist die Katalog-Lineage passiv und bietet keine Integritätsgarantien; überschreibt ein Entwickler eine Staging-Tabelle, hinterlässt dies keine Spuren. Eine Provenienz-Infrastruktur mit kryptografischer Verifikation schließt diese Lücken und arbeitet nahtlos mit Ihrem bestehenden Katalog zusammen.
Wie hilft Datenprovenienz bei der Erkennung von Training Data Poisoning?
Forschungsergebnisse aus dem Jahr 2025 bestätigen, dass Poisoning unabhängig von der Modellgröße nur eine konstante Anzahl von Datenpunkten erfordert und bereits 0,001 % manipulative Daten die Genauigkeit um 30 % verschlechtern können. Neuere Forschungen zu „Harmless Input Poisoning“ Ende 2025 zeigten, dass Backdoors über harmlos wirkende Daten eingeschleust werden können, weshalb eine rein inhaltsbasierte Erkennung nicht ausreicht. Eine Provenienz-Infrastruktur liefert die komplementäre Verteidigung: Eine verifizierte Chain of Custody von der Quelle bis zur Pipeline sorgt dafür, dass anomale Provenienz-Muster erkennbar werden. Daten aus unbestätigten Quellen, Datensätze mit fehlerhaften Hash-Ketten (die auf nachträgliche Modifikationen hinweisen) oder Beispiele, die die reguläre Ingestion umgehen, werden markiert, bevor kontaminierte Daten das Modelltraining erreichen.
Kann ich Datenprovenienz implementieren, ohne meine bestehenden Pipelines neu schreiben zu müssen?
Ja. Wir instrumentieren bestehende Pipelines mittels OpenLineage-kompatibler Ereignisübertragung für Spark, dbt, Airflow und Dagster und binden die Lineage-Erfassung auf Orchestrator- und Ausführungsebene ein, ohne die Geschäftslogik der Pipelines zu verändern. Wo native OpenLineage-Integrationen unvollständig sind (der Spark-Listener verwirft benutzerdefinierte Facets bei hohen Partitionszahlen, dbt-Lineage deckt nur dbt-Modelle ab), entwickeln wir ergänzende Instrumentierungen, um diese Lücken zu schließen. Für proprietäre ETL-Systeme ohne Standardintegration integrieren wir leichtgewichtige Hooks, die Provenienz-Ereignisse an denselben Lineage-Speicher übermitteln. Das Ziel ist die Erfassung von Provenienz-Metadaten auf der Ausführungsebene, nicht das Umschreiben der Transformationen selbst.
Was ist Trainingsdaten-Attribution und wann benötige ich sie?
Trainingsdaten-Attribution identifiziert, welche Trainingsbeispiele eine bestimmte Modellvorhersage beeinflusst haben. Sie nutzt Einflussfunktionen, um die mathematische Beziehung zwischen Trainingsdaten und Modellverhalten zu quantifizieren. Jüngste Fortschritte (LoGra-Gradientenprojektion, der ASTRA-Algorithmus mit EKFAC-vorkonditionierten Neumann-Reihen) haben dies im großen Maßstab rechentechnisch machbar gemacht. Sie benötigen Attribution bei regulatorischen Anfragen darüber, warum ein Modell eine bestimmte Entscheidung getroffen hat (Erklärbarkeitsanforderungen des EU AI Act), in Urheberrechtsstreitigkeiten, die den Nachweis des Einflusses von Trainingsdaten auf Modellausgaben erfordern, oder beim internen Modell-Debugging, um festzustellen, welche Trainingsbeispiele für problematisches Verhalten verantwortlich sind. Wir implementieren dies als forensische Funktion: vorberechnete Einflusswerte für kritisches Modellverhalten, zwischengespeichert für den schnellen Abruf.
Wie handhaben Sie die Provenienz für unstrukturierte Daten, die im LLM-Training verwendet werden?
Unstrukturierte Daten (Dokumente, Bilder, Audio, Video), die in Fine-Tuning- oder RAG-Pipelines genutzt werden, erfordern andere Provenienz-Verfahren als tabellarische Daten. Wir implementieren Content-Fingerprinting mit perzeptuellem Hashing (pHash für Bilder, chromaprint für Audio) in Kombination mit kryptografischen Hashes. Perzeptuelle Hashes ermöglichen die Nachverfolgung der Provenienz selbst dann, wenn Inhalte verlustbehafteten Transformationen (Größenanpassung, Formatkonvertierung, Komprimierung) unterzogen werden, die kryptografische Hashes verändern würden. Für Dokumentenbestände in RAG-Systemen kombinieren wir kryptografisches Hashing auf Dokumentenebene mit Provenienz auf Chunk-Ebene, die festhält, welche Chunks für bestimmte Abfragen abgerufen wurden. Dies ermöglicht eine lückenlose Rückverfolgbarkeit vom Quelldokument über das Retrieval bis hin zur generierten Ausgabe.
Entwickeln Sie Ihre KI mit Zuversicht.
Arbeiten Sie mit einem Team zusammen, das über umfassende Erfahrung im Aufbau der nächsten Generation von Unternehmens-KI verfügt. Wir helfen Ihnen, eine KI-Strategie zu entwerfen, zu entwickeln und einzuführen, der Sie vertrauen können.
Veriprajna Deep-Tech-Beratung ist auf die Entwicklung sicherheitskritischer KI-Systeme für die Bereiche Gesundheitswesen, Finanzen und Regulierung spezialisiert. Unsere Architekturen werden anhand etablierter Protokolle validiert und mit umfassender Compliance-Dokumentation belegt.