Empecemos por deshacer una ambigüedad de vocabulario, porque está en el origen de muchos malentendidos en este mercado. En UNYX, la orquestación designa la máquina que ejecuta. El orquestador designa a la persona cualificada que pilota esa máquina en su empresa. Las dos palabras se parecen, no designan lo mismo, y la segunda es un oficio.

Las piezas, en el orden en que las atraviesa una solicitud

  • Una puerta de entrada única. Formulario, correo, mensajería, llamada de otro programa: todo llega por un punto de paso que autentica, valida el formato y registra.
  • Una base de datos que hace autoridad. Cada solicitud se convierte allí en una fila con su estado. Los agentes nunca trabajan sobre una copia que ande por otro sitio.
  • Una cola de espera. Todo lo largo, caro o susceptible de fallar pasa por ella, con reintento y abandono motivado.
  • Agentes especializados. Un agente, una misión, un conjunto de herramientas. No un agente único que lo sepa hacer todo.
  • Una capa de reglas deterministas. Situada entre los agentes y el mundo exterior, rechaza las acciones prohibidas antes de que salgan.
  • Un registro. Cada acción lleva su autor, su motivo, su coste y su resultado.

Dónde se almacenan los datos

En una base relacional alojada en la Unión Europea, con reglas de acceso aplicadas fila a fila: un usuario solo puede leer lo que su rol autoriza, y esa verificación ocurre en el servidor, nunca en el navegador. Los documentos y archivos adjuntos viven en un almacenamiento privado accesible únicamente mediante enlaces firmados y temporales.

Las llamadas a los modelos solo transportan lo que la tarea necesita. Este punto merece plantearse a cualquier proveedor: enviar una base entera a un modelo para responder a una pregunta simple es a la vez caro e innecesariamente arriesgado.

Cómo se comunican los agentes

No conversando entre ellos en lenguaje natural, algo espectacular en una demostración e ingobernable en producción. Se comunican mediante el estado de la solicitud en la base: un agente lee un estado, produce un resultado estructurado, escribe el nuevo estado. El siguiente toma el relevo.

La ventaja es decisiva en el momento del diagnóstico: se puede abrir cualquier solicitud y leer exactamente quién hizo qué, en qué orden y con qué resultado. Una conversación entre agentes no deja ese rastro.

Un sistema que no se puede releer después no es un sistema. Es una caja negra con facturas.

Los permisos

Tres niveles, todos necesarios. El nivel de usuario, con roles y habilitaciones verificadas en cada petición. El nivel de agente, en el que cada agente recibe el mínimo estricto de herramientas y accesos que su misión exige. Y el nivel de acción, en el que las operaciones con efecto externo pasan por la capa de reglas, sea cual sea su origen.

Este último nivel es el más importante y el que más a menudo falta: la misma verificación debe aplicarse a la acción lanzada por un agente y a la lanzada por un humano desde la interfaz. Si no, la seguridad depende del camino tomado, lo que equivale a no tenerla.

Los errores

Reintento con espera progresiva ante fallos pasajeros, abandono motivado y alerta más allá, repliegue documentado cuando un modelo no está disponible, umbral de confianza que devuelve el caso a un humano y anulación real de las acciones reversibles. Detallamos este dispositivo, y la lección que lo originó, en el artículo sobre los errores.

Cómo comprobarlo

Pida una demostración en tres pantallas, no una presentación: el registro de una solicitud real de principio a fin, la pantalla en la que un humano valida una acción y el comportamiento del sistema cuando se provoca un error. Un proveedor que ha construido eso puede mostrarlo de inmediato. Nuestra página Orquestador IA explica lo demás: quién pilota, con qué compromiso y sobre qué accesos se ejecuta la IA.