jesubohr/skills

Cumplimiento Legal

Prepara un proyecto para su lanzamiento legal: documentos legales, captura de consentimiento, evidencia de consentimiento, manejo de cookies, reglas de reembolso, minimización de datos, derechos de medios y verificaciones de leyes locales.

El resultado es un borrador para revisión, no cambios aplicados. Un desarrollador lee el borrador, lo aprueba, y solo entonces un agente lo implementa. Esto mantiene cada decisión legal y de código visible y reversible.

Límites importantes

No eres un abogado, y las leyes cambian. Haz estas cosas en cada ejecución:

• Busca en la web para confirmar el estado actual de cada ley que cites. Registra la URL de origen y la fecha en que la verificaste. Los archivos de referencia en este skill pueden estar desactualizados.
• Marca cada afirmación legal de la que no estés seguro con (verificar).
• Dile al usuario que un abogado local debe revisar los documentos antes del lanzamiento, especialmente para sectores regulados (salud, finanzas, menores de edad, juegos de azar, criptomonedas, decisiones de IA sobre personas).
• Nunca prometas "protección total". El objetivo es eliminar las brechas comunes y costosas.

Flujo de trabajo

Paso 1: Inspeccionar el proyecto primero

Antes de hacer preguntas, aprende lo que el código ya te dice. Esto reduce las preguntas a aquellas que solo el usuario puede responder. Busca:

• Stack tecnológico, frontend y backend, móvil o web, dónde está la base de datos.
• Páginas legales existentes (busca "terms", "privacy", "cookies", "refund", "legal", "términos", "privacidad").
• Flujos de registro e inicio de sesión, y cada formulario que recopile datos personales. Enumera cada campo.
• Scripts y SDKs de terceros: analytics, anuncios, píxeles, repetición de sesiones, widgets de chat, mapas, videos incrustados, fuentes de CDNs, seguimiento de errores, tests A/B.
• Cookies y almacenamiento local que la aplicación establece.
• Pagos: proveedor, único o suscripción, bienes digitales o físicos.
• Correos electrónicos y SMS: transaccionales y de marketing.
• Imágenes, videos, fuentes, iconos y audio en el repositorio o cargados desde URLs.
• Alojamiento y ubicación de datos (región en la nube).
• Cualquier funcionalidad de IA que procese datos de usuarios.

Si aún no hay código, omite este paso y pregunta más en el Paso 2.

Paso 2: Entrevistar al usuario

Lee references/intake-questionnaire.md. Haz solo las preguntas que el Paso 1 no haya respondido. Pregunta en grupos pequeños (de 5 a 8 preguntas a la vez), con el grupo más importante primero: entidad legal y países. Ofrece respuestas predeterminadas sensatas cuando sea posible para que el usuario pueda responder rápido.

No adivines hechos sobre el negocio. Un nombre de empresa, país o uso de datos incorrecto en un documento legal es peor que uno faltante. Si el usuario no sabe una respuesta, escribe un marcador de posición claro [TODO: ...] y agrégalo a la lista de preguntas abiertas.

Paso 3: Encontrar las leyes aplicables

Las leyes se aplican según dónde esté establecido el negocio y dónde estén sus usuarios. Una startup colombiana que vende a México y Estados Unidos debe seguir partes de los tres.

1. Construye la lista de países (y estados de EE. UU.) a partir de la entrevista.
2. Lee el archivo correspondiente en references/jurisdictions/:
   • latam.md para Colombia, México, Brasil, Argentina, Chile, Perú y notas generales de Latinoamérica.
   • united-states.md para leyes federales y estatales.
   • other.md para cualquier otro país (notas breves de la UE y el Reino Unido, y un método para investigar un país desconocido).
3. Busca en la web para confirmar que cada ley sigue vigente y encontrar cambios posteriores a la fecha de referencia.
4. Usa la regla más estricta aplicable cuando las reglas entren en conflicto y un flujo global único sea más sencillo. Por ejemplo, un período de reembolso único que cumpla con el mínimo legal más largo es más fácil que uno por país. Informa al usuario cuando tomes esta decisión y qué le cuesta.

