Generación de políticas de privacidad — Ley 21.719 (Chile)

Generación de políticas de privacidad — Ley 21.719 (Chile)

Los otros cinco skills de este plugin trabajan hacia adentro: código, arquitectura, hallazgos, incidentes, un porcentaje. Este trabaja hacia afuera — produce el texto que un titular real va a leer antes de aceptar, o que un fiscalizador va a comparar contra lo que el sistema hace de verdad.

Por eso la regla que domina sobre todas las demás de este plugin se vuelve todavía más estricta aquí:

Cada afirmación del documento tiene que salir de evidencia verificable, o no se escribe. Una política de privacidad que dice "no compartimos tus datos con terceros" cuando el registro de proveedores muestra seis integraciones no es un error de redacción — es una declaración falsa de cara al público, y este skill existe justamente para que eso no pase.

Lo que este skill nunca hace

1. No inventa. Ni proveedores, ni finalidades, ni plazos de retención, ni mecanismos de transferencia que no estén registrados en la evidencia de F0. Si algo no está registrado, el documento lo deja como REVISIÓN LEGAL REQUERIDA o como un vacío explícito ("no se identificó evidencia de X — completar antes de publicar"), nunca como una frase plausible sin respaldo.
2. No publica nada. Todo lo que produce es un borrador para revisión legal. Cada documento generado abre con el aviso de la sección final de este archivo. Este skill redacta; no decide que el texto está listo para ir al sitio.
3. No emite conclusiones jurídicas dentro del texto que redacta más allá de lo que la evidencia sostiene — igual que el resto del plugin, marca REVISIÓN LEGAL REQUERIDA en vez de afirmar un plazo, una excepción o un corte etario que no esté confirmado en marco-legal.md o bases-y-consentimiento.md.

Relación con los otros cinco skills

Este skill es consumidor de evidencia, no productor — en eso se parece a preparacion-ley-21719, pero en vez de un puntaje produce texto legal:

chile-datos-personales / auditoria-ley-21719
        │  producen docs/privacidad/inventario.md y el RAT/ROPA
        ▼
implementar-ley-21719
        │  produce privacy_processing_activities, privacy_processors,
        │  privacy_ai_usage, privacy_retention_rules, privacy_consents
        ▼
generar-politicas-privacidad (este skill)
        │  redacta el texto público a partir de esa evidencia
        ▼
docs/privacidad/legal/   ← entregable, en el proyecto auditado, nunca aquí

Si ninguna de esas fuentes existe todavía, no redactes desde cero: dilo explícitamente y ofrece dos caminos — ejecutar primero el skill que falta, o redactar solo lo que la evidencia disponible permite, dejando el resto como brecha declarada. Un documento completo construido sobre huecos rellenados a criterio no es un borrador útil, es un riesgo con formato de política.

F0 — Reunir evidencia

En orden de preferencia:

1. docs/privacidad/inventario.md          → qué datos, clasificación
2. docs/privacidad/rat.md (o equivalente)  → tratamientos, finalidad, base legal
3. privacy_processors / proveedores-registro.md → terceros, transferencias
4. privacy_ai_usage / registro-ia.md        → uso de IA, decisión automatizada
5. privacy_retention_rules / retencion-ejecutable.md → plazos de retención
6. privacy_consents / consentimiento.md      → finalidades que ya piden
                                                consentimiento, versión vigente
7. Modelo de representación legal (NNA), si existe → bases-y-consentimiento.md
8. Uso de almacenamiento de archivos/fotos → almacenamiento-archivos.md

Por cada fuente, registra si existe, está completa, o falta — esto alimenta directamente qué documentos de F1 se pueden redactar con evidencia sólida y cuáles quedan con brechas declaradas.

F1 — Decidir qué documentos aplican

No generes los doce documentos por inercia. Cada uno tiene una condición de activación — actívalo solo si la evidencia de F0 lo justifica:

política de privacidad         siempre, si hay al menos un tratamiento en el RAT
aviso de registro               si existe un flujo de registro/alta de cuenta
cookies/tracking                 solo si registro-ia.md o analytics-tracking.md
                                  muestran herramientas activas
consentimiento de finalidad       por cada finalidad que use consentimiento
                                   como base legal (privacy_legal_basis)
datos sensibles                   solo si el inventario marca alguna categoría
                                   SENSIBLE tratada
NNA                                solo si el RAT o el inventario indican
                                    titulares que pueden ser menores de edad
proveedores y transferencias        si hay al menos un proveedor o una
                                     transferencia internacional registrada
aviso de formulario                 por cada formulario que capture datos
                                     PERSONAL o superior identificado en F0
aviso de fotografías/documentos      solo si almacenamiento-archivos.md
                                      muestra captura de imágenes/documentos
aviso de IA                          solo si registro-ia.md tiene al menos
                                      un uso activo

Presenta la lista de documentos a generar, con la condición que la activó, antes de redactar — permite que el usuario corrija si algo se activó por error de interpretación de la evidencia.

F2 — Redactar desde las plantillas

