La otra cara de la IA: lo que hizo con dos servidores de producción

Hoy empezamos con una pregunta simple: «salieron varias vulnerabilidades en las últimas semanas, ¿alguna nos afecta?». Dos VPS de producción, 88 contenedores, clientes reales corriendo arriba. Y **cero personas dedicadas a seguridad**. Ocho horas después: 114 parches aplicados, dos kernels puestos al día tras 37 versiones de atraso, 72 imágenes escaneadas, y un CVE de severidad 9.8 identificado como imposible de parchear todavía.

Este artículo no es sobre lo que la IA puede hacer. Es sobre lo que hizo, con números que puedo mostrar, y sobre las cuatro veces que se equivocó en el camino. Porque de eso casi nadie escribe.

1. Lo que había (y nadie estaba mirando)

El punto de partida no era dramático. Era peor: era normal. Nadie había hecho nada mal; simplemente nadie había tenido tiempo de mirar.

Dimensión	Hetzner (producción)	Oracle (servicios internos)
Parches pendientes	78 paquetes	36 paquetes
Kernel en ejecución	6.8.0-110 — 37 versiones detrás del instalado	6.8.0-1047 — 15 versiones detrás
Reboot pendiente	21 días	42 días
Contenedores	57	31
Imágenes escaneadas alguna vez	Ninguna. 72 sin inventario de CVEs.

Hay un detalle que resume todo: unattended-upgrades estaba activo y corriendo todos los días. Su log decía, textual: «No packages found that can be upgraded unattended». Era cierto —para los repos de Ubuntu—. Pero no cubre el repositorio de Docker ni los phased updates, así que llevaba un año reportando salud mientras el kernel acumulaba 37 versiones.

2. El CVE que no se podía parchear

El hallazgo más serio no fue una lista de parches: fue CVE-2026-98432, severidad 9.8, prioridad crítica en Ubuntu. Un use-after-free en el manejo de conexiones IPv4 del kernel, con potencial de ejecución remota de código. Publicado el 15 de octubre. Actualizado hoy.

Acá es donde un agente se vuelve distinto de un buscador. No bastaba con leer la noticia: había que responder ¿nos toca? y ¿qué hacemos?. La verificación fue contra el tracker de CVEs de Ubuntu, consultando el estado por paquete y release:

Release	Versión con el fix	Estado
Ubuntu 24.04 (noble) — linux	6.8.0-149.149	pending
Ubuntu 22.04 (jammy) — linux-oracle-6.8	6.8.0-1067.71~22.04.1	pending

pending significa una sola cosa: el parche no existe todavía en el repositorio. No es que no lo hayamos aplicado; es que Canonical aún no lo publicó. Debian sí lo tiene. Nosotros no.

La conclusión correcta en ese momento no era entrar en pánico ni ignorarlo. Era: no se puede parchear, se puede mitigar, y hay que instrumentar la espera. Se verificó net.ipv4.tcp_migrate_req=0 (cierra una de las dos rutas del fallo), se redujo la superficie expuesta y se dejó marcado el monitoreo de las versiones 149 y 1067.

3. Lo que sí se cerró

El resto sí tenía solución, y era mecánica. En una sesión:

• 78 → 0 paquetes pendientes en Hetzner. 36 → 3 en Oracle (los 3 restantes no son de seguridad: netplan y fwupd, deliberadamente diferidos porque un cambio de red en remoto te deja fuera).
• Kernels al día: 110 → 147 y 1047 → 1062. Eso cerró tres CVEs de severidad high que estaban parcheados pero nunca arrancados: el parche estaba instalado en disco desde hacía semanas, esperando un reboot que nadie hizo.
• Docker 29.4.1 → 29.9.3, incluyendo un fallo de DNS de contenedores que apuntaba a 127.0.0.53 (inalcanzable desde el netns) y que habría roto la renovación de certificados Let's Encrypt en silencio.
• Superficie de ataque: Docker publica puertos por encima de UFW. El único servicio realmente expuesto a internet era MinIO en Oracle, con 200 OK desde cualquier IP y cero hits en los logs. Se cerró, con reglas persistentes que sobreviven al reboot.

4. El inventario que no existía

Escaneamos las 72 imágenes con Trivy. El resultado crudo asusta: 1.102 CRITICAL y 15.521 HIGH. Y acá hay una decisión interesante, porque el número por sí solo es inútil y hasta peligroso: paraliza.

Lo primero fue separar el ruido de la señal:

• 69% de los críticos estaban en la capa de sistema operativo de la imagen (Debian/Ubuntu/Alpine dentro del contenedor) → se resuelven reconstruyendo, no reescribiendo código.
• 31% estaban en librerías de la aplicación → requieren actualizar dependencias.
• El agregado de 15.521 HIGH está inflado: Trivy cuenta una CVE por cada paquete × imagen. La métrica útil es CVEs únicas por servicio expuesto.

Con eso claro, se reconstruyeron 11 imágenes base y 9 imágenes propias —todas con --pull, para traer la base actualizada—. El resultado, medido antes y después con el mismo escáner:

Imagen	Antes (C/H)	Después (C/H)
swarm-orchestrator	16 / 427	1 / 90
confucius-agent-demo	13 / 174	2 / 48
chatwoot-bot	5 / 109	0 / 49
integrai-webhook	4 / 107	0 / 49
TOTAL (9 imágenes)	57 / 1.230	20 / 508

−65% en críticos, −59% en altos. Y un caso aparte: ebook-generator corría sobre node:18, una versión end-of-life desde abril de 2025, con 228 CVEs críticos en una sola imagen —el 41% de toda la deuda crítica de ese servidor—. El servicio ya no se usaba: se respaldó completo y se retiró. Un contenedor, 228 críticos menos.

