Si construyes un portal de clientes, una app de reservas o un pequeño CRM para tus clientes, el cumplimiento del RGPD se convierte rápidamente en una pregunta real — incluso sin equipo legal ni abogado interno. Esta guía desglosa, en lenguaje claro, lo que el RGPD realmente pide a una aplicación de pequeña empresa, qué cambia cuando construyes con una plataforma no-code o de IA, y una checklist práctica que puedes aplicar tú mismo. Es un resumen educativo, no un consejo legal: para sectores regulados (salud, finanzas, datos de menores) o tratamientos a mayor escala, habla con un abogado o con un delegado de protección de datos antes de publicar.
Responsable vs encargado del tratamiento: la distinción que lo aclara todo
El RGPD se basa en una distinción simple pero a menudo confusa. El responsable del tratamiento decide por qué y cómo se tratan los datos personales — normalmente eres tú, como propietario del negocio, cuando recoges nombres, emails o reservas de tus clientes dentro de tu app. Un encargado del tratamiento procesa esos datos por cuenta del responsable y según sus instrucciones — es el caso de cada herramienta que conectas: tu plataforma no-code/IA, tu proveedor de hosting, tu base de datos, tu herramienta de email, tu procesador de pagos. Esta distinción importa por una razón muy práctica: indica quién es responsable de qué, y por eso deberías exigir un contrato de tratamiento de datos (DPA) a cada encargado que toque los datos de tus usuarios. Si un proveedor no puede mostrar un DPA cuando se le solicita, trátalo como una señal de alarma.
- Responsable: tú, respecto a los datos de tus clientes finales recogidos a través de tu app.
- Encargado: tu plataforma, tu proveedor de hosting, tu herramienta de email, tu procesador de pagos — cualquiera que trate datos solo siguiendo tus instrucciones.
- Subencargado: los propios proveedores de un encargado, como el hosting en la nube detrás de tu proveedor de base de datos.
Qué suele exigir el RGPD a una pequeña aplicación
Sin el lenguaje jurídico, la mayoría de las obligaciones del RGPD para una pequeña app se reducen a una lista corta y práctica.
- Una política de privacidad en lenguaje claro: qué recoges, por qué, durante cuánto tiempo, quién tiene acceso, y cómo ejercer los derechos.
- Una base legal para cada tipo de tratamiento: ejecución del contrato para cumplir una reserva, consentimiento para emails de marketing o cookies no esenciales, interés legítimo para seguridad básica y prevención de fraude.
- Consentimiento donde realmente se requiera: una aceptación explícita para comunicaciones de marketing y para cualquier cookie o rastreador no esencial.
- Minimización de datos: recoger solo los campos que realmente necesitas para prestar el servicio — resistir el reflejo de añadir campos "por si acaso".
- Fundamentos de seguridad: conexiones cifradas (HTTPS), control de acceso razonable, contraseñas con hash, copias de seguridad periódicas.
- Derechos de los usuarios: una manera de solicitar acceso, rectificación o eliminación de sus datos, y recibirlos en un formato portable.
- Conciencia sobre las brechas de seguridad: si algo sale mal, quizá debas notificar a tu autoridad de control y, en algunos casos, a los usuarios afectados.
Las preguntas adicionales que añade una plataforma no-code o de IA
Construir sobre una plataforma no-code o de IA no te libera de tus obligaciones como responsable del tratamiento — añade una capa de preguntas sobre tu proveedor. Antes de confiar datos reales de clientes a cualquier plataforma, pregúntate lo siguiente.
- ¿Dónde viven físicamente los datos — en la infraestructura de quién, en qué región?
- ¿Quién es el encargado de esos datos, y publica una lista de sus propios subencargados?
- ¿Hay disponible un contrato de tratamiento de datos (DPA), y cubre realmente los datos que vas a almacenar?
- ¿Puedes exportar tu esquema y tus datos, y borrarlo todo a petición, sin depender del soporte del proveedor?
- ¿La IA se usa solo para ayudar a escribir el código de tu app, o también ve y conserva los datos de producción de tus usuarios finales?
- ¿La plataforma actúa como intermediaria opaca de los datos personales de tus clientes, o tú tienes las llaves de la base de datos real?
Elegir una región y obtener un DPA
Dos preguntas determinan gran parte de tu exposición al riesgo: dónde se almacenan los datos, y si puedes obtener un DPA firmado para ello. La mayoría de proveedores serios de backend-as-a-service — Supabase entre ellos — publican un DPA estándar que puedes aceptar directamente, y te permiten elegir la región de hosting para tu propio proyecto de base de datos, incluidas regiones en la UE. Esto importa porque pone la elección de la jurisdicción en tus manos en lugar de dejarla al valor por defecto de una plataforma. Merece la pena comprobarlo para cada encargado de tu stack — base de datos, herramienta de email, procesador de pagos, herramienta de analítica — no solo tu creador de apps.
Cookies y rastreadores en la app o el sitio que generas
Las reglas sobre cookies son más simples de lo que se piensa una vez separas las dos categorías. Las cookies estrictamente necesarias — las que mantienen a un usuario conectado o recuerdan un carrito — no requieren consentimiento. Todo lo demás, como analítica, publicidad o píxeles de redes sociales, generalmente sí lo requiere, mediante una aceptación clara antes de instalar la cookie. El enfoque más simple para una pequeña app: empezar solo con cookies estrictamente necesarias, y añadir un banner de consentimiento únicamente cuando realmente añades una herramienta de analítica o publicidad que lo necesite.
Una checklist sin abogado para tipos de app comunes
Web vitrina o portafolio: una página de política de privacidad enlazada en el pie, un formulario de contacto que indique qué ocurre con los datos enviados y durante cuánto tiempo, y un banner de cookies solo si añades analítica o publicidad.
App de reservas o citas: una base legal que combine la ejecución del contrato para la reserva en sí y el consentimiento para recordatorios de marketing, recogiendo solo lo necesario para cumplir la reserva (nombre, contacto, fecha), y listando tus encargados — sincronización de calendario, pago, proveedor de SMS o email — en tu política de privacidad.
Portal de clientes o pequeño CRM: un DPA vigente con cada encargado que toque los registros de clientes, acceso basado en roles para que cada miembro del equipo vea solo lo que necesita, una forma documentada de exportar o eliminar permanentemente el registro de un cliente, y un periodo de conservación que realmente aplicas en lugar de guardarlo todo para siempre.
Dónde encaja Cadrant: tú te quedas con las llaves
Cadrant está construido alrededor de una arquitectura "trae tu propio Supabase": cuando construyes una app, conectas tu propia organización de Supabase en lugar de una base de datos que Cadrant alojaría y controlaría por ti. Esto tiene consecuencias directas para el RGPD. Tú eliges tu propio proyecto de Supabase y su región de hosting. Supabase, como encargado del tratamiento de tu base de datos, publica su propio DPA que aceptas directamente con ellos. Sigues siendo el responsable de los datos de tus usuarios finales — las personas que reservan, se registran o envían formularios a través de tu app — y mantienes en todo momento la capacidad completa de consultar, exportar o eliminar esos datos desde tu propio panel de Supabase, con independencia de Cadrant. Esto es deliberadamente distinto de las plataformas donde los datos de tus clientes residen en una base de datos opaca, compartida y propiedad del proveedor, que no puedes consultar ni exportar.
Para ser transparentes sobre nuestra propia configuración: Cadrant es publicado por Convergence Lab, una empresa francesa, y la plataforma en sí — no las bases de datos que conectas — está alojada en infraestructura de AWS que no es exclusivamente de la UE; nos apoyamos en garantías adecuadas para cualquier transferencia fuera de la UE, y nuestro delegado de protección de datos puede contactarse en dpo@cadrant.ai para preguntas sobre la plataforma en sí. Hoy no reclamamos certificación SOC 2 ni ISO 27001, y deberías tratar con sano escepticismo cualquier afirmación de este tipo por parte de un proveedor hasta que hayas visto el certificado.
Cómo te ayuda Cadrant a mantenerte en cumplimiento, en la práctica
Puedes pedir en lenguaje natural las piezas que apoyan el cumplimiento: una página de política de privacidad, un banner de consentimiento de cookies, un formulario de contacto que explique qué se hace con los envíos, o una página de ajustes de cuenta donde tus propios usuarios finales puedan solicitar sus datos o pedir su eliminación. Como tu base de datos vive en tu propio proyecto de Supabase, atender una solicitud de eliminación o exportación es una acción real y auditable — no un ticket enviado a un tercero. El cumplimiento nunca es totalmente automático, pero partir de una arquitectura donde tú controlas los datos hace que cada paso posterior sea mucho más sencillo.