---
type: SOP — Standard Operating Procedure
asset_id: SOP-EL-HIORG-SanitizacionDemoVault-v01
version: v01
status: PROD
owner: Victor Heredia / EmpowerLabs
sherpa_owner: Jay (SherpaX maestro · ejecutor del protocolo)
fecha_creacion: 2026-05-18
intellbank: IB-EL-EmpowerLabs
subbank: PB-EL-Project-Bank / PB-WORX-Worx
proposito: |
  Protocolo operativo de sanitización de Demo Vault para clientes B2B, partners
  estratégicos y Sherpa Guides externos. Define 3 tiers de sanitización (T1 público ·
  T2 pseudonimización · T3 demo vault completo), checklist de auditoría, reglas de
  qué NO cruza nunca al cliente, y procedimiento paso a paso.
  Operacionaliza la Capa 3 (Operativa) del MePB-EL-HIORG-SecurityLayers-v01.
canonical_de: Capa 3 del MePB-EL-HIORG-SecurityLayers-v01 (sanitización operativa)
caso_origen: IB-AR-DemoVault (Alain Rios / Radsoft · primer Sherpa Guide externo · 2026-04-18)
ratificado_por: Victor Heredia (2026-05-07 EOD · D-Sec-03 implícita)
sistema_worx: K3 AGENCY (contrato cliente-EL) · K4 VAULT (sanitización del vault) · K5 GOVERNANCE (enforcement)
output_canonico: Demo Vault sanitizado por tier + Audit Report de sanitización
aplica_a: Toda entrega de activos del vault EL a entidades externas (clientes B2B · partners · Sherpa Guides externos · prospectos calificados)
documentos_hermanos:
  - MePB-EL-HIORG-SecurityLayers-v01 (las 6 capas · este SOP opera la Capa 3)
  - MePB-EL-CorpBrainOS-BehaviorCapture-v01 (§6 desensibilización PII)
  - PROT-EL-WORX-Cohort-OperatingProtocols-v01 (Skill Pack · vault-orphan-rescue)
skill_pack:
  - vault-orphan-rescue (validación de rutas + gate de salida)
  - bmf-file-renamer (renombrado de assets sanitizados con prefijo cliente)
  - bmf-registry-updater (registro de Demo Vaults producidos)
tags: [SOP, HIORG, Security, Sanitizacion, DemoVault, Capa3, T1, T2, T3, replicable-B2B]
---

# SOP — Sanitización de Demo Vault
## Protocolo operativo de 3 tiers para entrega segura a entidades externas

---

## I. PROPÓSITO

Antes de entregar cualquier activo del vault EL a una entidad externa (cliente B2B · partner estratégico · Sherpa Guide externo · prospecto calificado), aplicar el protocolo de sanitización en uno de los 3 tiers canonizados. Sin sanitización, el cliente recibe información de otros clientes · datos internos de EL · IP fundacional · o casos sensibles · violando SEC-03 + SEC-04 del MePB-EL-HIORG-SecurityLayers-v01.

> **Este SOP es la operacionalización de la Capa 3 (Operativa) de las 6 Capas de Seguridad.** No es opcional. Es la línea de defensa entre "vendemos valor real" y "filtramos IP por error operativo."

---

## II. LOS 3 TIERS DE SANITIZACIÓN · canonizados

### Tier 1 · DATOS PÚBLICOS (T1)

**Definición:** información ya publicada por EL externamente · en LinkedIn · website · papers públicos · charlas grabadas · contenidos del motor MasterPlaybooks.

**Sanitización requerida:** ninguna · ya pasó por revisión editorial previa a la publicación.

**Cuándo se aplica:**
- Prospecto calificado en pre-Ignition (`PAP-HIORGS-GranReto-v01` · landing pages · MPIs).
- Cliente B2B accede a Wiki cliente-facing (futuro).
- Sherpa Guide externo durante negociación (no operación).

**Activos T1 típicos:**
- `PAP-HIORGS-GranReto-v01` (paper cliente-facing).
- Landing pages comerciales.
- Casos públicos de éxito (con consent del cliente protagonista).
- Whitepapers publicados (`WP-BVH-SX-SherpaX-Whitepaper-v01` versión pública).
- Cascade content de MasterPlaybooks.

**Restricción:** NO se reclasifica T1 hacia abajo (T2/T3) · una vez público · es público.

---

### Tier 2 · PSEUDONIMIZACIÓN (T2)

**Definición:** templates · plantillas · ejemplos canónicos del vault EL · sanitizados antes de entregar a cliente B2B.

