Un agente que se incorpora a la empresa necesita un portátil y una tarjeta de acceso

Ilustración conceptual generada con IA. El portátil y la tarjeta representan la ejecución y el acceso a los sistemas de negocio.

Cuando llega una persona nueva a la empresa, normalmente se le preparan dos cosas.

Un ordenador para abrir archivos, ejecutar programas y trabajar. Y unas cuentas con permisos para entrar en los sistemas internos, consultar documentos y utilizar el CRM, leyendo y modificando datos dentro de sus responsabilidades.

Con un portátil pero sin cuentas, cuesta empezar. Con cuentas pero sin un entorno de trabajo adecuado, muchas tareas siguen siendo imposibles.

Los agentes de IA se encuentran con dos requisitos parecidos al incorporarse a una empresa.

Necesitan un entorno donde ejecutar tareas y un mecanismo de acceso autorizado a los sistemas de negocio. Un sandbox puede proporcionar lo primero. Las pasarelas de conexión y autorización, como OpenConnector, se ocupan de lo segundo.

Estas dos bases ayudan a convertir las capacidades de un agente en trabajo real dentro de la empresa.

De responder preguntas a asumir trabajo

Las tareas útiles suelen abarcar varios sistemas.

Imagina que pides al agente preparar la reunión de mañana con un cliente: comprobar los asistentes en el calendario, revisar los últimos correos, resumir el avance de la cuenta en el CRM y escribir los temas de conversación en el documento de la reunión.

Hace falta criterio y también acceso. El agente debe saber dónde buscar, con qué cuenta, qué información puede leer y dónde guardar el resultado.

Si además debe actualizar el estado del cliente o enviar invitaciones, cambian los permisos necesarios. Leer una ficha no concede derecho a modificar oportunidades. Consultar el correo no autoriza a enviarlo en nombre de la empresa.

En nuestro artículo sobre seguridad de los datos de los agentes explicamos que contar con suficiente contexto de negocio permite tomar mejores decisiones. Ahora hay que resolver cómo dar acceso a ese contexto y a las operaciones necesarias.

Las personas utilizan cuentas, roles y permisos para entrar en los sistemas. Los agentes también necesitan límites claros.

El sandbox es el ordenador de trabajo del agente

Las personas ejecutan programas en su ordenador. Los agentes necesitan un entorno de ejecución.

Pueden ejecutar código, procesar hojas de cálculo, generar archivos o manejar un navegador. El sandbox limita los archivos, procesos y recursos de red a los que puede acceder un programa, según su implementación y configuración. La explicación técnica de Anthropic describe el papel del aislamiento del sistema de archivos y de la red en la ejecución de agentes.

Se parece a entregar un ordenador de empresa: se proporcionan herramientas y se establecen límites de uso.

Pero poder ejecutar programas no da acceso automático al sistema financiero. Un sandbox capaz de ejecutar código tampoco recibe por sí solo acceso legítimo al CRM o a las aplicaciones internas.

El sandbox responde a esta pregunta: ¿dónde se ejecuta el agente y qué permite ese entorno?

Acceder a los sistemas de negocio requiere otra base.

La pasarela es el control de acceso detrás de la tarjeta

La tarjeta representa una identidad. El sistema de control determina qué puertas abre. Las cuentas, los roles y las autorizaciones del software empresarial cumplen una función parecida.

La pasarela de conexión y autorización asume parte de esa función para el agente: gestiona conexiones y credenciales, comprueba los permisos de llamada y entrega las operaciones permitidas al sistema de destino.

Conectar una aplicación es solo el principio. Un acceso que deba mantenerse necesita responder también a preguntas concretas:

• ¿Qué cuenta se utiliza y en nombre de quién?
• ¿Qué se puede leer y qué escrituras están permitidas?
• ¿Dónde se guardan, protegen y renuevan las credenciales externas?
• ¿Se puede localizar la causa y el registro de una llamada fallida?
• ¿Cómo se retira el acceso cuando termina la tarea o cambia la responsabilidad?

Guardar las claves de todas las aplicaciones directamente en el entorno del agente reparte estas responsabilidades entre scripts, configuraciones y despliegues. Un cambio de modelo o de entorno puede obligar a revisarlo todo de nuevo.

La pasarela ofrece un límite central para las conexiones y la autorización. El agente solicita operaciones mediante interfaces permitidas; las credenciales originales quedan bajo la gestión de la pasarela y las operaciones se comprueban al ejecutarse.

«Limítate a leer los datos» puede escribirse en una instrucción. Hacer cumplir «esta llamada no tiene permiso de escritura» requiere un control del sistema. Esa restricción ayuda a delegar operaciones reales de forma gradual.

Dos límites que protegen partes distintas

El sandbox y la pasarela pueden trabajar juntos.

Esquema conceptual de una llamada a través de una pasarela. Cada capa limita un ámbito distinto; las capacidades dependen del despliegue y la configuración.

Infraestructura	Analogía con una incorporación	Pregunta principal
Sandbox	Ordenador de trabajo	¿Dónde se ejecuta código y se procesan archivos?
Pasarela de conexión y autorización	Control detrás de la tarjeta	¿Qué cuenta y qué operaciones se pueden utilizar?

Un programa puede permanecer dentro del sandbox y enviar solicitudes por una conexión de red autorizada. Si dispone de credenciales que permiten borrar registros de clientes, el sandbox no sabe por sí mismo si ese borrado encaja con su función.

