Idea principal

Una funcionalidad determinista se prueba comparándola con un resultado esperado: el resultado es conforme o no lo es. Una respuesta producida por un modelo no ofrece ese asidero. Dos formulaciones correctas no tienen el mismo valor para el usuario, una respuesta falsa puede ser perfectamente plausible, y la experiencia del fallo — lo que hace el producto cuando no sabe — pasa a formar parte del producto igual que el acierto.

Evaluar este tipo de salida recae, por tanto, sobre preguntas que ningún conjunto de pruebas de conformidad cubre: la robustez ante los casos retorcidos, la coherencia con la intención de producto, la confianza que el usuario puede razonablemente depositar, y lo que está dispuesto a aceptar como margen de error en su trabajo.

Por eso, reducir esta evaluación a un control de calidad clásico la vacía de sustancia: la pregunta no es solo "¿es correcta la salida?" sino "¿es aceptable esta salida, aquí, para este uso?" — una pregunta de producto, no de verificación.

Por qué es importante

Dice a quién le corresponde la evaluación: no puede delegarse por entero en una función de control al final de la cadena, ya que exige decidir sobre la intención y sobre lo que el usuario tolera.

Y vuelve comprobable lo que muchos equipos renuncian a medir: la confianza y la aceptabilidad se trabajan con casos de negocio, escenarios de fallo y criterios escritos, no con una impresión general de calidad.

Matices y límites

La aceptabilidad no exime de la conformidad: en las reglas verificables — un cálculo, un permiso de acceso, un formato —, la exigencia sigue siendo binaria y el argumento probabilístico no debe servir de excusa.

Y el umbral de aceptabilidad no pertenece al equipo que produce: se constata con quienes usan, y varía según el ámbito, lo que está en juego y la reversibilidad de lo que la salida desencadena.

Preguntas abiertas

• ¿Cómo fijar por escrito un umbral de aceptabilidad, cuando lo que está en juego es la confianza de un usuario y no una tasa de error observable?