Módulo 7: Cost Control Ai In Production And Mcp

1. Presentación del módulo: la IA que no arruine el presupuesto

Descripción

Al terminar esta lección vas a poder explicar por qué los workflows con IA son los que más rápido queman dinero en una instancia de producción, vas a saber exactamente qué preguntas hay que responder para que eso deje de pasar, y vas a tener el mapa completo de las siete lecciones que siguen. También vas a recibir el caso de estudio que acompaña todo el módulo —Terra Market— y, muy importante, la frontera explícita entre lo que aprendes aquí y lo que ya se enseña en otra guía del ecosistema.

Esto importa por una razón muy poco romántica: la factura. Un workflow que mueve pedidos entre tu tienda y tu ERP tiene un costo predecible. Corre, hace tres llamadas HTTP, escribe una fila y termina. Si mañana el volumen se duplica, el costo se duplica: es aritmética. Un workflow con un agente de IA adentro no se comporta así. Puede correr el martes por ocho centavos y el miércoles por cuarenta, con el mismo volumen de entrada, porque alguien cambió un número en un desplegable o porque un ticket llegó redactado de una forma que hizo que el agente diera cuatro vueltas en vez de una. Esa falta de proporción entre lo que entra y lo que se paga es la característica que define a la IA en producción, y es lo que hace que este módulo exista.

Conexión con el módulo: esta lección es el mapa, no la herramienta. Aquí defines el problema (por qué la IA se comporta distinto de todo lo demás que operas), conoces a Terra Market, y recibes la frontera con las guías hermanas. La lección 2 abre el capó del costo: qué es un token, por qué la salida cuesta más que la entrada, y dónde exactamente se fuga el dinero en una instancia. La lección 3 va al nodo AI Agent y a sus guardarraíles, que es donde vive el problema concreto de Terra Market. La 4 trata la elección de modelo, que no es una decisión estética sino un renglón de la factura y también un riesgo de que el workflow deje de funcionar sin aviso. La 5 pregunta si conviene traer el modelo a tu propia máquina, y la responde con números en vez de con ideología. Las 6 y 7 tratan MCP desde el único ángulo que le corresponde a esta guía: qué cuesta y qué arriesga tenerlo encendido. Y la 8 junta todo en un workflow de producción con presupuesto controlado.

La factura que se triplicó

Vamos a empezar por el problema, porque es el que abre el módulo y el que vas a estar resolviendo hasta la lección 8.

Terra Market es un marketplace latinoamericano de tamaño mediano. Unas 60 personas, vendedores en cinco países, y una operación que ya no cabe en hojas de cálculo. Tiene 18 workflows en producción que conectan tres sistemas: la tienda en línea, el ERP donde vive el inventario y la contabilidad, y el transportista que mueve las cajas. Entre los tres, la instancia procesa alrededor de 4.000 ejecuciones al día. La persona que opera esa instancia eres tú.

Hace un año Terra Market metió IA en dos lugares del flujo de soporte, y funcionó bien:

ticket-classify — cuando entra un ticket de soporte, un agente lo lee y decide a qué cola va: devoluciones, envío tardío, problema de pago, o consulta general. Antes lo hacía una persona a mano, y se tardaba.
reply-draft — para las categorías más repetitivas, un segundo agente redacta un borrador de respuesta que una persona revisa antes de enviar.

Los dos funcionan. Nadie se queja de la calidad. Y sin embargo, la última reunión de finanzas terminó con una pregunta que quedó sin respuesta:

La factura del proveedor de IA de este mes es el triple de la del mes pasado. El volumen de tickets subió un 8%. ¿Qué pasó?

Vale la pena mirar de frente lo que ese silencio significa, porque es exactamente el estado en el que están la mayoría de las instancias con IA en producción:

Nadie tiene un tope. Ni por workflow, ni por día, ni por mes. La factura es lo que resulte.
Nadie mide. No existe un registro de cuántos tokens consumió cada ejecución. Cuando alguien pregunta "¿cuánto nos costó atender los tickets de ayer?", la respuesta honesta es "no sé".
Alguien tocó algo. Hace unas tres semanas una persona del equipo abrió ticket-classify, vio un campo que decía Max Iterations con el valor 10, y lo subió "para que funcionara mejor" en unos casos raros que estaban fallando. Funcionó: esos casos dejaron de fallar. Nadie miró lo que le pasó al resto.

