tempo de leitura : 12 minutes

Não contrato um LLM. Contrato um anonimizador. Antes de fazer RAG pgvector, antes de fazer fine-tuning de especialistas CDA/FPA, antes de provisionar workspaces de clientes — alguém deve limpar os banheiros dos dados. Este funcionário é o especialista em anonimização (MVP0, EPIC 2 de codebase-gradle). E é ele quem torna o produto comercializável.

toc

[]

O Problema que Faz Fugir Todo o Mundo

Toda startup de IA que manipule dados de treinamento bate no mesmo 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: ou você faz RAG em dados sujos (alucinações de PII, não conformidade com GDPR, risco jurídico), ou você não faz nada (sem produto). A terceira via — limpar manualmente — não é escalável.

Minha resposta: não contornar o problema. L'**automatizar**.

== MVP0: O Anonimizador, Primeiro Contratado no Período de Experiência

O MVP0 não é uma funcionalidade. É um**especialista em conveniência**— um funcionário que faz o trabalho sujo, estúpido e malvado, e que ninguém quer falar nos pitch decks.

O que ele faz:

[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
----

Ele detecta os padrões mais óbvios primeiro (e-mails`.*@.*`, tokens`sk-*`, `ghp_*`, IPs), então ele aprende. O período de teste, isso é: validamos que ele não deixa passar falsos negativos antes de efetivá-lo.

== O que esse MVP desbloqueia (e não é apenas a conformidade)

A anonimização como MVP0 não é o pedágio RGPD antes da autoestrada. É a própria autoestrada. Veja o que ela abre:

=== Presente: Realidade Aumentada em 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
----

O RAG não procura em dados sujos — ele procura em um espaço**limpo por construção**Isso muda tudo para a qualidade das respostas: o LLM não perde tempo a contornar PII que ele reconhece, mas que não deve mencionar.

=== Futuro : Fine-Tuning em Dados Saudáveis

[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)
----

O fine-tuning em dados brutos é uma catástrofe jurídica em potencial. Em dados limpos, é uma**método reprodutível**. Cada cliente acumula os seus conjuntos de dados limpos, cada cliente pode afinar os seus especialistas de negócio nos seus dados — sem nunca expor um dado pessoal.

== Por que é vendável

Não é « uma ferramenta de conformidade GDPR ». É uma**Método reprodutível que transforma um problema universal em ativo**:

1. *Toda empresa de formação tem dados sujos* — isso é o problema
2. *Nenhuma tem um pipeline automatizado de limpeza multi-fonte*—é o mercado
3. *O ciclo: anonimização → RAG → fine-tuning é proprietário* — é a barreira

O SaaS Edster (MVP3) não venderá « um workspace Gradle ». Ele venderá esse loop fechado. E o MVP0 é a porta de entrada.

== O Formato SQL como Terceira Via de Contexto

A importação de dados estruturados não é apenas um formato de troca. O esquema SQL (DDL) leva o**modelo de entidade-relacionamento do domínio**:

[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, uma vez anonimizado (linha 4), torna-se uma fonte de contexto para o LLM. Não é texto — do**modelo de negócio**. O RAG fornece o conteúdo (similaridade vetorial), Graphify fornece as relações (estrutura exata), e o esquema SQL fornece o**Design orientado por domínio implícito**: contextos delimitados, agregados, objetos de valor. O LLM compreende o negócio porque ele lê seu esquema.

== A Roadmap: do MVP0 ao 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 do anterior. Nenhum pode ser entregue sem o MVP0. Esta é a razão pela qual o Anonimizador não é « P0 » no backlog — ele é**MVP0**. É o primeiro entregável comercial, e tudo o resto está condicionado ao seu sucesso.

== Conclusão: o Trabalho Invisível que Torna Tudo Possível

Em uma startup clássica, a limpeza de dados é terceirizada, manual ou ignorada. Nesta arquitetura, é o**coração do produto**. O Anonimizador é o primeiro empregado porque, sem ele, nada funciona:

* Sem MVP0 → não há RAG legal (MVP1)
* Sem MVP0 → sem fine-tuning sem vazamento de dados (EPIC 5)
* Sem MVP0 → não há SaaS credível (MVP3)
* Sem MVP0 → não há realidade aumentada no prompt
* Sem MVP0 → não há terceira via de contexto (SQL DDD)

Ele faz o trabalho sujo. Nunca será citado nos pitches. Mas é ele quem faz a fábrica funcionar.

E é por isso que ele/ela é contratado primeiro.

== Referências

* Artigo sobre a ontologia espacial e os círculos de confiança :link:../2026/0114_gouvernance_cercles_confiance_ontologie_spatiale_alignement_llm_post.html[A Ontologia Espacial como Mecanismo de Alinhamento]
* Artigo sobre o agente de governança Eager/Lazy:link:../2026/0108_gouvernance_agent_opencode_eager_lazy_post.html[Governar um agente de IA com AsciiDoc]
* Artigo sobre o mecanismo Hot/Warm/Cold:link:../2026/0110_mecanisme_backup_contexte_agent_post.html[Janela deslizante e onda fria]
* Artigo sobre a comparação dos três 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