No faltan capacidades de IA. Hay una enorme carencia de arquitectura de confianza. Este es el diseño de referencia que construimos dirigiendo una empresa nativa de IA, 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 de agentes de IA de código abierto, estás evaluando herramientas para tu equipo o estás diseñando un sistema propio para permitir que IA 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 IA, pero hay una enorme carencia de arquitectura de confianza.

Cada audiencia necesita un tipo distinto de valor de un artículo como este:

  • Quienes construyen frameworks de código abierto necesitan patrones exigibles que puedan implementar en hooks, wrappers y plugins.
  • Quienes evalúan herramientas necesitan criterios concretos de diligencia debida para separar «demos de IA» 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 del planeta aproveche la IA para resolver problemas y mejorar su vida diaria. También somos una empresa nativa de IA, lo que significa que no solo hablamos de despliegues de IA: lo vivimos. Nuestro fundador trabaja a diario junto a agentes de IA 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 IA es tu compañera de trabajo, no tu chatbot, necesitas una infraestructura de confianza completamente distinta.

En resumen (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 identificadores de correlación).
  • Modelo de despliegue: Observación sin intervención → Avisos → Bloqueo flexible → Bloqueo estricto, 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 de código abierto «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 la herramienta con la lista de comprobación y clasificar cada límite (A-D) como implementado, parcial o ausente. 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 + registro 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 nativa de IA

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 IA como palanca. Esa filosofía moldeó todo, incluida la forma en que estructuramos nuestras propias operaciones.

Desde el principio funcionamos con IA. Un agente de IA 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 IA podía hacer el trabajo de un equipo mediano.

Pero las superpotencias sin salvaguardas 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 IA sin rastro de auditoría. La IA 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 IA, 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 IA acabará afrontando:

Los LLM son probabilísticos. La gobernanza debe ser determinista.

Cuando pides a una IA 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 IA 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.

En la práctica: las reglas que gobiernan lo que la IA puede y no puede hacer no deben depender de la disposición de la IA 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, pero no hace cumplir las reglas

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 herramientas de validación: scripts que podían comprobar propiedad documental, escanear deriva terminológica y verificar integridad estructural. Buen comienzo. Pero las herramientas solo registraban 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 el modo de observación sin intervención (solo registrar) hasta el bloqueo estricto (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 inyección de prompts, confusión de contexto o simples errores de razonamiento), las comprobaciones de gobernanza también están comprometidas. Es como si el mismo guardia hiciera el registro y decidiera si el registro fue válido.

La lección: la aplicación determinista debe ocurrir en componentes sobre los que el modelo de IA 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 de operador único 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 desempeña muchas funciones, esos frameworks no encajan.

