De 10 usuarios de negocio a 1,500 vendedores: el viaje arquitectónico de un sistema de IA que crece con la empresa

El problema de negocio (contado por quien lo vive)

“Llevo 15 años en ventas. Mi trabajo es conocer al cliente, entender qué necesita, y convencerlo de que somos la solución adecuada. Pero cada nuevo lead significa horas de investigación, redacción de correos, y seguimiento. No es que no quiera hacerlo — es que cada hora que paso redactando es una hora que no paso en la calle, conociendo a otro cliente.”

— Carlos, Director de Ventas, empresa de consultoría tecnológica

Carlos no pidió un sistema de IA. Carlos pidió más tiempo para vender. Su equipo de 10 vendedores estaba desbordado: cada nuevo lead requería investigar la empresa, entender su industria, encontrar el ángulo correcto, y redactar un correo personalizado que no sonara a plantilla. El proceso funcionaba, pero no escalaba. Y la empresa acababa de cerrar una ronda de financiación que iba a triplicar el equipo comercial en 18 meses.

El reto era claro: automatizar la investigación y la redacción inicial sin perder el toque humano que cerraba los tratos. Pero, como veremos, la solución no era un único sistema — era una arquitectura que evolucionara con el negocio.

El principio central que guía este caso

Antes de entrar en los detalles técnicos, vale la pena recordar una lección que ha aparecido una y otra vez en este compendio: la arquitectura correcta es una función del volumen y del patrón de uso real — no de una plantilla genérica de “cómo se hace un sistema de IA”.

Lo que es sobre-ingeniería con 10 usuarios (gateway de IA, dos modelos separados, guardrails automáticos, autohospedaje) se vuelve necesario con 1,500. Y lo que es suficiente con 10 usuarios (un solo modelo, revisión manual, sin caché de prompts) se convierte en un cuello de botella que puede tumbar el sistema a escala.

Este caso es un ejercicio de arquitectura evolutiva: no diseñamos para el futuro, diseñamos para el presente, con una hoja de ruta clara hacia el siguiente escalón. Cada etapa del viaje tiene su propia arquitectura óptima — y la transición entre etapas es una decisión consciente, no una urgencia.

Etapa 1: Diez usuarios de negocio (el comienzo)

“Necesito que mis 10 vendedores puedan evaluar leads y enviar correos personalizados. Rápido. No tenemos tiempo para construir infraestructura.”

— Ana, Head de Producto, 3 semanas antes del lanzamiento

Diagnóstico antes de diseñar

Dimensión	Análisis	Implicación arquitectónica
Concurrencia	10 usuarios internos, probablemente no todos escribiendo al mismo tiempo	No es un problema de throughput — es de latencia individual, porque cada persona espera en vivo su respuesta
Naturaleza de la tarea	Dos cosas mezcladas: evaluar clientes (análisis/clasificación) y generar correos (texto con tono específico)	Necesitamos dos capacidades distintas, pero podemos empezar con un modelo que haga ambas
Sensibilidad de datos	“Evaluar clientes nuevos” implica datos personales o comerciales sensibles	La privacidad no es negociable — si usamos una API externa, necesitamos contratos de confidencialidad
Consecuencia del error	Un correo mal redactado tiene impacto reputacional directo	Esto pide una capa de revisión humana, no automatización ciega

La decisión más importante: no autohospedar nada

Con solo 10 usuarios, construir infraestructura propia de inferencia (vLLM, GPUs, cuantización, batching continuo) es matar una mosca a cañonazos. Todo lo que vimos de optimización de inferencia en la Parte III importa cuando eres responsable de servir miles de solicitudes concurrentes de forma eficiente. Con 10 usuarios, un proveedor de API alojada ya resolvió ese problema a una escala que nunca se alcanzaría aquí.

El cálculo de costo era contundente:

API alojada: ~$0.02 por solicitud (evaluación + correo). 10 usuarios × 20 solicitudes/día × 22 días = 4,400 solicitudes/mes → ~$88/mes.
Autohospedado (una GPU): $3,000 en hardware + $200/mes en electricidad + mantenimiento → más de $5,000 en el primer año.

Conclusión: pagar por token era radicalmente más barato que mantener un servidor GPU corriendo 24/7 para este volumen.

