Santia: bot ciudadano de WhatsApp

Arquitectura y servicios

Santia son dos capas con responsabilidades opuestas. Una es una máquina de estados determinística que recolecta datos paso a paso, los valida y los escribe en los sistemas municipales. La otra es una capa de IA que entiende qué quiere el vecino cuando escribe en lenguaje libre. La regla que ordena todo el sistema es esa: la IA entiende, el bot ejecuta. Cuando se detecta una intención de trámite, la capa de IA no pide los datos: dispara el flujo determinístico y se hace a un lado hasta que el trámite termina.

Los trámites se clasifican en tres tipos según su complejidad. IA pura para consultas informativas abiertas, donde la respuesta sale de un RAG sobre documentación municipal indexada en Qdrant. Híbrido para trámites donde la IA comprende y clasifica pero los pasos críticos son determinísticos, como turnos médicos o renovación de licencias. Determinístico puro para formularios, pagos y validaciones contra APIs externas, donde no hay nada que interpretar. El escaneo de DNI se resuelve con visión y OCR dentro del mismo turno.

Hasta principios de 2026 la capa de decisión vivía enteramente en un orquestador no-code: un agente principal que clasificaba y delegaba en sub-agentes por dominio, cada uno con su propio acceso a la base vectorial. Sostuvo 63.000 conversaciones y funcionó. El costo era estructural: cada consulta encadena varias llamadas al modelo, el estado conversacional queda repartido entre sistemas y las reglas de negocio viven adentro de prompts. Esa capa se está reemplazando por código.

Volumen y operación

Desde el lanzamiento masivo en noviembre 2025, el bot procesó más de 9.6 millones de mensajes. El pico mensual fue noviembre (17.768 conversaciones), el mes de arranque. El promedio de mensajes por día en abril 2026 es de ~57.000.

Hay un patrón semanal muy marcado: domingos y lunes concentran el mayor tráfico (~250 a 317 conversaciones/día), mientras que viernes y sábados están en el mínimo (~65 a 114). La ratio pico/valle es de aproximadamente 4:1.

Resolución automática vs operador humano

Todas las conversaciones pasan por la capa de IA, que clasifica el intent de cada mensaje y decide el camino: flujos determinísticos para trámites con pasos conocidos, respuestas en lenguaje natural del LLM para consultas abiertas, o escalamiento a un operador cuando el trámite lo requiere.

El resultado: el 85% se resuelve sin intervención humana. El 15% restante se deriva a operadores para atención personalizada.

La migración del agente: el LLM propone, el código dispone

El rediseño se apoya en cuatro reglas. Ningún modelo ejecuta un efecto de lado: devuelve una estructura y el código valida y decide si actúa. Hay una sola llamada al LLM en el camino de decisión, no un orquestador que llama a agentes que llaman a agentes. Si el vecino ya está adentro de un trámite, el modelo no interviene. Y decidir y conversar son capas separadas, para poder cambiar el framework conversacional sin tocar nada de arriba.

El turno entra, se normaliza, se carga la sesión y recién ahí se clasifica. El router hace una sola llamada con salida estructurada y devuelve dominio, acción, entidades, confianza y qué datos faltan. Con eso decide una función pura. Lo que más mueve el costo no es qué modelo se usa: es que cuando queda una intención esperando un dato, el mensaje siguiente lo resuelve un validador y el modelo no se llama.

La policy cubre 17 dominios y cada rama es código testeable sin levantar nada. El umbral de confianza depende del dominio y también de la acción: preguntar algo sobre turismo no tiene por qué superar la misma vara que arrancar un expediente municipal. Si el modelo devuelve una acción que el dominio no permite, se corrige el verbo en vez de descartar el tema. Y si están todos los datos pero uno lo recordamos de un turno anterior, se confirma antes de registrar nada.

Respuestas con fuentes, o ninguna respuesta

El guardrail contra alucinaciones no es una línea de prompt: es una rama del código. Antes de contestar una consulta informativa se buscan fragmentos en las colecciones del dominio. Si ninguno supera el score mínimo, no se llama al modelo. Se dice que no está esa información y se pide reformular.

El razonamiento es simple: no se le puede pedir a un modelo que no invente si no se le da nada con qué responder. Cuando sí hay material, la síntesis se hace únicamente sobre esos fragmentos, y el prompt prioriza no omitir ningún requisito por sobre ser breve. Un horario o una dirección que no esté en el material no se escribe.

El caso que justificó el diseño fue real y pasó en producción: preguntas del tipo "hola, dónde queda la Muni" entraban como charla informal, se contestaban sin fuentes y el modelo devolvía una dirección que no existe. Hoy ese mensaje se desvía al dominio institucional, que sí tiene material indexado.

Cómo se reemplaza una capa viva

Nada de big bang. Los dos sistemas conviven: un flag general, una lista de números habilitados y un gate por dominio deciden turno por turno quién atiende. Cualquier caso que la capa nueva no cubra vuelve al camino anterior sin que el vecino note nada.

Eso permite habilitar un dominio, medirlo contra el comportamiento anterior y seguir con el que sigue. Para probar sin gastar mensajes de WhatsApp hay un sandbox que corre el pipeline real y muestra al costado la decisión tomada, las etapas del turno y cada llamada al modelo, más un visor de trazas por conversación.

El agente nativo ya atiende conversaciones reales sobre WhatsApp. Los 17 dominios están implementados y medidos, y el rollout avanza dominio por dominio detrás del flag, que es exactamente como se reemplaza una capa de la que dependen 63.000 conversaciones. El ritmo del cutover completo no lo marca la arquitectura: lo marca el límite de requests por minuto del proveedor de LLM contra el pico de tráfico.