Conectar la IA con tu servidor: despliegue y administración con un agente de IA

Hasta ahora, la mayoría de la gente usa la IA como un compañero muy leído al otro lado del teléfono: describes un problema del servidor, recibes un comando sugerido, lo copias en la consola, pegas de vuelta el mensaje de error y repites el ciclo hasta que funciona. En cuanto conectas la IA con tu servidor, ese rodeo desaparece. Un agente de IA como Claude Code, OpenAI Codex CLI o Gemini CLI inicia sesión por sí mismo en el servidor por SSH, lee los registros, revisa la configuración, aplica los cambios, prueba el resultado y deja por escrito lo que ha hecho. Tú defines la tarea y apruebas los pasos que no tienen vuelta atrás.

Este artículo cuenta una experiencia real. En KernelHost, un agente de IA lleva meses trabajando a diario en nuestra propia infraestructura: portal de clientes, monitorización, flujos de pago, documentación. Mostramos cómo está montada la conexión entre el agente y el servidor, qué proceso sigue el agente para desplegar en sistemas de producción, qué reglas evitan que algo salga mal o se filtre al exterior y qué tiene que ofrecer un servidor para que todo esto funcione. Los fundamentos sobre herramientas y arquitecturas están en el artículo Servidor gestionado por IA: conectar agentes de forma segura, y la instalación en el servidor, en la guía para Claude Code y Codex CLI.

Conectar la IA con el servidor: qué significa

Conectar una IA con el servidor significa dar a un agente de IA un acceso propio y controlado a la línea de comandos del servidor, normalmente mediante una clave SSH. A partir de ese momento, el agente ya no se limita a proponer comandos: los ejecuta él mismo, lee la salida y deduce de ella el siguiente paso. El modelo de lenguaje en sí sigue funcionando del lado del proveedor (Anthropic, OpenAI o Google); en tu equipo o en tu servidor solo hay una herramienta ligera de línea de comandos que se encarga de ejecutar las órdenes.

La palabra clave es «controlado». Un agente con acceso al servidor no es un piloto automático, sino un colaborador muy rápido que pregunta antes de cada acción intrusiva. Cuánto puede hacer sin preguntar lo decides tú: desde el acceso de solo lectura hasta la instalación autónoma de actualizaciones siguiendo un proceso fijo.

Chatbot o agente: la diferencia en una tabla

Así, media hora de idas y venidas se queda a menudo en unos pocos minutos, y la fuente de error «lo tecleé mal» desaparece por completo.

Qué hace un agente de IA en el servidor: ejemplos de nuestro trabajo diario

Los siguientes ejemplos salen de nuestro día a día. Omitimos nombres, direcciones y credenciales; los procesos son reales.

Despliegues con copia de seguridad y vuelta atrás

Cuando cambiamos algo en el portal de clientes o en un script del servidor, el agente se encarga del despliegue. Primero compara el archivo del servidor con la última versión conocida, para no sobrescribir ningún cambio ajeno. Después crea una copia de seguridad con fecha fuera del directorio web, escribe un script de vuelta atrás, comprueba la sintaxis del archivo nuevo, lo instala con los mismos propietarios y permisos que antes y a continuación prueba la función afectada. Solo cuando todo está en verde da el trabajo por terminado. El proceso exacto se describe más abajo, en la sección sobre el despliegue.

Diagnóstico de errores: del síntoma a la causa en minutos

«Desde la oficina no se puede acceder a la web, desde fuera sí». Antes, eso habría supuesto una búsqueda larga. El agente revisa las reglas del cortafuegos, busca la dirección de la oficina en los registros del software de protección, encuentra la regla que se ha disparado y explica qué petición la activó. La decisión sobre qué hacer sigue siendo nuestra; el trabajo de detective, no. Con los errores típicos de servidor web, como 502 Bad Gateway o los discos llenos, trabaja igual: lee journalctl y los registros de la aplicación, plantea una hipótesis y la respalda con pruebas antes de cambiar nada.

Monitorización que construye el propio agente