La arquitectura inicial

Qué resuelve cada capa:

1. App interna — el principio de la menor fricción: no construimos una app nueva. Construimos un plugin dentro del CRM que los vendedores ya usaban. Menos fricción (no aprenden una interfaz nueva), más adopción (si está donde ya trabajan, lo usarán), y contexto integrado (el plugin extrae automáticamente los datos del lead del CRM). La lección: la mejor interfaz es la que no parece una interfaz nueva.

2. Capa de orquestación — el cerebro del sistema: aquí se aplica todo el prompt engineering estructurado de la Parte II — rol del sistema, restricciones duras, ejemplos de la empresa, formato de salida, y sanitización de datos.

El prompt de sistema (simplificado):

Eres un asistente comercial especializado en consultoría tecnológica.
Tu misión: ayudar al vendedor a evaluar leads y redactar correos personalizados.

REGLAS ESTRICTAS (no puedes violarlas):
1. No inventes información sobre el cliente. Usa solo los datos disponibles.
2. No prometas descuentos, funcionalidades, o plazos que no estén en el catálogo.
3. No uses lenguaje sexista, discriminatorio, o inapropiado.
4. No copies plantillas al pie de la letra — personaliza cada correo.

EJEMPLOS DE CORREOS GOLD STANDARD:
[3 ejemplos de correos exitosos de la empresa, anonimizados]

FORMATO DE SALIDA:
EVALUACIÓN: [2-3 párrafos sobre el cliente y su industria]
CORREO: [texto completo del correo, listo para enviar]

Contexto del cliente:
{datos_del_crm}

Instrucción del vendedor:
{input_del_vendedor}

3. Datos del cliente — RAG + MCP, la distinción viva: conocimiento general (RAG) — el playbook de ventas, casos de éxito por industria, catálogo de producto, vectorizado una vez y consultado por similitud semántica (Capítulo 5 de Parte II). Si un lead es de la industria farmacéutica, el sistema recupera casos de éxito en farmacia, no en retail. Datos en vivo (MCP) — consultas al CRM sobre el lead específico (¿ya hay una oportunidad abierta? ¿cuál fue el resultado de la última llamada?), consultadas en tiempo real vía MCP (Capítulo 5c de Parte II), exactamente como el saldo de vacaciones del asistente de RR.HH.

4. Modelo de IA — un solo modelo para ambas tareas: con 10 usuarios, no hay necesidad de separar modelos. Un modelo capaz puede hacer tanto la evaluación como la redacción en la misma llamada.

5. Revisión humana — la línea roja: un correo saliendo a un cliente real no debería auto-enviarse sin confirmación humana — la misma lógica del agente de vacaciones de Parte II: si algo sale mal, el humano es responsable, no el modelo. El flujo: el modelo genera el correo → el sistema lo muestra al vendedor en el CRM → el vendedor lee, edita si hace falta, y hace clic en “Enviar” → el sistema registra el envío y actualiza el CRM. Si el vendedor no revisa, el correo simplemente no se envía — no hay auto-aprobación.

¿Qué patrón de arquitectura agéntica es esto?

Con el vocabulario del Capítulo 6b de Parte II, esto es el patrón secuencial: evaluar al cliente primero, usar ese resultado para informar el tono y contenido del correo, en un orden fijo que no cambia de un cliente a otro. Como todo patrón secuencial, la orquestación es código, no una decisión de un LLM — ningún modelo necesita “razonar” sobre si evaluar antes o después de redactar, ese orden ya viene decidido desde el diseño.

Esto marca un límite claro de cuándo este diseño dejaría de ser suficiente: si en el futuro un vendedor pudiera escribirle al sistema mensajes abiertos y variados (“¿qué tal le fue a Juan con la propuesta?”, “arma un caso de éxito para este sector”) en vez de un flujo fijo, ahí sí haría falta un coordinador con un LLM decidiendo dinámicamente a qué sub-flujo enrutar cada mensaje. Mientras la tarea siga siendo la fija de “evaluar, luego redactar”, el secuencial es la elección correcta.

Los primeros 30 días: lo que aprendieron

