KI-Trainingsdaten speichern: S3 Object Storage aus DE

Machine-Learning-Projekte scheitern selten an den Modellen – sondern an den Daten. Wer KI in Deutschland produktiv einsetzen will, braucht einen Speicher, der Terabytes an Trainingsdaten günstig, schnell und vor allem rechtssicher aufbewahrt. Genau hier wird S3-kompatibler Object Storage zum Fundament moderner KI-Infrastruktur. Dieser Praxis-Guide zeigt, wie Sie einen Data Lake für KI- und ML-Trainingsdaten aufbauen, der DSGVO-konform ist, den EU AI Act berücksichtigt und trotzdem kalkulierbar bleibt.

Warum Object Storage der natürliche Speicher für KI-Trainingsdaten ist

Trainingsdatensätze bestehen aus Millionen kleiner und großer Dateien: Bilder, Audiomitschnitte, PDFs, Sensor-Logs, Videoframes, Embeddings, Checkpoints. Klassische Fileserver oder NAS-Systeme stoßen dabei schnell an Grenzen – bei der Anzahl der Objekte, beim parallelen Zugriff und beim Preis pro Terabyte. Object Storage wurde für genau dieses Szenario entworfen:

• Flache Struktur statt Verzeichnisbaum: Milliarden Objekte in einem Bucket, ohne Performance-Einbruch durch tiefe Ordnerhierarchien.
• Metadaten am Objekt: Labels, Lizenz, Herkunft, Einwilligungsstatus und Datenschutzklassifizierung lassen sich direkt am Objekt hinterlegen – die Basis für eine belastbare Data Governance.
• Paralleler Zugriff über HTTP(S): Mehrere GPU-Worker, Dataloader oder Notebooks lesen gleichzeitig aus demselben Bucket.
• Versionierung: Datensatz-Versionen bleiben reproduzierbar – Voraussetzung für nachvollziehbare Modell-Trainings.
• Standard-API: Die S3-API ist der De-facto-Standard; nahezu jedes ML-Framework spricht sie nativ.

Der entscheidende Punkt für den deutschen Mittelstand: Object Storage ist der einzige Speichertyp, der Kapazität und Kosten linear skaliert. Bei safes3 liegt der Preis bei 0,025 EUR pro GB und Monat – ohne Traffic-Limit und ohne API-Gebühren. Gerade beim Training zählt das: Ein Datensatz wird nicht einmal, sondern über dutzende Epochen und Experimente hinweg gelesen. Bei Hyperscalern schlagen genau diese Lese- und Egress-Vorgänge als versteckte Kosten zu Buche.

Der DSGVO-Faktor: Trainingsdaten sind fast immer personenbezogen

Ein weit verbreiteter Irrtum lautet: „Wir trainieren doch nur ein Modell, das ist keine Datenverarbeitung.“ Das Gegenteil ist der Fall. Sobald ein Trainingsdatensatz Gesichter, Stimmen, Namen, Kundenkorrespondenz, Bewerbungsunterlagen, Support-Tickets oder Standortdaten enthält, greift die DSGVO in vollem Umfang – von der Rechtsgrundlage nach Art. 6 über die Zweckbindung bis zu den Betroffenenrechten nach Art. 15 bis 17.

Diese Pflichten betreffen direkt Ihren Speicher

• Art. 5 – Speicherbegrenzung: Rohdaten dürfen nicht unbegrenzt „für später“ liegen bleiben. Lifecycle-Regeln im Bucket setzen Löschfristen technisch durch.
• Art. 17 – Recht auf Löschung: Sie müssen einzelne Datensätze auffinden und entfernen können. Ohne saubere Objekt-Metadaten ist das in einem Data Lake praktisch unmöglich.
• Art. 32 – Sicherheit der Verarbeitung: Verschlüsselung bei Übertragung und im Ruhezustand, Zugriffskontrolle, Wiederherstellbarkeit.
• Art. 28 – Auftragsverarbeitung: Ein AV-Vertrag mit dem Storage-Anbieter ist Pflicht, nicht Kür.
• Art. 44 ff. – Drittlandtransfer: Liegen die Daten auf Servern eines US-Konzerns, bleibt der CLOUD Act ein reales Zugriffsrisiko – unabhängig vom Rechenzentrumsstandort.

