우리 첫 채용자: 데이터셋 익명화 도구 — MVP0 시범 기간

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

결과: RAG를 오염된 데이터에 사용할 경우(개인정보 환각, GDPR 위반, 법적 리스크)가 발생하거나, 아무것도 하지 않을 경우(제품 없음)이 됩니다. 세 번째 방법 — 수동으로 정리하는 것 — 은 확장 가능하지 않다.

내 답변 : 문제를 피하지 마라. L'**자동화하다**.

== MVP0 : 익명화 도구, 시험 기간 중 첫 번째로 고용된

MVP0는 기능이 아닙니다. 그것은**편의 전문가**— 더러운, 멍청하고 사악한 일을 하는 직원, 그리고 누구도 피치 덱에서 말하고 싶어 하지 않는.

그가 하는 일:

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

먼저 가장 명백한 패턴을 감지합니다 (emails`.*@.*`, 토큰`sk-*`, `ghp_*`, IPs), 그 후 그것이 배운다. 수습 기간은 이것이죠 : 우리는 위음성이 통과되지 않는지 확인한 후 그것을 정직원으로 채용합니다.

== 이 MVP가 잠금 해제하는 것(그리고 이것이 단순히 규제 준수가 아니다)

익명화는 MVP0가 아니라 GDPR 고속도로 앞의 통행료가 아닙니다. 그것은 고속도로 자체입니다. 다음은 그것이 열어주는 것 :

=== 현재: 프롬프트의 증강 현실

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

RAG는 오염된 데이터에서 검색하지 않는다 — 그것은 공간에서 검색한다**구성으로 깨끗한**. 이것은 답변의 품질에 모든 것을 바꾼다 : LLM은 인식한 PII를 우회하려 시간을 낭비하지 않지만 언급해서는 안 된다.

=== 미래 : 건강한 데이터에 대한 파인 튜닝

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

원시 데이터에서의 파인튜닝은 잠재적인 법적 재앙입니다. 깨끗한 데이터에서는 그것은**재현 가능한 방법**. 각 클라이언트는 정제된 데이터셋을 축적하고, 자신의 데이터를 기반하여 비즈니스 전문가를 파인 튜닝할 수 있으며, 개인 데이터를 절대 노출하지 않습니다.

== 왜 이것이 시장성이 있나요?

이것은 GDPR 준수 도구가 아닙니다. 이것은**보편적인 문제를 자산으로 바꾸는 재현 가능한 방법**:

1. *모든 교육 기업은 더러운 데이터를 가지고 있습니다* — 이것이 문제입니다
2. *자동화된 다중 소스 정제 파이프라인이 있는 것은 하나도 없습니다* — 이것이 시장입니다
3. *루프: 익명화 → RAG → 파인튜닝은 독점적이다* — 이것이 장벽이다

Edster SaaS (MVP3)는 « Gradle 워크스페이스 »를 판매하지 않을 것입니다. 이 폐쇄 루프를 판매할 것입니다. 그리고 MVP0는 입구입니다.

== SQL 형식은 세 번째 컨텍스트 경로

구조화된 데이터 가져오기는 단순히 교환 형식이 아닙니다. SQL 스키마(DDL)는**도메인 엔티티-관계 모델**:

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

이 DDL은 익명 처리된 후(4줄) LLM의 컨텍스트 소스가 된다. 텍스트가 아니라 — du**비즈니스 모델**. RAG은 내용(벡터 유사도)을 제공하고, Graphify는 관계(정확한 구조)를 제공하며, SQL 스키마는 제공한다**암시적 도메인 주도 설계**: bounded contexts, aggregates, value objects. LLM은 자신의 스키마를 읽음으로써 업계를 이해한다.

== 로드맵: MVP0부터 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
----

각 MVP는 이전 MVP에 의존합니다. MVP0 없이는 어떤 MVP도 제공할 수 없습니다. 이것이 바로 백로그에서 'P0'가 아닌 이유가 익명화 도구가 아닌 이유이며 — 그것은**MVP0**. 이것은 첫 번째 상업적 산출물이며, 나머지는 그 성공에 달려 있다.

== Conclusion : 모든 것을 가능하게 하는 보이지 않는 일

일반적인 스타트업에서는 데이터 정리가 외주화되거나 수작업으로 이루어지거나 간과됩니다. 이 아키텍처에서는 이것이**제품의 핵심**. 익명화하는 사람은 첫 번째 직원이기 때문에, 그에 없이는 아무것도 작동하지 않는다 :

* MVP0 없이는 → 법적 RAG이 없습니다 (MVP1)
* MVP0 없이는 → 데이터 유출이 없으면 미세 조정도 없습니다 (EPIC 5)
* MVP0 없이는 → 신뢰할 수 있는 SaaS 없음 (MVP3)
* MVP0 없음 → 프롬프트에서 증강 현실 없음
* MVP0 없음 → 컨텍스트의 세 번째 경로 없음 (SQL DDD)

그는 더러운 일을 한다. 그는 피치에서 결코 언급되지 않을 것이다. 하지만 그가 공장을 움직인다.

그게 바로 우리가 그들을 먼저 고용하는 이유다.

== 참고문헌

* 공간적 온톨로지와 신뢰의 원에 관한 기사 :link:../2026/0114_gouvernance_cercles_confiance_ontologie_spatiale_alignement_llm_post.html[공간 온톨로지로서의 정렬 메커니즘]
* Eager/Lazy 에이전트 거버넌스에 관한 기사 :link:../2026/0108_gouvernance_agent_opencode_eager_lazy_post.html[AsciiDoc을 사용한 AI 에이전트 관리]
* Hot/Warm/Cold 메커니즘에 대한 기사 :link:../2026/0110_mecanisme_backup_contexte_agent_post.html[슬라이딩 윈도우와 한파]
* 세 개의 LLM 비교에 관한 기사:link:../2026/0112_comparaison_kimi_glm_deepseek_long_contexte_plugin_gradle_opencode_post.html[DeepSeek-V4-Pro, Kimi K2.6, GLM-5.1]
----