¿Hace falta un registro de auditoría?
Si la app no guarda nada sensible y la usan cuatro personas, seguramente no. Hace falta cuando alguien puede preguntar «¿quién cambió este pedido?» o «¿quién exportó la lista de clientes?» y la respuesta importa: dinero, datos de empleados, clientes o un equipo de IT que tiene que aprobar la app. Estas preguntas salen en casi toda revisión de seguridad y están en la lista que IT repasa antes de aprobar una app de Base44.
Base44 tiene la certificación SOC 2 Type II para la plataforma. Cubre cómo Base44 gestiona su servicio. No registra lo que hacen dentro de tu app las personas que la usan.
Un registro hecho en la app
En un plan sin la API de Audit Logs, lo habitual es una entidad en la que escribe la app. Pídesela al chat de Base44 en un solo mensaje:
Crea una entidad llamada AuditLog con los campos user_email (texto), action (texto), detail (texto) y at (fecha y hora). Cualquier usuario con sesión iniciada puede crear un registro, pero solo los administradores pueden leer, editar o borrar registros. Añade una función logEvent(action, detail) que lea el usuario con sesión iniciada y cree un registro en AuditLog, y llámala cuando alguien abra la app y cada vez que alguien cree, edite o borre un registro.
La función que escriba debería parecerse a esta (ajusta el import a tu app):
import { base44 } from "@/api/base44Client";
export async function logEvent(action, detail = {}) {
const user = await base44.auth.me();
await base44.entities.AuditLog.create({
user_email: user.email,
action, // "open_app", "delete_order", "export_customers"
detail: JSON.stringify(detail),
at: new Date().toISOString()
});
}
Después abre los ajustes de la entidad y comprueba que las reglas de acceso son de verdad «cualquiera con sesión puede crear, solo los administradores pueden leer o cambiar». Keep44 no ha probado este mensaje exacto: confirma que las reglas se aplicaron antes de fiarte del registro.
Dónde se queda corto un registro hecho a mano
- Solo anota lo que el código llama. Una pantalla o acción que se olvide deja un hueco.
- No hay eventos de inicio de sesión de verdad. Una petición en el tablero de feedback de Base44 pide eventos de login y logout y propone escribir un registro al cargar la página. Eso anota «abrió la app», no un inicio de sesión verificado.
- Quien edita la app puede cambiar el código que escribe el registro. Cualquiera con permiso de edición puede quitar una llamada a
logEvent, así que el registro prueba menos que uno que guarda la plataforma. - La retención y la exportación son tuyas. Exporta la tabla a CSV de forma periódica y decide cuánto tiempo se conserva. El registro guarda correos electrónicos, que son datos personales: eso entra en el RGPD.
En Enterprise, la API de Audit Logs devuelve eventos de autenticación, cambios en entidades y acciones de administración de todas las apps del espacio de trabajo, y puede alimentar un SIEM. Hace falta el rol de administrador o propietario y una clave de API del espacio de trabajo. Su documentación no indica cuánto tiempo se conservan los eventos.
Lo que pregunta IT sobre el registro
Ten una respuesta para cada punto antes de la revisión de seguridad.
- Eventos: inicio de sesión, consulta de registros sensibles, cambios, borrados, exportaciones y acciones de administración.
- Quién lo puede leer: una lista corta y con nombres.
- Quién lo puede cambiar o borrar: lo ideal es que nadie que construya o use la app.
- Cuánto tiempo se conserva: y quién lo decide.
- Cómo sale de la app: una exportación programada, una API o un envío a la herramienta de registros que IT ya usa.
- Cuando alguien se va: sus registros pasados se quedan y su acceso termina el mismo día.
Si la app corre en el servidor de la empresa
En el modelo híbrido la app funciona en los servidores del cliente y él sigue construyéndola en Base44. El registro vive entonces en una tabla de SQL Server que IT ya incluye en sus copias, y los permisos de la base de datos deciden quién puede leerlo. La app debería poder insertar filas, pero no editarlas ni borrarlas. El inicio de sesión de empresa con Entra ID añade los registros de acceso propios de Entra, que quien edita la app no puede tocar. Cómo funciona está en las guías de cómo llevar una app de Base44 a tu servidor y de salir de Base44 o seguir diseñando en él.
En los servidores del cliente, el registro está en la base de datos y el plan de copias que IT ya gestiona.
Probado en laboratorio del 6 al 8 de octubre de 2026: Windows Server 2025, IIS, SQL Server y un tenant gratuito de Entra ID, con una app de demostración creada en Base44. La sincronización y el inicio de sesión de empresa funcionaron. La tabla AuditLog, el permiso de solo insertar y el mensaje de arriba son diseño, aún sin probar en el laboratorio. Si encaja con tu app se confirma en el Diagnóstico.
Cuándo Keep44 no es la respuesta: si tu espacio de trabajo ya tiene plan Enterprise, usa la API de Audit Logs. Si la app es pequeña y no guarda nada sensible, la entidad de arriba basta por sí sola.
Fuentes
- Base44: Audit Logs API overview (espacio de trabajo Enterprise, clave de API, tipos de evento). Consultado el 22/10/2026.
- Base44: Security overview (la seguridad de cada app es de quien la crea). Consultado el 8/10/2026.
- Base44: Privacy and security (SOC 2 Type II de la plataforma). Consultado el 21/10/2026.
- Tablero de feedback de Base44: auth event webhooks (petición de eventos de login y logout). Consultado el 21/10/2026.