Cómo elegir el backend de una aplicación creada con IA
Un marco práctico para elegir el backend según los datos, los permisos, los archivos, la recuperación, la portabilidad y el coste, con pruebas antes de lanzar.
Esta traducción no es una nueva auditoría de seguridad. Las fuentes oficiales del original se revisaron el 25 de agosto de 2026. Las funciones, los precios y los límites de los proveedores pueden haber cambiado desde entonces. El marco no se ha validado para todos los presupuestos, regiones ni cambios posteriores de planes.
Para quién sirve este marco
Está pensado para convertir una interfaz generada con IA en una aplicación revisada, con requisitos explícitos de datos, identidad, recuperación y coste. No es adecuado empezar a recopilar datos reales antes de definir el control de acceso, la eliminación, las copias de seguridad y las obligaciones legales.
El backend correcto es el que tu equipo puede proteger, probar, operar, restaurar y abandonar si hace falta; no simplemente el que se genera más rápido.
Árbol de decisión: datos, permisos, escala y salida
Estos escenarios orientan la decisión; no son resultados de pruebas de rendimiento.
- Datos relacionales con propietario: es un buen punto de partida cuando los registros se vinculan a usuarios, organizaciones, facturas o permisos que deben poder inspeccionarse. Escribe el esquema e intenta acceder a datos de otro usuario antes de elegir un proveedor de Postgres gestionado.
- Flujo de documentos que funciona sin conexión: el modelo documental puede simplificar la sincronización, pero las reglas de acceso y la multiplicación de lecturas forman parte del diseño. Simula conflictos, acceso revocado y la pantalla con más lecturas usando un volumen realista de datos.
- Carga de IA muy variable: las llamadas a modelos, las colas y los archivos generados pueden dispararse al margen del tráfico de la base de datos. Un titular sobre un plan gratuito no es un presupuesto. Define límites por usuario, alertas, tiempos máximos de ejecución y una parada manual.
- Sin exportación o restauración probada: la solución no está lista para producción si el equipo no puede recuperar o trasladar su estado crítico. Exporta registros y archivos representativos, restáuralos en otro entorno e identifica las dependencias de identidad o servicios que faltan.
Cuatro criterios que no conviene omitir
- Autenticación y autorización no son lo mismo: iniciar sesión no demuestra que una persona solo pueda leer sus propios registros.
- Guarda las claves privilegiadas en el servidor y revoca y rota cualquier credencial expuesta en prompts, capturas, paquetes del navegador o repositorios.
- Prueba la restauración y la exportación antes de producción. La documentación por sí sola no es un plan de recuperación.
- Calcula el uso normal, los picos y el consumo descontrolado; configura los controles de presupuesto y uso más sólidos disponibles.
1. Enumera las tareas del backend
Anota cada función que espera la interfaz. Un generador puede elegir varios proveedores sin hacerlo evidente. Mantén un registro de arquitectura que indique qué servicio se responsabiliza de cada tarea.
- Registros persistentes y relaciones entre ellos.
- Registro de cuentas y recuperación del acceso.
- Permisos por propietario, rol u organización.
- Subida y descarga de archivos.
- Validación en el servidor y acciones privilegiadas.
- Funciones programadas o activadas por eventos.
- Correo transaccional.
- Pagos y webhooks.
- Búsqueda o recuperación vectorial.
- Registros de auditoría, analítica y eliminación de datos.
2. Dibuja el modelo de datos
Considera un modelo relacional cuando sean centrales las restricciones, las uniones entre tablas, las transacciones y los informes. Un modelo documental encaja cuando los datos se consultan como conjuntos independientes y predominan consultas del cliente conocidas de antemano. Evalúa un backend reactivo cuando las consultas actualizadas en vivo y las funciones del backend sean requisitos esenciales.
Para un portal de clientes, define primero usuarios, organizaciones, membresías, proyectos, mensajes y archivos. Señala la propiedad y qué sucede al eliminar cada elemento. Si el esquema no expresa quién posee un registro, la autorización será frágil.
3. Escribe la matriz de acceso
La autenticación identifica a la persona. La autorización limita lo que esa identidad puede hacer. Define una tabla de permisos antes de elegir su sintaxis. Esta es una matriz de ejemplo para un portal de clientes.
- Leer una página pública: permitido para visitante, cliente, personal y administrador.
- Leer un proyecto: denegado al visitante; el cliente ve los suyos; el personal, los asignados; el administrador, todos con auditoría.
- Subir un archivo: denegado al visitante; el cliente, a su proyecto; el personal, a los asignados; el administrador, a todos con límites.
- Cambiar una membresía: denegado a visitante, cliente y personal; solo un administrador aprobado.
- Eliminar una cuenta: denegado a visitante y personal; el cliente dispone de un proceso para su propia cuenta; el administrador utiliza un proceso de soporte controlado.
Convierte la matriz en políticas RLS, Security Rules o funciones del backend. Prueba cada acción denegada, no solo las permitidas.
4. Decide dónde se ejecuta el código de confianza
Las claves públicas del cliente no equivalen a secretos privilegiados. Algunas plataformas exponen intencionadamente una URL de proyecto y una clave limitada, porque las reglas por fila o documento controlan el acceso. Las credenciales service-role, de administrador o de servicios en la nube pueden eludir esas protecciones y deben permanecer en un servidor o función de confianza.
Revisa el paquete compilado de la interfaz y el historial del repositorio en busca de secretos. Si una clave privilegiada apareció en una conversación con IA, una variable pública, una captura o un commit, revócala y rótala. Borrar la línea visible no basta.
5. Evalúa archivos, correo y APIs externas
Los archivos necesitan validación de tipo, límites de tamaño, autorización, una política frente a malware, retención y un comportamiento definido para las descargas firmadas. El correo necesita un dominio de envío autenticado, consentimiento para marketing, plantillas transaccionales, gestión de rebotes y protección de secretos.
Las APIs externas requieren secretos en el servidor, límites de solicitudes, verificación de webhooks y reglas de reintento. No reutilices una casilla de consentimiento de marketing para justificar mensajes transaccionales o ajenos a ese propósito.
6. Define recuperación y portabilidad
Fija requisitos medibles: pérdida de datos aceptable tras un fallo; tiempo máximo de restauración; frecuencia y retención de copias; quién inicia y verifica la recuperación; formatos de exportación de datos, usuarios de autenticación y archivos; destino del ensayo de migración; y comportamiento al caducar la suscripción o el alojamiento.
Ejecuta una restauración con datos sintéticos. Comprueba cantidades de registros, relaciones, fechas, archivos y permisos. Un ZIP con el código fuente no es una copia de la base de datos.
La documentación de Hostinger Horizons citada por el original, revisada el 2026-08-25, indicaba que el backend integrado no tenía una herramienta de exportación directa de datos, aunque el código del proyecto podía exportarse por separado. Es una limitación susceptible de cambiar: verifica la documentación vigente antes de decidir.
7. Calcula costes y umbrales de fallo
Estima tres escenarios: prototipo con desarrolladores y datos de prueba; uso esperado con usuarios y actividad media; y estrés por un pico de tráfico, un bucle o una clave comprometida. Incluye operaciones de base de datos, cómputo, almacenamiento, historial, transferencia saliente, funciones, método de autenticación, correo y registros.
Averigua si el proveedor ofrece una alerta, un límite flexible o una desactivación efectiva. No son equivalentes. El original cita límites de aviso y desactivación por despliegue en Convex, controles de autoescalado máximo y reducción a cero en Neon, y presupuestos y alertas en Firebase y otras nubes. Una alerta de presupuesto puede no detener el gasto automáticamente. Comprueba el comportamiento exacto y actual.
8. Compara el modelo operativo
Utiliza esta lista con criterio, no como una clasificación universal.
- Supabase: Postgres con autenticación y almacenamiento integrados; requiere políticas RLS probadas.
- Firebase: ecosistema documental y en tiempo real conectado a servicios de Google; exige Security Rules y disciplina de facturación.
- Appwrite: backend empaquetado con opciones de nube y alojamiento propio; requiere planificar límites de nube o asumir la infraestructura.
- Neon: Postgres sin servidor como especialidad; complétalo con autenticación, archivos y funciones adecuados.
- Convex: base de datos reactiva y funciones TypeScript; entiende su modelo de datos y cómo mide los recursos.
- Backend integrado en un constructor: menos configuración inicial, pero revisa la exportación, el control y el ciclo de vida antes de guardar datos importantes.
9. Construye un flujo completo y reducido
Implementa una función estrecha de principio a fin: registrarse, crear un registro, mostrarlo solo al usuario correcto, actualizarlo y eliminarlo. Añade registro de actividad y recuperación. Amplía el modelo de datos únicamente cuando esta prueba pase.
- Llamadas directas a la API sin usar la interfaz.
- Identificadores de usuario y registro modificados.
- Dos cuentas simultáneas.
- Credenciales caducadas.
- Datos de entrada inválidos o demasiado grandes.
- Reintentos de red y envíos duplicados.
- Agotamiento del límite del proveedor.
- Restauración de la copia de seguridad.
10. Documenta la responsabilidad
Registra quién controla la cuenta del proveedor, la facturación, el dominio, el remitente de correo, las copias, las actualizaciones de seguridad y la respuesta a incidentes. Usa un gestor de contraseñas y un sistema de secretos aprobados. El proyecto de un cliente no debería depender permanentemente de la cuenta personal de un profesional independiente.
Errores frecuentes
- Permitir lectura y escritura públicas solo para que funcione una demo.
- Enviar una clave service-role al navegador.
- Asignar el mismo rol a todas las cuentas.
- Recopilar campos sin una finalidad de retención.
- Suponer que una migración generada por IA es reversible.
- Activar pago por consumo sin alertas ni límites.
- Llamar copia completa a una exportación de código.
- Lanzar sin probar eliminación y recuperación.
Preguntas frecuentes
¿Debo usar el backend elegido por el constructor con IA?
Solo si cumple una lista escrita de requisitos de arquitectura y salida. Entiende su autorización, copias, exportación, facturación y ciclo de alojamiento antes de aceptarlo.
¿La autenticación basta para proteger los datos?
No. Identifica al usuario; la autorización restringe sus acciones y registros. Ambas requieren pruebas de solicitudes que deben ser rechazadas.
¿Puedo incluir una clave de Supabase o Firebase en el frontend?
Únicamente la configuración pública del cliente autorizada por su documentación y con reglas de acceso correctas. Nunca expongas credenciales service-role, de administrador o de cuenta de servicio.
¿Qué backend es más fácil de migrar?
Una base estándar como Postgres puede mejorar la portabilidad de los datos. Aun así, autenticación, archivos, funciones y comportamientos propios del proveedor necesitan un plan de migración probado.
¿Este consejo equivale a una auditoría de seguridad?
No. Traduce un marco de planificación basado en documentación oficial revisada el 2026-08-25. Un sistema real necesita una revisión de seguridad y legal específica para su implementación.
Fuentes
Estas son las fuentes oficiales del artículo original. Muchas de sus páginas están en inglés.