Funciona en mi máquina: los diez controles que separan un prototipo de un sistema en producción

Resumen ejecutivo

1. El prototipo no es producción

Un prototipo generado con IA tiene tres rasgos: es rápido de producir, está validado únicamente para el happy path y arrastra riesgos de seguridad que nadie ha mirado. Producción exige otras tres cosas: sensores de verificación dentro del ciclo, un checklist riguroso antes de publicar y hábitos que prevengan incidentes en vez de repararlos.

La distancia entre ambos estados no es de esfuerzo, es de método. Lo que la separa, dice Pinochet, es la verificación sistemática.

2. La verificación como sensor del bucle

La idea central de la clase es un cambio de lugar, no de herramienta. Las pruebas no van al final, después de que el agente terminó: van dentro del ciclo, funcionando como sensores que evalúan cada iteración.

Tres tipos de sensor cubren lo esencial. Las pruebas automatizadas, unitarias y de integración, validan el comportamiento esperado y los casos límite. Los linters de seguridad detectan malas prácticas y vulnerabilidades conocidas en tiempo real. Los verificadores de tipos —TypeScript o equivalentes— aseguran contratos de datos estrictos. Juntos forman la red que atrapa errores y alucinaciones antes de que lleguen a producción.

Lo interesante es cómo se cierra el circuito:

La integración con el agente sigue cuatro movimientos: identificar las funciones críticas del sistema (autenticación, pagos), especificar pidiéndole que escriba las pruebas a partir de la spec, ejecutar esas pruebas localmente en cada iteración y validar —no aceptar el código hasta que todas pasen en verde—. Las pruebas automatizadas son, en palabras de la clase, el contrato ejecutable entre el desarrollador y la IA.

Cinco minutos con mentalidad de atacante

Los sensores automáticos no cubren la lógica de negocio. Para eso la clase propone un ejercicio corto y deliberado antes de aprobar cualquier cambio, organizado en tres preguntas:

• Vectores de entrada — ¿qué pasa si envío datos maliciosos? Inyecciones, XSS, payloads gigantes, tipos inesperados.
• Flujo de negocio — ¿qué pasa si me salto un paso? Bypass de validaciones, endpoints ejecutados fuera de orden, manipulación de estado.
• Control de acceso — ¿qué pasa si pido datos de otro usuario? IDOR y escalada de privilegios.

Cinco minutos cuestionando el código generado antes de aprobarlo es, según la clase, la defensa con mejor relación coste-beneficio de todo el proceso.

3. El abismo entre desarrollo y producción

La segunda parte de la clase es la más concreta y la que más sorprende a quien nunca ha operado un servicio. El arnés de desarrollo y el de producción no son el mismo entorno con más usuarios: son mundos distintos.

De ahí sale una lista de mínimos que rara vez aparecen en un prototipo:

HTTPS y nada más. Los servicios deben exponer exclusivamente endpoints cifrados, y usar HSTS para forzar conexiones seguras siempre. En producción, HTTP plano equivale a transmitir credenciales, claves y tokens en texto claro.

Identidad de verdad. En desarrollo es habitual el token en duro y la cuenta de administrador por defecto. En producción hacen falta JWT firmados o sesiones con cookies HTTP-only, validación en el backend de si el usuario tiene permiso sobre ese recurso concreto, re-autenticación para acciones sensibles y soporte de MFA. La autenticación demuestra quién eres; la autorización define qué puedes hacer, y confundirlas es el origen de la mayoría de los IDOR.

Errores que no cuenten de más. Un stack trace revela la estructura interna de la aplicación y las versiones de las librerías. Al cliente le corresponde un mensaje genérico y un código HTTP semánticamente correcto; el detalle técnico va al log interno, sanitizado, sin datos personales ni contraseñas.

Límites de consumo. Es el riesgo Unrestricted Resource Consumption del OWASP API Security Top 10 (API4:2023): sin límites, alguien puede agotar CPU, memoria o presupuesto. Hacen falta rate limiting por IP o usuario, tamaño máximo de payload y alertas de gasto en servicios de terceros para evitar facturas sorpresa. Un endpoint sin límites es un cheque en blanco.

Resiliencia. La infraestructura falla: las bases de datos caen, las redes se desconectan, los servidores se reinician. Diseñar para el fallo significa reintentos con backoff exponencial, circuit breakers y respaldos automatizados, de modo que el sistema se recupere o se degrade con gracia sin perder datos.

Dependencias vivas. El código propio es la punta del iceberg. El análisis de composición (SCA) detecta CVE conocidos en las librerías, y el pipeline debe detener el despliegue si aparece una vulnerabilidad crítica. El mantenimiento no termina con el despliegue: los atacantes explotan fallos públicos rápido.

