XIII. La confianza caduca: versiones, banco estable e incidentes
Una aceptación es una fotografía. El sistema cambia aunque conserve el mismo nombre comercial: entra documentación nueva, se sustituye un embedding, se modifica el prompt, se actualiza el modelo, cambia el reranker o se reajustan los umbrales. Cada intervención puede mejorar una familia de consultas y degradar otra.
Por eso la organización necesita conservar un banco estable de pruebas. No para impedir la evolución, sino para saber qué cambió. Ese banco estable conserva fallos conocidos y conductas críticas —recuperación, reformulación, evidencia, premisa falsa, abstención y controles positivos— y permite comparar una versión con la anterior caso por caso.
Repetir el mismo banco permite comparar versiones, pero no lo convierte en un examen independiente. Ante un cambio importante conviene añadir preguntas nuevas y mantenerlas fuera del ajuste: sobre documentación compartible para una nueva criba, o sobre el archivo interno para confirmar la utilidad real. El banco estable comprueba que no reaparezcan fallos conocidos; los casos nuevos examinan si la mejora se sostiene más allá de ellos.
También los incidentes reales deben alimentar ese banco. Si una respuesta equivocada o una cita insuficiente influyeron en una decisión, «el modelo se equivocó» no es un diagnóstico. Hay que conservar la ejecución, identificar qué versión y qué páginas intervinieron, reproducir el caso, localizar el tramo donde se produjo la pérdida y añadir una prueba que impida que el mismo patrón desaparezca en la siguiente actualización.
Los fallos repetibles deberían terminar convertidos en una prueba. Los fallos que todavía exigen juicio deben permanecer en muestras de revisión. De ese modo la experiencia no queda en una anécdota del usuario: se transforma en conocimiento de ingeniería sobre la propia herramienta.