Plan2026/11-decision-ia-agentes.md

# 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)