Para elegir un primer proyecto de IA, buscaría una tarea frecuente, con material disponible, un resultado fácil de revisar y consecuencias limitadas si sale mal. Después compararía el trabajo actual con una prueba pequeña, contando también el tiempo de preparar los datos y corregir la respuesta.
La pregunta útil es «¿qué tarea merece una prueba?». Elegir primero una herramienta puede dejarte buscando dónde encajarla. Esta guía propone una matriz para comparar oportunidades y una ficha para decidir si continuar, ajustar o parar.
1. Describir tareas, entradas y resultados
Reúne a las personas que hacen el trabajo y pide ejemplos recientes. «Mejorar ventas» es demasiado amplio. «Preparar un borrador de respuesta a consultas que llegan por correo» tiene una entrada, una salida y alguien que puede revisar la calidad.
Para cada tarea anotaría quién la hace, cuántas veces se repite, qué documentos necesita, dónde se atasca y qué significa hacerla bien. Evitaría estimaciones generales como «nos ocupa muchísimo»: es mejor observar unas pocas ejecuciones y dejar claro que esa muestra puede no representar todos los casos.
También preguntaría si el problema se puede resolver con una plantilla, una regla o una mejora del proceso. Si toda la decisión depende de un campo fijo, una automatización convencional podría ser suficiente. La IA tiene que justificar su presencia en la prueba.
2. Aplicar un filtro antes de puntuar
Hay cuatro preguntas que resolvería antes de comparar ahorro o frecuencia:
- ¿Tenemos permiso para utilizar la información en el entorno previsto?
- ¿Hay una persona responsable que pueda valorar el resultado?
- ¿Podemos probar sin enviar, cobrar, borrar o modificar información de terceros automáticamente?
- ¿Sabemos volver al procedimiento anterior si la prueba falla?
Una respuesta pendiente no demuestra que el proyecto sea inviable. Sí indica que todavía no está preparado para empezar. Un total alto en una matriz no compensa una duda sobre los datos o la ausencia de alguien que revise.
El marco de riesgos de IA de NIST es una referencia voluntaria para incorporar estas consideraciones al diseño, uso y evaluación. La ficha de esta guía es una herramienta sencilla de trabajo, no una implementación completa de ese marco.
3. Comparar lo que realmente cambia la decisión
Propongo comparar cinco aspectos y escribir una evidencia para cada uno. No hace falta sumar puntos: una diferencia importante puede ser más útil que una puntuación aparentemente precisa.
| Aspecto | Qué observar | Buena señal para empezar |
|---|---|---|
| Frecuencia | Cuántas veces se hace. | Se puede repetir durante la prueba. |
| Material | Qué información necesita. | Existe, está ordenada y puede usarse. |
| Revisión | Cómo detectar un error. | El responsable puede contrastar la salida con una fuente. |
| Integración | Qué sistemas hay que conectar. | Se puede aprender algo antes de construir una conexión compleja. |
| Resultado | Qué mejora se espera. | Se puede observar calidad, tiempo o retrabajo. |
En un ejemplo hipotético, preparar un borrador de seguimiento comercial podría permitir una prueba manual: notas autorizadas, una salida en texto y revisión antes del envío. Cambiar automáticamente precios en un catálogo añadiría permisos, reglas comerciales y consecuencias externas. No son dos pruebas equivalentes aunque ambas utilicen IA.
AWS recomienda comenzar por un problema concreto y establecer una línea base de indicadores antes de valorar un piloto. Su guía de selección de casos de uso, en la página 4 del PDF, sirve como referencia para ese enfoque. La matriz anterior es mi propuesta para preparar la conversación, no una herramienta oficial de AWS.
4. Contar el trabajo completo: un ejemplo que obliga a revisar la idea
Imagina una tarea que se hace 40 veces por semana y tarda 12 minutos. Son 480 minutos semanales. Estos números son un ejemplo didáctico, no resultados de un cliente.
En la prueba, preparar la entrada, generar el borrador y revisarlo ocupa 8 minutos por caso. Eso suma 320 minutos. Si además hacen falta 90 minutos semanales para mantener instrucciones y resolver incidencias, el total es 410 minutos. La diferencia respecto al proceso anterior es de 70 minutos a la semana.
Ahora imagina que revisar cada caso resulta más difícil y el tiempo por tarea sube a 10 minutos. El total pasa a 490 minutos, incluyendo el mantenimiento. En ese escenario, la prueba consume 10 minutos más que el procedimiento anterior.
La cuenta ayuda a decidir qué observar. No mide todo el valor ni equivale a un retorno financiero: faltan costes de herramientas, implantación y cualquier cambio en calidad. Tampoco todo tiempo liberado se convierte automáticamente en ahorro de dinero.
Registraría por separado preparación, generación, revisión y correcciones. Si solo se mide cuánto tarda el modelo en responder, queda fuera una parte importante del trabajo que hace el equipo.
5. Escribir la condición para continuar antes de empezar
La ficha del piloto debería incluir una tarea, un responsable, material autorizado, casos de prueba, duración acordada y criterios de decisión. La muestra necesita casos habituales y excepciones que podrían hacer fallar el procedimiento.
Para el borrador de seguimiento, propondría comprobar si respeta las notas, señala lo que falta y evita inventar compromisos. El equipo decide qué errores son tolerables en un borrador y cuáles obligan a detener la prueba. Esa decisión no debería quedar escondida detrás de una media de tiempo.
- Continuar: cumple el criterio de calidad y hay una mejora suficiente para justificar el siguiente paso.
- Ajustar: hay utilidad, pero las entradas, las instrucciones o la revisión necesitan cambios.
- Parar: el coste, los errores o las restricciones impiden aprovecharlo en este momento.
Parar una prueba también es una decisión válida. Permite evitar una integración mayor y guardar lo aprendido para otra tarea.
Qué hacer después del diagnóstico
Si el principal bloqueo es que el equipo necesita aprender a dar contexto y revisar respuestas, el siguiente paso puede ser una formación práctica. Si hace falta conectar sistemas o desarrollar una solución, conviene definir ese alcance por separado. En Apogeo puedes explorar esa línea de implementación.
Si todavía estás comparando oportunidades, puedes descargar la matriz y completar dos o tres tareas. En mi asesoría en IA para empresas podemos revisarlas juntos y concretar una prueba. Me sirve más un ejemplo de cómo trabajáis hoy que una lista de herramientas que queréis incorporar.
Una plantilla para trabajar
Descargar la matriz del piloto
Sin registro. Puedes adaptarla y compartirla con atribución.