**Sanitización requerida:**
- Nombres propios de personas internas EL → reemplazados por placeholders (`[NOMBRE_PERSONA]`).
- Nombres propios de otros clientes → reemplazados (`[CLIENTE_X]`).
- IDs internos (D-P-XX · CAS-XXX · número de sesión) → reemplazados o removidos.
- Empresa EL → reemplazada por `[ORGANIZACIÓN]` o nombre del cliente target si el contexto lo permite.
- Pricing específico de otros deals → removido.
- Datos confidenciales · estrategia comercial · pipeline interno → removido completo.
- Referencias internas a otros documentos del vault que NO se entregan al cliente → reemplazadas por descripción genérica.

**Sanitización NO requerida:**
- Estructura del template (frontmatter · secciones · formato).
- Conceptos canónicos del método (XDoc · WORX · 5 capacidades · 4 ritmos).
- Reglas operativas (P001-P006 + P010-P012 son universales · sí se entregan).
- Naming Convention BMF (parte del valor entregado).
- 3 SOPs forzosos (RoomActivation · BrainOSFirst · DocBySherpa son universales).

**Cuándo se aplica:**
- Cliente B2B recibe templates canónicos adaptados a su organización.
- Cliente B2B recibe ejemplo de Workbook (PreIgnition · Etapa 1) sanitizado.
- Cliente B2B recibe SOPs forzosos como referencia.
- Cliente B2B recibe MePBs operativos adaptados a su dominio.

**Activos T2 típicos (post-sanitización):**
- `PLB-[CLIENTE]-Caso0-PreIgnitionWorkbook-v01` (versión cliente del template EL).
- `MePB-[CLIENTE]-OrganizationalKernel-v01` (su versión organizacional).
- Skill Pack instalado · skills como módulos funcionales (sin código fuente).
- 3 SOPs forzosos (aplicación directa · sin modificación).

---

### Tier 3 · DEMO VAULT COMPLETO (T3)

**Definición:** clone sanitizado completo del vault EL para uso de Sherpa Guides externos o partners estratégicos de alto nivel · que necesitan operar con un vault "vivo" como referencia (no solo templates).

**Sanitización requerida:**
- TODO lo de T2 +
- Todos los CAS- del LabPraxis con datos internos → reemplazados o removidos.
- Casos de otros clientes → removidos completamente.
- Pricing histórico · D-P financieros · `TP-HIORGS-ModeloNegocio-Pricing-v01` → removido o sanitizado.
- Brain Codes (BC-) de Victor · Jay · y otras figuras internas → removidos.
- Brain Codes de figuras externas curadas internamente (Jensen Huang · Hormozi · etc.) → removidos (son Crown Jewel ampliado).
- Memoria operativa de Victor · sus notas personales · sus rituales → removidos.
- LabPraxis completo · solo se incluyen casos que ilustran metodología (no incidentes operativos internos).
- Wiki LLM · solo páginas que enseñan método · no páginas internas de gobernanza.
- IntelliBanks app references → reemplazadas con placeholders.

**Sanitización NO requerida:**
- Estructura del vault (IB-* · PB-* · CP-* organización).
- Documentos canónicos arquitectónicos públicos (después de T2 sobre ellos).
- Naming Convention completa.

**Cuándo se aplica:**
- Sherpa Guide externo nuevo (caso Alain Rios · futuros).
- Partner estratégico que opera bajo nombre EL (raro · solo casos validados por Victor).
- Curso de certificación de implementadores externos (cuando exista programa formal).

**Restricción crítica:**
- T3 SIEMPRE requiere ratificación explícita de Victor caso por caso (D-Sec-05 implícita).
- T3 NUNCA se entrega a cliente B2B directo · solo a partners certificados bajo contrato exclusivo.
- T3 lleva NDA reforzado con cláusula de no-replicación + auditoría anual.

**Activos T3 típicos:**
- `IB-AR-DemoVault/` (caso Alain Rios · primer T3 producido · 2026-04-18).
- Futuros demo vaults de Sherpa Guides certificados.

---

## III. PROCEDIMIENTO PASO A PASO

### Paso 1 · Identificar el Tier aplicable

**Pregunta clave:** ¿quién recibe los activos · para qué los usa · qué nivel de exposición tiene el ecosistema EL?

