Resumen ejecutivo

Este whitepaper documenta las pruebas técnicas realizadas en el laboratorio de 3w2 para evaluar OpenClaw como agente IA autónomo conectado a distintos modelos de lenguaje mediante OpenRouter, y ejecutado en Windows, Linux Mint y Ubuntu 22.04 (VPS). El objetivo fue medir la viabilidad del sistema en escenarios reales: creación de contenidos, instalaciones, análisis, automatización y pruebas relacionadas con seguridad.

La conclusión es clara: OpenClaw se encuentra en una fase temprana de madurez. Se observó una variabilidad muy elevada en resultados y comportamiento dependiendo del modelo LLM utilizado, así como limitaciones de control en ejecución de tareas con dificultad diversa, lo que lo hace no apto para producción sin supervisión constante y sin un endurecimiento significativo de seguridad.

En seguridad, el sistema presenta un perfil de riesgo elevado cuando se usa sin experiencia: superficie de ataque amplia, dependencia de configuraciones correctas, exposición potencial de tokens y riesgos asociados a la extensión de capacidades a través de skills comunitarias. La calificación global en esta evaluación es “No Apto” para despliegue productivo. Se mantiene como herramienta en observación técnica a la espera de madurez, estabilidad y controles nativos más robustos.

Índice

1. Resumen ejecutivo
2. Objetivos y alcance
3. Contexto: agentes IA autónomos y orquestación LLM
4. Metodología de pruebas
5. Entornos, sistemas y configuración
6. Diseño experimental y categorías de tareas
7. Resultados y hallazgos
8. Dependencia del modelo: variabilidad y reproducibilidad
9. Control de ejecución y autonomía real
10. Análisis de seguridad
11. Recomendaciones para 3w2
12. Conclusiones
13. Anexos técnicos

1. Objetivos y alcance

1.1 Objetivos

• Evaluar la viabilidad de OpenClaw como agente IA autónomo en tareas reales de laboratorio.
• Medir estabilidad y calidad con distintos modelos LLM servidos por OpenRouter.
• Determinar el nivel de control, trazabilidad y reproducibilidad de resultados.
• Identificar riesgos de seguridad y necesidades de endurecimiento (hardening).
• Emitir una calificación orientada a uso productivo vs. uso experimental.

1.2 Alcance

• Evaluación técnica funcional, no auditoría de seguridad formal completa.
• Pruebas en Windows, Linux Mint y Ubuntu 22.04.
• Casos de uso: contenidos, instalaciones, análisis, automatización y seguridad.
• Integración LLM vía OpenRouter y configuración operativa del gateway/TUI.

2. Contexto: agentes IA autónomos y orquestación LLM

Un agente IA autónomo combina (a) un modelo de lenguaje (LLM) con (b) herramientas (tools/skills) y (c) un
bucle de ejecución capaz de planificar, ejecutar acciones, evaluar resultados y corregir errores.
En la práctica, la “autonomía” no depende solo del LLM, sino del conjunto:
orquestación + controles + observabilidad + seguridad.

En sistemas emergentes, el riesgo principal es confundir “capacidad conversacional” con “capacidad operativa”.
Un agente productivo debe incorporar como mínimo:

• Determinismo parcial (o, al menos, reproducibilidad controlada).
• Observabilidad (logs, trazas, métricas, auditoría).
• Control de permisos (principio de mínimo privilegio).
• Sandboxing real para acciones de sistema.
• Validación (guardrails, verificación de outputs, checks previos a ejecución).

3. Metodología de pruebas

3.1 Enfoque general

Se aplicó un enfoque incremental y comparativo: misma tipología de tareas, ejecutadas en distintos entornos,
alternando modelos y configuraciones. Se registraron diferencias en:
calidad, consistencia, tasa de error, control de ejecución y exposición a riesgos.

3.2 Criterios de evaluación

• Calidad del resultado: exactitud, completitud, utilidad práctica.
• Robustez: tolerancia a fallos, manejo de ambigüedad y reintentos.
• Control: predictibilidad de acciones, respeto de límites, validación previa.
• Reproducibilidad: resultados similares ante condiciones equivalentes.
• Seguridad: exposición de tokens, permisos, ejecución de comandos, skills externas.
• Operabilidad: facilidad de despliegue, mantenimiento, debugging, upgrades.

