WISSEN > AI INFRASTRUCTURE > AI READY DATA
Autor: Dirk Neumann Geschäftsführer ASSISTRA Cloud Services GmbH 17.08.2026
AI-ready Data ist keine Storage-Eigenschaft
Was Unternehmensdaten für einen AI-Anwendungsfall nutzbar macht
Das sollten Sie mitnehmen:
- AI-ready ist kein Storage-Merkmal.
Schneller oder skalierbarer Storage beschleunigt den Datenzugriff, löst aber weder fehlende Metadaten noch ungeklärte Berechtigungen, ungeeignete Formate oder veraltete Bestände.
- AI-ready ist anwendungsbezogen.
Datenqualität und technische Anforderungen lassen sich nur gegen einen konkreten Use Case bewerten, nicht als universelles Qualitätssiegel vergeben.
- Auffindbarkeit entscheidet vor dem Zugriff.
Ein Datenbestand, dessen Existenz und Relevanz nicht bekannt ist, bleibt für ein AI-System unsichtbar – unabhängig davon, wie gut er gespeichert ist.
- Berechtigungen müssen über den gesamten Pfad durchgesetzt werden.
Zwischen Quelldatei und Benutzer entstehen zusätzliche Processing-, Index- und Retrieval-Schichten, die bestehende Schutzmechanismen nicht implizit aushebeln dürfen.
- Der Energiebedarf gehört in die Architekturentscheidung.
AI-Datenpfade verlagern Last in Richtung GPU-naher Infrastruktur und wiederholter Datenbewegung – mit unmittelbaren Folgen für Anschlussleistung, Kühlung und EnEfG-Nachweise.
KI-ready Data ist keine Storage Eigenschaft
Inhaltsverzeichnis
- Was eine AI-Anwendung zusätzlich verlangt
- Ohne Auffindbarkeit bleibt der beste Datenbestand unsichtbar
- Datenqualität lässt sich nur gegen den Anwendungsfall bewerten
- Ein erreichbares Objekt ist noch kein lesbarer Inhalt
- Metadaten liefern den Kontext, den das Modell nicht mitbringt
- Berechtigungen enden nicht an der Quelldatei
- AI-ready Data und High-Performance Data Access sind nicht dasselbe
- Quelldaten und abgeleitete Strukturen driften auseinander
- Datenlokalität bleibt eine Architekturentscheidung
- Der Energiebedarf gehört in die Architekturentscheidung
- AI-ready ist anwendungsbezogen, nicht universell
- Fazit
- Quellen
Unternehmen verfügen meist bereits über große Datenbestände. Sie liegen auf Fileservern, Enterprise-Storage-Systemen, Object Storage, in Datenbanken, Cloud-Plattformen oder SaaS-Anwendungen. Allein ihre Existenz macht diese Daten jedoch noch nicht für künstliche Intelligenz nutzbar.
AI-ready Data bezeichnet Daten, die hinsichtlich Qualität, Auffindbarkeit, technischer Zugänglichkeit, Kontext, Aktualität und kontrollierter Nutzung so vorbereitet sind, dass sie für einen definierten AI- oder Machine-Learning-Anwendungsfall verwendet werden können. Der Begriff beschreibt damit keine einzelne Storage-Eigenschaft und auch kein bestimmtes Produkt.
Was eine AI-Anwendung zusätzlich verlangt
Für klassische Storage-Architekturen stehen häufig Kapazität, Performance, Verfügbarkeit, Datenintegrität und Schutz der gespeicherten Daten im Mittelpunkt. Eine AI-Anwendung stellt zusätzliche Anforderungen.
Ein Petabyte an Unternehmensdaten kann technisch hochverfügbar und performant gespeichert sein. Wenn jedoch nicht bekannt ist, welche Daten für einen Anwendungsfall relevant sind, welches Dokument aktuell ist, wer darauf zugreifen darf oder wie die Inhalte verarbeitet werden können, ist der Datenbestand für diesen Anwendungsfall noch nicht AI-ready.
Die Betrachtung verschiebt sich deshalb von der reinen Speicherung hin zur gesamten Datenkette. Sie beginnt bei der Datenquelle, führt über Auffindbarkeit, Zugriff und Verarbeitung sowie über die Anreicherung mit Kontext und Metadaten bis zum eigentlichen AI- oder ML-System. Bei Retrieval-Augmented Generation kommen weitere Verarbeitungsschritte hinzu – Parsing, Segmentierung, Embeddings, Indexierung und Retrieval. Diese Schritte machen die darunterliegenden Anforderungen an die Dateninfrastruktur nicht überflüssig, sondern setzen sie voraus.
[BILD 1: Datenkette von der Quelle bis zum AI-System – Datenquelle, Auffindbarkeit, Zugriff, Verarbeitung, Metadaten/Kontext, AI-/ML-System; darunter die zusätzliche RAG-Kette mit Parsing, Segmentierung, Embeddings, Index, Retrieval]
Die ISO/IEC-5259-Reihe behandelt Datenqualität für Analytics und Machine Learning ausdrücklich über den Datenlebenszyklus hinweg. ISO/IEC 5259-1 definiert dafür Grundlagen und Terminologie, ISO/IEC 5259-2 Qualitätsmerkmale und Messgrößen, ISO/IEC 5259-3 das Qualitätsmanagement, ISO/IEC 5259-4 den Prozessrahmen und ISO/IEC 5259-5 die Governance. Entscheidend ist dabei der Bezug zum vorgesehenen Einsatzzweck: Datenqualität ist nicht allein eine Eigenschaft der gespeicherten Daten, sondern muss in Bezug auf die Anforderungen der jeweiligen Verarbeitung bewertet werden.
Ohne Auffindbarkeit bleibt der beste Datenbestand unsichtbar
Bevor Daten verarbeitet werden können, muss bekannt sein, dass sie existieren und wo sie verfügbar sind. Das klingt trivial, wird bei verteilten Unternehmensdaten jedoch schnell zu einem Architekturproblem. Daten können über File Storage, Object Storage, Datenbanken, Cloud-Dienste und Fachanwendungen verteilt sein, ohne dass eine Instanz den Gesamtbestand kennt.
Auffindbarkeit ist deshalb nicht mit physischem Zugriff gleichzusetzen. Ein AI-System benötigt einen Mechanismus, mit dem relevante Datenbestände identifiziert und adressiert werden können. Ein standardisiertes Beispiel dafür ist das W3C Data Catalog Vocabulary DCAT. Es beschreibt Datensätze und Data Services über Metadaten und ermöglicht unter anderem die Auffindbarkeit von Datenbeständen sowie die föderierte Suche über mehrere Kataloge hinweg. DCAT 3 berücksichtigt darüber hinaus Versionierung und Dataset Series.
In unseren Migrationsprojekten sehen wir regelmäßig, dass der eigentliche Aufwand nicht im Datentransfer liegt, sondern in der vorgelagerten Bestandsaufnahme: Welche Shares sind fachlich noch relevant, welche Verzeichnisse sind seit Jahren unverändert, welche Daten wurden dupliziert? Diese Analyse ist für AI-Vorhaben dieselbe Vorarbeit wie für eine Storage-Konsolidierung. [QUERVERWEIS: NAS-Migration zu Global File System – Titel und URL vor Veröffentlichung einsetzen]
Datenqualität lässt sich nur gegen den Anwendungsfall bewerten
Nicht jede vorhandene Information ist für jeden AI-Anwendungsfall gleichermaßen geeignet. ISO/IEC 5259-2 definiert hierfür ein Data-Quality-Modell und messbare Qualitätsmerkmale und ist dabei sowohl auf strukturierte als auch auf unstrukturierte Daten ausgerichtet.
Diese Ausrichtung ist der wesentliche Unterschied zum älteren Modell der SQuaRE-Reihe: ISO/IEC 25012 definiert ein allgemeines Datenqualitätsmodell mit fünfzehn Merkmalen, bezieht sich aber ausdrücklich auf Daten in strukturierter Form innerhalb eines Computersystems. Für Unternehmensdaten, die überwiegend als Dokumente, Bilder oder unstrukturierte Ablagen vorliegen, greift dieses Modell allein zu kurz. Genau dort setzt die 5259-Reihe an.
Entscheidend ist das Prinzip „fit for purpose". Ein Datenbestand kann für einen Anwendungsfall ausreichend und für einen anderen ungeeignet sein. „AI-ready" sollte daher nicht als universelles Qualitätssiegel verstanden werden. Die erforderliche Datenqualität muss gegen den konkreten AI-Anwendungsfall bewertet werden.
Ein erreichbares Objekt ist noch kein lesbarer Inhalt
Daten müssen nicht nur gespeichert, sondern von den nachgelagerten Verarbeitungskomponenten interpretiert werden können. Unternehmensdaten liegen als Office-Dokumente, PDF-Dateien, Text, Bilder, Audio, Video, strukturierte Tabellen oder in anwendungsspezifischen Formaten vor. Zwischen Speicherung und AI-Verarbeitung befindet sich deshalb häufig eine Verarbeitungsschicht, die Daten liest, extrahiert, normalisiert oder transformiert.
Dabei sind zwei Fragen zu trennen: Kann das System auf die Datei oder das Objekt zugreifen? Und kann die Verarbeitungsschicht dessen Inhalt interpretieren? Ein technisch erreichbares Objekt ist noch kein maschinell nutzbarer Inhalt. Auch etablierte Protokolle unterscheiden deshalb zwischen übertragenen Daten und Metadaten über ihre Repräsentation. HTTP verwendet das Header-Feld Content-Type, um den Medientyp und damit die Interpretation einer Repräsentation zu beschreiben.
In der Praxis ist dieser Punkt häufig der eigentliche Engpass. Ein Object Store liefert das PDF zuverlässig aus; ob die Extraktionsschicht daraus verwertbaren Text gewinnt, hängt davon ab, ob es sich um ein Textdokument oder um ein eingescanntes Bild handelt. Diese Unterscheidung ist auf Storage-Ebene nicht sichtbar.
Metadaten liefern den Kontext, den das Modell nicht mitbringt
Ein Dokument enthält Informationen. Für seine sinnvolle Verwendung können jedoch zusätzliche Angaben erforderlich sein: Herkunft, Erstellungszeitpunkt, Version, Dokumenttyp, Eigentümer, fachliche Zuordnung oder Beziehungen zu anderen Daten. Metadaten bilden deshalb die Verbindung zwischen gespeicherten Daten und deren Interpretation.
Das W3C-PROV-Modell geht einen Schritt weiter und beschreibt Provenance – Informationen über Entitäten, Aktivitäten und Verantwortliche, die an der Entstehung von Daten beteiligt waren. Solche Herkunftsinformationen können zur Bewertung von Qualität, Zuverlässigkeit und Vertrauenswürdigkeit beitragen.
Damit sind Metadaten nicht nur ein Suchinstrument. Sie liefern Kontext für Klassifizierung, Governance, Retrieval und die Bewertung von Daten. [QUERVERWEIS: Data Intelligence & Governance – Titel und URL vor Veröffentlichung einsetzen]
Berechtigungen enden nicht an der Quelldatei
Die Einführung einer AI-Zugriffsschicht darf bestehende Schutzmechanismen nicht implizit außer Kraft setzen. Kann ein Benutzer eine Quelldatei nicht lesen, stellt sich bei einem darauf aufbauenden AI-System die Frage, ob und wie diese Zugriffsbeschränkung auch für daraus abgeleitete Informationen durchgesetzt wird.
Das Problem betrifft nicht nur den ursprünglichen Storage. Zwischen Quelle und Benutzer entstehen zusätzliche Systeme: Verarbeitung, Index, Retrieval und die AI-Anwendung selbst. Für diese Architektur muss definiert werden, an welchen Stellen Authentication und Authorization erfolgen und wie Zugriffsentscheidungen auf geschützte Ressourcen durchgesetzt werden.
[BILD 2: Berechtigungskette – Quelldaten, Verarbeitung, Index, Retrieval, AI-Anwendung, Benutzer; Markierung der Punkte, an denen Authentication und Authorization erfolgen müssen]
NIST SP 800-207 beschreibt für Zero-Trust-Architekturen einen ressourcenorientierten Ansatz: Der Schutz richtet sich auf Ressourcen statt auf Netzwerksegmente, und der Netzwerkstandort begründet allein kein implizites Vertrauen. NIST SP 800-207A überträgt dieses Prinzip auf verteilte, Cloud-native Anwendungen und verschiebt den Schwerpunkt von netzwerkbasierter Segmentierung hin zu identitätsbasierter Segmentierung – mit Authentication- und Authorization-Policies, die auch auf Anwendungs- und Service-Identitäten aufsetzen. Genau diese Konstellation liegt bei einer RAG-Kette vor, in der Extraktion, Index und Retrieval jeweils eigene Dienste sind.
Aus unseren Projekten kennen wir den umgekehrten Fall gut: Ein Index wird mit einem technischen Dienstkonto befüllt, das breite Leserechte besitzt, weil die Indexierung sonst unvollständig bleibt. Damit verlagert sich die Zugriffsentscheidung vollständig in die Retrieval-Schicht. Wird sie dort nicht sauber umgesetzt, entsteht ein Pfad, über den Inhalte sichtbar werden, für die auf der Quelldatei nie eine Berechtigung bestand. [QUERVERWEIS: Cyber Resilience– Titel und URL vor Veröffentlichung einsetzen]
AI-ready Data und High-Performance Data Access sind nicht dasselbe
AI-Systeme benötigen einen technischen Pfad zu den Quelldaten. Abhängig von der bestehenden Infrastruktur können Daten über SMB, NFS, S3, HTTP-basierte APIs oder Datenbank-Schnittstellen erreichbar sein. Die Existenz einer Schnittstelle allein reicht allerdings nicht aus: Für die Architektur sind Datenmenge, Zugriffsmuster, Parallelität, Latenz, benötigter Durchsatz und die Position der Verarbeitungskomponenten relevant.
Dabei sollte zwischen dem Speicherprotokoll und höheren Datenservices unterschieden werden. Ein Object Store stellt Daten über S3 bereit, ein File-System über SMB oder NFS. Darüber können zusätzliche Catalog-, Search-, Metadata- oder API-Schichten liegen. S3 ist dabei eine Zugriffsschicht auf den darunterliegenden Object Store, keine Datenplattform für sich. [QUERVERWEIS: S3 als Zugriffsschicht auf Object Storage – Titel und URL vor Veröffentlichung einsetzen]
Daraus folgt eine Unterscheidung, die in Architekturdiskussionen regelmäßig verwischt wird: Daten können semantisch und organisatorisch gut vorbereitet sein und trotzdem über einen ungeeigneten Datenpfad bereitgestellt werden. Umgekehrt macht ein sehr performanter Datenpfad schlecht klassifizierte oder nicht auffindbare Daten nicht AI-ready. Beide Fragen müssen getrennt beantwortet werden. [QUERVERWEIS: Hybrid-Cloud-Storage – Pfade und Performance planen – Titel und URL vor Veröffentlichung einsetzen]
Quelldaten und abgeleitete Strukturen driften auseinander
AI-Systeme sollten unterscheiden können, welche Version eines Datenbestands für den vorgesehenen Anwendungsfall maßgeblich ist. Das wird insbesondere relevant, wenn neben den Quelldaten weitere Repräsentationen entstehen. Ein RAG-System besitzt beispielsweise einen Suchindex, dessen Inhalte aus einem früheren Zustand der Quelldaten abgeleitet wurden.
Damit existieren mindestens zwei Zustände nebeneinander: der aktuelle Zustand der Quelldaten und der aktuelle Zustand der daraus abgeleiteten Datenstrukturen. Ändert oder löscht sich die Quelle, muss die Architektur definieren, wie und wann diese Änderung nachgelagerten Systemen bekannt wird. Versionierung ist auch Bestandteil etablierter Metadatenmodelle; DCAT 3 erweitert das Datenkatalogmodell entsprechend um Möglichkeiten zur Beschreibung von Versionierung und Dataset Series.
Daraus folgt eine weitergehende Anforderung an den Lifecycle. Daten entstehen, werden verändert, versioniert, archiviert und gelöscht – gleichzeitig erzeugen AI-Systeme daraus neue Strukturen wie extrahierten Text, Chunks, Embeddings oder Suchindizes. Das W3C-PROV-Modell bietet ein allgemeines Modell zur Beschreibung solcher Herkunfts- und Ableitungsbeziehungen, einschließlich Entitäten, Aktivitäten, Verantwortlichkeiten, zeitlicher Zusammenhänge und Ableitungen. Der Lifecycle darf deshalb nicht ausschließlich für die Quelldaten betrachtet werden. Auch abgeleitete Datenstrukturen gehören in die Lifecycle- und Governance-Prozesse – einschließlich Löschkonzepten.
Datenlokalität bleibt eine Architekturentscheidung
Wo Daten liegen, bleibt auch bei AI-Infrastrukturen relevant. Ein AI- oder Analytics-System kann in einem anderen Rechenzentrum, einer Cloud oder einer anderen Region betrieben werden als der zugrunde liegende Datenbestand. Dann befindet sich zwischen Compute und Storage ein Netzwerkpfad.
Datenlokalität beeinflusst deshalb die technische Architektur: Daten müssen entweder zur Verarbeitung transportiert werden, die Verarbeitung muss näher an die Daten gebracht werden, oder es wird eine Kombination aus Replikation, Caching und Datenbewegung gewählt. Hinzu kommen organisatorische und regulatorische Anforderungen daran, wo bestimmte Daten gespeichert oder verarbeitet werden dürfen.
„AI-ready" bedeutet daher nicht zwangsläufig, alle Unternehmensdaten in eine zentrale AI-Plattform zu kopieren. In verteilten Umgebungen mit mehreren Standorten hat sich in unseren Projekten der umgekehrte Ansatz bewährt: Der Datenbestand bleibt in einem zentralen Object Store, während die Verarbeitung dorthin verlagert wird, wo sie mit vertretbarem Netzwerkaufwand stattfinden kann. [QUERVERWEIS: Object Storage wird zur Datenplattform – Titel und URL vor Veröffentlichung einsetzen]
Der Energiebedarf gehört in die Architekturentscheidung
AI-Datenpfade sind energetisch kein Nebenschauplatz. Die Verlagerung von Verarbeitung in GPU-nahe Infrastruktur erhöht die Leistungsaufnahme pro Rack erheblich und verschiebt damit die Anforderungen an Anschlussleistung, Stromverteilung und Kühlung. Hinzu kommt, dass AI-Pipelines Daten mehrfach bewegen: Quelldaten werden gelesen, extrahiert, segmentiert, in Embeddings überführt und indexiert – jeder dieser Schritte verursacht Storage- und Netzwerklast, und bei Neuindexierungen wiederholt er sich vollständig.
Für Betreiber in Deutschland ist das unmittelbar regulatorisch relevant. Das Energieeffizienzgesetz gilt seit dem 18. November 2023 und stellt Rechenzentren unter ein eigenes energierechtliches Pflichtenregime mit Vorgaben zur Energieverbrauchseffektivität, zur Abwärmenutzung und zu Meldepflichten. Eine Novelle befindet sich derzeit im Gesetzgebungsverfahren: Das Bundeskabinett hat den Entwurf am 24. Juni 2026 beschlossen, die Beratung in Bundestag und Bundesrat steht noch aus. Der Entwurf hebt Schwellenwerte an, lockert die PUE-Vorgaben und reduziert den Adressatenkreis der Meldepflichten. Zu den konkreten Grenzwerten für Neubauten weichen die vorliegenden Fassungen und deren Auslegung voneinander ab; bis zur Verkündung gilt das bestehende Recht. Wir nennen an dieser Stelle deshalb bewusst keine Zahlenwerte.
Unabhängig vom Ausgang des Verfahrens bleibt ein methodischer Einwand bestehen: PUE misst das Verhältnis von Gesamtenergiebedarf zu IT-Energiebedarf und kann sich rechnerisch verbessern, während der absolute Verbrauch steigt. Wird ein bestehendes Rechenzentrum um AI-Kapazität erweitert, wächst der IT-Anteil überproportional – der PUE-Wert sinkt, die tatsächlich bezogene Energiemenge nimmt zu. Für die Bewertung einer AI-Dateninfrastruktur ist deshalb der absolute Energiebedarf entlang des gesamten Datenpfads die aussagekräftigere Größe. Dazu gehört auch die Frage, ob Daten für AI-Zwecke dupliziert werden müssen oder ob abgeleitete Strukturen inkrementell statt vollständig neu aufgebaut werden können. [QUERVERWEIS: Storage TCO – Titel und URL vor Veröffentlichung einsetzen]
AI-ready ist anwendungsbezogen, nicht universell
Datenqualität ist eine zentrale Voraussetzung, aber AI-ready Data umfasst mehr. Ein qualitativ hochwertiger Datenbestand hilft wenig, wenn das AI-System ihn nicht finden oder technisch nicht erreichen kann. Ebenso sind perfekt katalogisierte Daten nicht nutzbar, wenn die Verarbeitungskomponenten ihr Format nicht interpretieren können oder die erforderlichen Berechtigungen fehlen.
Eine AI-ready Data Infrastructure muss deshalb mehrere Ebenen zusammenbringen. Der Storage speichert Daten zuverlässig und stellt sie bereit. Die Zugriffsschicht ermöglicht den technischen Zugriff. Die Metadatenebene beschreibt Daten und macht sie auffindbar. Governance kontrolliert Nutzung, Verantwortlichkeiten und Lifecycle. Security setzt Authentication und Authorization durch. Die Verarbeitungsschicht interpretiert Daten und bereitet sie für die AI-Verarbeitung vor. Erst darüber liegt die eigentliche AI- oder Analytics-Nutzung. Keine dieser Ebenen allein macht Unternehmensdaten AI-ready.
[BILD 3: Ebenenmodell der AI-ready Data Infrastructure – Storage, Access, Metadata, Governance, Security, Processing, AI/Analytics mit jeweiliger Aufgabenzuordnung]
Daraus folgt eine Konsequenz, die in der Praxis oft übersehen wird: Es gibt keinen universellen Zustand, in dem sämtliche Unternehmensdaten „AI-ready" sind. Ein Dokumentbestand kann für Enterprise Search geeignet sein, für das Training eines Machine-Learning-Modells jedoch ungeeignet. Ein hochaktueller operativer Datenbestand kann für eine Echtzeitanalyse relevant sein, während ein anderer Anwendungsfall historische und versionierte Daten benötigt.
Die Architektur sollte deshalb nicht mit der Frage beginnen, wie sich die vorhandenen Daten AI-ready machen lassen. Präziser ist die Frage, welche Daten der konkrete AI-Anwendungsfall benötigt und welche Anforderungen sich daraus an Qualität, Metadaten, Zugriff, Berechtigungen, Aktualität und Infrastruktur ergeben. Erst danach lässt sich bestimmen, welche technischen Maßnahmen erforderlich sind.
Von vorhandenen Daten zur AI-ready Data Infrastructure
Für Unternehmen lässt sich daraus ein schrittweises Vorgehen ableiten. Zunächst werden die relevanten Datenquellen identifiziert. Danach wird geprüft, ob die benötigten Daten auffindbar, qualitativ geeignet, interpretierbar und aktuell sind. Im nächsten Schritt werden Berechtigungen und Governance betrachtet. Anschließend kann entschieden werden, wie die Daten technisch bereitgestellt werden und welche Processing-, Metadata-, Index- oder Retrieval-Komponenten zwischen Datenquelle und AI-Anwendung erforderlich sind.
Erst an dieser Stelle werden konkrete Infrastrukturentscheidungen sinnvoll. Storage-Performance, S3-Zugriff, File-Protokolle, Data Lakes, GPU-nahe Datenbereitstellung oder skalierbare Object-Storage-Systeme sind wichtige Bausteine einer solchen Architektur. Sie beantworten jedoch jeweils nur einen Teil der Gesamtfrage. Die Grundlagen der zugrunde liegenden Speicherarchitektur haben wir an anderer Stelle ausführlicher dargestellt: Enterprise Storage.
Fazit
AI-ready Data beschreibt keinen neuen Storage-Typ und kein einzelnes technisches Feature. Der Begriff fasst die Voraussetzungen zusammen, unter denen Daten für einen definierten AI- oder Machine-Learning-Anwendungsfall tatsächlich nutzbar werden. Dazu gehören Datenqualität und geeignete Formate ebenso wie Auffindbarkeit, Metadaten, Berechtigungen, technischer Zugriff, Aktualität, Datenlokalität, Schnittstellen und Lifecycle – und der Energiebedarf, den der gewählte Datenpfad verursacht.
Damit verschiebt sich die zentrale Infrastrukturfrage von der Frage, wo die Daten gespeichert werden, hin zu der Frage, wie die richtigen Daten kontrolliert und in geeigneter Form für AI-Systeme bereitgestellt werden. Genau an dieser Stelle entsteht die Verbindung zwischen bestehender Enterprise-Dateninfrastruktur und einer AI-ready Data Infrastructure.
Quellen
ISO/IEC JTC 1/SC 42: ISO/IEC 5259-1:2024 – Artificial intelligence — Data quality for analytics and machine learning (ML) — Part 1: Overview, terminology, and examples, 2024.
ISO/IEC JTC 1/SC 42: ISO/IEC 5259-2:2024 – Artificial intelligence — Data quality for analytics and machine learning (ML) — Part 2: Data qualitymeasures, 2024.
ISO/IEC JTC 1/SC 42: ISO/IEC 5259-3:2024 – Artificial intelligence — Data quality for analytics and machine learning (ML) — Part 3: Data qualitymanagement requirements and guidelines, 2024.
ISO/IEC JTC 1/SC 42: ISO/IEC 5259-4:2024 – Artificial intelligence — Data quality for analytics and machine learning (ML) — Part 4: Data qualityprocess framework, 2024.
ISO/IEC JTC 1/SC 42: ISO/IEC 5259-5:2025 – Artificial intelligence — Data quality for analytics and machine learning (ML) — Part 5: Data qualitygovernance framework, Februar 2025.
ISO/IEC JTC 1/SC 7: ISO/IEC 25012:2008 – Software engineering — Software product Quality Requirements and Evaluation (SQuaRE) — Data qualitymodel, 2008; zuletzt 2025 überprüft und bestätigt. Herangezogen für die Abgrenzung zwischen strukturbezogenem Qualitätsmodell und der Ausrichtung der 5259-Reihe auf unstrukturierte Daten.
W3C: Data Catalog Vocabulary (DCAT) – Version 3, W3C Recommendation, 22. August 2024. Herausgegeben von der Dataset Exchange Working Group.
W3C: PROV-DM: The PROV Data Model, W3C Recommendation, 30. April 2013.
W3C: PROV-Overview: An Overview of the PROV Family of Documents, W3C Note, 30. April 2013. Als Note nicht normativ; hier ausschließlich zur Einordnung der PROV-Dokumentenfamilie herangezogen.
NIST: Special Publication 800-207 – Zero Trust Architecture, August 2020.
NIST: Special Publication 800-207A – A Zero Trust Architecture Model for Access Control in Cloud-Native Applications in Multi-Location Environments, September 2023. Ko-Autor Zack Butcher ist bei Tetrate, Inc. tätig; die Publikation ist gleichwohl als NIST Special Publication veröffentlicht.
IETF: RFC 9110 – HTTP Semantics, Juni 2022.
Bundesrepublik Deutschland: Energieeffizienzgesetz (EnEfG), in Kraft seit 18. November 2023.
Bundesregierung: Entwurf eines Gesetzes zur Beschleunigung der Umsetzung der Energieeffizienzrichtlinie, Kabinettsbeschluss vom 24. Juni 2026. Zum Redaktionsschluss im parlamentarischen Verfahren; Angaben zu Grenzwerten daher nur richtungsbezogen.
ASSISTRA Cloud Services GmbH: Beobachtungen aus Migrations- und Storage-Projekten, als eigene Projekterfahrung gekennzeichnet.
Welche Entscheidung steht bei Ihnen an?
Sie möchten eine bestehende Infrastruktur bewerten, eine neue Architektur planen oder eine konkrete technische Fragestellung klären? Sprechen Sie mit uns über Ihre Anforderungen.
Spezialist für moderne Dateninfrastruktur
