Una empresa termina una consultoría de inteligencia artificial y recibe una presentación con veinte oportunidades. Al lunes siguiente, nadie sabe cuál empezar, quién tiene que preparar los datos ni cómo se comprobará que funciona. La lista puede ser interesante, pero todavía falta un plan que permita decidir.
En NorteIA planteamos el Plan Director de IA como un documento de trabajo: debe conectar una dificultad concreta de la empresa con una intervención que tenga responsable, alcance y una forma de comprobar el resultado. Estos son los entregables que proponemos revisar antes de pasar al desarrollo.
1. Un mapa del trabajo tal como ocurre
El organigrama explica quién depende de quién. Para desarrollar un sistema hace falta otra información: qué inicia la tarea, qué documentos se consultan, dónde se copia información y qué excepciones obligan a pedir ayuda.
Por ejemplo, en una empresa de servicios de A Coruña, una solicitud de presupuesto podría pasar del correo a una hoja de cálculo, de ahí al responsable técnico y después a un documento que alguien envía al cliente. Es un ejemplo ilustrativo, no un caso de cliente. El mapa debería identificar esos pasos, sus responsables y los puntos donde se pierde contexto.
2. Una ficha por cada oportunidad
«Automatizar presupuestos» deja demasiadas preguntas abiertas. La ficha debe concretar qué parte se quiere resolver y qué queda bajo decisión humana.
| Campo | Ejemplo de contenido útil |
|---|---|
| Problema observado | La solicitud llega sin los datos necesarios para preparar la propuesta. |
| Intervención | Detectar los datos que faltan y preparar una respuesta para revisión. |
| Datos y accesos | Buzón autorizado, catálogo vigente y plantilla de preguntas. |
| Límite | El sistema no decide descuentos ni envía propuestas sin aprobación. |
| Prueba de aceptación | Reconoce los campos ausentes y remite las solicitudes ambiguas al responsable. |
3. Prioridades que expliquen también qué se aplaza
La primera intervención debería combinar utilidad, datos accesibles y un error manejable. Un proceso muy frecuente puede ser una mala elección si depende de información dispersa o de decisiones que nadie ha documentado.
Conviene distinguir entre actuaciones que pueden empezar, actuaciones que necesitan preparar datos y actuaciones que todavía no compensan. Aplazar una integración debe tener una razón comprobable: falta de acceso, escasa frecuencia, reglas inestables o un coste de revisión superior al trabajo que se pretende ahorrar.
4. Un piloto con principio y final
El piloto necesita un responsable operativo, un conjunto de casos, una referencia del proceso actual y una fecha de revisión acordada. La pregunta de cierre no es si la demostración impresiona: es si el sistema cumple los criterios definidos y qué trabajo sigue requiriendo al equipo.
Incluye casos que deberían fallar de forma controlada: un documento ilegible, una petición duplicada, un dato contradictorio y un servicio no contemplado. Si el sistema los da por buenos, el piloto está revelando un problema que conviene resolver antes de ampliar su uso.
5. Responsabilidad después de la puesta en marcha
El documento debe indicar quién mantiene las conexiones, quién revisa los errores y qué ocurre si cambia una plantilla o deja de responder un proveedor. También debe recoger cómo detener el sistema y volver al procedimiento anterior.
Una buena pregunta para evaluar el plan es esta: si mañana cambia la persona que coordinó la consultoría, ¿el equipo puede entender qué hacer a continuación? Si necesita otra reunión para reconstruir las decisiones básicas, falta información.
Si estás preparando una intervención en tu empresa, puedes empezar por nuestra guía para preparar un proyecto de IA. Trabajamos desde A Coruña con empresas de Galicia para convertir ese diagnóstico en sistemas que se puedan utilizar y mantener.