Y aquí está lo que hace incómoda la situación: ninguna de esas tres cosas es un error técnico. La instancia está sana, los workflows corren, las ejecuciones salen en verde, el monitoreo no se queja. Si tu única señal de que algo va mal es la tasa de error, este problema es invisible hasta que llega el estado de cuenta.

Piénsalo como un taxi al que le quitaron el taxímetro de la vista. El auto anda bien, el chofer maneja bien, llegas a donde ibas. La única señal de que algo se descontroló llega al final del viaje, cuando ya no puedes hacer nada al respecto. Todo este módulo es, en el fondo, volver a poner el taxímetro donde se vea.

Ejemplo trabajado: por qué el volumen no explica la factura

Vamos a hacer el razonamiento que Terra Market no hizo, sin números reales todavía —esos llegan en la lección 2— pero con la estructura correcta.

Si el costo de un workflow con IA fuera proporcional al volumen, la aritmética sería esta:

Costo del mes = ejecuciones × costo por ejecución

Mes 1:  N ejecuciones × C  =  Factura
Mes 2:  1.08 × N × C       =  1.08 × Factura     ← +8% de volumen, +8% de factura

Lo que Terra Market observó fue esto:

Mes 2 real:  ≈ 3 × Factura

Es decir: el volumen subió 8% y la factura subió 200%. La conclusión es inevitable: el costo por ejecución cambió. No el número de ejecuciones — lo que cada una cuesta.

Y ahí es donde aparece la diferencia estructural entre un workflow normal y uno con IA. En un workflow normal, el costo por ejecución es una constante que tú fijaste al diseñarlo: tres llamadas HTTP son tres llamadas HTTP. En un workflow con agente, el costo por ejecución es una variable que depende de tres cosas que casi nadie vigila:

Qué cambia	Quién lo cambia	Efecto en la factura
Cuántas veces el agente llama al modelo en una sola ejecución	El agente mismo, según lo que decida — con un techo que tú configuras (`Max Iterations`)	Multiplicador directo
Cuánto texto viaja en cada llamada	El prompt, el historial acumulado, la descripción de las herramientas	Multiplicador directo
Qué modelo atiende la llamada	Tú, al elegirlo en el sub-nodo	Puede ser un factor grande entre modelos del mismo proveedor

Fíjate en la primera fila, porque es la que explica el caso de Terra Market. La persona que subió Max Iterations no cambió el volumen ni el modelo ni el prompt. Cambió el techo de cuántas veces el agente puede hablar con el modelo dentro de una sola ejecución. Y como cada iteración es una llamada nueva —que además arrastra todo lo que pasó en las iteraciones anteriores—, subir ese número no suma costo: lo multiplica, y de forma no lineal.

Qué esperar cuando hagas este mismo diagnóstico en una instancia real. Vas a encontrar que la factura no tiene un culpable único. Casi nunca lo tiene. Vas a encontrar tres o cuatro contribuciones que por separado parecían inofensivas: un Max Iterations que alguien subió, un system prompt que creció de 200 a 900 palabras porque el equipo le fue agregando excepciones, un reintento automático que se configuró para tres intentos sin pensar que cada intento vuelve a pagar el modelo entero, y un workflow de prueba que quedó publicado. La suma de esas cuatro cosas es el triple. Ninguna de las cuatro, sola, lo habría sido.

Lo que hace distinta a la IA de todo lo demás que operas

Vale la pena poner esto en palabras claras, porque cambia cómo operas.

En los seis módulos anteriores de esta guía aprendiste a operar sistemas cuyo comportamiento es determinista: los mismos datos de entrada producen el mismo trabajo, la misma duración y el mismo costo. Cuando algo se desvía, es porque algo se rompió, y por eso el manejo de errores, el replay y las métricas de ejecución funcionan tan bien: todos parten de que hay un comportamiento normal contra el cual comparar.

Un agente de IA no es determinista. Los mismos datos de entrada pueden producir dos, tres o siete llamadas al modelo, según lo que el modelo decida en el momento. Eso tiene dos consecuencias operativas que conviene tener presentes desde ya:

Primera: la variabilidad es normal, no es una falla. No vas a "arreglar" un agente para que siempre haga exactamente dos llamadas. Lo que vas a hacer es acotar el rango: poner un techo, medir la distribución real, y alertar cuando se salga de lo esperado. Es una diferencia de mentalidad importante. Operar IA se parece más a administrar un presupuesto variable que a vigilar un servicio con tiempos garantizados.

