Qué hace un consultor de inteligencia artificial (y qué no)
Es un oficio con nombre nuevo y mucha gente dentro. Esto es lo que debería estar haciendo quien se llame así, cuándo compensa pagarlo y cómo distinguir al que sabe del que ha hecho un curso.
Lo que vas a encontrar
La pregunta se la hacen casi todos los gerentes que me llaman, aunque no siempre con estas palabras. Lo que me dicen es: «me han recomendado que hable con alguien de IA, pero no sé muy bien qué le voy a pedir».
Es razonable. «Consultor de inteligencia artificial» es un título que en 2023 no existía y que hoy aparece en miles de perfiles de LinkedIn. Hay de todo: gente que lleva una década en datos, desarrolladores que han virado, agencias de marketing que han añadido una línea de servicio y vendedores que han aprendido cuatro términos.
Así que vamos por partes.
El trabajo, en una frase
Un consultor de IA mira cómo trabaja tu empresa de verdad, encuentra dónde se pierde tiempo o dinero, y decide qué parte de eso se resuelve con inteligencia artificial y a qué coste.
La parte más valiosa del trabajo consiste en descartar.
Fíjate en el orden. Primero el proceso, después la tecnología. Si alguien llega con la herramienta decidida antes de haber visto cómo trabajáis, no está haciendo consultoría: está colocando un producto.
El entregable típico no es un programa. Es un documento que dice: estos son vuestros cinco procesos más caros en horas, estos dos se pueden automatizar hoy con la tecnología que hay, este tercero no y te explico por qué, y esta es la cuenta de lo que costaría y de en cuánto tiempo se recupera.
Las cuatro cosas que hace de verdad
1. Hablar con quien hace el trabajo
No con dirección. Con la persona que mete las facturas, la que atiende el teléfono, la que busca el contrato que nadie encuentra.
Esto parece obvio y casi nadie lo hace. Dirección sabe qué le preocupa, pero rara vez sabe cuántos minutos se tarda en registrar un albarán ni cuántas veces al día alguien pregunta lo mismo. Esa información está abajo y hay que ir a buscarla.
De esas conversaciones sale el único dato que de verdad importa al principio: cuántas horas al año consume cada proceso y cuánto cuesta esa hora. A partir de ahí ya se puede hablar de dinero en lugar de hablar de tecnología.
2. Decidir qué merece la pena y qué no
La parte más valiosa del trabajo consiste en descartar.
Hay procesos que parecen candidatos perfectos y no lo son. El caso típico: una tarea que se hace tres veces al mes y lleva veinte minutos. Automatizarla cuesta varios miles de euros y ahorra doce horas al año. No sale.
Y hay procesos que nadie señala y son oro, normalmente porque llevan tanto tiempo haciéndose a mano que ya nadie los ve. Pasar datos del correo a una hoja de cálculo y de la hoja al programa de gestión es el ejemplo clásico: nadie lo nombra como problema porque siempre ha sido así.
3. Elegir la arquitectura
Aquí es donde hace falta saber de tecnología, y es donde se nota quién sabe.
Las decisiones reales son pocas pero pesan mucho: si los datos pueden salir de la empresa o no, si compensa pagar por uso a un proveedor comercial o montar un modelo en un servidor propio, cómo se conecta con el ERP que ya tienes, qué pasa cuando el sistema no está seguro de algo.
Ninguna de esas preguntas se contesta igual en todas las empresas. Una gestoría que maneja nóminas y una tienda que responde dudas sobre plazos de envío tienen necesidades opuestas en cuanto a dónde pueden vivir sus datos.
4. Mirar la parte legal antes de construir
El Reglamento Europeo de IA está en vigor y el RGPD lleva años. La mayoría de los usos de una pyme son de riesgo bajo y no traen gran cosa, pero hay excepciones serias: todo lo que toque selección de personal o evaluación de trabajadores entra en alto riesgo y cambia por completo el proyecto.
Eso se mira antes. Descubrirlo a mitad de la implantación es lo que convierte un proyecto de dos meses en uno de seis.
Si quieres el detalle, lo desarrollo en qué obligaciones trae el Reglamento Europeo de IA a una pyme.
Lo que no es
No es un vendedor de herramientas. Su trabajo empieza antes de elegir ninguna. Si la primera reunión ya incluye el nombre de un producto, algo va mal.
No es un desarrollador. Un buen desarrollador construye lo que le pidas, y lo construye bien. Pero decidir qué hay que construir es otro oficio. Mucha pyme contrata desarrollo cuando lo que necesitaba era que alguien le dijera qué desarrollar.
No es un formador. La formación puede ser parte del encargo, y de hecho suele serlo, pero dar un curso de ChatGPT a la plantilla no es consultoría. Es útil y es otra cosa.
Y no es alguien que te dice que sí a todo. Un consultor que nunca ha recomendado no hacer un proyecto no está asesorando, está facturando.
Cuándo compensa contratarlo
No siempre. Hay tres situaciones donde sí:
- Sabes que pierdes tiempo pero no dónde. La sensación de «esto tiene que poder hacerse mejor» sin un sitio concreto al que apuntar. Aquí el diagnóstico es casi todo el valor.
- Tienes una propuesta de un proveedor encima de la mesa. Una segunda opinión cuesta unas horas y puede ahorrarte un proyecto entero mal planteado. Sobre esto escribí las siete preguntas que le haría a cualquier presupuesto de IA.
- Ya has probado algo y no ha funcionado. Es más común de lo que parece. Casi siempre el fallo no fue técnico: fue elegir mal el caso de uso o no escribir qué significaba que funcionara.
Y hay una donde no compensa: si lo que necesitas es una herramienta concreta que ya sabes cuál es, contrata a quien la implante y ahórrate el intermediario.
Cómo saber si el que tienes delante sabe
Cinco señales, de las que se ven en la primera conversación.
Te pregunta mucho antes de proponer nada. Una propuesta seria llega después de muchas preguntas, no antes.
Habla de tu proceso, no de modelos. Si en media hora ha dicho cinco nombres de tecnologías y ninguno de tus departamentos, está vendiendo lo que sabe en lugar de resolver lo que tienes.
Te da un número. «Mejorar la eficiencia» no es un objetivo, es un deseo. «Bajar de cuatro minutos a uno el registro de una factura, medido sobre cincuenta facturas» sí lo es.
Menciona lo que va a salir mal. El estado de tus datos, la resistencia del equipo, el coste del segundo año. Quien solo cuenta la parte buena no ha hecho muchos proyectos.
Te dice que no a algo. Esta es la mejor de todas, y la desarrollo al final del artículo del presupuesto porque vale para cualquier proveedor.
Y la pregunta incómoda: ¿hace falta que sea técnico?
Mi opinión, sesgada porque yo lo soy: sí, al menos para decidir la arquitectura.
Se puede hacer un diagnóstico de procesos excelente sin saber programar. Lo que no se puede hacer sin base técnica es estimar bien cuánto cuesta construir algo, saber si una idea es viable con la tecnología de hoy o detectar cuándo un proveedor te está vendiendo humo con palabras correctas.
El perfil que mejor funciona en una pyme es el que se sienta en las dos sillas: entiende la conversación de negocio y además ha puesto cosas en producción. No porque sea más listo, sino porque cuando dice «esto cuesta tres semanas» lo dice por haberlo hecho.
Si estás en el punto de «sé que perdemos tiempo pero no sé por dónde empezar», eso es exactamente lo que hago en el diagnóstico. Media hora, sin coste, y si creo que no te hace falta IA te lo digo en esa misma llamada.
En tres líneas
- Primero el proceso y después la tecnología. Quien llega con la herramienta decidida no está asesorando.
- El valor está en descartar: la mitad del trabajo es decir qué no merece la pena automatizar.
- La mejor señal de que tienes delante a alguien serio es que te diga que no a algo.