3.3 Escala de calificación (laboratorio)

Apto: uso productivo posible con supervisión razonable y controles estándar.
Condicionado: uso acotado, en tareas no críticas, con supervisión intensiva.
No apto: no recomendable para producción; solo experimental.

4. Entornos, sistemas y configuración

4.1 Sistemas operativos y dispositivos

• Windows (10/11): pruebas de instalación, ejecución local y validación general.
• Linux Mint (laboratorio AIDA): ejecución estable de gateway y TUI con perfiles aislados.
• Ubuntu 22.04 (VPS 32 – entorno KAI): despliegue servidor, pruebas persistentes y control de servicios.

4.2 Componentes evaluados

• Gateway: punto de entrada, configuración de bind, tokens, modo local.
• TUI: interacción operativa y observación de ciclos de trabajo.
• Integración OpenRouter: variación de modelos y comportamiento emergente.
• Skills/Tools: capacidad extendida y superficie de ataque ampliada.

4.3 Configuración base

Se emplearon perfiles aislados para separar estado y configuración, y se utilizó autenticación por token en el gateway.
Aun así, se detecta que el endurecimiento completo no está “de serie” y depende de la experiencia del operador.

5. Diseño experimental y categorías de tareas

5.1 Creación de contenidos

• Redacción técnica y corporativa.
• Documentación de procesos.
• Textos SEO y comunicaciones internas.

5.2 Instalaciones y tareas de sistema

• Secuencias de instalación y configuración (entornos web, servicios, dependencias).
• Generación de comandos y verificaciones.
• Resolución de incidencias (logs, servicios, puertos, permisos).

5.3 Tareas analíticas

• Resumen estructurado, clasificación de información.
• Extracción de requisitos y plan de acción.
• Diagnóstico técnico con hipótesis y alternativas.

5.4 Pruebas de seguridad

• Revisión de exposición de credenciales y tokens.
• Riesgos de ejecución de comandos sin control.
• Riesgos por instalación/uso de skills comunitarias.
• Evaluación de configuración por defecto vs. configuración endurecida.

6. Resultados y hallazgos

6.1 Hallazgo A: estabilidad operativa desigual

El sistema funciona de forma aceptable en entornos controlados, pero aparecen fricciones en despliegues heterogéneos
(Windows vs Linux) y en escenarios persistentes de servidor. La estabilidad depende del mantenimiento del entorno, la consistencia de configuración y la disciplina operativa.

6.2 Hallazgo B: calidad funcional altamente variable

Para tareas de contenido y análisis, el rendimiento puede ser “bueno” con ciertos modelos, pero cae abruptamente con otros.
La ausencia de un mecanismo interno que normalice y valide respuestas provoca que el resultado final sea, en gran medida,
una función del modelo elegido.

6.3 Hallazgo C: planificación multi-paso insuficiente

En tareas multi-etapa (instalaciones, diagnósticos, secuencias con dependencias), se observan:

• Pérdida de coherencia entre pasos.
• Acciones prematuras sin verificación.
• Falta de “checkpoints” y “rollbacks” sistemáticos.
• Reintentos no consistentes o que repiten el fallo.

6.4 Hallazgo D: observabilidad y control insuficientes para producción

La ejecución no ofrece garantías operativas suficientes para entornos productivos con criticidad real.
La ausencia de políticas “por defecto” de validación y permisos obliga a diseñar capas adicionales
de control (hardening, sandbox, auditoría y guardrails).

7. Dependencia del modelo: variabilidad y reproducibilidad

El hallazgo central de esta evaluación es la dependencia estructural del LLM.
Cambios de modelo (vía OpenRouter) producen variaciones significativas en:

• Capacidad de planificación y descomposición de tareas.
• Precisión en comandos o instrucciones técnicas.
• Gestión de incertidumbre (reconocer límites vs. inventar).
• Consistencia del formato, seguimiento de requisitos y “memory” operacional.