Segunda: el costo es la señal más honesta que tienes. En un sistema determinista, el error te avisa que algo va mal. En un sistema con IA, muchas cosas que van mal no producen error: producen una respuesta más larga, una vuelta de más, un prompt que creció. La factura es el único lugar donde todas esas cosas se suman. Por eso este módulo trata el costo como una métrica de observabilidad de primera clase, al mismo nivel que la tasa de éxito o la latencia.

Hay una tercera diferencia, y es la que más incomoda: el proveedor puede retirar la pieza que estás usando. Ningún nodo de n8n se retira sin aviso, y una base de datos PostgreSQL que funciona hoy funciona el año que viene. Un modelo de lenguaje no: los proveedores anuncian fechas de retiro y, llegada esa fecha, el identificador que tienes escrito en tu workflow deja de existir y las llamadas fallan. Es un tipo de deuda que ningún otro componente de tu instancia tiene, y por eso la lección 4 existe.

La frontera: qué se enseña aquí y qué se enseña en otra guía

Esta es la sección más importante de la lección, y conviene leerla despacio.

Tres de las lecciones que siguen —la 5, la 6 y la 7— tratan temas que ya están montados paso a paso en otra guía de este mismo ecosistema: n8n-business-automation-recipes-guide, módulo 6. Si vienes de ahí, ya sabes conectar esas piezas. Si no vienes de ahí, ahí es donde tienes que ir para aprender a conectarlas.

Esta guía no repite el montaje. Aquí el ángulo es otro, y es el ángulo de operación: qué cuesta y qué arriesga tener esa pieza encendida en producción.

Tema	Dónde está el montaje (cómo se conecta)	Qué agrega esta guía (qué cuesta y qué arriesga)
Modelos locales con Ollama y una base vectorial	`business-recipes` M6-L6 — `local-rag-zero-cost`: el stack completo, el `docker-compose`, las direcciones de red, el modelo de embeddings, la primera indexación	Lección 5: la decisión económica. Cuándo un modelo local sale más barato que una API y cuándo es al revés. El punto de equilibrio. La latencia como costo escondido. Qué se degrada cuando eliges el modelo pequeño
Exponer tu instancia como servidor MCP	`business-recipes` M6-L5 — `your-instance-as-mcp-server`: el `MCP Server Trigger`, el servidor MCP de instancia, los dos interruptores, la conexión del cliente	Lección 6: la superficie de riesgo. Quién puede llamarlo, con qué autenticación, qué workflows expones y cuáles jamás, y qué le pasa a tu factura cuando un agente externo entra en bucle
Consumir servidores MCP externos	`business-recipes` M6-L4 — `mcp-client-tool`: el nodo `MCP Client Tool`, sus campos, cómo se acota el catálogo	Lección 7: la dependencia. Cada MCP externo es un tercero que puede cambiar, caerse o cobrarte. Qué le pasa a tu workflow cuando ese servidor no responde, y cómo se acota el gasto de un agente que decide solo cuántas veces llamar

Hay una frontera más, con otra guía hermana: n8n-ai-chatbots-agents-guide, módulo 4, cubre las herramientas de un agente —el contrato de cada tool, los límites de confianza, la revisión humana antes de una acción irreversible—. Ese módulo se ocupa de qué puede hacer el agente. Este se ocupa de qué cuesta que lo haga. Son complementarios y no se contradicen; cuando aparezca una decisión que toque los dos ángulos, lo vas a ver marcado.

Y una frontera hacia adentro de esta misma guía, para que no busques en el lugar equivocado:

El módulo 4 de esta guía monta la observabilidad general: logging estructurado, métricas de ejecución, health checks, alertas. Aquí vas a construir una métrica más —el costo— y va a vivir en esa misma capa. No vamos a rehacer la capa.
El módulo 5 trata la seguridad de credenciales, incluidas las llaves de los proveedores de IA, desde el ángulo de quién puede verlas y usarlas. Este módulo toca las mismas llaves desde el ángulo de cuánto se gasta con ellas. Una llave filtrada es un problema de seguridad; una llave sin tope de gasto es un problema de presupuesto. Los dos ángulos importan y no son el mismo.
El módulo 2 trata el manejo de errores. Aquí vas a descubrir que un reintento automático sobre un nodo de IA no es gratis como sobre un nodo HTTP, y eso cambia cómo lo configuras. Pero el mecanismo del reintento lo aprendes allá.

Los identificadores del caso

Toda la guía usa los mismos nombres, y todos van en inglés. Conviene fijarlos desde ya porque los vas a ver en las siete lecciones que siguen y en el proyecto final.

