Cómo diseñar una matriz de decisiones humanas, asistidas y ejecutadas por IA

Lista decisiones, no tareas genéricas. Observa el proceso y enumera decisiones concretas: clasificar, recomendar, aprobar, modificar o comunicar. Para cada una registra entrada, salida, frecuencia y dueño. Una tarea amplia puede contener decisiones con riesgos muy distintos. Desagregar evita automatizar todo el bloque cuando solo una parte es repetitiva y verificable. La métrica debe conectarse con una consecuencia de negocio: tiempo ahorrado, error evitado, exposición reducida o decisión acelerada. Contar solicitudes, prompts o usuarios no demuestra valor por sí mismo. Medir antes y después permite corregir el sistema y también decidir con serenidad cuándo detener una iniciativa que no funciona.

Puntúa consecuencia e incertidumbre. Puntúa impacto de error, sensibilidad, reversibilidad y variabilidad. Añade calidad de datos y capacidad de detectar un fallo. Una decisión reversible con evidencia clara puede recibir más autonomía; otra con consecuencias legales o humanas necesita asistencia y revisión. Conserva la justificación para que el puntaje no se vuelva una cifra arbitraria. El paso final siempre es confirmar el estado real. Una respuesta exitosa de una herramienta no prueba que el cambio persistió ni que otro sistema lo respetó. El readback debe consultar el destino, comparar identificadores y registrar diferencias. Esa disciplina separa intención de resultado y evita reportes de éxito prematuros.

Elige un modo de operación. Selecciona entre humano, humano asistido, IA con aprobación o IA ejecutora supervisada. Define qué significa cada modo en el sistema. Una etiqueta sin comportamiento no ayuda: especifica si la IA puede guardar, enviar, pagar o solo proponer. Empieza con el modo menos autónomo que todavía permita aprender y ahorrar tiempo. Conviene probar la afirmación con una muestra representativa y documentar lo que queda fuera. Los promedios esconden colas y los casos exitosos esconden condiciones de fallo. Una revisión honesta muestra tanto el resultado esperado como el comportamiento ante datos incompletos, permisos revocados y herramientas temporalmente indisponibles.

Asigna autoridad y evidencia. Nombra quién puede aceptar, cuestionar, anular y detener. Muestra fuente, confianza, diferencias y reglas aplicadas para que la persona tenga evidencia suficiente. Establece plazo y ruta de escalamiento. La responsabilidad debe ir acompañada de permisos reales; nadie debería responder por una decisión que técnicamente no puede modificar. La métrica debe conectarse con una consecuencia de negocio: tiempo ahorrado, error evitado, exposición reducida o decisión acelerada. Contar solicitudes, prompts o usuarios no demuestra valor por sí mismo. Medir antes y después permite corregir el sistema y también decidir con serenidad cuándo detener una iniciativa que no funciona.

Mide trabajo invisible. Registra minutos de revisión, porcentaje de excepciones, correcciones y cambios de contexto. Pregunta a usuarios qué esfuerzo no aparece en los sistemas. Calcula costo por resultado aceptado. Si la supervisión crece, investiga datos, interfaz o alcance en lugar de exigir que el equipo revise más rápido sin cambiar el diseño. El paso final siempre es confirmar el estado real. Una respuesta exitosa de una herramienta no prueba que el cambio persistió ni que otro sistema lo respetó. El readback debe consultar el destino, comparar identificadores y registrar diferencias. Esa disciplina separa intención de resultado y evita reportes de éxito prematuros.

Revisa con datos reales. Después de cuatro semanas compara métricas por tipo de decisión. Amplía solo cuando calidad y carga cumplen umbrales. Reduce autonomía ante regresión o nuevos riesgos. La matriz es un instrumento vivo: cambia con evidencia, modelo y proceso, pero conserva historial para explicar por qué una decisión pasó de humana a asistida o ejecutada. Conviene probar la afirmación con una muestra representativa y documentar lo que queda fuera. Los promedios esconden colas y los casos exitosos esconden condiciones de fallo. Una revisión honesta muestra tanto el resultado esperado como el comportamiento ante datos incompletos, permisos revocados y herramientas temporalmente indisponibles.