Cuándo no usar un agente de IA (y qué construir en su lugar)

Fundamentos 8 min de lectura

Un script de shell corto abierto en un portátil junto a un cuaderno cerrado, elegido frente a un diagrama complejo
A veces el proyecto terminado son cuarenta líneas de código determinista, y eso es un buen resultado.

Nos dedicamos a construir agentes, y precisamente por eso existe esta página. La forma más rápida de dañar la confianza de un equipo en esta tecnología es poner un agente en una tarea que no lo necesitaba, verlo acertar el 94 % donde un script acertaba el 100 % y pasar el trimestre siguiente defendiéndolo.

Abajo están las seis situaciones en las que decimos que no, y lo que sugerimos en su lugar. Ninguna habla de la capacidad de los modelos: hablan de dónde el indeterminismo es un coste y no una ventaja.

1. Los pasos nunca cambian#

Si la secuencia es fija — traer el fichero, validar columnas, transformar, cargar, notificar — no necesitas nada que decida el siguiente paso, porque nada decide. Escribe la tubería. Si un paso requiere criterio, como clasificar un campo de texto libre, llama al modelo para ese paso y deja el resto determinista.

Este es el sobredimensionamiento más común que vemos. Una llamada al modelo dentro de una tubería no es algo menor que un agente: es lo correcto.

2. La tarea es aritmética o coincidencia exacta#

Totales, conciliaciones, impuestos, reglas de elegibilidad con umbrales publicados: tienen respuesta correcta e implementaciones existentes. Un modelo puede explicar un cálculo maravillosamente y aun así equivocarse de vez en cuando, y de vez en cuando es una catástrofe en finanzas. Calcula en código y deja que el modelo explique el resultado.

3. Presupuesto de latencia por debajo de un segundo#

Un agente que planifica, llama a dos herramientas y responde no lo hace de forma fiable en menos de un segundo, porque cada llamada tiene su propio suelo. Si estás dentro de un checkout, una búsqueda mientras se escribe o un enrutado de llamadas, saca el trabajo del camino crítico o usa un clasificador y una consulta. La gente perdona una respuesta lenta que pidió; no perdona una página lenta.

4. Nadie sabe cómo es una ejecución correcta#

Si el equipo no puede producir veinte ejemplos de la tarea bien hecha, no tienes conjunto de evaluación — y sin él no hay forma de saber si un cambio ayudó. Construye primero los ejemplos. A menudo escribirlos revela que en realidad son tres tareas, dos triviales y una que es el problema de verdad.

Veinte ejemplos etiquetados es un listón deliberadamente bajo. Si un equipo no llega, la tarea aún no se entiende lo bastante para automatizarla.

5. Toda acción es irreversible y de alto valor#

Transferencias, firmas de contrato, borrados en producción. Puedes poner un agente delante — como redactor que arma el caso y lo entrega a una persona. Lo que no debes hacer es dar a un bucle autónomo acceso de escritura sin supervisión sobre algo irreversible, apoyándote en una cifra de precisión de un set de pruebas que no contenía tu peor semana.

6. Los datos que necesita no están accesibles#

Un agente es tan capaz como sus herramientas, y estas tan capaces como tus APIs. Si la información vive en un sistema sin API de lectura o en una hoja que editan tres personas a mano, el agente quedará reducido a adivinar. Arregla primero el acceso. Ese trabajo es poco lucido y concentra la mayor parte del valor: quien construye la API de lectura suele descubrir que después el agente es un proyecto de dos semanas.

Preguntas frecuentes

¿Cuándo es claramente la herramienta correcta?

Cuando el siguiente paso depende de verdad de lo que devolvió el anterior, cuando pueden hacer falta varias herramientas en un orden que no puedes fijar, y cuando hoy una persona lo hace consultando y decidiendo.

Ya construimos un agente para una tubería fija. ¿Lo quitamos?

No necesariamente: mide primero. Si es fiable y el coste es aceptable, déjalo. Sustitúyelo cuando puedas señalar un dolor concreto: latencia impredecible, coste por ejecución o fallos que nadie reproduce.

¿Puede un agente formar parte de un sistema determinista?

Sí, y suele ser el mejor diseño. Mantén la columna vertebral determinista y da al agente una región acotada donde haga falta criterio, con un contrato claro sobre lo que puede devolver.

cuándo no usar agentes de iaagente o flujolímites automatización llmalcance proyecto iaalternativas a agentes

Todas las guías

Última actualización 2026-08-04 por aiagentdevelopment.info · Sobre nosotros

Escrito por quienes construyen

Cada guía la escriben ingenieros que operan agentes en producción, no se reescribe de otros sitios.

Revisado periódicamente

Este campo cambia rápido. Cada guía lleva la fecha de su última revisión, y la publicamos aunque no haya cambiado nada.

Sin espacios pagados

Ningún proveedor de modelos, framework o plataforma puede comprar una mención, una posición ni un enlace.

Doce idiomas

Cada guía se traduce, no se sustituye con una máquina: cada idioma tiene su URL y su fecha de revisión.

Límites explícitos

Decimos con claridad cuándo una tarea no necesita un agente y un script sencillo sería más barato y fiable.