Muchas empresas llegan a la IA con una lista larga de ideas: contestar emails, resumir reuniones, clasificar tickets, revisar documentos, preparar ofertas, actualizar el CRM, leer facturas, ordenar incidencias, buscar información interna. Todo parece automatizable. Ese es justo el problema.
Cuando todo parece candidato, el primer piloto se decide por intuición, por la herramienta que alguien ha probado o por la tarea que más ruido hace esa semana. A veces sale bien. Bastantes veces acaba en una demo curiosa que nadie usa después.
Para una empresa de Donostia - San Sebastián, Gipuzkoa o Euskadi, suele funcionar mejor un paso menos vistoso: hacer inventario. Poner las tareas candidatas en una tabla, puntuar volumen, datos, riesgo, revisión humana e integración, y elegir el primer piloto con un criterio que dirección, negocio e IT puedan defender.
Al final tienes un PDF descargable con una plantilla básica para trabajar este inventario con tu equipo.
El error: empezar por la herramienta
La conversación suele arrancar así: “hemos visto una herramienta que automatiza esto”. Es normal. Las demos son rápidas y se entienden bien. Pero una herramienta no arregla una tarea mal definida.
Antes de elegir modelo, agente, RAG, CRM, Zapier, Make, n8n o cualquier conector, conviene saber qué proceso duele, cuánto se repite y qué pasa si la automatización falla. No es burocracia. Es ahorrar vueltas.
Un ejemplo sencillo: leer emails entrantes y preparar respuesta. Puede ser un buen piloto si los mensajes son parecidos, las fuentes están claras y una persona aprueba antes de enviar. Puede ser un mal piloto si cada email implica condiciones comerciales distintas, datos sensibles, promesas de plazo o decisiones que nadie ha escrito.
La misma tarea cambia mucho según el contexto. Por eso el inventario importa.
Qué debe entrar en el inventario
No hace falta montar un documento enorme. Para empezar, basta con recoger ocho datos por tarea.
- Nombre de la tarea.
- Equipo afectado: ventas, administración, soporte, operaciones, dirección, producción.
- Volumen aproximado: cuántas veces ocurre al mes.
- Tiempo medio actual.
- Entrada: email, PDF, formulario, ticket, llamada, Excel, CRM, ERP, carpeta compartida.
- Datos disponibles y calidad de esos datos.
- Riesgo si la IA se equivoca.
- Revisión humana necesaria antes de actuar.
Con eso ya se ve bastante. Una tarea muy repetida, con entrada clara, riesgo bajo y revisión sencilla puede ser un buen primer piloto. Una tarea con alto impacto legal, datos privados y muchas excepciones quizá merece otro tratamiento, aunque sea muy tentadora.
Cómo puntuar sin engañarse
La puntuación no tiene que ser perfecta. Tiene que obligar a hablar de lo que normalmente se deja para después.
Puedes usar una escala de 1 a 5 para cinco criterios.
- Volumen: cuánto se repite.
- Claridad de datos: si la entrada llega ordenada o hecha un lío.
- Facilidad de revisión: si una persona puede validar el resultado rápido.
- Riesgo: qué coste tiene un error.
- Integración: si se puede probar sin tocar media empresa.
Aquí hay una trampa habitual: sumar todo y elegir el número más alto. Mejor no. El riesgo debe leerse al revés. Si el riesgo es alto, el piloto no queda descartado, pero cambia el diseño. Quizá la IA solo prepara un borrador. Quizá no escribe en ningún sistema. Quizá se prueba primero con datos históricos.
Tres buenos primeros pilotos
En pymes de Gipuzkoa suelen aparecer tres candidatos razonables.
Clasificación de solicitudes entrantes. La IA lee formularios, emails o tickets, resume el caso, propone categoría y marca qué falta. Una persona revisa antes de responder o asignar.
Borradores con fuentes aprobadas. El sistema prepara respuestas usando FAQs, documentación pública, procedimientos o políticas internas. No envía nada solo al principio.
Extracción de datos de documentos repetidos. Facturas, albaranes, pedidos, partes, fichas o PDFs parecidos. La IA extrae campos y deja una tabla para validar.
No son los casos más llamativos. Mejor. Los primeros pilotos buenos suelen ser aburridos, medibles y fáciles de acotar.
Qué no pondría en el primer piloto
También conviene decirlo claro. Yo no empezaría por automatizaciones que toman decisiones irreversibles, prometen precios o plazos, modifican datos críticos del ERP, envían comunicaciones sensibles sin revisión o mezclan datos de clientes con fuentes poco controladas.
Eso no significa que nunca puedan automatizarse. Significa que no son el mejor sitio para aprender. Primero conviene construir confianza con una tarea donde el equipo vea ahorro de tiempo sin perder control.
Descarga el how-to básico
Descarga el how-to básico
PDF breve para listar tareas candidatas, puntuar volumen, datos, riesgo, revisión humana y decidir qué piloto de IA merece empezar primero.
Cómo puede ayudar Umintia
En Umintia ayudamos a empresas de Donostia - San Sebastián, Gipuzkoa y Euskadi a elegir el primer piloto de IA sin convertirlo en una apuesta a ciegas: inventario de procesos, datos disponibles, riesgos, revisión humana, integración y métrica de retorno.
Si tienes diez ideas encima de la mesa, probablemente no necesitas otra demo. Necesitas decidir cuál merece las próximas cuatro semanas.