Cómo elegir una empresa de desarrollo de agentes de IA: checklist para compradores

Elija una empresa de desarrollo de agentes de IA según cómo limita lo que el agente puede hacer, cómo lo prueba antes de lanzarlo, cómo gestiona los fallos, dónde aprueban las personas las acciones, qué registra y qué le pertenece al final. Una demo convincente muestra que un agente puede actuar. Esta checklist muestra si puede hacerlo con seguridad.

Los agentes se diferencian de los asistentes de chat en un aspecto clave: ejecutan acciones. Llaman a herramientas, leen y modifican registros, envían mensajes y encadenan varios pasos. Eso los hace más útiles y también más peligrosos. La empresa que contrate debe tratar esas acciones como el centro del diseño, no como un detalle de última hora.

Por qué un proyecto de agentes es más difícil de contratar de lo que parece

Un agente básico es fácil de construir. Se conecta un modelo a unas cuantas herramientas, se le dan instrucciones y en una demo completará tareas impresionantes. Lo difícil es todo lo que la demo evita: solicitudes ambiguas, herramientas que fallan a mitad de camino, límites de permisos, costos que crecen con cada iteración y acciones que no se pueden deshacer.

Muchos proveedores son nuevos en agentes, porque la propia categoría es nueva. Los portafolios suelen mostrar interfaces de chat y prototipos, más que agentes operando sobre sistemas reales durante meses. Eso dificulta distinguir a un equipo que ha entregado agentes fiables de uno que ha entregado buenas demos.

Además, el comportamiento de un agente es menos predecible que el del software tradicional. La misma entrada puede producir secuencias de herramientas distintas. Por eso las pruebas deben observar el comportamiento en muchos casos, no solo comprobar que un único camino funciona, y muchos equipos todavía no han desarrollado esa disciplina.

Lo que los compradores suelen hacer mal

El primer error es pedir autonomía antes que fiabilidad. Un agente totalmente autónomo suena eficiente, pero la autonomía multiplica el impacto de cada error. Empiece con un agente que proponga acciones para su aprobación y amplíe su autonomía solo donde la evidencia lo respalde.

El segundo error es conceder un acceso amplio a las herramientas. Dar a un agente una conexión general a la base de datos o una clave de API de administrador es cómodo durante el desarrollo y peligroso en producción. Cada herramienta debe tener el alcance más estrecho que le permita cumplir su función.

El tercer error es omitir la evaluación. Sin un conjunto de tareas de prueba realistas y una forma de puntuar el comportamiento del agente, cada cambio en las instrucciones, las herramientas o el modelo se convierte en una apuesta. Pregunte cómo prueba la empresa sus agentes antes del lanzamiento y después de cada cambio.

El cuarto error es ignorar los costos de operación. Un agente puede llamar a modelos y herramientas muchas veces por tarea. Lo que cuesta operarlo a su volumen importa tanto como lo que cuesta construirlo, y depende en gran medida de las decisiones de diseño.

Checklist para elegir una empresa de desarrollo de agentes de IA

Use estas preguntas en las conversaciones y al revisar propuestas. Un buen socio de desarrollo de agentes de IA las responderá de forma concreta y con ejemplos.

Alcance y herramientas

• ¿Qué tareas realizará el agente y cuáles quedan explícitamente fuera del alcance?
• ¿Qué herramientas llamará y cuál es el permiso mínimo que necesita cada una?
• ¿Están separadas las acciones de lectura y de escritura, con un control más estricto sobre la escritura?

Control humano

• ¿Qué acciones requieren aprobación humana antes de ejecutarse?
• ¿Cómo transfiere el agente el caso a una persona cuando tiene dudas o se bloquea?
• ¿Puede un operador pausar o desactivar el agente rápidamente?

Evaluación

• ¿Qué tareas de prueba se usarán y están basadas en su trabajo real?
• ¿Cómo se puntúa el comportamiento, incluida la elección de herramientas y no solo la respuesta final?
• ¿Cómo se comparan los cambios en instrucciones, herramientas o modelos antes de lanzarlos?

Gestión de fallos

• ¿Qué ocurre cuando una llamada a una herramienta falla en medio de una tarea de varios pasos?
• ¿Cómo se gestionan los tiempos de espera agotados, los límites de uso y las respuestas mal formadas del modelo?
• ¿Las acciones repetidas son seguras, o un reintento podría enviar dos veces el mismo mensaje o el mismo pago?

Observabilidad y auditoría

• ¿Se registra cada ejecución con sus entradas, llamadas a herramientas, salidas y las versiones utilizadas?
• ¿Puede reconstruir por qué el agente realizó una acción concreta?
• ¿Quién revisa los fallos y cómo se convierten en correcciones?

Propiedad y costos

• ¿Dónde residen el código, las instrucciones, las definiciones de herramientas y los datos de evaluación, y a quién pertenecen?
• ¿Cuáles son los principales factores del costo de operación y cómo se van a monitorear?
• ¿Podrá su equipo operar y modificar el agente después de la entrega?

Consideraciones de implementación

Pida a la empresa que describa una tarea de principio a fin, incluido lo que sucede cuando algo sale mal. Una buena respuesta cubre las herramientas utilizadas, los permisos de cada una, dónde ocurre la aprobación, qué se registra y cómo se recupera un paso fallido. Una respuesta débil solo describe el escenario ideal.

