Información de privacidad para solicitantes y afiliados

1. A quién se aplica y qué queda separado

Se aplica a personas que preparan o envían una solicitud, solicitantes en revisión, personas aprobadas o rechazadas, afiliados activos, suspendidos o terminados y, cuando una entidad actúe mediante representante, a sus personas de contacto.

La información del cliente referido se rige por la privacidad del servicio contratado. Esta política explica la vinculación económica y el acceso del afiliado, pero no convierte los datos del expediente del cliente en datos disponibles para el afiliado.

2. Recogida progresiva por fases

3. Datos exactos de la solicitud actual

4. Datos de cuenta de afiliado

Tras aprobarse, la cuenta puede contener identificador de usuario, solicitud de origen, código único, estado, modalidad de comisión, porcentaje de éxito, importe por caso viable, umbral de pago, días de atribución, persona aprobadora y fechas de aprobación, suspensión, terminación, creación y actualización.

El programa es una capacidad adicional de la cuenta de cliente: una persona puede conservar sus propios expedientes y disponer además del panel de afiliado. Esa compatibilidad no autoriza a mezclar datos del expediente propio con información de personas referidas.

5. Datos de campañas, atribución y actividad económica

6. Qué muestra realmente el panel

El panel servido por la aplicación consulta internamente el caso, pero devuelve al afiliado una referencia parcial, servicio, modalidad, estado de atribución, seguimiento permitido, comisión y fecha. No devuelve nombre, email, teléfono, DNI, documentos ni mensajes del cliente.

El área de campañas muestra clics, visitas únicas, casos atribuidos y su embudo, solicitudes de afiliación recibidas, aprobadas y rechazadas, conversión, calidad, comisión, EPC, gasto declarado, coste por resultado, retorno, ubicación declarada, hosts observados y alertas agregadas de cumplimiento. Son métricas agregadas por campaña, canal y periodo: no permiten identificar ni seguir individualmente a un visitante, cliente o solicitante. En modalidad de caso viable puede ocultarse el detalle posterior que no sea necesario para el devengo.

7. Identidad, domicilio e IBAN

El formulario inicial no solicita estos datos. Para que el perfil quede listo para pagos, la cuenta puede pedir nombre, apellidos, DNI o NIE, fecha de nacimiento, teléfono, domicilio, país, documentos de identidad e IBAN, con revisión separada de identidad y banco.

Los campos de DNI o NIE, fecha de nacimiento, domicilio e IBAN se guardan mediante campos cifrados en la implementación auditada; del IBAN también puede conservarse un sufijo de cuatro caracteres para mostrarlo enmascarado. Los documentos se someten a estados de revisión. No se piden contraseña, PIN, OTP ni acceso a la cuenta bancaria.

8. Pagos, facturación y registros económicos

El sistema utiliza un ledger económico append-only para créditos, retenciones, liberaciones, reversos, ajustes y pagos. La retirada se solicita desde 10 €, se reserva frente a solicitudes simultáneas y exige identidad e IBAN de titularidad verificados, además de la información fiscal y los controles antifraude que correspondan. Los mandatos y autorizaciones del expediente pertenecen al cliente referido y no son un requisito documental del afiliado para cobrar. La transferencia requiere revisión y una referencia bancaria; el estado de software por sí solo no acredita que el banco la haya ejecutado.

Los datos fiscales, facturas, retenciones y justificantes se tratarán cuando sean necesarios para cumplir la relación y las obligaciones contables o tributarias. Un dato económico consolidado puede quedar bloqueado tras la baja aunque se suprima información no necesaria del canal.

9. Procedencia de los datos

10. Finalidades y bases jurídicas

11. Interés legítimo: prueba que debe superarse

La expresión interés legítimo no autoriza por sí sola un tratamiento. Para prevención de fraude, calidad, seguridad o defensa debe identificarse un interés real y actual, demostrar que el dato es necesario y ponderar si prevalecen los derechos y expectativas razonables de la persona.

Entre las salvaguardas observadas o exigidas están la ausencia de acceso del afiliado al expediente, la deduplicación por caso, el bloqueo de autorreferidos, la ruta sin parámetros completos, los límites de acceso y la revisión humana de controversias. La persona puede oponerse a tratamientos basados en interés legítimo y explicar sus circunstancias.

12. Datos obligatorios, opcionales y posteriores

13. Borrador local del formulario

El borrador se guarda en el almacenamiento de sesión del navegador bajo una clave propia. Puede contener todas las respuestas y casillas del formulario, incluidas URLs, audiencia y plan. No se envía al servidor por el simple hecho de escribir.

