Por Procure Latam
25 de Mayo, 2026
Hay una pregunta que hago casi al inicio de cada sesión con equipos de compras: ¿cuántos de ustedes ya están usando IA? La mayoría levanta la mano. Luego pregunto cuántos tienen documentados los prompts que más les han funcionado: las manos bajan casi por completo.
Eso resume bien el problema. No hay problema de acceso a la tecnología. El problema es la distancia entre experimentar y operar con intención. En la segunda sesión de nuestro Ciclo Formativo IA para el Procurement, impartida el 20 de mayo junto a Procure Latam y el Tecnológico de Monterrey con el patrocinio de Wherex, trabajamos exactamente eso: cómo convertir esas interacciones en activos que la organización pueda reutilizar, medir y escalar. En este artículo desarrollo las ideas centrales.
Recordemos que la estrategia de adopción de IA se sostiene sobre cuatro pilares: personas, procesos, tecnología y estrategia. Pero todo eso descansa sobre un cimiento que determina si la salida del modelo será útil o inútil: los datos.
Si los datos de entrada son de mala calidad, la respuesta de la IA será de mala calidad, sin importar qué herramienta se use ni cuánto cueste la licencia. Esta no es una advertencia técnica. Es la razón por la que tantas iniciativas de IA en procurement fracasan silenciosamente: se invierte en tecnología sin primero invertir en la integridad del dato.
El otro elemento de la ecuación que vale la pena nombrar es el humano. La inteligencia artificial no viene a reemplazar al profesional de compras; viene a convertirlo en lo que algunos llaman un “superhumano”: alguien que delega en la IA las tareas repetitivas y de alto volumen, para enfocarse en lo que ningún modelo puede replicar. El pensamiento crítico, la experiencia del mercado, la intuición negociadora. Ese es el espacio que el profesional de procurement debe proteger y ampliar.
Un prompt es la instrucción que le damos a la IA. Puede ser una pregunta simple o una instrucción compleja con contexto, variables y formato de salida esperado. La idea que sostengo es que al prompt hay que tratarlo como es: un activo de la organización, algo que la mayoría de los equipos aun no hacen.
Voy con un ejemplo: dicen que la fórmula de la Coca-Cola solo la conocen dos personas en el mundo. Su valor no está en la tecnología con la que se produce la bebida; está en esa misma fórmula, que es reproducible y que se encuentra bien documentada.
Los prompts de un equipo de compras tienen el mismo potencial y se puede exprimir de múltiples formas: Un prompt permite analizar un contrato en minutos, comparar proveedores con criterios consistentes, generar una propuesta de negociación bien estructurada, etc. El problema es que hoy, en la mayoría de las organizaciones, ese valor se pierde en el historial del chat.
La solución no es técnicamente compleja (puede ser perfectamente un Excel), lo que importa es que ese repositorio exista, que cada prompt tenga una versión documentada, y que haya alguien responsable de mantenerlo: La versión 1.0 es el punto de partida, la 1.1 incorpora el contexto que faltó, la 2.0 integra perspectiva de otra área (legal, financiero, comercial) para obtener un resultado más robusto. Si la 2.0 no funciona bien, hay un rollback al prompt estable anterior… Esto es netamente higiene operativa hecha con apoyo de la IA.
Hay un principio que aplica aquí con toda su fuerza: lo que no se mide no se puede escalar. Si no evaluamos si un prompt entrega la información con la calidad y rapidez esperadas, seguiremos empezando desde cero cada vez. Aquí es donde hay que saber identificar la oportunidad: la organización que ya tiene su biblioteca de prompts optimizados estará, sencillamente, varios pasos adelante.
Hay una afirmación que repito con insistencia: el paso más difícil en la adopción de IA no es técnico. Es decidir en qué sí aplicarla y en qué no. Porque la tentación de automatizarlo todo es real, y casi siempre conduce a iniciativas que no generan valor medible.
Un caso de uso válido debe responder tres preguntas sin excepción.
1.- ¿qué decisión hoy es lenta, costosa o riesgosa?
2.- ¿dónde ocurre ese problema dentro del proceso?
3.-¿qué cambia, en términos cuantificables, si lo resolvemos?
Si no podemos responder las tres solo tenemos una idea y no un caso de uso.
La matriz de Gartner que revisamos en la sesión es útil precisamente porque ordena los casos de uso según dos ejes: valor de negocio y factibilidad técnica. Los que combinan alto valor con alta factibilidad son los candidatos naturales para empezar. En procurement, los más sólidos son el análisis de gasto (clasificación y detección de anomalías en los datos de compras) , la analítica avanzada de contratos, el onboarding y evaluación de proveedores, y la gestión de solicitudes internas mediante agentes. Son procesos con datos disponibles, impacto medible y tecnología accesible hoy.
Los números respaldan el argumento. Según los estudios que revisamos, organizaciones que han implementado IA en estas áreas reportan incrementos de más del 10% en eficiencia de negociación, equipos entre 20% y 35% más rápidos en sus respuestas, y reducciones de entre 40% y 60% en tiempos de procesamiento de datos. Pero lo que más me interesa de esas cifras no es su tamaño, sino su condición: solo se materializan cuando el caso de uso fue bien elegido y bien ejecutado.
En el taller práctico de la sesión trabajamos con un framework de cinco pasos (inspirado en el enfoque McKinsey para casos de uso de IA) que tiene como objetivo convertir una intuición en un proyecto ejecutable.
El primer paso es nombrar el problema con precisión: ¿qué decisión es hoy lenta, costosa o riesgosa, quiénes están afectados, y cuál es el impacto actual en horas, errores o dinero? El segundo es explorar cómo la IA puede abordar ese problema específico, no genéricamente. El tercero es identificar qué datos se necesitan y qué plataforma es más adecuada para ese caso: Copilot para documentos internos, Claude para razonamiento complejo, otras según el contexto. El cuarto es estimar el retorno: ¿cuántas horas se liberan, cuál es el costo de implementación, cuándo se recupera la inversión? El quinto es diseñar el roadmap: prueba de concepto primero, piloto después, escalamiento solo cuando el piloto valide.
Varios participantes del taller llegaron a conclusiones que no esperaban. Un equipo descubrió que su problema real no requería IA, sino un mejor control financiero. Otro identificó que el cuello de botella no estaba en el análisis de proveedores, sino en las ocho horas semanales que cada persona dedicaba a leer correos y extraer información de forma manual.
Hoy muchas organizaciones ya están usando IA, pero pocas están construyendo capacidades que realmente puedan sostenerse y escalar en el tiempo. La diferencia empieza a aparecer justamente ahí: en la capacidad de documentar lo aprendido, identificar bien los casos de uso y convertir interacciones aisladas en conocimiento operativo reutilizable.
El 27 de mayo entramos a la etapa de construcción para producción: cómo pasar del piloto a algo que escale dentro de la organización, mientras que el 3 de junio cerramos el ciclo con despliegue y monitoreo.
Inscribanse
