¿Cuál es el costo de un agente de IA? Construcción y operación

El costo de un agente de IA tiene dos partes: una construcción única (integraciones, acciones de escritura y evaluación) y una operación recurrente (llamadas al modelo, revisión humana y mantenimiento). Un agente de un solo flujo es un proyecto modesto; uno que escribe en varios sistemas del negocio es una decisión de plataforma.

Esta guía explica los factores detrás de cada cifra, ofrece rangos ilustrativos con sus supuestos explícitos y muestra cómo medir el costo por tarea antes de comprometerse. Los rangos son herramientas de planificación, no cotizaciones. Su flujo de trabajo, sus datos y su tolerancia a los errores los mueven más que cualquier tarifa de un proveedor. Las cifras se expresan en dólares estadounidenses; si presupuesta en euros o en pesos mexicanos, conviértalas con el tipo de cambio vigente y trátelas igualmente como una referencia, no como un precio.

Por qué es difícil estimar el costo de un agente de IA

Un chatbot responde una vez. Un agente planifica, llama a una herramienta, lee el resultado y decide si continúa. El número de llamadas al modelo por tarea no es fijo; depende de la entrada. Dos tickets de soporte que parecen iguales pueden generar una ejecución de tres pasos y otra de doce, y la segunda cuesta varias veces más procesarla.

El costo de construcción es difícil de precisar por otra razón. La demo es la parte barata. Un prototipo que llama a un modelo y a una API puede armarse en días. El trabajo caro está en los bordes: sistemas sin entorno de pruebas, registros que se contradicen entre sí, pantallas de aprobación, alcance de permisos, evaluación, monitoreo y la ruta de recuperación cuando una escritura se completa solo a medias. Nada de eso aparece en una demo, y todo eso decide si el agente puede quedarse encendido.

Lo que los equipos suelen hacer mal

El error más común es ponerle precio al modelo en lugar de al flujo de trabajo. Los tokens son la partida más visible, así que los presupuestos se anclan en ellos. En muchos flujos no son el costo más grande. El tiempo que una persona dedica a revisar borradores, las horas de ingeniería invertidas en integraciones y el mantenimiento mensual cuando se retira una versión del modelo suelen pesar más.

Otros errores recurrentes:

• Tratar el prototipo como la mayor parte de la construcción y descubrir después que el trabajo de producción es la porción más grande.
• Omitir el tiempo de revisión, aunque cada paso de aprobación convierte la salida del modelo en minutos humanos pagados.
• Olvidar el mantenimiento. Los modelos se retiran, las API de los proveedores cambian de versión y cada cambio de prompt necesita una ejecución de regresión.
• Operar sin techo. Un agente sin límite de pasos ni presupuesto por ejecución puede quedar en bucle con una herramienta que falla y seguir gastando hasta que alguien lo note.
• Comparar propuestas solo por tarifa diaria, cuando la diferencia real es si incluyen evaluación, monitoreo y traspaso.

Una forma práctica de estimar la construcción

Estime la construcción desde el flujo de trabajo hacia afuera. Anote los sistemas de los que el agente lee, los sistemas en los que escribe, las decisiones que toma y el peor error realista. Esa lista, no la elección del modelo, es lo que un desarrollador puede cotizar.

Los factores del costo de construcción

• Sistemas involucrados: cada integración necesita autenticación, manejo de errores y pruebas. Un sistema sin API o sin entorno de pruebas añade trabajo u obliga a un paso humano explícito.
• Lectura frente a escritura: un asistente de solo lectura es mucho más barato de hacer seguro que un agente que modifica registros, envía mensajes o mueve dinero.
• Experiencia de aprobación: quien revisa necesita ver el cambio propuesto, la evidencia que lo respalda y una forma de editarlo antes de aprobar.
• Preparación de datos: la recuperación sobre documentos desordenados produce respuestas equivocadas con mucha seguridad. A menudo hace falta limpiar la porción de datos de la que depende un flujo.
• Conjunto de evaluación: casos históricos reales con resultados correctos conocidos, más entradas adversarias, para medir la calidad antes del lanzamiento y después de cada cambio.
• Observabilidad y límites: registros por ejecución, seguimiento de costos, alertas y techos.
• Modelo de ejecución: un agente corto de petición y respuesta puede correr dentro de una solicitud web; las ejecuciones largas necesitan una cola, un proceso de trabajo y puntos de control.