Paso 4: Auditar y diseñar cada elemento

Trabaja en cada elemento a continuación. Para cada uno, lee el archivo de referencia que nombra.

Elemento	Referencia
Términos y Condiciones	references/documents.md
Política de Privacidad	references/documents.md
Política de Cookies y decisión de consentimiento	references/cookies.md
Casillas de verificación en formularios de registro con enlaces	references/consent-records.md
Registros de consentimiento trazables	references/consent-records.md
Política de Reembolso	references/documents.md (sección de reembolso) y el archivo de jurisdicción
Minimización de datos	references/data-minimization.md
Derechos de imagen y medios	references/media-rights.md
Lista de verificación de leyes locales	los archivos de jurisdicción

Regla del período de reembolso: el valor predeterminado del usuario es 5 días después de la compra. Usa el mayor entre este valor predeterminado y el mínimo legal de cada país aplicable. Anota si la ley cuenta días hábiles o días calendario, y a partir de qué evento (fecha de compra, fecha de entrega o fecha de contrato).

Paso 5: Escribir el borrador

Crea la carpeta del borrador en el proyecto. Ruta predeterminada: docs/legal-compliance/. Usa la estructura en assets/draft-structure.md. En resumen:

docs/legal-compliance/
├── README.md                  # Resumen, perfil del negocio, leyes, lista de verificación, preguntas abiertas
├── documents/
│   ├── terms-and-conditions.md
│   ├── privacy-policy.md
│   ├── cookies-policy.md
│   └── refund-policy.md
├── data-inventory.md          # Cada campo de datos, su propósito, base legal, retención
├── media-inventory.md         # Cada activo multimedia, fuente, licencia, estado
└── implementation-plan.md     # Cambios de código a realizar, paso a paso, en el stack del proyecto

Escribe los documentos legales en el idioma (o idiomas) de los usuarios objetivo. Usa los datos reales del negocio de la entrevista. Escribe en lenguaje sencillo: oraciones cortas, encabezados claros. El lenguaje sencillo es más fácil de entender para los usuarios, y muchas leyes (por ejemplo, en Brasil, México y California) requieren avisos claros y accesibles.

Escribe implementation-plan.md para el stack real del proyecto, con rutas de archivo y esbozos de código, para que un agente pueda implementarlo sin más trabajo de diseño. Si no hay código, describe los cambios en términos neutrales al stack (modelo de datos, comportamiento de la UI, comportamiento de la API).

Paso 6: Presentar y esperar aprobación

Dale al usuario un resumen breve:

• Leyes que aplican y por qué.
• La lista de verificación con estado: hecho, faltante o necesita decisión.
• Brechas de alto riesgo primero (por ejemplo: rastreadores que cargan antes del consentimiento, sin evidencia de consentimiento, medios sin licencia).
• Preguntas abiertas y elementos [TODO].
• Elementos que un abogado debe revisar.

Luego detente. No cambies el código de la aplicación hasta que el usuario apruebe el plan. Cuando apruebe, implementa implementation-plan.md paso a paso, y actualiza la lista de verificación en README.md a medida que se completen los elementos.

Obligaciones continuas que informar al usuario

El cumplimiento no es una tarea única. Agrega esto al README:

• Actualiza los documentos cuando el producto, el uso de datos, los terceros o la ley cambien. Aumenta el número de versión, conserva las versiones antiguas y pide a los usuarios que acepten nuevamente cuando el cambio sea material.
• Conserva los registros de consentimiento durante el tiempo que exija la ley (consulta references/consent-records.md).
• Responde a las solicitudes de los interesados (acceso, corrección, eliminación, exclusión) dentro del plazo legal.
• Ten un plan de respuesta a violaciones de datos con los plazos de cada país.
• Verifica nuevamente antes de ingresar a un nuevo país o agregar un nuevo uso de datos.