IA administrando un servidor: cómo se crea una máquina virtual sin romper nada

Leer el estado de la red es una cosa. Dejar que la IA haga algo en un servidor es otra muy distinta, y es donde casi todas las demostraciones que circulan se vuelven irresponsables.

Se puede hacer bien. Nosotros lo hacemos todos los días sobre nuestro propio servidor de virtualización, que es el que sostiene el laboratorio: máquinas virtuales, automatizaciones y los modelos de IA que corren en local.

Esto es cómo se ve cuando está bien hecho, y qué candados lo hacen posible.

Qué es un servidor de virtualización, en una frase

Es una sola máquina física que se comporta como varias. En vez de comprar un equipo por cada cosa, se compra uno bueno y dentro viven servidores independientes: uno para el sistema administrativo, otro para las automatizaciones, otro para lo que haga falta mañana.

La ventaja no es ahorrar equipo. Es que cada uno se respalda entero, se puede clonar y se puede devolver al estado de ayer si algo sale mal. Esa última parte es la que hace posible todo lo demás.

Cómo se le da acceso

No se le entrega la contraseña del administrador. Se hace como se hace con una persona nueva:

• Una llave de acceso propia, distinta de la del dueño, revocable por separado.
• Un usuario con los permisos que necesita y ninguno más. Estos sistemas permiten definir roles con detalle: quien puede crear una máquina virtual no tiene por qué poder borrar el almacenamiento.
• Registro de todo. Cada comando queda anotado con su hora, como cualquier otra sesión.
• Confirmación humana para lo irreversible. Reiniciar, borrar, formatear o tocar la red y el almacenamiento no se ejecutan solos. Se proponen, se leen y se aprueban.

Cómo se ve crear un servidor así

La secuencia real, cuando se pide una máquina virtual nueva:

1. Se dice qué hace falta, en lenguaje normal: para qué es, cuánta memoria, cuánto disco.

2. La IA revisa el estado real antes de proponer nada: cuánta memoria queda libre, cuánto espacio hay en el almacenamiento, qué números de máquina están ocupados.

3. Propone el plan con los comandos exactos, incluido dónde va a vivir el disco y qué red va a usar.

4. Una persona lo lee y aprueba. Aquí es donde se cortan los errores caros, y donde se detecta que el disco iba a caer en el almacén equivocado.

5. Se ejecuta, y después se comprueba lo real: que la máquina existe, que arrancó, que el almacenamiento sigue sano.

6. Queda documentado qué se hizo y por qué.

El paso 5 tiene una regla que parece obvia y casi nadie cumple: no se da por hecho lo que no se comprobó. "Debería estar funcionando" no es un estado, es una esperanza.

Lo que NO hace

• No decide qué necesita tu empresa. Ejecuta bien lo que alguien decidió bien.
• No opera sin supervisión. Un sistema que puede borrar un disco no se deja solo, igual que no se deja a nadie en su primer día.
• No sustituye los respaldos. Que la IA sea cuidadosa no cambia nada: la copia es lo que te salva del error, venga de quien venga.
• No conoce tu contexto si nadie se lo da. Sabe de tecnología, no de tu negocio.

Lo que de verdad cambia

El valor no está en escribir comandos: un ingeniero los escribe rápido. Está en tres cosas menos vistosas.

El estado siempre verificado. Antes de tocar, se lee. Después de tocar, se comprueba. Esa disciplina es la que la gente se salta cuando va con prisa, y es la que evita las averías de las seis de la tarde.

La documentación que nadie escribe. Cada cambio queda anotado sin esfuerzo extra. Cuando el equipo falle dentro de un año, existe la historia.

Los errores conocidos, evitados. Hay detalles que cuestan una tarde cuando no los sabes: la versión del sistema que toca en cada repositorio, identificar los discos por su nombre real y no por el orden en que aparecen. Un asistente con esas reglas escritas no los repite.

El caso: la máquina que iba al disco equivocado

Un servidor con dos almacenamientos: uno pequeño en un disco mecánico para el sistema, y otro grande y rápido, con dos discos en espejo, para las máquinas virtuales.

Al crear una máquina nueva, el destino por defecto era el pequeño. Habría arrancado, habría funcionado, y meses después habría ido lenta sin motivo aparente, y sin la protección del espejo. Se detectó al leer el plan, antes de ejecutarlo. Treinta segundos de revisión contra un problema que nadie habría relacionado con su causa.

Ese es el trabajo real: no que la máquina escriba el comando, sino que alguien lea el plan antes de que se ejecute.

Si alguien te ofrece una IA que administra tu servidor sola, sin aprobación y sin respaldo, no te está ofreciendo automatización. Te está ofreciendo un riesgo con buena presentación.