Rangos ilustrativos de construcción

Los rangos siguientes suponen un equipo senior pequeño, sistemas existentes con API utilizables, un entorno de producción y un cliente capaz de aportar ejemplos históricos reales para la evaluación. Excluyen licencias de software, una limpieza amplia de datos más allá de la porción propia del flujo y el trabajo de cumplimiento que requiere revisión legal. Son órdenes de magnitud para una conversación de presupuesto, no precios.

• Asistente de solo lectura sobre sus propios documentos o un sistema, con citas y un conjunto de evaluación: aproximadamente de $8,000 a $25,000.
• Agente de un solo flujo que redacta acciones en un sistema, con un paso de aprobación, un registro de auditoría y monitoreo: aproximadamente de $20,000 a $60,000.
• Agente multisistema con varias integraciones de escritura, ejecución duradera, permisos por herramienta y una capa de herramientas compartida: a menudo de $60,000 a $150,000 o más, normalmente entregado por etapas.

Una cotización cerrada necesita un flujo acotado, datos de muestra y una definición escrita de lo que es un resultado correcto. Sin eso, cualquier número es una suposición disfrazada de precio.

Cómo estimar el costo de operación por tarea

El costo de operación es más fácil de razonar por tarea y luego multiplicarlo por el volumen. Use un modelo simple: costo por tarea igual a costo del modelo, más tarifas de herramientas y API, más infraestructura, más tiempo de revisión humana, más una parte del mantenimiento mensual.

Veamos un ejemplo con precios de referencia; consulte la lista de precios vigente de su proveedor antes de usar cifras reales. Suponga que un modelo cuesta $1 por millón de tokens de entrada y $5 por millón de tokens de salida. Una tarea típica hace ocho llamadas al modelo, cada una envía unos 6,000 tokens de entrada y recibe unos 500 de salida. Eso son 48,000 tokens de entrada, unos $0.048, y 4,000 tokens de salida, $0.02, es decir, alrededor de $0.07 por tarea. Con 20,000 tareas al mes, el gasto en el modelo ronda los $1,360.

Ahora sume la revisión. Si una persona dedica dos minutos a aprobar cada borrador, 20,000 tareas equivalen a unas 667 horas de revisión al mes. En este ejemplo, el tiempo de quien revisa es una partida mucho mayor que los tokens. Por eso el diseño de la aprobación, tratado en agentes con intervención humana, es una decisión de costo tanto como de seguridad.

Costos de mantenimiento y de cambio

Reserve presupuesto para el trabajo recurrente incluso cuando nada está roto. Las versiones de los modelos se retiran y sus reemplazos se comportan de otra manera. Los sistemas conectados cambian sus API. En el tráfico real aparecen casos límite nuevos que se convierten en nuevos casos de evaluación. Cada cambio de prompt o de modelo necesita una ejecución de regresión antes de publicarse. Los equipos suelen cubrir esto con un acuerdo de soporte mensual o con una parte definida del tiempo de un ingeniero interno.

Consideraciones de implementación que cambian la factura

Varias decisiones de ingeniería mueven directamente el costo de operación:

• Límites de pasos: limite el número de pasos de razonamiento por ejecución para que un agente confundido se detenga en lugar de entrar en bucle.
• Presupuestos por ejecución: detenga o escale cuando el uso de tokens de una tarea supere un umbral.
• Forma de la salida: trunque o resuma los resultados grandes de las herramientas antes de devolverlos al contexto del modelo.
• Enrutamiento de modelos: use un modelo más pequeño para los pasos de clasificación y extracción, y reserve el modelo más grande para planificar o redactar.
• Reintentos acotados: reintente solo ante errores que pueden resolverse al reintentar, con espera progresiva. Cada reintento es otra llamada pagada.
• Registro de uso: registre el uso de tokens por paso para que el costo por tarea salga de datos y no de estimaciones.
• Caché: reutilice el contexto recuperado y las instrucciones de sistema estables cuando el proveedor lo permita.

Ventajas y desventajas

