Agentes de IA dentro de tus sistemas: qué puede hacer un agente por su cuenta, qué debe aprobar una persona y cómo empezar sin perder el control

Un agente de IA es un modelo de lenguaje que puede pedir a tu software que ejecute funciones, es decir, acciones como consultar un pago, actualizar un ticket o emitir un reembolso. El modelo solo hace la petición. Tus sistemas deciden si la llevan a cabo, y ahí es donde conservas el control. Empieza por una tarea acotada, en la que el agente lee datos y prepara borradores por su cuenta. Una persona designada aprueba todo lo que mueve dinero, cambia la ficha de un cliente o sale de la empresa.

¿Qué es un agente de IA, en palabras sencillas?

Un modelo de lenguaje, el tipo de IA que hay detrás de ChatGPT, produce texto. Un agente es un modelo de lenguaje conectado a funciones de tus sistemas, de modo que su resultado puede ser una acción, además de una respuesta.

La documentación de Anthropic para sus modelos Claude dice: «El uso de herramientas (también llamado function calling) permite a Claude llamar a funciones que tú defines o que proporciona Anthropic». Para las funciones que defines tú, el modelo «devuelve una llamada estructurada que ejecuta tu aplicación». Escribe la petición, y tu software la ejecuta o la rechaza. Todas las fuentes de este artículo se consultaron el 2 de noviembre de 2026.

Un agente repite esto en bucle. Llama a una función, lee el resultado y elige el siguiente paso hasta terminar la tarea. Una publicación de 2024 del blog de ingeniería de Anthropic describe a los agentes como «normalmente, solo LLM que usan herramientas en un bucle en función de la respuesta que reciben de su entorno». LLM son las siglas en inglés de modelo de lenguaje grande, y las herramientas son las funciones a las que puede llamar.

Así que un agente solo puede hacer lo que permiten sus funciones. La lista de funciones es la descripción de su puesto de trabajo, y es el primer documento que hay que pedir.

¿Por qué importa si el agente lee datos o los cambia?

Porque leer no cambia nada. Si el agente consulta los cinco últimos pagos de un cliente y se equivoca en uno, el resultado es un borrador erróneo, que una persona puede detectar.

Escribir cambia algo fuera del modelo: se paga un reembolso o un correo llega a un cliente. Algunos de estos cambios no se pueden deshacer.

La guía de OpenAI para construir agentes propone clasificar cada función como de riesgo bajo, medio o alto «en función de factores como el acceso de solo lectura frente al de escritura, la reversibilidad, los permisos de cuenta necesarios y el impacto financiero». La lectura sigue siendo de bajo riesgo solo mientras el agente no pueda enviar a ninguna parte lo que ha leído. La sección sobre la prompt injection, un truco que coloca instrucciones en un correo o en un documento, muestra por qué.

¿Qué acciones puede realizar el agente por su cuenta y cuáles necesitan a una persona?

Clasifica cada función en uno de estos tres grupos:

• El agente por su cuenta: leer datos, buscar en documentos, etiquetar y redactar borradores que se quedan dentro de tus sistemas hasta que alguien los usa
• El agente propone y una persona aprueba: todo lo que mueve dinero, cambia la ficha o el estado de un cliente, o envía un mensaje fuera de la empresa
• Nunca: cambios en permisos de acceso, límites o datos bancarios, ni decisiones que tu regulador espera que tome una persona designada

Cuatro preguntas deciden el grupo de la mayoría de las funciones:

• ¿Se puede deshacer la acción y quién puede hacerlo?
• ¿Mueve dinero o cambia lo que debe un cliente?
• ¿Verá el resultado un cliente, un socio o un regulador?
• ¿Dice una ley, una condición de la licencia o tu propia política que debe decidir una persona?

La guía de OpenAI da el mismo consejo para el grupo intermedio: «Las acciones sensibles, irreversibles o de alto impacto deberían activar la supervisión humana hasta que aumente la confianza en la fiabilidad del agente». Entre sus ejemplos están «cancelar pedidos de usuarios, autorizar reembolsos elevados o realizar pagos».