Cada plantilla vive en ${CLAUDE_PLUGIN_ROOT}/shared/templates/legal/ con extensión .template.md. Contienen placeholders entre [[ ]] (doble corchete, no < >) con una nota de qué fuente de F0 debe llenarlos — no los completes con contenido plausible si la fuente indicada no tiene el dato: dejar [[REVISIÓN LEGAL REQUERIDA: plazo de retención no registrado para esta categoría]] es el resultado correcto, no un fallo del skill.

El doble corchete es la convención deliberada de este skill, distinta del < > que el resto del plugin usa para ejemplos de formato: un placeholder sin rellenar tiene que poder detectarse con un solo grep sin falsos positivos contra HTML, JSX o un blockquote de markdown — ver F2.5.

shared/templates/legal/
    politica-privacidad.template.md
    aviso-privacidad.template.md
    cookies.template.md
    tratamiento-datos-sensibles.template.md
    tratamiento-nna.template.md
    proveedores-y-transferencias.template.md
    consentimiento-registro.template.md
    consentimiento-datos-sensibles.template.md
    consentimiento-nna.template.md
    aviso-formulario.template.md
    aviso-fotografias.template.md
    aviso-ia.template.md

Ver references/trazabilidad-y-versionado.md para el criterio exacto de cómo citar la fuente de cada afirmación y cómo versionar.

F2.5 — Verificar que no quedaron placeholders sin completar

Antes de entregar cualquier documento, corre esto sobre el archivo generado (no sobre la plantilla):

grep -n '\[\[' docs/privacidad/legal/<documento>.md

Cualquier coincidencia es un placeholder que quedó sin rellenar — o bien lo completas con el dato real de la evidencia de F0, o lo dejas como [[REVISIÓN LEGAL REQUERIDA: ...]] a propósito. Lo que no puede pasar es entregar un documento con [[nombre de la organización]] literal porque se te olvidó completarlo — eso no es un hueco declarado, es un descuido, y el disclaimer de borrador no lo cubre: el disclaimer avisa que falta revisión legal, no que el documento esté a medio rellenar.

Si el grep no devuelve nada, el documento está completo en el sentido de "todo lo que podía llenarse desde evidencia, se llenó" — puede seguir teniendo secciones REVISIÓN LEGAL REQUERIDA dentro de los corchetes, y eso está bien: son huecos declarados, no placeholders olvidados.

F3 — Entregar

docs/privacidad/legal/
    politica-privacidad.md
    aviso-privacidad.md
    cookies.md                        (si aplica)
    tratamiento-datos-sensibles.md    (si aplica)
    tratamiento-nna.md                (si aplica)
    proveedores-y-transferencias.md   (si aplica)
    registro-versiones.md             ← ver F4
    frontend/
        consentimiento-registro.md
        consentimiento-datos-sensibles.md  (si aplica)
        consentimiento-nna.md              (si aplica)
        aviso-formulario-<nombre>.md       (uno por formulario relevante)
        aviso-fotografias.md               (si aplica)
        aviso-ia.md                        (si aplica)

Nunca dentro de este plugin — estos son entregables del proyecto auditado, igual que el inventario o el informe de auditoría.

F4 — Versionado y registro de aceptación

Todo documento público que un titular acepta necesita versión, porque consentimiento.md (skill implementar-ley-21719) exige que privacy_consents.version_texto corresponda a un texto real y recuperable — no a "la política actual", que cambia.

Crea o actualiza docs/privacidad/legal/registro-versiones.md:

# Registro de versiones — documentos de privacidad
| Documento | Versión | Fecha | Cambios | Vigente |
|---|---|---|---|---|
| politica-privacidad.md | v1 | 2026-08-22 | Versión inicial | sí |
| consentimiento-registro.md | v1 | 2026-08-22 | Versión inicial | sí |

Cuando se regenera un documento por un cambio real en el sistema (nuevo proveedor, nueva finalidad), sube la versión y no reescribas la fila anterior — los consentimientos otorgados bajo v1 siguen siendo válidos para lo que v1 decía, igual que explica consentimiento.md.

Disclaimer obligatorio — va en cada documento generado

Encabeza todo documento de docs/privacidad/legal/ con esto, sin excepción y sin resumir:

> **BORRADOR — pendiente de revisión legal.** Este documento fue generado a
> partir de la evidencia técnica reunida en `docs/privacidad/` (inventario,
> RAT/ROPA, registro de proveedores, registro de IA, consentimientos) el
> <fecha>. No está listo para publicarse: requiere revisión de un abogado
> antes de usarse de cara a un titular. Los puntos marcados
> `REVISIÓN LEGAL REQUERIDA` son huecos deliberados, no omisiones — no los
> completes sin esa revisión.

Qué no debe hacer este skill

• No inventar contenido plausible. Ver la sección "Lo que este skill nunca hace" arriba — es la regla central, no una entre varias.
• No presentar el borrador como publicable. El disclaimer va siempre.
• No mezclar versiones. Un documento regenerado sube de versión; no sobrescribe silenciosamente el historial de qué decía antes.
• No usar datos personales reales como ejemplo en ningún documento — mismo criterio que el resto del plugin.
• No generar un documento cuya condición de activación (F1) no se cumple — un aviso de cookies en un sistema sin ninguna herramienta de tracking registrada es ruido, no protección.