Un modelo más barato puede elevar el costo total si necesita más pasos, más reintentos o más corrección humana. Mida la tarea completa, no el precio por token.

Los pasos de aprobación cuestan tiempo de revisión, pero reducen el costo esperado de un incidente. Manténgalos donde un error sale caro y retírelos donde la evidencia muestre que el agente es confiable.

Construir desde el inicio la ejecución duradera, un registro de llamadas a herramientas y la evaluación eleva la construcción inicial. Agregarlos cuando el agente ya está en producción suele costar más, porque los atajos del prototipo se han extendido por el código. El enfoque por etapas de migrar sistemas existentes a agentes mantiene pequeña la primera etapa sin perder esa estructura.

Lecciones del trabajo de ImadDhin

Las observaciones siguientes provienen del código del espacio de trabajo Agent de este portal. Son notas de implementación a nivel de código, no resultados de clientes ni cifras de costos de producción.

• La exposición al costo es una decisión de producto. El chat gratuito tiene un límite por visitante en el servidor, y las herramientas de investigación que llaman a una API externa de pago devuelven una respuesta de pago requerido salvo que el visitante tenga el nivel premium. Las capacidades caras se restringen antes de llamarlas, no después de que llegue la factura.
• Los contadores necesitan la consistencia adecuada. Un límite de uso es tan sólido como la forma en que se actualiza su contador. Un contador que lee y luego escribe permite que solicitudes concurrentes se salten el límite, un hallazgo frecuente al revisar productos construidos con IA. Puede ser tolerable para una pequeña cuota gratuita; todo lo vinculado a facturación o créditos debería usar un incremento atómico o una transacción.
• Las ejecuciones están acotadas en varios puntos. El motor de flujos limita una ejecución a un número fijo de pasos del grafo, rechaza puntos de control almacenados que superan un presupuesto de tamaño y trunca la salida de las herramientas antes de devolverla al modelo. Cada límite frena un tipo distinto de descontrol.
• El uso se registra por paso. Cada paso de razonamiento escribe los metadatos de uso del modelo en el registro de eventos de la ejecución, lo que convierte el costo por tarea en algo que se puede calcular a partir de registros.
• Los reintentos son gasto. El módulo de investigación hace como máximo tres intentos, respeta el encabezado de espera que envía el proveedor ante límites de tasa, espera de forma progresiva ante tiempos de espera agotados y errores del servidor, y nunca reintenta solicitudes mal formadas ni fallos de autenticación.

Errores comunes que conviene probar

Antes del lanzamiento, pruebe el comportamiento de costos con la misma atención que las respuestas:

• Envíe una entrada inusualmente larga o adversaria y confirme que el uso de tokens por ejecución se mantiene dentro del techo.
• Haga que una herramienta falle repetidamente y confirme que el agente se detiene o escala en lugar de entrar en bucle.
• Lance solicitudes concurrentes contra cualquier límite de uso y confirme que se mantiene donde debe.
• Simule una caída del proveedor y verifique cuánto cuesta y cómo se comporta la ruta alternativa.
• Cancele una ejecución a mitad de camino y confirme que el gasto se detiene.
• Confirme que puede reportar el costo por tarea de cada flujo, no solo el total de la factura mensual.

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

Si la tarea siempre sigue los mismos pasos, un flujo determinista con una sola llamada al modelo para clasificar o redactar es más barato de construir, más barato de operar y más fácil de probar que un agente. Si el volumen es bajo, una persona con una buena plantilla puede ser la opción más económica de todas.

Un agente justifica su costo cuando las entradas varían lo suficiente como para que la ruta deba decidirse caso por caso, y cuando el volumen es lo bastante alto como para amortizar la construcción. Si no está seguro de en qué lado de esa línea está un flujo, el AI Readiness Scan es una forma de bajo costo de averiguarlo antes de comprometerse con una construcción.

Obtenga un modelo de costos para su propio flujo

Una estimación útil parte del flujo de trabajo, de los sistemas que toca y del peor error realista, y luego separa el costo de construcción del costo por tarea. Si quiere ese modelo construido sobre su proceso real, consulte desarrollo de agentes de IA o traiga el flujo y sus volúmenes actuales a una llamada de 30 minutos.