Identificador	Qué es
`ticket-classify`	El workflow con agente que clasifica los tickets de soporte que entran
`reply-draft`	El workflow con agente que redacta el borrador de respuesta para las categorías repetitivas
`order-sync`	Uno de los workflows sin IA: sincroniza pedidos entre la tienda y el ERP. Sirve de contraste — es el que sí tiene costo predecible
`token_usage`	El campo donde se guardan los tokens consumidos por una llamada al modelo
`cost_log`	El registro donde vas a acumular el gasto: una fila por ejecución de un workflow con IA
`monthly_budget`	El tope de gasto mensual que Terra Market va a fijar, y contra el que se compara el acumulado

La convención es la de todo el ecosistema: el código, los nombres de campo y los identificadores van en inglés; la prosa y los comentarios van en español. Es la mezcla que vas a encontrar en cualquier equipo tech de la región, y hace que tus workflows sean legibles para alguien que no habla español.

Una nota de honestidad sobre los números de Terra Market: 60 personas, 18 workflows, 4.000 ejecuciones al día. Son hipótesis razonables para practicar, no datos de mercado. Si mañana operas una instancia real, los números van a ser otros; lo que se transfiere es la forma de pensar el problema y la estructura del cálculo.

Lo que vas a poder hacer al terminar el módulo

Al final de la lección 8 vas a poder:

Calcular el costo de una ejecución con IA desglosado en tokens de entrada y de salida, y estimar el costo mensual de un workflow a partir de su volumen.
Instrumentar un workflow con IA para que registre su propio consumo en cost_log, usando un nodo Code que lee datos que ya vienen en el item.
Configurar los guardarraíles del nodo AI Agent con criterio: saber qué hace Max Iterations, por qué subirlo multiplica el gasto, y cuándo Return Intermediate Steps vale lo que cuesta.
Verificar que el modelo que usas sigue vigente, con un procedimiento que no depende de que alguien te avise, y elegir el modelo correcto por tarea en vez de usar el mismo para todo.
Decidir con números si un modelo local le conviene a una operación concreta, incluyendo el costo del servidor que nadie cotiza.
Evaluar la superficie de riesgo y de gasto de exponer tu instancia por MCP y de depender de servidores MCP de terceros.
Poner un tope y alertar antes de llegar, en vez de enterarte con el estado de cuenta.

Lo que no vas a poder hacer al terminar, y está bien: construir agentes de IA sofisticados, montar un pipeline RAG desde cero, o afinar prompts para mejorar la calidad de las respuestas. Esta guía opera sistemas de IA en producción; construirlos es el trabajo de las guías de IA del ecosistema. Si al terminar sientes que sabes exactamente qué te cuesta cada agente pero no sabrías construir uno mejor, ese es el resultado esperado.

El mapa de este módulo

Lección	Qué resuelve
2	Dónde se fuga el dinero: qué es un token, por qué la salida cuesta más, cómo se calcula el costo de una ejecución, y las cinco fugas clásicas. Aquí construyes `cost_log`
3	El nodo `AI Agent` en producción: qué es una iteración, qué hace `Max Iterations` y por qué subirlo multiplica el gasto, qué cuesta `Return Intermediate Steps`, y cómo se pone un techo que no rompa el caso de uso
4	Elegir modelos vigentes: el ciclo de vida de un modelo, el procedimiento para verificar que el tuyo sigue vivo antes de cada cohorte, y cómo elegir por tarea en vez de usar el caro para todo
5	Modelos locales: la decisión económica. El punto de equilibrio entre un servidor con GPU y una API, la latencia como costo escondido, y qué se degrada con el modelo pequeño
6	Exponer tu instancia por MCP: la superficie de riesgo. Quién llama, con qué autenticación, qué se expone, y qué pasa con la factura cuando un agente externo entra en bucle
7	Consumir MCP externos: la dependencia. Qué pasa cuando el tercero no responde, y cómo se acota el gasto de un agente que decide solo cuántas veces llamar
8	Proyecto: un workflow de IA en producción con presupuesto medido, modelo vigente, guardarraíles y alerta antes de reventar el tope

El orden no es arbitrario. Primero medir (lección 2), porque no se puede controlar lo que no se mide y porque cada lección posterior necesita esos números. Después el guardarraíl más importante (lección 3), que es el que explica el caso concreto de Terra Market. Después las dos decisiones de arquitectura que mueven el costo de forma estructural: qué modelo (4) y dónde corre (5). Después las dos superficies de exposición que agregan riesgo y gasto desde afuera (6 y 7). Y al final el proyecto, que las junta.