Wer diese Punkte ernst nimmt, kommt zu einem klaren Ergebnis: Trainingsdaten deutscher Unternehmen gehören auf deutsche Infrastruktur. Alle Buckets bei safes3 liegen ausschließlich in deutschen Rechenzentren, betrieben von einem deutschen Unternehmen – ohne Drittlandtransfer, ohne Schrems-II-Diskussion und mit deutschsprachigem Ansprechpartner am Telefon.

EU AI Act: Warum Data Governance ab 2026 zur Pflicht wird

Der EU AI Act ist seit August 2024 in Kraft und wird stufenweise anwendbar: verbotene Praktiken seit Februar 2025, Pflichten für General-Purpose-KI-Modelle seit August 2025, die Kernpflichten für Hochrisiko-Systeme folgen in den Jahren 2026 und 2027. Für Unternehmen, die eigene Modelle trainieren oder feinjustieren, ist vor allem Artikel 10 (Daten und Daten-Governance) relevant. Er verlangt unter anderem:

• dokumentierte Herkunft und Erhebungsmethodik der Trainings-, Validierungs- und Testdaten
• Prüfung auf Verzerrungen (Bias) und Repräsentativität
• nachvollziehbare Datenaufbereitung, Annotation und Bereinigung
• Aufbewahrung der technischen Dokumentation über den Lebenszyklus des Systems

Übersetzt in Infrastruktur heißt das: Sie brauchen unveränderliche, versionierte Datensatz-Stände plus zugehörige Dokumentation – und zwar über Jahre. Ein S3-Bucket mit aktivierter Versionierung, Object-Lock-Logik und klarer Namenskonvention ist dafür das pragmatischste Werkzeug. Wer heute unstrukturiert auf lokale Platten trainiert, wird die Nachweispflichten später nicht erfüllen können.

Referenzarchitektur: Ein KI-Data-Lake mit S3 in fünf Zonen

Bewährt hat sich eine Trennung des Buckets in klar abgegrenzte Zonen – als Präfixe oder als separate Buckets:

• raw/ – Rohdaten, unverändert, schreibgeschützt, mit Herkunftsnachweis und Einwilligungsstatus in den Metadaten.
• curated/ – bereinigte, deduplizierte, pseudonymisierte Daten; hier greifen Löschanfragen zuerst.
• datasets/ – eingefrorene Trainingssätze mit Versionsnummer (z. B. datasets/v3/), reproduzierbar und unveränderlich.
• artifacts/ – Modell-Checkpoints, Gewichte, Tokenizer, Metriken und Trainingslogs.
• archive/ – abgeschlossene Projekte mit Lifecycle-Regel und definiertem Löschdatum.

Diese Struktur beantwortet drei Fragen, die im Audit garantiert gestellt werden: Woher stammen die Daten? Welche exakte Datenversion hat welches Modell trainiert? Und wann werden sie gelöscht?

Praxis: So binden Sie S3-Storage in Ihre ML-Pipeline ein

Weil safes3 vollständig S3-kompatibel ist, funktionieren die etablierten Werkzeuge ohne Umbau – lediglich der Endpoint wird getauscht. Typische Bausteine im deutschen ML-Alltag:

• AWS CLI & s3cmd für Bulk-Uploads und nächtliche Syncs großer Datensätze
• boto3 / s3fs für direktes Streaming in PyTorch- oder TensorFlow-Dataloader, ohne den Datensatz vorher lokal zu kopieren
• DVC oder LakeFS für Datenversionierung mit Git-artigem Workflow auf S3-Backend
• MLflow mit S3 als Artifact Store für Modelle, Metriken und Reproduzierbarkeit
• Cyberduck oder CloudBerry für Fachabteilungen, die Daten per GUI beisteuern
• Airflow, Dagster oder GitLab CI für automatisierte ETL- und Trainings-Pipelines

Ein häufig unterschätzter Vorteil: Da keine API-Gebühren anfallen, können Dataloader Objekte beliebig oft anfordern. Bei Hyperscalern zwingt das Preismodell Teams oft zu unnötigen Caching-Konstruktionen – nur um Request-Kosten zu drücken.

Kostenrechnung: Ein realistisches Beispiel

