Registro de Actividades de Tratamiento (RAT) — Northa

Última revisión: 2026-09-02 Versión: 3.2 (autónomo España + AEPD/LOPDGDD; GLM-4.7-flash; edad 16; Meta Pixel)

Documento interno preparado en cumplimiento del Art. 30 del Reglamento (UE) 2016/679 (GDPR), desarrollado por la Ley Orgánica 3/2018, de 5 de diciembre, de Protección de Datos Personales y garantía de los derechos digitales (LOPDGDD), y coherente con la Ley 34/2002, de 11 de julio, de servicios de la sociedad de la información y de comercio electrónico (LSSI-CE) para las actividades de comunicaciones comerciales. No requiere publicación pública, pero debe estar disponible para la Agencia Española de Protección de Datos (AEPD) —o la autoridad de control del Estado miembro correspondiente— en caso de inspección. Se mantiene actualizado por el responsable del tratamiento bajo supervisión de la AEPD.

Este registro es coherente con privacy-policy.md (v3.2) y subprocessors.md (v3.3). El detalle de plazos por categoría se desarrolla en retention-policy.md.

1. Responsable del tratamiento

• Titular: Carlos Eduardo Gómez Fandiño.
• Nombre comercial / marca: Northa (https://www.northa.center).
• Forma jurídica: Autónomo (persona física empresario individual) dado de alta en AEAT — epígrafes IAE de servicios de informática (orientativo 845, a confirmar con gestor).
• NIF: ES60052213H.
• Domicilio profesional: Calle Mayorazgo de Duarte 25, 28052 Madrid, España.
• Email de contacto y ejercicio de derechos: privacy@northa.center (también info@northa.center).
• Marco normativo aplicable:
  • Reglamento (UE) 2016/679 (GDPR) — de aplicación directa.
  • LOPDGDD (adaptación española al GDPR).
  • LSSI-CE (comunicaciones comerciales y servicios de la sociedad de la información).
  • Supervisión: Agencia Española de Protección de Datos (AEPD).
• Para usuarios ubicados fuera de la Unión Europea / EEE aplicamos las mismas protecciones como estándar global del producto.

2. Delegado de Protección de Datos (DPO)

No existe obligación de designar DPO bajo el Art. 37 GDPR (no realizamos seguimiento a gran escala, ni tratamiento sistemático y extensivo de datos de categoría especial, ni tratamiento a gran escala en el ámbito del Art. 37.1.b/c). Las solicitudes y consultas de protección de datos se atienden a través de info@northa.center. Si la escala del tratamiento cambiara, se evaluará el nombramiento formal de DPO.

3. Derechos de los interesados

El tratamiento documentado en este registro reconoce los derechos del interesado conforme al GDPR (Art. 15–22) y la LOPDGDD (Art. 11–19):

• Acceso (Art. 15), rectificación (Art. 16), supresión / "derecho al olvido" (Art. 17), limitación (Art. 18), portabilidad (Art. 20), oposición (Art. 21), no ser objeto de decisiones automatizadas (Art. 22) y retirada del consentimiento en cualquier momento sin que afecte a la licitud del tratamiento previo (Art. 7.3).
• Reclamación ante la AEPD (https://www.aepd.es) o la autoridad de control del Estado miembro de residencia.
• Para titulares en California (CCPA/CPRA) y resto de EE.UU. se aplican los derechos adicionales descritos en privacy-policy.md §10.4, incluido el control destacado "No vender ni compartir mis datos personales" en /dashboard/profile/privacy, que revoca de un clic los purposes third_party_sharing e identifiable_data_sharing (actividades 13 y 14).

El canal de ejercicio de estos derechos es info@northa.center; plazo de respuesta de un mes (Art. 12.3 GDPR), prorrogable a dos meses en solicitudes complejas.

4. Base de legitimación y datos sensibles (Art. 6 / Art. 9 GDPR)

• Bases del Art. 6 GDPR utilizadas: 6.1.a (consentimiento), 6.1.b (ejecución de contrato), 6.1.c (obligación legal), 6.1.f (interés legítimo).
• Datos de categoría especial (Art. 9 GDPR): la carta natal —al derivarse de la fecha/hora/lugar de nacimiento e interpretarse junto con las conversaciones del usuario— puede revelar convicciones filosóficas o espirituales e inferencias sobre bienestar personal o salud mental. Su tratamiento requiere consentimiento explícito (Art. 9.2.a GDPR).
• Gate de consentimiento Art. 9.2.a: ya implementado en el producto (checkbox previo al cálculo de la carta, sin marcar por defecto, bloquea la creación de la carta si no se acepta). La preferencia se persiste en el registro de consentimientos del usuario y es revocable en /dashboard/profile/privacy.
• Estándar de protección reforzado: además del consentimiento explícito, los datos de nacimiento se almacenan cifrados en reposo mediante cifrado a nivel de aplicación (Fernet / AES-128-CBC + HMAC-SHA256) — ver §6 y privacy-policy.md §12.

5. Transferencias internacionales

La mayoría de los sub-procesadores alojan o procesan datos fuera del Espacio Económico Europeo, principalmente en Estados Unidos. Las transferencias se amparan en Cláusulas Contractuales Tipo (SCC) de la Comisión Europea (Decisión 2021/914) y/o en el EU-US Data Privacy Framework (DPF) cuando el proveedor está certificado. Todos los sub-procesadores tienen DPA vigente (Art. 28 GDPR): auto-incluido en sus Terms of Service (AWS, Railway), aplicable por uso del DPF (Cloudflare), o aceptado explícitamente en el Admin Console (Google Workspace CDPA, 2026-07-27). Detalle por proveedor, fechas y referencias en subprocessors.md §3.

Sub-procesadores retirados (no activos; no aparecen como destinatarios en las actividades): OpenAI (retirado junio 2026 — migración a AWS Bedrock), Vercel (retirado 2026-07-12 — migración a Railway), Resend (retirado 2026-07-18 — migración a Gmail API), Photon/komoot (retirado julio 2026). Historial completo en subprocessors.md §4.

6. Medidas técnicas y organizativas generales (post-Bloque 1)

Conjunto de medidas aplicables de forma transversal (las específicas de cada actividad se detallan en su apartado):

• Contraseñas: hash bcrypt (one-way, nunca en claro) con timing equalizer anti-enumeración y verificación contra el corpus Have I Been Pwned (HIBP) en registros/ cambios de contraseña.
• Comunicaciones: TLS 1.3 en todo el tránsito, con cabecera HSTS.
• Cifrado a nivel de aplicación (Fernet / AES-128-CBC + HMAC-SHA256) para datos de nacimiento:
  • natal_charts: birth_date, birth_time, city, region, country (todos EncryptedString).
  • bookings: client_birth_date, client_birth_time, client_birth_place (todos EncryptedString).
  • Sin cifrado app-level, por diseño: users.password_hash (bcrypt one-way), bookings.client_birth_time_unknown (flag no sensible) y bookings.client_timezone (valor derivado).
• Sesiones / JWT (HS256): access 60 min, refresh 30 días, guest 24 h (TTL), cookies HttpOnly.
• Guard de producción LLM_PROVIDER: si ENVIRONMENT != 'local', la variable LLM_PROVIDER debe valer bedrock o el arranque del backend falla. Asegura que en producción nunca se enruten datos a OpenAI (o cualquier proveedor no autorizado) por accidente de configuración.
• Audit log: patrón append-only, con única excepción documentada: el job ip_anonymization que pone a NULL la IP de los registros con más de 30 días. Las acciones exentas (consent.*, account.deleted, admin.*) nunca se borran.
• Rate limiting: auth 5 / 60 s + 5 fallos / 15 min por email; chat 30 / min; report 12 / 5 min; geo 60 / min; contact 3 / 5 min.
• Filtro PII en chat marketplace: bloqueo server-side de teléfono, email y URL externa.
• Anti-alucinación y seguridad LLM: position_guard (post-LLM), scrub_source_attribution (anti-fuga de atribución) y detección de prompt injection.
• Backups cifrados, rotación 90 días. Acceso al backend por principio de mínimo privilegio.

7. Estructura de cada actividad

Para cada actividad documentamos: (1) nombre del tratamiento, (2) finalidad, (3) base legal GDPR, (4) categorías de interesados, (5) categorías de datos, (6) destinatarios y encargados, (7) transferencias internacionales, (8) plazo de conservación, (9) medidas técnicas y organizativas.

Actividad 01 — Registro y autenticación de usuarios

• Nombre: Gestión de cuentas y autenticación.
• Finalidad: Crear, mantener y autenticar cuentas de usuario; gestionar inicios de sesión, recuperación de contraseña, sesiones de invitado y OAuth con Google.
• Base legal: Art. 6.1.b GDPR (ejecución de contrato).
• Categorías de interesados: usuarios registrados; usuarios invitados temporales (sesión 24 h); suscriptores de pago.
• Categorías de datos: email, password_hash (bcrypt), nombre opcional, identificador interno, identificador OAuth de Google, timestamps de creación y último acceso, IP del último login (anonimizada a NULL a los 30 días por el job ip_anonymization).
• Destinatarios: ninguno externo salvo Google cuando el usuario opta por OAuth.
• Encargados del tratamiento: AWS RDS (PostgreSQL), Railway (hosting backend + web), Cloudflare (CDN/DNS/Turnstile en el flujo de login/registro), Google Identity (OAuth opcional).
• Transferencias internacionales: sí, a EE.UU. (AWS RDS, Railway, Cloudflare, Google). Mecanismo: SCC 2021/914 y/o EU-US DPF.
• Plazo: mientras la cuenta esté activa; tras eliminación, anonimización en 30 días excepto los datos retenidos por obligación fiscal/contable. Sesiones guest: 24 h (JWT TTL).
• Medidas: TLS 1.3 + HSTS; bcrypt + timing equalizer + check HIBP; JWT HS256 con expiración corta (access 60 min, refresh 30 d, guest 24 h) y cookies HttpOnly; rate limiting de auth (5/60 s + 5 fallos/15 min por email); Cloudflare Turnstile anti-bot; logging de intentos fallidos.

Actividad 02 — Cálculo de cartas natales y herramientas derivadas

• Nombre: Cálculo astrológico y persistencia de cartas.
• Finalidad: Calcular la carta natal del usuario, tránsitos, age point y aspectos; almacenar el resultado para reutilizarlo en sesiones futuras.
• Base legal: Art. 6.1.b (ejecución de contrato) + Art. 9.2.a GDPR (consentimiento explícito para datos sobre convicciones filosóficas/espirituales).
• Categorías de interesados: usuarios registrados y de pago.
• Categorías de datos: fecha, hora y lugar de nacimiento; coordenadas geográficas calculadas; carta natal estructurada (planetas, casas, aspectos); preferencias (sistema de casas). Datos de categoría especial (Art. 9 GDPR) por revelar potencialmente convicciones filosóficas/espirituales.
• Destinatarios: ninguno externo para el cálculo. La geocodificación (ciudad/país → lat/lon) se realiza contra OpenStreetMap/Nominatim vía proxy del backend (solo topónimo, sin identidad ni IP — no constituye tratamiento de datos personales).
• Encargados: AWS RDS (PostgreSQL), Railway (hosting backend).
• Transferencias internacionales: sí, a EE.UU. (AWS RDS, Railway). Mecanismo: SCC 2021/914 y/o EU-US DPF.
• Plazo: mientras la cuenta esté activa. Al borrar la cuenta, anonimización irreversible en 30 días (se conserva un identificador anónimo sin enlace al usuario para coherencia de auditoría).
• Medidas: cifrado a nivel de aplicación Fernet de birth_date, birth_time, city, region, country en natal_charts; gate de consentimiento Art. 9.2.a previo al cálculo; controles de acceso por usuario autenticado; mínimo privilegio en consultas de backend.

Actividad 03 — Generación de reports interpretativos con LLM y RAG

• Nombre: Generación de reports narrativos con modelos de lenguaje.
• Finalidad: Producir reports interpretativos personalizados (personalidad, propósito, ciclos vitales, etc.) basados en la carta natal del usuario y en una base de conocimiento documental (RAG).
• Base legal: Art. 6.1.b (ejecución de contrato) + Art. 9.2.a (consentimiento explícito) + Art. 22 GDPR (tratamiento automatizado con intervención humana disponible a petición).
• Categorías de interesados: usuarios registrados que solicitan un report.
• Categorías de datos: carta natal completa, contexto del usuario, fragmentos relevantes de la base RAG. El report final se persiste en Report.sections_json.
• Destinatarios: AWS Bedrock — generación con GLM-4.7-flash (informes y chat) y embeddings RAG con Amazon Titan Embed v2. OpenAI NO procesa datos de usuario (retirado junio 2026). El payload al modelo se construye con minimización deliberada (carta, fragmentos RAG, consulta); no se envían email de cuenta, contraseña, IP del usuario final ni datos de pago.
• Encargados: Amazon Web Services / AWS Bedrock (generación GLM-4.7-flash + embeddings Titan), AWS RDS (almacenamiento).
• Transferencias internacionales: sí, a EE.UU. (AWS Bedrock región us-east-1, AWS RDS us-east-1). Mecanismo: SCC 2021/914 + EU-US DPF, con políticas de AWS Bedrock que excluyen el uso de entradas/salidas para entrenamiento de modelos base y no almacenan prompts/respuestas tras servir la petición (sin retención de contenido por defecto).
• Plazo: mientras la cuenta esté activa; eliminación / anonimización en 30 días tras borrado de cuenta.
• Medidas: TLS 1.3 en tránsito; guard de prod LLM_PROVIDER (production solo acepta bedrock); anti-alucinación post-LLM (position_guard); anti-fuga de atribución (scrub_source_attribution); detección de prompt injection; persistencia de secciones para evitar regeneración innecesaria; opción de revisión humana ante solicitud (Art. 22.3 GDPR).

Actividad 04 — Conversaciones con el agente conversacional

• Nombre: Chat asistido por LLM.
• Finalidad: Mantener conversación contextual con el usuario sobre su carta y temas relacionados; preservar historial para continuidad.
• Base legal: Art. 6.1.b + Art. 9.2.a GDPR (los mensajes pueden contener información sobre convicciones, bienestar personal o vida íntima).
• Categorías de interesados: usuarios registrados, usuarios invitados temporales (24 h).
• Categorías de datos: mensajes del usuario, respuestas generadas, metadatos (timestamp, stage de la interacción, identificador de sesión).
• Destinatarios: AWS Bedrock — generación con GLM-4.7-flash (chat). OpenAI NO procesa datos de usuario (retirado junio 2026).
• Encargados: Amazon Web Services / AWS Bedrock (generación GLM-4.7-flash), AWS RDS (PostgreSQL).
• Transferencias internacionales: sí, a EE.UU. (AWS Bedrock us-east-1, AWS RDS us-east-1). Mecanismo: SCC 2021/914 + EU-US DPF; sin entrenamiento sobre datos del cliente y sin retención de contenido por defecto.
• Plazo: 90 días desde updated_at con hard-delete físico automático; las conversaciones fijadas (pinned) quedan exentas del borrado. El usuario puede borrar conversaciones individualmente o todo el historial desde el dashboard; anonimización 30 días tras borrado de cuenta.
• Medidas: TLS 1.3; sanitización de prompts; rate limiting chat 30/min; detección de prompt injection; almacenamiento con cifrado en reposo.

Actividad 05 — Procesamiento de pagos (vía Stripe)

• Nombre: Suscripciones, facturación y cobros.
• Finalidad: Procesar pagos recurrentes, emitir facturas, gestionar suscripciones, devoluciones y disputas.
• Base legal: Art. 6.1.b (ejecución de contrato) + Art. 6.1.c GDPR (obligación legal fiscal/contable — Código de Comercio y normas tributarias españolas).
• Categorías de interesados: suscriptores de pago.
• Categorías de datos: identificador Stripe del cliente, identificador de suscripción, importe, divisa, fecha, estado del pago, datos fiscales (nombre/razón social, dirección, NIF u identificación tributaria aplicable), método de pago tokenizado (nunca PAN completo — los datos de tarjeta se introducen directamente en Stripe y nunca pasan por nuestros servidores).
• Destinatarios: Stripe (procesador). AEAT y, cuando proceda, otras autoridades fiscales, para cumplimiento de obligaciones legales.
• Encargados: Stripe (PCI-DSS Level 1).
• Transferencias internacionales: sí, a EE.UU. / Irlanda (Stripe). Mecanismo: SCC + EU-US DPF.
• Plazo: 6 años para libros contables (Código de Comercio, Art. 30) y 4 años para soportes/facturas (prescripción de obligaciones tributarias, Art. 66 Ley General Tributaria — AEAT). Tras dichos plazos, supresión salvo obligación judicial o defensa de reclamaciones.
• Medidas: PCI-DSS gestionado por Stripe; no almacenamiento de datos de tarjeta; separación de roles; cifrado en reposo y tránsito.

Actividad 06 — Email transaccional (vía Google Workspace / Gmail API)

• Nombre: Envío de emails transaccionales.
• Finalidad: Enviar emails operativos (confirmación de cuenta, recuperación de contraseña, recibos, recordatorios de renovación, notificaciones de cambios).
• Base legal: Art. 6.1.b (ejecución de contrato) + Art. 6.1.c GDPR (obligación legal cuando aplica).
• Categorías de interesados: usuarios registrados, suscriptores.
• Categorías de datos: email destinatario, contenido del email (nombre, importe, enlaces personalizados).
• Destinatarios: Google Workspace (Gmail API). (Resend fue retirado el 2026-07-18 — ya no procesa datos.)
• Encargados: Google LLC (Google Workspace, con CDPA aceptado en Admin Console el 2026-07-27).
• Transferencias internacionales: sí, a EE.UU. (Google). Mecanismo: SCC + EU-US DPF.
• Plazo: logs de envío según la política de Google Workspace; nuestros registros internos según retención general.
• Medidas: TLS, DKIM, SPF, DMARC configurados; opt-out fácil; lista de no contactar respetada.

Actividad 07 — Formulario de contacto público

• Nombre: Captura y respuesta a consultas de contacto.
• Finalidad: Recibir consultas desde el formulario público (/api/contact) y responder por email.
• Base legal: Art. 6.1.f GDPR (interés legítimo: poder responder a quien nos contacta) + Art. 6.1.a (consentimiento implícito en el envío del formulario).
• Categorías de interesados: visitantes del sitio público.
• Categorías de datos: nombre, email, mensaje, IP (anti-spam), timestamp.
• Destinatarios: Google Workspace (Gmail API, entrega del email). (Resend retirado 2026-07-18.)
• Encargados: Google LLC (Gmail API), Cloudflare (Turnstile anti-bot del formulario).
• Transferencias internacionales: sí, a EE.UU. (Google, Cloudflare). Mecanismo: SCC + EU-US DPF.
• Plazo: 6 meses tras última interacción; o supresión inmediata a petición del interesado.
• Medidas: Cloudflare Turnstile anti-bot; rate limiter de contact (3 / 5 min); validación de inputs; TLS.

Actividad 08 — Analytics web y métricas de uso

• Nombre: Análisis estadístico de uso.
• Finalidad: Comprender cómo se usa el producto a nivel agregado para mejorar funcionalidades. No usamos analytics con identificación individual hoy.
• Base legal: Art. 6.1.f GDPR (interés legítimo). Si en el futuro activamos analytics con cookies que perfilen, pasaremos a Art. 6.1.a GDPR (consentimiento).
• Categorías de interesados: todos los visitantes y usuarios.
• Categorías de datos: páginas visitadas, duración, dispositivo, navegador, IP truncada.
• Destinatarios: ninguno externo en la versión actual. Si se activa un proveedor, se actualizará este RAT.
• Encargados: TBD.
• Transferencias internacionales: ninguna en la versión actual.
• Plazo: datos agregados sin caducidad; logs crudos 90 días.
• Medidas: IP truncada, sin cookies de tracking persistentes, sin perfilado individual.

Actividad 09 — Captura de leads de upgrade

• Nombre: Captura y gestión de leads para conversión a planes de pago.
• Finalidad: Identificar usuarios free interesados en planes superiores y enviarles comunicaciones segmentadas con su consentimiento.
• Base legal: Art. 6.1.a (consentimiento) o Art. 6.1.f GDPR (interés legítimo respecto a usuarios ya registrados) según el caso. Las comunicaciones comerciales por email se rigen además por el Art. 21 LSSI-CE (requieren consentimiento previo del destinatario o relación contractual previa sobre productos/servicios análogos).
• Categorías de interesados: usuarios free, visitantes que se suscriben al newsletter.
• Categorías de datos: email, plan al que muestra interés, fuente, timestamp.
• Destinatarios: Google Workspace (Gmail API, envío) y TBD (CRM, si se incorpora). (Resend retirado 2026-07-18.)
• Encargados: Google LLC (Gmail API).
• Transferencias internacionales: sí, a EE.UU. (Google). Mecanismo: SCC + EU-US DPF.
• Plazo: mientras no se ejerza baja/revocación; revisión periódica de bases inactivas.
• Medidas: doble opt-in para newsletter, opt-out en cada envío, segmentación clara.

Actividad 10 — Logs técnicos y auditoría

• Nombre: Registro de eventos técnicos y de seguridad.
• Finalidad: Detectar incidencias, depurar errores, investigar incidentes de seguridad, cumplir obligaciones legales y mantener trazabilidad de consentimientos y accesos.
• Base legal: Art. 6.1.f GDPR (interés legítimo) + Art. 6.1.c cuando aplica (obligación legal).
• Categorías de interesados: usuarios autenticados, visitantes.
• Categorías de datos: identificador de usuario (cuando aplica), IP, user-agent, endpoint, código de respuesta, timestamp, mensaje de error, acción auditada (p. ej. consent.*, account.deleted, admin.*).
• Destinatarios: ninguno externo en producción mínima. Si se integra observabilidad OTLP externa, se actualizará este RAT.
• Encargados: AWS RDS (PostgreSQL), Railway, Cloudflare (CDN/DNS ven IPs de conexión). Proveedor de observabilidad externo TBD.
• Transferencias internacionales: sí, a EE.UU. (AWS RDS, Railway, Cloudflare). Mecanismo: SCC 2021/914 y/o EU-US DPF.
• Plazo: audit_log: 730 días (2 años) con hard-delete físico automático, excepto acciones exentas (consent.*, account.deleted, admin.*) que nunca se borran. Logs operativos generales: 90 días. IP en audit_log anonimizada (puesta a NULL) a los 30 días por el job ip_anonymization.
• Medidas: patrón append-only con única excepción documentada (anonimización de IP a los 30 días); rotación automática; control de acceso restringido a administradores.

Actividad 11 — Mensajería interna profesional-cliente

• Nombre: Chat directo cliente↔astrólogo del marketplace.
• Finalidad: Facilitar la comunicación previa y en torno a la sesión; moderar el canal para impedir el intercambio de datos de contacto fuera de la plataforma; conservar evidencia para resolver disputas.
• Base legal: Art. 6.1.b GDPR (ejecución del contrato) para la mensajería; Art. 6.1.f GDPR (interés legítimo) para la moderación y la prevención del bypass del marketplace.
• Categorías de interesados: clientes y astrólogos del marketplace.
• Categorías de datos: contenido de los mensajes, marca temporal, partes implicadas, estado (entregado/bloqueado), motivo de bloqueo, señales de moderación (reportado/revisado).
• Destinatarios: el astrólogo destinatario (mensajes entregados); el equipo de moderación interno solo para mensajes bloqueados o reportados.
• Encargados: AWS RDS (PostgreSQL), Railway (hosting backend).
• Transferencias internacionales: sí, a EE.UU. (AWS RDS, Railway). Mecanismo: SCC 2021/914 y/o EU-US DPF.
• Plazo: mensajes entregados 90 días desde su creación; evidencia de moderación (mensajes bloqueados o marcados): 180 días, o hasta resolver la revisión pendiente si fuera posterior. Hard-delete físico (sweep diario).
• Medidas: filtro PII automático server-side (bloquea teléfono, email y URL externa); acceso de moderación restringido y solo a mensajes flagged; audit log de accesos; soft-delete y cifrado en tránsito.

Actividad 12 — Análisis interno de producto (con consentimiento)

• Nombre: Telemetría de producto gateada por consentimiento.
• Finalidad: Registrar eventos de uso del producto (funnel de activación: pantallas visitadas, funciones usadas) para entender la adopción del servicio y priorizar mejoras.
• Base legal: Art. 6.1.a GDPR (consentimiento). Purpose analytics_internal, opt-in, desmarcado por defecto en el registro y revocable en /dashboard/profile/privacy.
• Categorías de interesados: usuarios que otorgan el consentimiento analytics_internal.
• Categorías de datos: identificador interno de usuario, tipo de evento, identificador de carta relacionado (si aplica), metadatos del evento (metadata_json). Sin contenido de chat, reports ni datos de salud/creencias (tabla product_events).
• Destinatarios: ninguno externo; uso interno exclusivamente.
• Encargados: AWS RDS (PostgreSQL), Railway (hosting backend).
• Transferencias internacionales: sí, a EE.UU. (AWS RDS, Railway). Mecanismo: SCC 2021/914 y/o EU-US DPF.
• Plazo: mientras el consentimiento esté vigente; al revocarlo dejamos de insertar eventos nuevos. Conservación de los eventos ya registrados según la política general de retención.
• Medidas: gate de consentimiento server-side previo a cualquier inserción; exclusión explícita de datos sensibles; soft-delete.

Actividad 13 — Compartir/vender datos anonimizados y agregados con filiales, socios y clientes

• Nombre: Compartición/venta de datos anonimizados y agregados.
• Finalidad: Compartir o vender datos anonimizados y agregados (estadísticas de uso, tendencias astrológicas sin identificar a ningún titular) con filiales del grupo, socios comerciales y clientes de datos.
• Base legal: Art. 6.1.a GDPR (consentimiento explícito, separado y revocable). Purpose third_party_sharing, opt-in, desmarcado por defecto (disponible tanto en el registro como en Ajustes), revocable en cualquier momento, incluido de un clic vía el control "No vender ni compartir mis datos personales" (CCPA/CPRA).
• Categorías de interesados: usuarios que otorgan el consentimiento third_party_sharing.
• Categorías de datos: métricas de uso agregadas y anonimizadas. Nunca identificadores directos (nombre, email) ni datos de nacimiento en bruto atribuibles a una persona concreta.
• Destinatarios: filiales del grupo, socios comerciales y clientes de datos. Hoy no existen destinatarios activos — se documentará cada receptor concreto (nombre, finalidad, DPA) en este registro antes de que el flujo de datos sea real.
• Encargados: AWS RDS (almacenamiento de la preferencia de consentimiento); sin encargado de la compartición en sí mientras no haya destinatarios activos.
• Transferencias internacionales: ninguna activa hoy; dependerá del destinatario cuando exista y se documentará en ese momento.
• Plazo: mientras el consentimiento esté vigente; revocable en cualquier momento.
• Medidas: anonimización/agregación como precondición de cualquier compartición futura; opt-in granular y revocable; sin flujo de datos real hasta que existan destinatarios documentados.

Actividad 14 — Compartir/vender datos identificables con terceros — CAPACIDAD INACTIVA

• Nombre: Compartición/venta de datos identificables (no activada).
• Finalidad declarada (no ejecutada): posible compartición o venta futura de datos identificables con filiales, socios y clientes, si en el futuro se activa formalmente.
• Base legal: Art. 6.1.a GDPR (consentimiento explícito). Purpose identifiable_data_sharing, opt-in, desmarcado por defecto, disponible solo en Ajustes → Privacidad (no en el registro) con aviso explícito de inactividad.
• Estado: CAPTURADO PERO INACTIVO. Ningún proceso del backend lee este consentimiento para efectuar una compartición real; no existe destinatario, flujo de datos ni transferencia internacional asociados hoy.
• Categorías de interesados: usuarios que otorgan (o deniegan) el consentimiento identifiable_data_sharing — el registro de su preferencia es, por ahora, el único tratamiento real.
• Categorías de datos: ninguna sale hoy; en caso de activarse, se limitaría a lo estrictamente necesario y se documentaría aquí antes de la activación.
• Destinatarios: ninguno.
• Puerta de activación (dura): este purpose no se activa hasta (a) contrato y DPA firmados con cada receptor concreto, (b) base jurídica documentada para esa compartición específica, y (c) privacy-policy.md actualizada y publicada con el detalle exacto. Ver spec docs/superpowers/specs/2026-07-11-data-consent-sharing-design.md §4.5.
• Plazo: la preferencia del usuario se conserva mientras exista la cuenta, como cualquier otro consentimiento.
• Medidas: separación de código: ningún sink de exfiltración lee este purpose; fail-safe por diseño.

Actividad 15 — Datos de nacimiento compartidos con el astrólogo elegido (ejecución del contrato)

• Nombre: Divulgación de datos de nacimiento al astrólogo de una reserva activa.
• Finalidad: Permitir que el astrólogo elegido prepare la carta del cliente y preste correctamente la sesión reservada.
• Base legal: Art. 6.1.b GDPR (ejecución del contrato). Automático al confirmarse la reserva; no requiere un consentimiento de venta aparte — es transparencia sobre la prestación del servicio (divulgado en terms-of-service.md §7.6 y en la pantalla de reserva).
• Categorías de interesados: clientes que reservan una sesión con un astrólogo del marketplace.
• Categorías de datos: fecha, hora y lugar de nacimiento; flag birth_time_unknown. Nunca email, teléfono ni otro dato de contacto.
• Destinatarios: exclusivamente el astrólogo asignado a esa reserva concreta, verificado por propiedad (mismo patrón que api/authz.py, filtrado por astrologer_id). Ningún otro astrólogo ni tercero.
• Encargados: AWS RDS (PostgreSQL), Railway (hosting backend). Google Calendar/Meet (gestión de la reserva y enlace de la sesión).
• Transferencias internacionales: sí, a EE.UU. (AWS RDS, Railway, Google). Mecanismo: SCC 2021/914 y/o EU-US DPF.
• Plazo: mientras la reserva esté en un estado activo (confirmed/completed); las reservas completadas se auto-resuelven a los 180 días y los datos efímeros (enlace Meet, tokens) se purgan a los 30 días tras resolved; se conserva el núcleo fiscal. Al cancelar la reserva se retira la exposición al astrólogo.
• Medidas: guard de propiedad anti-IDOR (carga solo si el astrólogo solicitante es dueño de la reserva); minimización estricta (sin datos de contacto); carga en batch sin exponer datos de otras reservas; cifrado a nivel de aplicación Fernet de client_birth_date, client_birth_time y client_birth_place en bookings.

Actividad 16 — Medición de publicidad (Meta Pixel)

• Nombre: Meta Pixel (Facebook/Instagram Ads).
• Finalidad: medir visitas (PageView) y el rendimiento de campañas publicitarias. Eventos de conversión (registro, compra) podrán añadirse más adelante con el mismo consentimiento.
• Base legal: Art. 6.1.a GDPR (consentimiento) + ePrivacy / Guía de cookies de la AEPD. Categoría de cookies Marketing, opt-in, desmarcada por defecto; revocable desde el banner / «Configurar cookies».
• Categorías de interesados: visitantes de www.northa.center / northa.center que aceptan Marketing. No se dispara en QA ni en local.
• Categorías de datos: URL, referrer, user-agent, IP (recibida por Meta), cookies _fbp / _fbc. Sin email, nombre, identificador de cuenta, carta natal ni contenido de chat (sin Advanced Matching).
• Destinatarios / corresponsables: Meta Platforms Ireland Limited (corresponsable de los eventos del Pixel según Controller Addendum / Business Tools Terms).
• Encargados: no aplica el modelo clásico Art. 28 para el Pixel (corresponsabilidad). Hosting del script en el frontend: Railway.
• Transferencias internacionales: sí, Irlanda + EE.UU. (Meta). Mecanismo: consentimiento + SCC y/o EU-US DPF.
• Plazo: cookies ~90 días; Meta conserva según su política. Al retirar el consentimiento dejamos de cargar el script y caducamos _fbp/_fbc.
• Medidas: no carga sin consentimiento; sin <noscript> (evitaría el opt-in); Pixel ID validado numérico; CSP enforcing limita orígenes a connect.facebook.net / *.facebook.com.

Tabla resumen

Revisión y actualización

Este registro se revisa al menos una vez al año y siempre que se incorpore un nuevo tratamiento, sub-procesador o cambio normativo relevante. La próxima revisión está prevista para 2027-06-30 o antes si hay novedades. Como responsable del tratamiento bajo GDPR/LOPDGDD, mantenemos este registro interno (Art. 30 GDPR) a disposición de la AEPD a requerimiento; no existe obligación de inscripción en un registro público de bases de datos para un autónomo de esta escala.

Anexos previstos

• Lista actualizada de sub-procesadores: ver subprocessors.md.
• Política de retención detallada: ver retention-policy.md.
• Documento de medidas técnicas y organizativas (DPIA / evaluación de impacto cuando proceda): en desarrollo.