El OWASP Top 10 for LLM Applications 2025, una lista de riesgos que publica el proyecto de seguridad OWASP, tiene una entrada llamada excessive agency (agencia excesiva). Trata del daño que puede causar un agente cuando tiene más funciones, permisos o libertad de los que necesita su tarea. Uno de los controles que enumera es «exigir que una persona apruebe las acciones de alto impacto antes de que se lleven a cabo».

¿Cómo se ve esto en soporte, alta de clientes, pagos e informes?

En cada área, el agente lee y redacta, y una persona se queda con las decisiones. Tu propia lista depende de tus sistemas y de lo que espere tu regulador.

• Soporte: el agente etiqueta los tickets y redacta respuestas. Al principio, una persona aprueba cada respuesta, y los reembolsos y las exenciones de comisiones siempre requieren aprobación. El agente nunca cambia el correo electrónico ni el teléfono de un cliente, porque quien los controla puede restablecer el acceso del cliente a su cuenta
• Alta de clientes: el agente revisa los documentos en busca de campos que falten y los resume para el analista. Un cambio en la calificación de riesgo espera aprobación, y aceptar a un cliente sigue en manos de una persona
• Pagos: el agente cuadra las líneas del extracto bancario con las facturas y señala lo que no cuadra. Liberar un pago retenido espera aprobación, y cambiar los datos bancarios de un beneficiario nunca le corresponde al agente
• Informes: el agente redacta el informe mensual con la fuente de cada cifra. Una persona aprueba todo lo que se envía a un cliente, al consejo o a un regulador

¿Dónde debe estar el paso de aprobación?

Pon la aprobación en el software que ejecuta la función, no solo en el prompt, que es el conjunto de instrucciones que recibe el modelo. Un modelo puede ignorar una línea de su prompt o dejarse convencer para saltársela. Una función de reembolso que no se ejecuta sin el clic de un aprobador no se deja convencer de nada.

Las recomendaciones de OWASP coinciden: «Implementar la autorización en los sistemas posteriores en lugar de confiar en que un LLM decida si una acción está permitida o no».

Una pantalla de aprobación útil muestra al aprobador:

• La acción, el registro que modifica y el importe
• El registro antes y después del cambio
• Los datos en los que se basó el agente, como el ticket o la línea del extracto
• Un motivo obligatorio siempre que el aprobador rechace

Si todas las propuestas se aprueban en cuestión de segundos, la gente ha dejado de revisar. El Reglamento de IA de la UE (AI Act) tiene un nombre para esto: sesgo de automatización. Su artículo sobre la supervisión humana dice que las personas que supervisan un sistema de alto riesgo deben poder ser conscientes de «la posible tendencia a confiar automáticamente o en exceso en los resultados de salida». Revisa de nuevo cada semana una muestra de las acciones aprobadas.

¿Qué permisos debe tener la cuenta del agente?

La cuenta del agente debe permitir las funciones de su lista y nada más. Da a cada agente su propia cuenta en cada sistema que toca, nunca una cuenta de administrador ni las credenciales de un empleado. Fija esos permisos en el propio sistema, donde el modelo no puede cambiarlos. Las contraseñas y las claves se quedan en tu software, fuera de la vista del modelo.

El ejemplo de OWASP es un agente que recomienda productos y «quizá solo necesite acceso de lectura a una tabla “products”». También advierte contra las funciones abiertas, como ejecutar cualquier comando en un servidor, y prefiere funciones acotadas que hagan una sola cosa cada una.

Cuando el agente trabaja para un empleado, debe actuar «en el contexto de ese usuario concreto y con los privilegios mínimos necesarios», en palabras de OWASP. Así no puede ver ni hacer más que esa persona.

¿Qué es la prompt injection y por qué importa más con agentes?

La prompt injection consiste en colocar instrucciones en un texto que lee el agente, como un correo, un ticket o un documento subido. El modelo puede seguirlas como si vinieran de ti. Las instrucciones pueden estar ocultas para un lector humano, y con un agente pueden convertirse en acciones. OWASP sitúa la prompt injection en primer lugar en su lista de 2025 y dice que «no está claro si existen métodos infalibles para prevenir la prompt injection».

La entrada de OWASP sobre la agencia excesiva describe un asistente que lee un buzón para resumir el correo entrante. El complemento que usa también puede enviar correos. Un correo preparado a propósito lo engaña para que busque información sensible en la bandeja de entrada y la reenvíe al atacante.

