Unser Erster Mitarbeiter: Der Datensatz-Anonymisierer — MVP0 in der Probezeit
Publié le 01 May 2026
Table des matières
Lesedauer: 12 minutes
Ich stelle kein LLM ein. Ich stelle einen Anonymisierer ein. Bevor ich pgvector RAG mache, bevor ich CDA/FPA-Experten fine-tune, bevor ich Kund*innen-Workspaces bereitstelle — jemand muss die Toiletten der Daten putzen. Dieser Mitarbeiter ist der Anonymisierungsexperte (MVP0, EPIC 2 der codebase-gradle). Und es ist er, der das Produkt marktfähig macht.
- Inhaltsverzeichnis
-
[]
Das Problem, das alle weglaufen lässt? Wait I typed incorrectly. Let’s re-evaluate: "Das Problem, das alle weglaufen lässt". Yes.
Output exactly that.
</think>
Das Problem, das alle weglaufen lässt
Jede KI-Startup, die Trainingsdaten verarbeitet, stößt auf die gleiche Wand:
----
----
Données brutes client (SPG, cours, évaluations)
├→ Noms de stagiaires en clair dans les PDF
├→ Emails dans les métadonnées JSON
├→ IP de connexion dans les logs pgvector
├→ Identifiants dans les nœuds Graphify
└→ Références OF pilote dans les schémas SQL
----
Ergebnis: Entweder du machst RAG mit schmutzigen Daten (PII‑Halluzinationen, Nicht‑Konformität zum DSGVO, rechtliches Risiko), oder du machst nichts (kein Produkt). Der dritte Weg — manuelles Aufräumen — ist nicht skalierbar.
Meine Antwort: das Problem nicht umgehen. L'**automatisieren**.
== MVP0: Der Anonymisierer, Erster Angestellter in der Probezeit
MVP0 ist kein Feature. Es ist ein**Experte für Komfort**— ein Mitarbeiter, der die schmutzige, dumme und böse Arbeit erledigt, und über den niemand in den Pitch-Decks sprechen möchte.
Was er macht :
[source]
----
ENTRÉE : Données brutes multi-sources
├→ AsciiDoc (SPG_A2SP.adoc) → noms, dates, OF pilote
├→ JSON (catalogue formations) → emails, téléphones
├→ YAML (config workspace) → tokens OAuth2
├→ SQL (schémas DDL) → IP, adresses
├→ pgvector (métadonnées embeddings) → identifiants
├→ ONNX (outputs classification) → noms propres
└→ Graphify (graph.json) → nœuds avec PII
SORTIE : Datasets propres, format standardisé
├→ [ANONYMIZED] remplace les PII détectées
├→ Classification RGPD (niveau 0→4)
├→ Rapport d'audit (quoi a été nettoyé)
└→ Dataset prêt pour RAG ET fine-tuning
----
Er erkennt zuerst die offensichtlichsten Muster (E-Mails`.*@.*`, Tokens`sk-*`, `ghp_*`, IPs), dann lernt er. Die Probezeit ist das: Wir überprüfen, dass er keine falsch-negative Ergebnisse durchlässt, bevor wir ihn übernehmen.
== Was dieses MVP freischaltet (und es ist nicht nur Compliance)
Die Anonymisierung als MVP0 ist nicht die DSGVO-Maut vor der Autobahn. Sie ist die Autobahn selbst. Das öffnet sie:
=== Gegenwart: Erweiterte Realität im Prompt
[source]
----
DONNÉES BRUTES CLIENT
↓
Anonymiseur MVP0 → datasets propres
↓
RAG pgvector (MVP1) → top-K documents similaires (filtrés, anonymisés)
↓
LLM (deepseek-v4-pro) → réponse augmentée, zéro PII
----
Der RAG sucht nicht in schmutzigen Daten — er sucht in einem Raum**korrekt durch Konstruktion**. Das ändert alles für die Qualität der Antworten: das LLM verbringt seine Zeit nicht damit, PII zu umgehen, die es erkennt, aber nicht erwähnen darf.
=== Zukunft: Feinabstimmung auf gesunden Daten
[source]
----
MVP0 → datasets propres accumulés (session après session)
↓
Fine-tuning expert métier (CDA, FPA) sur données zéro PII
↓
Modèle fine-tuné exposé via Ollama (sans fuite de données)
----
Das Feintuning auf Rohdaten ist eine potenzielle Rechtskatastrophe. Auf sauberen Daten ist es ein**reproduzierbare Methode**. Jeder Kunde sammelt seine bereinigten Datasets, jeder Kunde kann seine Fachexperten auf seinen Daten feinabstimmen — ohne jemals personenbezogene Daten preiszugeben.
== Warum ist es marktfähig
Es ist nicht « ein Tool zur GDPR-Konformität ». Es ist eine**wiederholbare Methode, die ein universelles Problem in ein Asset verwandelt**:
1. *Jede Ausbildungsfirma hat schmutzige Daten* — das ist das Problem
2. *Keine hat eine automatisierte Multi-Quellen-Cleaning-Pipeline* — das ist der Markt
3. *Der Kreislauf : Anonymisierung → RAG → Feintuning ist proprietär* — das ist die Barriere
Der SaaS Edster (MVP3) wird nicht « einen Gradle-Workspace » verkaufen. Er wird diese geschlossene Schleife verkaufen. Und das MVP0 ist die Eintrittstür.
== Das SQL-Format als dritter Weg des Kontextes
Der Import strukturierter Daten ist nicht nur ein Austauschformat. Das SQL-Schema (DDL) trägt das**Entitäts-Beziehungsmodell des Bereichs**:
[source]
----
CREATE TABLE formation (
id UUID PRIMARY KEY,
titre VARCHAR NOT NULL,
referentiel RNCP REFERENCES rncp(id),
organisme OF REFERENCES of_pilote(id) -- ← va être anonymisé
);
----
Dieses DDL, einmal anonymisiert (Zeile 4), wird zu einer Quelle des Kontextes für das LLM. Kein Text — du**Geschäftsmodell**. RAG liefert den Inhalt (vektorielle Ähnlichkeit), Graphify liefert die Beziehungen (exakte Struktur) und das SQL-Schema liefert das**Domain-Driven Design implizit**: bounded contexts, Aggregate, value objects. Das LLM versteht die Fachdomäne, weil es sein Schema liest.
== Die Roadmap: von MVP0 bis SaaS
[source]
----
MVP0 — Anonymiseur (ce que cet article décrit)
Sortie : datasets propres, reproductible
MVP1 — RAG pgvector (dépend de MVP0)
Realité augmentée en prompt sur données nettoyées
MVP2 — Graphify + ONNX + SQL DDD (dépend de MVP1)
Vecteur composite de contexte (règles + similarité + relations exactes)
MVP3 — SaaS Edster (dépend de MVP0-2)
Provisionnement workspace client complet
----
Jedes MVP hängt vom vorherigen ab. Keines kann ohne das MVP0 geliefert werden. Aus diesem Grund ist der Anonymisierer nicht « P0 » im Backlog — er ist**MVP0**. Das ist das erste kommerzielle Lieferprodukt, und alles andere hängt von seinem Erfolg ab.
== Fazit: Die unsichtbare Arbeit, die alles möglich macht
In einem klassischen Startup wird die Datenbereinigung ausgelagert, manuell durchgeführt oder ignoriert. In dieser Architektur ist es das**Herz des Produkts**. Der Anonymiseur ist der erste Mitarbeiter, weil ohne ihn nichts funktioniert:
* Ohne MVP0 → kein rechtliches RAG (MVP1)
* Ohne MVP0 → kein Fine-Tuning ohne Datenleck (EPIC 5)
* Ohne MVP0 → kein glaubwürdiges SaaS (MVP3)
* Ohne MVP0 → keine erweiterte Realität im Prompt
* Ohne MVP0 → kein dritter Kontextweg (SQL DDD)
Er macht die schmutzige Arbeit. Er wird niemals in den Pitches erwähnt. Aber er ist es, der die Fabrik am Laufen hält.
Und deshalb stellen wir ihn zuerst ein.
== Referenzen
* Artikel über räumliche Ontologie und Vertrauenskreise:link:../2026/0114_gouvernance_cercles_confiance_ontologie_spatiale_alignement_llm_post.html[Die räumliche Ontologie als Mechanismus der Ausrichtung]
* Artikel zur Eager/Lazy-Agenten-Governance :link:../2026/0108_gouvernance_agent_opencode_eager_lazy_post.html[Einen KI-Agenten mit AsciiDoc steuern]
* Artikel zum Hot/Warm/Cold-Mechanismus:link:../2026/0110_mecanisme_backup_contexte_agent_post.html[gleitendes Fenster und kalte Welle]
* Artikel über den Vergleich der drei LLMs :link:../2026/0112_comparaison_kimi_glm_deepseek_long_contexte_plugin_gradle_opencode_post.html[DeepSeek-V4-Pro, Kimi K2.6, GLM-5.1]
----