Describe el trabajo antes de elegir tecnología
Escribe qué sucede hoy: quién recibe la tarea, qué información consulta, qué decisión toma y qué entrega. Localiza el atasco observable. «Queremos usar agentes» describe una preferencia tecnológica; «el equipo necesita reunir información dispersa antes de contestar una solicitud» identifica una tarea que se puede investigar.
Observa ejemplos del trabajo y conversa con quien lo realiza. Diferencia tiempo de ejecución, tiempo de espera y tiempo dedicado a corregir errores. Una automatización puede reducir una tarea sin resolver una demora causada por falta de autorización o por información que todavía no existe.
Compara oportunidades con criterios visibles
Puedes construir una tabla sencilla para comparar tareas. No hace falta convertirla en una puntuación aparentemente precisa: registra qué sabes y qué debes comprobar. El marco AI RMF de NIST sitúa el contexto de uso, las personas afectadas y los riesgos entre las cuestiones que deben definirse al trabajar con IA.
- Frecuencia: con qué regularidad ocurre la tarea y cuánto varían sus entradas.
- Información: si existen datos suficientes, actualizados y utilizables para ese propósito.
- Verificación: quién puede distinguir un resultado válido de uno incorrecto.
- Consecuencias: qué sucede si la solución interpreta mal un caso o realiza una acción equivocada.
- Continuidad: quién mantendrá el proceso y cómo seguirá funcionando cuando haya una incidencia.
Ejemplo didáctico: preparar respuestas a consultas internas
Imagina que el personal pregunta por procedimientos repartidos entre varios manuales. Una primera versión podría localizar referencias y preparar un borrador para revisión. El alcance inicial excluiría cambios en sistemas y respuestas sobre documentación no disponible. Es un ejemplo para delimitar trabajo, no un caso real ni una promesa de ahorro.
Antes de construirlo, comprueba si organizar los manuales y mejorar su búsqueda ya resuelve la necesidad. Si sigue siendo útil resumir o combinar información, prueba esa aportación con preguntas representativas. La decisión de incorporar generación debe apoyarse en lo que añade a esa tarea concreta.
Convierte la idea en un piloto comprobable
Define el inicio y el final del recorrido, un conjunto de entradas de prueba y la salida esperada. Añade casos en los que falte información o el sistema deba pedir ayuda. Separa funciones imprescindibles de mejoras que pueden esperar y acuerda qué persona puede aprobar el resultado.
Escribe los límites antes de probar: documentos autorizados, acciones permitidas, condiciones de revisión y forma de volver al proceso manual. Anota también las dependencias externas. Tener acceso a una herramienta no demuestra que tengas acceso a los datos o permisos que necesita el proyecto.
Decide qué aprender antes de ampliar
El piloto debería resolver una incertidumbre concreta: si se recupera información adecuada, si el borrador ahorra revisión o si las entradas pueden clasificarse con utilidad suficiente. Acuerda de antemano cómo distinguir avanzar, corregir y detener. El umbral depende del uso y de la gravedad de sus errores.
Documenta resultados y excepciones sin convertir una demostración satisfactoria en una conclusión sobre todo el negocio. Con esa evidencia puedes elegir herramientas y estimar el retorno. Si todavía no sabes quién revisará la solución o qué problema medirá, resuelve esas preguntas antes de ampliar el alcance.
Fuentes y documentación
Documentación del proveedor o del organismo citado. Los ejemplos de esta ficha son didácticos; no describen resultados de clientes.