Las soluciones de OWASP empiezan por una función que solo puede leer correo y un acceso de solo lectura al buzón. Además, una persona debe «revisar manualmente y pulsar “enviar” en cada correo redactado por la extensión del LLM». Como la prompt injection no se puede descartar, planifica como si el agente ya hubiera sido engañado y mantén pequeño el daño que puede hacer.

¿Qué debemos registrar y cómo deshacemos un error?

Registra cada llamada a función. Cada entrada muestra el agente, la función y sus datos de entrada, el resultado, el texto que llevó a la llamada, la versión del modelo y del prompt, y quién la aprobó y cuándo. Alguien ajeno al equipo que lo construyó debería poder leer el log y saber qué le pasó a un cliente concreto.

OWASP señala que los logs y los límites de frecuencia no evitarán la agencia excesiva, «pero pueden limitar el nivel de daño causado». Un límite de frecuencia fija cuántas acciones de un mismo tipo puede realizar el agente en un tiempo determinado, de modo que una serie de acciones erróneas se detiene pronto.

Antes del lanzamiento, deja por escrito cómo se deshace cada función que cambia datos y quién lo hace. Da preferencia a las funciones que crean algo pendiente, como un reembolso que espera en una cola. Un elemento pendiente se puede borrar, mientras que un pago enviado es difícil de recuperar. Ten un interruptor que desactive de inmediato las funciones del agente, sin necesidad de publicar una nueva versión del software, y pruébalo antes de la puesta en producción.

¿Dice la ley que debe aprobar una persona?

En la UE, el Reglamento de IA (AI Act) fija normas de supervisión humana para los sistemas de IA que clasifica como de alto riesgo. Esas normas están en el artículo 14, y el anexo III enumera los usos de alto riesgo. La lista incluye evaluar la solvencia de personas físicas o establecer su calificación crediticia, aunque se excluyen los sistemas que detectan fraudes financieros. También incluye la evaluación de riesgos y la fijación de precios para personas físicas en los seguros de vida y de salud. El AI Act Service Desk de la Comisión Europea da el 2 de diciembre de 2027 como la fecha a partir de la cual se aplican las normas para los sistemas de alto riesgo del anexo III. Esa fecha refleja los cambios introducidos por el Digital Omnibus on AI. Fechas como esta pueden cambiar, así que comprueba el calendario vigente antes de hacer planes en función de él.

El artículo 14 dice que las medidas de supervisión «serán proporcionales a los riesgos, al nivel de autonomía y al contexto de uso» del sistema. Las personas que lo supervisan deben poder «decidir, en cualquier situación concreta, no utilizar el sistema de IA de alto riesgo o descartar, invalidar o revertir de otro modo sus resultados de salida». También deben poder detenerlo con «un botón de “parada” o un procedimiento similar».

Estas normas solo se aplican a los sistemas de alto riesgo que enumera el Reglamento, y muchos agentes de soporte y operaciones no estarán entre ellos. Aun así, los mismos controles tienen sentido para esos agentes. Si tu sistema entra en el ámbito de estas normas es una pregunta para tus abogados. Este artículo no constituye asesoramiento jurídico y trata solo las normas de la UE.

¿Cómo empezamos sin perder el control?

Empieza por preguntarte si la tarea necesita realmente un agente. La publicación de ingeniería de Anthropic recomienda «buscar la solución más sencilla posible y aumentar la complejidad solo cuando sea necesario», y añade: «Esto puede significar no construir sistemas agénticos en absoluto». Para muchas tareas, basta con una sola petición al modelo o una secuencia fija de pasos. Una secuencia fija también se comporta de forma más predecible que un agente que elige sus propios pasos.

Elige un flujo de trabajo con muchos casos a la semana, reglas claras y errores baratos de corregir, como clasificar tickets de soporte y redactar respuestas. Después, avanza por etapas:

• Mide el flujo de trabajo tal como funciona hoy: tiempo por caso, porcentaje de casos que hay que rehacer y volumen de casos pendientes cada semana
• Ejecuta el agente en modo sombra con casos reales. Él propone, las personas trabajan como antes y comparas ambos resultados
• Pasa al modo de aprobación, en el que una persona aprueba cada acción, y registra con qué frecuencia los aprobadores editan o rechazan
• Deja que el agente actúe por su cuenta solo en los tipos de acción con menos correcciones, y sigue revisando una muestra semanal

Acuerda de antemano qué cifras hacen que el agente pase a la siguiente etapa y quién lo decide. La guía de OpenAI termina así: «Empieza poco a poco, valida con usuarios reales y amplía las capacidades con el tiempo». La publicación de Anthropic recomienda «pruebas exhaustivas en entornos aislados», es decir, una copia de tus sistemas en la que los errores no cuestan nada.

¿Qué debemos comprobar antes de que el agente entre en producción?

• Cada función está en uno de los tres grupos y tiene un responsable designado en tu empresa
• Alguien intentó una acción prohibida con la cuenta del agente en cada sistema y comprobó que fallaba
• Pasaron por el agente tickets y documentos con instrucciones colocadas a propósito, y no ocurrió nada fuera de lo que permiten los grupos
• Para cualquier cliente, el log muestra qué hizo el agente y quién lo aprobó
• Una nueva versión del modelo entra en producción solo después de volver a pasar las mismas pruebas

¿De quién son el código, los prompts y los logs?

Deberían ser de tu empresa, y el contrato debe decirlo. El código es solo una parte del agente. Los prompts, la lista de funciones, las reglas de aprobación y los casos de prueba deciden cómo se comporta. Enuméralos todos como entregables, guardados en un almacenamiento que controle tu empresa.

Los logs contienen datos de clientes, así que necesitan las mismas reglas de acceso y el mismo plazo de conservación que los registros que describen. Si el modelo se ejecuta en un proveedor externo, pregunta si ese proveedor guarda lo que le envía el agente y durante cuánto tiempo.

¿Qué deberíamos preguntar a una empresa que lo construiría?

• ¿Podemos ver cada función a la que llamará el agente, con el grupo en el que está cada una?
• ¿Dónde se hacen cumplir las aprobaciones: en nuestros sistemas, en su código o solo en el prompt?
• ¿Qué cuenta usa el agente en cada sistema y cómo comprobaron que no puede hacer más?
• ¿Cómo hacen pruebas de prompt injection y qué pasa cuando una de ellas tiene éxito?
• ¿Puede nuestro equipo de cumplimiento normativo leer el log sin su ayuda?
• ¿Cómo se deshace cada acción y con qué rapidez podemos desactivar el agente?
• ¿Qué será nuestro al final: código, prompts, definiciones de funciones, casos de prueba y logs?

¿Dónde encaja amBrain?

amBrain usa agentes en su propio producto. Su línea sobre ese producto dice: «Nuestro propio producto, shyash.ai, funciona con agentes de IA que investigan, escriben, revisan y miden a partir de una memoria compartida de datos de la empresa. Una persona aprueba todo lo que sale».

El único proyecto de cliente con modelos de lenguaje que amBrain describe en público es este: «Hemos llevado a producción una integración de LLM dentro del perímetro FinTech de un cliente: extracción y normalización de avisos no estructurados de brókers y de centros de negociación —eventos corporativos, cambios de instrumentos y de márgenes— en registros estructurados que consume el sistema de trading».

Este artículo no es un caso de estudio y no describe ningún trabajo para clientes más allá de la línea anterior. Esa línea no dice nada sobre agentes ni aprobaciones, y el artículo no dice que amBrain construya sistemas de agentes para clientes. Los ejemplos de soporte, alta de clientes, pagos e informes son generales, no están tomados de trabajos de amBrain.

Las empresas y organizaciones que se nombran aquí se citan a partir de sus páginas publicadas. El artículo no afirma que amBrain tenga relación alguna con ninguna de ellas y no da precios ni plazos de amBrain.

amBrain desarrolla software desde 2019. Trabaja en tres formatos: entrega completa, un equipo dedicado o ingenieros integrados en tu equipo. Sobre la propiedad, su frase es: «El cliente conserva la propiedad completa del producto y del código, salvo nuestros componentes reutilizables». Las preguntas anteriores valen para cualquier empresa que estés considerando.