Buena parte de nuestra monitorización ha surgido trabajando junto al agente: pequeños scripts de comprobación que cada pocos minutos, mediante una tarea cron, prueban un servicio de extremo a extremo y, si algo falla, envían un mensaje al móvil, por ejemplo a través de un bot de Telegram. El agente escribe el script, lo prueba provocando un fallo a propósito, configura la tarea cron y documenta cómo silenciar la alarma. Cómo montar algo así en general se explica en el artículo Configurar la monitorización del servidor.

Inventarios y tareas de limpieza

¿Qué servidores siguen en marcha aunque su contrato ya esté cancelado? ¿Qué servicios adicionales se pagan pero ya no se usan? El agente responde a este tipo de preguntas consultando bases de datos e interfaces en modo de solo lectura y presentando el resultado en una tabla. Solo puede limpiar tras recibir la aprobación, y antes comprueba si la máquina está realmente en desuso, por ejemplo por su tráfico de los últimos días.

Documentación que crece sola

Cada cambio termina con una entrada en el registro de cambios y, si hace falta, con una ampliación del manual de operaciones. Al agente le cuesta segundos y a nosotros nos ahorra horas más adelante, porque la pregunta «¿Y esto por qué está así?» tiene una respuesta por escrito.

Las ventajas de que la IA trabaje directamente en el servidor

• Rapidez: el agente lee en segundos lo que a una persona le lleva minutos, y pone a prueba una hipótesis al instante en lugar de describirla primero.
• Minuciosidad: lee la configuración completa, con los archivos incluidos, y las líneas del registro alrededor del error, no solo el fragmento que a alguien le pareció relevante.
• Un proceso siempre igual: la copia de seguridad, la comprobación de sintaxis y la verificación se ejecutan cada vez, también un viernes a última hora y también en el vigésimo cambio pequeño.
• Documentación sin esfuerzo extra: cada cambio queda descrito, con el motivo, la ubicación de la copia de seguridad y la vuelta atrás.
• Automatización sin estudiar scripting: los scripts de comprobación, las tareas cron y los informes surgen de una descripción en lenguaje normal y se prueban antes de ponerlos en marcha.
• Aprendizaje de paso: el agente explica qué hace y por qué. Quien lo sigue de cerca entiende su servidor mucho mejor al cabo de unas semanas.

Tres arquitecturas y cuál usamos nosotros

Hay tres formas probadas de conectar un agente con un servidor. Se diferencian en dónde se ejecuta la herramienta y dónde se guardan las credenciales.

Nuestra elección: el agente en el puesto de trabajo y los servidores por SSH

Nosotros trabajamos con la primera variante. El agente se ejecuta en el equipo de trabajo, cada servidor tiene una entrada en la configuración SSH y el agente se conecta con su propia clave. El motivo principal: gestionamos muchos sistemas, y así un solo agente puede seguir una causa a través de varios servidores en una misma sesión, por ejemplo desde el servidor web hasta el cortafuegos, pasando por la base de datos. Además, el inicio de sesión con el proveedor de IA y las claves están en un lugar que protegemos de todos modos. Si solo tienes un servidor y quieres informes automáticos por la noche, la segunda variante te irá bien. Encontrarás más sobre sus ventajas e inconvenientes en el artículo sobre el servidor gestionado por IA.

Guía: conectar un agente de IA con el servidor por SSH

Los siete pasos siguientes funcionan igual con Claude Code, Codex CLI y Gemini CLI. Los ejemplos usan la dirección de documentación 203.0.113.10 y el nombre de usuario deploy; sustituye ambos por tus propios valores. El requisito previo es un servidor con inicio de sesión por clave SSH, como se describe en el artículo Asegurar SSH y configurar el acceso por clave.

Paso 1: generar una clave SSH propia solo para el agente

El agente nunca recibe tu clave personal, sino una propia. Así puedes retirarle el acceso en cualquier momento sin perder el tuyo, y en los registros se ve qué inicio de sesión procede del agente.

ssh-keygen -t ed25519 -C "ki-agent" -f ~/.ssh/ki_agent_ed25519

Ed25519 genera claves cortas, es rápido y se considera seguro. El comentario ki-agent aparecerá más adelante en el archivo authorized_keys del servidor y permitirá reconocer la clave de un vistazo.

