tiempo de lectura : 12 minutes

No contrato un LLM. Contrato un anonimizador. Antes de hacer RAG pgvector, antes de afinar a los expertos CDA/FPA, antes de aprovisionar los espacios de trabajo de los clientes — alguien tiene que 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.

toc

[]

El problema que hace huir a todo el mundo

Cualquier startup IA que maneja los datos de entrenamiento se topa con el mismo 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
----

Resultado: o haces RAG con datos sucios (alucinaciones de PII, no cumplimiento del RGPD, riesgo jurídico), o no haces nada (sin producto). La tercera vía — limpiar a mano — no es escalable.

Mi respuesta : no sortear el problema. L'**automatizar**.

.

== MVP0 : El Anonimizador, Primer Contratado en Período de Prueba

El MVP0 no es una feature. 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.

Qué 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 primero los patrones más evidentes (emails`.*@.*`, tokens`sk-*`, `ghp_*`, IPs), luego aprende. El período de prueba, eso es: verificamos que no deje pasar falsos negativos antes de nombrarlo titular.

== Lo que este MVP desbloquea (y no es solo la Conformidad)

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**correcto por construcción**. Esto cambia todo para la calidad de las respuestas: el LLM no pasa su tiempo evitando PII que reconoce pero que no debe mencionar.

=== Futuro : Fine‑Tuning sobre datos limpios

[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 fine-tuning sobre datos brutos es una catástrofe jurídica potencial. Sobre datos limpios, es una**método reproducible**. Cada cliente acumula sus datasets limpios, cada cliente puede ajustar sus expertos de negocio sobre sus datos — sin nunca exponer un dato personal.

== ¿Por qué es comercializable?

No es « una herramienta de cumplimiento GDPR ». Es una**método reproducible que transforma un problema universal en activo**:

1. *Toda empresa de formación tiene datos sucios* — es el problema
2. *Ninguna tiene un pipeline automatizado de limpieza de fuentes múltiples* — eso 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». Vendrá 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 — de**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, objetos de valor. El LLM comprende el negocio porque lee su esquema.

== La hoja de ruta: de 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
----

Cada MVP depende del anterior. Ninguno puede ser entregado sin el MVP0. Esta 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.

== Conclusion: el Trabajo Invisible que Lo Hace Todo Posible

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 → no hay RAG legal (MVP1)
* Sin MVP0 → sin ajuste fino sin fuga de datos (EPIC 5)
* Sin MVP0 → no SaaS creíble (MVP3)
* Sin MVP0 → sin realidad aumentada en el prompt
* Sin MVP0 → no hay tercer camino de contexto (SQL DDD)

Él hace el trabajo sucio. Nunca será mencionado en los pitchs. Pero es él quien hace funcionar la fábrica.

Y es por eso que lo contratan 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 Alineación]
* Artículo sobre la gobernanza del agente Eager/Lazy :link:../2026/0108_gouvernance_agent_opencode_eager_lazy_post.html[Gobernar un agente IA con AsciiDoc]
* Artículo sobre el mecanismo Hot/Warm/Cold :link:../2026/0110_mecanisme_backup_contexte_agent_post.html[Ventana deslizante y ola fría]
* 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]
----

Articles connexes