← Volver al listado de tecnologías ← Índice de Los 12 Factores (12factor.net)

15. Auditoría con un agente LLM

4 de julio de 2026 Por: Artiko

12factortwelve-factorauditoriallmagentecloud-native

15. Auditoría con un agente LLM

El capítulo de cierre propone recorrer manualmente la tabla de los 12 factores marcando cumple / no cumple / parcial. Este capítulo automatiza ese ejercicio: convierte el checklist en un briefing ejecutable que le pasas a un agente LLM con acceso a tu repositorio para que audite la aplicación factor por factor, con evidencia del código real y un plan de remediación priorizado.

La diferencia con una revisión de ojo es que el agente no dice “parece stateless”: busca en el código dónde se guarda el estado de sesión, si hay sticky sessions en el balanceador, o si un archivo se escribe en disco local esperando persistir entre requests — y lo respalda con archivo y línea.

Cómo usar este capítulo

Abre una sesión limpia de tu agente en la raíz del proyecto a auditar.
Copia el bloque “Briefing para el agente” completo y pégalo como primer mensaje.
El agente ejecuta las cuatro fases y devuelve un informe factor por factor.
Regla de oro: el agente audita y reporta; no modifica nada sin aprobar antes el plan.

flowchart LR
    A[Reconocimiento] --> B[Diagnóstico<br/>12 factores]
    B --> C[Plan priorizado]
    C --> D[Reporte con<br/>evidencia]
    D -.aprobación.-> E[Remediación]

Escala de evaluación

Estado	Significado
CUMPLE	El factor se respeta y hay evidencia verificable en el código o la configuración
PARCIAL	Se respeta a medias: funciona pero con excepciones, o depende de disciplina manual
NO CUMPLE	El factor se viola de forma clara y verificable
N/A	No aplica a este tipo de aplicación (debe justificarse)

Los 12 factores no son igual de urgentes: el briefing pide priorizar por impacto operacional. Config hardcodeada (III) y estado en proceso (VI) rompen despliegues y escalado ya; los demás degradan mantenibilidad.

Briefing para el agente

Copia todo lo que sigue en este bloque y pégalo a tu agente.

# MISIÓN: Auditoría Twelve-Factor App

Eres un auditor de arquitectura cloud-native. Tu misión es determinar si ESTA
aplicación cumple los 12 factores (12factor.net): una metodología para que una app
sea portable entre entornos, escalable horizontalmente y con mínima brecha dev/prod.

REGLA DE ORO: NO modifiques ningún archivo. Solo lees, diagnosticas y reportas.
Toda remediación se propone como plan y espera mi aprobación explícita.

## FASE 1 — Reconocimiento

Lee, sin implementar nada:

- README y documentación de arranque/despliegue
- Manifiesto de dependencias y su lock file (package.json + lock, go.mod, etc.)
- Dockerfile, docker-compose.yml, Procfile
- Manifiestos de despliegue (k8s, Helm, Terraform, PaaS config)
- Archivos de configuración y entorno (.env*, config/, settings)
- Código de arranque del proceso (entrypoint, main, server bootstrap)
- Manejo de logs (dónde escribe la app) y de señales (SIGTERM)
- Scripts de migración / tareas administrativas

Resume en 5-8 líneas: lenguaje, framework, cómo arranca, cómo se despliega,
qué backing services usa y cómo se escala.

## FASE 2 — Diagnóstico factor por factor

Para CADA factor responde con este formato exacto:

  - **[N] Factor**: CUMPLE | PARCIAL | NO CUMPLE | N/A — impacto
    - Evidencia: `ruta/archivo.ext:línea` (cita el fragmento)
    - Nota: por qué ese veredicto

### I. Código base
Un repo por app, múltiples despliegues. ¿Hay un solo repo? ¿Monorepo con varias
apps que en realidad son una? ¿Código compartido copiado en vez de dependencia?

### II. Dependencias
Declaración explícita + aislamiento. ¿Existe manifiesto Y lock file? ¿El código
asume binarios del sistema no declarados (curl, imagemagick, ffmpeg)?
¿Se usa un entorno aislado (venv, node_modules, vendoring)?

### III. Configuración
Todo lo que varía entre entornos en variables de entorno. TEST DEL OPEN SOURCE:
¿podrías hacer público el repo AHORA sin filtrar credenciales? Busca hosts, URLs,
claves, passwords hardcodeados o en archivos versionados. .env NO debe estar en git.

### IV. Backing services
DB, cola, cache, SMTP, APIs externas tratados como recursos conectables vía URL/
credencial. ¿Se puede cambiar de una DB local a una gestionada tocando SOLO la
config, sin cambiar código? ¿Hay hosts de servicios hardcodeados?

### V. Build, release, run
Tres etapas separadas y estrictas. ¿La build produce un artefacto inmutable?
¿El release combina build + config con un ID único? ¿Se puede hacer rollback?
¿Se muta el código en el servidor en runtime (mala señal)?

### VI. Procesos
Stateless y share-nothing. ¿El estado de sesión vive en el proceso (memoria/disco
local) o en un backing service (Redis, DB)? Busca sticky sessions en el balanceador,
uploads guardados en disco local, cachés en memoria que asumen un solo proceso.

### VII. Asignación de puertos
La app se autocontiene y expone HTTP por sí misma vía port binding. ¿Depende de
inyección en un servidor externo (Apache mod_php, un contenedor de servlets) o
arranca su propio servidor y escucha en un PORT configurable?