Qué es gratis y qué es Enterprise

Vale la pena decirlo temprano y sin rodeos, porque en este terreno hay bastante confusión y porque afecta lo que vas a poder construir.

Lo que funciona en cualquier instancia, incluida Community self-hosted: el nodo AI Agent y sus opciones, incluido Max Iterations. Los sub-nodos de modelo de todos los proveedores. El nodo Code, que es donde vas a contar tokens y acumular costo. Las tablas de datos nativas de n8n para guardar cost_log. Los nodos de notificación para alertar. El MCP Server Trigger y el MCP Client Tool. El Self-Hosted AI Starter Kit para correr modelos locales. Es decir: todo lo que este módulo te pide construir se puede construir sin pagar licencia de n8n.

Lo que no es de n8n y sí se paga: los tokens del proveedor de IA. Ese es el gasto del que trata el módulo entero, y no depende de tu edición de n8n. Y si eliges el camino local, el servidor donde corre el modelo — que se paga esté ocupado o no, y de eso trata la lección 5.

Lo que sí es Enterprise en n8n son piezas de gobierno que ayudan pero no son imprescindibles para el proyecto: control de acceso fino, almacenes de secretos externos, registro de auditoría avanzado, entornos con Git. El módulo 8 de esta guía los trata a fondo. Aquí los vas a ver mencionados cuando cambien una recomendación, siempre con una alternativa que funcione sin Enterprise. Como cualquier detalle de edición envejece rápido, verifica en la página de precios de n8n qué incluye tu plan antes de prometerle algo a tu equipo.

Una última honestidad sobre las cifras: en este módulo no vas a encontrar una tabla de precios de proveedores de IA. No es por descuido: los precios cambian, y una tabla vieja en una guía es peor que ninguna tabla — alguien la va a usar para presupuestar y va a presupuestar mal. Lo que sí vas a encontrar es cómo se calcula el costo, y a dónde ir a buscar el precio vigente el día que lo necesites. Esa habilidad no envejece.

Errores comunes

Creer que "no falló" significa "salió bien" (conceptual). Qué pasa: alguien mira el panel de ejecuciones, ve 4.000 ejecuciones en verde, y concluye que la operación está sana. Tres semanas después la factura llega triplicada y nadie entiende cómo, porque el monitoreo nunca se quejó. Por qué pasa: todas las métricas que aprendiste a montar en el módulo 4 —tasa de éxito, duración, volumen— son métricas de funcionamiento, y un agente que da diez vueltas en vez de dos funciona perfectamente: entrega la respuesta correcta y sale en verde. Cómo detectarlo: pregúntate si sabes responder "¿cuánto costó la ejecución más cara de ayer?". Si no lo sabes, tienes el problema. Cómo corregirlo: tratar el costo como una métrica más, con su registro y su alerta, exactamente igual que la duración. Es lo que construyes en la lección 2 y lo que cierra el proyecto de la lección 8.

Tratar el ajuste de un parámetro de IA como un cambio menor (práctico). Qué pasa: alguien abre un agente, sube Max Iterations de 10 a 30 "para que funcione mejor" en unos casos raros, comprueba que esos casos ahora funcionan, y cierra. El cambio arregló lo que quería arreglar y multiplicó el techo de gasto de las 4.000 ejecuciones diarias. Por qué pasa: el campo se ve como cualquier otro campo de configuración, y no hay nada en la interfaz que diga "esto es un multiplicador de tu factura". Cómo detectarlo: revisa el historial de cambios de tus workflows con IA de los últimos dos meses y busca cambios en Max Iterations, en el system prompt, en el modelo elegido o en la lista de herramientas. Cualquiera de esos cuatro es un cambio de costo disfrazado de cambio de configuración. Cómo corregirlo: adopta la regla que vamos a formalizar en la lección 3 — un cambio en un parámetro de agente se mide antes y después, con una muestra de ejecuciones reales, igual que medirías un cambio de rendimiento.

Meter la IA en un workflow de alto volumen sin haber medido primero (conceptual). Qué pasa: una automatización que corre miles de veces al día recibe un nodo de IA "para clasificar mejor", el piloto se prueba con veinte casos, funciona bien, y se publica. El costo de veinte casos es imperceptible; el de miles al día no. Por qué pasa: el piloto se evalúa por calidad, no por costo, y a esa escala el costo no se nota. Cómo detectarlo: antes de publicar, multiplica el costo observado en el piloto por el volumen real de producción y mira el número resultante. Si nunca hiciste esa multiplicación, no sabes lo que vas a publicar. Cómo corregirlo: el piloto de un workflow con IA tiene dos criterios de aceptación, no uno — que la calidad sirva y que el costo proyectado quepa en el presupuesto. La lección 2 te da la aritmética para el segundo.