Aprendizaje	Lo que hicieron	Impacto
Los prompts necesitan iteración	La primera versión producía correos demasiado largos y formales	Añadieron ejemplos más diversos y ajustaron el tono
La revisión humana es más valiosa de lo que pensaban	Los vendedores editaban ~30% de los correos (ajustes pequeños)	Decidieron mantener la revisión en la siguiente fase, no automatizarla
Los datos del CRM eran inconsistentes	Algunos leads tenían información incompleta	Añadieron lógica de “preguntar al vendedor si falta información crítica”
La latencia importa	Si el modelo tardaba más de 5 segundos, los vendedores se impacientaban	Optimizaron el prompt para reducir tokens de salida
El RAG funcionó mejor de lo esperado	Los correos que citaban casos de éxito relevantes tenían mayor tasa de respuesta	Ampliaron la base de conocimiento del RAG

El momento “aha”: un vendedor, después de usar el sistema durante una semana, dijo: “No me quita trabajo — me da tiempo para hacer más trabajo. Antes pasaba 2 horas al día redactando correos. Ahora paso 20 minutos revisando y enviando. El resto del tiempo lo paso hablando con clientes.” El sistema no había reemplazado al vendedor. Lo había amplificado.

Etapa 1.5: El escalón intermedio (50 usuarios)

“El piloto funcionó. Los vendedores quieren más. El equipo va a crecer a 50 personas en el próximo trimestre. ¿Qué tenemos que cambiar?”

El salto de 10 a 50 usuarios no es tan dramático como el de 10 a 1,500, pero introduce nuevas consideraciones:

Dimensión	Cambio	Implicación
Volumen	10 → 50 usuarios (5×)	La factura de la API empieza a ser visible
Variedad	Más industrias, más tipos de cliente	El RAG necesita más documentos y mejor segmentación
Concurrencia	Picos más pronunciados	Empieza a importar el rate limit de la API
Personalización	Vendedores con estilos diferentes	El prompt necesita capturar “estilo de marca” de forma más explícita

Las decisiones de la etapa 1.5:

Mantener la API alojada — con 50 usuarios el costo seguía siendo aceptable (~$500/mes), y el autohospedaje seguía siendo más caro.
Añadir prompt caching — como el prompt de sistema era el mismo para todos, habilitaron prefix caching en la API. Ahorro: ~30-40% en costo y latencia de prefill.
Segmentar el RAG por industria — en vez de una sola base vectorial, crearon una por industria (farmacia, retail, banca, manufactura), limitando la búsqueda a la industria del lead y mejorando la precisión de recuperación.
Añadir un “filtro de tono” al final del pipeline — otro paso, con un modelo más barato, verificaba que el tono coincidiera con la voz de marca, sugiriendo correcciones si no.
Recopilación de métricas de uso — empezaron a registrar qué vendedores usaban más el sistema, qué industrias generaban más correos, y cuáles eran las ediciones más comunes — datos que serían cruciales para la etapa de 1,500.

Etapa 2: Escalando a 1,500 vendedores (el salto cuántico)

“Hemos crecido. 1,500 vendedores. 30,000 solicitudes al día. El sistema que funcionaba con 10 usuarios ahora es el sistema que toda la empresa usa. Y está empezando a romperse.”

— Carlos, ahora VP de Ventas

A esta escala, el problema cambia de naturaleza. Con 10 usuarios, el reto era criterio y calidad. Con 1,500 vendedores, el throughput, el costo, y la gobernanza se vuelven problemas de ingeniería reales.

Qué deja de funcionar tal cual

Componente	Problema a escala	Por qué se rompe
Revisión humana centralizada	No es viable que una persona revise los correos de 1,500 vendedores	El volumen es demasiado alto
Llamadas directas a la API	Los picos de tráfico topan los rate limits del proveedor	1,500 vendedores → 30,000 solicitudes/día, picos a las 9am
Un solo modelo para todo	El costo por token se vuelve una línea de presupuesto real	Evaluar clientes es más barato que redactar correos — pagar lo mismo por ambas es un desperdicio
Auditoría manual	No se puede auditar manualmente cada interacción	Hace falta observabilidad real (Parte III, Capítulo 5)
Sin control de tráfico	Una tormenta de solicitudes de 300 vendedores simultáneos colapsa la API	El rate limit del proveedor se topa en minutos

