No faltan capacidades de AI. Falta masivamente arquitectura de confianza. Este es el diseño de referencia que construimos dirigiendo una empresa AI-native, y las cinco lecciones duras que le dieron forma.
La promesa y el problema
Si estás leyendo esto, probablemente estás en uno de tres grupos: estás construyendo sobre un framework open-source de agentes de AI, estás evaluando herramientas para tu equipo o estás diseñando un sistema propio para permitir que AI y humanos trabajen juntos dentro de tu organización. En los tres casos, te has topado con el mismo muro que nosotros: no faltan capacidades de AI, pero falta masivamente arquitectura de confianza.
Cada audiencia necesita un tipo distinto de valor de un artículo como este:
- Quienes construyen frameworks open-source necesitan patrones exigibles que puedan implementar en hooks, wrappers y plugins.
- Quienes evalúan herramientas necesitan criterios concretos de due diligence para separar "demos de AI" de sistemas de colaboración listos para producción.
- Quienes diseñan sistemas propios necesitan una arquitectura de referencia con límites claros, etapas de despliegue y modos de fallo.
Este artículo está diseñado para entregar las tres cosas.
Somos Lucy Labs. Nuestra misión es permitir que cada persona aproveche la AI para resolver problemas y mejorar su vida diaria. También somos una empresa AI-native, lo que significa que no solo asesoramos sobre despliegues de AI: lo vivimos. Nuestro fundador trabaja a diario junto a agentes de AI para dirigir el negocio, escribir código, gestionar operaciones y producir entregables. No como demo. Como modelo operativo real.
Ese modelo operativo nos obligó a enfrentarnos a algo que la mayoría de las organizaciones aún no ha afrontado: cuando la AI es tu compañera de trabajo, no tu chatbot, necesitas una infraestructura de confianza completamente distinta.
TL;DR (para lectores ocupados)
- Tesis central: el comportamiento de los LLM es probabilístico, así que la gobernanza debe ser determinista y externa.
- Regla principal de diseño: la política debe vivir fuera del contexto del modelo y aplicarse en código.
- Modelo de ejecución: validar → evaluar política → aplicar → auditar (con correlation IDs).
- Modelo de despliegue: Shadow → Advisory → Soft Block → Hard Block, con criterios medibles de promoción.
- Modelo humano: diseña gobernanza para el equipo que tienes ahora, con un camino claro hacia controles más maduros.
| Audiencia | Lee esto primero | Primera acción (próximos 7 días) | Señal de éxito |
|---|---|---|---|
| Constructores de frameworks open-source | "El reto técnico fundamental", "La ruta de ejecución para acciones gobernadas" | Implementar un wrapper de política before_tool_call que pueda devolver allow/warn/block/requires-approval. |
Cada llamada a herramienta gobernada produce un registro estructurado de decisión de política. |
| Evaluadores de herramientas | "Cómo se ve una buena arquitectura", "Límites de confianza" | Revisar el proveedor o herramienta contra el checklist y puntuar cada límite (A-D) como implemented, partial o missing. |
Puedes explicar exactamente dónde ocurre la aplicación, quién puede anularla y cómo se auditan las acciones. |
| Diseñadores de sistemas propios | "Plano de control vs. plano de datos", "Los ocho subsistemas" | Levantar un plano de control mínimo: registro canónico + validación determinista + motor de políticas + log de auditoría. | Las acciones de alto riesgo se bloquean o se aprueban explícitamente mediante una ruta de excepción trazada. |
Cómo llegamos aquí: dolores de crecimiento de una empresa AI-native
Lucy Labs empezó con una tesis que seguimos sosteniendo: los expertos de dominio conocen sus problemas mejor que cualquier proveedor. Nuestro trabajo no es construir soluciones para la gente, sino guiarla para que construya las suyas, usando AI como palanca. Esa filosofía moldeó todo, incluida la forma en que estructuramos nuestras propias operaciones.
Desde el principio funcionamos con AI. Un agente de AI se convirtió en una parte central de nuestro flujo diario: gestionaba documentación, redactaba especificaciones de negocio, ejecutaba scripts de validación y manejaba tareas operativas. Para una empresa pequeña y con recursos limitados, era una superpotencia. Un puñado de personas más AI podía hacer el trabajo de un equipo mediano.
Pero las superpotencias sin guardrails crean una categoría distinta de problema.
Pronto notamos deriva. Los documentos se contradecían. La terminología cambiaba sin que nadie lo detectara. Especificaciones importantes de negocio eran modificadas por flujos de AI sin rastro de auditoría. La AI hacía exactamente lo que se le pedía, pero "lo que se le pedía" no siempre era lo que debía hacer en el contexto organizativo más amplio.
Habíamos construido velocidad. No habíamos construido infraestructura de confianza.
La idea central era incómoda pero importante: cuanto más capaz se vuelve tu AI, más peligrosa se vuelve la falta de arquitectura de gobernanza. Un chatbot que responde mal es molesto. Un agente que modifica tus documentos y sistemas canónicos de negocio basándose en contexto obsoleto es un riesgo empresarial.
El reto técnico fundamental
Este es el problema en su forma más reducida, el que todo equipo que construya sistemas de colaboración con AI acabará afrontando:
Los LLM son probabilísticos. La gobernanza debe ser determinista.
Cuando pides a una AI que siga reglas poniendo esas reglas en un prompt, estás pidiendo a un sistema probabilístico que se comporte de forma determinista. Funcionará la mayor parte del tiempo. "La mayor parte" no es una postura de gobernanza; es una esperanza. En aplicaciones de bajo riesgo, la esperanza puede bastar. Cuando agentes de AI ejecutan acciones reales — modificar archivos, llamar APIs, crear documentos que impulsan decisiones de negocio, desplegar aplicaciones de producción — la esperanza no basta.
Esto lleva al principio de diseño del que depende todo lo demás en nuestro sistema:
El plano de control debe ser determinista. La política debe vivir fuera del payload.
(Capa LLM probabilística vs. capa de gobernanza determinista)
En la práctica: las reglas que gobiernan lo que la AI puede y no puede hacer no deben depender de la disposición de la AI a seguirlas. Deben ser aplicadas por código que se ejecuta de forma independiente al modelo, en una capa que el modelo no puede modificar.
Cinco lecciones duras que moldearon nuestra arquitectura
1. La gobernanza basada en prompts orienta, no aplica
Empezamos donde empiezan casi todos los equipos: escribiendo reglas en prompts de sistema e instrucciones de skills. "Comprueba siempre la propiedad antes de modificar un documento." "Nunca hagas commit de secretos." "Usa terminología canónica."
Esto funcionaba aproximadamente el 90% del tiempo. El 10% causaba problemas reales. La presión de la ventana de contexto podía dejar caer instrucciones. Situaciones nuevas activaban casos límite que el prompt no cubría.
La lección: los prompts son valiosos para guiar y dar forma a la intención, pero no son un mecanismo de aplicación. Cualquier acción cuyo fallo tenga consecuencias reales necesita una comprobación determinista fuera del bucle de razonamiento del modelo.
2. Validación sin aplicación crea fatiga de alertas
Nuestro siguiente paso fue construir tooling de validación: scripts que podían comprobar propiedad documental, escanear deriva terminológica y verificar integridad estructural. Buen comienzo. Pero el tooling solo registraba avisos. Nadie estaba obligado a actuar sobre ellos.
En pocas semanas, los logs de advertencia eran ruido. La lección: la validación debe estar conectada a la ruta de ejecución con consecuencias reales. Hay un espectro desde shadow mode (solo registrar) hasta hard blocking (detener la ejecución), y hay que recorrerlo deliberadamente, pero el estado final debe incluir aplicación real para acciones de alto riesgo.
3. La autogobernanza del agente es un problema de reflexividad
Si el agente ejecuta las comprobaciones de gobernanza y el contexto del agente está comprometido (por prompt injection, confusión de contexto o simples errores de razonamiento), las comprobaciones de gobernanza también están comprometidas. Es como tener a un guardia de seguridad que también es la persona registrada.
(Problema de reflexividad vs. aplicación externa de políticas)
La lección: la aplicación determinista debe ocurrir en componentes sobre los que el modelo de AI no pueda influir en tiempo de inferencia. Motores de políticas, permisos de archivos, flujos externos de aprobación: estos son los puntos correctos de aplicación precisamente porque no dependen del estado actual de razonamiento del modelo.
4. El modo "solo operator" no es un caso límite
La mayoría de los frameworks de gobernanza asumen equipos: múltiples revisores, propietarios de dominio, cadenas de aprobación. Si eres una startup, un fundador solo o un equipo pequeño donde una persona lleva muchos sombreros, esos frameworks no encajan.
Diseñamos "Solo Operator Mode": adaptaciones de gobernanza que mantienen propiedades de seguridad sin requerir una segunda persona. Los mecanismos clave: protocolos de demora temporal (una espera de 24 horas en cambios de alto impacto), surfacing de preocupaciones asistido por AI (el agente señala riesgos, aunque solo un humano pueda aprobar) y retrospectivas estructuradas (revisiones semanales de todas las decisiones tomadas bajo autoridad individual).
La lección: diseña tu modelo de gobernanza para el equipo que realmente tienes, no para el que te gustaría tener. Luego construye una ruta clara de mejora para cuando el equipo crezca.
5. El despliegue progresivo no es negociable
Intentamos pasar de "sin gobernanza" a "gobernanza estricta" en un solo paso. Falló de inmediato. Demasiados falsos positivos. Demasiado bloqueo de trabajo legítimo. Terminamos desactivándolo todo, lo cual era peor que no tener nada: nos enseñó a desconfiar de nuestros propios controles.
La lección: la aplicación debe ser graduada. Ahora usamos un modelo de cuatro etapas — Shadow, Advisory, Soft Block, Hard Block — y la promoción entre etapas exige evidencia medible de que la etapa anterior es estable.
(Despliegue de cuatro etapas: Shadow → Advisory → Soft Block → Hard Block)
Modos de fallo a controles (referencia)
| Modo de fallo | Control determinista | Métrica mínima a seguir |
|---|---|---|
| Instrucciones de prompt omitidas o mal interpretadas | Validación externa + motor de políticas antes de la ejecución | % de acciones gobernadas evaluadas por política |
| La validación corre pero nadie actúa sobre los avisos | Etapas de aplicación con resultados explícitos (warn/block/requires-approval) |
Tasa de reconocimiento de advertencias |
| El agente intenta gobernarse a sí mismo en un contexto comprometido | Aplicación en componentes externos que el modelo no puede modificar | % de decisiones de política producidas fuera del runtime del modelo |
| Equipos pequeños evitan la gobernanza por "demasiado pesada" | Ruta de excepción segura para solo operator con demora temporal para cambios de alto riesgo | % de cambios de alto riesgo con demora + retrospectiva |
| Controles estrictos provocan colapso del flujo de trabajo | Despliegue por etapas con criterios de promoción y rollback | Tasa de falsos positivos y tasa de excepciones por etapa |
La arquitectura: una referencia para sistemas de colaboración AI/humano
Separación entre plano de control y plano de datos
La decisión estructural más importante de todo el sistema es la separación entre el plano de control y el plano de datos.
El plano de datos es donde la AI hace su trabajo: razonar, generar contenido, llamar herramientas, interactuar con usuarios. Es probabilístico por naturaleza. Es donde opera el LLM.
El plano de control es donde ocurre la gobernanza: decisiones de política, comprobaciones de validación, flujos de aprobación, logging de auditoría, control de cambios. Esto debe ser determinista.
La regla no negociable: el plano de datos no puede saltarse el plano de control para acciones gobernadas. Si una acción está gobernada, debe pasar por validación determinista y evaluación de políticas antes de ejecutarse.
(Plano de datos (probabilístico) vs. plano de control (determinista))
La ruta de ejecución para acciones gobernadas
(Ruta de ejecución: solicitud → validación → política → allow/warn/block/approve → auditoría)
Cuando se solicita una acción gobernada, la ruta de ejecución se ve así:
- La solicitud entra por un channel gateway. El gateway gestiona autenticación, gestión de sesión y enrutamiento inicial. Venga la solicitud de una interfaz de chat, una CLI o una llamada API, entra por el mismo gateway con el mismo modelo de identidad.
- La solicitud se enruta a una workflow skill. Las skills son definiciones de flujo estructuradas y con plantilla, no prompts libres. Una skill especifica qué contexto hace falta, qué herramientas están disponibles, qué validación debe pasar y cómo debe ser la salida esperada.
- Se ejecuta validación determinista. Antes de que se ejecute cualquier acción de alto riesgo, un motor de validación corre una batería de comprobaciones deterministas: verificación de propiedad, cumplimiento terminológico, integridad estructural, escaneo de secretos, aplicación de políticas de ruta. Cada comprobación produce un resultado legible por máquina.
- La evaluación de políticas ocurre en un motor externo. Los resultados de validación se envían a un motor dedicado de políticas. El motor devuelve una decisión determinista: allow, warn, block o requires-approval. La lógica de política está escrita en código, versionada en Git y testeable con unit tests. Nunca depende del razonamiento del LLM.
- La decisión se aplica. Si es "allow", la acción continúa y se registra. Si es "warn", la acción continúa pero la advertencia se muestra y se registra. Si es "block", la acción se detiene y se explica al usuario por qué. Si es "requires-approval", la solicitud entra en un flujo de excepción.
- Todo se registra con correlation IDs. Cada decisión de política, resultado de validación y solicitud de excepción recibe un correlation ID y se escribe en un almacén estructurado de auditoría.
Los ocho subsistemas
(Ocho subsistemas: capas de Foundation, Runtime, Enforcement y Evolution)
La arquitectura se descompone en ocho subsistemas, cada uno con responsabilidades claras:
01 Operating Model. La base de gobernanza: quién tiene autoridad sobre qué, cómo escalan las decisiones, qué SLAs aplican. La mayoría de equipos se salta esto. Cuando falta, es lo que más dolor causa.
02 Canonical Registry. Un registro legible por máquina de todos los artefactos gobernados, con propiedad, clasificación de datos, estado de ciclo de vida y fechas de revisión. Sin él, la validación no tiene contexto y la política no tiene datos.
03 Runtime Topology. Define los límites alrededor de la ejecución de agentes: acceso al workspace, herramientas disponibles, aislamiento de sesión, límites de contexto. Privilegios mínimos por defecto.
04 Skills and Workflow Engine. Las skills son interfaces estructuradas entre usuarios y ejecución con AI. Cada skill especifica entradas, contexto requerido, herramientas disponibles, gates de validación y salidas esperadas. Ejecución template-first: la AI opera dentro de un marco definido.
05 Validation and Gates. El núcleo de validación determinista. Ejecuta comprobaciones, alimenta resultados al motor de políticas y aplica decisiones. Deterministic-first: se priorizan comprobaciones que siempre producen el mismo resultado para la misma entrada frente a comprobaciones semánticas basadas en LLM.
06 Exceptions and Human Ops. Cuando la política bloquea una acción, debe existir una ruta controlada de override; si no, la gente bordea los controles por completo. El flujo de excepción requiere declaración de riesgo, justificación de negocio, aprobación humana autorizada, expiración obligatoria y retrospectiva para excepciones críticas.
07 Observability and Learning. El sistema debe producir telemetría que permita mejora continua: tasas de falsos positivos, frecuencia de bypass, latencia de validación, patrones de excepción. Estos datos alimentan un bucle de calibración: el sistema mejora con el tiempo, pero solo mediante cambios revisados por humanos en reglas deterministas.
08 Rollout and Change Control. El motor de despliegue por etapas. Shadow → Advisory → Soft Block → Hard Block, con criterios medibles de promoción en cada etapa y procedimientos de rollback probados. Sin evidencia no hay promoción de etapa. No se saltan etapas.
Límites de confianza
(Cuatro límites de confianza: canales externos, runtime de agente, servicios internos, APIs externas)
La arquitectura define cuatro límites de confianza, cada uno con identidad autenticada del llamante, política allow/deny, logging estructurado y comportamiento fail-safe:
- Límite A: Canales externos al agent gateway. Donde se establece la identidad del usuario y se asignan niveles de confianza específicos del canal.
- Límite B: Runtime del agente a wrappers de herramientas. Donde ocurre la aplicación de política para llamadas individuales a herramientas. El wrapper decide qué está permitido hacer al agente.
- Límite C: Wrappers de herramientas a infraestructura interna. Donde importa el alcance de credenciales. Cada integración de servicio usa credenciales dedicadas con los permisos mínimos necesarios.
- Límite D: Servicios internos a APIs externas. Donde vive el control de acceso saliente. El acceso de agentes a internet se limita a servicios concretos con propósitos concretos.
El stack de componentes
(Stack de componentes: runtime de agente, capa de políticas, capa de datos, capa de seguridad)
El stack al que hemos convergido y por qué:
- Agent runtime: OpenClaw — open-source, local-first, con hooks de gobernanza incorporados, políticas de herramientas, sandboxing y plantillas de skills.
- Evaluación de políticas: Open Policy Agent (OPA) — policy-as-code en Rego, versionada, testeable con unit tests, evaluación de función pura sin efectos secundarios.
- Orquestación de flujos: n8n — para flujos asíncronos de excepción con human-in-the-loop: aprobaciones, temporizadores de SLA, cadenas de escalado.
- Estado y almacenamiento de auditoría: PostgreSQL — estructurado, consultable, fiable.
- Observabilidad: Langfuse — trazado end-to-end de flujos gobernados, cobertura de evaluación e instrumentación del bucle de feedback.
- Identidad y secretos: Authentik (SSO e identidad de servicio) y Vaultwarden (gestión de secretos). Secretos hardcodeados, nunca.
Una nota sobre proxies de modelos: La aplicación de gobernanza ocurre en la capa de ejecución de herramientas, no en la capa de solicitud al modelo. Cuando el LLM decide llamar a una herramienta, la aplicación ocurre en el wrapper de la herramienta: ahí es donde se comprueba la política y se permiten o bloquean acciones. La solicitud al LLM en sí no necesita pasar por un proxy para que la gobernanza funcione.
Cómo se ve una buena arquitectura: checklist
- ¿Tu plano de control opera de forma independiente al LLM? Si el modelo puede razonar una forma de rodear tus controles, no son controles: son sugerencias.
- ¿Tu política puede evaluarse y probarse fuera del runtime del agente? ¿Puedes escribir un unit test para una decisión de política? Si no, tu política es implícita e inverificable.
- ¿Tienes un modelo de despliegue progresivo? ¿Puedes pasar de "solo registrar" a "bloqueo duro" con criterios medibles en cada etapa?
- ¿Tienes una ruta de excepción? Cuando tus controles bloqueen trabajo legítimo (y lo harán), ¿existe una forma estructurada y auditable de anularlos?
- ¿Todo es auditable? ¿Puedes reconstruir exactamente qué decisión de política se tomó, por quién, con qué evidencia y qué ocurrió como resultado?
- ¿Tu sistema degrada con seguridad? Si tu motor de políticas cae, ¿el sistema vuelve a un estado seguro por defecto en vez de detenerse por completo?
- ¿Estás diseñando para el equipo que realmente tienes? Construye para hoy, con un camino claro hacia mañana.
Planes de acción de 30 días por audiencia
Si estás construyendo sobre un framework open-source de agentes
- Instrumenta cada llamada a herramienta con un wrapper que emita un objeto normalizado de entrada de política.
- Añade comprobaciones deterministas previas para propiedad, política de rutas y escaneo de secretos.
- Añade resultados de política (
allow/warn/block/requires-approval) antes de la ejecución, no después. - Guarda decisiones en una tabla de auditoría indexada por correlation ID y session ID.
- Ejecuta 2 semanas en Shadow mode y ajusta comprobaciones antes de bloquear nada.
Si estás evaluando herramientas de proveedor para tu equipo
- Pregunta dónde ocurre la aplicación y pide pruebas (logs, capturas o trazas de demo).
- Confirma si las decisiones de política son deterministas y testeables fuera de prompts.
- Valida el manejo de excepciones: quién puede aprobar, bajo qué SLA y con qué expiración.
- Confirma controles de límites: identidad en entrada, política en herramientas, credenciales acotadas, restricciones de salida.
- Exige logs de auditoría exportables para análisis de incidentes y revisiones internas de gobernanza.
Si estás diseñando un sistema AI/humano propio
- Empieza con un registro canónico (
artifact → owner → criticality → review date). - Implementa validadores deterministas como código y conéctalos a un motor de políticas.
- Construye un flujo simple de excepción con declaración de riesgo y expiración obligatorias.
- Define gates de despliegue desde el principio (Shadow → Advisory → Soft Block → Hard Block).
- Revisa métricas semanalmente y ajusta reglas mediante cambios de política versionados.
Evita: construir los ocho subsistemas a la vez antes de demostrar el flujo end-to-end en un único workflow gobernado.
Volviendo al punto central
(Bucle de feedback Confianza → Valor personal → Adopción → Capacidad → Escala)
Todo vuelve a una sola cadena: Confianza → Valor personal → Adopción → Capacidad → Escala. No puedes obtener valor de la colaboración con AI sin confianza. No puedes obtener confianza sin arquitectura que se la gane. No puedes escalar esa confianza sin gobernanza determinista, auditable y humana.
Nuestra misión en Lucy Labs es permitir que cada persona del planeta aproveche la AI para resolver problemas y mejorar su vida diaria. Esa misión requiere un mundo donde las personas puedan construir soluciones impulsadas por AI de forma segura, donde exista la arquitectura para mantener a los humanos al mando mientras la AI hace lo que mejor sabe hacer.
Estamos construyendo esa arquitectura en abierto. Esperamos que este artículo te ayude a construir la tuya.
Escríbenos si quieres hablar sobre tu arquitectura →
Travis Sheppard es el fundador de Lucy Labs. Lleva veinte años construyendo el músculo operativo que hace que las empresas escalen de verdad, y ahora está construyendo Lucy para poner ese músculo detrás de cada persona que aprende a trabajar con AI.