El control del lado del servidor es fundamental. Los permisos, los límites de uso y las funciones de pago deben verificarse en el servidor, nunca solo en la interfaz. Los datos de sesión y de mensajes que usa el agente no deben poder leerse ni modificarse directamente desde el navegador.

Diseñe pensando en la idempotencia. Cuando un agente reintenta un paso, la acción subyacente no debe duplicarse. Normalmente eso implica identificadores estables para cada acción y comprobaciones antes de escribir.

Trate las instrucciones y las definiciones de herramientas como código de producto versionado. Cambian con frecuencia, influyen en el comportamiento tanto como el código y un pequeño cambio de redacción puede alterar las herramientas que elige el agente. Pregunte cómo las almacena la empresa, cómo revisa los cambios y cómo vincula cada ejecución registrada con la versión exacta que la produjo. Si las instrucciones se editan directamente en un panel sin historial, espere regresiones que nadie podrá explicar.

Tenga en cuenta también la normativa de protección de datos de los países donde opera. Si el agente procesa datos personales, esas reglas pueden condicionar qué se registra, cuánto tiempo se conserva y a qué proveedores de modelos se envía. Revise estas decisiones con su asesoría legal antes del piloto.

Planifique el camino a producción desde el inicio. Acuerde un piloto con un número limitado de usuarios o tareas, criterios claros de éxito y de parada, y monitoreo. Para profundizar en la seguridad, el artículo sobre cómo proteger agentes de IA describe las vías de ataque más comunes.

Ventajas y desventajas

Los frameworks aceleran el desarrollo y aportan piezas útiles, pero pueden ocultar comportamientos que importan en producción, como el funcionamiento de los reintentos y la memoria. Una empresa debe poder explicar qué hace su framework por dentro, o por qué prefirió escribir una capa más ligera por su cuenta.

Más aprobación humana hace que los agentes sean más seguros y más lentos. El equilibrio adecuado depende del costo de un error. Para tareas internas de investigación puede bastar una revisión ligera. Para mensajes a clientes o acciones financieras, la aprobación debe mantenerse hasta que la evidencia sea sólida.

Una agencia especializada puede tener más patrones propios de agentes; un estudio de producto suele ser más fuerte integrando el agente en un producto real y en el trabajo diario de sus usuarios. Un estudio dirigido por su fundador le da acceso directo a la persona que diseña el sistema, con menos capacidad en paralelo que una empresa grande.

Lecciones del trabajo de ImadDhin

El espacio de agente del propio portal ofrece observaciones a nivel de código relevantes para esta checklist. Describen cómo está construido el sitio, no resultados de clientes.

Las sesiones y los mensajes del agente no se pueden leer ni escribir desde el navegador. Todo el tráfico del chat pasa por rutas de servidor, de modo que un visitante no puede leer ni modificar la sesión de otra persona, ni su propio historial, llamando directamente a la base de datos.

Las capacidades se controlan en el servidor. El chat gratuito tiene un tope y se mantiene solo como chat; la búsqueda web y otras herramientas requieren el plan de pago, y el servidor rechaza esas llamadas cuando la cuenta no tiene derecho. El navegador solo refleja esa decisión.

Las llamadas al proveedor externo de investigación pasan por un único módulo contenedor. Respeta la indicación de espera del proveedor ante límites de uso, reintenta tiempos de espera y errores del servidor con un número acotado de intentos espaciados y no reintenta solicitudes rechazadas por inválidas o no autorizadas. Los fallos del proveedor muestran un error claro al usuario en lugar de una respuesta predeterminada engañosa.

Nada de esto es exótico. Es la ingeniería habitual que separa un agente que se puede operar de una demo, y es justo lo que esta checklist pretende descubrir.

Errores comunes que conviene probar

• Dé al agente una solicitud ambigua y compruebe si pide aclaraciones o adivina.
• Provoque el fallo de una herramienta a mitad de tarea y confirme que el agente se detiene limpiamente sin dejar escrituras parciales.
• Repita una tarea que envía un mensaje y confirme que el mensaje no se duplica.
• Intente activar una función restringida o de pago modificando la solicitud del navegador.
• Intente leer los datos de sesión de otro usuario desde el cliente.
• Elija al azar una ejecución registrada y confirme que puede reconstruir cada llamada a herramientas y cada decisión.

Cuándo es mejor una solución más simple

Muchos problemas descritos como proyectos de agentes son en realidad flujos con una secuencia fija de pasos. Si los pasos siempre son los mismos, una automatización convencional con un paso de IA para clasificar o redactar es más simple, más barata y más fácil de probar que un agente que decide qué hacer a continuación.

Un agente vale la pena cuando las tareas varían, la secuencia correcta de acciones depende del contexto y una persona tendría que alternar entre varias herramientas para completarlas. Si no está seguro de en qué categoría encaja su problema, esa sola pregunta justifica una primera conversación.

Elija al socio que habla primero de los fallos

Cuando compare empresas de desarrollo de agentes de IA, fíjese en quién menciona permisos, evaluación, gestión de fallos y registros de auditoría sin que se lo pidan. Son los equipos con más probabilidades de construir un agente al que pueda confiarle trabajo real.

Conozca nuestro desarrollo de agentes de IA, vea cómo se estructuran los proyectos o repase su caso de uso en una llamada de 30 minutos.