Il nostro primo assunto: l'anonimizzatore di dataset — MVP0 in periodo di prova
Publié le 01 May 2026
Table des matières
tempo di lettura : 12 minutes
Non assumo un LLM. Assumo un anonymizzatore. Prima di fare RAG pgvector, prima di fare il fine-tuning degli esperti CDA/FPA, prima di effettuare il provisioning di workspaces per i clienti — qualcuno deve pulire i bagni dei dati. Questo dipendente è l’esperto di anonimizzazione (MVP0, EPIC 2 di codebase-gradle). Ed è lui che rende il prodotto commerciabile.
- toc
-
[]
Il problema che fa fuggire tutti
Ogni startup IA che manipola dati di addestramento si scontra con lo stesso muro :
----
----
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
----
Risultato: o fai RAG su dati sporchi (allucinazioni di PII, non conformità al GDPR, rischio legale), o non fai nulla (nessun prodotto). La terza via — pulire manualmente — non è scalabile.
Mia risposta: non aggirare il problema. L'**automatizzare**.
== MVP0 : l'Anonymiseur, primo assunto nel periodo di prova
Il MVP0 non è una funzionalità. È un**esperto di comodità**— un dipendente che svolge il lavoro sporco, stupido e cattivo, e di cui nessuno vuole parlare nei pitch deck.
Cosa fa:
[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
----
Rileva prima i modelli più evidenti (email`.*@.*`, tokens`sk-*`, `ghp_*`, IPs), poi impara. Il periodo di prova è questo: validiamo che non lasci passare falsi negativi prima di titolarizzarlo.
== Cosa sblocca questo MVP (e non è solo la conformità)
L'anonimizzazione come MVP0 non è il pedaggio RGPD prima dell'autostrada. È l'autostrada stessa. Ecco cosa apre :
=== Presente : Realtà Aumentata in 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
----
Il RAG non cerca nei dati sporchi — cerca in uno spazio**corretto per costruzione**Questo cambia tutto per la qualità delle risposte: il LLM non passa il suo tempo a evitare dei PII che riconosce ma che non deve menzionare.
=== Futuro: Fine‑tuning sui dati sani
[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)
----
Il fine-tuning sui dati grezzi è una potenziale catastrofe giuridica. Con i dati puliti, è una**metodo riproducibile**. Ogni cliente accumula i suoi dataset puliti, ogni cliente può effettuare il fine‑tuning dei suoi esperti di settore sui propri dati — senza mai esporre un dato personale.
== Perché è commerciale
Non è « uno strumento di conformità GDPR ». È una**metodo riproducibile che trasforma un problema universale in attivo** :
1. *Ogni azienda di formazione ha dati sporchi* — è il problema
2. *Nessuna ha un pipeline automatizzato di pulizia multi-sorgente* — è il mercato
3. *Il ciclo: anonimizzazione → RAG → fine-tuning è proprietario* — è la barriera
Il SaaS Edster (MVP3) non venderà « un workspace Gradle ». Venderà questo ciclo chiuso. E il MVP0 è la porta d'ingresso.
== Il formato SQL come terza via di contesto
L'importazione di dati strutturati non è solo un formato di scambio. Lo schema SQL (DDL) porta il**modello entità-relazione del dominio**</think>
[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é
);
----
Questo DDL, una volta anonimizzato (riga 4), diventa una fonte di contesto per il LLM. Non testo — di**modello mestiere**. Il RAG fornisce il contenuto (similarità vettoriale), Graphify fornisce le relazioni (struttura esatta), e lo schema SQL fornisce il**Domain-Driven Design implicito**: bounded contexts, aggregati, oggetti di valore. Il LLM comprende il settore perché legge il suo schema.
== La roadmap: da MVP0 a 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
----
Ogni MVP dipende dal precedente. Nessuno può essere consegnato senza il MVP0. Questa è la ragione per cui l'Anonymiseur non è « P0 » nel backlog — è**MVP0**. È il primo deliverable commerciale, e tutto il resto è condizionato al suo successo.
== Conclusione: il lavoro invisibile che rende tutto possibile
In una startup classica, la pulizia dei dati è esternalizzata, manuale, o ignorata. In questa architettura, è il**cuore del prodotto**. L'anonimizzatore è il primo dipendente perché senza di lui, nulla funziona :
* Senza MVP0 → nessun RAG legale (MVP1)
* Senza MVP0 → nessun fine-tuning senza perdita di dati (EPIC 5)
* Senza MVP0 → nessun SaaS credibile (MVP3)
* Senza MVP0 → nessuna realtà aumentata nel prompt
* Senza MVP0 → nessuna terza via di contesto (SQL DDD)
Fa il lavoro sporco. Non sarà mai citato nei pitch. Ma è lui a far girare la fabbrica.
E' per questo che lo assumono per primo.
== Riferimenti
* Articolo sull'ontologia spaziale e i cerchi di fiducia :link:../2026/0114_gouvernance_cercles_confiance_ontologie_spatiale_alignement_llm_post.html[L'Ontologia Spaziale come Meccanismo di Allineamento]
* Articolo sulla governance dell'agente Eager/Lazy :link:../2026/0108_gouvernance_agent_opencode_eager_lazy_post.html[Governare un Agente IA con AsciiDoc]
* Articolo sul meccanismo Hot/Warm/Cold :link:../2026/0110_mecanisme_backup_contexte_agent_post.html[Sliding Window e Onda Fredda]
* Articolo sulla comparazione dei tre LLMs:link:../2026/0112_comparaison_kimi_glm_deepseek_long_contexte_plugin_gradle_opencode_post.html[DeepSeek-V4-Pro, Kimi K2.6, GLM-5.1]
----
Articoli correlati
L'architettura « Plugin Indipendente + Radice Consumatore » : Perché i miei build Gradle si duplicano
14 May 2026
14 May 2026