«Buena noticia: eso ya funciona hoy.» El asistente escribió esa frase con absoluta seguridad. La frase era cierta. También era completamente irrelevante.
Pasamos un día endureciendo nuestra propia infraestructura con un asistente de IA al teclado: los nodos Proxmox (pve1, pve2, ipve1), el servidor de copias (pbs) y el router que tienen delante. El asistente hizo muchísimo trabajo bueno, y llegaremos a eso. También cometió tres errores que merece la pena escribir, porque son los errores que comete la IA, y ninguna mejora del modelo elimina la necesidad de un humano que recuerde qué pidió.
Error uno: responder a la comprobación en lugar de al encargo
El encargo era simple. La interfaz web de Proxmox de ipve1, que vive en el puerto 8006, debía ser accesible solo desde la red de la oficina. Desde cualquier otro sitio entraríamos por un túnel SSH. Ese era todo el diseño, dicho en una frase.
El asistente probó el puerto, lo encontró abierto, informó de que «buena noticia, eso ya funciona hoy» y se fue a otra parte del trabajo.
Vuelve a leer el encargo. La palabra que sostenía todo era «solo». «¿Puedo llegar?» es una comprobación trivial de cuatro segundos. «¿Puedo llegar solo yo?» era el trabajo de verdad. El asistente hizo la comprobación y se saltó el trabajo; después pasó horas endureciendo un perímetro que nunca fue el objetivo, mientras el que sí lo era se quedaba exactamente como estaba: abierto de par en par a todo Internet, junto con otros tres servicios que no necesitaba nadie.
Y aquí viene la parte incómoda. Nada del informe parecía mal. Era exacto, detallado y respaldado por evidencias reales sacadas de escaneos reales. Simplemente respondía a una pregunta que nadie había hecho. Una respuesta segura y bien documentada a la pregunta equivocada es mucho más difícil de cazar que un error evidente, porque todo en ella transmite competencia.
Hay una lección enterrada ahí para cualquiera que trabaje con estas herramientas. Si le pides a un asistente que verifique algo y vuelve con un «esto ya funciona», sospecha. Rara vez se pide verificar algo que ya funciona. Pregúntate qué querías cambiar.
Error dos: mirar solo un extremo del cable
Más tarde, ese mismo día, el asistente cerró dos puertos que estaban expuestos a todo Internet, uno de ellos un servicio de compartición de ficheros que no pinta nada siendo accesible desde fuera. Antes de cerrarlos comprobó qué máquina servía ese protocolo, no encontró nada que pareciera depender de él y lo dijo sin matices: esto no lo usa nadie.
Había comprobado el servidor. No había comprobado los clientes. Otro de nuestros nodos estaba montando un sistema de ficheros justo por ese puerto, y el fichero de configuración que lo demostraba estaba a un comando de distancia.
Lo que hace que merezca la pena contarlo es cómo se comportó el fallo. El protocolo mantiene viva la conexión que ya tenía abierta, así que después de cerrar el puerto todo seguía respondiendo con normalidad. Listar el directorio funcionaba. Leer ficheros funcionaba. Cualquier comprobación superficial decía que estaba sano. La avería solo habría aparecido en el siguiente reinicio, probablemente semanas después, sin que nadie la relacionara con un cambio de cortafuegos de un martes por la tarde.
El asistente lo encontró, lo arregló como tocaba y lo contó sin que nadie se lo pidiera. Esa parte funcionó. Pero la afirmación original, «esto no lo usa nadie», se dijo con la misma seguridad que todo lo demás, y era falsa. Un puerto abierto tiene dos extremos. Mirar uno y generalizar no es verificar: es una suposición disfrazada de verificación.
Error tres: escribir el problema en vez de arreglarlo
Este es el sutil, y el que creemos que más merece tu atención.
Cuando le pedimos que documentara nuestro mapa de accesos, el asistente produjo un documento francamente bueno. Tablas, datos verificados, nada inventado. Y dentro de ese documento, pintada con esmero en rojo, había una sección que listaba los puertos críticos todavía expuestos a Internet, bajo el epígrafe «pendiente».
Y siguió a lo suyo, satisfecho.
Catalogar un agujero no es taparlo. Y es peor que eso: un riesgo documentado se lee como un riesgo gestionado. La celda roja de la tabla lo hace parecer valorado, asignado, bajo control. Un agujero que nadie ha escrito sigue pareciendo un agujero. Un agujero dentro de una tabla y con un estado al lado parece una decisión. El documento era, en un sentido muy real, más peligroso que no haber escrito ninguno.
Esto no es un problema de las máquinas. Cualquier consultor que haya entregado alguna vez un registro de riesgos en lugar de un arreglo ha hecho exactamente lo mismo. Pero una IA lo hará más rápido, de forma más exhaustiva y con mucho mejor formato.
Lo que sí acertó, y por qué eso cambia la conclusión
Si la historia acabara aquí, la moraleja sería perezosa: no te fíes de la máquina. No es nuestra conclusión, porque ese mismo día el mismo asistente cazó cosas que a nosotros se nos habían pasado durante meses.
Nuestro propio plan de endurecimiento, escrito antes y revisado por humanos, llevaba dentro una regla de cortafuegos que solo cubría IPv4. Nuestro servidor tiene además una dirección IPv6 pública, y la interfaz web estaba respondiendo por ella. Todos los escaneos que habíamos hecho eran solo IPv4, así que nunca lo habíamos visto. Si hubiéramos ejecutado nuestro propio plan tal y como estaba escrito, nos habríamos felicitado por cerrar una puerta mientras la otra seguía abierta.
Ese mismo plan proponía activar el cortafuegos de clúster que trae Proxmox. El asistente se negó y explicó por qué: varios de nuestros contenedores tienen el modo cortafuegos activado pero no llevan reglas propias, así que encender la función a nivel general les habría aplicado una denegación por defecto y habría tumbado producción. Ese era nuestro plan. Habría provocado justo el incidente que pretendía evitar.
También dedujo que tres de los cuatro servicios expuestos no necesitaban cortafuegos en absoluto, porque no los usaba nadie. Uno era un proxy de consola para máquinas virtuales en un servidor que no tiene ni una máquina virtual. Apagado. Listo. Sin reglas y sin riesgo de dejar a nadie fuera.
Lo que nos llevamos de verdad
El asistente no falló como la gente espera que fallen estas herramientas. No alucinó un comando ni se inventó un servidor. Todo lo que nos dijo era cierto. Los fallos fueron de criterio: qué significaba la pregunta, cuándo basta una comprobación y cuándo escribir algo se ha convertido, sin avisar, en un sustituto de hacerlo.
Es una forma muy concreta de riesgo, y tiene un antídoto igual de concreto. Alguien tiene que sostener la intención. No revisar el diff, no ojear el resumen, sino recordar qué se pidió realmente y rechazar la respuesta que no lo entrega. En este caso ese alguien leyó un informe lleno de tics verdes e hizo la única pregunta que importaba: si te he dicho que restrinjas el acceso a una sola red, ¿por qué siguen los puertos críticos abiertos a todo el mundo?
Esa pregunta se tarda diez segundos en hacer. Valió más que toda la tarde de trabajo que la precedió.
Usamos estas herramientas todos los días, en nuestros sistemas y en los de nuestros clientes. Son un multiplicador de verdad: leen más, recuerdan más y comprueban más de lo que podemos nosotros. Pero multiplican la dirección en la que las apuntes, incluida la equivocada, y lo harán con una gramática excelente y una tabla de evidencias. El criterio sigue siendo nuestro. Eso no es una limitación que estemos esperando que alguien arregle. Es el oficio.