Construir un agente que consulte documentos, responda preguntas o ejecute una tarea es cada vez más accesible, pero convertirlo en un servicio fiable exige resolver otras cuestiones: quién puede utilizarlo, qué información puede consultar, qué acciones tiene permitidas y cómo intervenir cuando algo falla. Al multiplicar los agentes, esas decisiones se convierten en un problema de operación y gobierno.
Pensemos en una organización con asistentes para compras, operaciones, atención al cliente y desarrollo. Cada equipo incorpora modelos, herramientas y fuentes de información. Las dependencias se cruzan. Una modificación en un permiso, una tabla o una API puede afectar a varios servicios. El volumen de conversaciones apenas explica una parte de esa complejidad.
Escalar requiere una capacidad compartida para autorizar, observar, evaluar y mantener esos sistemas durante toda su vida útil. En ALTIA acompañamos a clientes con servicios de datos e IA sobre Databricks, en los que la operación y el gobierno forman parte del trabajo. La plataforma aporta componentes relevantes, pero convertirlos en un servicio sostenible requiere arquitectura, integración y responsabilidades claras. Unity Catalog, Unity Gateway y MLflow permiten abordar distintas partes de ese reto. Omnigent añade una perspectiva complementaria para determinados entornos de trabajo con agentes. Entender sus funciones ayuda a decidir qué necesitamos y cómo llevarlo a producción.
Cada agente necesita un responsable y unos límites
El primer paso es disponer de un inventario operativo. Para cada agente necesitamos conocer su propósito, responsable de negocio, equipo de soporte, usuarios, datos, herramientas, modelos y dependencias. También el entorno en el que se ejecuta, su nivel de autonomía y los criterios que justifican mantenerlo activo. Ese inventario debe acompañar al despliegue. Un agente sin responsable, presupuesto asignado o procedimiento de retirada deja una obligación de mantenimiento que alguien tendrá que asumir. Cuando hay decenas de servicios, confiar en el conocimiento informal de sus desarrolladores hace difícil gestionar los cambios y las incidencias.
Los controles deben ser proporcionales al impacto. Consultar una política interna, proponer una respuesta y modificar un pedido requieren autorizaciones diferentes. Conviene separar explícitamente lectura, recomendación y ejecución, estableciendo en qué operaciones debe intervenir una persona. Por ejemplo: un asistente de compras puede localizar contratos y preparar una comparativa, pero autorizarlo a cambiar condiciones en el sistema de gestión exige una decisión adicional, con validaciones sobre los parámetros y el alcance de la operación. Un permiso genérico para utilizar la herramienta resulta demasiado amplio si permite tanto consultar como modificar.
La organización debe acordar estos límites entre negocio, datos, seguridad y operaciones. Después, hay que trasladarlos a identidades, permisos, políticas y comprobaciones ejecutables. Una instrucción dentro del prompt puede orientar al agente, pero la autorización de una acción debe comprobarse en el sistema que la ejecuta.
Unity Catalog: gobernar los activos y la identidad que los utiliza
Unity Catalog proporciona una base común para gobernar activos de datos e IA. Su modelo permite asignar permisos sobre tablas, vistas, volúmenes, funciones, modelos y servicios registrados, facilitando que el acceso del agente se integre en la estructura de gobierno de la organización. El diseño empieza por una decisión que suele pasar desapercibida: con qué identidad actúa cada componente. Un servicio puede utilizar una identidad técnica o ejecutar determinadas solicitudes en nombre del usuario. En Databricks Apps existen ambos modelos: la autorización delegada permite aplicar los permisos del usuario cuando se configura y utiliza correctamente.
La diferencia tiene consecuencias prácticas. Si toda la aplicación consulta datos con una identidad técnica muy amplia, esta no limita por sí sola la información recuperada. Debemos diseñar y probar ese recorrido completo, desde la entrada del usuario hasta el acceso al recurso. Para aplicar reglas de forma consistente, Unity Catalog ofrece controles por fila y columna, así como políticas basadas en atributos y etiquetas gobernadas que permiten expresar criterios comunes sobre conjuntos de activos, con los requisitos y límites de cada funcionalidad.
La aplicación de estas capacidades requiere clasificar la información, acordar quién mantiene las etiquetas y verificar los permisos efectivos. En un asistente que recupera documentación también hay que revisar los índices, las copias y las cachés: un cambio de permisos en el origen debe tener un tratamiento definido en esos componentes.
El linaje aporta otra pieza: ayuda a conocer dependencias y analizar el impacto de cambios en los activos compatibles, ya que para reconstruir una ejecución concreta necesita complementarse con las trazas de la aplicación. El linaje de datos y el registro de las llamadas de un agente responden a preguntas diferentes.
De AI Gateway a Unity Gateway: controlar el tráfico de IA
Cuando diferentes equipos consumen modelos y herramientas, necesitamos un punto común para aplicar controles sobre esas llamadas. La evolución de AI Gateway aparece en la documentación actual como Unity Gateway, integrado con Unity Catalog. Conviene distinguirlo del AI Gateway asociado a los endpoints de Model Serving anteriores, porque su alcance y configuración difieren. Su función es gobernar el tráfico que se canaliza a través de él: acceso a modelos, servicios de herramientas, límites de uso y seguimiento del consumo. Incluye servicios MCP, el protocolo utilizado para conectar agentes con herramientas y fuentes externas. La centralización ayuda a evitar que cada aplicación gestione por separado las mismas decisiones de acceso y consumo.
Ese control depende de la arquitectura. Si un agente conserva credenciales que le permiten llamar directamente a un proveedor, esa ruta queda fuera del gateway. La implantación debe contemplar las conexiones, la gestión de secretos y los caminos de salida autorizados, además de la configuración del propio servicio. En organizaciones que ya utilizan el gateway anterior, esta evolución requiere planificar una migración. Los permisos y configuraciones existentes no se trasladan automáticamente a la nueva experiencia. Hay que revisar los servicios, adaptar los clientes, recrear los controles necesarios y comprobar el recorrido de las llamadas antes de exigir el nuevo canal. Es una intervención que combina arquitectura, seguridad y continuidad operativa, y que conviene abordar por fases según las dependencias de cada aplicación.
Las políticas de servicio añaden controles sobre solicitudes y respuestas. Databricks documenta mecanismos para permitir, denegar o requerir aprobación de interacciones, junto con protecciones frente a determinados contenidos y riesgos. Estas políticas siguen en beta y su adopción debe ajustarse a la criticidad del caso y a su disponibilidad. Estos controles deben combinarse con la validación de cada acción. Un filtro de contenido no determina, por sí solo, si una modificación contractual es correcta ni sustituye las reglas del proceso de compras.
El coste necesita igualmente una visión de servicio. Los límites de peticiones y el seguimiento de consumo ayudan a controlarlo, pero el presupuesto completo incluye modelos, cómputo, recuperación de información, almacenamiento, evaluación y soporte. Nuestro enfoque es medir el coste por tarea resuelta con calidad: una llamada barata puede acabar generando más gasto si provoca reintentos, correcciones o trabajo manual. Unity Gateway permite configurar límites de frecuencia y presupuestos con alertas y bloqueo de consumo, dentro de su cobertura. Debemos comprobar qué modalidades y proveedores están incluidos y cómo se contabilizan. Los presupuestos no equivalen a un techo exacto de facturación: por ejemplo, las solicitudes que están en curso pueden continuar al alcanzarse el umbral. El diseño financiero necesita combinar estos mecanismos con seguimiento y capacidad de intervención.
El éxito de una estrategia de agentes debe medirse por las tareas que resuelve de forma fiable, dentro de los permisos acordados y con un coste sostenible. Operar cien agentes exige poder explicar cómo funcionan, detectar cuándo se desvían y actuar a tiempo. Ese es el trabajo que convierte la IA en una capacidad empresarial duradera. Hablemos de qué necesita tu organización para dar ese paso.
