Hipótesis de valor y criterios de éxito medibles

Hola. En la lección anterior evaluaste si un cliente estaba preparado para probar la clasificación y el resumen de consultas de acceso con revisión humana. Quedaron preguntas abiertas sobre datos, integración y autoridad para aprobar el piloto. Esas incógnitas importan: no basta con elegir un caso prometedor; hay que poder comprobar su valor sin dar por resueltas las condiciones de uso.

Durante unos 40 minutos convertirás el caso priorizado en una hipótesis de valor y en criterios de éxito medibles. El resultado será una ficha que puedas discutir con dirección, agentes y responsables del proceso antes de iniciar el piloto. No diseñaremos aún el despliegue: primero acordaremos qué tendría que observarse para justificarlo.

Del caso prometedor a una afirmación comprobable

Al priorizar un caso de uso, estimas que puede aportar valor y que merece estudiarse. Una hipótesis de valor da un paso más: expresa qué mejora esperas, para quién, mediante qué cambio en el trabajo y bajo qué condiciones. Sigue siendo una predicción, no un beneficio demostrado.

La matriz siguiente recuerda las tres perspectivas que motivan una priorización: impacto empresarial, deseabilidad para los usuarios y viabilidad técnica. Una puntuación alta ayuda a escoger dónde investigar; no demuestra que el ahorro, la calidad o la adopción se producirán.

La guía de AWS plantea la pregunta central de una prueba de concepto: si se construye la solución, ¿importará para el objetivo del negocio? Lee su propuesta de conectar objetivos, metas y medidas antes de concretar nuestra hipótesis.

Apliquemos esa distinción al caso que venimos siguiendo. El objetivo podría ser reducir el trabajo necesario para preparar consultas de acceso sin empeorar la fiabilidad de la atención. La estrategia sería mostrar al agente una clasificación y un resumen sugeridos por IA, manteniendo el original a la vista y exigiendo revisión humana antes de utilizarlos. La meta tendría que cuantificar una mejora en una tarea delimitada. Las medidas permitirían comprobar tanto esa mejora como sus posibles costes: correcciones, errores y uso efectivo por parte de los agentes.

Una primera formulación, deliberadamente provisional, sería:

Si los agentes reciben una clasificación y un resumen sugeridos para las consultas de acceso incluidas en el piloto, y pueden contrastarlos y corregirlos antes de usarlos, entonces disminuirá el tiempo de preparación de cada consulta respecto al procedimiento habitual, sin aumentar los errores relevantes ni exigir más trabajo de corrección del que se evita.

Esta frase identifica un mecanismo y una condición de calidad, pero aún no permite decidir si funcionó. «Disminuirá» necesita un umbral; «tiempo de preparación» necesita límites; y «errores relevantes» necesita una definición que dos personas puedan aplicar de manera consistente.

Definir una medida que realmente pueda contrastarse

Un KPI no queda definido al ponerle nombre. «Uso de IA» o «tiempo ahorrado» pueden significar cosas distintas según quién prepare el informe. En este vídeo breve, presta atención a los componentes que hacen comprobable una medida y a la diferencia entre señales tempranas y resultados.

Para nuestro piloto, la definición de tiempo podría ser: minutos de trabajo del agente desde que abre una consulta elegible hasta que deja preparada su clasificación y una nota utilizable, tras revisar y corregir cualquier sugerencia. Esa definición incluye la revisión humana; medir solo la rapidez con que la IA genera texto exageraría el ahorro. También permite comparar el piloto con el procedimiento anterior, siempre que se mida la misma tarea terminada en ambos periodos.

Antes de fijar la meta hay que obtener una línea de base: cuánto tarda hoy esa tarea, con qué variación y para qué tipos de consultas. Si las consultas excepcionales tardan mucho más que las habituales, una mejora aparente podría deberse simplemente a que durante el piloto entraron casos más fáciles. Conviene mantener los mismos criterios de inclusión y observar por separado los casos habituales y las excepciones.

Supongamos, solo como ejemplo hipotético, que una medición autorizada de 100 consultas elegibles anteriores da una mediana de 12 minutos. El equipo podría proponer como meta inicial una reducción de al menos el 15 % en consultas comparables: una mediana de 10,2 minutos o menos, incluyendo la revisión. El 15 % no procede de un estándar universal; es un umbral para negociar tras conocer la línea de base, la variación entre casos y el esfuerzo del piloto.

