Respuesta directa
En pocas palabras
Para prevenir consumo sin límites en un AI Sales Copilot, calcula antes de ejecutar el costo máximo del recorrido completo y aplica cuotas por organización, usuario, operación y periodo. Limita entrada, contexto, salida, fan-out, herramientas, reintentos, concurrencia, cola y gasto externo. Reserva capacidad para recorridos críticos, rechaza temprano el trabajo imposible y usa degradación segura; autoscaling y alertas no sustituyen límites aplicados por la aplicación.
El consumo sin límites es un riesgo de seguridad, no solo de costo
OWASP LLM10:2025 describe el consumo sin límites cuando una aplicación permite inferencias excesivas o sin control. El impacto puede aparecer como denegación de servicio, degradación para usuarios legítimos, gasto insostenible, uso no autorizado o recopilación sistemática de respuestas para replicar el comportamiento de un modelo. Una solicitud pequeña también puede disparar un trabajo grande si activa recuperación, herramientas, agentes, reintentos o generación extensa.
La defensa empieza en la aplicación que conoce identidad, tenant, plan, finalidad y recorrido. El proveedor del modelo puede limitar llamadas globales, pero no sabe si una organización agotó su presupuesto, si una operación merece prioridad o si un lote contiene cientos de subtareas. El objetivo no es impedir el uso intensivo legítimo: es asignar recursos de forma explícita, proporcional y observable antes de que un actor o un error consuma la capacidad compartida.
Dibuja el grafo completo de consumo
Inventaría cada recurso que una acción puede tocar: bytes de entrada, tokens, OCR, parsing, embeddings, búsqueda, reranking, memoria, caché, inferencia, herramientas, navegador, exportación, almacenamiento, red, correo y servicios pagados. Incluye procesos asíncronos, webhooks, trabajos programados y operaciones de recuperación. Para cada nodo registra unidad, proveedor, límite técnico, costo, timeout, concurrencia, cola, propietario y comportamiento al agotarse.
Sigue también la amplificación. Un botón puede dividirse en varias consultas, cada consulta recuperar documentos y cada resultado iniciar otra herramienta. Modela profundidad, anchura y número total de pasos. Un límite en el endpoint inicial no controla un bucle interno ni un fan-out después de aceptar el trabajo. Asigna un identificador al recorrido para sumar todo su consumo, aunque atraviese procesos y proveedores diferentes.
Calcula un presupuesto antes de admitir el trabajo
Antes de llamar al modelo, estima un límite superior razonable con entrada, contexto recuperado, salida máxima, número de candidatos, herramientas permitidas, profundidad, fan-out y reintentos. No necesitas predecir el costo exacto para rechazar una operación que ya excede la política. Reserva el presupuesto de forma atómica para evitar que varias solicitudes simultáneas gasten el mismo saldo aparente.
La admisión responde tres preguntas: ¿esta identidad puede ejecutar la operación?, ¿queda presupuesto para el recorrido completo? y ¿existe capacidad para terminarlo dentro del objetivo? Si la respuesta es negativa, rechaza antes de cargar archivos, generar embeddings o abrir conexiones pagadas. Devuelve una razón estable y una alternativa, como reducir el lote, usar un modo breve, programar el trabajo o solicitar una excepción con vencimiento.
| Criterio | Control verificable | Atajo insuficiente |
|---|---|---|
| Solicitud | Reserva costo máximo del recorrido | Cuenta una llamada HTTP |
| Agente | Limita pasos, fan-out y herramientas | Confía en que terminará solo |
| Lote | Cuenta elementos y trabajo agregado | Acepta el archivo por tamaño |
| Proveedor | Budget local y límite externo | Solo alerta al recibir la factura |
Aplica límites por dimensión y por alcance
Define máximos de bytes, caracteres, archivos, páginas, filas, objetos, tokens de entrada, contexto, salida y tiempo. Añade límites para top-k, resultados por página, operaciones por lote, profundidad de consulta y contenido comprimido o expandido. Valida antes de transformar: un archivo pequeño puede producir muchas páginas, celdas, imágenes u objetos al descomprimirse o procesarse.
Separa alcances. Una cuota global protege al proveedor, pero puede permitir que un solo tenant afecte a todos. Usa límites por organización, usuario, credencial, IP cuando aporte señal, endpoint, operación y ventana. No confíes únicamente en IP: redes compartidas castigan a personas legítimas y un atacante distribuido la elude. Combina identidad autenticada, finalidad, historial y costo observado sin convertir heurísticas en autorización.
Controla tokens, contexto y longitud de salida
Estima tokens con el tokenizer correspondiente y aplica máximos del lado del servidor. Limita el contexto recuperado por cantidad y por presupuesto, no solo por número de documentos. Deduplica fragmentos, elimina versiones vencidas y evita copiar historiales completos cuando un resumen autorizado basta. Si la entrada supera el contrato, no la trunques de forma silenciosa cuando eso pueda cambiar una condición comercial; informa qué quedó fuera.
Fija una salida máxima por tarea. Una clasificación necesita menos tokens que una propuesta. Usa formatos estructurados y stop conditions, pero no dependas de que el modelo obedezca una instrucción de brevedad. Interrumpe streaming al alcanzar el límite, cancela el trabajo aguas abajo y registra resultado parcial. No reenvíes automáticamente la misma petición para completar una respuesta cortada: un reintento puede duplicar el consumo y el efecto.
Acota agentes, herramientas y trabajo recursivo
Un agente necesita un presupuesto compartido para pasos, profundidad, tiempo, tokens, llamadas y costo externo. Cada herramienta declara su costo máximo, timeout, efecto, idempotencia y número de invocaciones permitido. La aplicación descuenta antes de ejecutar y detiene el plan cuando no puede completar el siguiente paso dentro del saldo. El modelo no puede elevar su propio límite ni crear otro agente para eludirlo.
Bloquea bucles repetidos mediante IDs de operación, límites de profundidad, detección de estados equivalentes y un máximo total de acciones. Restringe destinos de red y servicios disponibles. Las acciones materiales conservan autorización y aprobación separadas: tener presupuesto no concede permiso para enviar un correo, exportar datos o cambiar una oportunidad. El kill switch debe poder detener herramientas sin desconectar las funciones de lectura necesarias para investigar.
Gobierna concurrencia, colas y backpressure
Limita trabajo simultáneo por tenant, operación y dependencia. Una cola no crea capacidad; solo aplaza el consumo. Define longitud máxima, tiempo de espera, prioridad, expiración y política de descarte. No mantengas indefinidamente solicitudes que ya perdieron vigencia ni dejes que un lote de baja prioridad bloquee una tarea interactiva. Separa pools cuando un recorrido crítico no deba competir con generación masiva.
Propaga backpressure hacia el origen. Cuando modelo, base, proveedor o worker está saturado, reduce admisión en lugar de acumular conexiones y reintentos. Devuelve respuestas coherentes con `Retry-After` cuando corresponda y añade jitter al reintento del cliente. Un sistema que sigue aceptando trabajo porque autoscaling podría llegar después puede multiplicar costo y latencia antes de que la nueva capacidad esté disponible.
Haz que timeouts, cancelación y reintentos liberen recursos
Define un deadline de extremo a extremo y reparte presupuestos menores entre dependencias. Un timeout del navegador no significa que el modelo, la herramienta o el job se detuvieron. Propaga cancelación, cierra streams, libera locks y evita persistir un artefacto huérfano. Registra si el proveedor aceptó cancelar o si el costo continuó después de perder la respuesta.
Los reintentos necesitan máximo, backoff exponencial, jitter, clasificación de errores e idempotency key. No repitas errores permanentes, validaciones rechazadas ni operaciones cuyo estado es desconocido. Un circuit breaker debe cortar una dependencia degradada y probar recuperación con pocas solicitudes. Presupuesta todos los intentos desde el inicio; de otro modo, una falla de proveedor puede transformarse en una tormenta generada por tus propios clientes y workers.
Contén Denial-of-Wallet y gastos de terceros
Configura límites duros cuando el proveedor los ofrezca y alertas antes de alcanzarlos. Mantén también un ledger interno casi en tiempo real por tenant, operación, modelo y proveedor; la factura puede llegar demasiado tarde. Usa umbrales de observación, reducción, aprobación y bloqueo. Separa presupuesto de producción, pruebas y desarrollo para que una carga experimental no agote el servicio público.
Incluye costos indirectos: OCR, búsqueda, correo, SMS, almacenamiento, transferencia, observabilidad y herramientas externas. Valida destinatarios, lotes y frecuencia antes de una llamada pagada. Una clave comprometida debe poder revocarse y el tenant afectado aislarse sin detener a todos. Las excepciones requieren alcance, máximo, aprobador y caducidad; un aumento temporal no debe convertirse en la configuración permanente.
Detecta extracción y replicación funcional del modelo
OWASP incluye la extracción mediante API y la replicación funcional entre los impactos del consumo sin límites. Limita volumen y diversidad de consultas según el caso, restringe logits y logprobs cuando no sean necesarios y observa patrones sistemáticos: barridos, alta cobertura de clases, variaciones mínimas, enumeración y descargas sostenidas. El rate limit por minuto puede no detectar una recolección lenta durante semanas.
Relaciona señales entre credenciales, organizaciones y dispositivos sin asumir que toda automatización es maliciosa. Protege también prompts, herramientas y datasets mediante controles específicos; el límite de consumo no reemplaza autorización ni confidencialidad. Si el servicio utiliza un modelo de un tercero, no afirmes propiedad sobre sus pesos. Documenta qué activo propio proteges: configuración, evaluación, workflow, datos o comportamiento compuesto.
Degrada con prioridad y aislamiento, no de forma indiscriminada
Diseña modos degradados antes del incidente: respuesta más breve, menor top-k, modelo alternativo evaluado, procesamiento asíncrono, pausa de trabajo no esencial o captura manual. Conserva controles de seguridad y exactitud. No reduzcas citas, autorización o validación de precios para ahorrar recursos. Explica el estado al usuario y evita mostrar una respuesta parcial como si estuviera completa.
Define prioridades por recorrido y consecuencia, no por quién genera más tráfico. Reserva capacidad para autenticación, consulta de información existente, revisión y recuperación. Mantén aislamiento de bulkheads entre tenants o funciones críticas. Prueba que el límite no permita a un atacante bloquear deliberadamente a otra persona mediante su identidad y que la recuperación no libere toda la cola al mismo tiempo.
Prueba costo, saturación y abuso antes de producción
Construye casos para entrada máxima, salida máxima, contexto extenso, archivos comprimidos, lotes, consultas profundas, fan-out, herramientas lentas, proveedor caído, respuestas parciales y cancelación. Añade tráfico sostenido, ráfagas, tenants ruidosos y extracción lenta. Comprueba límites en cada salto, no solo en el gateway. Usa cuentas, modelos y destinos aislados para no generar efectos reales durante la prueba.
Mide admisión, trabajo rechazado, tokens reservados y usados, costo, latencia, cola, concurrencia, reintentos, cancelación efectiva, errores, degradación y recuperación. Verifica equidad por tenant y capacidad reservada. Una prueba de carga que solo informa solicitudes por segundo no demuestra resistencia a Denial-of-Wallet ni a amplificación interna. Conserva cada caso como regresión cuando cambien modelo, tokenizer, herramienta, proveedor o arquitectura.
Monitorea consumo accionable y prepara contención
Observa por recorrido, tenant, actor, modelo y dependencia: solicitudes, bytes, tokens, pasos, herramientas, costo estimado, concurrencia, cola, timeouts, reintentos y rechazos. Añade razones de admisión y degradación sin copiar prompts o datos sensibles. Alerta por tasa de cambio y concentración, no solo por total mensual. Un aumento puede ser crecimiento legítimo, abuso, loop, credencial filtrada o cambio de precio; la respuesta depende de la causa.
El runbook debe permitir reducir cuotas, bloquear una operación, revocar credenciales, drenar o descartar colas, desactivar herramientas, cambiar a modo degradado y aislar un tenant. Conserva trazas del recorrido y estado de proveedores. Después de contener, concilia costo, identifica trabajo derivado, corrige el límite o loop y repite la prueba. Reabre gradualmente con canary; no borres la evidencia al limpiar la cola.
Mantén estas fronteras al aplicar la guía a Cerravi
OWASP LLM10 aporta escenarios de DoS, Denial-of-Wallet, consultas costosas y extracción. OWASP API4 amplía límites de memoria, tiempo, tamaño, lotes y proveedores pagados. CWE-770 describe la debilidad de asignar recursos sin restricciones. NIST AI RMF organiza gobierno, medición y respuesta. Ninguna referencia certifica una implementación: la evidencia está en políticas aplicadas, pruebas y telemetría observada.
En Cerravi, Copilot organiza contexto y propone borradores para revisión humana; no envía mensajes ni cambia etapas automáticamente en los recorridos públicos. Las propuestas usan productos y precios conocidos. Si falta un importe, se marca para confirmación y no se inventa. Las monedas permanecen separadas salvo conversión aprobada. Buyer Room aporta señales sin probar identidad, aceptación, firma, pago ni intención. Forecast usa reglas transparentes del CRM y no garantiza cierres. La guía no afirma que Cerravi mida facturas de proveedores, ejecute chargeback o garantice ahorro.
Preguntas frecuentes
Dudas comunes sobre este proceso
¿Cuál es la diferencia entre rate limiting y una cuota de consumo de IA?
Rate limiting controla frecuencia en una ventana. Una cuota de consumo también limita trabajo acumulado: tokens, salida, herramientas, pasos, concurrencia, cola y costo. Se necesitan ambos porque pocas solicitudes pueden ser muy costosas.
¿Cómo evitar Denial-of-Wallet en una aplicación con LLM?
Reserva un presupuesto máximo antes de ejecutar, aplica límites por tenant y operación, configura topes del proveedor, controla reintentos y fan-out, y bloquea o degrada antes de agotar el saldo. Las alertas por sí solas llegan después del consumo.
¿Qué límites necesita un agente de IA?
Necesita máximos compartidos para pasos, profundidad, fan-out, tiempo, tokens, costo, herramientas y reintentos. Cada herramienta conserva autorización y timeout propios, y el agente no puede aumentar su presupuesto ni delegar para eludirlo.
¿Autoscaling resuelve el consumo sin límites?
No. Puede añadir capacidad, pero también aumentar rápidamente el gasto y no corrige loops, lotes enormes, extracción o uso no autorizado. Debe operar detrás de admisión, cuotas, concurrencia, backpressure y presupuesto.
¿Cómo degradar un AI Sales Copilot sin comprometer seguridad?
Reduce funciones no esenciales, longitud, top-k o prioridad, o programa el trabajo. Mantén autorización, aislamiento, validación de precios, evidencia y revisión humana. Comunica cualquier resultado parcial y conserva una alternativa manual.