El manual vivo de tu empresa
Guía · 8 min de lecturaErrores al implementar IA en una empresa (y cómo evitarlos)
Seis formas de que un proyecto de IA se quede en prueba, contadas desde lo que pasa de verdad en una pyme, y qué hacer en su lugar.
Los errores al implementar IA en una empresa se parecen mucho entre sí, y casi ninguno es técnico. Rara vez falla el modelo: falla el orden en que se hacen las cosas, la falta de un responsable o que nadie decidió qué se iba a medir. El resultado típico no es un desastre, es algo peor de gestionar: una prueba que estuvo bien, que gustó en la reunión y que seis meses después nadie usa. Estos son los seis fallos que más se repiten en pymes y qué hacer en su lugar.
Empezar por la herramienta
Es el error de cabecera. Se contrata un programa, se reparten accesos y se espera que la gente encuentre para qué sirve. Al principio hay curiosidad; en un mes, el uso baja a dos o tres personas que ya tenían interés por su cuenta.
El motivo es simple: una herramienta no sabe nada de tu negocio. No sabe quién aprueba un pedido de 4.200 €, ni qué hacéis si el proveedor ya ha facturado la devolución. Sin ese contexto responde en general, y lo general no ayuda a decidir.
Qué hacer en su lugar. Elige primero un trabajo concreto que duela —la misma pregunta que llega veinte veces, el correo que alguien reescribe cada día— y comprueba si está escrito. La herramienta se elige después, cuando ya sabes qué tiene que hacer. El planteamiento completo está en implantar IA sin empezar por el programa.
Automatizar sin entender lo que se automatiza
Alguien monta un automatismo a partir de cómo cree que funciona un proceso. Funciona para el caso normal, que es el que se explica en la reunión, y falla en el de al lado: el pedido urgente que entra por teléfono, el cliente que factura por obra, el material que se devuelve sin albarán.
Cuando eso pasa, la gente deja de fiarse y vuelve a hacerlo a mano «por si acaso». Entonces tienes el trabajo antiguo más un automatismo que hay que vigilar.
Qué hacer en su lugar. Antes de automatizar, siéntate con quien hace el trabajo y recorre el proceso real de principio a fin, incluidos los casos raros. La regla de elección está en la guía sobre qué merece automatizarse y qué no: frecuencia, volumen, reglas claras, riesgo bajo y dato disponible.
Pilotos que no mide nadie
Se lanza una prueba, se dedica tiempo, sale razonablemente bien. Llega el momento de decidir si se extiende y nadie sabe responder si ha servido, porque no se midió nada antes de empezar. La decisión acaba siendo una opinión, y la opinión que gana es la del que más manda.
Qué hacer en su lugar. Apunta la línea base antes de tocar nada: cuántos casos al mes, cuánto tarda hoy, cuántos errores o retrabajos salen, cuántas veces se pregunta esto mismo por el chat interno. Fija una fecha de decisión desde el principio y tres resultados posibles: seguir, ajustar o parar. Parar con datos es un buen resultado, no un fracaso.
Hay una versión suave de este mismo fallo: medir lo que es fácil de contar en lugar de lo que importa. Saber cuántas consultas ha atendido el asistente no dice nada si nadie ha mirado si esas consultas han dejado de interrumpir a alguien, o si las respuestas eran correctas. Elige dos indicadores que le importen al responsable del área y olvídate del resto.
Ignorar las excepciones
En las pymes, las excepciones no son casos marginales: son una parte importante del trabajo y, muchas veces, lo que diferencia a la empresa. El cliente de toda la vida al que se le sirve aunque haya pasado el plazo, el proveedor al que hay que llamar antes del jueves, el pedido que se prepara aparte porque el transportista pasa a primera hora.
Un proyecto de IA que documenta solo el camino feliz produce respuestas correctas en teoría e inútiles en la práctica. Y lo que es peor: la primera vez que alguien pregunta por un caso raro y recibe una respuesta genérica, deja de preguntar.
Qué hacer en su lugar. Que cada proceso escrito tenga su apartado de excepciones, con la regla y con quién decide cuando no hay regla. Y que el sistema pueda decir «esto no lo sé» en lugar de improvisar. Una respuesta que reconoce el límite mantiene la confianza; una inventada la rompe para siempre.
Documentar una vez y no volver
Se hace un esfuerzo grande, se escriben cuarenta procesos y se da por terminado. A los seis meses ha cambiado el programa de facturación, dos personas han cambiado de puesto y hay un cliente nuevo con otras condiciones. Nada de eso está reflejado.
La documentación vieja es más peligrosa que la falta de documentación, porque la gente se fía. Y si encima hay una IA respondiendo a partir de ella, repite el error con seguridad y a mayor velocidad.
Qué hacer en su lugar. Tres hábitos baratos: cada proceso tiene un puesto dueño que responde de él; cada cambio deja rastro de qué se cambió, cuándo y quién, para poder volver atrás; y el aviso va solo a los puestos afectados, no a toda la empresa, porque el aviso general acaba en carpeta de ignorados. Es la diferencia entre una carpeta de archivos y un manual que se mantiene vivo.
Olvidar los permisos
El último error es el que puede costar un disgusto serio. Se conecta el asistente a «todo lo que hay en la nube» para que tenga más contexto, y de repente cualquiera puede preguntar cuánto cobra un compañero, qué pone la carta de un despido o qué margen se le aplica a un cliente.
No hace falta mala intención: basta una pregunta inocente y una respuesta demasiado servicial.
Qué hacer en su lugar. Define quién lee cada página antes de conectar nada y comprueba que la IA respeta esos permisos, de modo que solo busque en lo que puede ver quien está preguntando. Repasa en especial personal, datos económicos por cliente y contratos. Y haz la prueba al revés: pide a alguien sin permisos que pregunte por algo sensible y mira qué contesta.
Casi todos los errores al implementar IA en una empresa tienen la misma raíz
Si miras los seis fallos juntos, todos comparten la misma raíz: se trató la IA como una compra y no como un cambio en la forma de trabajar. Las compras se instalan; las formas de trabajar se acompañan, se miden y se corrigen.
Por eso el proyecto que sale adelante suele empezar pequeño, sobre un trabajo que molesta a alguien de verdad, con un responsable con nombre, una medida acordada y una fecha para decidir. Y por eso el paso previo casi nunca es tecnológico: es entender y escribir cómo funciona la empresa. Si quieres ver ese trabajo previo convertido en una lista concreta, está en lo que conviene tener listo antes.