Cómo integrar agentes de IA con los sistemas empresariales existentes: arquitectura, procesos y prácticas de seguridad

Aclarar primero qué significa «integrar»: el modelo no debe tener permisos directos sobre los sistemas

Cuando una empresa conecta un agente de IA con su ERP, CRM, sistema de automatización de oficinas, sistema de tickets o base de conocimiento, lo esencial no es conectar el modelo a la base de datos, sino permitirle realizar consultas, evaluaciones o acciones limitadas mediante herramientas controladas y con una autorización explícita. El modelo interpreta la solicitud y propone el siguiente paso; la capa de herramientas define y valida las acciones; los sistemas empresariales siguen siendo la fuente de referencia de los datos y las reglas de negocio.

Una propuesta del agente no significa que el sistema ya la haya ejecutado, y una llamada a una herramienta completada con éxito tampoco garantiza que el resultado de negocio sea correcto: ambos aspectos deben verificarse. Para conocer el mecanismo de llamada a herramientas, consulte la documentación de OpenAI sobre llamadas a funciones: el modelo genera la información de la llamada a la herramienta según su definición, pero la ejecución real sigue correspondiendo a la aplicación.

Inventariar las tareas antes de decidir qué sistema conectar

Empiece por los procesos de negocio, no por la terminología técnica. Enumere las tareas pendientes, los sistemas implicados, los datos de entrada y salida, los pasos manuales actuales, las consecuencias de los fallos y las acciones que requieren la aprobación del personal. Después, seleccione el primer caso de uso según su valor para el negocio, la sensibilidad de los datos, la madurez de las interfaces, el impacto de los fallos y las necesidades de aprobación.

Por ejemplo, se puede empezar evaluando la «clasificación y asignación de tickets de atención al cliente»: el agente lee los nuevos tickets y la información interna, y propone una categoría y un equipo responsable; la capa de herramientas comprueba que el identificador del ticket, la categoría y el equipo sean válidos; en los casos de bajo riesgo, se empieza generando solo propuestas y se actualiza el ticket tras la confirmación del personal de atención al cliente. Este ejemplo no presupone capacidades concretas de ningún sistema: antes de implantarlo, hay que comprobar las interfaces y los permisos disponibles.

Cómo elegir entre API, webhooks, llamadas a funciones y RPA

Las API son adecuadas para consultas y operaciones de negocio bien definidas. La capa de herramientas puede encapsular las interfaces del sistema en acciones acotadas y claras, como «consultar el estado de un ticket», para evitar exponer funciones de consulta genéricas demasiado amplias. Hay que comprobar el método de autenticación, las definiciones de los campos, las respuestas de error y el entorno de pruebas.

Las llamadas a funciones son una forma de interacción en la que el modelo selecciona herramientas predefinidas y completa sus parámetros; no constituyen una nueva interfaz para los sistemas empresariales. Deben combinarse con validaciones del lado del servidor: el hecho de que el modelo haya proporcionado parámetros no significa que sean fiables ni que la acción esté autorizada. La documentación de OpenAI sobre llamadas a funciones explica que, una vez que el modelo genera una solicitud de llamada a una herramienta, la aplicación debe ejecutar el código correspondiente y devolver el resultado al flujo de la conversación.

Los webhooks son adecuados para activar procesos posteriores a partir de eventos de negocio, por ejemplo, para notificar al servicio de integración cuando un sistema genera una tarea pendiente. La entrega de eventos debe contemplar duplicados, retrasos, orden de llegada y reintentos tras fallos; su comportamiento concreto depende del sistema conectado. La documentación de GitHub sobre webhooks explica cómo gestionar los fallos de entrega y los reenvíos, entre otros aspectos, y puede servir como ejemplo para comprobar el comportamiento de una plataforma concreta, pero no como garantía común a todos los servicios.

La RPA puede ser una opción transitoria cuando no hay interfaces disponibles, ya que permite manejar sistemas heredados a través de su interfaz de usuario. Sin embargo, los cambios en la interfaz, el estado de la sesión y las ventanas emergentes inesperadas pueden afectar al proceso. Es necesario evaluar la estabilidad, la supervisión del funcionamiento y los costes de mantenimiento, además de mantener un mecanismo de comprobación para las operaciones de escritura críticas. Las explicaciones de la documentación de UiPath sobre selectores e identificación de elementos de la interfaz indican que la propia localización de estos elementos debe validarse y mantenerse en la aplicación de destino.

La orquestación mediante una capa intermedia es adecuada para escenarios que requieren conectar varios sistemas y unificar identidades y reglas. Permite centralizar la transformación, la validación y la auditoría, pero también añade componentes y responsabilidades de operación y mantenimiento. Al elegir una solución, no solo debe compararse la rapidez de integración, sino también la localización de fallos, el aislamiento de permisos y el mantenimiento a largo plazo.

Arquitectura recomendada: separar la planificación, la ejecución y la gobernanza

