IA para pymes: por dónde empezar

La pyme española no necesita un “centro de excelencia en IA”. Necesita tres flujos que ahorren horas reales esta temporada y un equipo que sepa usarlos el lunes siguiente. El resto —modelos propios, chatbots públicos sin supervisión, roadmaps de 18 meses— es teatro caro.

En Kit Digital IA (Clutch Developer, Barcelona) arrancamos por el trabajo sucio: tickets, facturas, pedidos, políticas internas. Si no puedes señalar el proceso en una pizarra, no hay proyecto. Si no puedes medir horas o errores en 30 días, el alcance es demasiado grande.

Este artículo es la guía de arranque que entregamos antes de hablar de herramientas: qué falla, qué tres casos sí pagan, cómo elegir el primero, qué dejar fuera y cómo encaja con Kit Digital o Kit Consulting.

Por qué fallan los primeros proyectos de IA

El patrón es siempre el mismo: se compra una herramienta, se hace un taller, y a la semana el equipo vuelve al Excel. Falta un dueño del proceso, falta un “antes/después” numérico y sobra alcance. La IA no sustituye un proceso roto: lo acelera, errores incluidos.

Otro fallo frecuente es empezar por el chatbot de la web. El visitante nota al instante si la respuesta es vaga. Empieza dentro de casa, donde el coste de un fallo es una corrección, no una reseña de Google.

El tercer fallo es tratar la IA como un proyecto de informática en vez de un cambio de hábito. Si nadie tiene dos horas protegidas a la semana para operar el flujo, el piloto muere aunque el modelo sea excelente.

Tres casos con retorno en semanas

• Asistente interno de políticas y FAQ. Manuales, horarios, catálogo y convenios: respuestas que citan la fuente. El equipo deja de buscar en carpetas o de preguntar a la misma persona.
• Borradores de soporte y email. Plantillas con el tono de la casa. Un humano valida y envía. El tiempo por ticket baja; el tono no se diluye.
• Extracción de datos de facturas o pedidos. De PDF a ERP u hoja, con validación de CIF, totales e IVA. El administrativo no teclea: revisa.

Los tres comparten diseño: dato de entrada claro, salida estructurada, humano que confirma, y un interruptor para apagar el automatismo si algo huele mal. Sin eso, no es un proyecto: es una demo.

Un ejemplo de la primera semana

Lunes: eliges “cuando llega un PDF de proveedor, extraemos líneas y las dejamos en borrador”. Mides cuántos PDF entran y minutos por documento. Martes: acotas campos (NIF, fecha, base, IVA, total, número). Miércoles: pruebas veinte documentos reales, no la factura bonita de la demo. Jueves: defines quién valida y qué pasa si el total no cuadra. Viernes: el flujo corre en paralelo al proceso viejo, sin apagar nada.

Si esa semana no puedes escribir la frase del piloto, no estás listo para integrar el ERP. Estás listo para una hoja y una cola. Eso también es un arranque honesto.

Cómo elegir el primer flujo

Cuenta repeticiones. Si alguien hace la misma tarea más de cinco veces al día, es candidata. Si el fallo cuesta dinero o cliente (facturación, plazos, stock), sube de prioridad. Si el dato es sensible y no tienes base legal clara, páralo hasta el inventario RGPD.

Una regla útil: el primer piloto cabe en una frase. Si necesitas un diagrama de dos páginas, recorta. Y no elijas el flujo “más inteligente”: elige el que ya tiene dueño y volumen.

Qué dejar para después

• Modelos entrenados con vuestros datos “porque sí”: caro, lento y casi nunca el cuello de botella.
• Chatbots públicos sin cola humana ni fuentes citadas.
• “Transformación digital” sin un proceso concreto ni un responsable con nombre.
• Integrar doce herramientas a la vez. Primero una, medida, luego la siguiente.
• Comprar asientos para toda la plantilla “para que experimenten”. Eso no es un piloto: es ruido.

Métrica que se puede enseñar en un comité

Horas por semana en la tarea, errores detectados antes de cliente, tiempo de respuesta, y porcentaje de casos que el humano acepta sin reescribir. Si a los 30 días no hay número, o el piloto está mal diseñado o nadie lo usa. Las dos cosas se arreglan: recortando alcance o formando en el propio stack, no en demos genéricos.

Evita indicadores de vanidad: clics en el taller, “satisfacción con la herramienta”, capturas de pantalla. Un comité serio pregunta qué cambió en el trabajo de la semana pasada.

Encaje con Kit Digital y Kit Consulting

Estos arranques encajan en asesoramiento (diagnosticar, priorizar, formar) y en soluciones de digitalización (sitio con captación, gestión, procesos). El programa no pide magia: pide entregables, formación y que el hábito quede en la empresa. Por eso diseñamos el piloto para que el equipo lo opere sin nosotros a la tercera semana.

Si estás midiendo madurez digital o eligiendo agente digitalizador, pide el mismo criterio: inputs, outputs, kill switch, y un número a 30 días. Todo lo demás es catálogo.

Qué hacer esta semana

• Lista tres tareas repetitivas con dueño y volumen semanal.
• Elige una sola. Escribe la frase del piloto y la métrica.
• Decide qué datos toca y si ya tienes base legal.
• Pide una valoración con sector, tamaño y esa tarea — no con un wishlist.

Preguntas frecuentes

¿Hace falta un data scientist en plantilla?

No. Hace falta alguien que conozca el proceso y un proveedor que deje el sistema operable. El científico llega, si acaso, cuando ya hay un flujo midiendo.

¿Empezamos por ChatGPT de pago para todos?

Una licencia no es un proceso. Sin plantillas, sin fuentes y sin revisión, solo aceleras el copia-pega. Mejor un flujo acotado que diez cuentas sueltas.

¿Cuánto tarda un primer piloto?

Si el dato ya existe y el proceso cabe en una frase, semanas, no trimestres. Lo que alarga es no decidir el alcance.

¿Y si no tenemos ERP, solo Excel?

Entonces el piloto termina en una hoja bien nombrada y una cola de revisión. El Excel no impide empezar; impide fingir que ya sois una plataforma.

¿Listo para una valoración? Cuéntanos tu pyme — sector, tamaño y dónde se pierde el tiempo. Plan claro, orientado a digitalización, sin teatro. Relacionado: priorizar casos de uso, la checklist de arranque y la guía de Kit Digital.