El almacenamiento de sesión suele desaparecer al finalizar la sesión de la pestaña, puede borrarse desde el navegador y se elimina expresamente tras un envío correcto. Si la persona inicia sesión o crea una cuenta para completar el envío, el borrador permite reanudarlo. No debe utilizar un equipo compartido sin cerrar la pestaña y la sesión.

14. Envío autenticado y límites técnicos

La API exige sesión de cliente, limita el cuerpo a 16 KB, normaliza textos y URLs y aplica límites por usuario e IP. Estos controles reducen abuso y entradas excesivas, pero no deciden la aprobación comercial.

La ruta actual obtiene el email verificado de la cuenta y no confía en un correo escrito libremente dentro del formulario. Si ya existe una cuenta de afiliado no terminada o una solicitud enviada, evita crear duplicados.

15. Evidencia de aceptación: qué se guarda y qué no

La interfaz obliga a abrir las condiciones, desplazarse hasta el final y marcar lectura, aceptación, prohibición de spam y prohibición de garantías antes de enviar. En servidor se exige aceptación y se registran el indicador de aceptación, la referencia de condiciones, la fecha y hora y, para las nuevas solicitudes selladas, el SHA-256 de la instantánea canónica del contenido completo.

La versión aceptada debe coincidir exactamente con la versión vigente que valida el servidor. La instantánea estructurada se guarda una sola vez por referencia en un registro inmutable; cada solicitud nueva enlaza su versión y huella mediante integridad referencial. Si el contenido de una referencia ya registrada no coincide, el alta falla de forma cerrada. Si cambia la versión mientras existe un borrador, se conservan las respuestas no jurídicas, pero se reinician las cuatro confirmaciones legales y se exige releer.

La base de datos no contiene una columna que pruebe cada movimiento de scroll ni columnas separadas para las dos confirmaciones de cumplimiento; estas últimas se incorporan al texto del plan enviado. Las solicitudes anteriores al sellado conservan su versión y fecha como evidencia histórica limitada y no reciben una huella reconstruida. No se afirmará una evidencia técnica distinta de la realmente conservada.

16. Revisión de canales y ubicaciones declaradas

La revisión puede comprobar existencia, acceso público, titularidad aparente, temática, audiencia declarada, formato, frecuencia, URL exacta de publicación y forma prevista de recomendar. La URL es obligatoria cuando la colocación dispone de una dirección pública; si no existe o el soporte es privado, efímero, email, mensajería u offline, se exige una explicación verificable. Ninguna de esas vías autoriza a entrar en áreas privadas, solicitar contraseñas o recopilar seguidores.

La Plataforma solo conoce ubicaciones declaradas y usos que llegan a sus enlaces o se aportan como evidencia. No puede prometer descubrir una copia privada, no indexada, borrada o que nunca genere una petición. Solo debe conservarse evidencia pertinente para la decisión o una incidencia y la revisión humana debe distinguir una señal técnica incompleta de una infracción acreditada.

17. Categorías especiales y datos ajenos

No se solicitan opiniones políticas, religión, salud, orientación sexual, biometría ni otras categorías especiales para aprobar una afiliación. Que un canal público trate esos temas no autoriza a extraerlos ni a utilizarlos como criterio general.

Si una evidencia incluye accidentalmente información sensible o de terceros, debe ocultarse o suprimirse la parte irrelevante. Solo una necesidad legal específica, documentada y proporcionada podría justificar un tratamiento excepcional.

18. Decisión humana sobre la solicitud

La aprobación o rechazo corresponde a administración o al rol específico de supervisor de afiliados. Los managers de reclamaciones no acceden a esta cola. La implementación registra quién revisó, cuándo y, en un rechazo, la motivación necesaria. No existe un algoritmo que apruebe o rechace la idoneidad comercial por sí solo.

Las validaciones automáticas de formato, longitud, sesión, duplicidad o límites de envío son requisitos técnicos, no una evaluación de idoneidad. Una nota interna no debe contener juicios excesivos, categorías especiales ni información ajena al canal y al cumplimiento.

19. Atribución, campaña, ubicación y ruta de entrada

El servidor aplica primero una vinculación contractual vigente del cliente. Para una atribución nueva exige un código activo y una campaña registrada de esa cuenta, unida a un canal aprobado y compatible con la página de destino. Un código aislado, una campaña inventada, un canal ajeno, un destino distinto o una campaña archivada no originan una atribución nueva.

Solo se conserva como ruta de entrada el pathname, sin la consulta completa. Cuando el navegador facilita una fuente externa, se normaliza a host y URL sin consulta, fragmento ni credenciales y se contrasta con la ubicación declarada. El Referer puede faltar o ser impreciso y por sí solo no acredita una infracción. Los intentos duplicados, autorreferidos o inválidos no se atribuyen; sus categorías de riesgo pueden agregarse como evidencia de seguridad, pero el formulario o caso del cliente sigue su curso.

