Límites de tasa para chatbots de IA: controlar costes y carga de forma justa

Un chatbot accesible públicamente en un sitio web puede desencadenar en pocos segundos más trabajo de cómputo que una página de contacto tradicional durante toda una visita. Un solo mensaje puede iniciar procesos de recuperación, reordenamiento (reranking), múltiples llamadas al modelo y comprobaciones adicionales. Por ello, sin límites claros, no solo basta un gran ataque de bots: también un cliente defectuoso, muchas pestañas abiertas simultáneamente o un bucle de reintento automático pueden disparar los tiempos de respuesta y los costes.

Los límites de tasa (rate limits) para chatbots de IA no deben entenderse como un bloqueo rígido. Los buenos límites distribuyen equitativamente los recursos escasos, protegen el presupuesto y mantienen un servicio residual comprensible para los usuarios legítimos. Esta guía práctica muestra qué volúmenes deben limitar los equipos web, cómo definir una identidad justa y qué respuesta debe ofrecer el chatbot ante una carga elevada.

Por qué no basta con un límite simple de peticiones por minuto

En las API convencionales, dos solicitudes suelen tener un coste similar. En un chatbot de IA, sin embargo, un saludo breve puede requerir solo unos pocos tokens, mientras que un análisis extenso de documentos, una recuperación amplia de información o múltiples pasos del modelo consumen muchísimos más. El informe actual OWASP GenAI LLM Top 10 2026 clasifica el consumo descontrolado de recursos como Unbounded Consumption. El núcleo del problema es la asimetría de costes: un atacante o cliente defectuoso puede desencadenar un procesamiento desproporcionadamente caro con muy poco esfuerzo propio.

Asimismo, el estándar OWASP API4:2023 menciona, junto a la tasa de interacción, otros límites como el tiempo de ejecución, la memoria, el tamaño de subida, las operaciones por petición y los gastos en servicios de terceros. Para los chatbots, esto implica que la directiva no solo debe contar peticiones, sino presupuestar todo el flujo de procesamiento.

Siete recursos que requieren presupuestos independientes

Un concepto sólido comienza con un mapa de recursos. Para cada dimensión se establece cuándo una solicitud se acepta, se acorta, se retrasa o se rechaza.

• Peticiones: cantidad por ráfaga (burst) corta y por intervalo de tiempo más extenso.
• Concurrencia: respuestas ejecutadas simultáneamente por usuario, sesión y cliente.
• Entrada: caracteres, archivos adjuntos y estimación de tokens de entrada antes de invocar un modelo.
• Salida: presupuesto máximo de respuesta y una interrupción adecuada en caso de bucles infinitos.
• Recuperación (Retrieval): número de variantes de búsqueda, resultados, candidatos de reordenamiento y documentos cargados.
• Cola de espera: tareas pendientes y tiempo máximo de espera antes de aplicar una alternativa clara.
• Costes: presupuesto diario o mensual por organización, junto a un freno de emergencia global.

Tratamiento diferenciado entre ráfagas y periodos prolongados

Estos límites están interconectados, pero no son intercambiables. Un presupuesto diario generoso no evita un pico de carga en un segundo determinado. De igual forma, un límite de peticiones no protege frente a una sola solicitud extremadamente costosa. Para el entorno de ejecución técnico, resulta valioso combinar esto con un presupuesto explícito de latencia, timeouts y reintentos controlados.

Identidad justa en lugar de bloqueos genéricos por IP

Por qué la dirección IP por sí sola es insuficiente

El estándar HTTP RFC 6585 evita deliberadamente especificar cómo un servidor debe identificar a un usuario o contar las peticiones. Esto es crucial porque una dirección IP no constituye un criterio de usuario fiable. En empresas, hoteles, redes móviles o entornos familiares, muchas personas pueden compartir la misma dirección pública. Por el contrario, un cliente automatizado puede cambiar fácilmente de IP.

Combinación de señales respetuosas con la privacidad

En áreas con autenticación, la organización, la cuenta y el ID de usuario representan las claves más sólidas. Para un chatbot público, se recomienda una combinación escalonada compuesta por una sesión de corta duración respetuosa con los datos, una señal de red general y el patrón de riesgo actual. No es necesario almacenar prompts sin procesar, huellas digitales permanentes del dispositivo ni registros detallados de IP. Cuando se utilicen datos personales de cuenta, las restricciones de un chatbot de IA autenticado en el portal de clientes deben planificarse de forma independiente.

