El viernes, el dominio de WebCom respondía con un error. El domingo teníamos un sitio nuevo con despliegue automático, un test de ciberseguridad basado en NIST, correo que por fin llega a las bandejas de Microsoft 365, un servidor bastante más seguro y almacenamiento propio para reemplazar una nube de terceros.
Lo construimos con la fábrica: un método donde el humano define y decide, y los agentes de IA ejecutan detrás de compuertas. Pero lo que vale la pena contar no es la lista de cosas hechas. Son las lecciones. Varias salieron de errores, y los contamos porque si no lo corremos nosotros, no te lo vendemos.
1. Un ítem se cierra con evidencia, no con ejecución
Aplicamos un cambio en el servidor web y el comando respondió "OK". Parecía listo. Pero cuando probamos el efecto, un límite de intentos de inicio de sesión, el límite no aparecía.
El servidor había rechazado la configuración nueva en silencio y seguía con la anterior. El "OK" solo decía que el comando se había enviado, no que hubiera funcionado.
La regla que quedó: después de cada cambio, se prueba el efecto, no el código de salida. Si el cambio era "bloquear al séptimo intento", se intenta siete veces.
2. «Idénticas» sobre cero no prueba nada
Para retirar un sistema viejo hicimos un respaldo final y lo restauramos en una base de prueba, para comparar tabla por tabla. El primer resultado dijo "idénticas". Era cierto: cero tablas contra cero tablas. La consulta de comparación había fallado y comparó la nada contra la nada.
La segunda vez exigimos un mínimo: si no aparecen las 145 tablas, la prueba no vale. Ahí sí: 145 de 145 tablas y 389.255 filas iguales.
La regla que quedó: toda verificación declara qué espera encontrar. Un "todo bien" sin cantidades es una opinión.
3. Lo que no ves también existe
Mudamos el DNS de un dominio a otro proveedor. Armamos el inventario consultando los registros uno por uno y todo coincidía. Hasta que exportamos la zona completa: había ocho registros que apuntaban a otros servidores y que nuestras consultas nunca vieron, porque un registro comodín respondía por ellos.
Si hubiéramos cambiado los servidores DNS con el primer inventario, tres sistemas en producción se habrían caído.
La regla que quedó: no se deduce la fuente de verdad, se exporta.
4. Permisos mínimos, siempre
Cada servicio que manda correo tiene su propia cuenta. Las credenciales de envío solo sirven para enviar. Las contraseñas se generan en el servidor y nunca pasan por una conversación. Y cuando una credencial con acceso amplio sí pasó por el chat, se usó desde memoria, se borró al terminar y se revocó.
No es paranoia. Es que, el día que algo se filtre, el daño tiene que ser chico.
5. Los errores se escriben
Cada cambio en el servidor quedó en una bitácora con tres cosas: por qué se hizo, qué cambió y cómo revertirlo. Los errores también, con nombre y apellido. Un agente que dice "me equivoqué, así lo arreglé" vale más que uno que nunca falla, porque al segundo no le podés creer.
6. Primero borrar, después automatizar
El algoritmo de mejora de la fábrica tiene un orden obligatorio: cuestionar el requisito, borrar, simplificar, acelerar y recién al final automatizar.
Este fin de semana borramos mucho: un sistema retirado que seguía arrancando cada lunes, tareas programadas que fallaban quinientas veces por día, cuentas con permisos de administrador que nadie usaba y gigas de restos de pruebas. Cada cosa que borrás es una cosa menos que cuidar, actualizar y defender.
Lo que nos llevamos
La IA no reemplaza el criterio: lo vuelve más necesario. Los agentes ejecutan rápido, y por eso mismo las compuertas importan. Hay que decidir qué cuenta como terminado, pedir evidencia y escribir lo que pasó.
Si no lo corremos nosotros, no te lo vendemos.
¿Querés saber qué tan expuesta está tu organización? Hacé el Test de Exposición: 12 preguntas, 2 minutos, basado en NIST CSF 2.0.