Diseñamos el «Modo de operador único»: 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), identificación de motivos de preocupación asistida por IA (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 (Observación sin intervención, Avisos, Bloqueo flexible, Bloqueo estricto) y la promoción entre etapas exige evidencia medible de que la etapa anterior es estable.

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 entorno de ejecución del modelo
Equipos pequeños evitan la gobernanza por «demasiado pesada» Ruta de excepción segura para un operador único 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 reversión Tasa de falsos positivos y tasa de excepciones por etapa

La arquitectura: una referencia para sistemas de colaboración entre la IA y las personas

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 IA 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, registro 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.

La ruta de ejecución para acciones gobernadas

Cuando se solicita una acción gobernada, la ruta de ejecución se ve así:

  1. La solicitud entra por una pasarela de canales. La pasarela 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 la misma pasarela con el mismo modelo de identidad.
  2. La solicitud se enruta a una skill de flujo de trabajo. 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.
  3. 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.
  4. 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 pruebas unitarias. Nunca depende del razonamiento del LLM.
  5. 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.
  6. Todo se registra con identificadores de correlación. Cada decisión de política, resultado de validación y solicitud de excepción recibe un identificador de correlación y se escribe en un almacén estructurado de auditoría.

Los ocho subsistemas

La arquitectura se descompone en ocho subsistemas, cada uno con responsabilidades claras:

01 Modelo operativo. 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 Registro canónico. 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 Topología del entorno de ejecución. Define los límites alrededor de la ejecución de agentes: acceso al espacio de trabajo, herramientas disponibles, aislamiento de sesión, límites de contexto. Privilegios mínimos por defecto.

04 Motor de skills y flujos de trabajo. Las skills son interfaces estructuradas entre usuarios y ejecución con IA. Cada skill especifica entradas, contexto requerido, herramientas disponibles, controles de validación y salidas esperadas. Ejecución basada primero en plantillas: la IA opera dentro de un marco definido.

05 Validación y controles. El núcleo de validación determinista. Ejecuta comprobaciones, alimenta resultados al motor de políticas y aplica decisiones. Prioridad a las comprobaciones deterministas: se priorizan comprobaciones que siempre producen el mismo resultado para la misma entrada frente a comprobaciones semánticas basadas en LLM.

06 Excepciones y operaciones humanas. Cuando la política bloquea una acción, debe existir una ruta controlada de anulación; 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 Observabilidad y aprendizaje. El sistema debe producir telemetría que permita mejora continua: tasas de falsos positivos, frecuencia de elusión de controles, 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 Despliegue y control de cambios. El motor de despliegue por etapas. Observación sin intervención → Avisos → Bloqueo flexible → Bloqueo estricto, con criterios medibles de promoción en cada etapa y procedimientos de reversión probados. Sin evidencia no hay promoción de etapa. No se saltan etapas.

Límites de confianza

La arquitectura define cuatro límites de confianza, cada uno con identidad autenticada del llamante, política allow/deny, registro estructurado y comportamiento seguro ante fallos:

  • Límite A: Canales externos a la pasarela del agente. Donde se establece la identidad del usuario y se asignan niveles de confianza específicos del canal.
  • Límite B: Entorno de ejecución 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 conjunto de componentes

El conjunto de componentes que hemos adoptado y por qué:

  • Entorno de ejecución del agente: OpenClaw, de código abierto, con prioridad a la ejecución local, con hooks de gobernanza incorporados, políticas de herramientas, sandboxing y plantillas de skills.
  • Evaluación de políticas: Open Policy Agent (OPA), políticas como código en Rego, versionada, testeable con pruebas unitarias, evaluación de función pura sin efectos secundarios.
  • Orquestación de flujos: n8n, para flujos asíncronos de excepción con intervención humana: aprobaciones, temporizadores de SLA, cadenas de escalado.
  • Estado y almacenamiento de auditoría: PostgreSQL, estructurado, consultable, fiable.
  • Observabilidad: Langfuse, trazado de principio a fin de flujos gobernados, cobertura de evaluación e instrumentación del ciclo de retroalimentación.
  • Identidad y secretos: Authentik (SSO e identidad de servicio) y Vaultwarden (gestión de secretos). Secretos escritos en el código, 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: lista de comprobación

  • ¿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 entorno de ejecución del agente? ¿Puedes escribir una prueba unitaria 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 estricto» 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 de agentes de código abierto

  1. Instrumenta cada llamada a herramienta con un wrapper que emita un objeto normalizado de entrada de política.
  2. Añade comprobaciones deterministas previas para propiedad, política de rutas y escaneo de secretos.
  3. Añade resultados de política (allow/warn/block/requires-approval) antes de la ejecución, no después.
  4. Guarda decisiones en una tabla de auditoría indexada por identificador de correlación e identificador de sesión.
  5. Ejecuta el sistema durante 2 semanas en modo de observación sin intervención y ajusta las comprobaciones antes de bloquear nada.

Si estás evaluando herramientas de proveedor para tu equipo

  1. Pregunta dónde ocurre la aplicación y pide pruebas (logs, capturas o trazas de demo).
  2. Confirma si las decisiones de política son deterministas y testeables fuera de prompts.
  3. Valida el manejo de excepciones: quién puede aprobar, bajo qué SLA y con qué expiración.
  4. Confirma controles de límites: identidad en entrada, política en herramientas, credenciales acotadas, restricciones de salida.
  5. Exige logs de auditoría exportables para análisis de incidentes y revisiones internas de gobernanza.

Si estás diseñando tu propio sistema de colaboración entre la IA y las personas

  1. Empieza con un registro canónico (artefacto → responsable → criticidad → fecha de revisión).
  2. Implementa validadores deterministas como código y conéctalos a un motor de políticas.
  3. Construye un flujo simple de excepción con declaración de riesgo y expiración obligatorias.
  4. Define controles de despliegue desde el principio (Observación sin intervención → Avisos → Bloqueo flexible → Bloqueo estricto).
  5. 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 de principio a fin en un único flujo de trabajo gobernado.

Volviendo al punto central

Todo vuelve a una sola cadena: Confianza → Valor → Adopción → Capacidad → Escala. No puedes obtener valor de la colaboración con IA 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 IA para resolver problemas y mejorar su vida diaria. Esa misión requiere un mundo donde las personas puedan construir soluciones impulsadas por IA de forma segura, donde exista la arquitectura para mantener a los humanos al mando mientras la IA 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 →

Lucy Labs crea a Lucy, una coach de IA que ayuda a empresas y personas a obtener la visibilidad, el saber hacer, las habilidades y los datos que necesitan para rediseñar su forma de trabajar y sacar un rendimiento real a la IA. Para consultas, visita lucylabs.ai.