Esto genera un problema práctico: no hay un comportamiento estandarizado del agente.
OpenClaw actúa como orquestador, pero sin una capa sólida de verificación, el modelo “define” la calidad final.
En producción, esta variabilidad se traduce en riesgo operacional y no reproducibilidad.

8. Control de ejecución y autonomía real

8.1 Autonomía operativa

OpenClaw muestra autonomía parcial en tareas simples, pero falla al escalar en complejidad.
El control efectivo no resulta satisfactorio para:

• Tareas con dependencias (paso A condiciona paso B).
• Escenarios con riesgo (comandos, cambios de configuración, credenciales).
• Entornos donde se requiere cumplimiento estricto de procedimientos.

8.2 Conclusión operativa

La herramienta es adecuada para prototipado, ideación y pruebas acotadas, pero no para flujos críticos.
Para aproximarse a producción se necesitarían capas externas: validación, permisos, sandboxing y auditoría completa.

9. Análisis de seguridad

9.1 Principales riesgos identificados

• Gestión de tokens: exposición accidental en logs, configuración o terminales compartidas.
• Ejecución de comandos: posibilidad de ejecutar acciones no deseadas si no existe sandbox/allowlist.
• Skills comunitarias: extensión de capacidades con cadenas de suministro no verificadas (supply chain risk).
• Permisos: riesgo alto si se opera con privilegios excesivos (root/sudo) sin segmentación.
• Datos sensibles: riesgo de filtración por prompts, herramientas o conexiones externas.

9.2 Riesgo por skills de terceros

La ampliación de capacidades mediante skills comunitarias es un vector crítico:
puede introducir comportamientos no auditados, dependencias vulnerables o
acceso a recursos no previstos. Sin un proceso de revisión y firma/verificación,
el riesgo es elevado.

9.3 Requisitos mínimos para endurecimiento

• Principio de mínimo privilegio para el proceso del agente.
• Sandbox real: contenedor/VM, perfiles AppArmor/SELinux donde aplique.
• Allowlist de comandos y herramientas; bloqueo por defecto.
• Rotación y almacenamiento seguro de tokens (vault/secret manager).
• Auditoría y logging centralizado con alertas.
• Proceso formal de revisión de skills (SCA, firmas, revisión manual).

10. Recomendaciones

10.1 Recomendación estratégica

Mantener OpenClaw en observación técnica y uso experimental controlado.
No integrar en procesos productivos ni en entornos con datos sensibles sin una capa de seguridad y control adicional.

10.2 Recomendación técnica

• Definir un “perfil laboratorio” con permisos mínimos, sandboxing y allowlists.
• Crear una matriz interna de modelos (por familias) para seleccionar según tarea, coste y fiabilidad.
• Diseñar un pipeline de verificación: checks previos y posteriores a cada acción.
• Establecer una política: sin skills de terceros salvo revisión y firma interna.
• Implementar un “modo auditoría”: logs enriquecidos, trazas, hashes de configuración, registro de prompts.

10.3 Recomendación de gobernanza

• Documentar un SOP (procedimiento estándar) para uso del agente en laboratorio.
• Definir roles: operador, revisor de seguridad, aprobador de cambios.
• Separar ambientes: pruebas, preproducción, producción (si aplica en el futuro).

11. Conclusiones

OpenClaw presenta un planteamiento prometedor, pero su implementación actual es
inmadura para producción. La variabilidad derivada del modelo LLM, el control insuficiente en tareas multi-paso
y el perfil de riesgo en seguridad impiden su adopción operativa con garantías.

Calificación global (laboratorio 3w2): No Apto. Se mantiene en seguimiento teórico-técnico hasta que
la herramienta mejore estabilidad, controles nativos y endurecimiento por defecto.

12. Anexos técnicos

npx openclaw gateway
Se recomienda operar con perfiles aislados para evitar contaminación de estado entre pruebas (por ejemplo, perfiles de desarrollo).

{
  "gateway": {
    "mode": "local",
    "bind": "loopback",
    "auth": {
      "token": "xxxxxxx"
    }
  },
  "agents": {
    "defaults": {
      "policy": {
        "allow_network": false,
        "allow_shell": false,
        "allow_filesystem_write": false
      }
    }
  },
  "logging": {
    "level": "info",
    "redact_secrets": true
  }
}