| Entidad receptora | Uso | Tier aplicable |
|---|---|---|
| Prospecto pre-Ignition | Conocer la propuesta · evaluar comprar | T1 |
| Cliente B2B en cohort de instalación | Operar el WORX OS en su organización | T2 |
| Sherpa Guide externo certificado | Operar con vault vivo como facilitador externo | T3 |
| Implementador HIORG futuro en certificación | Aprender el método para replicarlo | T2 mayormente · T3 supervisado |
| Auditoría legal · abogado IP externo | Validar contratos · proteger IP | T1 + activos legales específicos |
| Conferencias / charlas / cascade content | Difusión pública | T1 |

**Si hay ambigüedad sobre el tier · escalar a Victor antes de proceder.**

### Paso 2 · Inventario de activos a sanitizar

Listar uno por uno los activos a entregar:
- Path canónico EL.
- Tipo de activo (PLB- · MePB- · SOP- · WP- · etc.).
- Tier aplicable.
- Datos sensibles detectados (PII · cliente · interno · IP).

### Paso 3 · Aplicar sanitización por tier

#### Para T1 (datos públicos)
- No requiere sanitización adicional.
- Validar que el activo está efectivamente publicado (link público o referencia editorial).
- Entregar tal cual.

#### Para T2 (pseudonimización)
1. Copiar el activo original a una ubicación de trabajo (NO sanitizar el original).
2. Aplicar pseudonimización siguiendo §II Tier 2:
   - Search & replace de nombres propios internos.
   - Remover referencias a otros clientes.
   - Remover IDs internos (D-P-XX · CAS-XXX · números de sesión).
   - Adaptar contexto al cliente target si es template.
3. Renombrar el activo con prefijo cliente: `[TIPO]-[CLIENTE]-[Slug]-v01.md`.
4. Validar manualmente que NO queda nada sensible (Paso 4 checklist).
5. Mover a ubicación de entrega.

#### Para T3 (demo vault completo)
1. Clone completo del vault EL a ubicación nueva.
2. Aplicar TODO lo de T2 sobre cada activo del clone.
3. Adicionalmente remover:
   - LabPraxis con casos internos.
   - Brain Codes (BC-) internos y de figuras externas curadas.
   - Memoria personal de Victor.
   - Pricing histórico.
   - Wiki páginas internas de gobernanza.
4. Renombrar IntelliBank: `IB-[CLIENTE-CODE]-DemoVault/`.
5. Crear `README.md` del demo vault explicando qué es · qué incluye · qué no incluye · términos de uso.
6. Validar exhaustivamente con Paso 4 checklist + ratificación Victor.
7. Empaquetar (zip o repo Git separado).

### Paso 4 · Checklist de auditoría obligatorio antes de entregar

| # | Criterio | T1 | T2 | T3 |
|---|---|---|---|---|
| 1 | Nombres propios internos EL removidos/reemplazados | N/A | ✅ | ✅ |
| 2 | Nombres de otros clientes removidos | N/A | ✅ | ✅ |
| 3 | IDs internos (D-P · CAS-) removidos o reemplazados | N/A | ✅ | ✅ |
| 4 | PII de empleados/contratistas removida | N/A | ✅ | ✅ |
| 5 | Pricing de otros deals removido | N/A | ✅ | ✅ |
| 6 | Estrategia comercial interna removida | N/A | ✅ | ✅ |
| 7 | Referencias a Crown Jewel (L0+L0.5+L1) removidas/condensadas | N/A | ✅ | ✅ |
| 8 | LabPraxis casos internos removidos | N/A | parcial | ✅ |
| 9 | Brain Codes internos + externos curados removidos | N/A | ✅ | ✅ |
| 10 | Memoria personal de Victor removida | N/A | N/A | ✅ |
| 11 | Wiki páginas internas removidas | N/A | parcial | ✅ |
| 12 | NDA firmado por receptor | N/A | ✅ | ✅ (reforzado) |
| 13 | Contrato de licencia firmado | N/A | ✅ | ✅ |
| 14 | Ratificación Victor (caso por caso) | N/A | opcional | ✅ obligatoria |

**Regla de oro:** un FAIL en cualquier criterio aplicable bloquea la entrega. Sin excepciones · sin "es solo para Alain · él es de confianza."

### Paso 5 · Producir Audit Report

Cada sanitización (T2 + T3) produce un Audit Report canónico:

```markdown
## Audit Report · Sanitización [TIER]
- **Fecha:** AAAA-MM-DD
- **Sanitizador:** [Nombre · Sherpa Owner típicamente Jay]
- **Receptor:** [Entidad externa]
- **Tier aplicado:** [T1/T2/T3]
- **Activos sanitizados:** [lista con paths originales + paths sanitizados]
- **Checklist § IV ejecutado:** [✅ todos PASS · ❌ N FAIL detectados y corregidos]
- **Ratificación Victor (si T3):** [fecha · método]
- **NDA receptor:** [vigente · fecha de firma · referencia contrato]
- **Notas operativas:** [excepciones · decisiones tomadas · ambigüedades resueltas]
```