Confundir esta guía con la guía de construir agentes (conceptual). Qué pasa: alguien llega a este módulo esperando aprender a montar un stack local completo o a conectar su primer servidor MCP, y se frustra porque las lecciones 5, 6 y 7 no traen el paso a paso. Por qué pasa: los títulos suenan a montaje. Cómo detectarlo: si lo que necesitas es "¿qué escribo en el campo Endpoint?", estás en la guía equivocada. Cómo corregirlo: ve a n8n-business-automation-recipes-guide, módulo 6, que monta las tres cosas paso a paso, y vuelve aquí cuando la pregunta sea "¿esto qué me va a costar y qué me puede romper?". Las dos guías están hechas para leerse en ese orden y ninguna repite a la otra.

Ejercicios

Ejercicio 1 — Separa lo predecible de lo variable. Terra Market tiene 18 workflows en producción. Aquí van seis de ellos, con una descripción de una línea. Para cada uno, decide si su costo por ejecución es predecible (lo fijaste tú al diseñarlo) o variable (depende de lo que pase en tiempo de ejecución), y escribe en una frase por qué.

(a) order-sync — cada 5 minutos lee pedidos nuevos de la tienda y los escribe en el ERP. (b) ticket-classify — cuando entra un ticket, un agente lo lee y decide a qué cola va. (c) label-print — cuando un pedido pasa a "listo", llama a la API del transportista y guarda el PDF de la guía. (d) reply-draft — para tickets de ciertas categorías, un agente redacta un borrador de respuesta. (e) stock-alert — cada hora consulta el inventario y manda un mensaje si algún SKU bajó del mínimo. (f) weekly-report — los lunes junta las métricas de la semana y arma un resumen en texto usando un modelo.

Ver solución

Predecibles: (a), (c) y (e). Los tres hacen un número fijo de llamadas a sistemas cuyo precio no depende del contenido. order-sync cuesta lo mismo con 3 pedidos que con 30 en términos de estructura: es una llamada por lote, y si crece el volumen crece de forma proporcional y visible. label-print es una llamada por pedido. stock-alert es una consulta por hora. Si mañana el volumen se duplica, el costo se duplica, y eso es todo.

Variables: (b), (d) y (f). Los tres tienen una llamada a un modelo de lenguaje adentro, y en los tres el costo de una ejecución depende de cosas que no fijaste al diseñar: cuánto texto trae el ticket, cuántas vueltas decide dar el agente, cuánto texto genera de respuesta.

Vale la pena mirar la diferencia entre (b) y (d), porque no es la misma clase de variabilidad. ticket-classify genera poca salida —una categoría, unas pocas palabras— y su costo está dominado por lo que entra: el texto del ticket más el prompt. reply-draft genera mucha salida —un borrador de respuesta completo— y la salida es la parte cara, por razones que vas a ver en la lección 2. Dos workflows con IA, dos perfiles de costo distintos, y por eso en la lección 4 vas a ver que probablemente no deberían usar el mismo modelo.

Y (f) merece una nota aparte: corre una vez por semana. Aunque su costo por ejecución sea alto, su contribución mensual es de cuatro ejecuciones. Es el recordatorio de que el costo total es costo por ejecución multiplicado por frecuencia, y que optimizar el workflow caro que corre poco suele rendir menos que optimizar el barato que corre miles de veces.

Por qué funciona: el criterio que estás practicando es "¿el costo lo fijé yo al diseñar, o lo decide algo en tiempo de ejecución?". Esa pregunta, sola, separa los workflows que puedes presupuestar de los que tienes que vigilar. Y son justamente los segundos los que necesitan lo que construyes en este módulo.

Ejercicio 2 — Reconstruye el diagnóstico. La factura de Terra Market se triplicó. El volumen subió 8%. Te dan estos cuatro hechos, todos ciertos, todos del último mes. Ordénalos por cuánto crees que cada uno contribuyó al aumento, de mayor a menor, y justifica el orden en una frase por cada uno.