20. Cookies propias de atribución

Cuando existe consentimiento de marketing y el servidor valida el enlace oficial, el navegador puede guardar sp_affiliate_ref, sp_affiliate_landing, sp_affiliate_campaign, sp_affiliate_channel, sp_affiliate_click y, si procede, sp_affiliate_widget. Su máximo técnico ordinario es 90 días; se configuran con SameSite=Lax, Path=/ y Secure bajo HTTPS, y se eliminan al retirar ese permiso.

Las cookies separan el código, el pathname, la clave de campaña, el UUID del canal, un recibo aleatorio de clic y el identificador del widget. El recibo sp_affiliate_click lo emite el servidor como HttpOnly: el JavaScript de la página no puede leerlo ni escribirlo. No contienen nombre, email, DNI, documentación ni UUID del caso. Borrarlas elimina la señal del navegador, pero no una atribución contractual ya consolidada ni una vinculación vigente del cliente.

21. Autorreferidos, duplicados y señales antifraude

22. Efectos económicos y revisión humana

Algunas reglas técnicas pueden impedir una atribución concreta por autorreferencia, duplicidad o código inactivo. Aunque no son una aprobación o rechazo de la cuenta, pueden tener efecto económico. El afiliado puede pedir revisión en affiliates@sinpleitos.es indicando su código, la referencia parcial disponible y el motivo, sin aportar datos del cliente.

Una señal de riesgo no debe convertirse automáticamente en una declaración de fraude. Las suspensiones, terminaciones, reversos y ajustes controvertidos requieren la motivación, proporcionalidad y vías de revisión previstas en las condiciones aplicables.

23. Separación respecto de clientes referidos

• El afiliado no recibe nombre, email, teléfono, DNI, dirección ni documentación del cliente.
• No puede abrir el expediente, descargar archivos, leer comunicaciones ni contactar al cliente desde el panel.
• La referencia corta sirve para conciliar sin exponer el UUID completo.
• El estado se simplifica y puede ocultarse cuando la modalidad no lo necesita.
• El afiliado no decide viabilidad, estrategia, negociación, cierre ni tratamiento jurídico.
• Una reclamación del afiliado sobre su comisión no autoriza a revelar el contenido del caso.

24. Responsabilidades en los canales del afiliado

El afiliado determina cómo trata datos en sus perfiles, web, newsletter, grupo o comunidad y actúa como responsable de esas operaciones. Debe informar, usar una base válida, respetar las reglas del canal y evitar spam, scraping ilícito, bases compradas o mensajes a personas sin permiso.

Compartir un enlace no convierte al afiliado en encargado de SINPLEITOS ni le permite recopilar formularios por su cuenta. Si en el futuro existiera una integración que transmitiera leads directamente, su rol, contrato, campos, seguridad y deber de información tendrían que definirse antes de activarla.

25. Datos de terceros que no deben enviarse

• Listados de seguidores, suscriptores o contactos.
• Capturas de conversaciones privadas sin ocultar datos.
• DNI, contratos, extractos, billetes o documentación de potenciales clientes.
• Credenciales de redes sociales o enlaces privados de administración.
• Datos comprados, obtenidos por scraping o recogidos sin información válida.
• Información de menores o categorías especiales sin necesidad y base acreditadas.
• Secretos empresariales o datos de clientes de otro profesional.

26. Accesos internos y compartimentación

27. Controles de base de datos y API

Las tablas de solicitudes, cuentas, campañas, ubicaciones, evidencias agregadas de enlaces, gasto declarado, revisiones de ranking y pagos tienen seguridad a nivel de fila forzada. No se concede acceso directo al navegador: las escrituras pasan por rutas autenticadas y las funciones de observabilidad quedan reservadas al servicio. La persona afiliada recibe estadísticas y observaciones saneadas de sus campañas.

La base de datos comprueba que campaña, cuenta, canal, clave, ubicación y evidencia mínima sean coherentes. Los eventos repetidos se agregan mediante una huella irreversible y las decisiones administrativas conservan actor, fecha y motivo. Esta arquitectura reduce exposición, pero requiere revisar permisos, cuentas de servicio, logs y consultas cada vez que cambie el panel.

28. Proveedores y transferencias

La infraestructura puede utilizar proveedores de alojamiento, base de datos, almacenamiento, correo y observabilidad. El proveedor principal para datos de cuenta y tablas es Supabase en la arquitectura observada; Vercel presta alojamiento y ejecución y Resend puede intervenir en comunicaciones cuando esté configurado.

