CCAR-P · Comunicación con stakeholders y ciclo de vida
El traspaso no es el final, dueño, evaluaciones periódicas y umbrales que disparan la iteración
El asistente de compras salió muy bien evaluado. Seis meses después recomienda productos discontinuados y no conoce la mitad de las categorías nuevas. Nadie tocó el código. El equipo de proyecto creía que operaciones se ocupaba de las evaluaciones; operaciones creía que eran del equipo de proyecto. Faltan tres semanas para la campaña más grande del año.
Las fases y quién es dueño de cada una
El ciclo de vida (lifecycle) de una solución no termina en el traspaso:
| Fase | Qué se entrega | Dueño |
|---|---|---|
| Discovery | problema, métrica, línea de base, requisitos | arquitecto con el negocio |
| Diseño | arquitectura, ADR, suite de evaluación | arquitecto y equipo de proyecto |
| Piloto y lanzamiento | resultados contra los criterios de aceptación, runbook probado | equipo de proyecto |
| Traspaso | operación compartida un tiempo, documentación | los dos equipos |
| Monitoreo | tableros de calidad, costo y operación, alertas | dueño del sistema |
| Iteración | cambios evaluados y lanzados de forma controlada | dueño del sistema |
La fila que suele faltar es la última. Sin un dueño del sistema (system owner) con nombre y tiempo asignado, las evaluaciones dejan de correr el día que el equipo de proyecto se va.
Por qué se degrada sin que nadie lo toque
Un sistema con LLM tiene deriva (drift) aunque el código esté congelado:
- cambian los datos: catálogo, políticas, documentos que alimentan la recuperación;
- cambian los usuarios: preguntas nuevas, otra forma de pedir, temporadas;
- cambia el entorno: modelos que se retiran y hay que migrar, APIs internas que cambian de formato;
- cambia el propio sistema: alguien ajusta el prompt para un caso y rompe otro.
Por eso la evaluación del lanzamiento caduca: medía el sistema contra los datos de ese momento.
Lo que tiene que existir después del traspaso
- Un dueño responsable de la calidad, el costo y los cambios.
- Evaluación periódica (scheduled evaluation): la suite corre con un calendario fijo sobre un dataset que se refresca con casos recientes de producción, anonimizados.
- Umbrales de disparo (trigger thresholds): valores acordados que, al cruzarse, abren una iteración sin esperar a que alguien se queje.
- Un proceso de cambio: todo cambio de prompt, modelo o índice pasa la suite antes de salir y se lanza de forma gradual.
| Métrica | Umbral de ejemplo | Acción |
|---|---|---|
| Precisión en la suite periódica | cae más de 3 puntos | revisar recuperación y datos nuevos |
| Tasa de derivación a personas | sube un 20% en dos semanas | analizar los casos derivados por tema |
| Costo por transacción | supera el presupuesto acordado | revisar caché, ruteo y longitud de salida |
| Aviso de retiro del modelo | fecha anunciada | evaluar el reemplazo con la suite y planificar la migración |
Las trampas típicas
- Dar el proyecto por terminado en el traspaso.
- Volver a llamar al equipo de proyecto cuando las quejas pasan cierto nivel: reacciona tarde y no deja dueño.
- Congelar los datos (el catálogo, las políticas) para que el asistente no se desactualice.
- Hacer fine-tuning con el catálogo nuevo cuando lo que falta es actualizar la recuperación y medir.
- Evaluaciones “cuando haya tiempo”, con el mismo dataset del lanzamiento.
En el examen
Si un sistema se degradó meses después del lanzamiento y nadie lo vio venir, buscá la opción que asigna un dueño, programa evaluaciones periódicas con datos actualizados y define umbrales que disparan la iteración. Descartá las que reaccionan a las quejas, congelan el negocio o cambian el modelo sin medir.
Pregunta rápida
Una pregunta del simulacro sobre este dominio. Cuenta para tu progreso.
A retail chain wants Claude to produce a daily narrative report for each of its 600 stores, summarising sales anomalies, stock issues and customer comments. The regional managers' request says the reports must be 'real-time'.
When the architect interviews the managers, it turns out they read the reports at the 8 a.m. stand-up and nobody looks at them during the day. The architect would like to generate them overnight with the Message Batches API, which costs noticeably less than running the same requests one by one in real time, and the job would comfortably finish before morning.
The sponsor, the retail operations director, controls the budget and was the one who wrote 'real-time' in the request.
How should the architect handle this decision?