(i) Alguien subió Max Iterations de 10 a 30 en ticket-classify, que corre unas 300 veces al día. (ii) El system prompt de reply-draft creció de 200 a 900 palabras porque el equipo le fue agregando excepciones de política de devoluciones. (iii) Se activó el reintento automático (3 intentos) en el nodo del agente de ticket-classify, porque a veces el proveedor devolvía un error temporal. (iv) Un workflow de prueba llamado reply-draft-test quedó publicado y corriendo con un trigger de cada 15 minutos.

Ver solución

No hay un orden único correcto sin los números reales, y ese es parte del punto: el diagnóstico honesto termina en "hay que medirlo", no en una conjetura con cara de certeza. Pero sí hay un razonamiento defendible, y es este.

Probablemente el mayor: (i), el Max Iterations. Es el único de los cuatro que es un multiplicador en vez de un sumando, y afecta a un workflow de volumen alto. Subir el techo de 10 a 30 no significa que todas las ejecuciones ahora den 30 vueltas —la mayoría seguirá dando dos o tres—, pero sí significa que las ejecuciones que antes se cortaban en 10 ahora pueden llegar a 30, y esas son las caras. Y hay un detalle que lo empeora y que vas a ver en la lección 3: cada iteración arrastra el historial de las anteriores, así que la iteración número 20 cuesta bastante más que la número 2.

Segundo, probablemente (iv), el workflow de prueba publicado. Un trigger cada 15 minutos son 96 ejecuciones diarias que nadie pidió, en un workflow que genera texto largo. Es gasto puro, sin ninguna contraparte de valor. Y es el más fácil de arreglar de los cuatro: se despublica y se acabó.

Tercero, (ii), el system prompt que creció. De 200 a 900 palabras son unas 700 palabras extra en cada llamada al modelo, para siempre. Suena poco por llamada y es mucho por mes. Pero es un sumando constante, no un multiplicador, así que su efecto es más predecible que el de (i).

Cuarto, (iii), el reintento. Contribuye solo en las ejecuciones que fallan, que deberían ser una minoría. Ahora bien, tiene una característica que lo hace merecer atención aparte de su tamaño: un reintento sobre un nodo de IA vuelve a pagar la llamada completa. No es como reintentar un HTTP Request a un endpoint gratuito. Si la tasa de fallo del proveedor sube, este renglón crece rápido y sin aviso.

Y la observación que vale más que el orden: ninguno de los cuatro, solo, explica un aumento del 200%. Los cuatro juntos, sí. Esa es la forma típica de este problema — varias contribuciones que por separado parecían inofensivas. Por eso el primer paso del módulo no es apagar cosas: es medir, para saber cuál de los cuatro es cuál. Apagar a ciegas te deja sin saber si arreglaste el problema o si solo lo escondiste.

Por qué funciona: distinguir multiplicadores de sumandos es el criterio más rentable en control de costos de IA. Un multiplicador afecta a todas las ejecuciones y crece con el volumen; un sumando afecta a una parte. Cuando tengas que priorizar dónde meter mano, empieza siempre por los multiplicadores.

Ejercicio 3 — Ubica cada pregunta en su guía. Para cada una de estas seis preguntas, decide si la responde este módulo, o si corresponde a business-recipes M6, o a n8n-ai-chatbots-agents-guide M4, o a otro módulo de esta misma guía. Justifica en media frase.

(a) "¿Qué URL pongo en el campo Endpoint del nodo MCP Client Tool?" (b) "Si expongo mi instancia por MCP y un agente externo entra en bucle, ¿cuánto puedo llegar a pagar?" (c) "¿Cómo escribo la descripción de una tool para que el agente la elija en el momento correcto?" (d) "¿Me conviene montar un servidor con GPU o seguir pagando la API?" (e) "¿Cómo configuro el docker-compose para que n8n y Ollama se vean entre sí?" (f) "¿Dónde guardo la llave de API del proveedor de IA para que no quede en texto plano?"

Ver solución

(a) business-recipes M6-L4. Es montaje puro: qué campo, qué valor. Esa lección incluso advierte sobre el nombre heredado SSE Endpoint y sobre pegar la dirección del transporte equivocado. Aquí no lo repetimos.

(b) Este módulo, lección 6. Es exactamente el ángulo de operación: la superficie de riesgo y el peor caso de factura. Es la pregunta que nadie hace hasta que ya pasó.

(c) n8n-ai-chatbots-agents-guide M4. El contrato de una tool —nombre, descripción, parámetros— es diseño del agente, no operación. Esa guía le dedica una lección entera.

(d) Este módulo, lección 5. Y fíjate en que es una pregunta de números, no de montaje. Cómo montar el stack local está en business-recipes M6-L6; si te conviene o no, está aquí.