Paso 2: guardar la clave pública en el servidor

ssh-copy-id -i ~/.ssh/ki_agent_ed25519.pub deploy@203.0.113.10

Si quieres restringir aún más el acceso, añade opciones delante de la clave en el archivo ~/.ssh/authorized_keys del servidor. from= solo permite el inicio de sesión desde una dirección concreta, y no-agent-forwarding y no-port-forwarding impiden que la conexión sirva de trampolín:

from="198.51.100.7",no-agent-forwarding,no-port-forwarding,no-X11-forwarding ssh-ed25519 AAAA... ki-agent

Si después el servidor responde con Permission denied (publickey), te ayudará el artículo Solucionar el error SSH Permission denied (publickey).

Paso 3: crear un alias de host en la configuración SSH

Con un alias, el agente solo necesita conocer un nombre corto y siempre usa la clave correcta:

Host web-prod
    HostName 203.0.113.10
    User deploy
    IdentityFile ~/.ssh/ki_agent_ed25519
    IdentitiesOnly yes
    ServerAliveInterval 30

A partir de ahí basta con ssh web-prod "systemctl status nginx". IdentitiesOnly yes evita que SSH pruebe otras claves de tu llavero. Para cada servidor adicional creas un bloque propio; para los sistemas de pruebas y de producción, mejor con nombres distintos como web-test y web-prod, para que cualquier confusión salte a la vista ya por el nombre.

Paso 4: instalar el agente e iniciar sesión

Claude Code, Codex CLI y Gemini CLI funcionan en Linux, macOS y Windows, y se inicia sesión en ellos con una cuenta del proveedor o con una clave API. La instalación y el inicio de sesión sin navegador se describen en la guía paso a paso. Para la variante del puesto de trabajo, instala la herramienta en tu equipo, no en el servidor.

Paso 5: definir las reglas que sigue el agente

Las tres herramientas leen al arrancar un archivo de reglas en el directorio de trabajo: Claude Code lee CLAUDE.md; Codex CLI, AGENTS.md; y Gemini CLI, GEMINI.md. Ahí se define cómo se trabaja en tus servidores. Un punto de partida probado:

# Reglas para trabajar en servidores

- Antes de cada cambio, crear una copia de seguridad con fecha fuera del directorio web.
- Antes de aplicar cambios, comprobar la sintaxis (nginx -t, php -l, apachectl configtest).
- Después de aplicarlos, comprobar el servicio, el registro y la función, e informar del resultado.
- No mostrar nunca contraseñas, claves API ni tokens, ni copiarlos nunca en archivos.
- Borrados, cambios en bases de datos y todo lo irreversible, solo con aprobación expresa.
- No modificar directamente los archivos que gestiona el panel de control.
- Eliminar los archivos de prueba después de la prueba.

Las reglas crecen con el tiempo. Cada vez que el agente haga algo de forma distinta a como tú quieres, la corrección debe entrar en este archivo como regla. Al cabo de unas semanas trabajará como trabajarías tú.

Paso 6: configurar las aprobaciones y la lista blanca

Por defecto, las herramientas preguntan antes de cada comando que cambia algo. Al principio es lo correcto. Los comandos de lectura que confirmas una y otra vez puedes permitirlos de antemano. En Claude Code se hace en el archivo .claude/settings.json:

{
  "permissions": {
    "allow": [
      "Bash(ssh web-prod journalctl:*)",
      "Bash(ssh web-prod systemctl status:*)",
      "Bash(ssh web-prod df -h)"
    ]
  }
}

Todo lo que no esté en esta lista sigue necesitando tu aprobación. Las opciones que desactivan todas las confirmaciones solo tienen cabida, como mucho, en una máquina de pruebas desechable.

Paso 7: una primera tarea de solo lectura

Empieza con tareas que no puedan cambiar nada y observa cómo trabaja el agente:

Revisa en web-prod los errores de nginx de las últimas 24 horas y nombra las tres
causas más frecuentes, cada una con una prueba sacada del registro. No cambies nada.

