Créditos de IA: ¿qué pasa si se agotan a mitad de mes?

TL;DR (Quick Summary)

Agotar los créditos puede detener un flujo, dejar ejecuciones en cola, activar un modo limitado o generar cargos adicionales. La previsión depende de qué pasos usan IA, cuántas veces se ejecutan y qué respaldo existe.

• Definir qué se está comprando → Identificar la unidad real de consumo.
• Mapear el flujo antes de calcular → Separar los pasos que usan IA de las reglas convencionales.
• Calcular el consumo del proceso → Estimar el volumen habitual y los escenarios de mayor demanda.
• Prever qué ocurre cuando se agota el saldo → Identificar ejecuciones detenidas, pendientes o incompletas.
• Diseñar una ruta de respaldo → Mantener la continuidad operativa sin ocultar errores.
• Definir límites y monitorización → Medir consumo, bloqueos y calidad.
• Dejar las condiciones por escrito → Acordar reglas de cobro, reintentos y ajustes de precio.
• Resolver los casos límite → Establecer cómo recuperar el trabajo pendiente.

Key Takeaway: el mayor riesgo es perder trazabilidad o dejar casos incompletos sin detectar, más allá de pagar de más. Antes de contratar, hay que conocer la unidad de cobro, el comportamiento al llegar al límite y el procedimiento para recuperar las ejecuciones afectadas.

---

El día 18 del mes, un flujo de atención recibe nuevos casos, pero la clasificación automática deja de ejecutarse porque se agotó el saldo disponible. Los tickets siguen entrando, algunas notificaciones se envían y otras no, y el equipo desconoce cuáles quedaron incompletos. El proveedor informa que se consumió la asignación de créditos, pero no aclara si las ejecuciones se detuvieron, quedaron en cola o generaron cargos adicionales.

Este es el problema de quedarse sin créditos a mitad de mes: el flujo puede seguir recibiendo trabajo sin completarlo de forma predecible. Por eso, no basta con calcular cuánto cuesta una automatización. También hay que saber qué unidad de trabajo se cobra, cuántas veces puede ejecutarse por caso y qué hará la plataforma cuando el saldo llegue a cero. Estas condiciones deben definirse antes de poner el flujo en producción.

Definir qué se está comprando realmente

“Créditos de IA” describe una unidad comercial, pero no necesariamente una unidad operativa clara. Un crédito puede representar una llamada a un modelo, un documento analizado, una ejecución de agente, un enriquecimiento de datos o varias operaciones dentro de un flujo.

Hay tres esquemas habituales:

• Crédito abstracto: se compra una bolsa de unidades y cada función descuenta una cantidad distinta.
• Cobro por acción: se factura cada ejecución, como resumir un correo o extraer campos de una factura.
• Modelo híbrido: existe una cuota base y, al superarla, se cobra el exceso, se bloquea el consumo o se modifica el comportamiento del flujo.

Dos proveedores conocidos muestran cómo se ven estos esquemas en la práctica. Microsoft vende los créditos de Copilot Studio en paquetes de 25.000 al mes por 200 USD, un crédito abstracto que cada función descuenta a su ritmo, y ofrece además una modalidad de pago por uso que se factura según el consumo real.

Salesforce cobra Agentforce por acción: con Flex Credits, a 500 USD por cada 100.000 créditos, lo que equivale a unos 0,10 USD por acción estándar del agente, o a 2 USD por conversación en los agentes de cara al cliente. Si se supera lo contratado, el exceso se factura a mes vencido, un ejemplo de modelo híbrido. Las tarifas y los multiplicadores por tipo de acción cambian con frecuencia, así que revísalos en la página oficial antes de presupuestar.

Un proceso de alta de clientes (onboarding) que el usuario percibe como una sola operación puede incluir la clasificación del formulario, la extracción de datos de un documento de identidad, una consulta de riesgo y un resumen para el analista. La plataforma puede contabilizar varias operaciones de IA, además de las integraciones y el almacenamiento, según sus reglas de consumo.