Vivirá en: `IB-EL-EmpowerLabs/PB-EL-Project-Bank/PB-WORX-Worx/AUD-EL-Sanitizacion-[ENTIDAD]-[FECHA]-v01.md`.

### Paso 6 · Entrega + tracking en Registry

- Activos sanitizados se entregan al receptor por canal acordado (email · GitHub repo · Google Drive con permisos restringidos · etc.).
- Registry maestro actualizado con entrada del Demo Vault producido (si T3) vía skill `bmf-registry-updater`.
- Audit Report archivado en banco WORX.

---

## IV. REGLAS INVIOLABLES

| # | Regla | Capa MePB-Security |
|---|---|---|
| **SAN-01** | NUNCA entregar el archivo original sin sanitización · siempre trabajar sobre copia | Operativa |
| **SAN-02** | T1 no se reclasifica · una vez público · es público | Operativa |
| **SAN-03** | T3 requiere SIEMPRE ratificación explícita Victor caso por caso | Operativa + Legal |
| **SAN-04** | NDA firmado por receptor ANTES de entregar cualquier activo T2 o T3 | Legal |
| **SAN-05** | Checklist § IV ejecutado completo · un FAIL bloquea entrega · sin excepciones | Operativa |
| **SAN-06** | Audit Report producido por cada sanitización T2/T3 · archivado · auditable | Governance |
| **SAN-07** | Datos de otros clientes NUNCA cruzan a Demo Vault · cero excepciones | Operativa |

---

## V. CASOS DE USO ILUSTRATIVOS

### Caso A · Prospecto B2B descarga paper

**Situación:** prospecto interesado en WORX OS visita landing · descarga `PAP-HIORGS-GranReto-v01`.

**Flujo:**
1. Paso 1 · Tier T1 (datos públicos · paper ya publicado).
2. Paso 2 · Activo único · ya sanitizado en su versión publicada.
3. Paso 3 · Entrega directa vía descarga del landing.
4. Paso 5 · NO requiere Audit Report (T1).
5. Lead capture en CRM · sin más.

### Caso B · Cliente B2B firma deal · recibe templates

**Situación:** Cliente XYZ firma contrato bundle MONEX α · necesita PreIgnitionWorkbook adaptado a su organización.

**Flujo:**
1. Paso 1 · Tier T2 (pseudonimización).
2. Paso 2 · Inventario: `PLB-EL-Caso0-PreIgnitionWorkbook-v01` original.
3. Paso 3 · Copiar · search & replace de nombres EL/internos · adaptar contexto a XYZ · renombrar a `PLB-XYZ-Caso0-PreIgnitionWorkbook-v01`.
4. Paso 4 · Checklist § IV (1-9 + 12-13 aplican).
5. Paso 5 · Audit Report producido por Jay.
6. Paso 6 · Entrega al Sherpa Guide asignado al cliente XYZ.

### Caso C · Alain Rios como Sherpa Guide externo (T3 real · 2026-04-18)

**Situación:** Alain Rios certificado como Sherpa Guide externo · necesita vault operativo para facilitar a primer cliente.

**Flujo (ejecutado el 2026-04-18):**
1. Paso 1 · Tier T3 (demo vault completo).
2. Paso 2 · Clone completo del vault EL.
3. Paso 3 · Sanitización exhaustiva (todo lo de T2 + remoción LabPraxis interno · BC- · memoria Victor · Wiki interno).
4. Paso 4 · Checklist § IV completo (todos los 14 criterios).
5. Paso 5 · Audit Report producido.
6. Paso 6 · Entrega vía repo Git separado · NDA reforzado firmado · ratificación Victor.
7. Resultado: `IB-AR-DemoVault/` · primer T3 del ecosistema · referenciado como patrón canónico.

**Tiempo total:** ~20 min de trabajo activo + 2h de sesión completa con Alain (ver `CAS-EL-WORX-013` LabPraxis).
**Multiplicador WORX documentado:** ~360× (`SP-EL-WORX-ROITracker-v01` fila 6).

### Caso D · Implementador HIORG futuro en certificación

**Situación:** Jesús/Gustavo se certifican como implementadores HIORG · necesitan acceso a vault operativo durante certificación.