Del mismo modo, pasar las llamadas por una pasarela no gestiona todos los archivos descargados, scripts locales y resultados temporales. Esos elementos siguen necesitando un entorno adecuado.

Ambos límites son especialmente importantes para agentes que ejecutan código, procesan archivos y operan en varias aplicaciones.

El despliegue empresarial también requiere gestión de identidades, coordinación de tareas, aprobación y verificación de resultados. Algunas tareas realizadas solo mediante API controladas no necesitan un sandbox independiente. La analogía destaca dos capacidades básicas: ejecución y acceso concedido al negocio.

Por qué esta capa merece atención a largo plazo

Una llamada correcta puede mostrar el potencial en una demostración. El uso continuo plantea otra pregunta: ¿pueden varios agentes utilizar los mismos sistemas de forma fiable, con diferentes cuentas y responsabilidades?

Hoy un asistente prepara información de clientes. Mañana lo sustituye otro modelo. Después se incorpora un agente de pedidos. El CRM, los documentos, el correo y las aplicaciones internas suelen permanecer, junto con sus necesidades de conexión y permisos.

Si cada agente se integra por separado, se repiten la adaptación a las API, el almacenamiento de credenciales, la renovación de tokens, las restricciones y el diagnóstico de errores.

Una infraestructura reutilizable permite aprovechar conexiones existentes y asignar permisos según el papel del nuevo agente. Los desarrolladores dedican más tiempo a los procesos de negocio y la empresa mantiene reglas más coherentes.

Cuando los agentes asumen trabajo real, la conexión y la autorización se convierten en necesidades recurrentes.

Para los desarrolladores es ingeniería compartida que merece esfuerzo. Para las empresas, un límite arquitectónico que conviene planificar. Para los inversores que estudian el sector, es un ámbito de infraestructura que merece análisis. Su valor duradero depende de reducir integraciones repetidas, reutilizar capacidades en distintas tareas y mantener conexiones, permisos y operaciones de forma sostenida.

La aportación de OpenConnector

OpenConnector es una pasarela de conexión de código abierto mantenida por OOMOL. Gestiona conexiones y credenciales y ofrece operaciones invocables mediante SDK, CLI, MCP y HTTP.

El agente o un backend de confianza elige una operación y una conexión. La pasarela comprueba la credencial del solicitante y la política de operaciones, llama al proveedor con la cuenta correspondiente y devuelve el resultado.

Los desarrolladores pueden examinar definiciones, parámetros y ámbitos de autorización, configurar operaciones permitidas o bloqueadas en despliegues propios e investigar fallos con registros que ocultan datos sensibles. El runtime abierto, las definiciones y los controladores ejecutables localmente cuando están disponibles permiten revisar y ampliar la ruta de llamada. Consulta la documentación de OpenConnector.

Las políticas se aplican junto con los permisos de la cuenta y los ámbitos del proveedor. Los registros de clientes visibles dependen también del sistema de origen. Enviar un correo puede requerir confirmación humana en el proceso de negocio. La pasarela debe trabajar con el sistema general de identidades y aprobaciones.

Se puede empezar con OOMOL alojado, o autoalojar OpenConnector para gestionar la pasarela, las credenciales y el runtime. La guía de despliegue explica cómo elegir.

Una base que merece construirse entre todos

La integración de aplicaciones exige mantenimiento continuo. Cada servicio tiene autorizaciones, parámetros, errores y límites diferentes. Las API cambian, los tokens caducan y las empresas añaden aplicaciones y sistemas internos.

Buena parte de ese trabajo puede beneficiar a varias organizaciones. Corregir la paginación ayuda a otros usuarios del conector. Precisar los ámbitos necesarios evita investigar el mismo fallo. Publicar el código permite revisarlo, corregirlo y ejecutarlo en otro entorno.

Ese es el sentido de una pasarela abierta: convertir el trabajo de conexión repetido en cada empresa en capacidades que aproveche todo el ecosistema.

Una capa abierta también conserva opciones. Los agentes y modelos pueden evolucionar mientras las conexiones siguen disponibles mediante interfaces e implementaciones públicas. Los equipos que necesitan controlar el entorno disponen de código y de una ruta de despliegue.

El código abierto permite revisión, modificación y mantenimiento compartido. La seguridad sigue necesitando revisión de código, configuración correcta y operación continua; las condiciones de las API externas siguen aplicándose. El valor de colaborar aparece al completar y reutilizar esas mejoras concretas.

Preparar al próximo compañero digital

Podemos pensar en el agente como en alguien que empieza a trabajar: ¿dónde lo hará?, ¿en qué sistemas podrá entrar?, ¿qué podrá leer y modificar?

Cuando el sistema hace efectivas esas respuestas, es posible delegar tareas de mayor valor de forma gradual.

Queremos que OpenConnector forme parte de esa infraestructura y que más desarrolladores participen. Se puede empezar por una aplicación cotidiana: añadir una operación necesaria, corregir un problema de autorización, mejorar un parámetro o comunicar una incidencia de despliegue.

Visita el sitio de OOMOL para conocer el producto y las opciones de integración. Para validar un caso de uso, conecta una aplicación en OOMOL Console y empieza con una lectura de alcance explícito.

Los agentes que entran en la empresa necesitan un entorno de trabajo y una puerta a los sistemas con los permisos adecuados. Empezamos por esa puerta, junto con la comunidad.