# Decision: IA y agentes para operaciones de infraestructura ## Contexto Gestionamos 100-500 servidores PVE/PBS con un equipo tecnico reducido. Ya tenemos decidido: Ansible + Semaphore (automatizacion), n8n (orquestacion futura), Netbox (inventario), Zammad (tickets), VictoriaMetrics + Loki (metricas/logs), Wazuh (seguridad), Grafana (dashboards). La pregunta es: como integramos IA para que nos ayude operativamente. Dos dimensiones: uso interactivo (tecnico + IA) y agentes automatizados (IA trabaja sola o semi-sola). --- ## 8.1 Claude Code interactivo: copiloto para tecnicos ### Que es Claude Code es un CLI que se instala en una maquina Linux. El tecnico abre terminal, ejecuta `claude`, y trabaja de forma conversacional. Claude Code puede leer ficheros, ejecutar comandos, buscar en el codigo, y generar scripts/playbooks. ### Donde se instala En la **VM Bastion** (ya existe, SSH jump host). El tecnico hace SSH al bastion y desde ahi usa Claude Code con acceso a: - Repos Forgejo clonados (playbooks Ansible, scripts) - CLI de PBS via SSH a los nodos (`proxmox-backup-manager`) - CLI de ZFS via SSH - Logs locales y remotos - API de Netbox, PBS, PVE (curl) ### Casos de uso reales | Escenario | Que hace el tecnico | Que hace Claude Code | |-----------|--------------------|--------------------| | GC lleva 3 dias | "revisa el GC del cliente ACME" | Lee logs, estado del job, uso de disco, diagnóstica | | Cliente nuevo | "genera playbook para cliente X, 200GB, sync desde pbs3343" | Genera YAML validado siguiendo el patron existente | | Alerta Wazuh | "analiza esta alerta de file integrity" | Lee evento, correlaciona con logs, valora si es falso positivo | | Script heredado | "que hace status_disk.sh y como mejorarlo" | Lee, documenta, sugiere mejoras | | Incidencia disco | "el pool9 del pbs tiene IO alto" | Revisa iostat, zpool status, encuentra el dataset problematico | | Post-mortem | "genera el timeline del incidente de ayer" | Lee logs de Loki, Wazuh, metricas, construye cronologia | ### Implementacion ```bash # En VM Bastion (Debian 12) curl -fsSL https://claude.ai/install.sh | bash # Configurar API key export ANTHROPIC_API_KEY="sk-ant-..." # Crear CLAUDE.md con contexto de la infra cat > /root/CLAUDE.md << 'EOF' # Infraestructura DoCloud - Pool ZFS: pool9 (PBS), pool10 (PVE) - Playbooks: /opt/ansible/ - Scripts legacy: /root/*.sh - PBS API: https://localhost:8007 - Netbox API: https://netbox.internal/api/ - Clientes: ver `proxmox-backup-manager datastore list` EOF ``` ### Recursos - CPU/RAM: despreciable (solo durante uso interactivo) - Coste: API key Anthropic, ~$20-50/mes segun uso del equipo - No requiere VM dedicada (va en Bastion existente) ### Seguridad - El tecnico ya tiene acceso SSH al bastion con sus credenciales - Claude Code hereda los permisos del usuario que lo ejecuta - No abre puertos, no es un servicio, no tiene persistencia - Logs de sesion almacenables para auditoria --- ## 8.2 Agentes automatizados via n8n + API Claude ### Arquitectura Los agentes no son procesos permanentes. Son **workflows de n8n** que se disparan por un trigger (alerta, cron, webhook), enriquecen contexto consultando APIs, llaman a Claude API con un prompt especializado, y actuan sobre el resultado (crear ticket, generar informe, notificar). ``` Triggers Agentes (n8n workflows) Acciones ┌──────────────┐ ┌─────────────────────┐ ┌──────────────┐ │ Alertmanager ├──────────────►│ Triaje de alertas ├─────────►│ Ticket Zammad│ │ │ │ (prompt seguridad) │ │ │ ├──────────────┤ ├─────────────────────┤ ├──────────────┤ │ Cron semanal ├──────────────►│ Capacity planning ├─────────►│ Informe │ │ │ │ (prompt storage) │ │ Outline │ ├──────────────┤ ├─────────────────────┤ ├──────────────┤ │ Wazuh alert ├──────────────►│ Analisis seguridad ├─────────►│ Ticket Zammad│ │ (nivel ≥10) │ │ (prompt forense) │ │ + Mattermost │ ├──────────────┤ ├─────────────────────┤ ├──────────────┤ │ Zammad ticket├──────────────►│ Provisioning assist ├─────────►│ MR en Forgejo│ │ (alta-client)│ │ (prompt ansible) │ │ │ └──────────────┘ └────────┬────────────┘ └──────────────┘ │ Consultas read-only ┌───────────┼───────────┐ │ │ │ VictoriaMetrics Loki Netbox (metricas) (logs) (inventario) ``` ### Agente 1: Triaje de alertas (mayor ROI) - **Trigger**: Alertmanager envia webhook a n8n - **Contexto que recopila**: - Metricas del servidor afectado (VictoriaMetrics API, ultimas 2h) - Logs recientes del servidor (Loki API, ultimos 30 min) - Datos del servidor en Netbox (cliente, tipo, rol, SLA) - Historial de alertas similares (VictoriaMetrics alerts API) - **Prompt especializado**: incluye la definicion de severidades de la empresa, SLAs por cliente, y arboles de decision para problemas comunes (disco, CPU, backup fallido, conectividad) - **Output**: Ticket en Zammad con: severidad calculada, diagnostico, acciones recomendadas, metricas relevantes embebidas - **Ejemplo real**: Alerta "pbs_gc_duration_seconds > 86400 en ACME" → agente consulta tamaño datastore, snapshots, ultimo GC exitoso, y genera: "GC de ACME lleva 26h. Datastore: 1.2TB, 340 snapshots. Ultimo GC exitoso: hace 12 dias. Recomendacion: verificar si hay un sync job concurrente bloqueando. Si no, considerar maintenance-mode y GC forzado." ### Agente 2: Capacity planning (semanal) - **Trigger**: Cron lunes 08:00 - **Contexto**: Uso de disco de todos los datastores (VictoriaMetrics), quotas ZFS, tendencias 30/60/90 dias - **Output**: Informe en Outline con tabla priorizada: ``` | Cliente | Usado | Quota | Tendencia 30d | Dias hasta lleno | Accion | |---------|-------|-------|---------------|------------------|--------| | ACME | 82% | 600GB | +2.1%/semana | ~45 dias | Avisar | | GAMMA | 91% | 300GB | +5.3%/semana | ~12 dias | URGENTE| | BETA | 34% | 1TB | estable | >1 año | OK | ``` ### Agente 3: Analisis de seguridad (evento Wazuh) - **Trigger**: Wazuh alerta nivel ≥10 via webhook - **Contexto**: Evento Wazuh completo, logs Loki del servidor (misma ventana), eventos correlacionados (mismo servidor, ultima hora), baseline de comportamiento normal del servidor - **Output**: Ticket Zammad clasificado: - **Falso positivo**: justificacion detallada de por que es benigno - **Incidente real**: pasos de respuesta recomendados, basados en el playbook de incidentes (decision-incidentes.md) - **Indeterminado**: que verificaciones adicionales hacer manualmente ### Agente 4: Asistente de provisioning - **Trigger**: Ticket Zammad con tag "alta-cliente" o webhook ICSManager - **Contexto**: Datos del cliente (nombre, GB, servidor sync), inventario Netbox (verificar duplicados), recursos disponibles en PVE destino - **Output**: Branch en Forgejo con YAML del cliente listo para revisar, o ticket actualizado con datos validados para lanzar playbook desde Semaphore ### Implementacion en n8n Cada agente es un workflow con estos nodos: ``` Webhook/Cron → HTTP Request(s) → Claude API → IF/Switch → Action(s) (trigger) (recopilar (analizar) (decidir) (actuar) contexto) ``` El nodo "Claude API" es un HTTP Request a `https://api.anthropic.com/v1/messages` con: - System prompt: instrucciones especializadas del agente + contexto de la infra - User message: datos recopilados en los pasos anteriores - Modelo: `claude-sonnet-4-6` para agentes rutinarios (mas barato, suficiente), `claude-opus-4-6` para analisis de seguridad (maximo razonamiento) ### Coste estimado | Agente | Frecuencia | Tokens/ejecucion | Modelo | Coste/mes | |--------|-----------|-------------------|--------|-----------| | Triaje alertas | ~50-100/dia | ~3000-5000 | Sonnet | $15-30 | | Capacity planning | 1/semana | ~10000 | Sonnet | $1-2 | | Seguridad Wazuh | ~5-20/dia | ~5000-8000 | Opus | $10-25 | | Provisioning | ~5-10/mes | ~3000 | Sonnet | $1-2 | | **Total** | | | | **~$30-60/mes** | --- ## 8.3 Evaluacion de OpenClaw ### Que es OpenClaw OpenClaw (antes Clawdbot/Moltbot) es un agente de IA open-source autonomo creado por Peter Steinberger. Se ejecuta localmente, conecta a LLMs (Claude, GPT, DeepSeek), y usa plataformas de mensajeria (WhatsApp, Telegram, Slack, Discord) como interfaz. Tiene 145k+ estrellas en GitHub y ~400k usuarios. Caracteristicas principales: - Corre localmente, trae tu propia API key - Multi-canal: WhatsApp, Telegram, Slack, Signal, Teams, Matrix - 100+ AgentSkills precofiguradas (ejecutar shell, gestionar ficheros, web automation) - Memoria persistente entre conversaciones - Open source (MIT) ### Ventajas potenciales para nuestro caso | Ventaja | Detalle | |---------|---------| | Multi-canal | Los tecnicos podrian interactuar via Telegram/Mattermost sin SSH | | Open source | Sin vendor lock-in, personalizable | | Skills extensibles | Podriamos crear skills para PBS, ZFS, Netbox | | Self-hosted | Control total de datos | ### Problemas criticos para nuestro caso #### 1. Seguridad: INACEPTABLE para infraestructura de produccion Este es el punto definitivo. OpenClaw tiene vulnerabilidades documentadas graves: - **Prompt injection via skills**: Cisco demostro que skills de terceros pueden hacer data exfiltration sin que el usuario lo note - **ClawJacked (marzo 2026)**: Vulnerabilidad que permite a atacantes controlar el agente via WebSocket local y acceder a datos del dispositivo - **Superficie de ataque amplia**: Un agente con acceso a shell en un servidor que gestiona 100-500 servidores de clientes es exactamente el vector de ataque que acabamos de sufrir con el backdoor PAM **Nosotros acabamos de recuperarnos de un credential stealer que tenia acceso shell. Poner un agente de IA con acceso shell y vulnerabilidades conocidas de prompt injection seria repetir el mismo error.** #### 2. Modelo de ejecucion inadecuado OpenClaw es un **agente personal** (asistente general) ejecutandose como demonio. Nuestras necesidades son **agentes especializados** con scope limitado que se ejecutan solo cuando hay un trigger. Diferencia fundamental: | Aspecto | OpenClaw | Nuestro modelo (n8n + API) | |---------|----------|---------------------------| | Ejecucion | Demonio permanente | Bajo demanda (trigger) | | Permisos | Acceso amplio al sistema | Read-only a APIs especificas | | Scope | General ("haz lo que te pida") | Especializado ("triaje de alertas") | | Auditoria | Logs propios | Logs de n8n + Loki | | Superficie de ataque | WebSocket + shell + mensajeria | Solo API HTTP saliente | | Acciones | Ejecuta directamente | Genera recomendaciones, humano aprueba | #### 3. Complejidad innecesaria - OpenClaw requiere su propia infraestructura (MongoDB para memoria, gateway, canales) - Nosotros ya tenemos n8n (orquestacion) + Zammad (interfaz humana) + Mattermost (chat futuro) - Añadir OpenClaw duplica funcionalidad sin añadir valor #### 4. Gobernanza incierta - El creador (Peter Steinberger) se unio a OpenAI en febrero 2026 - Proyecto con hype extremo pero inmaduro en seguridad - China ha restringido su uso en agencias gubernamentales por riesgos de seguridad ### Veredicto: NO usar OpenClaw **OpenClaw no encaja en nuestro caso por razones de seguridad y arquitectura.** No necesitamos un agente general con acceso al sistema. Necesitamos agentes especializados, scoped, auditables, sin acceso directo a shell. Nuestro stack ya cubre todo lo que OpenClaw ofrece de forma mas segura: - **Chat con IA**: Claude Code interactivo en Bastion (controlado, sin demonio) - **Automatizacion con IA**: n8n + Claude API (scoped, read-only, auditable) - **Mensajeria del equipo**: Mattermost/Zammad (ya decidido) - **Ejecucion de tareas**: Ansible + Semaphore (aprobacion humana) Si en el futuro OpenClaw madura en seguridad y necesitamos un asistente conversacional para tecnicos via chat, se puede reevaluar. Pero hoy, con nuestro historial de seguridad, la respuesta es clara: **no**. --- ## 8.4 Orden de implementacion | Fase | Que | Cuando | Dependencias | |------|-----|--------|-------------| | **Fase 0** | Claude Code en Bastion | Dia 1, tras desplegar Bastion | Solo API key Anthropic | | **Fase 1** | Agente triaje de alertas | Mes 1-2 | n8n desplegado, Alertmanager configurado | | **Fase 2** | Agente capacity planning | Mes 2-3 | VictoriaMetrics con historico ≥30 dias | | **Fase 3** | Agente analisis seguridad | Mes 3-4 | Wazuh maduro, baseline establecida | | **Fase 4** | Agente provisioning | Mes 4+ | Playbooks Ansible estables, Netbox poblado | ### Principios de diseño de los agentes 1. **Read-only por defecto**: Los agentes consultan APIs pero nunca ejecutan comandos en produccion 2. **Humano en el bucle**: Las acciones de escritura (tickets, MRs) son para que un humano revise y apruebe 3. **Scope minimo**: Cada agente tiene un prompt especializado y solo accede a las APIs que necesita 4. **Auditabilidad**: Todo queda en n8n (historial de ejecuciones) + Loki (logs) 5. **Coste controlado**: Sonnet para tareas rutinarias, Opus solo para analisis complejos --- ## Resumen > **Capa 8: IA y agentes para operaciones** > > - **8.1**: Claude Code interactivo en VM Bastion (copiloto para tecnicos, dia 1) > - **8.2**: Agentes automatizados via n8n + Claude API (4 agentes especializados, despliegue progresivo meses 1-4) > - **8.3**: OpenClaw evaluado y **descartado** (riesgos de seguridad inaceptables, arquitectura inadecuada, funcionalidad cubierta por stack existente) > - **8.4**: Orden de implementacion en 4 fases > > **Recursos adicionales**: ninguno (Claude Code en Bastion existente, agentes en n8n ya planificado) > **Coste operativo**: ~$30-60/mes en API Anthropic > **Herramientas nuevas**: ninguna (todo sobre stack ya decidido)