Cliente. Un sistema de salud académico de EE.UU., a través del equipo de modernización de aplicaciones de un hyperscaler global de cloud. El departamento de enfermería necesita que cada profesional empiece su turno sabiendo qué cambió: alertas de seguridad del paciente, novedades operativas de la unidad y lo informativo, sin leerse la bandeja de correo entera. La plataforma está diseñada para decenas de miles de profesionales de enfermería en varios campus.
Enfoque
Llegué a un sistema que ya existía y que había que llevar a escala. Tomé la responsabilidad del backend, del servidor MCP y del pipeline multiagente cuando se fue el Tech Lead de backend, y además quedé como backup del framework de evaluación.
La tesis que ordena el trabajo es que el costo y el riesgo de un sistema agéntico se diseñan, no se descubren en la factura. Con un modelo de lenguaje, cada decisión de arquitectura es también una decisión de precio: qué entra al contexto, qué se repite en cada corrida, cuánto audio se genera. Si nadie modela eso antes de producción, el primer dato real sobre el costo llega a fin de mes, y con él la conversación incómoda.
El problema detectado
- El volumen multiplica cualquier descuido. El dimensionamiento de la primera fase es de 78.000 corridas semanales y 7.800 usuarios concurrentes. Un par de miles de tokens de más por corrida parece irrelevante en una prueba; a esa escala no lo es.
- Buena parte del prompt se repetía idéntico en cada corrida. Guardrails y reglas de negocio suman unos 14.500 tokens estáticos que se volvían a pagar a precio completo cada vez.
- Hay un precipicio de precio. Por encima de 200.000 tokens de contexto, las tarifas de entrada y salida del modelo se duplican. La segunda fase suma ingesta de documentos, y sin control el contexto cruzaba ese umbral.
- Las reglas clínicas estaban mezcladas con la aritmética. La lógica de qué importa para cada rol de enfermería convivía con el motor que reparte el presupuesto de palabras. Cambiar una regla clínica obligaba a tocar el motor.
Relevamiento funcional
El pipeline clasifica cada ítem en niveles antes de sintetizar, y esa clasificación es la que después reparte el presupuesto:
| Nivel | Qué contiene | Cómo se trata en el briefing |
|---|---|---|
| Tier 1 | Seguridad del paciente | Entra siempre, sin compresión |
| Tier 2 | Operativa de la unidad | Entra según el presupuesto restante |
| Tier 3 | Informativo | Se comprime primero cuando falta espacio |
| Ruido | Correos sin contenido accionable | Se filtra antes de llegar al modelo |
El briefing tiene un presupuesto determinístico de 500 palabras, unos dos minutos de audio. Ese número no es estético: es la variable que controla el costo de síntesis y el tiempo que la enfermera le dedica al inicio del turno.
Construcción de la solución técnica
- Backend, MCP y agentes. Backend en FastAPI. Servidor Model Context Protocol que integra Microsoft Graph, SharePoint y BigQuery con delegación On-Behalf-Of: cada consulta corre con la identidad del usuario, no con una cuenta de servicio omnipotente. El pipeline multiagente en Google ADK usa Gemini 2.5 Pro para sintetizar y Gemini 2.5 Flash TTS para el audio.
- Reglas separadas del motor. Separé las reglas clínicas por rol (enfermería asistencial, especialistas clínicos, liderazgo y asistentes) del motor determinístico de presupuesto de palabras, y dejé los guardrails del sistema como contratos inmutables. Ahora una regla clínica se cambia sin tocar la aritmética, y la aritmética se prueba sin opinar sobre medicina.
- Configuración en un solo lugar. Centralicé la configuración con Pydantic Settings v2. Reemplaza las lecturas de variables de entorno que estaban dispersas en routers, helpers de voz y conectores MCP, y valida los tipos al arrancar, no a mitad de una corrida.
- Sin fallas silenciosas. Eliminé fallbacks que ocultaban errores y fijé contratos inmutables de salida y de citación. En un contexto clínico, un briefing que falla visiblemente es preferible a uno que sale incompleto sin avisar.
- Desbloqueo de infraestructura. El despliegue del backend de evaluación en Cloud Run estaba trabado por el puerto del contenedor. Mostré que el contenedor ya aceptaba el puerto por parámetro, así que alcanzaba con inyectarlo desde Terraform, sin reconstruir imágenes ni duplicar pipelines de CI/CD. El liderazgo técnico adoptó la solución en la misma sesión. También diagnostiqué un 404 del frontend detrás del balanceador, causado porque el base path de compilación no coincidía con las reglas de ubicación del proxy inverso.
Capa de información y datos
La economía de tokens es, en el fondo, gobierno de lo que entra al contexto:
- Caché de contexto. Los ~14.500 tokens estáticos de guardrails y reglas pasan por Vertex AI Context Caching, que los cobra con un 90% de descuento en lugar de a precio completo en cada corrida.
- Filtrado de ruido. Un filtro de correos saca unos 8.000 tokens por corrida que no aportaban nada accionable.
- Resultado combinado. Las dos medidas juntas bajan un 40,8% el gasto proyectado de inferencia por lote.
- Lejos del umbral. El mismo diseño mantiene el contexto de la segunda fase por debajo de los 200.000 tokens, donde la tarifa se duplica.
- Auditoría del audio. En síntesis de voz, cada token de audio generado cuesta unas veinte veces más que uno de texto de entrada, a razón de unos 25 tokens por segundo. El presupuesto de 500 palabras (~700 tokens de entrada, ~3.100 de audio) absorbe ese diferencial si se comprime primero lo informativo y se cachea el audio ya generado.
Una aclaración de honestidad: el 40,8% sale del modelo financiero y de carga que co-escribí con el Practice Lead, no de facturación medida. La plataforma todavía no opera a su escala completa. El número dice cuánto cuesta la arquitectura tal como está diseñada, que es exactamente lo que hay que saber antes de escalarla.
Cómo se condujo el trabajo
- El modelo de costos como artefacto de ingeniería. El modelo de carga vive al lado del código y se discute como un diseño, no como una planilla que hace finanzas al final.
- Evaluación compartida. Soy co-responsable de la evaluación automatizada de agentes (juez LLM sobre un banco de 50 perfiles clínicos, con telemetría en Cloud Run y BigQuery), así que cada cambio de costo se contrasta contra la calidad del briefing.
- Visibilidad operativa. Escribí CLIs concurrentes en Python para auditar en tiempo real el backlog de ingeniería y los canales entre equipos.
- Documentación de punta a punta. Armé un atlas BPMN 2.0 de 12 guías HTML interactivas con los flujos humanos, clínicos e informáticos: autenticación delegada, screening de prompt injection, el reparto del presupuesto y el pipeline de audio con su fallback.
Qué prueba este caso
- FinOps de LLM antes de producción: el costo se modeló, se atacó en sus dos fuentes principales (lo repetido y lo irrelevante) y se alejó del precipicio de precio antes de escalar.
- Resiliencia por diseño: reglas separadas del motor, configuración validada al arranque y contratos que no dejan pasar un error en silencio.
- Continuidad técnica: tomé un sistema en marcha a mitad de camino y lo seguí haciendo evolucionar, en lugar de reescribirlo.