1. Capa del agente: interpreta las solicitudes, organiza el contexto y propone un plan de llamadas a herramientas; no almacena credenciales de bases de datos.
2. Capa de herramientas: define la finalidad, los tipos de parámetros, los campos obligatorios, los rangos permitidos y la estructura de respuesta de cada acción; el servidor vuelve a validarlos.
3. Capa de integración: conecta sistemas como ERP, CRM y OA, y gestiona la autenticación, la adaptación de protocolos, los tiempos de espera y la correspondencia de errores.
4. Capa de permisos y aprobaciones: vincula las identidades de los empleados y de los servicios con los permisos para ejecutar acciones; exige confirmación para las operaciones de alto impacto.
5. Capa de registros y evaluación: registra quién realiza la llamada, la herramienta utilizada, el resumen necesario de la solicitud, el resultado y las excepciones, y permite revisar lo ocurrido y calcular métricas.

Los límites deben estar claros: el modelo se encarga de «proponer qué hacer»; el servicio de herramientas, de determinar «si está permitido y si los parámetros son válidos»; y el sistema de negocio, de establecer «cuál es el estado final». No permita que el modelo eluda la capa de herramientas y disponga directamente de credenciales de acceso a la base de datos de producción. Esta separación en capas es una recomendación de diseño para la implementación; los límites concretos entre componentes deben definirse según las capacidades de los sistemas y los requisitos de control de la organización. Puede consultar la Introducción a las identidades de trabajo de los agentes empresariales de Gemini para comprender el papel de la identidad y los permisos en los agentes empresariales; esa página es una presentación del producto y no sustituye una evaluación de la arquitectura del entorno propio.

Del piloto a la puesta en producción: ampliar gradualmente según el riesgo

Primer paso: elegir un caso de uso acotado. Defina las condiciones de activación, los criterios de finalización y la gestión de fallos; no confunda «conseguir conectarse al sistema» con alcanzar el objetivo de negocio.

Segundo paso: redactar los contratos de las herramientas. Especifique para cada herramienta su finalidad, parámetros, permisos, posibles efectos secundarios, tipos de error y métodos de verificación de los resultados. Priorice la división en acciones individuales y evite que una misma herramienta consulte, modifique y elimine datos.

Tercer paso: conectar primero un entorno de pruebas. Realice pruebas con entradas representativas, valores límite, campos ausentes y respuestas anómalas; compruebe si el agente solicita información adicional cuando no dispone de datos suficientes, en lugar de adivinar los parámetros.

Cuarto paso: establecer medidas de protección antes del despliegue gradual. Empiece con un modo de solo lectura o de recomendaciones y, después, habilite operaciones de escritura de bajo riesgo previamente aprobadas. Establezca límites de llamadas, tiempos de espera y alertas; defina con claridad cuándo detener la ejecución, reintentar o recurrir a una persona en caso de fallo.

Quinto paso: revisar los resultados antes de ampliar el alcance. Registre los errores de clasificación, los parámetros no válidos, las llamadas duplicadas y los motivos de la intervención humana. Considere ampliar el conjunto de acciones únicamente cuando los resultados sean verificables, los límites de los permisos estén claros y exista un procedimiento para gestionar las incidencias.

La clasificación y asignación de incidencias, por ejemplo, puede implantarse por fases: primero, leer las incidencias y proponer una clasificación; después, guardar la clasificación tras la confirmación de un empleado; y, por último, evaluar si se pueden asignar automáticamente aquellas incidencias sujetas a reglas claras y cuya asignación pueda revertirse. Defina criterios de salida para cada fase y vuelva a la confirmación humana si aumentan las asignaciones erróneas o no es posible auditar el proceso. Para evaluar el riesgo de que un agente rebase sus límites, puede consultar nuestro análisis sobre incidentes de seguridad de agentes, tomando siempre como referencia las pruebas realizadas en el sistema real.

Seguridad y gobernanza: convertir los controles en comprobaciones concretas

• Mínimo privilegio e identidad independiente: conceda a la identidad de servicio del agente acceso únicamente a los sistemas y las acciones necesarios para completar la tarea; antes de la puesta en producción, compruebe que las credenciales sean de uso exclusivo, puedan rotarse y no incluyan permisos de escritura ajenos a la tarea.
• Control de campos sensibles: facilite al modelo únicamente la información necesaria para completar la tarea; revise uno por uno los campos de entrada, salida y registro, y compruebe que las reglas de enmascaramiento de datos se apliquen correctamente.
• Protección frente a la inyección de instrucciones y el acceso no autorizado: trate los textos externos, como correos electrónicos, incidencias y páginas web, como datos y no como instrucciones que otorguen autorización. Utilice contenidos de prueba que intenten inducir llamadas adicionales o la exportación de datos para comprobar que las reglas de permisos sigan bloqueando esas acciones o exigiendo confirmación. La documentación de OWASP sobre seguridad de aplicaciones con LLM incluye la inyección de instrucciones entre las categorías de riesgo que deben tenerse en cuenta.
• Protección de las operaciones de escritura: establezca validación de parámetros, una vista previa del impacto, aprobación y lectura posterior de los resultados para las modificaciones en producción; compruebe que el contenido aprobado coincida con el que realmente se envía.
• Idempotencia y gestión de incidencias: diseñe claves de deduplicación o comprobaciones de estado para las acciones que puedan enviarse más de una vez; pruebe por separado los tiempos de espera agotados, los reintentos y los éxitos parciales, y confirme que sea posible determinar el estado real del sistema tras un fallo.
• Auditoría y atribución de responsabilidades: registre la información necesaria sobre identidad, acción, fecha y hora, resultado y aprobación, y controle el acceso a los registros; compruebe mediante una revisión por muestreo si es posible rastrear un cambio de negocio hasta la llamada y la autorización que lo sustentaron.

