Cómo usar la IA para desplegar a producción rápido y sin sacrificar seguridad

Un asistente de IA puede escribir en minutos la configuración de Docker, el pipeline de CI y los scripts de despliegue que antes me llevaban días. Eso es real. Pero también es real que un despliegue rápido y mal hecho solo te lleva antes al problema.

Hace poco puse en producción un proyecto trabajando con un asistente de IA para programar (en mi caso, Claude Code) y lo desplegué en mi propio servidor. En este artículo comparto el método que me funcionó: la IA acelera, pero las pruebas, los permisos y la verificación los pones tú.

Se habla mucho de la IA que escribe código, pero muy poco de lo que pasa cuando ese código llega a producción. Quería comprobar si era posible ir rápido sin bajar el listón: sin secretos expuestos, sin despliegues a ciegas y sin «ya lo arreglaremos después».

1. Empieza por las reglas, no por el código

El error más común es pedir «hazme un despliegue con Docker». La IA lo hará, pero con sus propias suposiciones. Antes de pedir código, dale las restricciones que no son negociables:

• Nunca poner claves ni tokens en el código, en los logs ni en el navegador.
• No afirmar que algo funciona sin haberlo ejecutado.
• Usar los permisos mínimos para cada servicio.
• Preguntar antes de tocar el servidor, el DNS o cualquier cosa difícil de deshacer.

Un buen asistente las respetará durante todo el trabajo, y te ahorrará discutirlas en cada paso. Cuanto más claro es el marco, menos tienes que corregir después.

2. Pide pruebas, no promesas

La frase más peligrosa de un asistente de IA es «esto debería funcionar». La alternativa es exigir que cada cambio pase por comprobaciones automáticas antes de llegar a producción:

• Comprobación de tipos y lint.
• Pruebas unitarias de la lógica sensible (en mi caso, el formulario de contacto: validación, límites de tamaño, orígenes permitidos).
• Pruebas de extremo a extremo con un navegador real, incluida una revisión automática de accesibilidad.

Estas pruebas no son burocracia: me salvaron varias veces. En una ocasión, un ajuste de seguridad hizo que la web se viera sin ningún estilo en el entorno de desarrollo. Las pruebas de producción pasaban, pero ninguna comprobaba los estilos en desarrollo. La lección: cuando algo se rompe sin que las pruebas lo detecten, la solución incluye añadir la prueba que faltaba.

3. Un pipeline con tres puertas

El flujo final es sencillo de explicar:

git push → 1. Validar → 2. Construir imagen → 3. Desplegar

Cada puerta solo se abre si la anterior pasó. Si falla la validación, no se construye nada y producción sigue intacta. Una versión simplificada del workflow de GitHub Actions:

jobs:
  validate:
    steps:
      - run: npm ci
      - run: npm run check && npm run lint && npm test
      - run: npm run test:e2e

  image:
    needs: validate
    # construye la imagen Docker y la publica en un registro privado

  deploy:
    needs: image
    # se conecta al servidor y despliega exactamente la versión de este commit

Un detalle que marca la diferencia: el despliegue usa la etiqueta del commit (sha-1a2b3c4), no «latest». Así sabes siempre qué versión exacta está en producción y puedes volver a cualquiera.

4. Seguridad: donde la IA más ayuda y donde más hay que vigilar

La IA es muy buena proponiendo medidas de seguridad. Estas son las que considero imprescindibles:

Secretos fuera del código. Las claves viven en el servidor (o en los secrets de GitHub), nunca en el repositorio. El código solo conoce el nombre de la variable.

Permisos mínimos. Cada credencial debe poder hacer una sola cosa. El servidor solo necesita descargar la imagen, así que su token tiene únicamente permiso de lectura de paquetes. En el proceso llegué a tener un token con acceso completo a todos mis repositorios, y la decisión correcta fue no guardarlo en el servidor y crear otro con el permiso justo.

Una clave de despliegue que solo sabe desplegar. GitHub Actions entra al servidor por SSH, pero esa clave está restringida a ejecutar un único script:

command="/opt/app/deploy.sh",restrict ssh-ed25519 AAAA... github-actions-deploy

Aunque esa clave se filtrara, no abriría una terminal: solo permitiría redesplegar la aplicación. Y el script valida lo que recibe, así que un intento como latest; rm -rf / se rechaza sin ejecutarse.

No pegues contraseñas en el chat. Es tentador pasarle al asistente una contraseña o un token «para que lo haga él». Si ocurre, trata esa credencial como comprometida y cámbiala al terminar.

5. Despliega con red de seguridad

Un despliegue automático sin vuelta atrás es una apuesta. El script de despliegue hace esto:

docker compose pull web
docker compose up -d web

if wait_healthy; then
  echo "$TAG" > .deployed-tag        # versión en producción
else
  IMAGE_TAG="$PREVIOUS" docker compose up -d web   # vuelta atrás automática
  exit 1
fi

La clave es el healthcheck: el contenedor tiene que demostrar que responde antes de darse por bueno. No me fié de que funcionara: lo probé desplegando a propósito una versión rota. El script detectó el fallo, volvió solo a la versión anterior y la web no dejó de responder.

6. Lo que la IA no ve (y tú sí)

Algunos de los problemas más difíciles no estaban en el código:

• El DNS. Mi dominio apuntaba a tres servidores distintos (restos de configuraciones antiguas). El navegador elegía uno al azar y el certificado HTTPS no se podía emitir. La IA lo detectó al consultar el DNS, pero la corrección tenía que hacerla yo en el proveedor del dominio.
• La configuración en el sitio equivocado. Las variables estaban creadas en GitHub, pero dentro de un «entorno» que el workflow no leía. Todo parecía configurado y nada funcionaba.
• Lo que ya hay en el servidor. Mi servidor ya tenía otros servicios detrás del mismo proxy. La regla fue: inspeccionar primero, no tocar lo que ya funciona y añadir lo nuevo sin afectar a nada.

En todos los casos, lo que resolvió el problema fue verificar en el entorno real, no suponer.

Lo que más me sorprendió no fue la velocidad escribiendo código, sino dónde aportó más la IA: revisando, inspeccionando y comprobando, más que construyendo. Mi papel cambió: pasé de escribir cada línea a definir las reglas, revisar las decisiones y aprobar lo que llegaba a producción.

Checklist para tu próximo despliegue con IA

• Diste a la IA las reglas de seguridad antes de pedir código.
• Ningún secreto está en el repositorio.
• Cada credencial tiene el permiso mínimo necesario.
• Hay pruebas automáticas que bloquean el despliegue si algo falla.
• El despliegue usa versiones concretas, no solo «latest».
• Existe healthcheck y vuelta atrás automática, y la probaste con una versión rota.
• Verificaste en producción: HTTPS, cabeceras de seguridad y la funcionalidad crítica.
• Cambiaste cualquier credencial que haya pasado por un chat.

Conclusión

La IA me permitió ir mucho más rápido, pero la velocidad vino de combinarla con disciplina: reglas claras, pruebas automáticas, permisos mínimos y verificación en el mundo real. La IA escribe; tú decides qué llega a producción.

Si estás pensando en automatizar el despliegue de tu proyecto o en incorporar IA en tu forma de trabajar, hablemos.