Lo mismo ocurre con funciones integradas. Al analizar una llamada, CoPilot en el CRM de Bitrix24 transcribe la conversación, la resume y completa los campos vacíos de la ficha. El usuario lo vive como una sola acción, pero detrás hay tres pasos de IA; al estimar el consumo, hay que contar pasos, no clics.

Tampoco todo el costo procede de la IA generativa. Hay que separar las llamadas a modelos de las reglas convencionales, los webhooks, las consultas al CRM, el almacenamiento, la transferencia de datos y las tareas programadas. Algunas plataformas incluyen varias operaciones en un mismo saldo; otras las desglosan por producto o módulo.

Antes de comparar precios, solicita una tabla de consumo con ejemplos verificables que indique:

• Qué acción consume créditos y cuántos.
• Qué ocurre cuando una ejecución falla o se reintenta.
• Si una ejecución parcial genera un cargo.
• Cómo se contabilizan los pasos de un mismo flujo.
• Qué servicios se cobran por separado y cuáles están incluidos en la cuota.

Sin esa definición, el precio por crédito no permite estimar el costo real ni planificar la operación.

[BANNER type="lead_banner_1" title="Plantilla para controlar consumo de créditos y recarga" description="Ingresa tu correo electrónico para descargar una guía que te ayudará a comenzar con cualquier software de gestión de proyectos." picture-src="/upload/medialibrary/c0f/04zrwoo0jpzvirn15czqu595pynw0yl9.webp" file-path="/upload/medialibrary/c40/veetou3lsi4jwyvb6ya7l5jwbs25jtht.pdf"]

Mapear el flujo antes de calcular consumo

Presupuestar “un crédito por flujo” suele ser impreciso. El consumo se concentra en pasos concretos y algunos solo se ejecutan en determinadas ramas. Para estimarlo, hay que identificar cada operación que puede consumir créditos y cuántas veces se ejecuta por caso.

Un flujo de soporte puede dividirse en:

• Entrada: correo, formulario, mensaje o archivo.
• Clasificación: tipo de solicitud, prioridad o intención.
• Extracción: campos obtenidos de texto, imágenes o documentos.
• Decisión y actualización: selección de una ruta y actualización del CRM, ERP o sistema de tickets.
• Notificación y escalamiento: avisos a usuarios o responsables y derivación de excepciones.

Clasificar lenguaje natural puede justificar una llamada a IA. En cambio, validar un campo obligatorio o actualizar el estado de un ticket normalmente puede resolverse con reglas fijas. En Bitrix24, por ejemplo, las reglas de automatización del CRM permiten cambiar registros de etapa, crear tareas y enviar notificaciones mediante condiciones predefinidas.

Para cada etapa, documenta la entrada, la operación, la salida y la condición de ejecución. Así puedes identificar, por ejemplo, que la extracción solo ocurre cuando hay adjuntos, que el resumen se genera al escalar un caso a un supervisor y que una corrección del usuario activa una segunda clasificación.

Este mapa permite distinguir las operaciones que usan IA de las que siguen reglas convencionales y calcular cuántas veces puede ejecutarse cada una. No obstante, que una acción no use IA no significa necesariamente que sea gratuita: algunas plataformas también contabilizan ejecuciones de automatización, integraciones u otros servicios. Confirma las reglas de cobro antes de estimar el costo.

Como criterio de diseño, reserva la IA para interpretar contenido ambiguo o realizar transformaciones que las reglas fijas no resuelven bien. Utiliza condiciones deterministas para validaciones y actualizaciones previsibles. Esta separación ayuda a controlar el consumo y facilita detectar qué paso lo incrementa cuando cambia el volumen o aparecen excepciones.

Calcular cuántos créditos consume el proceso

La previsión debe partir del volumen de trabajo, no del número de usuarios contratados. Como estimación inicial:

Consumo base mensual = casos mensuales × ejecuciones medias de IA por caso × créditos por ejecución.

Después, hay que ajustar el cálculo por reprocesos, excepciones y ejecuciones adicionales. Si las tasas se calculan sobre el consumo base y las ejecuciones fijas se contabilizan aparte, puede usarse esta fórmula:

Consumo ajustado = consumo base × (1 + tasa de reproceso + tasa de excepciones) + ejecuciones fijas adicionales.

Esta fórmula es una aproximación: si los reprocesos y las excepciones se solapan, sumarlos puede sobreestimar el consumo. Cuando haya datos históricos, es preferible calcular el consumo adicional observado por cada causa.

Un proceso que clasifica solicitudes y extrae datos de adjuntos debe contabilizar cuántas entradas incluyen documentos, cuántas requieren una segunda lectura, cuántas regresan por corrección y cuántas se envían a otro modelo por su complejidad.

Trabaja con tres escenarios:

• Normal: volumen habitual, pocas excepciones y ruta estándar.
• Pico: campañas, cierres mensuales o temporadas de alta demanda.
• Reproceso: errores de integración, correcciones manuales, documentos ilegibles o instrucciones enviadas de nuevo al modelo.

Ejemplo ilustrativo: supongamos una bolsa de 8.000 créditos al mes, dos ejecuciones de IA por caso, un crédito por ejecución y 300 créditos fijos para resúmenes diarios. Para facilitar la comparación, consideramos un mes de 30 días y un consumo distribuido de forma uniforme.

• Escenario normal: 3.000 casos × 2 ejecuciones × 1 crédito = 6.000 créditos de consumo base. Con un 10% de reproceso y un 5% de excepciones: 6.000 × 1,15 + 300 = 7.200 créditos al mes, equivalentes a unos 240 al día. La bolsa alcanza, con un margen de 800 créditos.
• Escenario pico: 4.500 casos × 2 ejecuciones × 1 crédito = 9.000 créditos de consumo base. Si el reproceso sube al 20% y las excepciones se mantienen en el 5%: 9.000 × 1,25 + 300 = 11.550 créditos al mes, equivalentes a unos 385 al día. A ese ritmo, una bolsa de 8.000 créditos se agotaría aproximadamente el día 21, si el consumo fuera uniforme.

Un umbral inicial de alerta puede ser un consumo diario superior en un 20% al previsto para el escenario normal: 240 × 1,2 = 288 créditos, aproximadamente 290. Este umbral debe ajustarse a los patrones reales de actividad para no generar alertas innecesarias.

También hay que vigilar el consumo acumulado. Para cada día, compara los créditos consumidos desde el inicio del mes con el consumo acumulado previsto hasta esa fecha. Si el consumo real supera esa proyección, la alerta debe indicar cuánto se ha desviado y qué saldo queda. En el escenario pico, el consumo diario estimado de 385 créditos superaría el umbral normal desde el primer día.

Los adjuntos grandes, las instrucciones extensas, los historiales completos y los agentes que consultan herramientas varias veces pueden elevar el consumo aunque el número de casos permanezca estable. Por eso, conviene medir no solo el volumen de casos, sino también los créditos consumidos por caso y por etapa.

Finanzas necesita conocer el saldo y la proyección mensual; operaciones necesita detectar desviaciones a tiempo. Cada alerta debe tener un responsable y una acción asociada, como revisar los reprocesos, limitar temporalmente una operación costosa o activar una ruta de respaldo.

Una hoja inicial puede incluir volumen diario, ejecuciones por etapa, créditos por ejecución, excepciones, reintentos y saldo disponible. Después, contrasta las estimaciones con los eventos reales de la plataforma y recalibra las tasas para detectar desviaciones y mejorar la previsión.

