Cómo proteger los datos de tus usuarios en tu app creada con IA (sin un equipo de seguridad)

Una coach que conocemos creó una app para dar seguimiento a sus clientes con un creador de apps con IA en un fin de semana. Notas de sesión, objetivos, revisiones de avances — todo lo que antes guardaba en una libreta, ahora con buscador y organizado. Funcionó tan bien que dos amigas coaches le pidieron usarla también.

Ahí fue cuando cayó en cuenta: ya no estaba guardando sus propias notas. Estaba guardando las notas de otras personas sobre sus clientes — detalles de salud, problemas personales, nombres. Si esos datos se filtraran, no sería su vergüenza. Sería la de ellas.

No necesitas un equipo de seguridad para manejar esto de forma responsable. Necesitas tres hábitos y la disposición de hacerle a tu creador con IA algunas preguntas directas. Esta guía cubre cómo proteger los datos de tus usuarios en tu app creada con IA al nivel que de verdad importa para un producto pequeño.

Empieza por notar qué datos de usuario estás guardando en realidad

La mayoría de los creadores subestima esto. “Solo tengo un formulario de registro” normalmente significa que tienes:

Direcciones de correo — suficiente para hacer spam o phishing a alguien.
Nombres conectados a comportamiento — qué compraron, qué escribieron, cuándo inician sesión.
Lo que sea que tus usuarios escriban en cajas de texto libre — y la gente escribe de todo en un campo de notas: números de teléfono, detalles médicos, sueldos, quejas sobre su jefe.

Tómate diez minutos y anota cada pieza de información que tu app guarda sobre una persona. No los campos de la base de datos — el significado humano. “Correo”, “qué suplementos toman”, “notas que su entrenador escribió sobre ellos”. Esa lista es tu superficie de responsabilidad. Todo lo demás en este artículo trata de hacerla más pequeña y más segura.

Hábito 1: Recolecta menos

Los datos más baratos de proteger son los datos que nunca recolectaste. Antes de proteger nada, reduce la lista.

Repasa la lista que acabas de hacer y pregúntate de cada elemento: ¿uso esto? La app de la coach pedía fecha de nacimiento al registrarse porque la plantilla de registro del creador con IA la incluía. Ella nunca la usó en ningún lado. Una sola frase a su creador con IA — “quita la fecha de nacimiento del registro y borra la columna” — y toda una categoría de datos sensibles desapareció.

Cosas que las apps suelen recolectar y nunca usan: fechas de nacimiento, números de teléfono, direcciones físicas, género, “¿cómo te enteraste de nosotros?”. Si no lo usas este mes, siempre lo puedes pedir después. Lo que no puedes es revertir una filtración.

Hábito 2: Controla quién puede ver qué

Hay dos versiones de esta pregunta, y necesitas las dos.

Dentro de la app: ¿puede un usuario ver los datos de otro usuario? Si tu app tiene clientes y coaches, ¿puede el cliente A llegar a ver las notas del cliente B alguna vez? Escribimos una guía completa sobre los permisos de usuario en tu app creada con IA, pero la versión corta: describe la regla a tu creador con IA en lenguaje sencillo (“un coach ve solo a sus propios clientes; los clientes se ven solo a sí mismos”) y luego pruébalo tú mismo con dos cuentas. Inicia sesión como un usuario, intenta llegar a los datos de otro usuario haciendo clic por ahí. Cinco minutos, dos cuentas de prueba. Esta sola prueba atrapa la filtración más común en las apps pequeñas.

Fuera de la app: ¿quién puede ver la base de datos en sí? Eso eres tú, tu plataforma de creación con IA y cualquier persona con quien hayas compartido accesos. Lo que nos lleva a las preguntas.

Hábito 3: Hazle a tu creador estas cinco preguntas

No necesitas entender las respuestas a fondo. Necesitas preguntar, y las respuestas deberían ser síes con seguridad. Pega estas en tu creador de apps con IA una por una:

“¿Las contraseñas de los usuarios se guardan con hash, o cualquiera puede leerlas?” La única respuesta aceptable incluye la palabra “hash”. Si tu app guarda contraseñas que cualquiera puede leer, arréglalo hoy mismo — normalmente es un arreglo de un solo prompt, y la mayoría de los creadores modernos lo hacen bien por defecto.
“¿La conexión a la app está cifrada (HTTPS)?” Busca el candado en tu propio navegador. Si la dirección de tu app empieza con https://, ya terminaste con esta.
“Si alguien obtuviera el archivo de la base de datos, ¿podría leer los campos sensibles?” Esto va sobre el cifrado en reposo. La mayoría de las plataformas de hosting lo manejan automáticamente — pregunta de todos modos y anota la respuesta.
“¿Qué servicios de terceros reciben datos de los usuarios?” Herramientas de correo, analítica, procesadores de pagos. No los estás quitando — estás completando tu lista, porque cada servicio que guarda los datos de tus usuarios es parte de tu superficie de responsabilidad.
“¿Hay un respaldo, y quién puede acceder a él?” Los respaldos son copias de tus datos, y las copias también necesitan protección. (Si todavía no has configurado respaldos, empieza aquí).

Guarda las respuestas en un documento. Ese documento es el comienzo de tu postura de seguridad, y te alegrará que exista la primera vez que un cliente — o el abogado de un cliente — pregunte.

Cuando alguien dice “borra mis datos”

Tarde o temprano alguien lo hará, y la ley en la mayoría de los lugares (el GDPR en Europa, reglas parecidas en otras partes) dice que tienes que hacerlo de verdad. Decide ahora cuál es tu respuesta:

¿Puedes borrar a un usuario y todo lo conectado a él? Pídele a tu creador con IA que lo agregue — “crea una acción de administrador que borre a un usuario y todos sus datos” — antes de necesitarlo contra reloj.
¿Borrarlos en la app también los quita de tu herramienta de correo y de analítica? Revisa tu lista de la pregunta 4.
Los respaldos seguirán conteniéndolos por un tiempo. Eso es normal y, en general, está bien — solo tenlo claro, para que puedas decirlo con honestidad.

Responder una solicitud de borrado en un día porque te preparaste se ve profesional. Andar a las carreras durante dos semanas se ve exactamente como lo que es.

Escribe la página de privacidad en lenguaje sencillo

Olvídate por ahora de las 4,000 palabras de jerga legal generada. Escribe cinco frases honestas: qué recolectas, por qué, quién más lo toca (tu herramienta de correo, tu procesador de pagos), cuánto tiempo lo conservas y cómo pedir el borrado. Ponla en /privacy y enlázala desde tu página de registro.

Esto no es asesoría legal, y si manejas datos genuinamente sensibles — salud, niños, finanzas — gasta el dinero en una hora con un abogado. Pero una página clara y honesta le gana a una que se ve impresionante y que nadie puede leer, y escribirla te obliga a conocer de verdad tus propias respuestas.

El listón está más bajo de lo que temes, y más alto que cero

No te estás defendiendo de estados-nación. Te estás defendiendo de las fallas aburridas y comunes: un campo de datos sobrante que nadie necesitaba, una regla de permisos que nadie probó, una tabla de contraseñas que alguien olvidó hashear. Proteger los datos de los usuarios a este nivel no es una habilidad de especialista — cada una de esas fallas se arregla con un prompt en lenguaje sencillo y una prueba de cinco minutos.

La coach del principio hizo todo esto en una tarde: borró dos campos sin usar, corrió la prueba de las dos cuentas (y atrapó una filtración — los clientes podían ver los nombres de pila de los demás en un menú desplegable), hizo las cinco preguntas, escribió su página de privacidad. Su app no se veía diferente después. Pero cuando su amiga le preguntó “¿esto es seguro para las notas de mis clientes?”, tenía una respuesta de verdad.

Tómate la tarde. Tus usuarios te dieron sus datos por confianza — así se ve cuidarlos.