5. Donde la IA se equivocó (cuatro veces)

Esta es la sección que no suele aparecer en los artículos sobre agentes. Hoy, el mismo agente que cerró 78 parches tumbó producción dos veces. No lo cuento como anécdota: lo cuento porque define dónde está el límite real de la herramienta.

5.1 El reboot que se llevó el sitio, 7 minutos

El plan era correcto: reiniciar para arrancar el kernel nuevo. Lo que no se verificó fue qué servicios estaban enabled y competirían por puertos. Un nginx del host, deshabilitado funcionalmente pero enabled en systemd, arrancó antes que Traefik y se quedó con el puerto 80. Resultado: siete minutos de producción caída.

Y hubo un segundo error encadenado: tras el salto de Docker, el contenedor de Traefik se recreó sin red adjunta —cero interfaces—, así que no publicaba 80/443. El log decía que el proceso estaba «Up». El proceso estaba arriba y era inútil.

5.2 MongoDB 8.2 contra 9.0

Al actualizar mongo:latest, el tag saltó de la versión 8.2 a la 9.0.4. La base se negó a abrir los datos:

UPGRADE PROBLEM: Found an invalid featureCompatibilityVersion document
version: "8.2" ... Expected one of: '9.0', '8.3', '8.0'

No había corrupción: los datos estaban intactos. Era un chequeo de compatibilidad. El fix correcto no fue «volver atrás», fue pinnear mongo:8.2 en el compose en vez de :latest. Es decir: el incidente validó exactamente el diagnóstico que el propio informe señalaba — :latest es deuda técnica con forma de comodidad.

5.3 El rollback que no servía para nada

El procedimiento incluía respaldar la imagen anterior antes de recrear, para poder volver. Se implementó… después del pull. Es decir, el tag de rollback apuntaba a la imagen nueva. Inservible justo en el momento en que se necesitó, con Mongo caído.

Se resolvió por otra vía. Pero el error es instructivo: el orden de los pasos de seguridad importa tanto como los pasos. Un rollback que se captura tarde no es un rollback, es una ilusión de rollback.

5.4 El backup de 20 bytes que pasaba el chequeo

Antes de planificar cualquier actualización con migraciones de base de datos, se hicieron los respaldos. El de GLPI salió de 20 bytes. El archivo existía, el gzip era válido, el script decía «OK». Un chequeo superficial lo habría aprobado.

La causa: el contenedor usaba MARIADB_ROOT_PASSWORD y el script leía MYSQL_ROOT_PASSWORD. Autenticación fallida, salida vacía, gzip de nada. Se corrigió y se verificó por contenido: 449 tablas, 1,1 millones de líneas.

6. La economía real del asunto

Acá está el argumento que me interesa, y es de negocio, no de tecnología.

Lo que se hizo hoy —inventario de superficie, gestión de parches, rotación de kernel con ventana, escaneo de 72 imágenes, triage por explotabilidad, reconstrucción de 20 imágenes, respaldos verificados con restore drill, e informe con evidencia— es trabajo de seguridad operacional. Con un proveedor, se cotiza por proyecto y depende muchísimo del alcance; con un equipo interno, es un SRE que una pyme no puede sostener.

Y hay una asimetría que casi nadie nombra: el costo de no hacerlo no aparece en ninguna factura hasta que aparece de golpe. Un ransomware por un servicio expuesto, una multa bajo la Ley 21.719 —vigente desde el 1 de diciembre de 2026, con sanciones de hasta 20.000 UTM—, o simplemente un fin de semana entero reconstruyendo lo que un backup inexistente no cubrió.

La IA no abarata el juicio. Abarata brutalmente la ejecución y la verificación: leer 72 imágenes y priorizar, cruzar un CVE contra un tracker por release y paquete, reconstruir 20 imágenes en paralelo, escribir el informe con la evidencia al lado. Eso es lo que antes costaba horas de un especialista y hoy es una sesión de trabajo de una persona que sabe qué preguntar.

7. Lo que la IA no puede hacer (y por eso sigue habiendo un responsable)

Cuatro cosas de hoy no las decidió el agente:

1. Autorizar la caída. Reiniciar producción es una decisión de negocio. La IA puede estimar el riesgo; no puede asumirlo.
2. Elegir la ventana. «Ahora» o «a las 02:00» depende de si hay clientes en una reunión.
3. Aceptar un riesgo que no tiene solución. Cal.com trae 205 CVEs críticos y su versión latest ya es la última publicada: no hay parche del proveedor. Eso es una decisión documentada, no un ticket que se cierra.
4. Decidir qué se borra. El ebook-generator tenía 2,2 GB de ebooks generados. El agente podía respaldar; decidir que ese servicio ya no importaba fue del humano.

8. Cierre

Sobre los riesgos de la IA se está escribiendo —con razón— muchísimo. Pero hay un desbalance: se habla de lo que puede romper mucho más de lo que se documenta de lo que puede reparar. Y quien administra la infraestructura de una pyme chilena, un estudio jurídico, una clínica o una consultora pequeña, no necesita otra advertencia. Necesita que alguien le mire los servidores.

Hoy esos servidores están parcheados, con los kernels al día, con la superficie de ataque cerrada, con inventario de CVEs, con backups probados y con un CVE 9.8 identificado, mitigado y en vigilancia. En un día. Con una persona.

Y con cuatro errores en el camino que quedaron escritos acá, porque la parte honesta no es la que muestra el dashboard en verde: es la que cuenta cuántas veces estuvo en rojo y cómo se salió.