Recommended resources
The freely available resources this lesson will direct you to.
Hola. En la lección anterior segmentaste a quienes intervienen en las consultas de acceso según su tarea, contexto, necesidades y barreras. Ahora toca tomar una decisión: entre varias oportunidades detectadas en ese flujo, ¿cuál merece investigarse primero como caso de uso de IA? Que una idea resulte atractiva no basta; también debe aportar valor a quienes la usarán, poder ejecutarse en condiciones reales y mantener sus riesgos bajo control.
En unos 40 minutos construirás una priorización provisional que puedas explicar a un cliente: qué opción estudiar primero, cuáles requieren más información y qué condiciones impedirían avanzar. No se trata todavía de aprobar un despliegue.
Antes de puntuar: definir qué solución compite
Un caso de uso describe una tarea, las personas que intervienen y la ayuda concreta que se propone. «Aplicar IA a las consultas» es demasiado amplio para compararlo con nada. En cambio, «clasificar y resumir consultas de acceso para que un agente de oficina revise el resultado antes de responder» delimita qué hará la herramienta y dónde permanece la decisión humana.
Conviene comparar también la solución propuesta con una alternativa sin IA generativa. Si el problema consiste únicamente en enviar cada consulta a un equipo según un campo del formulario, unas reglas pueden resultar más fiables y baratas. La pregunta inicial no es «¿dónde ponemos IA?», sino «¿qué forma de resolver esta tarea justifica su coste y sus riesgos?».
Select the right AI use case for your business
En «Select the right AI use case for your business», IBM Technology explica por qué la elección de tecnología debe partir del problema, no de la popularidad de la IA generativa.
Mira el ajuste entre problema y solución: presta atención al coste de escoger IA generativa cuando existe una alternativa adecuada. Después, en los cuatro factores, identifica las preguntas sobre necesidad, capacidades, integración y conocimientos del equipo. Úsalas como filtro previo a la puntuación, no como prueba de que una tecnología concreta sea la correcta.
Este filtro ayuda a formular candidatos comparables. Para nuestro flujo hipotético, consideraremos tres: asistencia para clasificar y resumir consultas; un sistema que responde y modifica permisos sin aprobación humana; y ayuda para localizar y redactar respuestas a preguntas frecuentes, que un especialista revisaría. Los tres pretenden mejorar la atención, pero no exigen los mismos datos, autorizaciones ni cambios de trabajo.
Valor, viabilidad y riesgo responden a preguntas distintas
Una priorización útil separa tres perspectivas que pueden entrar en tensión.
Valor pregunta si merece la pena resolver el problema. Incluye el impacto en un objetivo del cliente —por ejemplo, reducir demoras sin aumentar errores— y el beneficio que perciben las personas usuarias. Un gran ahorro teórico no vale mucho si la herramienta añade pasos a quien atiende cada caso.
Viabilidad pregunta si puede construirse, incorporarse y mantenerse con los datos, sistemas, tiempo y capacidades disponibles. La disposición de los usuarios también cuenta: una función técnicamente accesible puede ser inviable en la práctica si exige una revisión imposible durante la jornada.
Riesgo pregunta qué podría salir mal, a quién perjudicaría y qué controles permitirían reducirlo. No es solo una dificultad de implementación. Una respuesta incorrecta sobre una pregunta frecuente y un cambio indebido de permisos pueden tener consecuencias muy diferentes, aunque ambos sean errores de IA.
La lectura siguiente organiza la evaluación en negocio, experiencia y tecnología. Fue escrita pensando en decisiones de desarrollo de aplicaciones; aquí la usaremos para una decisión de adopción en un cliente, sin asumir que ingresos o monetización sean siempre el objetivo principal.
Evaluate and Prioritize an AI Use Case with Business ...
Lee el marco Business, Experience, Technology de Microsoft Learn para distinguir el valor para la organización, la utilidad para las personas y la posibilidad de operar la solución con seguridad.
En «Apply the Business, Experience, Technology Framework», recorre estas tres partes y omite las figuras de puntuación de los ejemplos. En «Business», lee negocio y plazos, hasta justo antes de «Example Use Cases Business Evaluation»; céntrate en alineación, beneficio y tiempo de cambio. En «Experience», lee necesidad y adopción, hasta antes de «Example Use Cases Experience Evaluation». En «Technology», lee riesgos y salvaguardas, hasta antes de «Example Use Cases Technology Evaluation». Pregúntate en cada parte qué evidencia podrías solicitar al cliente y qué seguiría siendo una suposición.
La plantilla de la lectura reúne esas preguntas. Observa que no solicita solamente una nota: pide describir la estrategia, las personas beneficiadas, la resistencia posible, los riesgos operativos, las salvaguardas y el encaje de la IA. La explicación de una nota importa más que su decimal.
Comparar candidatos sin ocultar las incertidumbres
Podemos emplear una escala sencilla de 1 a 5, donde 1 significa encaje bajo y 5, alto. Para no sumar conceptos incompatibles, anotaremos por separado el riesgo residual: el que permanecería después de aplicar los controles propuestos. Ahí 5 significa riesgo alto. Una nota provisional debe ir acompañada de la evidencia disponible y de la condición que falta comprobar.
Esta comparación es ilustrativa, no una evaluación de un cliente real. Supone que existen consultas documentadas y agentes capaces de revisar resultados; ambas suposiciones tendrían que verificarse.
| Candidato | Valor para el negocio y usuarios | Viabilidad | Riesgo residual estimado | Qué falta comprobar |
|---|---|---|---|---|
| A. Clasificar y resumir consultas de acceso, con revisión del agente | 4/5. Podría ahorrar lectura y preparación en una tarea frecuente; el agente conserva el caso original. | 4/5, provisional. La tarea está acotada, pero exige acceso autorizado a los tickets y una integración utilizable. | 2/5, solo si se limitan los datos expuestos, se comprueba la calidad de los resúmenes y la revisión humana es efectiva. | Frecuencia de casos útiles, omisiones relevantes, permisos de acceso y tiempo real de revisión. |
| B. Responder y modificar permisos automáticamente | 5/5, potencial. La automatización completa podría eliminar más pasos si funcionase correctamente. | 2/5. Requiere decisiones fiables sobre excepciones, integración para efectuar cambios y supervisión estricta. | 5/5 por ahora. Un error podría conceder o retirar acceso indebidamente; no hay controles suficientes definidos. | Quién autoriza cambios, qué excepciones existen y si alguna parte puede siquiera automatizarse de forma segura. |
| C. Ayudar a localizar información y redactar respuestas frecuentes, con revisión de un especialista | 3/5. Beneficio más limitado si estas consultas son poco frecuentes. | 4/5, provisional. Podría acotarse a documentación autorizada, si está vigente y es accesible. | 2/5, condicionado a mostrar la fuente y evitar respuestas no verificadas. | Volumen de preguntas, calidad de las fuentes y utilidad frente a una búsqueda convencional. |
Estas notas no son mediciones. Expresan una hipótesis comparable. La opción B ilustra por qué no conviene elegir simplemente el mayor valor potencial: sin autorizaciones y salvaguardas claras, su riesgo impide recomendar un piloto operativo, por alta que sea su promesa. La opción A parece una mejor primera candidata si se confirman sus condiciones. La C puede mantenerse como alternativa si las consultas frecuentes resultan ser un problema relevante o si A tropieza con limitaciones de acceso a los tickets.
También importa a qué segmento se refiere cada nota. La viabilidad de A podría ser relativamente alta para agentes de oficina que revisan tickets en ordenador y baja para personal que solo dispone de breves consultas desde el móvil. Promediar ambas situaciones ocultaría una decisión importante: quizá el primer alcance deba limitarse a un segmento, no descartarse ni extenderse a todos.
La matriz orienta; los riesgos ponen límites
Una matriz permite comunicar la comparación sin reducirla a «ganador y perdedores». La propuesta de Microsoft Learn sitúa en un eje el impacto estratégico y de negocio y en otro el encaje de ejecución, que combina deseabilidad para los usuarios y factibilidad técnica. Sirve para decidir qué acelerar, investigar o replantear.
Evaluate and Prioritize an AI Use Case with Business ...
Vuelve al mismo artículo de Microsoft Learn para ver cómo transforma las valoraciones anteriores en una conversación sobre prioridades.
En «Evaluate the Viability of Your Use Case», lee los dos ejes, desde el primer párrafo hasta antes de «Example Scenarios: Use Case Prioritization». En «Example Scenarios: Use Case Prioritization», localiza la tabla desde la fila «Strategic fit» hasta «Degree of executional fit»; lee la comparación para observar cómo se obtienen las posiciones. No interpretes la posición como autorización automática para desplegar: la matriz resume puntuaciones, pero no sustituye la revisión de riesgos.
En nuestro ejemplo, A sería candidato a preparar una exploración acotada, no a lanzarse directamente a producción. B requiere detener la propuesta de automatización completa mientras no se aclaren las autorizaciones y los controles. C merece investigar el volumen y la calidad de la documentación antes de invertir. Son decisiones diferentes, aunque las tres ideas hayan nacido del mismo flujo de trabajo.
Para que la recomendación pueda defenderse ante dirección, usuarios y equipo técnico, déjala escrita en cinco elementos:
- Alcance: tarea, segmento y grado de autonomía propuesto.
- Valor esperado: qué problema resolvería y para quién, sin presentar estimaciones como resultados obtenidos.
- Viabilidad: datos, integración, tiempo de cambio y capacidad de revisión necesarios.
- Riesgos y condiciones de avance: qué controles deben existir y quién debe confirmarlos; un riesgo grave no se «compensa» con una media alta.
- Incertidumbre decisiva: qué evidencia podría cambiar el orden de prioridad.
Así, priorizar significa escoger dónde merece la pena aprender primero, conservando la posibilidad de rectificar. Si resulta que clasificar tickets con reglas resuelve gran parte del problema, la propuesta de IA deberá justificar qué valor adicional aporta. Y si los resúmenes omiten información crítica, la nota de viabilidad de A tendrá que bajar, no protegerse porque el proyecto ya parecía prometedor.
Para cerrar
Una buena priorización combina valor para el negocio y las personas usuarias, viabilidad real y riesgos controlables. Compara casos de uso bien delimitados, contempla alternativas más simples, registra la evidencia detrás de cada valoración y establece límites de seguridad que ninguna puntuación pueda anular. Para el flujo hipotético de consultas, la asistencia con revisión humana es la primera opción que investigaríamos; no una aprobación anticipada.
En la próxima lección identificarás a patrocinadores, responsables, influenciadores y usuarios en un mapa de grupos de interés. Ese mapa ayudará a saber quién debe aportar la evidencia pendiente y quién puede decidir si una propuesta avanza.