Empieza por un proceso frecuente y valioso, con entradas suficientemente claras, fuentes accesibles, salida verificable e impacto de error controlable. El primer proyecto no debería ser el más espectacular: debería comprar aprendizaje y demostrar una mejora frente a una línea base.
La oportunidad con más “wow” no siempre es la que conviene construir primero. Una buena cartera compara valor, preparación y riesgo con el mismo criterio y premia los casos que pueden demostrar algo útil en pocas semanas.
Copiar datos cinco veces porque dos sistemas no comparten identidad puede ser un problema de integración. Una aprobación que nadie utiliza quizá deba eliminarse. Un informe manual puede resolverse con una consulta determinista.
Automatizar desperdicio sólo hace el desperdicio más rápido. El discovery empieza preguntando qué pasos aportan valor y cuáles son deuda del proceso.
Usa esta matriz como herramienta de conversación. Asigna 0, 1 o 2 a cada dimensión y escribe la evidencia que justifica el número. Un dato desconocido se marca como pendiente; no se rellena con optimismo. La escala es una propuesta editorial para comparar tus candidatos, no un estándar ni una predicción de rentabilidad.
| Criterio | 0 · Sin preparar | 1 · Parcial | 2 · Con evidencia |
|---|---|---|---|
| V · Valor | El beneficio no está definido. | Hay una mejora plausible sin línea base. | Existe una unidad y un registro del problema que se quiere mejorar. |
| F · Frecuencia | No se conoce el volumen. | Hay pocos casos o llegan de forma irregular. | Hay casos suficientes y comparables para evaluar el piloto. |
| P · Preparación | Faltan responsable o fuentes. | Hay responsable, pero quedan entradas o excepciones por aclarar. | Responsable, entrada, fuentes y resultado están definidos. |
| C · Comprobación | Nadie puede decidir si la salida es correcta. | Se puede revisar, con criterios aún incompletos. | Hay criterios de aceptación y casos de prueba contrastables. |
| I · Integración | Faltan acceso autorizado o interfaz necesaria. | Hay acceso viable, con una dependencia pendiente de probar. | Las lecturas y escrituras necesarias se han comprobado en un entorno adecuado. |
| R · Reversibilidad | El error puede salir sin control o ser difícil de revertir. | Hay revisión, pero el tratamiento de excepciones está incompleto. | El piloto tiene límites, revisión y una salida segura ante errores. |
La suma va de 0 a 12 y sirve para ordenar conversaciones entre candidatos parecidos. No autoriza a lanzar. Sin acceso autorizado, sin una persona capaz de aceptar el resultado o con una acción de impacto sin control, el caso se pospone o se reduce aunque sume muchos puntos. Un 12 tampoco demuestra retorno: aún hace falta probar el sistema y calcular su economía.
Conserva junto a cada ficha: proceso y responsable, muestra de entrada, fuente de verdad, salida esperada, volumen observado, tiempo activo actual, criterio de aceptación, excepción conocida y próximo dato que falta. Así la reunión termina con una decisión comprobable, no con seis notas sueltas.
Una tarea de cuatro minutos repetida 2.000 veces al mes puede tener más impacto que un proceso sofisticado trimestral. Pero el volumen no manda solo: una tarea que ocurre diez veces y bloquea una venta de alto valor también puede justificar inversión.
Usa unidades que dirección entienda: horas/mes, retraso, errores, coste externo, capacidad perdida o conversión.
Extraer campos de una factura puede compararse con el documento. Clasificar un ticket puede contrastarse con ejemplos etiquetados. Un buscador puede exigir cita a la fuente. Una escritura en CRM puede confirmarse en el sistema destino.
Cuando nadie sabe definir “bien”, cada demo parece buena hasta que aparece una excepción. Para Phase 1 de un programa de IA, preferimos tareas donde calidad pueda medirse.
Generar un borrador interno y cancelar un pedido no deberían tener la misma autonomía. Cuanto más difícil sea detectar o revertir un error, más pequeño debe ser el perímetro inicial y más importantes los controles.
Esto no excluye procesos sensibles; simplemente evita usarlos como primer laboratorio si todavía no conocemos el comportamiento del sistema.
Una oportunidad aparentemente sencilla puede implicar cinco sistemas, identificadores incompatibles, permisos por rol y una API limitada. Puntúa el caso con la arquitectura que necesita en producción, no con un CSV limpio preparado para una demo.
La calidad de datos y el acceso al sistema destino suelen mover más el calendario que elegir entre dos modelos de lenguaje.
Supuesto ficticio: una empresa compara tres ideas. En este ejercicio se asume que el acceso de lectura del correo comercial ya se ha probado, que la conexión de escritura al ERP aún no está disponible y que no existe un criterio aceptado para una negociación autónoma. Las puntuaciones salen de esas condiciones; no de resultados de clientes ni de una prueba de IA.
| Candidato | V/F/P/C/I/R · Total | Decisión y siguiente comprobación |
|---|---|---|
| Preparar el triaje de correo comercial | 2/2/2/2/2/2 · 12/12 | Candidato a piloto con revisión humana. Contrastar asignación y resumen con correos anonimizados; incluir duplicados y datos insuficientes. |
| Extraer datos de facturas y escribir en ERP | 2/2/1/2/0/1 · 8/12 | Posponer la escritura. Primero comprobar el acceso autorizado al ERP; mientras tanto, valorar extracción revisada sin registrar asientos. |
| Negociar y cancelar pedidos de forma autónoma | 2/1/1/0/1/0 · 5/12 | Reducir el alcance. Preparar una propuesta para aprobación podría ser otro candidato; negociar o cancelar requiere criterios y controles que aquí faltan. |
El segundo caso no pierde porque el ERP sea menos interesante: le falta una dependencia que condiciona el encargo. El tercero cambia de proyecto cuando se limita a preparar borradores. Al cambiar el alcance, vuelve a puntuar la ficha; no arrastres la nota de la versión anterior.
Si triaje y búsqueda interna empataran, comprobaríamos qué incertidumbre despeja cada piloto y cuánto cuesta mantenerlo. La puntuación ayuda a discutir; el acceso, la aceptación y el coste deciden si hay proyecto.
Dentro de un mismo workflow puede haber reglas para validar importes, IA para interpretar un email, una API para consultar el pedido y una persona para aprobar una excepción. No conviertas todo el flujo en “IA” si una parte ya tiene una solución exacta.
La comparación automatización vs agente ayuda a decidir dónde merece autonomía y dónde no.
Triaje de correo, extracción documental, búsqueda interna, preparación de informes, enriquecimiento de CRM, soporte con fuentes y pasos repetitivos de operaciones suelen funcionar bien cuando tienen volumen y una salida comprobable.
La categoría por sí sola no basta. “Atención al cliente” puede ser un gran piloto si responde desde una base controlada o un mal piloto si pretende resolver desde el día uno cualquier incidencia y ejecutar devoluciones.
Cuando hayas delimitado el caso, baja un nivel: copiloto comercial conectado al CRM para preparar trabajo de ventas; extracción de datos de documentos para convertir una entrada documental en campos revisables; o asistente de conocimiento interno cuando el problema es encontrar y contrastar información. Si aún no está claro qué paso sobra, empieza por la optimización del proceso con IA.
Si eliges preparar propuestas comerciales, empieza por delimitar el documento que alguien podrá revisar. El ejemplo de correo a propuesta comercial con IA incluye una ficha por solicitud y un ejercicio de cambios después de una revisión de ejemplo.
Las facturas de proveedores permiten concretar esta comparación por campo, documento y operación. El plan de un piloto de procesamiento de facturas con IA propone revisar duplicados, ambigüedad y confirmación del ERP antes de ampliar. No presupone que toda factura deba registrarse sin revisión.
Elige una unidad estrecha y define qué dato decidirá si amplías. El proyecto debería enseñarte algo sobre calidad, integración, adopción, seguridad o economía que reduzca incertidumbre del siguiente caso.
Después pasa el resultado por el marco de ROI de IA. Si no mejora la métrica acordada, ajustar o detener es una conclusión válida.
Con el candidato elegido, pasa a presupuestar la automatización en 2027: entrada, integración, revisión, pruebas y operación. Si comparas una inversión más amplia, conserva también la visión general de cuánto cuesta implementar IA en una empresa. Son decisiones distintas: elegir el primer proceso no equivale a presupuestar todo el programa.
Si el primer candidato pertenece al equipo de contenidos o campañas, el plan de automatización de marketing para 2027 desarrolla la implantación por entregas y una simulación editorial con seis solicitudes ficticias.
Respuestas directas para convertir la pregunta en una decisión de proyecto.
Uno con impacto suficiente, frecuencia o alto valor, datos accesibles, resultado verificable y riesgo controlable.
No. También pesan valor por caso, preparación, integración, facilidad de validación y coste del error.
Primero conviene eliminar pasos innecesarios, aclarar responsabilidades y resolver problemas estructurales. Automatizar un proceso roto puede amplificarlo.
Correo, documentos, búsqueda interna, reporting, CRM y soporte pueden encajar bien cuando el flujo está definido y la salida puede comprobarse.
No. A menudo el mejor piloto automatiza uno o dos pasos y mantiene excepciones o decisiones sensibles bajo control humano.
Con una línea base y una métrica definida antes de construir: tiempo, errores, capacidad, coste, calidad o resultado de negocio.
Las ponemos en la misma matriz de valor, preparación y riesgo para elegir un primer caso que pueda demostrar algo de verdad.