Los principios de mínimo privilegio, autorización y auditabilidad también pueden contrastarse con la documentación de OWASP sobre amenazas y mitigaciones de la IA agéntica y aplicarse de acuerdo con los procedimientos de gestión de identidades y auditoría de la organización; esta documentación no sustituye la evaluación de seguridad de cada sistema concreto.

Cómo medir la eficacia de la integración

No evalúe únicamente la fluidez de las respuestas. En el ámbito técnico, puede observar la tasa de finalización de tareas, la tasa de fallos de validación de parámetros, la tasa de errores en las llamadas, la latencia de respuesta, las ejecuciones duplicadas y la tasa de intervención humana; en el ámbito operativo, el tiempo de tramitación, la variación del trabajo pendiente, la carga de revisión y el coste de las llamadas por tarea. Defina primero con claridad los criterios de medición: por ejemplo, ¿se considera que una tarea está «completada» cuando la herramienta devuelve un resultado satisfactorio o cuando se confirma el estado del sistema de negocio mediante una lectura posterior?

Antes de la prueba piloto, registre los valores de referencia del proceso actual y, después, compare los resultados para el mismo conjunto de tareas, distinguiendo entre errores de criterio del modelo, fallos de las interfaces y cambios en las reglas de negocio. Si la automatización aumenta la carga de revisión humana, no debe considerarse sin más una mejora, aunque la tasa de éxito de las llamadas sea buena. No presuponga un porcentaje de mejora: utilice primero los datos reales de funcionamiento de su empresa para decidir si amplía el alcance.

Preguntas frecuentes

¿Puede un agente integrarse con un sistema heredado que no tiene API? Se puede evaluar el uso de una capa intermedia controlada, una plataforma de integración existente o RPA, pero antes hay que confirmar la estabilidad de las operaciones, la observabilidad y quién se encargará del mantenimiento. Si el proceso implica operaciones de escritura de alto riesgo, conviene mantener la confirmación humana; no debe considerarse que la automatización de interfaces equivale a una API estable.

¿Es necesario modificar los sistemas existentes para integrar un agente? No necesariamente. Si el sistema ya dispone de API o mecanismos de eventos utilizables, normalmente se puede empezar creando una capa de herramientas y permisos externa al sistema. Si las interfaces son insuficientes, habrá que evaluar, según la tarea concreta, la incorporación de interfaces de solo lectura, adaptadores de integración o modificaciones puntuales. El caso de uso debe validarse con los cambios mínimos necesarios.

¿Cómo evitar que un agente realice operaciones incorrectas o exceda sus permisos? Defina para cada herramienta su finalidad, sus parámetros y los recursos a los que puede acceder, y utilice identidades de servicio independientes con los mínimos privilegios necesarios. Establezca requisitos de aprobación o confirmación para las operaciones de escritura en producción y registre quién realiza cada llamada, las entradas, los resultados y las excepciones. También deben probarse los casos en los que instrucciones maliciosas o contenido no fiable induzcan al agente a utilizar herramientas.

¿Qué tareas no conviene automatizar desde el principio? Las tareas con consecuencias difíciles de revertir, reglas poco claras, una fuerte dependencia de criterios implícitos o sin métodos fiables de verificación no son adecuadas como primeros casos de uso sin supervisión. Se puede empezar haciendo que el agente genere recomendaciones para que el personal las revise y, después, decidir si se amplía la automatización en función de los tipos de errores y los riesgos para el negocio.

Conclusión: empezar con pequeñas acciones verificables

La clave para integrar agentes de IA con los sistemas existentes de una empresa es definir claramente los límites de sus capacidades: el modelo propone un plan, las herramientas controladas lo validan y ejecutan, los mecanismos de permisos y auditoría limitan los riesgos, y los sistemas de negocio confirman el resultado final. Empezar con casos de uso de solo lectura o de generación de recomendaciones que sean de bajo riesgo y verificables, e incorporar después, de forma gradual, operaciones de escritura sujetas a aprobación, permite al equipo detectar problemas de interfaces, permisos y gobernanza en procesos reales, sin delegar de golpe acciones de alto riesgo en la automatización.