4. El checklist: diez controles antes de publicar

El argumento a favor del checklist no es burocrático, es cognitivo. Depender de la memoria produce olvidos bajo presión, el supuesto de que «alguien más lo revisó» e inconsistencia entre despliegues. Un checklist reduce la carga mental, ofrece un criterio objetivo de aprobación y deja historial auditable.

El checklist solo sirve si se ejecuta siempre, y por eso vive en el pipeline: pruebas, linters y análisis estático corriendo en cada commit o pull request, con reportes que dejan historial. Pero la pieza que le da fuerza es la última:

5. Los hábitos: gobernanza personal

La última parte de la clase es la que decide si todo lo anterior sobrevive al segundo mes. La seguridad como evento aislado —una auditoría antes del lanzamiento— produce correcciones masivas y dolorosas y depende de la memoria de alguien. Como hábito diario, es parte del flujo.

Reutilizar el contexto. Reescribir las reglas de seguridad en cada prompt es ineficiente y se olvida. Un archivo de reglas persistentes en la raíz del repositorio —AGENT.md o equivalente— mantiene las políticas globales, asegura que el agente use siempre las mismas librerías y evite los mismos antipatrones, y se actualiza a medida que el equipo aprende de sus errores. Es, literalmente, la memoria institucional del equipo.

Mantener lo que ya funciona. Las vulnerabilidades en dependencias se descubren todos los días. Herramientas como Dependabot o Renovate abren las actualizaciones automáticamente, y la suite de pruebas confirma que no rompen nada. El código seguro de hoy puede ser vulnerable mañana.

Revisar en pequeño. Auditar bloques masivos de código generado es agotador y propenso a errores. Revisar iteración por iteración, con el alcance de una sola funcionalidad, hace la tarea realista: detectar una alucinación en cincuenta líneas es factible; en quinientas, es una ilusión.

No relajar el arnés. La tentación aparece siempre con la misma excusa —«es solo un prototipo», «hay prisa»— y consiste en desactivar linters o ignorar pruebas que fallan. Pero el código generado sin validación es una caja negra: relajar los sensores es exactamente lo que permite que una alucinación llegue a producción. La regla no admite matices: si no pasa las pruebas, no se despliega.

Saber cuándo llamar a alguien. La IA escala el desarrollo y detecta patrones comunes, pero carece de intuición y de contexto sistémico. En pagos, criptografía o autenticación central, la revisión humana experta no es opcional; y reconocer cuándo un problema de arquitectura supera al equipo es parte del oficio. La IA no reemplaza a un profesional de seguridad: lo libera para concentrarse en lo complejo.

6. Conclusiones

La clase cierra recapitulando el trío que sostiene todo el curso. La spec define el qué: el contrato, las restricciones y los criterios de aceptación. El bucle define el cómo: iteración continua en pasos pequeños. El arnés aporta la validación: sensores que verifican en tiempo real. La combinación de los tres es lo que transforma la velocidad de la IA en software confiable; cualquiera de los tres por separado produce prototipos.

Tres ideas para llevarse. Primera: la verificación va dentro del bucle, no después —un error que vuelve al agente como texto exacto se corrige solo; un error que descubre un usuario, no—. Segunda: el checklist debe poder bloquear, porque una lista de buenas intenciones que no detiene nada no es un control. Tercera: publicar es un acto de responsabilidad, y esa responsabilidad se ejerce con hábitos, no con esfuerzos heroicos la noche antes del lanzamiento.

Referencias

• Pinochet Maturana, R. (2026). Del prototipo a producción: verificación en el loop, checklist y hábitos [presentación]. Clase 5 del curso FVCS-101, Comunidad IA LATAM × 8.8 Academy.
• OWASP Foundation. OWASP API Security Top 10 — API4:2023 Unrestricted Resource Consumption.
• OWASP Foundation. Transport Layer Security Cheat Sheet — base de la exigencia de HTTPS y HSTS citada en clase.
• Herramientas mencionadas: OWASP Dependency-Check, Snyk, Dependabot y Renovate para el mantenimiento continuo de dependencias.

Autoría

Sr. Rudy Pinochet Maturana — Presidente de ISACA Santiago · Director de Alianzas de Comunidad IA LATAM. Profesional y docente con más de 15 años liderando arquitectura de plataformas, ciberseguridad, auditoría y gestión de riesgos en banca, seguros, retail, telecomunicaciones y energía. Presidente de ISACA Santiago, consultor senior y académico en programas de postgrado en Chile y Latinoamérica. CISM, CDPSE, CEH, CHFI.

Artículo elaborado por Comunidad IA LATAM a partir de la presentación y la grabación de la clase. Las cinco clases del curso están abiertas en Academy IA LATAM.