/compliance-cl

name: compliance-cl
description: >-
  Esta skill se usa cuando el usuario pide "armar el compliance", "cumplir la Ley 21.719",
  "preparar la protección de datos", "auditar datos personales", "generar política de privacidad /
  DPA / RAT / EIPD / consentimiento", "cumplir la ley de datos en Chile" o "modelo de prevención de
  delitos (Ley 21.595)". Audita un repo y genera, SIN abogado, toda la documentación de cumplimiento
  para un SaaS o empresa en Chile, contrastada contra el texto oficial de la ley. Cubre la Ley 21.719
  (datos personales, vigencia dic-2026) y la 21.595 (delitos económicos, ya vigente), y es extensible
  a más marcos (packs).
license: MIT
allowed-tools:
  - Read
  - Write
  - Edit
  - Grep
  - Glob
  - Bash
  - AskUserQuestion

compliance-cl — Motor de cumplimiento (Chile), multi-marco y self-service

Auditar una aplicación contra uno o varios **packs** de ley, **resolver las decisiones** con el criterio de la ley y **generar toda la documentación rellenada** (sin dejar tarea), dejando un **estado versionado** en el repo que se re-corre en el tiempo. Objetivo: que un founder cumpla **solo**; el abogado es opcional (ver `references/cuando-acudir-a-abogado.md`).

> **DISCLAIMER OBLIGATORIO** — No constituye asesoría legal (un software no asume la responsabilidad legal > del usuario). Genera borradores fundados en la normativa chilena para cumplir sin abogado. Incluir este > disclaimer al pie de cada documento legal generado.

Modelo mental

• **Controles** = unidades reutilizables que satisfacen varios marcos a la vez. Catálogo + crosswalk:

`references/controls.md`.

• **Packs** = una ley cada uno (`packs/<id>/pack.md`): obligaciones, controles que exige y documentos a

generar. Hoy: `ley-21719`, `ley-21595`.

• **Estado** = el output vive en `<repo>/.compliance/` versionado por git. Formato: `references/output-model.md`.
• **Fuentes (verdad)** = textos OFICIALES en `sources/` (`FUENTES.md`). Toda afirmación legal cita

**ley + artículo + archivo**; lo no verificable se marca `[verificar contra fuente oficial]`. NADA inventado. Numeración verificada: `references/mapa-articulos-21719.md`.

Flujo

Fase 0 — Encuadre (CUESTIONARIO: recoger todo para no dejar `[COMPLETAR]`)

Mostrar el disclaimer. Luego preguntar al usuario (con `AskUserQuestion` cuando aplique) y **registrar las respuestas para rellenar los documentos**. No dejar placeholders salvo que el dato sea genuinamente desconocido; en ese caso, proponer un **default sensato** y marcarlo. Recoger: 1. Repo a auditar y **packs** a activar (default: `ley-21595` + `ley-21719`). 2. **Empresa:** razón social, RUT, domicilio, correo de contacto, tamaño, representante legal. 3. **Responsable de datos / encargado de prevención** designado (en micro suele ser el dueño). 4. Por flujo de datos: rol **responsable** vs **encargado**. 5. **Plazos de retención** por tipo de dato; si no los sabe, proponer defaults razonables. 6. ¿Tratan **datos sensibles** (salud, etc.)? ¿Usuarios en la **UE** (gatilla GDPR a futuro)? Si ya existe `<repo>/.compliance/state.json`, leerlo: esta corrida es una re-evaluación.

Fase 1 — Descubrimiento (leer el código, no asumir)

Recorrer el repo con Grep/Glob para levantar evidencia de cada control:

• Datos personales (esquemas/migraciones/modelos/formularios): `email|phone|telefono|rut|address|nombre|name|ip|lat|lng|password`; marcar **datos sensibles** específicos (salud, biométricos, menores).
• Proveedores externos y transferencias internacionales (`.env*`, `package.json`, configs): AWS, Google, Meta, etc.; marcar los que procesan fuera de Chile.
• Medidas técnicas: TLS, cifrado en reposo, hashing de password, MFA, logs/auditoría, segregación por tenant, secretos fuera del código, seudonimización, privacy-by-default.
• Gobernanza (no está en el código): tomarla del cuestionario; marcar `❓` lo no verificable por código.

Fase 2 — Evaluar controles y RESOLVER decisiones

Para cada control de `references/controls.md`: estado (✅/⚠️/❌/❓) + evidencia + remediación. Un control se propaga a todos los marcos que lo exigen. **Resolver las decisiones** (no dejarlas abiertas), citando el artículo:

• **DPO** (Art. 50): obligatorio solo para organismos públicos o datos sensibles a gran escala; si no,

basta el responsable designado → dar el resultado.

• **EIPD** (Art. 15 ter): aplicar el test de `packs/ley-21719/templates/eipd.md`; si aplica un supuesto, es obligatoria.
• **Base de licitud** por flujo y **mecanismo de transferencia** (cláusulas modelo).

Fase 3 — Generar TODA la documentación (rellenada)

Por cada pack activo, leer su `pack.md` y generar **todos** sus `templates/`, **rellenados con las respuestas de Fase 0 y los hallazgos de Fase 1**. Para `ley-21719`: rat, política, consentimiento, canal-derechos, dpa, anexo-transferencias, plan-respuesta-brechas, registro-vulneraciones, y eipd (si el test la hace obligatoria). Para `ley-21595`: modelo-prevencion-delitos, código-etica, matriz-riesgos, acta-encargado-prevencion, reglamento-canal-denuncias. Reemplazar todos los placeholders; usar `[COMPLETAR: ...]` solo para lo realmente desconocido.

Fase 4 — Escribir el estado versionado

Escribir en `<repo>/.compliance/` según `references/output-model.md`: `state.json` (controles + score por marco), `docs/` (todo lo generado), `INSTRUCTIVO.md` (runbooks desde `references/instructivo-situaciones.md`) y `RESUMEN.md` (postura, brechas priorizadas, **diff vs la corrida anterior**, y qué quedó resuelto solo + el único insumo externo: supervisión anual del MPD). Sugerir commitear `.compliance/`.

Fase 5 — Cierre y construcción

Reportar la postura por marco. Para cada hueco con remediación de código, **ofrecer construirlo** (esta skill corre en Claude Code) siguiendo las **recetas de `references/build/`** (MFA, cifrado en reposo, audit log + actor/IP, endpoints ARCO, consentimiento, retención): en una rama, con tests y los gates del repo. Ofrecer también **montar el monitoreo** (