**Flujo:**
1. Paso 1 · T2 mayormente (siguen siendo internos EL) · T3 supervisado para vault de práctica.
2. Reciben acceso a templates T2 sanitizados de clientes anteriores (sin datos sensibles).
3. NO reciben Crown Jewel BMF (L0+L0.5+L1).
4. Acceso completo al método operativo (Type D L2 · SOPs · Skill Pack).
5. Auditoría trimestral del uso conforme.

---

## VI. ANTI-PATRONES

### VI.1 · "Es solo para [X] · es de confianza"

**Síntoma:** facilitador EL salta SAN-05 porque receptor es persona conocida.
**Consecuencia:** establece precedente · cliente posterior espera mismo trato · burbujas estancas se rompen.
**Antídoto:** SAN-05 inviolable · checklist se ejecuta SIEMPRE · sin importar relación personal.

### VI.2 · Sanitización superficial sin checklist

**Síntoma:** "ya quité los nombres" · pero quedan IDs internos · referencias cruzadas · pricing.
**Consecuencia:** receptor descubre información sensible · pérdida de confianza · potencial demanda.
**Antídoto:** Paso 4 checklist completo · NO se entrega sin todos los criterios PASS.

### VI.3 · Producir T3 sin ratificación Victor

**Síntoma:** Sherpa Owner produce T3 "porque ya lo hicimos antes con Alain."
**Consecuencia:** T3 entregado sin validación estratégica · receptor puede no ameritar T3.
**Antídoto:** SAN-03 inviolable · CADA T3 requiere ratificación Victor · sin precedentes asumidos.

### VI.4 · Reutilizar Demo Vault de cliente anterior

**Síntoma:** producir Demo Vault de cliente nuevo basado en clone del Demo Vault de cliente anterior.
**Consecuencia:** datos del cliente anterior cruzan al nuevo · violación SAN-07 + SEC-03.
**Antídoto:** cada Demo Vault se construye desde el vault EL canónico · NUNCA desde otro Demo Vault.

### VI.5 · Entregar antes de NDA firmado

**Síntoma:** receptor pide acceso "para evaluar" · facilitador entrega T2/T3 sin NDA.
**Consecuencia:** receptor accede a IP sin obligación contractual · si replica · enforcement es difícil.
**Antídoto:** SAN-04 inviolable · NDA firmado SIEMPRE antes de entrega T2/T3.

---

## VII. CONEXIONES CANÓNICAS

| Documento | Relación |
|---|---|
| `MePB-EL-HIORG-SecurityLayers-v01` | Este SOP operacionaliza Capa 3 (Operativa) |
| `MePB-EL-CorpBrainOS-BehaviorCapture-v01` | §6 desensibilización PII · base técnica |
| `IB-AR-DemoVault/` | Caso real T3 · referencia operativa |
| `CAS-EL-WORX-013` (LabPraxis · `MIN-VH-Retiro-16al19Abril2026-v01` Frente 3) | Documentación del primer T3 producido |
| `SP-EL-WORX-ROITracker-v01` fila 6 | Multiplicador WORX del proceso (~360×) |
| `PROT-EL-WORX-Cohort-OperatingProtocols-v01` | Skill Pack mandatorio · `vault-orphan-rescue` valida rutas de entrega |
| `MePB-EL-HIORG-ClientLicensing-v01` | Futuro · operacionaliza Capa 4 económica · contratos de uso post-sanitización |

---

## VIII. CHANGELOG

- **2026-05-18 · v01** — Primer release PROD. SOP operativo de sanitización con 3 tiers canonizados (T1 público · T2 pseudonimización · T3 demo vault completo). 6 pasos del procedimiento + checklist 14 criterios + 7 reglas inviolables (SAN-01 al SAN-07) + 4 casos de uso ilustrativos (incluyendo caso real Alain Rios) + 5 anti-patrones. Operacionaliza Capa 3 del `MePB-EL-HIORG-SecurityLayers-v01`.
- **Corrección de fecha (registrada 2026-05-18)** — `fecha_creacion` corregida de "2026-05-07 EOD" a "2026-05-18". Causa: frontmatter heredado de template sin validación temporal. Documentado en CASO 018 del LabPraxis. Antídoto: P014 Frontmatter Integrity (a canonizar).

---

*SOP-EL-HIORG-SanitizacionDemoVault-v01 · IB-EL-EmpowerLabs/PB-EL-Project-Bank/PB-WORX-Worx/ · 2026-05-18*
*Owner: Victor Heredia · Sherpa Owner: Jay (SherpaX maestro)*
*"Sanitización es la línea entre vender valor real y filtrar IP por error operativo."*