¿Se pueden guardar datos de salud en una app de Base44?
No sin pedirlo antes. Los términos de servicio de Base44 (apartado 4.3, versión del 22 de junio de 2026) comprometen al cliente a no subir datos especialmente protegidos por ley, con la información sanitaria como ejemplo, salvo que Base44 lo acepte antes y por escrito.
El ejemplo viene de la ley sanitaria de Estados Unidos, pero lo prudente es aplicarlo igual a los datos de salud en Europa. Sus certificaciones de seguridad (SOC 2 e ISO 27001) no cambian esto: dicen que la plataforma está bien protegida, no que puedas meter en ella cualquier tipo de dato.
En vuestros servidores, esta cláusula deja de afectaros: los datos de salud nunca llegan a Base44, que solo ve el diseño de la app y datos de prueba.
¿Tu app tiene datos de salud aunque no lo parezca?
Dato de salud es cualquier cosa que diga algo sobre la salud de una persona. En una app interna creada fuera de IT aparecen sin que nadie los haya buscado, casi siempre en campos pensados para otra cosa:
| Campo o pantalla | ¿Es dato de salud? | Cómo evitarlo |
|---|---|---|
| Motivo de ausencia “baja médica” | Sí: dice que la persona está enferma | “Ausencia justificada”, sin motivo. El justificante, en el sistema de RR. HH. |
| Parte de accidente con la lesión | Sí | La app registra el suceso; la lesión, solo el sistema de prevención |
| Resultado del reconocimiento médico (“apto con restricciones”) | Sí, aunque no diga el diagnóstico | Guardar solo la fecha del último reconocimiento |
| Alergias o dieta para un evento o el comedor | Sí | Recogerlo fuera de la app, o borrarlo al acabar el evento |
| Adaptación de puesto, discapacidad, embarazo | Sí | Fuera de la app |
| “Observaciones” en texto libre y adjuntos en PDF | Puede serlo: acaban guardando lo que nadie previó | Revisar qué se escribe ahí y limitar los adjuntos |
| Turnos, fichajes, vacaciones | No, por sí solos | Nada que cambiar |
El caso que nadie ve venir es el adjunto: alguien sube un justificante médico en PDF. Va a los archivos, que siguen en Estados Unidos aunque se contrate la residencia en la UE, y si la app usa la IA para leerlo o resumirlo, el contenido llega a OpenAI o Anthropic.
Al llevar la app a vuestros servidores, este repaso campo por campo es el primer paso: lo que sobra se quita y lo que queda se protege con permisos por rol.
Si vuestra app no tiene ninguno de estos campos, esta guía no es para ti. Lo que sí te interesa es cómo llevar una app de Base44 a vuestro servidor propio.
¿Basta con la residencia de datos en la UE de Base44?
Ayuda, pero no lo resuelve. Decide dónde se guardan los registros, no por dónde pasan. Según la documentación de Base44 a 4 de octubre de 2026, además:
- Hace falta el plan Enterprise (o Elite, si el espacio de trabajo se creó antes del 1 de octubre de 2026).
- Solo vale para apps creadas después del 16 de abril de 2026.
- Los archivos, la cuenta y la facturación siguen en Estados Unidos.
Es la misma duda que planteó en septiembre de 2026, en la comunidad de Base44, un equipo con una app de datos de salud: aunque los datos se guarden en la UE, las peticiones se procesan en Estados Unidos. Antes de contratar, pedía un entorno dedicado en Europa o poder desplegarla por su cuenta.
Y la residencia es de Enterprise, que no está en la página de precios: se pide hablando con ventas, el precio es a medida y, como proveedor nuevo, pasa por la revisión de seguridad y compras de la empresa. En la migración real en la que se basan las guías de Keep44, la contratación de Enterprise tuvo que pasar por compras, legal e IT, y llevó más de medio año.
Si que los datos de salud pasen por Estados Unidos es aceptable, lo decide vuestro delegado de protección de datos. La tabla del principio es lo que necesita ver para decidirlo.
En vuestros servidores no hay residencia que contratar ni proveedor nuevo que aprobar: los datos de salud se guardan y se procesan dentro de vuestra red, y quien creó la app sigue cambiándola en Base44 con el modelo híbrido.
Los cuatro caminos
| Camino | Cuándo encaja | Qué hace falta | Lo que queda pendiente |
|---|---|---|---|
| Quitar el dato de salud | El dato no es imprescindible (el motivo de una baja, unas observaciones) | Cambiar los campos en Base44 y borrar lo ya guardado | Casi nada |
| Base44 Enterprise con residencia en la UE | Vuestro delegado acepta que los datos pasen por EE. UU. y aprobar un proveedor nuevo es viable | Plan Enterprise y el acuerdo por escrito con Base44 | Archivos, correo e IA fuera de la UE |
| Servidor propio con modelo híbrido | El dato es necesario y no puede salir de vuestra red, o la app habla con sistemas internos | Migrar el backend; Base44 queda solo con datos de prueba | Mantener el servidor. Los datos de salud no salen de vuestra red |
| Rehacerla con las herramientas de IT | La app pasa a ser crítica o entra en terreno clínico | Un proyecto de desarrollo completo | El más caro y el más lento |
Criterio de Keep44: empezar siempre por el primero. Muchas apps internas guardan datos de salud por un campo de texto que nadie necesitaba. Si, tras quitar lo que sobra, la app sigue necesitándolos, toca elegir entre los otros tres.
Qué cambia con un servidor propio
Con la app en vuestro servidor, Base44 y las empresas de la tabla del principio salen de producción. En el modelo híbrido, quien creó la app sigue editándola en Base44, pero solo con datos de prueba: a vuestro servidor viaja el diseño (pantallas, campos, lógica), nunca un dato real. El mecanismo está en la guía de cómo funciona el modelo híbrido.
Lo que se resuelve: los datos de salud no salen de vuestra red, no hace falta el acuerdo con Base44, nadie entrena IA con ellos y los archivos y correos se quedan en casa.
Lo que hay que hacer bien al migrar, porque en Base44 lo resolvía la plataforma:
- Permisos por rol, reescritos y revisados tabla por tabla: quién ve las bajas, quién los partes de accidente.
- Un registro de quién consulta esos datos.
- Cifrado y copias de seguridad dentro de vuestra política.
- La IA: si la app la usa, cambiarla por un proveedor que vuestra empresa haya aprobado, o quitarla.
En la migración real en la que se basan las guías de Keep44, lo que frenó a IT fue justo eso último: el riesgo de que los datos de la empresa acabaran entrenando un modelo de IA. La app usaba la IA integrada de Base44 y hubo que quitarla al migrar. Con eso, la pregunta dejó de existir y la app se puso en uso sin esperar a Enterprise.
Lo que dice esta guía sobre Base44 está comprobado en sus términos y su documentación el 4 de octubre de 2026. Sin confirmar todavía: en qué condiciones acepta Base44 datos de salud por escrito.
Cuándo Keep44 no es la respuesta
Si los datos de salud se pueden quitar de la app, quítalos: sale más barato que cualquier migración y no hace falta nadie de fuera. Y si vuestro delegado da por buena la residencia en la UE y Base44 firma el acuerdo, también vale.
Tampoco lo es si la app se ha convertido en una herramienta clínica para pacientes: ahí lo sensato es rehacerla con IT o con un proveedor del sector.
Lo que IT necesita saber
- Qué hay: qué tablas y campos tienen datos de salud, contando el texto libre y los adjuntos.
- Por dónde pasa: con Base44, por empresas de EE. UU. aunque haya residencia en la UE; con servidor propio, por ninguna.
- IA: qué pantallas llaman a la IA integrada y con qué datos. Fuera de Enterprise, pueden usarse para entrenar modelos.
- Accesos: permisos por rol y registro de quién consulta los datos de salud.
- Datos antiguos: lo que ya se guardó en Base44 hay que borrarlo. Las apps borradas pasan 30 días en la papelera.
- Quién decide: lo técnico, IT; si el tratamiento es aceptable, el delegado de protección de datos.
Esta guía explica la parte técnica. La decisión legal sobre datos de salud es de vuestro delegado de protección de datos.
Fuentes
- Base44: Terms of Service, apartado 4.3 (versión del 22/06/2026). Consultado el 4/10/2026.
- Base44: lista de empresas que procesan los datos (anexo C de su acuerdo de tratamiento de datos). Consultado el 4/10/2026.
- Base44: Privacy and security (residencia, entrenamiento de IA, papelera). Consultado el 4/10/2026.