Inteligencia práctica para programas de IA responsables.
Descubrimiento de casos de uso de IA
Método práctico para observar flujos reales, contrastar evidencias y decidir si conviene probar IA, otro cambio, investigar más o detenerse.
ModelFold Editorial Team8 min de lectura
Una queja es una pista de investigación, no un caso de uso de IA listo para aprobar. Si un equipo de operaciones dice que preparar fichas de incorporación de clientes demora demasiado, un diagrama dibujado de memoria puede hacer parecer que el problema está en redactar. Al revisar casos terminados, sin embargo, puede aparecer otra historia: las fichas difíciles esperan decisiones comerciales faltantes y se reescriben cuando se resuelven datos contradictorios. Automatizar el resumen visible dejaría intacta la restricción que realmente se repite.
Ideas clave
Antes de observar, hay que fijar un límite revisable para el flujo y una pregunta concreta que la evidencia deba responder. Define qué lo activa, dónde termina, qué resultado produce, quién lo recibe, qué roles participan y qué casos rutinarios o excepcionales importan. En la incorporación de clientes, el límite va desde un traspaso comercial aprobado hasta una ficha aceptada por quien liderará la entrega, incluyendo casos normales, incompletos y con cambio de alcance.
El protocolo es una síntesis práctica, no un paquete metodológico obligatorio. Puede bastar una entrevista de caso reciente y algunos artefactos; un evento intermitente podría requerir un diario, y una duda sobre recurrencia podría justificar revisar registros. Elige la combinación más pequeña que compense los puntos ciegos relevantes. Si la observación revela una decisión previa o una consecuencia posterior que cambia el problema, amplía el límite y deja constancia de por qué se modificó.
Una entrevista de caso reciente revela el flujo cuando reconstruye una instancia terminada, paso a paso, en vez de pedir una explicación genérica. Comienza por el evento que la activó; pregunta qué información llegó, qué ocurrió después, qué decisiones se tomaron, quién recibió cada traspaso, qué resultado fue aceptado y dónde el caso se apartó de lo esperado. Un relato representa una experiencia concreta: contrástalo con otros casos, roles y evidencias antes de inferir un patrón.
Las preguntas deben ser abiertas y neutrales; pedir que la persona diseñe una función de IA durante la reconstrucción desplaza la conversación desde la evidencia hacia una solución imaginada. También conviene indagar señales, necesidades de información y juicios difíciles, no solo clics visibles. Esto toma una idea del análisis cognitivo de tareas, pero no equivale al protocolo ACTA formal. En el ejemplo, compara una ficha rutinaria con otra difícil e incluye coordinación, operaciones comerciales y liderazgo de entrega para cubrir los traspasos.
En el entorno habitual conviene mirar herramientas, documentos, interrupciones, dependencias y decisiones tal como aparecen durante el caso. Registra cambios entre fuentes, verificaciones, esperas, reprocesos, traspasos, soluciones improvisadas e información incompleta o contradictoria. La observación silenciosa conserva mejor el flujo, pero puede ocultar los motivos; las preguntas ocasionales aportan contexto con cierta interrupción, mientras la explicación continua entrega profundidad a costa de modificar más la actividad. Declara el modo elegido en las notas.
La investigación debe presentarse como una revisión del flujo, nunca como evaluación individual. Requiere participación informada, revalidación antes de cualquier nueva grabación, recolección proporcional a la pregunta y acceso controlado a la evidencia. Cuando corresponda, involucra a responsables de privacidad, seguridad, asuntos legales, relaciones laborales, accesibilidad y del dominio; este método no determina cumplimiento normativo. Al terminar, pide a la persona que corrija la reconstrucción. Su confirmación mejora la interpretación, pero una muestra pequeña no representa objetivamente a toda la organización.
Los artefactos, diarios breves y registros operacionales amplían lo que una conversación o una sesión observada no alcanza a mostrar. Pide que expliquen plantillas, planillas, mensajes, borradores, notas y vistas de cola usados en el caso. Sus marcas y disposiciones pueden revelar estado, memoria y coordinación ausentes del mapa oficial, pero su significado siempre debe confirmarse con quien los usa. Tener un documento no demuestra con qué frecuencia ni para qué se ocupa.
Usa diarios cuando el evento ocurre de manera intermitente o fuera de una observación programada: cada entrada debe quedar ligada a una instancia real y aclararse después. Para las fichas, podría registrar el tipo de caso, el insumo faltante, la consulta, la espera, las revisiones y la aceptación, sin imponer una duración universal. Si existen datos utilizables, revisa antigüedad de colas, devoluciones, secuencias y razones registradas. Documenta también aclaraciones realizadas fuera del sistema y no descartes excepciones antes de examinar su esfuerzo y consecuencia.
| Método | Qué puede revelar | Qué puede omitir | Cómo contrastarlo |
|---|---|---|---|
| Entrevista de caso reciente | Secuencia recordada, motivos, incertidumbre y traspasos | Pasos implícitos, frecuencia y detalles olvidados | Pedir demostraciones, artefactos y casos contrastantes |
| Observación contextual | Herramientas, interrupciones, verificaciones y soluciones prácticas | Eventos infrecuentes y motivos no expresados | Hacer preguntas acotadas y validar la reconstrucción |
| Artefactos del flujo | Estado, prioridades, memoria, correcciones y coordinación | Significado, frecuencia y trabajo verbal no registrado | Revisarlos junto con las personas que los usan |
| Diario breve | Instancias distribuidas en el tiempo y contexto cercano | Actividad omitida, recuerdo selectivo y prácticas no reportadas | Aclarar entradas mediante entrevistas o evidencias del caso |
| Registros operacionales | Recurrencia, espera, reproceso, desviaciones y variantes | Trabajo fuera del sistema y razones detrás del evento | Reconciliar con observación, artefactos y participantes |
Un problema reportado se convierte en una hipótesis creíble cuando distintas evidencias ubican una restricción recurrente en un punto definido y la conectan con una consecuencia observable. La intensidad de la molestia no basta, y una marca de tiempo tampoco explica por qué ocurrió el atraso. Aplica seis preguntas como regla editorial de decisión, conservando casos negativos y explicaciones alternativas. El resultado sigue siendo una hipótesis: no es una prueba estadística ni una demostración causal.
En las fichas de incorporación, la hipótesis cambia desde “el resumen es lento” hacia “las decisiones faltantes y los campos contradictorios generan espera y reescritura en casos difíciles”. Las fichas rutinarias se redactan rápido, una mayor extensión no coincide siempre con más demora y los registros no capturan aclaraciones fuera del sistema. Esa contraevidencia impide declarar una causa. Si todavía faltan recurrencia, ubicación o consecuencia, mantén el problema como pista abierta y diseña la prueba más pequeña que distinga explicaciones.
No preguntes dónde encaja la IA hasta mostrar dónde se repite la restricción, qué consecuencia sigue y qué continúa incierto.
Una ficha de oportunidad respaldada por evidencia debe convertir el trabajo de campo en una decisión acotada, sin suponer que la IA ganará. Registra el inicio y término del flujo, resultado, usuario posterior, roles, período observado, tipos de caso y métodos usados. Separa el dolor declarado del patrón observado y vincula cada afirmación sustantiva con notas, artefactos anonimizados, entradas de diario o consultas de registros; si no tiene respaldo, identifícala como supuesto.
La función Map del NIST AI RMF Playbook respalda documentar propósito, usuarios, contexto, valor, limitaciones, impactos, alcance y supervisión, además de considerar alternativas sin IA; es una guía voluntaria, no una certificación. Para las fichas de incorporación, prueba primero campos obligatorios, un responsable explícito del traspaso y una cola visible de excepciones. La asistencia de redacción puede evaluarse después, solo en casos con hechos completos. Propón IA cuando muestre una ventaja comprobable sobre opciones más simples; si la acción posible sigue incierta, investiga más o detente.
Delimita trabajo recurrente por su inicio, término, resultado, roles y tipos de caso. Contrasta casos reales, observación, artefactos o registros hasta ubicar una restricción repetida y una consecuencia observable. Documenta la incertidumbre y compara la IA con alternativas más simples antes de proponer una prueba controlada.
Un punto de dolor es un reporte válido sobre una experiencia problemática. Una oportunidad requiere además una tarea acotada, recurrencia, ubicación dentro del flujo, consecuencia observable, restricciones conocidas y una intervención plausible. La evidencia puede concluir que conviene un cambio sin IA o que aún falta investigar.
Presenta el estudio como investigación del flujo y no como evaluación individual, con participación informada y un modo de observación explícito. Recoge solo la evidencia necesaria, controla el acceso y permite que las personas corrijan la reconstrucción. Involucra a los responsables organizacionales pertinentes cuando haya información personal, confidencial o regulada.
No. Esta combinación es una síntesis práctica, no una lista obligatoria. Elige la mezcla más pequeña que responda la pregunta y compense los puntos ciegos relevantes: por ejemplo, un diario para eventos intermitentes o registros para examinar recurrencia, siempre que los datos sean utilizables.
No. La observación y los registros pueden sostener una hipótesis coherente sobre recurrencia, ubicación y consecuencia, pero no prueban causalidad por sí solos. Conserva casos que contradigan el patrón, anota explicaciones alternativas y ejecuta la prueba discriminante más pequeña antes de afirmar que una intervención funciona.
Este artículo se investigó a partir de las siguientes fuentes:
Contamos cómo aterriza de verdad la IA dentro de una empresa. Partimos de fuentes identificadas, distinguimos lo que encontramos de lo que pensamos y usamos IA como apoyo para investigar y redactar, bajo controles editoriales documentados. No reemplazamos la revisión de un experto.
Método práctico para rediseñar excepciones, aprobaciones y traspasos con evidencia, responsables y controles claros antes de automatizar un flujo.
Método práctico para mapear tareas, probar una configuración de IA y rediseñar roles solo después de medir carga, controles, excepciones y aprendizaje.
Método práctico para asignar decisiones de IA, registrar evidencia y convertir aprendizajes de pilotos en cambios de financiamiento, control y estrategia.