Además, la directiva debe permitir reintentos legítimos. Un usuario puede reenviar un mensaje debido a una conexión inestable o requerir más interacciones si utiliza tecnologías de asistencia. Por lo tanto, rara vez resulta sospechosa una señal aislada, sino la combinación de una alta frecuencia, entradas extensas, múltiples sesiones paralelas y el agotamiento recurrente de rutas costosas.

Definir límites mediante métricas reales, no suposiciones

Un buen punto de partida surge de conversaciones reales y exitosas. El equipo mide durante varias semanas los tokens de entrada y salida, los resultados de recuperación, los tiempos de ejecución, la concurrencia y los costes por tarea completada. A continuación, se separan el uso normal, los picos y los valores atípicos. El límite debe situarse por encima de un pico legítimo razonable, pero por debajo de la zona donde un solo actor pueda poner en riesgo el servicio o el presupuesto.

Ejemplo: La mayoría de las interacciones requieren como máximo tres respuestas en un minuto y se mantienen muy por debajo del presupuesto de tokens. En ese caso, una ráfaga corta puede admitir más mensajes, mientras que una ventana de mayor duración limita el volumen total. Las rutas de análisis costosas reciben un cupo separado más reducido. Lo determinante no es una cifra arbitraria de un sistema ajeno, sino su alineación documentada con pruebas de carga, el modelo de costes y el comportamiento del usuario.

Los cambios deben implementarse primero en un modo de supervisión (Shadow Mode). El sistema registra qué sesiones legítimas habrían alcanzado un límite planificado, sin llegar a bloquearlas. De esta manera, los umbrales se calibran de forma gradual y se identifican bloqueos innecesarios.

Una cadena de protección multinivel para cada petición

1. Verificación en la entrada: El tamaño del payload, el tipo de archivo, la sesión y las repeticiones evidentes se evalúan antes de la recuperación y la llamada al modelo.
2. Estimación previa de costes: La longitud de entrada, la salida esperada, la amplitud de recuperación y la clase de modelo determinan un peso estimado de la solicitud.
3. Reserva atómica de presupuestos: La sesión, el usuario, la organización y el fondo global se verifican de forma conjunta. Las peticiones simultáneas no deben consumir múltiples veces el mismo saldo restante.
4. Limitación del tiempo de ejecución: Timeouts, límites en los pasos del modelo y una cola de espera acotada evitan bloqueos costosos.
5. Contabilización del consumo real: Al finalizar, el consumo real sustituye a la estimación. Las interrupciones y errores del proveedor permanecen visibles como métricas independientes.

Esta cadena se ejecuta en el servidor. Ocultar el botón de envío en el navegador es una mejora útil de experiencia de usuario, pero no constituye una barrera de seguridad. Lo mismo se aplica a las instrucciones en los prompts: no reemplazan al limitador técnico ni a la protección contra Prompt Injection en chatbots para sitios web.

429, Retry-After y el riesgo de una ola de reintentos

Cuando se agota el cupo de un usuario, la respuesta adecuada legible por máquina es el código HTTP 429 Too Many Requests. El estándar RFC 6585 recomienda incluir una explicación y permite usar la cabecera Retry-After. El cliente debe respetar este tiempo, evitar el reenvío inmediato y mostrar el estado de forma clara. Idealmente, se añade cierta variación aleatoria (jitter) entre clientes para evitar que se reconecten simultáneamente.

En situaciones de sobrecarga general temporal, el código HTTP 503 Service Unavailable puede ser más conveniente. El estándar RFC 9110 especifica que Retry-After puede enviarse como fecha HTTP o como tiempo de espera en segundos. Las acciones no idempotentes nunca deben reintentarse a ciegas: siempre debe verificarse previamente si una reserva o transferencia ya se ha completado.

En la interfaz del chat, la respuesta técnica requiere un texto comprensible para las personas: por qué no se puede procesar la solicitud en ese momento, cuándo es adecuado intentar de nuevo y qué alternativa existe. El mensaje debe ser ejecutable por tecnologías de asistencia. La guía del W3C sobre WCAG 2.2 Status Messages muestra cómo anunciar cambios de estado sin forzar un cambio de foco.