(e) business-recipes M6-L6. Montaje. Esa lección incluso explica por qué la dirección es http://ollama:11434 y no localhost, que es el tropiezo número uno.

(f) Módulo 5 de esta misma guía, que trata la seguridad de credenciales y secretos, y tiene una lección dedicada a proteger llaves de API y tokens de LLM. Aquí tocamos esas mismas llaves pero desde el gasto, no desde el acceso.

Por qué funciona: la pregunta que separa las guías es "¿esto es cómo se conecta, o es qué cuesta y qué arriesga?". Si es lo primero, es la guía de recetas. Si es lo segundo, es esta. Y si es "¿qué debería poder hacer el agente?", es la guía de agentes. Tener esa separación clara te ahorra buscar en el lugar equivocado y, cuando entregues documentación de una instancia, te da la estructura para decir a dónde va cada pregunta.

Resumen y siguiente paso

En esta lección viste por qué los workflows con IA se comportan distinto de todo lo demás que operas: su costo por ejecución no es una constante que fijaste al diseñarlos, sino una variable que depende de cuántas veces el agente llama al modelo, de cuánto texto viaja en cada llamada y de qué modelo la atiende. Esa falta de proporción entre entrada y factura es la razón de ser del módulo, y quedó ilustrada con el caso que lo abre: la factura de Terra Market se triplicó con un 8% más de volumen, y nadie sabe por qué porque nadie tiene tope, nadie mide, y alguien cambió Max Iterations sin medir el efecto.

Viste las tres diferencias operativas que se derivan de eso: que la variabilidad de un agente es normal y se acota en vez de arreglarse, que el costo es la señal más honesta porque muchas cosas que van mal no producen error, y que un modelo —a diferencia de cualquier otro componente de tu instancia— puede ser retirado por su proveedor con fecha anunciada.

Y sobre todo recibiste la frontera: las lecciones 5, 6 y 7 no montan modelos locales ni MCP, porque eso ya está montado paso a paso en n8n-business-automation-recipes-guide módulo 6. Aquí el ángulo es qué cuesta y qué arriesga tener esas piezas encendidas. Con dos fronteras más: la guía de agentes se ocupa de qué puede hacer el agente, y los módulos 4 y 5 de esta misma guía se ocupan de la capa de observabilidad y de la seguridad de las llaves.

Antes de avanzar deberías poder: explicar en una frase por qué la factura de un workflow con IA no es proporcional al volumen; nombrar las tres cosas que hacen variar el costo por ejecución; y decir, ante una pregunta cualquiera de IA en n8n, si le toca a esta guía o a una de las guías hermanas.

La lección 2 baja al detalle que todo lo demás necesita: qué es exactamente un token, por qué el texto que el modelo genera cuesta más que el texto que recibe, cómo se calcula el costo de una ejecución concreta, y cuáles son las cinco fugas por donde se escapa el dinero en una instancia real. Al final de esa lección vas a tener cost_log funcionando: un registro que escribe una fila por cada ejecución con IA, con sus tokens y su costo estimado, construido con un nodo Code que solo lee datos que ya vienen en el item. A partir de ahí dejas de opinar sobre la factura y empiezas a medirla.

Recursos

AI Agent node — n8n Docs — el nodo que está en el centro del módulo. Ahí viven Max Iterations, Return Intermediate Steps y el resto de las opciones que vas a operar.
Tools Agent — n8n Docs — la variante concreta del agente con su lista completa de opciones y sus valores por defecto. Verifica ahí lo que ves en tu versión.
Code node — n8n Docs — la herramienta con la que vas a contar tokens y acumular costo, y sus límites en n8n 2.0.
Self-hosted AI Starter Kit — n8n Docs — el montaje oficial del stack local. Lo vas a necesitar como referencia en la lección 5, aunque el montaje paso a paso está en la guía hermana.
Guía hermana n8n-business-automation-recipes-guide, módulo 6 (este mismo ecosistema) — el montaje completo de MCP cliente, MCP servidor y RAG local a costo cero. Es donde vas cuando la pregunta es "cómo se conecta".
Guía hermana n8n-ai-chatbots-agents-guide, módulo 4 (este mismo ecosistema) — herramientas del agente, contratos de tool y límites de confianza. Es donde vas cuando la pregunta es "qué debería poder hacer".

← Anterior8. Proyecto: hacer rápido un workflow lento Siguiente →2. Control de costos: dónde se fuga el dinero