Nuestro Primer Contratado: el Anonimizador de Conjuntos de Datos — MVP0 en Período de Prueba
Publié le 01 May 2026
Table des matières
tiempo de lectura: 12 minutes
No contrato un LLM. Contrato un anonimizador. Antes de hacer RAG pgvector, antes de ajustar finamente a expertos CDA/FPA, antes de aprovisionar los workspaces de los clientes — alguien debe limpiar los baños de los datos. Este empleado es el experto en anonimización (MVP0, EPIC 2 de codebase-gradle). Y es él quien hace que el producto sea comercializable.
- tic
-
[]
El Problema que Hace que Todos Huyan
Toda startup de IA que manipule datos de entrenamiento se encuentra con la misma barrera :
----
----
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
----
Resultado: o bien haces RAG sobre datos sucios (alucinaciones de PII, no conformidad con el RGPD, riesgo legal), o bien no haces nada (sin producto). La tercera vía — limpiar a mano — no es escalable.
Mi respuesta: no evitar el problema. L'**automatizar**.
== MVP0 : El Anonimizador, Primer Contratado en Periodo de Prueba
El MVP0 no es una característica. Es un**experto de comodidad**— un empleado que hace el trabajo sucio, tonto y malvado, y del que nadie quiere hablar en los pitch decks.
Lo que hace :
[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
----
Detecta los patrones más obvios primero (emails`.*@.*`, tokens`sk-*`, `ghp_*`), IP), luego aprende. El período de prueba, eso es: validamos que no deje pasar falsos negativos antes de titularlo.
== Lo que este MVP desbloquea (y no es solo el cumplimiento)
La anonimización como MVP0 no es el peaje del RGPD antes de la autopista. Es la autopista misma. Esto es lo que abre:
=== Presente : Realidad Aumentada en 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
----
El RAG no busca en datos sucios — busca en un espacio**limpio por construcción**. Cambia todo para la calidad de las respuestas: el LLM no pasa su tiempo evitando las PII que reconoce pero que no debe mencionar.
=== Futuro: Ajuste fino sobre datos sanos
[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)
----
El ajuste fino en datos brutos es una catástrofe jurídica potencial. En datos limpios, es una**método reproducible**. Cada cliente acumula sus datasets limpios, cada cliente puede ajustar fino sus expertos de negocio sobre sus datos — sin exponer nunca un dato personal.
== ¿Por qué es comercializable?
No es « una herramienta de conformidad RGPD ». Es una**método reproducible que transforma un problema universal en activo**:
1. *Toda empresa de formación tiene datos sucios* — eso es el problema
2. *Ninguna tiene un pipeline automatizado de limpieza multi‑fuente* — es el mercado
3. *El bucle: anonimización → RAG → fine-tuning es propietario* — es la barrera
El SaaS Edster (MVP3) no venderá « un workspace Gradle ». Venderá este bucle cerrado. Y el MVP0 es la puerta de entrada.
== El formato SQL como tercera vía de contexto
La importación de datos estructurados no es solo un formato de intercambio. El esquema SQL (DDL) lleva el**modelo entidad-relación del dominio** :
[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é
);
----
Este DDL, una vez anonimizado (línea 4), se convierte en una fuente de contexto para el LLM. No es texto — del**modelo de negocio**. El RAG da el contenido (similaridad vectorial), Graphify da las relaciones (estructura exacta), y el esquema SQL da el**Domain-Driven Design implícito**: bounded contexts, agregados, value objects. El LLM comprende el dominio porque lee su esquema.
== El roadmap : del MVP0 al 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
----
Cada MVP depende del anterior. Ninguno puede ser entregado sin el MVP0. Esa es la razón por la cual el Anonimizador no es « P0 » en el backlog — es**MVP0**. Es el primer entregable comercial, y todo lo demás está condicionado a su éxito.
== Conclusión: el Trabajo Invisible que hace posible todo
En una startup tradicional, la limpieza de datos está externalizada, manual o ignorada. En esta arquitectura, es el**corazón del producto**. El Anonimizador es el primer empleado porque sin él, nada funciona :
* Sin MVP0 → sin RAG legal (MVP1)
* Sin MVP0 → sin fine-tuning sin fuga de datos (EPIC 5)
* Sin MVP0 → ningún SaaS creíble (MVP3)
* Sin MVP0 → no hay realidad aumentada en prompt
* Sin MVP0 → no hay tercera vía de contexto (SQL DDD)
Él hace el trabajo sucio. Nunca será mencionado en los pitchs. Pero él es quien hace que la fábrica funcione.
Y es por eso que lo contratamos primero.
== Referencias
* Artículo sobre la ontología espacial y los círculos de confianza:link:../2026/0114_gouvernance_cercles_confiance_ontologie_spatiale_alignement_llm_post.html[La ontología espacial como mecanismo de la alineación]
* artículo sobre el agente de gobernanza Eager/Lazy:link:../2026/0108_gouvernance_agent_opencode_eager_lazy_post.html[Gobernar un agente de IA con AsciiDoc]
* Artículo sobre el mecanismo Hot/Warm/Cold :link:../2026/0110_mecanisme_backup_contexte_agent_post.html[Ventana deslizante y ola de frío]
* Artículo sobre la comparación de los tres LLMs:link:../2026/0112_comparaison_kimi_glm_deepseek_long_contexte_plugin_gradle_opencode_post.html[DeepSeek-V4-Pro, Kimi K2.6, GLM-5.1]
----