La arquitectura escalada

Las piezas nuevas, y por qué cada una existe:

1. Gateway de IA — el portero. Con 10 usuarios, la orquestación era simple: armar el prompt y llamar a la API. Con 1,500, ese punto único necesita tres responsabilidades nuevas:

Rate limiting (encolar y espaciar): el gateway mantiene una cola de solicitudes por vendedor y por ventana de tiempo. Si un vendedor supera el límite (ej. 30 solicitudes/hora), sus solicitudes se espacian; si el sistema global supera el límite del proveedor, las solicitudes se encolan y se procesan en orden.
Caché de prompts (reutilizar el cómputo): el prompt de sistema (5,000 tokens) se procesa una vez; las siguientes 1,499 llamadas reutilizan ese prefill, pagando solo por los tokens nuevos — el prompt caching que ofrecen los proveedores de API.
Enrutamiento entre modelos: si la tarea es “evaluar cliente” → modelo rápido; si es “redactar correo” → modelo capaz. El enrutamiento es una regla fija de código, no un LLM decidiendo dinámicamente — seguimos dentro del patrón secuencial, solo que ahora la decisión está automatizada a nivel de infraestructura.

2. Dos niveles de modelo, no uno. Evaluar un cliente nuevo es una tarea más estructurada, cercana a clasificación — puede resolverse con un modelo más barato y rápido, posiblemente uno pequeño afinado específicamente para esa tarea (aquí es donde LoRA/QLoRA de la Parte II deja de ser un ejercicio educativo y se vuelve una decisión de costo real). Redactar el correo, donde el tono y la calidad importan para la reputación, justifica pagar por un modelo más capaz. Si evaluar es 10× más frecuente que redactar, y puede hacerse con un modelo 10× más barato, el ahorro es significativo.

3. Guardrails automáticos antes de la revisión humana. La revisión ya no es “alguien más aprueba” — es un filtro automático que verifica: ¿el correo menciona datos que no deberían estar ahí?, ¿usa lenguaje prohibido?, ¿inventó una cifra o promesa que no está en los datos del cliente?, ¿el tono coincide con la voz de marca? Solo si el guardrail pasa, el sistema muestra el correo al vendedor para que lo revise y apruebe. La IA nunca “posee” el envío final — el vendedor sigue siendo el responsable.

4. Registro de la acción vía MCP. Después de que el vendedor aprueba y envía, el sistema actualiza el CRM (marca el correo como enviado, registra la fecha de seguimiento) — una acción en tiempo real, del lado de MCP, no de RAG.

Las decisiones de infraestructura (aplicando el trilema)

Estimación de demanda: cada vendedor genera ~20 solicitudes/día → 30,000 solicitudes/día en total. Si el 40% se concentra en las primeras 2 horas de la mañana → 12,000 solicitudes en 2 horas → ~1.7 solicitudes/segundo en promedio. El problema real son los picos: si 300 vendedores disparan una evaluación en el mismo minuto, hay que absorber ~300 solicitudes concurrentes en una ventana corta — ese número de pico es el requisito real de throughput, no el promedio.

Dónde vive cada concepto:

Concepto	Dónde aplica	Quién decide
Batch size	Dentro del “Modelo rápido” — solo si se autohospeda	El equipo de infra, si se autohospeda
Batching (invisible)	Dentro del “Modelo capaz” — la API alojada lo hace internamente	El proveedor de la API
Throughput	El Gateway de IA — debe absorber el pico sin colapsar	El equipo, vía diseño del gateway y/o cuota con el proveedor
Latencia	Lo que cada vendedor experimenta esperando su evaluación o correo	Resultado de las dos decisiones anteriores
Rate limit	El techo impuesto por el proveedor (RPM y TPM)	El proveedor (negociable en tiers empresariales)

La pregunta que decide si conviene self-hosting: con 1,500 usuarios, el argumento de “no autohospedes nada” ya no es tan obvio — pero tampoco se vuelve automáticamente “sí, autohospeda todo”. La pregunta correcta es de volumen real: ¿cuántas llamadas al modelo se generan por día, y de qué tamaño?

