Un agente se conecta a cada sistema por un conector: una puerta controlada que usa la API del sistema, el protocolo MCP o el mecanismo que ese sistema entienda. El agente nunca recibe las llaves del sistema; recibe un conjunto acotado de acciones permitidas, cada una con su permiso y su bitácora.
¿Qué es exactamente un conector?
Un conector es la pieza que traduce entre el agente y un sistema. Del lado del sistema habla su idioma (una API, una base de datos, un archivo, una interfaz). Del lado del agente expone un catálogo corto de acciones con nombre y propósito claros, por ejemplo «consultar el saldo de un cliente» o «registrar una promesa de pago».
La ventaja de ese catálogo es doble. El agente no puede hacer nada que el catálogo no incluya, y cada acción se puede validar, limitar y registrar por separado. Un conector bien hecho es lo que convierte «un modelo que sabe escribir» en «un agente que puede trabajar sin poner en riesgo el sistema».
¿API o MCP: cuál se usa?
Depende de si hay una persona detrás de la consulta o si el proceso corre sin supervisión inmediata.
- API directa. Es el camino para procesos desatendidos: cobranza nocturna, conciliaciones, cargas. El conector usa credenciales propias del agente, con el mínimo de permisos, y se invoca desde el núcleo del proceso.
- MCP. El Model Context Protocol es un estándar abierto para conectar aplicaciones de inteligencia artificial con sistemas externos. Es muy útil para que las herramientas que tu equipo ya usa (un asistente de IA, un editor) lleguen a la operación real a través de una puerta definida, y para que un conector se escriba una vez y lo usen varios agentes.
- Ambos, según el caso. Es común que el mismo núcleo use API para lo desatendido y exponga MCP para las consultas de tu equipo.
Algunos fabricantes de software empresarial ofrecen sus propios servidores MCP. Si el sistema ya trae una puerta oficial, la aprovechamos en lugar de construir otra. Pero conviene revisar con el proveedor para qué tipo de uso está pensada: muchas de esas puertas suponen una persona autenticada detrás, no un proceso que corre solo. Eso se confirma sistema por sistema durante el diagnóstico.
¿Qué se hace con un sistema que no tiene API?
Pasa más de lo que se admite. Las opciones, de mejor a menos buena:
- Una API que existe pero nadie usa. Muchos sistemas la traen y nunca se activó. Se revisa primero.
- Acceso a la base de datos de lectura. Para consultar sin tocar el sistema, con una réplica o una vista de sólo lectura acordada con TI.
- Intercambio de archivos controlado. Importaciones y exportaciones programadas que el sistema ya sabe hacer.
- Una puerta construida. Un servicio pequeño, a veces con automatización de interfaz como último recurso, que da al agente una acción limpia aunque por detrás el sistema sea cerrado.
La regla es la misma en todos los casos: el agente ve una acción con nombre, no la pantalla ni la base de datos. Si la puerta cambia por dentro, el catálogo para el agente no cambia, y el proceso sigue.
¿Qué permisos tiene el agente en cada sistema?
Los mínimos para su tarea. En la práctica:
- Credenciales propias del agente, nunca las de una persona, para que cada acción quede atribuida a él en la bitácora de ambos sistemas.
- Permisos separados de lectura y de escritura, y de escritura sólo sobre lo que el proceso necesita.
- Límites por acción (qué rangos, qué estados, qué volumen) que viven en el conector, no en el texto con el que se instruye al modelo.
- Acciones sensibles marcadas para aprobación humana antes de ejecutarse.
Ese último punto importa: un límite que sólo está escrito en una instrucción al modelo es una petición, no un control. Los controles viven en el código del conector. Lo desarrollamos en gobierno del agente y en seguridad y datos.
¿Qué debería revisar TI antes de abrir una puerta?
- Qué sistema es la fuente de verdad de cada dato, para que el agente no la duplique.
- Quién autoriza el acceso y cómo se revoca. Un conector se apaga sin tocar el sistema.
- Qué límites de uso impone el proveedor del sistema y cómo se respetan.
- Cómo se guardan las credenciales: fuera del código y fuera de las instrucciones del modelo.
- Qué pasa cuando el sistema no responde: reintentos acotados y escalamiento, nunca insistencia ciega.
- Cómo se prueba contra un entorno que no sea producción.
Con esas respuestas, abrir una puerta es una tarea de ingeniería normal. Para ver qué se construye encima de ellas, pasa a los núcleos agénticos; si tu duda es qué pasa con sistemas muy antiguos, lee construir sin migrar.