AI as operator, not owner¶
Principio de diseño para agentes AI con autoridad sobre infra: fixean automáticamente patterns conocidos, piden aprobación humana para cambios significativos, documentan todo, y el humano mantiene control overall. Es el contrato de seguridad mínimo para que un AI agent corra 24/7 sin volverse un riesgo.
Contexto¶
Para Q10 (AI tooling) y Q7 (LLM en runtime), este principio es la barandilla. Sin él, los agentes están en uno de dos extremos malos: o demasiado tímidos (cada decisión pide approval, no aportan valor) o demasiado autónomos (toman decisiones que el humano nunca habría aprobado). El principio define el rango operable en el medio.
Contenido¶
Las 4 reglas (formulación de madebynathan)¶
- Fixea known issue patterns autonomously.
- Pide aprobación humana para significant changes.
- Documenta todas las acciones (no es opcional).
- El humano mantiene control overall.
Cómo se opera concretamente¶
Definir el "perímetro autónomo"¶
Lista explícita de acciones que el agente puede tomar sin pedir permiso: - Restart de un servicio (pod / container / systemd unit). - Renovar un certificado expirado (cert-manager trigger). - Limpiar logs viejos / liberar disco. - Re-apply de un manifest desde git (drift correction). - Reabrir un PR fallido por test transitorio.
Todo lo que no está en esa lista, pide approval. La aprobación puede ser:
- PR review en GitHub (vía gh).
- Mensaje en Telegram con botones aprobar/rechazar.
- Email con link único.
Definir el "perímetro prohibido"¶
Lista de acciones que el agente nunca debe tomar, ni con approval automatizado: - Borrar datos (DB drops, file removes). - Cambios en firewall / network policies. - Rotar secrets / credentials sin coordinación. - Cambios de schema de DB. - Operar sobre datos sensibles (PII).
Estas requieren intervención humana directa.
Documentación = primera ciudadana¶
Cada acción del agente produce un registro: - Commit message si el cambio entra por git. - Comentario en el PR si abrió uno. - Entry en un log estructurado (JSON Lines) que va a Loki. - Mensaje en el canal de alertas con resumen.
Esto sirve para auditar después y para que el humano sepa qué pasó mientras dormía.
Por qué importa especialmente en smart home¶
- Los essentials (luces críticas, calefacción, seguridad) tienen alta consecuencia ante decisiones malas.
- El usuario no está siempre disponible para aprobar cambios — pero ciertos cambios sí deben esperar.
- Si el agente "se da cuenta solo" de un problema y "lo soluciona" sin documentar, el usuario pierde el rastro.
Aplicación práctica al setup del usuario:
| Componente | Perímetro autónomo | Pide approval | Prohibido |
|---|---|---|---|
| HA Container (experimental) | restart pod, re-apply config desde git | upgrade de versión, cambio de network | borrar /config, rotar tokens |
| HA Yellow (essentials) | (probablemente vacío — no dar acceso al essentials al inicio) | cualquier cambio | todo lo destructivo |
| ESPHome devices | OTA con firmware ya validado en repo | flash de firmware nuevo no probado | nada (no hay datos) |
| Z2M | rejoin de device, restart | re-pair masivo | borrar database.db, cambiar coordinator |
Riesgo del antipattern: "AI as owner"¶
Si un agente actúa como owner, opera como humano principal: - Hace cambios sin consultar. - Define su propia política. - Decide qué documentar.
Eso es inadecuado para un componente que falla silenciosamente (LLMs alucinan), no entiende consecuencias económicas/legales, y no puede ser interpelado por un juez si rompe algo importante. La diferencia entre operator y owner es la fuente de la autoridad última: para operator, es el humano; para owner, es el propio agente.
Relaciones¶
- Embodied en: ../entities/openclaw (el caso concreto que opera bajo este modelo).
- Parte de: self-healing-infrastructure (capa 5).
- Contrasta con: "AI as advisor" (sólo sugiere, no actúa) y "AI as owner" (decide solo).
- Relacionado con: principios de building-in-the-open (transparencia) y ../concepts/ha-update-best-practices (documentación).
Citas / evidencia¶
-
"OpenClaw has access but follows strict rules: fixes known issue patterns autonomously, requests approval for significant changes, documents all actions, and humans maintain overall control." — ../sources/madebynathan-self-healing-2026-02.
-
"The AI can restart services but cannot delete data." — ../sources/madebynathan-self-healing-2026-02.
Abierto / gaps¶
- ¿Cómo se expresa el perímetro autónomo en código (tool whitelist, prompt rules, policy engine)?
- Casos límite: agente decide que un patrón es "known" cuando en realidad es nuevo y debió escalar. Cómo se detecta.
- Métrica: % de acciones del agente que terminaron con humano "deshacer" — tolerable < 5%, problemático > 10%.
- Connecting tissue: este principio en runtime de automation (Q7) vs gestión de infra (Q10) — ¿mismos principios, distintos perímetros?