Solo cuando los análisis sean correctos toca pasar a cambios pequeños, como una nueva rotación de registros o un servicio systemd, y solo después, a los despliegues en el sistema de producción.

Así despliega el agente: nuestro proceso para cada cambio en el sistema de producción

Un agente de IA solo debe desplegar en un sistema de producción siguiendo un proceso fijo que incluya una copia de seguridad, una vuelta atrás preparada y una comprobación antes y después del despliegue. En nuestro caso, el proceso es este:

1. Comprobar el estado actual. El archivo del servidor se compara con la última versión conocida. Si otra persona lo ha modificado entretanto, el agente se detiene y pregunta en lugar de sobrescribir ese cambio ajeno.
2. Crear una copia de seguridad. Los archivos afectados van, con fecha, a una carpeta de copias de seguridad fuera del directorio web. Una copia dentro del directorio web podría llegar a ser accesible públicamente.
3. Preparar la vuelta atrás. Un pequeño script que restaura la versión anterior con un único comando se escribe antes del cambio, no en plena emergencia.
4. Comprobar la sintaxis. El archivo nuevo se comprueba antes de aplicarlo: en PHP con php -l, en nginx con nginx -t. Así, un error de sintaxis ni siquiera llega al sistema de producción.
5. Aplicar con los permisos correctos. El propietario, el grupo y los permisos del archivo se toman de la versión anterior. Después de los errores de sintaxis, los permisos incorrectos son la causa más habitual de caídas tras una actualización.
6. Probar sin efectos secundarios. Las pruebas se hacen en modo de lectura, con datos de prueba inventados o en un entorno aislado, nunca con pedidos reales ni con datos reales de clientes.
7. Comprobar en vivo. Tras el despliegue se revisan el código de estado HTTP, el registro de errores y la función modificada.
8. Documentar. Se actualizan el registro de cambios y el manual de operaciones, con la ubicación de la copia de seguridad y el comando para volver atrás.

Como secuencia de comandos, con marcadores de posición en lugar de rutas reales, tiene más o menos este aspecto:

ZIEL=/var/www/app/config.php
SICH=/var/backups/agent/$(date +%F-%H%M)
mkdir -p "$SICH" && chmod 700 "$SICH"
cp -a "$ZIEL" "$SICH/"
echo "cp -a $SICH/config.php $ZIEL" > "$SICH/rueckweg.sh"
php -l neu/config.php
install -o www-data -g www-data -m 640 neu/config.php "$ZIEL"
curl -fsS -o /dev/null -w "%{http_code}\n" https://example.com/

Por qué la vuelta atrás se prepara antes del cambio

Cuando algo falla, nadie está en su mejor momento para pensar una vuelta atrás limpia. Si el script ya está preparado, deshacer el cambio es cuestión de segundos, y el agente puede incluso ejecutarlo él mismo si falla la comprobación posterior al despliegue. Esa es la mayor diferencia entre un agente que cambia algo «en un momento» y uno al que se le confía un sistema de producción.

Pruebas que no pueden romper nada

Muchas funciones no se pueden probar sin que ocurra algo: un pedido, un pago, un correo electrónico. Aquí ayudan tres técnicas. Primero, las ejecuciones en seco (dry run) que ofrece la propia herramienta. Segundo, identificadores inventados que con toda seguridad no existen en ningún sitio. Tercero, un entorno aislado: un proceso que se ejecuta en su propio espacio de nombres de red, sin conectividad (unshare -n), no puede llegar a ninguna interfaz externa ni comprar nada por error, pero sigue viendo la base de datos local a través del socket Unix. Después de la prueba se eliminan todos los archivos de prueba.

Las acciones que cuestan dinero necesitan un bloqueo

Cuando un proceso pide, factura o borra algo, no debe ejecutarse dos veces a la vez, ni siquiera si alguien hace doble clic o el agente repite un comando. La solución más sencilla en Linux es flock:

flock -n /run/lock/bestellung.lock ./bestellung-ausfuehren.sh || echo "ya se está ejecutando"

