Del pedido "queremos un agente" al problema real

La directora de operaciones pide “un agente que resuelva los reclamos”. El área de sistemas quiere elegir modelo y framework este mes. Nadie sabe cuántos reclamos entran por tipo ni cuánto tarda cada uno. Si arrancás a construir con eso, vas a entregar algo que nadie puede evaluar ni defender. El primer trabajo del arquitecto es convertir el pedido en un problema.

Dónde se va el tiempo o la plata hoy

El relevamiento (discovery) no es una reunión para anotar deseos: es mirar el proceso real. Las preguntas que ordenan todo:

• ¿Qué parte del proceso consume más horas o más costo?
• ¿Qué decisiones tiene que tomar una persona por ley, por contrato o por riesgo?
• ¿Qué volumen hay por tipo de caso y cuánto riesgo tiene cada uno?

Muchas veces el pedido es “un agente que decida” y el cuello de botella real es leer, extraer o resumir. Si el 70% del tiempo se va en transcribir montos de informes adjuntos y la decisión final la tiene que firmar un profesional matriculado, la solución no es automatizar la decisión: es extraer los datos en un formato estructurado y marcar los desvíos para que la persona decida más rápido. Eso es humano en el circuito (human-in-the-loop) por diseño, no por desconfianza.

Métrica de éxito y línea de base, antes de la arquitectura

“Menos tickets y empleados más contentos” no es una métrica de éxito (success metric). Una métrica sirve si se puede medir, si tiene un valor actual y si alguien acordó qué valor cuenta como éxito.

1. Elegí el indicador que el sponsor quiere mover (tiempo de gestión, costo por caso, tasa de error).
2. Medí su línea de base (baseline) en el proceso actual, antes de tocar nada.
3. Mapeá los casos por volumen, esfuerzo y riesgo: lo de mucho volumen y poco riesgo es candidato a automatizar; lo de alto riesgo (una denuncia que puede terminar en una investigación) queda con personas o con revisión obligatoria.
4. Recién ahí elegí patrón, modelo y herramientas.

Elegir el modelo o escribir el system prompt antes de este paso es empezar por el final: son decisiones que salen de los requisitos, no que los fijan.

Atar la técnica al valor de negocio

La guía habla de pilares de valor de negocio (business value pillars): eficiencia, productividad, transformación, costo y SLA de rendimiento. Sirven para preguntar a qué pilar apunta el proyecto y qué indicador lo representa.

El sponsor pidió…	El indicador a medir
Que los analistas atiendan más casos	Casos por persona y tiempo por caso
Bajar el costo del área	Costo total por caso, incluidas las correcciones
Respuestas dentro del SLA	Latencia por percentil en el flujo que importa

La trampa es optimizar lo que es fácil de medir en lugar de lo que se pidió. Un equipo que baja la latencia de un resumen de 4 a 1,5 segundos hizo un buen trabajo técnico, pero si el sponsor pidió bajar el tiempo de trabajo posterior a la llamada y los agentes pierden minutos corrigiendo campos, otro sprint de latencia no mueve nada. Medí el indicador del negocio y priorizá cada cambio por su efecto en él.

Las trampas típicas

• Aceptar “un agente” como requisito en lugar de investigar el problema.
• Elegir el modelo más capaz “para no rehacer nada” antes de tener requisitos.
• Un prototipo multiagente de todo para impresionar, sin saber qué conviene automatizar.
• Automatizar una decisión que por norma tiene que tomar una persona.
• Reportar mejoras técnicas (latencia, costo por pedido) sin mostrar su efecto en el indicador del sponsor.

En el examen

Los escenarios de este objetivo suelen tener un párrafo de relevamiento con el dato clave: dónde se va el tiempo, qué decisión es obligatoria para una persona o que nadie mide el indicador. Buscá la opción que ataca ese cuello de botella y deja la decisión regulada en manos humanas. En las preguntas de “qué hacer antes de elegir la arquitectura”, las respuestas buenas son definir la métrica con línea de base y priorizar casos por volumen y riesgo; descartá las que eligen modelo, escriben prompts o construyen prototipos primero.