Seguridad y privacidad: cuando la app contiene la vida real de tus clientes

Una app para entrenadores puede reunir nombre, correo, mensajes, fotos de progreso, peso, perímetros, hábitos, lesiones, dolor, alimentación y pagos. Son datos de personas reales, no contenido de prueba. Algunos pueden revelar información sobre la salud y requieren una protección especialmente cuidadosa.

No hace falta demonizar las herramientas de IA para reconocer el riesgo. La IA puede detectar fallos, sugerir reglas de acceso y ayudar a escribir pruebas. Lo que no puede hacer por sí sola es asumir la responsabilidad legal ni conocer todas las decisiones de negocio que solo están en tu cabeza.

1. Empieza por un inventario de datos

Antes de hablar de cifrado, escribe todos los datos que recoge la app. Para cada campo, responde cinco preguntas: quién lo aporta, para qué se usa, quién puede verlo, cuánto tiempo se conserva y a qué terceros se envía.

El RGPD exige, entre otros principios, finalidad, minimización, limitación del plazo y seguridad apropiada. Además, su artículo 9 establece una protección específica para las categorías especiales, entre ellas los datos relativos a la salud. Puedes consultar el texto oficial del Reglamento.

2. El proveedor aloja; tú sigues tomando decisiones

Si decides para qué y cómo se usan los datos de tus clientes, normalmente ocupas el papel de responsable del tratamiento. Los servicios de base de datos, correo, analítica, pagos o IA pueden actuar como encargados o subencargados en determinadas operaciones. Esos papeles implican contratos, instrucciones y controles.

• Mapa de proveedores: saber quién recibe datos y para qué.
• Acuerdos: revisar condiciones de tratamiento y subencargados.
• Ubicación y transferencias: entender dónde se procesan los datos y qué garantías aplican.
• Retención: configurar plazos y borrado también en copias, logs y herramientas auxiliares.
• Derechos: poder localizar, exportar, corregir y eliminar información sin una búsqueda manual interminable.

Una certificación del proveedor puede ser una señal valiosa sobre su organización. No certifica tus reglas de acceso, tus textos, tus integraciones ni el modo en que tu equipo usa la app.

3. Autenticación no es autorización

La autenticación responde «¿quién eres?». La autorización responde «¿puedes ver o cambiar este registro concreto?». Una app puede tener un login perfectamente correcto y aun así permitir que un cliente consulte datos de otro cambiando un identificador en la URL o en una petición.

Las reglas en la interfaz sirven para evitar confusión, no para proteger datos. El navegador está bajo control del usuario. La propia guía de Lovable recuerda que el frontend es público y no debe tomar decisiones de seguridad; las validaciones y permisos deben aplicarse del lado servidor y en la base de datos. Consulta sus buenas prácticas oficiales.

4. Añadir IA añade otro flujo de datos

«Generar una rutina con IA» suena como una función aislada. En realidad, primero hay que decidir qué contexto sale de tu sistema. Enviar el perfil completo porque está disponible es cómodo, pero contradice la minimización si bastaban objetivo, experiencia y restricciones relevantes.

• ✓ Elimina nombre, correo, teléfono y otros identificadores si no son necesarios.
• ✓ No envíes conversaciones completas para resolver una pregunta concreta.
• ✓ Revisa si el proveedor conserva entradas y salidas o las usa para mejorar modelos.
• ✓ Documenta los subprocesadores, la región y los mecanismos de transferencia aplicables.
• ✓ Evita que una respuesta del modelo ejecute cambios sensibles sin validación y confirmación.
• ✓ Informa con claridad al cliente cuando sus datos se comuniquen a un tercero de IA.

La IA generativa también puede inventar, omitir una contraindicación o producir contenido incoherente. Si la salida afecta al servicio, necesitas revisión humana, límites y un registro suficiente para reconstruir qué ocurrió sin almacenar más datos de los necesarios.

5. La seguridad incluye saber responder

No existe un sistema con riesgo cero. La diferencia profesional es detectar pronto, contener, entender el alcance y comunicar cuando corresponda. El plan mínimo debe existir antes de la primera incidencia:

• Detectar: alertas de accesos anómalos, errores y cambios críticos.
• Contener: revocar sesiones y claves, desactivar una función o aislar un proveedor.
• Investigar: registros útiles, con acceso restringido y sin secretos ni datos excesivos.
• Evaluar: qué personas y datos se han visto afectados y qué riesgo existe.
• Notificar: cumplir los plazos y destinatarios legales cuando sean aplicables.
• Aprender: corregir la causa, verificar la solución y documentar el incidente.

En determinados casos, el RGPD exige notificar una violación a la autoridad de control sin dilación indebida y, cuando sea posible, dentro de 72 horas desde que se tiene constancia. No significa que todo error deba notificarse: significa que necesitas evaluar el riesgo con rapidez y dejar registro de la decisión.

6. Las tiendas también exigen privacidad operativa

Publicar una app nativa añade reglas concretas. Apple exige una política accesible que explique recogida, uso, terceros, retención y borrado; si la app permite crear una cuenta, debe permitir iniciar su eliminación desde la propia app. Google Play también exige una vía dentro de la app y un recurso web para solicitar el borrado de cuenta y datos asociados.

No es solo rellenar el formulario de la tienda. El botón tiene que borrar de verdad los datos correspondientes, coordinar archivos y proveedores y conservar únicamente aquello que debas mantener por una razón válida. Revisa las guías oficiales de Apple y Google Play antes de diseñar el flujo.

7. Checklist de salida

• □ Existe un inventario de datos, finalidades, bases, plazos y destinatarios.
• □ Cada rol solo accede a los registros que necesita y hay pruebas que lo demuestran.
• □ Los secretos no llegan al navegador ni aparecen en repositorios o registros.
• □ Los archivos privados no tienen enlaces públicos permanentes.
• □ Hay un flujo real para acceso, exportación, rectificación y borrado.
• □ Se han revisado proveedores, subencargados y transferencias.
• □ El uso de IA minimiza contexto, informa al cliente y tiene revisión humana.
• □ Existe un plan de incidentes con responsables y datos de contacto.
• □ Una persona cualificada ha revisado la seguridad según el riesgo del producto.

Serie completa

• Parte 1: coste real y cuándo compensa
• Parte 2: infraestructura, datos y backups
• Parte 3: seguridad, privacidad y datos de clientes (estás aquí)
• Parte 4: mantenimiento, observabilidad, actualizaciones y soporte

Preguntas frecuentes