Respuesta directa
En pocas palabras
Para planear capacidad de un AI Sales Copilot, mide la demanda por recorrido y por unidad de costo, identifica el primer recurso que se satura y define un margen operativo ligado a tus SLO. Protege el sistema con cuotas, prioridades, colas acotadas, backpressure y modos degradados. Prueba picos y fallas de dependencias, registra decisiones de escalamiento y revisa límites cuando cambian usuarios, modelos o integraciones.
La capacidad se define desde el recorrido comercial, no desde una gráfica de CPU
Planear capacidad significa decidir qué volumen y qué mezcla de trabajo puede atender el copiloto dentro de sus objetivos de tiempo, calidad, seguridad y costo. El punto de partida no es una máquina: es el recorrido que una persona necesita completar. Preparar una reunión, consultar una cuenta, generar un borrador, validar precios, exportar una propuesta y abrir una Buyer Room consumen recursos distintos y toleran esperas diferentes.
Describe para cada recorrido su población, horario, frecuencia, concurrencia, tamaño de entrada, dependencias, tiempo útil, alternativa manual y consecuencia de esperar. Separa lo interactivo de lo programado y lo obligatorio de lo conveniente. Una plataforma puede mostrar disponibilidad mientras sus colas convierten una tarea de minutos en una respuesta que ya no sirve para la conversación comercial.
Convierte la demanda en unidades que expliquen el costo real
Las solicitudes por minuto rara vez bastan. Registra usuarios concurrentes, operaciones por tipo, documentos, filas recuperadas, tamaño de archivos, tokens de entrada y salida, llamadas a herramientas, escrituras, conexiones, duración y reintentos. Una petición corta de lectura no compite de la misma forma que una propuesta con catálogo amplio, recuperación de contexto y exportación.
Conserva identidad de organización, versión, modelo, recorrido y canal sin incluir contenido comercial sensible. Estima el costo al admitir el trabajo y concílialo con el consumo observado cuando termina. Para modelos generativos, la salida completa puede conocerse después de aceptar la petición; utiliza límites de entrada y salida, estimaciones conservadoras y métricas reales para recalibrar, en vez de presentar una precisión inexistente.
| Criterio | Qué observar | Por qué importa |
|---|---|---|
| Experiencia | Concurrencia, espera y recorrido completado | Muestra si el resultado aún llega a tiempo |
| Aplicación | Operaciones, colas, workers y reintentos | Explica acumulación y amplificación |
| IA | Tokens, modelo, herramientas y duración | Relaciona cuota, latencia y costo |
| Datos | Consultas, conexiones, filas y escrituras | Descubre contención e integridad en riesgo |
Sigue el flujo completo hasta encontrar el primer límite
Dibuja el camino desde navegador, API o tarea programada hasta identidad, CRM, catálogo, recuperación, modelo, herramientas, almacenamiento, exportación, correo y telemetría. Anota límites publicados, compartidos y medidos. Una cuota del proveedor puede estar distribuida por región o modelo; una base puede aceptar conexiones mientras una consulta específica bloquea las demás; una exportación puede llenar almacenamiento sin afectar de inmediato la latencia de la API.
Busca fan-out, recursos globales y vecinos ruidosos. Una sola acción puede generar varias búsquedas, llamadas o reintentos y multiplicar la carga aguas abajo. Define el radio de impacto de cada límite: usuario, organización, operación, cola, modelo, proveedor o servicio completo. Proteger únicamente la entrada puede trasladar la sobrecarga al CRM, a la base o a un tercero compartido.
Modela base, pico, crecimiento y mezcla; no solo el promedio
Construye una línea base con periodos comparables y separa horas laborales, cierre de mes, campañas, carga de catálogos, importaciones, nuevos equipos y cambios de modelo. El promedio diario oculta una ráfaga de veinte minutos. Registra percentiles, simultaneidad, duración y composición: el mismo número de usuarios puede consumir mucho más si pasan de consultas breves a documentos complejos.
Para una función nueva, usa supuestos explícitos y un rango. Multiplica población elegible por adopción esperada, frecuencia, concurrencia y costo por operación; después prueba escenarios normal, alto y extremo. Señala qué dato falta y cuándo se reemplazará el supuesto con observación. Un forecast de capacidad orienta una decisión, no garantiza demanda ni rendimiento futuros.
Define una envolvente operativa y margen para absorber variación
La envolvente reúne el volumen, mezcla, latencia, calidad, error, costo y estado de dependencias bajo los cuales el recorrido cumple su objetivo. Establece un punto de advertencia, uno para limitar trabajo y otro para detener una operación. El recurso decisivo puede ser cuota de tokens, conexiones, memoria, cola, almacenamiento, presupuesto o capacidad humana de revisión.
Reserva margen para ráfagas, escalamiento, fallas parciales y medición imperfecta. El porcentaje adecuado depende de la velocidad con que crece la demanda, el tiempo para añadir capacidad, la criticidad y la alternativa disponible; no existe un margen universal. Documenta quién puede modificarlo, con qué evidencia y cuánto tiempo puede permanecer una excepción.
Asigna cuotas y presupuestos sin mezclar organizaciones ni trabajos
Define límites por identidad de organización, recorrido, operación, modelo y clase de trabajo. Distingue un límite de usuario, que evita que una cuenta consuma lo de las demás, y un límite de servicio, que protege el conjunto. Mantén separadas las cargas interactivas, por lotes y administrativas para que una importación no retrase una consulta que acompaña una llamada con cliente.
Las cuotas deben respetar aislamiento, contratos y propósito. No prestes capacidad entre organizaciones si esa decisión puede exponer datos, alterar prioridad acordada o impedir trazabilidad. Si permites ráfagas, define duración, deuda, recuperación y máximo. Un límite debe producir una respuesta visible y accionable; rechazar en silencio provoca reintentos, duplicados y tickets difíciles de investigar.
Las colas necesitan límite, prioridad, vencimiento y política de descarte
Una cola absorbe diferencias temporales entre llegada y procesamiento, pero no crea capacidad. Mide profundidad, antigüedad del elemento más viejo, tasa de entrada, tasa de salida, tiempo estimado y trabajo vencido. Define un máximo; una cola sin límite convierte una sobrecarga breve en horas de resultados atrasados y puede consumir memoria o almacenamiento hasta causar otra falla.
Prioriza por utilidad y fecha límite, no por quién reintenta más. Conserva orden cuando sea requisito y utiliza idempotencia para que repetir no duplique mensajes, actividades o documentos. Decide qué trabajo puede expirar, cancelarse, resumirse o volver a solicitarse. Si una propuesta ya no llegará antes de la reunión, procesarla después puede gastar capacidad sin producir valor.
Backpressure y throttling deben frenar la amplificación antes del colapso
Backpressure comunica al origen que el sistema no puede aceptar más trabajo al ritmo actual. Throttling aplica límites de tasa, concurrencia, volumen o costo. Colócalos en entrada, comunicaciones internas y salidas hacia dependencias. Incluye fan-out y endpoints privados; de otro modo una ruta alternativa puede saltarse la protección y saturar el componente compartido.
Devuelve una señal consistente con espera sugerida, estado y alternativa cuando corresponda. Los clientes deben usar backoff, jitter, máximo de intentos y una condición para dejar de reintentar. Un retry inmediato multiplica la demanda justo cuando queda menos capacidad. Prueba la cooperación de extremo a extremo: un 429 correcto no ayuda si otra capa lo convierte en error genérico y reintenta sin control.
Prepara modos degradados que conserven lo esencial
Elige por adelantado qué puede simplificarse cuando la capacidad se acerca al límite: reducir contexto no esencial, posponer análisis por lotes, limitar exportaciones, acotar resultados, desactivar enriquecimientos secundarios o pasar a lectura y borradores. Conserva identidad, autorización, aislamiento, fuente de precios y revisión humana. Un modo degradado no puede relajar precisamente el control que protege al comprador o a la empresa.
Cada nivel indica señal de entrada, funciones disponibles, mensaje al usuario, duración, dueño, monitoreo, salida y conciliación pendiente. La alternativa manual necesita datos, instrucciones y capacidad humana real. En Cerravi, un precio sin fuente se bloquea; la presión de tiempo o cómputo no autoriza inventarlo. Las monedas permanecen separadas y las sugerencias siguen requiriendo revisión.
Escala con señales que representen el cuello de botella
El escalamiento puede ser programado, automático o manual; vertical, horizontal o por unidad completa. Elige la señal que describe la restricción: concurrencia, cola, latencia, cuota, conexiones o una métrica combinada. CPU baja no demuestra capacidad cuando el sistema espera una API externa, una base o una cuota regional.
Registra tiempo de provisión, calentamiento, drenaje y reducción. Añadir instancias tarde puede no resolver una ráfaga; en ese intervalo necesitas admisión y degradación. Define mínimo y máximo para evitar inestabilidad y costo sin control. Escalar hacia abajo también requiere cuidado: drena trabajo, preserva estado y confirma que la demanda ya no depende de la capacidad retirada.
Prueba carga, picos y saturación en un entorno autorizado
Crea una mezcla representativa con datos sintéticos: lectura de cuentas, recuperación, generación, herramientas, exportación y tareas de fondo. Ejecuta calentamiento, carga sostenida, ráfaga, escalamiento y recuperación. Después introduce una dependencia lenta, cuota reducida, reintentos y un vecino ruidoso. Observa el recorrido, no solo throughput: latencia, calidad, errores, colas, costo y datos pendientes.
Define límites de seguridad, ventana, responsables, condición de alto y rollback antes de probar. No uses producción ni datos de clientes sin autorización específica. Una prueba no demuestra capacidad ilimitada: conserva versión, configuración, modelo, conjunto de datos, distribución de solicitudes y resultado para saber qué cambió cuando repitas.
Monitorea saturación junto con experiencia y trabajo pendiente
Combina indicadores adelantados y tardíos. Los primeros incluyen utilización de cuota, concurrencia, conexiones, memoria, profundidad y edad de cola. Los segundos muestran latencia, error, cancelación, tiempo de recorrido, calidad, tareas vencidas y usuarios que abandonan. Segmenta por organización, versión, operación y dependencia sin publicar contenido sensible.
Alerta cuando todavía existe una acción útil: añadir capacidad, limitar lote, reducir fan-out, activar modo degradado o escalar a un proveedor. Relaciona la señal con SLO, runbook y guardia. Si la telemetría llega tarde o pierde cardinalidad, declara la incertidumbre; cero errores durante una caída del recolector no significa cero impacto.
Cada cambio relevante vuelve a abrir la hipótesis de capacidad
Un modelo, prompt, herramienta, índice, catálogo, integración, región o límite de salida puede cambiar tiempo y costo aun cuando la interfaz permanezca igual. Incluye en el control de cambios una estimación, prueba comparable, impacto por recorrido, cuota, costo, plan de despliegue limitado, señales, umbral de parada y rollback. No mezcles resultados de versiones sin etiquetarlos.
Usa canary u olas cuando el cambio permita aislar población y efecto. Expande solo si la experiencia, la calidad, el costo y las colas permanecen dentro de la envolvente. Un despliegue técnicamente exitoso no cierra la revisión: observa el periodo de uso real y conserva suficiente capacidad para revertir o mantener ambas versiones durante la transición.
Revisa capacidad como una decisión compartida de producto, operación y negocio
Mantén un registro de supuestos, demanda, cuellos de botella, límites, pruebas, margen, excepciones, costos y fecha de revisión. Producto aporta roadmap y adopción; negocio, periodos críticos y alternativa; tecnología, medición y escalamiento; finanzas, presupuesto; seguridad y datos, límites que no deben degradarse. Nombra una autoridad para priorizar cuando no puede servirse todo.
Revisa por calendario y por evento: crecimiento, campaña, cierre de periodo, nuevo modelo, proveedor, cambio de precios, incidente, error budget acelerado o cola persistente. NIST AI RMF contempla los recursos requeridos y las alternativas no basadas en IA al gestionar riesgos. La referencia es voluntaria: cada organización debe adaptar capacidad, responsabilidades y obligaciones a su contexto técnico, contractual y local.
Preguntas frecuentes
Dudas comunes sobre este proceso
¿Cómo se calcula la capacidad de un AI Sales Copilot?
Se modela por recorrido: población, adopción, frecuencia, concurrencia y costo por operación. Después se identifica el primer límite entre aplicación, modelo, datos y dependencias, y se valida con pruebas que reproduzcan mezcla, picos y recuperación. El resultado es una envolvente con supuestos y margen, no una cifra permanente.
¿Cuál es la diferencia entre una cola, rate limit y throttling?
La cola retiene trabajo para procesarlo después; el rate limit restringe una tasa; throttling es el control más amplio de admisión por tasa, concurrencia, volumen, costo o estado. Una cola no sustituye capacidad y necesita máximo, prioridad y vencimiento. Los controles deben comunicar backpressure para evitar reintentos desordenados.
¿Qué debe priorizarse durante una sobrecarga?
Los recorridos con mayor consecuencia y menor alternativa, dentro de los compromisos y permisos aplicables. En un copiloto comercial suele protegerse identidad, aislamiento, fuentes autorizadas, revisión y tareas interactivas antes que enriquecimientos o lotes. La prioridad se define antes del pico y no debe depender de quién reintenta más.
¿Autoscaling evita por sí solo la sobrecarga?
No. Añadir capacidad toma tiempo y puede no resolver cuotas, bases, proveedores o fan-out. Además puede aumentar el costo o amplificar llamadas aguas abajo. Combínalo con límites de admisión, backpressure, colas acotadas, modos degradados, máximos de escala, monitoreo y una ruta operativa para investigar.
¿Cómo probar sobrecarga sin afectar clientes?
Usa un entorno aislado, datos sintéticos y una mezcla representativa. Define límites, condición de alto y responsables; prueba carga sostenida, ráfagas, dependencia lenta, cuota reducida y recuperación. Conserva versión, configuración y resultados. Una prueba en producción exige una autorización y controles propios, no se infiere de esta guía.