[BANNER type="lead_banner_2" blockquote="\"Gracias a Bitrix24 nuestro trabajo será aún más eficiente.\"" user-picture-src='/upload/optimizer/converted/upload/iblock/d5a/062s36q6eo0ocal1x5tzptglv0o8mij0.png.webp?1742482421333' user-name="Director de Innovacion Tecnológica, Myriam Doria" user-description="Agregador de Contenidos Caloryfrio.com s.l." button-message="EMPEZAR GRATIS"]

Explicar qué ocurre cuando el saldo se agota mientras el flujo sigue recibiendo trabajo

Cuando se agotan los créditos, el resultado depende de las reglas del proveedor y del diseño del flujo. La ejecución puede detenerse, quedar en cola, generar cargos por exceso o continuar parcialmente si algunas etapas no necesitan IA.

No hay que asumir que la plataforma cambiará automáticamente a un modelo más barato: ese comportamiento debe estar previsto y configurado.

Comportamientos posibles al agotarse el saldo

En un flujo síncrono, como una respuesta en un portal, el usuario puede recibir un error inmediato o una respuesta incompleta. En uno asíncrono, como la clasificación nocturna de tickets, el problema puede pasar inadvertido hasta que se acumulan tareas pendientes. El comportamiento concreto depende de cómo gestione cada plataforma los errores y los límites de consumo.

También hay que distinguir el agotamiento del saldo de los límites de frecuencia. Una plataforma puede restringir el número de solicitudes por minuto u hora aunque todavía haya créditos disponibles.

CoPilot, el asistente de IA de Bitrix24, es un buen ejemplo: acepta hasta 600 solicitudes por hora para toda la cuenta, en todos los planes. Si un equipo lanza a la vez el análisis de todas las llamadas de una campaña, las nuevas solicitudes quedan en espera hasta que se liberan huecos dentro de esa hora, aunque no se haya agotado ningún saldo.

La ejecución parcial es especialmente difícil de detectar: el ticket puede haberse creado sin prioridad, el documento almacenado sin extracción o el correo enviado sin actualizar el CRM. Contar únicamente los casos recibidos oculta los fallos de las etapas posteriores.

Para evitar que los eventos entrantes se pierdan o queden sin seguimiento, define por adelantado:

• Qué hacer con los nuevos eventos: rechazarlos con un error controlado, guardarlos en una cola persistente o derivarlos a un proceso alternativo.
• Cómo registrar las ejecuciones incompletas: conservar el identificador del caso, la etapa alcanzada, el motivo del fallo y las acciones ya realizadas.
• Cuándo reintentar: establecer condiciones y límites para evitar bucles y cargos repetidos.
• Cómo recuperar el trabajo pendiente: definir quién autoriza la reanudación y cómo comprobar que no se duplican notificaciones, registros ni operaciones.
• Qué ruta alternativa activar: permitir, cuando sea seguro, una clasificación manual o una versión simplificada del flujo.

La prioridad es preservar los datos, hacer visible el trabajo pendiente y poder reanudarlo de forma controlada cuando vuelva a haber capacidad, aunque eso obligue a pausar temporalmente algunas funciones.

Diseñar el comportamiento de respaldo para que el proceso no se rompa a mitad de mes

Un flujo que se queda sin créditos necesita una ruta explícita: cola manual, reglas simples, pausa del nodo de IA o una versión reducida del proceso. La elección depende del costo de equivocarse. Para clasificar prospectos, puede bastar con conservar el registro y asignarlo a revisión; en una factura o una validación de identidad, una extracción incompleta debe detener el avance y solicitar aprobación humana.

La arquitectura de respaldo debería incluir:

• Detección: identificar el error de saldo agotado y distinguirlo de otros fallos técnicos.
• Marcado: registrar el caso como incompleto, con la etapa pendiente y las operaciones ya realizadas.
• Enrutamiento: enviarlo a una cola manual o a una ruta basada en reglas, con un responsable asignado.
• Aprobación: exigir revisión humana en decisiones sensibles.
• Reanudación: retomar los pasos pendientes sin duplicar registros, notificaciones ni otras acciones.

