De una iniciativa de IA ambigua a trabajo ejecutable.

1. Empieza por la decisión, no por la demostración

Un prompt que produce una respuesta llamativa todavía no es un requisito de producto. Empieza por la persona que debe actuar, la decisión que necesita tomar y la consecuencia de equivocarse. Así la iniciativa permanece vinculada a una necesidad operativa y no a una exhibición de tecnología.

Describe el cambio esperado con una afirmación observable. Por ejemplo: una coordinadora recibe un borrador completo con referencias a los registros fuente y puede aprobarlo, corregirlo o rechazarlo antes de que se envíe. Esto es más útil que “usar IA para automatizar el seguimiento”, porque identifica a la persona usuaria, el resultado, el control y el límite.

• ¿Quién tiene el problema y quién responde por la decisión final?
• ¿Qué ocurre hoy, incluido el trabajo manual y las excepciones?
• ¿Qué debe volverse más rápido, claro, seguro o consistente?
• ¿Qué daño puede producir una salida creíble pero incorrecta?

Pregunta de decisión: si el equipo no puede explicar el cambio sin nombrar un modelo, el problema todavía no está definido con suficiente claridad para construir.

2. Mapea el trabajo actual y su evidencia

Observa el flujo real antes de rediseñarlo. El proceso oficial puede omitir hojas de cálculo, bandejas de entrada, trabajo de copiar y pegar, aprobaciones informales o a la persona que resuelve registros ambiguos. Esos detalles determinan si un paso asistido por IA será confiable en la práctica.

Sigue un caso representativo desde el disparador hasta el resultado de negocio. Registra dónde nace la información, qué sistema gobierna cada dato, quién lo cambia, cómo se resuelven duplicados o conflictos y qué evidencia demuestra que el trabajo terminó. Incluye al menos una excepción; no documentes únicamente el recorrido ideal.

• Disparador: el evento que inicia el trabajo.
• Fuente oficial: el sistema o la persona con autoridad sobre cada dato.
• Transformación: qué se clasifica, resume, genera o enruta.
• Traspaso: quién recibe el resultado y qué necesita para continuar.
• Excepción: qué ocurre cuando faltan datos, se contradicen o llegan tarde.
• Evidencia: el registro que permite verificar el resultado después.

3. Define límites de datos y responsabilidad antes de escoger herramientas

Enumera los datos que el flujo puede usar, los que nunca debe usar y los entornos autorizados para procesarlos. Los registros personales, confidenciales de clientes, laborales, financieros, de salud, credenciales o sensibles para la seguridad requieren un manejo deliberado. No pegues información personal o confidencial en un servicio externo de IA sin que la organización haya aprobado el servicio, el propósito, la retención y el acceso.

Separa la asistencia de la autoridad. El sistema puede redactar, comparar, clasificar o señalar; una persona nombrada o un control determinístico debe conservar las decisiones con impacto material de negocio, legal, financiero, de seguridad o laboral. Define dónde la revisión humana es obligatoria y qué debe poder inspeccionar quien revisa.

• Entradas permitidas y entradas prohibidas.
• Entornos aprobados, reglas de retención y roles de acceso.
• Resultados que exigen revisión humana antes de usarse.
• Acciones que el paso asistido por IA nunca puede ejecutar.
• Responsable con autoridad para pausar el flujo cuando la evidencia sea débil.

Pregunta de límites: ¿alguien del equipo puede explicar adónde va cada dato sensible y quién puede verlo? Si no, detén la selección de herramientas y resuelve primero el recorrido de datos.

4. Define el menor alcance útil de principio a fin

Un alcance pequeño debe llegar a un resultado real. Evita un prototipo aislado que demuestra generación y deja para después la identidad, los permisos, la revisión, la entrega y la recuperación. Elige un grupo de usuarios, un disparador, una salida y un destino controlado para probar el recorrido completo.

Haz que el primer alcance sea reversible. Usa un conjunto limitado de datos, un interruptor claro y una alternativa manual. El objetivo no es ocultar trabajo incompleto, sino aprender con una implementación acotada sin volver dependiente al negocio de un comportamiento que aún no se ha validado.

• Una persona usuaria y un contexto de negocio definidos.
• Un recorrido completo desde el disparador hasta un resultado revisado.
• Casos normales, de borde e inaceptables que representen la realidad.
• Una alternativa manual y una persona responsable de intervenir.
• Un interruptor que no elimine el acceso al trabajo original.

5. Escribe criterios de aceptación alrededor de la evidencia

Los requisitos deben describir lo que se puede observar, no solo lo que el sistema pretende hacer. Incluye el estado de entrada, la acción, el resultado esperado, los permisos, las referencias a fuentes, el comportamiento ante fallas y la evidencia guardada. Que un resultado se vea correcto una vez no demuestra una operación repetible.

Evalúa por separado la calidad del contenido y el comportamiento del sistema. El contenido puede revisarse por integridad, afirmaciones sin soporte, tono y referencias obligatorias. El sistema puede revisarse por autenticación, enrutamiento, duplicados, latencia, auditoría, reintentos e imposibilidad de ejecutar acciones prohibidas.

• Dado un estado conocido, cuando corre el flujo, entonces el resultado y su evidencia son visibles.
• Cuando falta una fuente obligatoria, el sistema se detiene de forma segura y explica la siguiente acción.
• Quien revisa puede rastrear cada resultado material hasta las fuentes aprobadas.
• Un resultado rechazado no continúa de forma silenciosa a otro sistema.
• El equipo puede distinguir incertidumbre del modelo de una falla de integración o permisos.

6. Separa el comportamiento del modelo del comportamiento del sistema

La salida de un modelo puede variar aunque el flujo que la rodea deba permanecer controlado. Coloca reglas determinísticas alrededor de identidad, permisos, campos obligatorios, selección de destinos, movimiento de dinero, comunicación externa y acciones destructivas. Usa el modelo solo donde la variación sea aceptable y revisable.

Prueba el sistema completo cuando el modelo no está disponible, responde lentamente o entrega algo inútil. La persona usuaria debe recibir un estado veraz y una alternativa útil, no un mensaje falso de éxito. Los registros deben identificar la etapa que falló sin exponer prompts o contenido sensible.

• Calidad del modelo: ¿la salida es útil, fundamentada y está dentro del alcance?
• Integridad del flujo: ¿se conservaron el registro, responsable y destino correctos?
• Controles: ¿se mantuvieron los permisos, la revisión y las acciones prohibidas?
• Fallas: ¿se puede recuperar el trabajo sin perderlo ni duplicarlo?

7. Toma una decisión explícita de preparación

Cierra el descubrimiento con una decisión, no con una recomendación vaga de experimentar. La evidencia puede justificar un piloto controlado, otra iteración de diseño, una mejora del flujo sin IA o detener la iniciativa. Cada resultado es válido si responde a la necesidad operativa y al riesgo.

Registra los supuestos abiertos, la persona responsable, la siguiente prueba y la fecha de vencimiento de la decisión. Esto evita que un piloto se convierta silenciosamente en producción permanente y deja claro qué debe cumplirse antes de ampliar el alcance.

Pregunta de decisión: ¿están explícitos el problema, los límites, el primer alcance, la evidencia, la alternativa y la persona responsable? Si alguna respuesta es no, la iniciativa todavía no está lista para construir.