Requisitos funcionales y de infraestructura; un cambio de prompt o de modelo es una versión

Un broker de seguros pide un asistente que resuma las llamadas: quiere el motivo, los datos de la póliza y los próximos pasos. El documento lista todo eso y nada más. Recién en la reunión aparece que el resumen se usa con el cliente todavía en línea y que compliance exige que las grabaciones no salgan de la región europea. Esas dos frases cambian el diseño más que todo lo anterior.

Qué hace y cómo tiene que funcionar

• Los requisitos funcionales (functional requirements) dicen qué hace el sistema: qué campos trae el resumen, qué botón aparece, qué pasa si falta un dato.
• Los requisitos no funcionales (non-functional requirements), o de infraestructura, dicen cómo tiene que funcionar: latencia, volumen, disponibilidad, residencia de datos (data residency), seguridad, trazabilidad, costo.

Elegir un modelo, usar streaming o pasar a lotes no son requisitos: son decisiones que salen de ellos.

Requisito	Decisión que sugiere
“La primera parte tiene que aparecer en segundos, con el cliente en línea”	Streaming, un modelo rápido, prompt corto
“Diez mil documentos por mes, sin apuro”	Message Batches API
“Los datos no salen de la región de la UE”	Endpoint regional o la plataforma de nube que lo garantice
“Poder explicar una decisión un año después”	Registro de auditoría desde el primer día

Auditar es guardar en el momento

Si el negocio tiene que mostrar más adelante qué recibió el sistema, con qué corrió y qué respondió, hay que guardarlo cuando pasa: la entrada, la salida, el ID de la solicitud, el ID del modelo fijado y la versión del prompt. Volver a correr el pedido después no reconstruye nada: el prompt pudo cambiar y la salida de un modelo no es determinista.

El ciclo de vida

Un sistema con Claude pasa por las mismas etapas que cualquier sistema: planificar, construir, probar, desplegar, operar y, al final, retirar o migrar. Lo particular es que hay dos piezas que cambian el comportamiento sin tocar el código: el prompt y el modelo. Por eso, un cambio de cualquiera de las dos es una versión más:

1. Pruebas de regresión (regression testing): se corre el set de casos evaluados (por ejemplo, ciento cincuenta conversaciones con la respuesta esperada) y se compara contra la versión actual.
2. Despliegue gradual (gradual rollout): primero a un porcentaje chico del tráfico, mirando métricas, y después al resto.
3. Vuelta atrás: la versión anterior queda lista para restaurarse en minutos.
4. Monitoreo en producción: tasa de errores, stop_reason inesperados, latencia, costo y alguna muestra revisada por personas.

Un prompt editado en caliente un viernes, que llega a producción sin pasar por nada de esto, es el escenario típico del examen.

Cuando un modelo se retira

Los modelos tienen fecha de retiro del modelo (model retirement), y después de esa fecha los pedidos a ese ID fallan. El aviso de deprecación es el comienzo de una tarea de mantenimiento:

1. Inventariar todos los lugares donde se configura un ID de modelo (servicios, jobs, scripts, nubes).
2. Evaluar el modelo sucesor en cada servicio con su propio set, y armar el set si falta.
3. Migrar con tiempo, con el mismo despliegue gradual de cualquier versión.

Las trampas típicas

• Confundir una decisión técnica (“usar Opus”) con un requisito.
• Pasar por alto los requisitos no funcionales escondidos en el contexto del escenario.
• Pensar que se puede auditar después volviendo a correr el pedido.
• Liberar un cambio de prompt o de modelo sin regresión, sin despliegue gradual y sin vuelta atrás.
• Esperar a la fecha de retiro para empezar a migrar.

En el examen

Si te piden requisitos de infraestructura, elegí los que hablan de latencia, volumen, región, disponibilidad o trazabilidad, no de funciones. Si el requisito es auditar, buscá el registro en el momento con modelo y versión de prompt. Si un cambio de prompt causó daño en producción, buscá regresión, despliegue gradual y vuelta atrás. Y ante un aviso de retiro, buscá inventario, evaluación del sucesor y migración antes de la fecha.