Evaluación de clientes: tarea frecuente (~80% de las llamadas), modelo pequeño (7B-13B), decenas de miles de llamadas diarias. Costo anual en API: ~$20,000-$30,000. Self-hosting (una GPU de 24GB, modelo cuantizado, vLLM) puede costar ~$5,000 en hardware + ~$2,000/año en electricidad → ahorro significativo desde el primer año.
Redacción de correos: tarea menos frecuente (~20% de las llamadas), modelo grande (70B+), necesita calidad. El costo en API es aceptable porque el volumen es menor; self-hosting requeriría varias GPUs o un modelo más pequeño con pérdida de calidad — mejor mantenerlo en API alojada.

La decisión final: patrón híbrido. Modelo rápido (evaluación) autohospedado con vLLM, cuantizado, en una sola GPU de 24GB. Modelo capaz (redacción) vía API alojada, con prompt caching habilitado. Gateway de IA autohospedado en un servidor pequeño. RAG y MCP autohospedados (bases de datos vectoriales + servidores MCP).

Observabilidad y seguridad a esta escala

Con 10 usuarios, un error ocasional lo detectaba el propio vendedor al leer el correo antes de enviarlo. Con 1,500, hace falta la misma disciplina que construimos para el asistente de RR.HH. en la Parte III.

Golden datasets, separados por tarea: dataset de evaluación (clientes de prueba con calificación “correcta” ya conocida, ejecutado semanalmente para detectar deriva), dataset de redacción (perfiles de cliente con correos “gold standard”, para validar que el modelo no degrade), y dataset de guardrails (ejemplos de correos que deberían bloquearse, para verificar que los guardrails no se debiliten). Mezclar estos datasets impediría diagnosticar si una caída de calidad viene de la evaluación o de la redacción — separados, permiten aislar el problema.

Trazabilidad agéntica: si un vendedor reporta que el correo generado le atribuyó a un cliente una necesidad que no tiene, hace falta reconstruir la cadena completa — ¿qué fragmentos recuperó el RAG del playbook?, ¿qué dato trajo la consulta MCP al CRM?, ¿qué prompt final se le pasó al modelo de redacción? Sin esa traza, “el correo salió mal” no dice si el problema fue de recuperación, de datos en vivo, o de la generación misma.

Red-teaming, antes del lanzamiento a escala: el equipo probó ataques deliberados — inyección indirecta en formularios de captura de leads con texto malicioso escondido, intentos de extraer datos de otros clientes manipulando el modelo de evaluación, y manipulación del tono vía prompts maliciosos en los datos del cliente. Resultado: encontraron una vulnerabilidad real en el procesamiento de campos de texto libre del CRM, y la cerraron antes del lanzamiento general.

El impacto real: lo que los números dicen (y lo que los vendedores sienten)

Después de 6 meses con el sistema escalado, la empresa midió el impacto:

Métrica	Antes (sin IA)	Después (con IA)	Cambio
Tiempo de evaluación por lead	15-20 min	2-3 min	~80% menos
Correos enviados por vendedor/día	8-10	18-22	~2× más
Tasa de respuesta de correos	12%	18%	+50%
Tasa de conversión de leads	8%	11%	+37%
Tiempo en revisión de correos	2 min/correo	30 seg/correo	~75% menos
Satisfacción del vendedor (1-10)	6.2	8.7	+2.5 puntos

El testimonio que importa:

“El sistema me da superpoderes. No es que haga mi trabajo por mí — es que me permite hacer más trabajo, mejor trabajo, y trabajo que importa. Antes pasaba el día redactando correos. Ahora paso el día hablando con clientes. Y mis números lo reflejan: he cerrado un 40% más de tratos este trimestre que el anterior.”

— Laura, vendedora, 3 años en la empresa

Lo que el sistema NO hizo

Vale la pena notar lo que el sistema no logró (y que la empresa no esperaba que lograra):

No reemplazó a los vendedores. Ningún vendedor fue despedido — al contrario, el equipo creció de 10 a 1,500 en 18 meses.
No eliminó la necesidad de formación. Los vendedores nuevos siguen necesitando aprender a vender; el sistema les da una base, no un atajo.
No resolvió problemas de datos. El sistema es tan bueno como los datos del CRM — si los datos son malos, los correos son malos.
No eliminó la revisión humana. Sigue siendo el vendedor quien aprueba y envía; el sistema es un asistente, no un sustituto.