El enrutamiento no necesita IA. Con la automatización de tareas de Bitrix24, cuando un caso pasa a la etapa “Revisión manual”, una regla crea una tarea para la persona responsable, con su plazo. El flujo conserva el contexto necesario para que esa persona continúe sin reconstruir lo ocurrido.

Antes de reanudar una ejecución, comprueba si las acciones anteriores se completaron realmente. Por ejemplo, una llamada puede haber creado un registro en el CRM aunque el flujo no haya recibido la confirmación. En esos casos, utiliza un identificador único para comprobar el resultado antes de repetir la operación.

Las alertas deben llegar a operaciones y al responsable del flujo, no solo al administrador técnico. Prueba la ruta de respaldo con un caso controlado y verifica el estado en cada sistema, la información visible para el usuario, la identificación del caso, la ausencia de duplicados y quién autoriza la recuperación.

Poner límites y monitorización donde realmente importan

Observa por separado el consumo, el rendimiento del proceso y la calidad de la salida. Un menor gasto puede indicar eficiencia, pero también que las ejecuciones fallan o que los casos se detienen antes de llegar al paso de IA.

Por flujo, registra:

• Créditos consumidos por caso y porcentaje de bloqueos por saldo.
• Casos pendientes (backlog), antigüedad de los pendientes y tiempo de ciclo.
• Revisiones humanas, errores y reintentos por etapa.
• Calidad de la salida, medida mediante validaciones y correcciones posteriores.

Para que todos midan lo mismo, define las fórmulas, el periodo y la fuente de los datos desde el inicio:

• Créditos por caso completado = créditos consumidos por las ejecuciones del flujo durante el periodo ÷ casos que completaron el flujo durante ese mismo periodo. Incluye los créditos de reintentos y ramas adicionales. Registra aparte los casos incompletos y sus consumos para evitar que los fallos se interpreten como un ahorro.
• Porcentaje de bloqueos por saldo = casos únicos detenidos por saldo agotado durante el periodo ÷ casos únicos que llegaron a un paso de IA durante ese periodo × 100. Si el denominador incluye todos los casos recibidos, el indicador puede ocultar el problema cuando muchos casos no llegan a la etapa afectada.

El marco FinOps para IA de la FinOps Foundation aborda el uso de métricas unitarias para comprender el costo de las cargas de trabajo de IA. Este enfoque ayuda a relacionar el gasto con la actividad real, en lugar de observar únicamente el saldo consumido.

En Bitrix24, el análisis del embudo del CRM permite observar cuántos registros hay en cada etapa y detectar dónde se acumulan. Para confirmar que el bloqueo se debe a la falta de créditos, hay que contrastar ese patrón con los registros de ejecución y los eventos de consumo.

Aplica los límites donde se origina el riesgo: por equipo, flujo experimental o ruta crítica. Así, una automatización con instrucciones demasiado largas o demasiados reintentos no consume sin control la asignación destinada a otros procesos.

Combina alertas de consumo acumulado, velocidad de uso y errores. Un aumento de reintentos puede indicar un problema de integración o de calidad de los datos que no se resuelve comprando más créditos. Revisa estos indicadores después de modificar formularios, instrucciones (prompts), modelos, reglas o integraciones.

Qué condiciones hay que dejar por escrito antes de firmar con un proveedor

La documentación comercial debe responder preguntas operativas, no limitarse a indicar el precio de una bolsa de créditos. Solicita la definición exacta de la unidad de consumo: llamada, token, documento, acción del agente o ejecución completa.

Deja por escrito:

• Unidad de consumo: qué funciones descuentan créditos, cuánto consume cada una y cómo se contabilizan las ejecuciones parciales.
• Errores y reintentos: qué ocurre con las llamadas fallidas, incompletas, repetidas y los reintentos automáticos, tanto en créditos descontados como en cargos facturados.
• Límite de consumo: qué sucede al agotarse el saldo y si se detiene el flujo, se acumulan tareas, se factura el exceso o se activa una ruta alternativa.
• Control del gasto: si se puede desactivar el cobro por exceso y cómo se priorizan las tareas acumuladas.
• Recuperación: cómo se reanudan los casos pendientes después de renovar o recargar el saldo y cómo se evitan duplicados.
• Modo degradado: qué funciones, capacidad y nivel de calidad se mantienen cuando se utiliza una ruta alternativa.

Hay tres preguntas que conviene hacer de forma explícita:

• ¿Se cobran los reintentos automáticos iniciados por la propia plataforma, aunque el cliente no los haya solicitado?
• ¿Puede un ajuste de precio aplicarse retroactivamente al consumo realizado o a los créditos ya comprados? ¿Con cuánto aviso se notifican los cambios?
• ¿Cada cargo de la factura incluye un identificador que permita vincularlo con el caso y el evento correspondiente del flujo?

Pregunta por la continuidad de cada flujo, no solo por la disponibilidad general del servicio. La auditoría debe permitir conciliar la factura con los eventos reales mediante datos como el identificador del caso, la etapa, el modelo utilizado, los créditos descontados, el resultado, el error y los reintentos.

Para que esa conciliación sea viable, acuerda qué identificadores estarán disponibles en los registros del proveedor y en los del flujo, además de su formato y periodo de conservación. Si no existe un identificador común, define cómo relacionar ambos registros sin depender de una revisión manual caso por caso.

Incluye también un procedimiento de salida: cómo exportar los datos y los casos pendientes, cuánto tiempo estarán disponibles los registros de consumo, cómo se notifican los cambios de precio y qué opciones existen para migrar o completar el trabajo pendiente si termina el contrato.

FAQ operativa para equipos que ya están automatizando

¿Conviene reservar créditos solo para pasos de alto valor y mover el resto a automatización determinista?

En general, sí, cuando la tarea puede resolverse con reglas, validaciones o coincidencias exactas. Reserva la IA para interpretar texto libre, documentos variables o situaciones que dependen del contexto. Si las reglas se vuelven demasiado complejas de mantener, compara ese costo con el de las llamadas a IA. Antes de actualizar sistemas críticos, valida los resultados y define qué errores requieren revisión humana.

¿Cómo cambia la previsión si el mismo caso puede disparar varias ejecuciones por correcciones o reenvíos?

Calcula las ejecuciones por caso, registra qué eventos provocan cada reproceso y comprueba si se vuelve a enviar todo el contexto o solo el dato corregido. Incluye estas rutas en la estimación, aunque sean poco frecuentes, y establece un máximo de reintentos. Los casos que superen ese límite deben pasar a revisión para evitar bucles de consumo.

¿Qué SLA interno tiene sentido fijar si el proveedor pone en cola ejecuciones al agotarse el saldo?

Distingue entre el tiempo de recepción, el inicio del procesamiento y la resolución del caso. Define un tiempo máximo en cola, prioridades para casos críticos y una ruta manual cuando se supere ese plazo. Asigna a una persona responsable de revisar los pendientes y autorizar los reintentos. Si el proveedor no garantiza un tiempo de recuperación, el SLA interno debe contemplar esa incertidumbre y establecer qué hacer mientras se restablece el servicio.

Próximos pasos:

• Mapear el flujo e identificar qué etapas consumen créditos de IA.
• Estimar el consumo mensual en escenarios normal y pico, incluidos los reprocesos.
• Configurar alertas de consumo diario y acumulado, con un responsable y una acción definida.
• Probar la ruta de respaldo para cuando se agote el saldo y verificar cómo recuperar los casos pendientes.
• Acordar por escrito con el proveedor la unidad de consumo, los límites, los cargos por reintentos, los cambios de precio y la conciliación entre factura y eventos del flujo.