Que la IA lleve el servidor, sin romperlo

Atlas puede abrir su propio servidor Model Context Protocol para quien lo quiera, y ofrece un campo de comandos dentro del panel. Es un componente aparte: no llega con la instalación, quien lo quiere lo añade desde el panel con un botón y en una máquina que no lo quiere no está presente en absoluto. Una vez añadido, se lee el estado del servidor, se recorre una avería y el trabajo se hace escribiendo lo que se quiere. El límite lo traza Proxmox: a lo que un usuario puede tocar llega también la IA, no más. No aparece ninguna noción nueva de permisos. La IA se conecta a Atlas, no a Proxmox. Proxmox queda debajo, pero el modelo nunca llega a él directamente: solo usa lo que Atlas sabe hacer.

Lo que cuesta hoy dar acceso al servidor a un modelo

Hoy solo hay un camino para que un asistente de IA trabaje con Proxmox: entregarle una sesión SSH o un token de API con todos los privilegios. Eso es ceder root, y a partir de ahí nada se interpone entre el modelo y el hardware.

El riesgo nace de la falta de contexto, no de la mala intención. Un modelo puede ver un disco vacío y tratarlo como retirable cuando pertenece a una máquina simplemente apagada. Puede leer un grupo degradado y proponer reconstruirlo cuando el paso correcto es sustituir un disco. El comando se escribe bien y el resultado es pérdida de datos.

Por eso en entornos serios el modelo se deja fuera del servidor. La pérdida se ve en el diagnóstico: leer registros largos y encontrar qué se rompió es justo lo que un modelo hace bien, y es justo ese trabajo el que no se hace.

Lo que se puede preguntar

En el campo de comandos del panel se pregunta y se manda hacer, como una sola conversación. Los ejemplos de abajo son el lado de las preguntas: el modelo lee el estado del servidor y responde con el registro en el que se apoya, y en ellos no cambia nada.

¿Por qué falló la copia de esta noche, en qué paso se detuvo, había sitio en el almacenamiento de destino?

¿Por qué esta máquina virtual va lenta desde anoche, el cuello de botella está en el procesador o en el disco?

¿Por qué está degradado el grupo, qué disco cayó, hay datos en riesgo ahora mismo?

¿Cuál de las actualizaciones pendientes pide reinicio y qué servicios detendrá?

¿Qué significa este error del registro, ya había ocurrido antes, se repite?

A este ritmo, ¿cuándo se llena la capacidad, qué máquina crece más rápido?

Lo que se puede hacer

A esto se le llama VibeOps: llevar un servidor hablándole. El vibe coding es escribir sin leer el código, y en Proxmox eso no cabe, así que aquí cada paso queda a la vista. En el mismo campo también se trabaja. Se escribe lo que se quiere. Atlas informa primero de qué va a hacer y dónde va a tocar: los pasos, las máquinas y los almacenamientos afectados y el camino de vuelta. El trabajo se realiza después de la aprobación. No aparece ninguna noción nueva de permisos: el campo de comandos trabaja con los permisos de la cuenta de Proxmox con la que se conecta. Quien quiera una IA más estrecha le da una cuenta de Proxmox acotada, y el alcance queda escrito en los permisos de esa cuenta. La escritura también puede apagarse para la propia sesión, dejándola en solo lectura. Cada paso entra en el registro de auditoría.

Dale dos núcleos más a esta máquina y sube su memoria a ocho gigabytes.

Programa una copia a las tres de la madrugada para todas las máquinas de este grupo.

Instala los parches de seguridad pendientes, deja los que piden reinicio para la ventana de mantenimiento.

Pon la política de reinicio de ese contenedor en siempre.

Dale a este usuario solo el derecho de copia de seguridad, nada más.

Mueve ese disco al grupo nuevo, haz una instantánea antes de moverlo.

El modelo pasa por la misma puerta que una persona

El servidor MCP no abre una vía lateral. Las mismas protecciones que Atlas ya aplica al usuario humano se aplican al modelo, en el mismo orden.

Los permisos vienen de Proxmox

El modelo trabaja con los derechos del usuario con el que se conecta, no con una cuenta propia. Lo que Proxmox le cierra a ese usuario queda cerrado también al modelo. Atlas no crea su propio sistema de permisos.