Lecciones generales del caso

1. La arquitectura correcta es una función del volumen. Lo que es sobre-ingeniería con 10 usuarios (gateway, dos niveles de modelo, guardrails automáticos) se vuelve necesario con 1,500. Y lo que es suficiente con 10 usuarios (un solo modelo, revisión manual, sin caché) se convierte en un cuello de botella. La decisión clave: saber cuándo es el momento de escalar la arquitectura, y hacerlo antes de que el sistema se rompa por sí solo.

2. La revisión humana no desaparece al escalar — se transforma. Con 10 usuarios, un aprobador dedicado revisa todo. Con 1,500, guardrails automáticos filtran, y el propio actor revisa antes de actuar. El principio: la automatización no elimina la responsabilidad humana — la redirige hacia donde más importa.

3. El costo de la inferencia es una decisión de arquitectura, no un detalle de implementación posterior — se decide desde el diseño, considerando el patrón de tráfico real (síncrono vs. asíncrono, picos vs. promedio). El patrón híbrido: cada tarea con la infraestructura que su volumen y su necesidad de calidad justifican.

4. Ningún concepto de infraestructura vive aislado. Latency, throughput, batch, rate limit, prompt caching, y selección de modelo son decisiones interconectadas — cambiar una afecta a las demás. Ejemplo: añadir prompt caching reduce la latencia del prefill, lo que permite batches más grandes sin degradar la experiencia del usuario.

5. Autonomía y verificación crecen juntas. Con 10 usuarios, casi no había verificación automática — el propio vendedor era el control de calidad. Con 1,500, cada capacidad nueva que agregamos (RAG, MCP, dos modelos, un gateway) vino acompañada de un mecanismo de control nuevo (guardrails, golden datasets, trazabilidad, red-teaming). Este caso es la demostración práctica de la idea que cerró la Parte II: cada capa de autonomía requiere una capa adicional de verificación.

Cierre del viaje (y lo que esto significa para ti)

Hemos recorrido un camino que empezó en la Parte I con un predictor de tokens, pasó por la Parte II con agentes y RAG, atravesó la Parte III con infraestructura y observabilidad, y ahora termina aquí: con un sistema real, funcionando en producción, usado por 1,500 personas, que genera valor de negocio tangible.

Lo que este caso demuestra:

Los principios del compendio no son teoría. Cada capítulo que has leído —desde los embeddings hasta los guardrails— tiene un lugar en este sistema. Ninguna pieza es opcional.
La evolución es inevitable. El sistema que funciona con 10 usuarios no es el sistema que funciona con 1,500. Diseñar para el presente, con una hoja de ruta hacia el futuro, es la habilidad clave.
La IA no reemplaza a las personas — las amplifica. Los vendedores no perdieron sus trabajos. Ganaron tiempo para hacer más de lo que mejor saben hacer: vender.
La verificación es el precio de la autonomía. Cada vez que se añadió capacidad (RAG, MCP, agentes), se añadió control (guardrails, evals, observabilidad). Eso no es un extra — es el costo de tener un sistema que realmente funciona.

Para ti, que has llegado hasta aquí: ya no eres solo alguien que “usa IA”. Eres alguien que diseña sistemas con IA. Sabes que la arquitectura correcta depende del volumen, no de una plantilla. Sabes que la autonomía sin verificación es riesgo, no poder. Sabes que la observabilidad no es un extra — es la diferencia entre un experimento y un producto.

El siguiente paso: aplicar todo esto a tu propio contexto. La empresa de este caso tenía 10 vendedores y llegó a 1,500. Tú tienes tu propio problema, tu propio volumen, tu propio patrón de uso. Las herramientas y los principios están aquí. Ahora te toca a ti.

Fin del compendio.

Nota del autor: este caso es una construcción didáctica basada en patrones reales de escalado de sistemas de IA en empresas de consultoría y tecnología. No corresponde a una empresa específica, pero las decisiones arquitectónicas, los trade-offs, y las lecciones son reales y aplicables. El viaje de Carlos, Ana, y Laura es el viaje de cualquier equipo que pasa de un prototipo a un sistema de producción a escala.