Lo que debe controlar la integración de agentes de IA
Un agente de IA conectado a los sistemas empresariales es un actor, no una función. Lee registros, decide qué hacer a continuación y, cuando se le ha dado la capacidad, escribe de vuelta. Una integración convencional hace lo que se configuró para hacer. Un agente decide.
Controlar a un actor significa decidir de antemano a qué puede acceder y qué puede cambiar. Esas son las mismas decisiones que toma una empresa sobre un empleado o una cuenta de servicio. La diferencia es la velocidad, porque una suposición que se deja implícita se pone a prueba cientos de veces antes de que alguien la revise.
Cinco cosas deben ser explícitas:
- Alcance del acceso: qué sistemas y qué registros, ya que un agente que responde preguntas de servicio no tiene motivos para leer los precios de los proveedores
- Acciones permitidas: la diferencia entre leer un pedido, cambiarlo y cancelarlo, cada una de las cuales es una decisión independiente
- Umbrales y escalamiento: el valor o nivel de riesgo por encima del cual una persona confirma, en lugar de un permiso o denegación general
- Identidad y atribución: qué agente, actuando en nombre de qué usuario o proceso, para que una acción tenga un responsable
- Un registro completo: qué se leyó, qué se cambió y sobre qué base, en una forma que responda a un auditor o a una queja de un cliente
Ninguno de estos son requisitos nuevos. Son los controles que ya se aplican a las integraciones e interfaces, aplicados a un actor que genera su propio siguiente paso. Ahora importan más porque un agente que actúa es un problema diferente al de un agente que solo lee.
¿Por qué un agente de acción es diferente de uno de lectura?
Un agente de lectura que se equivoca da una mala respuesta y alguien la corrige. Un agente de acción que se equivoca emite un reembolso que no correspondía, ajusta una cifra de inventario que ya era correcta o cancela un pedido que el cliente aún desea. Deshacer cualquiera de estas acciones requiere una segunda operación con sus propias consecuencias.
La segunda diferencia es más difícil de percibir. Una integración normal hace lo mismo cada vez que se ejecuta, por lo que una prueba te indica lo que hará en producción. Un agente elige su propia ruta hacia el objetivo, y la misma solicitud puede producir una secuencia de pasos diferente cada vez. Probarlo resulta menos concluyente. El único control fiable es limitar lo que es capaz de hacer desde el principio.
La velocidad es la tercera diferencia. Un agente completa en minutos lo que a una persona le llevaría días. Cuando la lógica es correcta, ese es precisamente el objetivo. Cuando es incorrecta, cuatrocientos registros ya se han visto afectados antes de que alguien se dé cuenta.
La gobernanza de la IA abarca lo que un modelo lee y cómo llega a una conclusión, lo cual es un problema de datos. Gobernar lo que un agente escribe en el ERP es un problema de acceso, y ambos requieren controles diferentes.
Lo que cuesta el acceso de agentes de IA sin gobernanza
La mayoría de estos son problemas de integración antiguos que llegan más rápido. La diferencia es que un agente llega a ellos sin que nadie haya decidido que debería hacerlo:
- Las credenciales se comparten demasiado: el agente termina con una cuenta de servicio que puede leer y escribir en todo el ERP, porque limitar su alcance a cuatro operaciones habría tomado una semana
- Las acciones no se pueden atribuir: el pedido fue cancelado por “integration_user” a las 02:14, y nadie puede decir qué agente lo hizo, qué instrucción lo provocó o quién lo solicitó
- Los errores se acumulan antes de que alguien los revise: el agente aplica la misma regla incorrecta a seiscientos pedidos durante la noche, y el patrón aparece en la cola de la mañana
- Los datos regulados terminan en un lugar sin evaluar: los registros de clientes llegan a un modelo o a un servicio de terceros que nadie ha revisado en cuanto a datos personales
- La acción no se puede revertir: no hay registro de cuáles eran los valores antes de que el agente los cambiara, por lo que restaurarlos es una suposición
El último punto convierte un incidente en una pérdida total. Los cinco son versiones de un requisito que las empresas han tenido durante años sin aplicarlo estrictamente.
Por qué la integración de agentes de IA convierte un requisito antiguo en una urgencia
Las empresas llevan años conectando sistemas entre sí sin definir con precisión qué puede hacer cada conexión. Un proceso nocturno extrae pedidos de la tienda web al ERP utilizando una cuenta de base de datos que también puede escribir en el libro mayor. Una fuente de precios del PIM tiene permiso para actualizar todos los campos de un producto, cuando en realidad solo debería tocar tres. A nadie le importa, porque esas integraciones hacen lo mismo cada noche.
Un agente rompe ese esquema. Decide su propio siguiente paso, por lo que confiar en lo que elegirá hacer no es un control. El alcance de los permisos, que era una buena práctica para el proceso nocturno, se convierte en una condición previa para el agente.
Por lo tanto, la pregunta al conectar un agente no es a qué puede acceder. Es qué se le puede impedir hacer y si alguien podría reconstruir sus acciones un mes después. Las empresas que ya gestionan la seguridad de los datos en sus integraciones de IA ya tienen gran parte del trabajo hecho.
La mayoría de los equipos comienzan conectando el agente directamente a la API de cada sistema. Esa es la ruta más rápida, y coloca las credenciales y las reglas sobre lo que el agente puede hacer dentro del propio agente. Algunos utilizan una plataforma de agentes, que gestiona las conexiones pero mantiene esas reglas en un lugar separado de todo lo demás que ejecuta la empresa. Otros crean un middleware para cada agente, lo cual funciona pero debe volver a construirse para el siguiente.
Los tres comparten un problema. La empresa ya tiene un lugar donde sus sistemas se conectan entre sí y donde se aplican las reglas sobre lo que puede pasar entre ellos. Poner los controles del agente en cualquier otro lugar significa mantener dos conjuntos de reglas sobre los mismos sistemas.
Cómo una plataforma de integración gobierna la integración de agentes de IA
Una plataforma de integración como servicio (iPaaS) es un lugar central donde cada sistema se conecta una sola vez en lugar de conectarse directamente entre sí, y donde se mueve y transforma la información. Las empresas ya la utilizan para este tipo de tareas: extraer pedidos de la tienda web al ERP durante la noche, enviar datos de productos del PIM a la tienda y devolver las cifras de stock. Cada una de estas tareas se configura en lugar de programarse. Alguien ya ha definido qué puede leer, qué puede escribir y qué se registra cuando se ejecuta.
Un agente se conecta de la misma manera. No recibe credenciales para el ERP. Recibe acceso a las operaciones específicas que alguien configuró para él, y esas operaciones llevan las reglas y el registro que ya tiene cualquier otra integración en la plataforma.
Eso pone al alcance los siguientes controles de gobernanza sin tener que construir nada nuevo. La plataforma de integración Alumio puede configurarse para:
- Limitar el acceso por conexión: el control de acceso al sistema basado en roles y el aislamiento por entorno significan que un agente accede a los datos y operaciones específicos que se le otorgaron, en lugar de poseer credenciales del sistema
- Expresar acciones como flujos gobernados: un agente activa una Ruta dentro de Alumio que realiza una operación definida, por lo que el rango de acciones posibles está limitado por la configuración y no por el criterio del agente
- Validar antes de escribir nada: un Transformador aplica las mismas reglas que cualquier otra integración, por lo que un valor fuera de rango es rechazado independientemente de quién lo haya solicitado
- Registre cada acción: la plataforma iPaaS de Alumio registra qué se solicitó, qué se ejecutó y qué devolvió el sistema receptor, lo que hace que la gobernanza de los agentes de IA sea auditable en lugar de una suposición
Debido a que esa gobernanza ya cubre los sistemas con los que interactúa el agente, añadir uno no significa crear un modelo de control paralelo. El siguiente agente se conecta a lo que el primero estableció.
Lo que hace posible la integración gobernada de agentes de IA
La mayoría de las empresas están estancadas en el mismo punto. El departamento de TI no conectará un agente al ERP sin saber qué podría hacer en un mal día. El equipo de operaciones obtiene poco valor de un agente que solo puede leer. Por lo tanto, el agente redacta correos electrónicos y resume tickets, mientras que los procesos en los que realmente ahorraría dinero siguen siendo manuales.
La salida no es decidir si se puede confiar en los agentes. Es decidir qué acciones son seguras de delegar y bajo qué condiciones, lo cual tiene respuestas específicas que varían según el proceso. Leer y redactar son tareas de bajo riesgo en casi cualquier lugar. Realizar un pago no lo es. La mayoría de los casos útiles se encuentran en un punto intermedio, donde el agente prepara el trabajo y una persona lo aprueba.
Una plataforma de integración hace que esa división sea ejecutable, en lugar de ser una política que nadie puede verificar. Limita lo que el agente puede hacer, valida lo que produce y registra lo que hizo.
La empresa puede entonces decir que sí a más de esto. Los agentes pasan a gestionar pedidos, devoluciones y comunicación con proveedores, en lugar de limitarse a resúmenes y borradores.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
