La conversación sobre IA suele comenzar por capacidades: resumir, generar, clasificar, predecir o conversar. El negocio, en cambio, necesita resolver esperas, errores, trabajo repetitivo, falta de contexto o decisiones lentas. Traducir una capacidad técnica en un caso de uso requiere empezar por la fricción y diseñar el sistema completo que la rodea.
Describe el trabajo antes de imaginar la solución
Conviene mapear qué inicia el proceso, qué información entra, qué decisión se toma, qué salida se produce y quién responde por ella. También hay que observar excepciones. Los procesos documentados suelen mostrar la ruta ideal; el valor y el riesgo aparecen en los casos que obligan a pedir contexto, corregir datos o escalar a una persona.
Una fricción priorizable tiene frecuencia, costo o impacto. Puede consumir tiempo, crear errores, retrasar una respuesta o degradar experiencia. Si el equipo no puede describir cómo se ve hoy y qué debería mejorar, tampoco podrá evaluar si la IA produjo valor o solo desplazó trabajo hacia revisión y corrección.
La IA crea valor cuando reduce una fricción sin volver invisible el riesgo que introduce.
Separa automatización, asistencia y decisión
No todos los casos necesitan el mismo nivel de autonomía. La IA puede asistir preparando una respuesta, recomendar una acción o ejecutar dentro de límites. Cuanto mayor sea la consecuencia de un error, más importantes son aprobación humana, trazabilidad, controles de acceso y una ruta clara para detener o revertir la acción.
El diseño debe hacer visible qué produjo el sistema, con qué fuentes y qué parte necesita juicio. Una experiencia que oculta incertidumbre puede parecer fluida y crear un riesgo mayor. La calidad no depende solo del modelo: depende de datos, instrucciones, interfaz, responsables, monitoreo y capacidad para gestionar incidentes.
Prioriza por valor, viabilidad y riesgo
Impacto potencial pregunta cuánto tiempo, calidad, capacidad o experiencia podría mejorar. Viabilidad revisa datos, integración, estabilidad del proceso y esfuerzo de adopción. Riesgo considera privacidad, seguridad, sesgo, consecuencias del error y dependencia. Un caso con alto valor y riesgo controlable suele ser mejor punto de partida que una demostración espectacular sin dueño operativo.
El marco de gestión de riesgos de IA de NIST propone incorporar confiabilidad durante diseño, desarrollo, uso y evaluación. En la práctica, eso significa definir responsables, criterios de aceptación, pruebas, monitoreo y respuesta antes de escalar. La gobernanza no llega después del piloto; permite que el piloto produzca evidencia utilizable.
- La fricción y su línea base están documentadas.
- El nivel de autonomía corresponde a la consecuencia del error.
- Datos, responsables y controles existen antes del piloto.
- La evaluación incluye calidad, riesgo y trabajo humano total.
Un piloto debe medir el sistema completo
Velocidad o costo por tarea son señales incompletas. También conviene medir tasa de aceptación, correcciones, escalamiento, errores, satisfacción, cobertura y tiempo humano total. Una respuesta generada en segundos puede ser más cara si exige revisión extensa o provoca retrabajo posterior.
El cierre del piloto debe responder si la fricción disminuyó, para qué casos, bajo qué controles y con qué costo de operación. Después se decide escalar, ajustar o detener. La organización aprende así a incorporar IA como una capacidad gobernada, no como una colección de herramientas que cada equipo prueba por separado.
¿Qué decisión debería seguir perteneciendo a una persona aunque la IA prepare toda la información?
La respuesta ayuda a diseñar límites, interfaz y escalamiento antes de automatizar.