Saltar al contenido
Todos los artículos

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.

0/12 listo

Tus tres próximos pasos

  1. El código vive en Git; los cambios pasan por pull requests
  2. Ninguna clave secreta en el frontend; las del servidor, solo en el servidor
  3. Seguridad a nivel de fila (o equivalente) en cada tabla
Pedir una revisión de preparación
Todas las calculadoras y checklists

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.

Del prototipo a producción: cada cambio pasa por Git, CI y staging; las copias se demuestran cada noche; las comprobaciones sintéticas vigilan lo que hacen los clientes.
Arquitectura de entrega del prototipo con IA a producción: un generador de apps con IA sube a GitHub, la CI ejecuta tests y una prueba de migraciones, los cambios pasan a staging y luego a producción en Vercel con Supabase y row-level security, los secretos llegan por OIDC, las copias van a un object store con restauración nocturna de prueba y comprobaciones sintéticas vigilan la web en directo.

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.

sql
-- 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.

Advanced Row Level Security (RLS) Policies // Authorization Deep Dive, Supabase (YouTube). Se carga desde YouTube solo cuando haces clic.

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.

bash
# 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.

yaml
# .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.

Más artículos

    Hablemos

    Cuéntame qué estás construyendo; te respondo en 1 o 2 días laborables.

    Dominik Heinrich
    Empresa
    MADO Consulting

    Disponible en todo el mundo en remoto. Presencial bajo petición, según el país.

    Te respondo en 1 o 2 días laborables. Huecos libres: mira el calendario

    Abre aquí el calendario de reservas de Calendly. Al cargarlo se envían datos a Calendly (ver aviso legal).