La función concreta, activación, rol, subencargados y transferencias se explican en el Registro público de proveedores y privacidad. No se afirma una región o DPA firmado que no pueda comprobarse desde el código. Una transferencia internacional debe apoyarse en el mecanismo aplicable y en medidas complementarias cuando procedan.

29. Conservación por categoría

30. Límite técnico de la conservación auditada

La auditoría del repositorio no ha acreditado una tarea automática específica que purgue por sí sola todas las tablas de solicitudes, cuentas, atribuciones, eventos y pagos al alcanzar un plazo uniforme. Por tanto, no se promete una eliminación automática inexistente.

La conservación debe ejecutarse mediante el calendario y las decisiones de bloqueo de la Política de conservación y supresión de datos. La ausencia de un borrado automático no permite conservar indefinidamente: obliga a aplicar revisiones operativas, registrar excepciones y demostrar la necesidad de cada categoría.

31. Derechos disponibles

32. Cómo ejercer derechos o impugnar una decisión

33. Comunicaciones y preferencias

Los avisos sobre revisión, activación, seguridad, atribución, incidencias, condiciones, facturación, pagos, suspensión o cierre son necesarios para gestionar la solicitud o relación. No se consideran por ello una autorización general para publicidad.

Las campañas, novedades o materiales promocionales no imprescindibles deben separarse y permitir una retirada sencilla cuando se basen en consentimiento. Oponerse a mercadotecnia directa no impide recibir un aviso contractual o de seguridad necesario.

34. Seguridad, exactitud e incidentes

• Cuenta autenticada, controles de rol y rutas de servidor.
• Seguridad a nivel de fila forzada y vistas saneadas del panel.
• Campaña ligada en base de datos a su cuenta, canal, ubicación y destino aprobados.
• Destinos internos sin API, administración, panel ni autenticación.
• Nombres, claves y conceptos de gasto sin datos personales.
• Fuente externa sin consulta, fragmento ni credenciales y huella irreversible para agregar repeticiones.
• Cifrado de campos sensibles de identidad, domicilio e IBAN en la implementación observada.
• Normalización, límites de tamaño y rate limiting en solicitud, campañas y clics.
• Separación entre verificación de identidad y banco.
• Revisión humana motivada antes de confirmar una infracción discutida.
• Registros inmutables de revisión del ranking y eventos para cambios relevantes.
• Actualización de canales, ubicaciones, contacto e IBAN a cargo de la persona afiliada.
• Evaluación y notificación de brechas conforme al riesgo y plazos aplicables.

35. Funciones avanzadas y activación controlada

El modelo operativo incorpora niveles, examen, revisión de canales y contenidos, campañas medibles, gasto declarado, saldo y retiradas, recursos, ranking seudonimizado, permanencia y una relación de subafiliación limitada a un nivel. La recompensa de subafiliación permanece desactivada mientras no exista una condición económica individual sostenible y aceptada.

El ranking no se publica ni genera un premio por el mero cálculo automático: el periodo debe cerrarse, resolver empates y superar una revisión humana registrada contra las bases y el hash exacto del cálculo. Un alias sigue siendo dato personal seudonimizado aunque no muestre el nombre civil. Antes de activar una función que amplíe datos o destinatarios se define su base, necesidad, acceso, conservación y oposición.

36. Menores y capacidad

El Programa está dirigido a personas con capacidad para contratar y no está diseñado para menores. Si se detecta una solicitud sin capacidad suficiente, se detendrá la evaluación y se conservará únicamente la evidencia necesaria para seguridad, cumplimiento o defensa antes de suprimirla.

37. Cambios, correcciones e historial

PAF-2026.8 conserva los controles y límites de PAF-2026.7 y corrige el alcance operativo del lanzamiento: el formulario actual solo admite microcréditos; la opción de aerolíneas permanece oculta y bloqueada en interfaz, API, repositorio, campañas, widgets y atribución hasta su activación expresa. Los registros históricos válidos no se reescriben por este cierre temporal.

PAF-2026.7 corrigió la descripción del alta económica: el formulario dejó de recoger una preferencia entre modalidades, la API rechaza caso viable y toda cuenta nueva queda fijada en porcentaje sobre éxito. El cambio a caso viable solo puede solicitarse posteriormente desde nivel 5 (Platino) y exige los controles aplicables.

La política se revisará si cambia el formulario, la ventana o fuente de atribución, la información visible, una modalidad económica, el perfil requerido, un proveedor, un proceso automatizado o una función pública. Un cambio material se reflejará en el historial documental y se comunicará a las relaciones activas cuando proceda.