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 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 formada por el primer bloque del identificador, servicio, modalidad, estado de atribución, seguimiento permitido, comisión y fecha. No devuelve nombre, email, teléfono, DNI, documentos ni mensajes del cliente.

En modalidad de porcentaje puede mostrarse un estado simplificado del caso para permitir seguimiento. En modalidad de caso viable, la columna de seguimiento se oculta porque el detalle posterior no es necesario para ese devengo. Los estados no permiten abrir el expediente ni consultar su estrategia.

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, banco, titularidad y los dos documentos legales del perfil verificados. 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 y la fecha y hora.

La base de datos de solicitudes no contiene una columna independiente que pruebe cada movimiento de scroll ni columnas separadas para las dos confirmaciones de cumplimiento; estas últimas se incorporan al texto del plan enviado. No se afirmará que existe una evidencia técnica distinta de la que realmente se conserva. Desde esta revisión, las nuevas aceptaciones quedan alineadas con la referencia pública vigente AF-2026.51; las versiones históricas deben conservar su referencia original.

16. Revisión de canales declarados

La revisión puede comprobar existencia, acceso público, titularidad aparente, temática, audiencia declarada, formato, frecuencia y forma prevista de recomendar. Una URL opcional facilita la comprobación, pero no autoriza a entrar en áreas privadas, solicitar contraseñas o recopilar seguidores.

Solo debe conservarse evidencia pertinente para la decisión o una incidencia. Si una publicación cambia después, la revisión posterior debe limitarse al contenido relacionado con el Programa. No se adquieren bases externas para enriquecer el perfil del solicitante.

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, fuente y ruta de entrada

El servidor aplica primero una vinculación contractual vigente del cliente; si no existe, utiliza la primera cookie propia válida, después un código del formulario y por último el referrer o URL. Se admite un código normalizado y se conserva como ruta de entrada únicamente el pathname, sin la consulta completa, para evitar guardar otros parámetros que pudieran contener información personal.

Cuando el cliente crea un caso, la atribución almacena el código, la fuente, la ruta, el servicio y la configuración económica aplicable. Un caso solo puede tener una atribución en la tabla. Los intentos duplicados y los códigos inexistentes o inactivos se ignoran.

20. Cookies propias de atribución

Al llegar mediante parámetros como ref, aff, affiliate o afiliado, el navegador solo guarda las cookies propias sp_affiliate_ref y sp_affiliate_landing cuando existe consentimiento de marketing. Su máximo técnico ordinario es 90 días; se configuran con SameSite=Lax, ruta general y atributo Secure cuando la conexión es HTTPS, y se eliminan al retirar ese permiso.

La primera contiene el código normalizado y la segunda solo la ruta. No contienen el UUID del caso ni la identidad del visitante. Borrar las cookies elimina esa señal del navegador, pero no borra una atribución contractual ya creada ni una vinculación vigente del cliente; esas evidencias tienen finalidad y conservación diferentes.

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 y pagos tienen seguridad a nivel de fila para que la persona autenticada consulte sus propios registros o acceda el backoffice autorizado. Las filas brutas de atribución no se conceden directamente al cliente de Supabase: el servidor construye una vista saneada para el panel.

La escritura de solicitudes, aprobaciones y atribuciones se realiza por rutas o repositorios de servidor. 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 y vistas saneadas del panel.
• 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 la solicitud.
• Separación entre verificación de identidad y banco.
• Registros de eventos para decisiones y cambios relevantes.
• Actualización de canales, 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, 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; tampoco se publica un ranking hasta cerrar y revisar el periodo correspondiente.

Antes de activar una función que amplíe los datos, la visibilidad o los destinatarios se define su base, necesidad, campos, acceso, conservación y oposición. Un alias enlazable internamente sigue siendo dato personal aunque no muestre el nombre civil; se trata como seudónimo y no como dato anónimo.

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.3 sustituye la versión resumida anterior por una auditoría del formulario, evidencia de aceptación, tablas de afiliación, panel, perfil, cookies, decisiones, conservación y funciones condicionadas. También alinea las nuevas aceptaciones con las condiciones AF-2026.51.

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.