La cuenta de Proxmox marca el alcance

El campo de comandos trabaja con los permisos de la cuenta de Proxmox con la que se conecta; Atlas no introduce una noción de permisos propia. Quien quiera un alcance estrecho le da una cuenta estrecha, y ese alcance queda escrito en los permisos de la cuenta y en una auditoría se relee de ahí. Apagar la escritura para la propia sesión es un solo gesto.

El impacto se muestra antes

Cuando se propone un cambio, los pasos a aplicar, los recursos afectados y el camino de vuelta se muestran a una persona. La aprobación ocurre en pantalla, no dentro de la conversación.

Confirmación dura para lo que no tiene vuelta

Si la cuenta con la que se conecta no tiene permiso, borrar, formatear y deshacer un grupo no son posibles en absoluto. Donde hay permiso, sigue rigiendo la confirmación dura que el producto usa en otros sitios: escribir el nombre para confirmar, un clic no basta. Quien quiera un paso más lo activa: las escrituras piden un código de un solo uso, la misma verificación en dos pasos que la cuenta ya usa.

Cada paso queda registrado

Todo lo que el modelo lee y cada operación que pide entra en el registro de auditoría: qué usuario, qué modelo, cuándo y con qué resultado. La entrada ya no se puede modificar.

Las respuestas muestran su origen

El modelo dice de dónde sacó la conclusión: qué línea de registro, qué medición, qué configuración. Una respuesta que no se puede comprobar no cuenta como respuesta.

Lo que el modelo no puede hacer

Los límites viven en el producto, no en la conversación. Cómo se le pregunte al modelo, o cuánto se insista en convencerlo, no cambia nada. En una organización que conecta su propio modelo se aplican los mismos límites, porque la regla se impone en el servidor y no en el modelo.

No puede ampliar sus propios permisos ni crear un usuario o una clave de acceso.

No puede aplicar ninguna escritura sin aprobación.

Si la cuenta con la que se conecta no tiene permiso de escritura, no cambia nada y solo lee.

No puede abrir un intérprete de comandos en el servidor ni pasar a la línea de comandos. Hace falta pocas veces, porque el trabajo que exige profundidad también está cubierto: del grupo ZFS a Ceph, del puente a OVS, de fijar el núcleo a repartir permisos, y la cobertura se amplía con cada versión. Para la rara tarea que se sale del marco, escribe el comando y explica su riesgo, y la ejecución queda en manos de una persona.

No puede borrar ni alterar la entrada de auditoría.

A dónde van los datos

El servidor MCP es un componente aparte y no forma parte de la instalación por defecto. Se añade desde el panel con un botón; en una máquina que no lo quiere no hay ni siquiera un archivo suyo. Una vez instalado, qué recursos puede mirar y cuánto tiempo queda abierto siguen siendo decisiones del cliente.

La elección del modelo también es del cliente. Con un modelo local ejecutándose en el propio servidor, ningún dato sale de la máquina y el producto sigue sin conexión. Si se elige un servicio externo, el contenido a enviar se ve antes de enviarse.

Para organizaciones bajo regulación estricta

No se reclama ninguna certificación. El producto se diseña para cumplir los requisitos de marcos con condiciones de auditoría duras, y la auditoría interna de una organización puede usar estos comportamientos como prueba.

Sistema de gestión de IA (ISO/IEC 42001): lo que el modelo puede hacer está escrito, los límites se imponen en el producto, cada uso queda registrado.

Seguridad de la información (ISO/IEC 27001): el acceso viene del sistema de identidad ya existente, los privilegios siguen el mínimo privilegio, los registros son inalterables.

Gestión de riesgos de IA (ISO/IEC 23894 y NIST AI RMF): sin acción autónoma, la aprobación humana es un paso obligatorio del flujo.

Datos personales (RGPD y equivalentes): los datos se quedan en la máquina del cliente; si han de salir, se ve antes y la decisión es del cliente.

Infraestructura crítica (NIS2 y disposiciones de transparencia sobre IA): tras un incidente se puede releer quién hizo qué, qué propuso el modelo y quién lo aprobó.

Preguntas frecuentes