El primer proyecto de IA de una empresa decide mucho más que ese proyecto: decide si la organización se cree la tecnología o la archiva como moda cara. Un piloto bien elegido y bien medido abre la puerta a años de mejora; un piloto ambicioso y difuso produce la frase más cara del sector: "eso ya lo probamos y no funcionó". La diferencia entre ambos casi nunca está en la tecnología —que es la misma— sino en tres decisiones que se toman antes de escribir una línea de código: qué proceso, qué métrica y qué equipo.
Esta guía recorre esas decisiones en orden: cómo elegir el proceso adecuado, cómo definir el éxito antes de empezar, qué equipo mínimo necesitas de tu lado, qué calendario es realista para un piloto y qué hacer después según el resultado. Es, condensado, el método que aplicamos en cada proyecto.
Cómo elegir el proceso para tu primer proyecto de IA
La tentación habitual es empezar por lo más vistoso o por lo más grande. Error en ambos casos. El proceso candidato ideal cumple tres condiciones a la vez, y las tres son obligatorias:
- Doloroso: consume horas visibles, genera errores o cuellos de botella, y el equipo se queja de él espontáneamente. Si nadie sufre el proceso, nadie celebrará su mejora ni colaborará en ella.
- Medible: puedes expresar su coste actual en un número —horas por semana, días de ciclo, porcentaje de errores, euros de retrabajo—. Sin línea base no habrá forma de demostrar la mejora, y un piloto que no demuestra es un piloto que fracasa aunque funcione.
- Con datos digitales: la información que el proceso necesita ya existe en formato accesible (correos, PDFs, ERP, CRM, hojas de cálculo). Si antes hay que digitalizar un archivo en papel o limpiar tres años de datos corruptos, ese es otro proyecto —previo— como explicamos en cómo preparar los datos de tu empresa para la IA.
Dos filtros adicionales que ahorran disgustos: elige un proceso con reglas mayormente claras (las excepciones existen, pero son minoría identificable) y de riesgo acotado: que un error del sistema en las primeras semanas sea corregible y barato, no una factura mal emitida a tu mejor cliente. Para inspiración concreta, en procesos automatizables con IA recorremos los candidatos típicos por departamento.
Un truco práctico: haz la lista de los 5 procesos más quejados de tu empresa, puntúa cada uno de 1 a 5 en dolor, medibilidad y datos, y multiplica. El ganador suele ser evidente. Y suele ser aburrido: procesar documentos, responder consultas repetitivas, conciliar datos entre sistemas. Perfecto: los pilotos aburridos son los que salen bien.
Define el éxito ANTES de empezar, o lo discutirás después
La causa número uno de pilotos zombis —esos que ni triunfan ni mueren— es no haber pactado qué significa éxito antes de arrancar. Sin criterio previo, el resultado se evalúa por sensaciones, y las sensaciones siempre encuentran motivos para el "ni fu ni fa".
La definición de éxito tiene tres componentes, todos escritos y pactados antes del arranque:
- La métrica: una, principal, de negocio. "Reducir el tiempo de respuesta a presupuestos de 3 días a 4 horas". "Procesar el 85 % de las facturas sin intervención humana". No cinco métricas: una que mande y las demás de control.
- La línea base: el valor actual, medido, no estimado de memoria. Dedica una o dos semanas a medir el proceso tal como es hoy. Es la parte menos glamurosa y la más rentable del proyecto.
- El umbral de decisión: qué número convierte el piloto en despliegue ("si supera el 70 % de automatización con menos de 2 % de error, escalamos") y qué número lo mata. Pactar el criterio de muerte por adelantado es lo que te permite matar rápido y barato, que es el segundo mejor resultado posible de un piloto.
Este trabajo previo es también tu vacuna contra los errores clásicos al implantar IA: la mayoría de ellos se incuban precisamente aquí, antes de empezar.
El equipo mínimo del lado del cliente
Ningún proveedor puede sacar adelante un piloto solo, por bueno que sea. Del lado de tu empresa hacen falta tres papeles —que en una pyme pueden ser dos personas, pero nunca cero:
- Un sponsor con poder de decisión: alguien de dirección que quiere el resultado, desbloquea accesos y decide en días, no en comités mensuales. Dedicación real: 1-2 horas por semana.
- Un dueño del proceso: la persona que hace hoy el trabajo y se conoce las excepciones que no están escritas en ningún manual. Es quien valida que el agente hace las cosas bien. Dedicación: 3-5 horas semanales durante el piloto. Es el papel más crítico y el que más se escatima.
- Un contacto técnico: quien da accesos a los sistemas (ERP, correo, CRM) y responde dudas de integración. Puede ser tu informático interno o tu proveedor IT habitual. Dedicación: puntual, concentrada al principio.
Si no puedes liberar esas horas, no tienes un problema de IA: tienes un problema de prioridades, y el piloto debe esperar. Un proyecto sin dueño del proceso disponible produce un agente que funciona en la demo y fracasa en el caso real número 40.
Calendario realista de un piloto: 4-8 semanas
Un piloto que dura seis meses no es un piloto: es un proyecto sin criterio de salida. El calendario sano para un primer proyecto de IA bien acotado:
- Semanas 1-2 — Medición y diseño: línea base del proceso, catálogo de casos y excepciones, definición de éxito firmada, accesos técnicos resueltos.
- Semanas 3-5 — Construcción e iteración: el agente se monta y empieza a trabajar en paralelo al proceso real (shadow mode): hace el trabajo, una persona lo revisa todo, los fallos alimentan la mejora.
- Semanas 6-7 — Operación supervisada: el agente pasa a producción sobre el flujo real con supervisión decreciente; se mide contra la línea base.
- Semana 8 — Decisión: los números sobre la mesa, contra el umbral pactado. Escalar, ajustar o cerrar.
Si el alcance no cabe en 8 semanas, el problema es el alcance: recórtalo hasta que quepa.
Qué hacer después del piloto, según el resultado
El piloto termina con una de tres salidas, y las tres tienen guion. Si superó el umbral: despliega al 100 % del proceso, formaliza la supervisión (quién revisa excepciones y con qué cadencia) y elige el segundo proceso — que ahora será más fácil, porque ya tienes método, accesos y credibilidad interna. Si se quedó cerca: identifica si el déficit es de datos, de reglas mal capturadas o de casos raros; ajusta una vez, con plazo cerrado (2-3 semanas), y vuelve a medir. Una vez, no cinco. Si falló claramente: ciérralo, documenta por qué —casi siempre la lección es sobre tus datos o tus procesos, y vale dinero— y aplica lo aprendido al siguiente candidato de tu lista. Un piloto muerto en 8 semanas con lección aprendida es infinitamente mejor que uno zombi de 18 meses.
Conclusión
Un primer proyecto de IA sale bien cuando se decide bien antes de empezar: un proceso doloroso, medible y con datos digitales; una definición de éxito escrita con línea base y umbral; un equipo mínimo real del lado del cliente; y un calendario de 4-8 semanas con decisión al final. Nada de esto es tecnología: es método. La tecnología, hoy, es la parte fácil.
Si estás eligiendo tu primer proceso y quieres una segunda opinión con números, en MG Solutions ofrecemos un diagnóstico gratuito y sin compromiso: evaluamos tus candidatos, medimos el potencial de cada uno y te proponemos por dónde empezar. Así es exactamente nuestro proceso.