En aplicaciones con base de datos, un bloqueo con nombre (GET_LOCK en MySQL y MariaDB) cumple la misma función; en las API, un Idempotency-Key. Hablamos de ello más abajo, en la sección sobre la KernelHost API.

Seguridad: acceso para el agente sin que se filtre nada

La duda que más oímos es: «¿Y qué pasa con mis datos?». La respuesta sincera: todo lo que lee el agente lo envía para su procesamiento al modelo de lenguaje del proveedor. Por eso, con las siguientes reglas decides tú qué llega a ver.

Los secretos no van en el chat

Las contraseñas, las claves API y los tokens nunca se escriben en una tarea y el agente nunca los muestra. Los scripts los leen de archivos con permisos 600, que el agente no necesita mostrar para usar el script. Si aun así una clave acaba en el chat, se revoca de inmediato en el proveedor y se genera una nueva. Tampoco los fragmentos van en el chat: los primeros caracteres de una clave no ayudan a nadie a encontrar un error, pero sí le ahorran trabajo a un atacante.

Claves propias, permisos propios, revocables en cualquier momento

Cada agente recibe su propia clave SSH, y cada clave se reconoce por su comentario en authorized_keys. Para retirar el acceso basta con borrar esa línea. Cuando es suficiente, el agente trabaja con un usuario propio y una regla de sudo que solo permite los comandos necesarios. Las API reciben claves propias con los mínimos permisos posibles, de solo lectura si únicamente sirven para informes.

Aprobaciones: lo que nunca ocurre sin una persona

Sin aprobación expresa, nuestro agente no puede borrar nada, ni escribir en bases de datos, ni relajar reglas del cortafuegos o de protección, ni detener máquinas, ni pedir nada. Las herramientas lo facilitan: Claude Code detiene las acciones intrusivas y, además, se puede configurar para que un filtro de seguridad detecte los comandos arriesgados y los bloquee hasta que se aprueben. De nuestro día a día: este filtro ha detenido más de una vez una acción que era técnicamente correcta, pero irreversible. Solo se ejecutó después de que una persona la aprobara expresamente. Así es exactamente como debe ser.

Trazabilidad: registro, lista de cambios, copias de seguridad

Cada sesión deja huellas que una persona puede leer: las copias de seguridad con fecha, el script de vuelta atrás, la entrada en el registro de cambios y los inicios de sesión en el registro del sistema. Si además gestionas /etc en Git con etckeeper, verás cada cambio de configuración como un diff. Lo que no es trazable tampoco se puede revertir. La base sigue siendo una estrategia de copias de seguridad que funcione, porque un agente no sustituye a una copia de seguridad.

¿Qué servidor es adecuado para un agente de IA?

Un servidor para la administración asistida por IA necesita acceso root completo, inicio de sesión por clave SSH, conexiones salientes sin restricciones, protección DDoS permanente e, idealmente, una API con la que pedir y controlar servidores de forma automatizada. No necesita GPU, porque el modelo de lenguaje funciona del lado del proveedor.

Por qué KernelHost para servidores gestionados por IA

En principio, un agente de IA puede trabajar con cualquier servidor en el que obtenga un shell. En la práctica, sin embargo, el entorno decide cuánto trabajo puedes delegarle de verdad. En un servidor root KVM o un servidor dedicado de KernelHost no hay cuentas restringidas, ni obstáculos para las conexiones HTTPS con los proveedores de IA, ni una permanencia que encarezca las pruebas. La protección DDoS permanente está activa en cada servidor sin coste adicional, y para tareas con mucha carga de cálculo hay servidores root Professional con núcleos dedicados. La facturación es PrePaid: sin contrato, sin permanencia mínima, sin cuota de instalación. Si quieres probar primero, empieza con el servidor de prueba gratuito.

La KernelHost API: tu agente pide y controla servidores por sí mismo

La mayor palanca está un nivel por encima del servidor individual. A través de la KernelHost API, un agente puede consultar productos y precios, pedir servidores, leer el estado de sus servicios, arrancar, detener y reiniciar servidores, y solicitar cancelaciones o revocarlas. Así, «Prepárame un servidor de pruebas» se convierte en una sola tarea: el agente pide la máquina, espera a que esté activa, se conecta por SSH, instala la aplicación y devuelve la dirección.

