Del prototipo con IA a producción: las ocho capas que añado, en este orden
Los generadores de apps como Lovable, Bolt o v0 te dan un producto que funciona en pocos días. Luego llegan clientes reales, pagos y datos personales, y el prototipo empieza a parecer frágil: un cambio pequeño rompe el checkout, nadie sabe si las copias de seguridad funcionan y la IA que lo construyó sigue reescribiendo cosas. El consejo habitual es reescribirlo. Yo he llevado dos prototipos así a producción sin reescribirlos. Estas son las capas que añado, en este orden, y por qué el orden importa.
Actualizado 11 min de lectura
1. Hacer inventario en una tarde
Exporta el código a GitHub si aún no está allí y anota lo que hace realmente la app: registro e inicio de sesión, pagos, correos, subida de archivos, pantallas de administración, tareas programadas, llamadas a IA. Marca todo lo que toque dinero o datos personales. Esa lista es tu mapa de riesgos, y suele ser más corta y más clara de lo que se teme.
Después comprueba dónde están los secretos. En las apps generadas suelen acabar en el código del frontend, en un archivo .env compartido o en el historial del chat con el generador. Mira también la base de datos: qué tablas hay, cuáles no tienen políticas de acceso y qué columnas contienen datos personales. La comprobación de madurez de abajo convierte esta tarde en una puntuación, para ver de un vistazo por dónde empezar y mostrar el progreso después.
Consejo práctico
Busca en el bundle de JavaScript compilado tu clave de service role o el secreto de pagos. Si aparece, rótala hoy, antes que cualquier otra cosa de esta lista.
Interactivo
¿Tu app hecha con IA está lista para producción?
Marca lo que ya se cumple. Lo que queda es tu lista de tareas, en orden.
Tus tres próximos pasos
- El código vive en Git; los cambios pasan por pull requests
- Ninguna clave secreta en el frontend; las del servidor, solo en el servidor
- Seguridad a nivel de fila (o equivalente) en cada tabla
2. Separar staging y producción
Dos entornos con su propia base de datos, sus propias claves y sus propias cuentas de terceros en modo prueba. Cada cambio pasa primero por staging, migraciones de base de datos incluidas, y a producción no llega nada que no haya funcionado allí. Con Supabase, un segundo proyecto o el branching te dan una base de datos de staging; en Vercel, los preview deployments dan a cada pull request su propia URL para probarla.
Este único paso elimina la mayoría de los momentos de 'se rompió en la web en directo', porque el generador de IA y los desarrolladores tienen por fin un sitio donde equivocarse sin riesgo. Mantén staging parecido a producción: misma configuración, mismas extensiones, datos realistas pero anonimizados. Un staging que se aleja se convierte en un lugar donde todo funciona y nada demuestra nada. La checklist de producción de Supabase es una buena compañera aquí: repasa los ajustes que separan un proyecto de pruebas de uno en directo, desde las restricciones de red hasta el proveedor de correo.
3. Blindar quién puede leer qué
El código generado suele confiar en el navegador: el frontend oculta un botón y da por hecho que eso es seguridad. En producción tiene que imponerlo la base de datos, porque cualquiera puede llamar a tu API sin tu frontend. Activa row-level security en cada tabla, escribe políticas por rol y repite las comprobaciones críticas en funciones del servidor. El control de acceso roto lleva años en lo más alto del OWASP Top 10, y las apps hechas con IA no son una excepción.
Después escribe un test por rol que intente leer y escribir datos que no le corresponden: las facturas de otra organización, un ajuste de administración, los registros de un usuario borrado. Estos tests cuestan poco de escribir y valen oro cuando la IA cambia una política sin avisar. En una plataforma esto supuso políticas en todas las tablas y una batería de tests de más de mil archivos, y esa batería es lo que permite al equipo seguir publicando rápido.
-- Members only see invoices of their own organisation
alter table invoices enable row level security;
create policy "members read own org invoices"
on invoices for select
using (
org_id in (
select org_id from memberships
where user_id = auth.uid()
)
);Consejo práctico
Una política sin probar es una suposición. En tus tests, inicia sesión con cada rol e intenta leer datos de otra organización; el test pasa solo si la base de datos dice que no.
4. Copias de seguridad ya restauradas
Las copias del proveedor de hosting son un comienzo, no un plan. Si te bloquean la cuenta, cae la región o alguien borra el proyecto, esas copias desaparecen con él. Añade volcados cifrados programados, guardados en otro proveedor, y restaura uno cada noche en un proyecto aparte comprobando que el número de filas coincide. Los archivos subidos necesitan lo mismo: réplica en un segundo object store.
Los pilares de fiabilidad de los Well-Architected Frameworks de Azure y AWS hacen la misma pregunta incómoda: ¿cuándo probaste por última vez una restauración? En las plataformas de producción que opero, la prueba de restauración se ejecuta cada noche, y es la única razón por la que puedo decir que las copias funcionan. Una copia que nunca has restaurado es una esperanza, no un plan, y no quieres descubrirlo en mitad de un incidente.
# Nightly: dump, encrypt, ship to another provider, prove it restores
pg_dump "$PROD_DB_URL" --format=custom --file=prod.dump
age -r "$BACKUP_PUBKEY" -o prod.dump.age prod.dump
aws s3 cp prod.dump.age "s3://backups-offsite/$(date +%F)/" \
--endpoint-url "$OFFSITE_S3_ENDPOINT"
pg_restore --clean --if-exists --no-owner -d "$RESTORE_TEST_DB_URL" prod.dump
psql "$RESTORE_TEST_DB_URL" -c "select count(*) from public.bookings;"5. Un pipeline de release que sabe decir que no
Solo pull requests, nada de pushes directos a main, tampoco para la IA. La CI comprueba tipos, pasa el linter con una línea base que solo puede mejorar, ejecuta tests unitarios y prueba las migraciones de base de datos contra staging antes de fusionar nada. Una migración que falla en staging a las tres de la tarde es un aprendizaje; la misma migración fallando en producción a las tres de la madrugada es un incidente.
Tras la fusión, despliega solo lo que ha cambiado y lanza un smoke test contra la web en directo: ¿alguien puede registrarse, entrar y llegar al checkout? Si no, revierte automáticamente o con un clic. Los pasos pequeños y reversibles suman más rápido que los grandes y cuidadosos: una plataforma fusionó así 3.025 pull requests en diez meses, y el pipeline es lo que hizo seguro ese ritmo.
# .github/workflows/ci.yml (excerpt)
on: pull_request
jobs:
check:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with: { node-version: 22 }
- uses: supabase/setup-cli@v1
- run: npm ci
- run: npm run typecheck && npm run lint && npm test
- name: Migration dry run against staging
run: supabase db push --dry-run --db-url "$STAGING_DB_URL"
env:
STAGING_DB_URL: ${{ secrets.STAGING_DB_URL }}6. Vigilar lo que hacen de verdad los clientes
Las gráficas de CPU no te dicen que nadie ha podido reservar desde mediodía. El libro de SRE de Google lo resume así: vigila los síntomas que notan los usuarios, no solo las causas. Añade comprobaciones desde fuera sobre los recorridos importantes, registro, checkout y reserva, cada pocos minutos y desde fuera de tu hosting, para enterarte de un flujo roto antes de que te escriba un cliente.
Después vigila estados de negocio, no solo técnicos. 'Pago correcto pero sin reserva creada' y 'ninguna reserva en seis horas un día laborable' son las alertas que cazan los fallos caros. En una plataforma eso supuso sondas cada hora sobre el embudo de reservas, un pago sintético diario y una alerta de sequía de reservas. Alerta solo en los cambios de estado, abierta y resuelta, para que la gente siga leyendo las alertas en vez de silenciar el canal.
Consejo práctico
Haz un pago sintético al día por el checkout real en modo prueba. Detecta webhooks rotos mucho antes que un cliente.
7. Secretos y accesos sin claves de larga duración
Saca los secretos del código, de los historiales de chat y de los portátiles de la gente. Cada entorno tiene sus propios secretos en el almacén de secretos de la plataforma. La CI se autentica en tu nube con OpenID Connect en vez de con claves guardadas, así que en GitHub no hay ninguna credencial de larga duración que pueda filtrarse. Las claves de service role se quedan en el servidor y nunca llegan al navegador.
El acceso de las personas sigue la misma idea. Cada uno tiene su propia cuenta con los permisos mínimos que necesita, los administradores usan autenticación multifactor y los accesos se retiran el día en que alguien se va. Apúntalo en una matriz de accesos de una página: quién puede desplegar, quién puede leer datos de producción, quién puede cambiar la facturación. Lleva una hora y responde a las primeras preguntas de cualquier cuestionario de seguridad que te envíe un cliente. Revísala cada trimestre; los accesos que nadie mira solo crecen.
8. Reglas para la IA que sigue construyendo
El agente de código que construyó el prototipo lo seguirá cambiando, así que dale reglas, igual que harías al incorporar a un desarrollador nuevo. Un archivo de instrucciones escrito en el repositorio dice qué puede tocar y qué no, qué comandos debe ejecutar antes de un pull request y qué áreas necesitan siempre a una persona: inicio de sesión, pagos, borrado de datos, políticas de acceso.
Mantén sus pull requests pequeños y haz que demuestre su trabajo. Una comprobación de los recorridos principales en un navegador real antes de cada release, una captura o un resultado de test en cada pull request que cambie un flujo de usuario y una aprobación humana para las áreas sensibles. El agente conserva su velocidad; el pipeline, los tests y la revisión mantienen segura la producción. De eso se trata: el ritmo de un producto hecho con IA con la fiabilidad que los clientes esperan de uno de verdad.
Consejo práctico
Que el agente lo demuestre: ningún pull request que toque un recorrido de usuario se fusiona sin un resultado de test en navegador o una captura.
Conclusión
Conserva la velocidad del prototipo y añade la seguridad de producción por capas. No necesitas reescribir; necesitas estos ocho pasos, en este orden.
Proyectos reales relacionados
Pruébalo tú mismo
Fuentes y guías oficiales
Más artículos
- 3.025 pull requests en diez meses: un proceso de entrega con IA, desde dentro
- La Ley de IA de la UE para medianas empresas: qué te aplica y desde cuándo
- FinOps para el gasto en IA: tokens, caché, enrutado y presupuestos que aguantan
- Hacer visible una red de restaurantes en las respuestas de la IA: un proyecto GEO paso a paso
- Cómo está hecha esta web: estática donde se puede, en streaming donde hace falta
- Costes de Kubernetes en EKS y GKE: el mismo método, otras palancas
- Una landing zone para empresas medianas, en Terraform o Bicep: las piezas que importan
- El manual de migración de sistemas heredados: oleadas, ejecución en paralelo y recuentos y checksums idénticos
- Seguridad de MCP a fondo: dejar entrar a los asistentes de IA en tu producto sin abrir las puertas
- Monitorizar resultados de negocio: paneles en verde, caja vacía
- Agentes de IA por teléfono: la arquitectura y los tropiezos que ninguna demo enseña
- Pruebas de restauración: un backup que nunca has restaurado es solo una esperanza
- Respuestas de IA en streaming en Azure Static Web Apps: la cabecera que lo retenía todo
- Construir un asistente de IA para WhatsApp de principio a fin: lo que hace falta más allá de la demo
- Sistemas air-gapped: software crítico sin conexión a internet
- IA en producción en AWS: Amazon Bedrock y AgentCore en una configuración privada
- IA en producción con Microsoft Foundry: una configuración de referencia privada para agentes
- /goal, /loop o rutinas: deja de vigilar a tu agente de programación
- Los nuevos planes de Claude: Max, Ultra y lo que significan para los equipos
- OpenAI Codex a finales de 2026: goal mode, dots y cómo blindarlo
- ¿GitHub Copilot, Claude Code o Codex? Cómo elegiría para una empresa
- Fundamentos de GEO: cómo aparecer en las respuestas de la IA
- IA en producción en Google Cloud: de Vertex AI a Gemini Enterprise Agent Platform
- LLM locales en una red air-gapped: IA para tus datos más sensibles
- Quiero ejecutar un LLM local: ¿qué servidor compro?
- MiniMax M3: ¿un modelo puntero que puedes ejecutar tú mismo?
- Investigación de prompts a gran escala con un modelo abierto
- SEO y GEO juntos: una auditoría práctica en 6 pasos
- Dimensionar bien Kubernetes: el método que llevó un clúster de 7 a 4 nodos
- IA privada para datos sensibles: un LLM local que supera la revisión de seguridad