La degradación gradual mantiene un servicio residual útil

Un bloqueo total y estricto no siempre es la mejor solución. Bajo una alta carga, el chatbot puede ofrecer de forma opcional respuestas más breves, evaluar menos candidatos de búsqueda o eludir análisis no críticos en el tiempo. La transparencia es fundamental: el usuario debe percibir que se encuentra en un modo limitado. No obstante, las fuentes, las verificaciones de seguridad y la autorización no deben omitirse en ningún caso.

Para consultas urgentes, debe existir una opción sencilla de contacto o derivación a un agente. Si esa ruta también está saturada, el sistema debe presentar una alternativa fiable en lugar de una confirmación ficticia. Los criterios de degradación, desconexión y reinicio deben formar parte del plan de respuesta a incidentes y rollback.

Métricas clave para gestionar la protección

El número total de respuestas 429 ofrece poca información por sí solo. Un panel de control efectivo separa los datos por dimensión de límite y categoría de usuario: peticiones aceptadas y limitadas, ejecuciones en paralelo, tiempo en cola, tokens de entrada y salida, alcance de recuperación, coste por conversación exitosa y errores del proveedor. Además, se requiere una muestra de las sesiones bloqueadas para detectar falsos positivos.

Las alertas deben responder a anomalías: un incremento inusual del coste por minuto, un crecimiento acelerado de la cola de espera, un volumen elevado de entradas largas desde sesiones cambiantes o un alto porcentaje de reintentos inmediatos a pesar de la cabecera Retry-After. Por lo general, basta con utilizar contadores seudonimizados y metadatos técnicos; el contenido completo de las conversaciones no debe incluirse automáticamente en los registros de carga. El marco NIST AI RMF Core destaca la importancia de medir y probar los sistemas de IA antes de su despliegue y de forma periódica en producción.

Plan de pruebas antes de la activación en producción

• Las conversaciones individuales normales y las ráfagas legítimas breves no sufren alteraciones.
• Las entradas excesivamente largas se acotan antes de realizar llamadas costosas al modelo o a la recuperación de datos.
• Múltiples pestañas abiertas en paralelo comparten correctamente el mismo presupuesto de sesión o cuenta.
• Diferentes usuarios legítimos tras una misma IP pública no son bloqueados de forma indiscriminada.
• Las respuestas 429 y 503 incluyen información de espera coherente y comprensible.
• Los clientes respetan la cabecera Retry-After y no generan olas de reintentos.
• El modo limitado preserva los límites de seguridad, privacidad y fuentes.
• Un límite global de costes detiene las rutas de alto consumo sin afectar a la página de estado o a las vías de contacto.

Lista de verificación práctica para equipos web

1. Medir el flujo de recursos y el coste por conversación exitosa.
2. Establecer límites independientes para peticiones, tokens, concurrencia, recuperación, cola y presupuesto.
3. Priorizar identidades autenticadas y combinar señales anónimas minimizando el uso de datos.
4. Validar primero los umbrales en Shadow Mode frente al tráfico real.
5. Probar el comportamiento de 429, 503 y Retry-After tanto en la API como en la interfaz.
6. Documentar la degradación gradual, la derivación a agentes y el freno de emergencia global.
7. Evaluar periódicamente los bloqueos erróneos, los costes y la carga de forma conjunta.

Conclusión: Los límites de tasa adecuados protegen el servicio y al usuario

Establecer límites de tasa para un chatbot de IA es una tarea de arquitectura, no un simple ajuste en la CDN. Solo la combinación de presupuestos basados en volumen, tokens, concurrencia y costes previene el consumo descontrolado. Una identificación equitativa, una semántica clara de reintentos y un servicio residual transparente garantizan que la protección no perjudique la experiencia del usuario.

Para operar un chatbot en un sitio web de manera estable, se debe comenzar con un mapa de recursos medido y ajustar la directiva progresivamente. Evalúe en su implementación de ChatReact qué presupuestos se adaptan al tráfico de su sitio web y compruebe los límites antes de su activación definitiva.

Fuentes

• OWASP GenAI LLM Top 10 2026
• OWASP API4:2023 – Unrestricted Resource Consumption
• RFC 6585 – 429 Too Many Requests
• RFC 9110 – Retry-After
• W3C WCAG 2.2 – Status Messages
• NIST AI Risk Management Framework Core