Idea principal

Evaluar salidas probabilísticas, mantener una memoria de producto consultable, escribir una documentación aprovechable tanto por una máquina como por un humano, conservar un repositorio legible, formular criterios de aceptación nítidos, orquestar los encadenamientos de herramientas: nada de esto es nuevo. Esos trabajos ya existían, dispersos, sostenidos por quien tuviera tiempo, y nadie perdía gran cosa al descuidarlos.

En cuanto un equipo pone a trabajar agentes, dejan de ser periféricos. La calidad del contexto aportado determina la calidad de lo que se produce, y un contexto que nadie mantiene degrada todas las salidas a la vez. Lo que era cuestión de esmero se convierte en una condición de funcionamiento.

Esas necesidades no se convierten forzosamente en puestos. Se convierten en responsabilidades que hay que atribuir — y la pregunta que se le plantea a un equipo equipado ya no es "¿quién hace qué?" sino "¿quién juzga, quién construye, quién garantiza, quién evalúa, quién mantiene la memoria, quién orquesta?".

Por qué es importante

Explica por qué dos equipos con las mismas herramientas obtienen resultados muy distintos: la diferencia no se juega en la herramienta, se juega en aquello de lo que nadie tenía el encargo de ocuparse.

Y ofrece una lista de responsabilidades que atribuir explícitamente antes de constatar su ausencia, en lugar de después de que una salida falsa haya pasado a producción.

Matices y límites

Hacer visibles estas responsabilidades no dice cómo dotarlas. Un equipo que las atribuye sin liberar el tiempo correspondiente obtiene una lista de propietarios nominales y el mismo abandono que antes.

Y algunas de estas cargas son transitorias: la fiabilidad de las herramientas avanza, y una responsabilidad de evaluación dimensionada para el estado actual de los modelos puede volverse desproporcionada.

Preguntas abiertas

• ¿Cuáles de estas responsabilidades ganan al ser sostenidas por una persona dedicada, y cuáles se degradan en cuanto se sacan del equipo que produce?