Oracle AI World 2026, que se celebra del 25 al 28 de octubre en Las Vegas, incorpora a su programa un problema que aparece cuando una organización empieza a utilizar agentes de inteligencia artificial de varios proveedores: cómo encontrarlos, distinguir sus funciones y controlar las acciones que pueden realizar. Oracle abordará esa gestión mediante AI Registry y Agent Hub, dos nombres asociados a su AI Data Platform.
La agenda contempla un hackatón este 25 de octubre, donde los participantes trabajarán con AI Registry, agentes y datos gobernados, y el laboratorio HOL2326 del martes 27, dedicado a la administración de agentes. Las actividades permiten delimitar los asuntos que Oracle pretende demostrar, aunque su programación no acredita por sí sola la disponibilidad general de todas las funciones anunciadas.

Un registro de agentes no equivale a un permiso para ejecutarlos
La primera función que conviene distinguir es la del inventario. AI Registry aparece en el programa práctico de Oracle AI Data Platform junto con los componentes de agentes, flujos, cómputo y catálogo maestro; la pauta del laboratorio HOL2326, por su parte, plantea trabajar con agentes desarrollados dentro y fuera del entorno de Oracle.
Registrar un agente permitiría tratarlo como un recurso identificable, en lugar de depender de que cada equipo conozca su dirección o la aplicación donde fue creado. Sin embargo, ni su presencia en un inventario ni la posibilidad de descubrirlo demuestran que cualquier empleado pueda utilizarlo o que tenga autorización para consultar todos los sistemas disponibles.

Agent Hub responde a una necesidad relacionada, pero distinta: ofrecer un lugar desde el cual acceder a agentes y utilizar el contexto empresarial disponible en AI Data Platform. Oracle anuncia para el hackatón la prueba de un agente mediante el nuevo Agent Hub y describe en su página comercial una interfaz conversacional unificada para agentes propios, integrados en Fusion o conectados desde terceros.
Esa presentación comercial está formulada como una capacidad prevista. Todavía corresponde verificar en las demostraciones qué clases de agentes externos admite el Hub, cómo se incorporan y qué funciones están habilitadas para cada cliente, región y configuración.
La ficha del agente explica qué ofrece, pero no sustituye la autenticación
La documentación de despliegue de AI Data Platform permite observar una parte concreta del mecanismo de identificación. Para los agentes que utilizan el protocolo Agent2Agent (A2A), Oracle contempla una ficha con nombre, descripción, versión, capacidades, habilidades, requisitos de autenticación y, opcionalmente, información sobre el proveedor.

Esta ficha tiene un estado de borrador mientras se prepara el agente y otro publicado que refleja el momento de su despliegue. Sirve para que otros sistemas conozcan cómo comunicarse con él, pero no debe confundirse automáticamente con la totalidad de las funciones de AI Registry, cuyo alcance de inventario y validación sigue pendiente de una demostración específica.
En la práctica, hay tres cuestiones diferentes: saber que el agente existe, determinar qué tareas declara poder realizar y comprobar quién está autorizado para invocarlo. La primera se relaciona con el descubrimiento, la segunda con la descripción de capacidades y la tercera con controles de acceso que deben verificarse al ejecutar la solicitud.
La identidad que ejecuta el agente es distinta de la del usuario y de sus herramientas
En un despliegue de AI Data Platform, Oracle permite elegir la identidad Run As para las operaciones del agente dentro de la plataforma: la del propio usuario o una cuenta de servicio. La documentación precisa que esta selección no decide quién puede llamar al agente ni cómo se autentican sus herramientas frente a los sistemas externos.
Por eso, la cadena de permisos no se reduce a una autorización única. Una persona necesita acceso al agente, su ejecución utiliza una identidad configurada y cada servicio al que se conecte puede exigir credenciales y políticas adicionales; autorizar un nivel no elimina las comprobaciones de los demás.

La plataforma contempla controles basados en roles y despliegues autenticados mediante OAuth2. Para seleccionar una cuenta de servicio almacenada en Credential Store, una función identificada como Preview en la documentación, se exige al menos permiso USE sobre esa credencial, mientras que la retirada de un agente desplegado requiere permiso MANAGE sobre el recurso.
La distinción resulta especialmente relevante para agentes de terceros: registrarlos o permitir que otros agentes los descubran no demuestra que Oracle administre las identidades del sistema remoto. El alcance real depende de cómo se hayan configurado la invocación, las credenciales y las autorizaciones del servicio que finalmente ejecuta la acción.


MCP amplía las herramientas disponibles, pero cada conexión conserva sus límites
Los agentes de AI Data Platform pueden construirse visualmente o mediante código y utilizar plantillas de herramientas SQL, RAG, instrucciones reutilizables, código personalizado y solicitudes HTTP. Oracle también documenta conexiones con servidores remotos mediante Model Context Protocol (MCP), entre ellos servicios de la propia compañía y plataformas de terceros.
MCP permite que un agente disponga de herramientas expuestas por otros sistemas sin desarrollar una integración particular para cada llamada. No obstante, el protocolo de conexión no sustituye los permisos de las aplicaciones de destino, ni convierte automáticamente una herramienta externa en un recurso gobernado por las mismas políticas que los datos locales.