### VIII. Concurrencia
Escalar via el modelo de procesos. ¿Hay tipos de proceso distintos (web, worker,
cron) escalables por separado? ¿O todo corre en un proceso monolítico que no se
puede replicar horizontalmente?

### IX. Desechabilidad
Arranque rápido y apagado elegante. ¿La app maneja SIGTERM para terminar requests
en curso y cerrar conexiones? ¿El arranque tarda segundos o minutos? ¿Los jobs son
idempotentes / reencolables si el worker muere?

### X. Paridad dev/prod
Cerrar las brechas de tiempo, personal y herramientas. ¿Dev y prod usan el MISMO
tipo y versión de backing services (misma DB, no SQLite en dev y Postgres en prod)?
¿Docker/compose replican prod localmente?

### XI. Logs
Logs como flujo de eventos a stdout, sin que la app gestione archivos. ¿La app
escribe a stdout/stderr, o abre y rota sus propios archivos de log? ¿Asume rutas
de log específicas?

### XII. Administración de procesos
Tareas one-off (migraciones, scripts) en el MISMO entorno y release que la app,
con el mismo código y config. ¿Las migraciones corren desde el mismo artefacto?
¿O hay scripts sueltos que se corren manualmente en otra máquina?

## FASE 3 — Plan priorizado

Ordena SOLO los factores PARCIAL y NO CUMPLE:

  ### ALTO IMPACTO (rompe despliegue o escalado)
  - [ ] [N] Factor — archivo — remediación en una línea
  ### MEDIO
  - [ ] ...
  ### BAJO
  - [ ] ...

Prioridad sugerida: Config (III) y Procesos/estado (VI) primero, luego backing
services (IV) y paridad (X), luego el resto.

## FASE 4 — Reporte

Entrega:
1. Tabla resumen: factor | estado | impacto
2. Score: nº de CUMPLE / total aplicable (excluye N/A)
3. Las 3 violaciones más costosas con su evidencia
4. El plan priorizado de la Fase 3

Espera mi aprobación antes de tocar cualquier archivo.

Qué evidencia debe buscar el agente (guía rápida)

Estas son las señales concretas que delatan cada violación. Sirven también para revisar críticamente el reporte del agente:

Factor	Dónde mirar	Señal de NO CUMPLE
III Config	código + `.gitignore`	`db_password = "..."`, URLs de prod hardcodeadas, `.env` versionado
IV Backing services	config de conexión	`host = "localhost"` fijo, driver acoplado por `if entorno == ...`
V Build/release/run	Dockerfile, CI	`git pull` en el servidor, config horneada dentro de la build
VI Procesos	manejo de sesión	sesión en memoria, `express-session` sin store externo, uploads a disco local
VII Puertos	bootstrap	depende de un servidor externo; puerto hardcodeado en vez de `PORT`
VIII Concurrencia	Procfile / manifests	un solo tipo de proceso; workers dentro del proceso web (threads)
IX Desechabilidad	entrypoint	sin handler de `SIGTERM`; arranque que precalienta cachés lentos
X Paridad	dev vs prod config	SQLite en dev / Postgres en prod; versiones distintas de la DB
XI Logs	logger config	`winston`/`logback` escribiendo a archivo; rotación propia de logs
XII Admin	scripts	migraciones en un repo aparte o corridas a mano en otra máquina

El test del open source (Factor III) es la prueba más rápida y reveladora: pídele al agente que responda, sí o no, si el repo podría hacerse público ahora mismo sin filtrar un solo secreto. Si la respuesta es “no”, ya tienes tu primera violación crítica — y debe revisar también el historial de git, no solo el árbol actual.

Formato de reporte esperado

## Auditoría Twelve-Factor — mi-app

**Score: 8 / 12 factores**

| # | Factor | Estado | Impacto |
|---|--------|--------|---------|
| III | Configuración | NO CUMPLE | ALTO |
| VI | Procesos | PARCIAL | ALTO |
| XI | Logs | NO CUMPLE | MEDIO |
| ... | ... | ... | ... |

### Violaciones más costosas
1. **VI** — `src/session.js:22` guarda sesiones en memoria; con >1 réplica el
   login se pierde entre requests. Requiere sticky sessions (antipatrón).
2. **III** — `config/database.yml:8` tiene la contraseña de producción en claro.
3. **XI** — `logger.js:10` escribe a `/var/log/app.log` en vez de stdout.

Auditoría continua

Igual que con seguridad, algunas violaciones se pueden atrapar automáticamente en CI, sin esperar una auditoría con agente:

Config (III): gitleaks para secretos + un test que verifique que la app arranca leyendo todo de variables de entorno.
Build inmutable (V): que el pipeline construya una imagen con tag por commit/digest, nunca latest.
Paridad (X): docker-compose que levante los mismos backing services que producción, usado tanto en dev como en los tests de integración.

El agente cubre lo que ningún linter modela —estado en proceso, sticky sessions, migraciones corridas a mano— y el CI evita las regresiones conocidas commit a commit.

Cierre

Con este briefing, la autoevaluación de los 12 factores deja de ser un ejercicio de pizarra y se vuelve un diagnóstico repetible sobre el código real. El agente recorre el repositorio, encuentra la evidencia de cada factor y entrega un plan priorizado por impacto operacional. El criterio final —qué violación duele más en tu contexto— sigue siendo humano, pero el trabajo pesado de rastrear la evidencia lo hace el agente.

Recursos

Aplicación práctica y cierre — el checklist que el briefing recorre
Manifiesto original en español: 12factor.net/es
Tutorial complementario: OWASP Secure by Default — Auditoría con un agente LLM