La fuente de los tiempos también debe existir en la práctica. Si el sistema solo registra cuándo llega y cuándo se cierra un ticket, quizá no permita medir esos minutos de trabajo activo. Habría que acordar un método viable —por ejemplo, registros del flujo o una observación acotada— antes de prometer ese KPI. Un dato que nadie puede recoger de forma fiable no es un criterio de éxito operativo.

Medir uso, resultado y calidad sin confundirlos

Los primeros usos indican si la solución está entrando en el trabajo cotidiano. No prueban, por sí solos, que aporte valor: un agente puede abrir la herramienta muchas veces y tardar más porque debe corregir sus resúmenes. Del mismo modo, una sugerencia rápida y correcta en una demostración no prueba que vaya a utilizarse durante una jornada real.

Esta lectura distingue entre señales de adopción, productividad, calidad, experiencia y valor organizativo. Ayuda a elegir pocas medidas equilibradas, en vez de llenar la ficha con todos los datos disponibles.

Para las consultas de acceso, una ficha inicial podría contener tres criterios medidos y una condición obligatoria. Todas las cifras de la tabla son ilustrativas y deberán revisarse con quienes conocen el proceso.

La medida de adopción especifica su denominador: no cuenta como «no adoptante» a quien no recibió acceso o apenas tuvo consultas incluidas esa semana. La de calidad mira la sugerencia original, no el texto final corregido por el agente; de otro modo, la habilidad humana podría ocultar un rendimiento deficiente de la IA.

La condición de control no se compensa con una buena media de tiempo. Si se usa una sugerencia sin revisar o no está autorizado el tratamiento de los datos, el piloto debe pausarse o limitarse, aunque otras cifras parezcan excelentes. Tampoco «cero errores graves observados» en una muestra demostraría riesgo cero: obliga a examinar los fallos detectados y los límites de lo observado, no a declarar infalible la solución.

Acordar de antemano qué significarán los resultados

Una hipótesis útil termina en una decisión posible, no en un gráfico. Antes de empezar, quienes patrocinan y operan el proceso deberían acordar qué harán si los resultados divergen:

• Continuar hacia la siguiente fase, si se cumplen la meta de tiempo, la calidad y las condiciones de control, y hay uso suficiente para que la comparación tenga sentido.
• Ajustar y volver a medir, si existe interés de los agentes pero la revisión consume el ahorro esperado, o si determinados tipos de consulta concentran los errores.
• Reducir o detener el alcance, si no se pueden usar los datos conforme a las condiciones aprobadas, falla la revisión humana o aparecen errores que hacen inaceptable el riesgo.

Estos no son todavía un calendario de despliegue ni unas pruebas técnicas detalladas. Son reglas para interpretar la evidencia sin cambiar el significado de «éxito» después de ver los números. Si la adopción es baja, por ejemplo, no concluyas automáticamente que el caso carece de valor: quizá los agentes no tuvieron acceso, las consultas elegibles fueron escasas o la sugerencia aparece demasiado tarde. Habrá que distinguir esas explicaciones antes de decidir.

Con las definiciones anteriores, la hipótesis de valor ya contrastable quedaría así:

En las consultas de acceso elegibles, mostrar una clasificación y un resumen sugeridos por IA, siempre sujetos a revisión y corrección humana, reducirá al menos un 15 % la mediana del tiempo de preparación frente a consultas comparables del procedimiento habitual. Consideraremos prometedor el piloto si alcanza esa reducción con uso suficiente, sugerencias de calidad aceptable y todas las condiciones de control cumplidas.

Aún falta confirmar la línea de base, acordar la pauta de calidad y resolver los pendientes de datos, tecnología y gobernanza detectados en la lección anterior. Hasta contar con las autorizaciones correspondientes, esta ficha sirve para planificar la comprobación, no para introducir consultas reales en una herramienta de IA.

Para cerrar

Has pasado de «este caso parece valioso» a una predicción que indica qué tarea debe mejorar, cuánto, para quién y sin sacrificar qué condiciones. Una medida sólida define su población, comparación, fuente, umbral y momento de revisión. Combinar adopción, resultado y calidad evita confundir actividad con beneficio; mantener los controles como condiciones obligatorias evita declarar exitoso un piloto inseguro.

Con esto concluye el módulo de descubrimiento y estrategia. En el siguiente comenzarás a examinar la arquitectura básica de un asistente de IA: entender sus componentes te permitirá comprobar con el equipo técnico cómo podría sostenerse —o no— el flujo que acabas de definir.