Ein mittelständischer Maschinenbauer trainiert ein Modell zur optischen Qualitätskontrolle. Der Bilddatensatz umfasst 20 TB, dazu kommen 3 TB Checkpoints und Artefakte. Pro Monat werden rund 40 TB gelesen, weil mehrere Experimente parallel laufen.

• Speicher: 23.000 GB × 0,025 EUR = 575 EUR pro Monat
• Traffic: 0 EUR – kein Traffic-Limit
• API-Requests: 0 EUR – keine Gebühren
• Mindestlaufzeit: keine – das Projekt kann monatlich skalieren

Bei US-Hyperscalern kämen zu den Speicherkosten typischerweise Request- und Egress-Gebühren hinzu, sobald Daten das Rechenzentrum verlassen – etwa für Auswertungen im eigenen Haus oder für einen Wechsel des Anbieters. Genau dieser Egress-Posten ist das klassische Vendor-Lock-in-Instrument. Mehr zum Vergleich finden Sie in unserem Beitrag Amazon S3 vs. safes3.

Sicherheit: Verschlüsselung, Zugriff und Backup

Trainingsdaten sind Betriebsgeheimnis und personenbezogene Daten zugleich. Drei Ebenen sollten Standard sein:

• Transportverschlüsselung per SSL/TLS für jeden Zugriff, plus End-to-End-Verschlüsselung sensibler Rohdaten.
• Least Privilege: getrennte Access Keys für Ingest, Training und Auswertung; Trainings-Worker brauchen in der Regel nur Lesezugriff.
• 3-2-1-Backup der eingefrorenen Datensätze und Modell-Artefakte – Details dazu in unserem Guide zur Backup-Strategie mit S3.

Hinzu kommen DDoS-Schutz und eine Uptime-Garantie von 99,5 %, damit laufende Trainingsjobs nicht an einem nicht erreichbaren Bucket scheitern.

Nachhaltigkeit: KI-Training hat einen Fußabdruck

KI-Workloads sind energieintensiv – das gilt für GPUs ebenso wie für den Speicher, der rund um die Uhr läuft. Wer eine glaubwürdige ESG-Bilanz und CSRD-Berichterstattung braucht, sollte auch den Storage-Anbieter prüfen. safes3 setzt auf 100 % erneuerbare Energien, Wärmerückgewinnung und Second-Life-Hardware. Der Betrieb aus Mainfranken heraus bedeutet zudem kurze Wege, regionale Wertschöpfung und persönliche Ansprechpartner statt anonymer Ticket-Systeme.

Häufige Fehler beim Aufbau eines KI-Data-Lakes

• Rohdaten und Trainingsdatensätze im selben Präfix vermischen – Reproduzierbarkeit geht verloren.
• Keine Metadaten zu Herkunft und Einwilligung – Löschanfragen werden zum manuellen Suchspiel.
• Versionierung deaktiviert lassen, um Speicher zu sparen – und damit den AI-Act-Nachweis verlieren.
• Trainingsdaten dauerhaft auf lokalen Workstations halten, ohne Backup und ohne Zugriffskontrolle.
• Den Anbieter allein nach dem GB-Preis wählen, ohne Egress- und Request-Kosten einzurechnen.

Fazit: Souveräne KI beginnt beim Speicher

Ein KI-Projekt ist nur so vertrauenswürdig wie die Datenbasis, auf der es steht. S3-kompatibler Object Storage aus Deutschland löst dabei gleich mehrere Probleme auf einmal: Er skaliert auf beliebige Datenmengen, spricht die Standard-API aller ML-Werkzeuge, hält die Kosten durch wegfallende Traffic- und API-Gebühren kalkulierbar – und schafft die dokumentarische Grundlage, die DSGVO und EU AI Act verlangen. Für KMU, Start-ups und Behörden ist das kein Nice-to-have, sondern die Voraussetzung für KI, die auch im Audit besteht.

Jetzt souveränen KI-Speicher starten

Bauen Sie Ihren Trainingsdaten-Speicher auf einer Infrastruktur auf, die vollständig in Deutschland betrieben wird: 0,025 EUR pro GB im Monat, kein Traffic-Limit, keine API-Gebühren, keine Mindestlaufzeit – dazu deutschsprachiger Support per Mail und Telefon. Jetzt unverbindlich testen unter safes3 und den ersten Bucket in wenigen Minuten mit AWS CLI, boto3 oder Cyberduck anbinden.