Pensando en su uso por agentes, la API se ha diseñado deliberadamente con cautela. Las claves API solo reciben los permisos que necesitan, y una clave para informes no puede pedir absolutamente nada. Un Idempotency-Key garantiza que un pedido que el agente repite tras un error de tiempo de espera no se ejecute dos veces. Las peticiones están limitadas por clave, por cuenta y por dirección, de modo que ni siquiera un agente atrapado en un bucle infinito desencadena una avalancha. Y cada consulta de credenciales dispara una notificación por correo electrónico, para que sepas cuándo un agente ha leído credenciales.

¿Cuánto cuesta un servidor gestionado por IA?

Hay dos partidas. La primera, el propio servidor: si el agente trabaja por SSH, el servidor no necesita ningún equipamiento especial; basta con cualquier servidor root en el que ya funcione tu aplicación. Si el agente se ejecuta directamente en el servidor, la herramienta solo necesita unos pocos cientos de megabytes de memoria, y un servidor root con 2 vCPU y 4 GB de RAM es suficiente si no se ejecuta mucho más en él. La segunda, el modelo de lenguaje: o bien una suscripción del proveedor que incluye el uso de la herramienta de línea de comandos, o bien una clave API con facturación por consumo. Con un uso diario intensivo, la suscripción suele salir más barata; para tareas automatizadas sin nadie delante, la clave API es la vía limpia, porque se puede limitar con un presupuesto mensual. Encontrarás los precios actuales de los servidores en la página Alquilar servidor root.

Errores frecuentes y cómo evitarlos

• El agente trabaja con la clave personal del administrador. Entonces su acceso no se puede retirar por separado ni distinguir en los registros. Solución: una clave propia con su propio comentario.
• Todas las confirmaciones están desactivadas. El primer día ahorra clics y, tarde o temprano, cuesta un servidor. Solución: lista blanca para los comandos de lectura y aprobación para todo lo intrusivo.
• Ninguna copia de seguridad antes del cambio. Solución: copia de seguridad y script de vuelta atrás como regla fija en CLAUDE.md o AGENTS.md.
• Copias de seguridad dentro del directorio web. Un archivo como config.php.bak en la raíz web puede ser accesible públicamente, contraseña de la base de datos incluida. Solución: una carpeta de copias de seguridad fuera del directorio web con permisos 700.
• Secretos en el prompt. Solución: credenciales solo en archivos con permisos 600 que leen los scripts y, si hay un descuido, generarlas de nuevo de inmediato.
• Ejecución doble. Un doble clic o una petición repetida hace el pedido dos veces. Solución: un bloqueo con flock o un Idempotency-Key.
• Archivos gestionados por el panel de control modificados directamente. El panel los sobrescribe en la siguiente actualización o falla por su culpa. Solución: excluir esos archivos en las reglas y hacer los cambios a través del panel o de su interfaz.
• Salidas aceptadas sin comprobar. Un agente que no entiende una salida, adivina. Solución: exigir pruebas («enséñame la línea del registro») y hacer que compruebe los resultados en vivo.

Resumen

• Conectar una IA con el servidor significa dar a un agente como Claude Code, Codex CLI o Gemini CLI una clave SSH propia y unas reglas claras.
• El agente lee registros, aplica cambios, comprueba el resultado y lo documenta; los pasos intrusivos solo se ejecutan con aprobación.
• Cada despliegue sigue un proceso fijo: comprobar el estado actual, hacer la copia de seguridad, preparar la vuelta atrás, comprobar la sintaxis, aplicar, probar, comprobar en vivo y documentar.
• Los secretos nunca van en el chat, y las acciones que cuestan dinero necesitan un bloqueo contra la ejecución doble.
• El servidor necesita acceso root, claves SSH, conexiones salientes libres y protección DDoS, pero no una GPU.
• Los servidores de KernelHost cumplen de serie todos los requisitos, en PrePaid y sin permanencia, y a través de la KernelHost API el agente puede incluso pedir y controlar servidores por sí mismo.