Dentro del constructor visual se pueden distribuir funciones entre agentes especializados y un supervisor que interpreta la solicitud y decide a qué componente enviarla. Oracle documenta además controles opcionales de guardrails para revisar entradas o pasos intermedios, lo que obliga a diferenciar el recorrido de una petición de las autorizaciones efectivas de cada herramienta.
Un caso ya descrito por Oracle consiste en incorporar como herramienta un proyecto de Oracle Integration con pasos de aprobación humana. Así, un agente puede solicitar la ejecución de un flujo gobernado, mientras las validaciones y aprobaciones de ese proceso se mantienen en el servicio de integración.

Los datos gobernados aportan contexto, sin dar acceso indiscriminado a toda la organización
AI Data Platform reúne datos estructurados y no estructurados, metadatos, reglas de acceso y contexto de negocio para aplicaciones analíticas y agentes. Su catálogo maestro permite organizar metadatos de activos como tablas, vistas y esquemas sin que ese registro implique necesariamente mover o duplicar los datos originales.
El contexto empresarial comprende relaciones, métricas y reglas de los procesos que una organización utiliza para interpretar su información. Según Oracle, este nivel permite que agentes y aplicaciones trabajen con definiciones compartidas, pero su aprovechamiento depende de los permisos sobre los recursos y de la configuración de cada conexión.

La existencia de una base de datos gobernada tampoco convierte en confiable cualquier respuesta o actuación de un agente. Hay que separar la procedencia y autorización de los datos, las herramientas que ejecutan operaciones y el registro de lo ocurrido en cada paso, porque esos controles cumplen funciones diferentes.
Desplegar una nueva versión puede sustituir a la anterior en el mismo punto de acceso
Oracle documenta que, al desplegar un agente, se publica una instantánea de su estado en un entorno de cómputo de IA. Si el equipo modifica el agente y quiere actualizar el servicio, debe volver a desplegarlo; la dirección de acceso permanece estable y la nueva implementación sustituye a la anterior detrás de ese mismo punto de entrada.
La guía de despliegue también indica que un agente solo puede estar desplegado en un clúster de AI Compute a la vez. Los clientes pueden utilizar rutas para conversación y comunicación A2A, mientras que la opción Undeploy permite dejar fuera de servicio un agente sobre el que se dispone del permiso de administración correspondiente.

Esto documenta actualización y retirada, pero no acredita un mecanismo universal de reversión inmediata a cualquier versión previa. La ficha A2A incluye un campo de versión y una instantánea publicada, aunque hace falta comprobar por separado qué conserva AI Registry, cómo se recupera una versión anterior y qué sucede con las ejecuciones que ya estaban en curso.
La trazabilidad documentada no equivale a una auditoría completa de cualquier agente externo
En el entorno de pruebas, Oracle ofrece una vista de conversaciones, trazas y segmentos de ejecución (spans) para examinar cómo se procesó una solicitud. La documentación identifica atributos de esas trazas, entradas y salidas, tiempos de ejecución y eventos de error; la plataforma comercial también describe supervisión de agentes en producción.
AI Data Platform incorpora registros operativos y de auditoría asociados a accesos, actividad de usuarios, interacciones con agentes y cambios administrativos. Asimismo, al crear agentes se pueden establecer límites de retención para los datos de sesión, con opciones por tiempo, volumen almacenado o cantidad de conversaciones.

No debe inferirse de ello que el Hub almacena todas las decisiones internas de un agente externo o el contenido completo de cada consulta a un sistema de terceros. Queda por precisar qué eventos se recopilan realmente, dónde se conservan, quién puede consultarlos y cómo se correlacionan las evidencias cuando una ejecución atraviesa varias plataformas.

Agent Hub, Fusion AI Agent Studio y Oracle Integration no cumplen la misma función
La denominación de los productos importa porque Oracle desarrolla varias piezas para crear, utilizar y coordinar agentes. El constructor de AI Data Platform admite diseño visual o mediante código, mientras que Fusion AI Agent Studio se orienta a agentes para las aplicaciones Fusion y Oracle Integration aporta conectividad, orquestación de procesos y aprobaciones humanas.
La separación también se observa en la sesión LRN2288 anunciada para Oracle AI World, donde Oracle Integration se presenta como el componente que conecta agentes de Fusion, AI Data Platform, Oracle AI Database 26ai y terceros. Esa interoperabilidad prevista no significa que todas las plataformas compartan idéntico registro, permisos o mecanismos de revocación.

Lo que las actividades del 25 y 27 de octubre todavía deben aclarar
El hackatón del domingo 25 de octubre contempla AI Registry, agentes, flujos, cómputo y catálogo maestro con cuentas y datos de demostración. Para el martes 27 está programado, a las 10:00, el laboratorio Manage Agent Sprawl with Oracle AI Registry and Agent Hub (HOL2326).
Ese mismo martes, a las 13:00, T.K. Anand, vicepresidente ejecutivo de AI Data Platform y Healthcare, abordará el papel del contexto empresarial en las aplicaciones y los agentes.

Las pruebas pendientes tienen un alcance concreto: verificar cómo se registra y valida la propiedad de un agente externo, qué atributos hacen falta para publicarlo y cómo se definen sus audiencias autorizadas. También queda por determinar si retirar una herramienta bloquea de inmediato las sesiones en curso, quién puede recuperar una versión anterior y cómo se auditan decisiones repartidas entre varios servicios.
Hasta que esas cuestiones se documenten o demuestren, conviene conservar la distinción entre lo que AI Data Platform ya describe para sus agentes, lo que Oracle atribuye a sus servicios de integración y lo que el programa de AI World anuncia para AI Registry y Agent Hub.










