Qué es un agente de IA
Un agente de IA es un programa que usa un modelo de lenguaje para decidir qué pasos dar y a qué herramientas llamar hasta cumplir un objetivo. Recibe una petición, elige una acción, como consultar una base de datos, buscar en un documento o preparar un correo, examina el resultado y decide el paso siguiente. Repite ese ciclo hasta terminar o hasta que le falta algo para continuar.
Un chatbot, tal como se suele entender, responde dentro de la conversación con lo que sabe o con la información que se le facilita. El agente, además, actúa sobre otros sistemas. Por eso lo que puede hacer depende de las herramientas y los permisos que se le conceden, y de eso trata el resto de esta nota.
A veces basta una regla
Hay tareas que parecen pedir un agente y se resuelven con una condición bien escrita. Si una factura tiene que ir a contabilidad cuando lleva un código de proyecto, o si alguien pregunta por el estado de un pedido que ya figura en la base de datos, una regla o una consulta dan la misma respuesta cada vez y se pueden comprobar línea a línea. Un modelo de lenguaje añade interpretación. Con ella llegan la incertidumbre y un coste por cada uso.
Empieza a tener sentido cuando la petición llega en texto libre, cuando hay que buscar en documentación que cambia o cuando la tarea encadena pasos que una regla fija cubre mal. Aun así, muchas veces propongo algo mixto: el modelo interpreta lo que se pide y el resto del recorrido lo hacen reglas y consultas que sabemos cómo se comportan.
Qué puede hacer y con qué permisos
Parto de una lista corta de acciones permitidas, por ejemplo consultar un pedido, buscar en un manual interno o preparar el borrador de una respuesta. Cada acción corresponde a una herramienta con entradas definidas, y lo que no está en la lista queda fuera de su alcance. Si una tarea solo necesita leer, la cuenta del agente no tiene permiso de escritura. Le doy credenciales propias en vez de reutilizar las de una persona; así se pueden revocar o limitar sin afectar a nadie más.
Después marco las acciones que necesitan confirmación humana: enviar un correo a un cliente, modificar un registro, aprobar un pago o borrar información. El agente puede dejarlas preparadas, y alguien de tu equipo decide si salen.
Cuando tiene que conectarse con varias herramientas, o con aplicaciones que ya ofrecen ese protocolo, valoro integrarlas mediante MCP. La especificación de MCP advierte de que una herramienta puede ejecutar código arbitrario y pide que el usuario entienda y autorice lo que hace cada una. Para una sola consulta a una base de datos, una llamada directa suele ser más fácil de mantener.
Ejemplos con la respuesta esperada
Antes de dejarlo trabajar reúno, con las personas que hoy hacen esa tarea, un conjunto de ejemplos representativos y la respuesta o acción que esperamos en cada uno. Incluyo peticiones ambiguas, datos incompletos, preguntas ajenas a su función y documentos o correos que contienen instrucciones dirigidas al propio agente para cambiar su comportamiento.
Una parte del conjunto la forman casos en los que debe pedir ayuda o no hacer nada: falta información, dos fuentes se contradicen o la petición supone una acción que no tiene autorizada. Que conteste bien a casi todo sirve de poco si en esos casos actúa por su cuenta.
Guardo los ejemplos y los vuelvo a pasar cada vez que cambian las instrucciones, las herramientas o la versión del modelo, para que un ajuste en un punto no estropee otro sin que nadie lo vea. El resultado describe cómo se comporta con esos ejemplos. No garantiza que acierte con cualquier entrada futura.
Registro, coste y mantenimiento
El agente deja constancia de lo que hace: qué petición recibió, qué herramientas llamó y con qué parámetros, qué le devolvieron y qué acción se ejecutó o quedó pendiente de confirmar. Con ese registro se puede explicar una decisión y detectar un error que se repite. Como puede contener datos personales o información interna, acordamos quién lo consulta y cuánto tiempo se conserva.
El coste depende del número de peticiones, de cuánta información se envía al modelo en cada una y de la infraestructura o el proveedor que se elijan. Lo estimo con los ejemplos de prueba y el uso previsto, y documento cómo medirlo después. El mantenimiento también cuenta: los modelos cambian de versión, las APIs de las herramientas se modifican y la documentación en la que busca envejece. En la propuesta queda escrito quién se ocupa de cada cosa cuando termina el encargo.
Datos personales y material autorizado
Solo conecto el agente a documentación y sistemas que tu empresa tenga derecho a usar para ese fin. Si hay datos personales, revisamos qué información necesita de verdad, dónde se procesa y qué proveedores intervienen, y lo contrastamos con quien lleve la protección de datos en tu empresa. Un documento interno puede incluir información de terceros que no debería enviarse a un servicio externo.
El Reglamento (UE) 2024/1689, de inteligencia artificial, fija obligaciones distintas según el tipo de sistema y el uso que se le da; entre otras cosas, enumera prácticas prohibidas y exige transparencia a determinados sistemas que interactúan con personas. Saber si un agente concreto queda afectado y cómo es una cuestión jurídica. Esta nota no es asesoramiento legal, y conviene que lo revises con tu asesor.
Una primera fase puede limitarse a definir acciones y permisos, reunir los ejemplos y hacer una prueba acotada con material autorizado. Con esos resultados decides si seguir. El resto del trabajo lo explico en la página de desarrollo de software y automatización.
¿Tienes un caso parecido?
Escríbeme qué ocurre ahora y qué te gustaría cambiar; no hace falta una especificación técnica. Preparar la propuesta no tiene coste.
Te respondo en dos días laborables como máximo. También puedes escribir a hola@wave56.com.