Adopción de IA en empresas LATAM: el trabajo empieza después del piloto

Para llevar un piloto de IA a la operación hay que definir qué decisión cambia, con qué datos, quién responde por ella y en qué rutina se usará. Si esas piezas no están claras, una demo convincente puede terminar como otra pestaña que el equipo abandona cuando vuelve la urgencia diaria.

He trabajado esa transición desde growth, datos y sistemas en LATAM. La parte difícil rara vez es conseguir una primera respuesta de un modelo. Es lograr que alguien pueda confiar en ella lo suficiente para incorporarla a un flujo, corregirla cuando falle y explicar si el trabajo mejoró. Esta guía reúne las preguntas que uso para separar una prueba interesante de un sistema que vale la pena operar.

Empieza por una decisión, no por la herramienta

Una solicitud como «queremos usar IA en ventas» todavía no define un caso. «Cada lunes el equipo decide qué cuentas requieren seguimiento y tarda una mañana en reunir la información» sí permite investigar un flujo concreto. Ya sabemos quién decide, cuándo ocurre y qué preparación consume tiempo.

Antes de abrir un piloto, escribe tres respuestas:

1. ¿Qué decisión o entrega cambiará? Nombra el resultado observable: una cotización revisada, una prioridad asignada o una reunión que empieza con datos listos.
2. ¿Qué sucede hoy? Registra el tiempo de espera, los pasos manuales, las correcciones y las fuentes que el equipo consulta. Esa es la línea base.
3. ¿Qué parte puede preparar la IA? Distingue entre reunir información, proponer una respuesta y ejecutar una acción. Cada paso exige un nivel distinto de revisión.

Conviene elegir un proceso que se repite, tiene un responsable y deja ver sus errores. Si todos los casos son excepcionales o nadie acepta ser dueño del resultado, primero hay que ordenar el proceso.

Cuatro condiciones para que el piloto sobreviva

Una decisión visible. El equipo debe poder señalar quién toma la decisión final y qué información necesita en ese momento. Una respuesta útil fuera de tiempo también puede ser inútil.

Un dato que se pueda defender. Define qué fuente manda, quién la actualiza y qué hacer si está incompleta. La calidad necesaria depende del riesgo: resumir antecedentes y modificar un precio no requieren el mismo umbral. En este artículo sobre datos y agentes explico por qué esa distinción importa cuando un sistema puede ejecutar acciones.

Un dueño operativo. La persona responsable del proceso debe participar desde la prueba, revisar excepciones y decidir si el resultado entra en su rutina. El equipo que construye la herramienta puede mantenerla, pero no puede decidir por quienes viven las consecuencias.

Una rutina nueva. Especifica dónde aparece la salida de la IA y qué paso reemplaza. Si el equipo sigue preparando el archivo paralelo, copiando la respuesta a otra pantalla o pidiendo la misma aprobación por fuera, todavía no cambió el trabajo.

La ficha mínima antes de construir

Una página basta para hacer explícitos los acuerdos de un piloto:

• Caso y frecuencia: qué ocurre y cuántas veces aparece en un ciclo normal de trabajo.
• Entrada: qué datos necesita, de dónde salen y qué hacer cuando faltan.
• Salida: qué entrega el sistema y quién puede verla o utilizarla.
• Permisos: qué puede preparar, qué puede proponer y qué acción requiere aprobación humana.
• Responsable: quién revisa errores y quién decide cambios en las reglas.
• Criterio de salida: qué evidencia justificaría ampliar el piloto, corregirlo o detenerlo.

Esto evita descubrir demasiado tarde que la demo usó datos limpios preparados a mano o que nadie tiene permiso para aplicar la recomendación. También permite empezar con una versión pequeña: preparar información y sugerir una acción antes de automatizar su ejecución.

Mide trabajo real, no entusiasmo inicial

El número de licencias activadas indica acceso; no indica adopción. Para saber si el flujo entró en operación, compara un periodo anterior con varios ciclos de uso real. Estas cuatro medidas suelen revelar más:

• Uso en casos elegibles: casos resueltos con el nuevo flujo divididos entre los casos donde podía usarse. Pregunta por qué el equipo evitó el resto.
• Tiempo hasta la decisión: desde que entra la solicitud hasta que alguien puede actuar, incluyendo la revisión humana.
• Calidad y retrabajo: correcciones, respuestas rechazadas y pasos que hubo que repetir.
• Excepciones y control: casos escalados, motivo del escalamiento y tiempo para resolverlos.

La medida exacta cambia con el proceso. Una revisión semanal busca datos consistentes y decisiones a tiempo; una respuesta a clientes necesita además tono adecuado y revisión de contenido. Anota desde el inicio qué resultado justificaría mantener el sistema. Si no hay mejora observable, ajusta el flujo antes de ampliarlo.

Dos casos que muestran capas distintas

El dashboard WBR que construí consolida ventas, operación y metas para una revisión semanal con una vista compartida de los desvíos. Muestra la capa de datos y rutina: el equipo necesita llegar a la reunión con una misma base para decidir, en lugar de volver a unir planillas.

En Kauce, la IA redacta respuestas para atención, ventas y cotizaciones en la voz de la empresa; el equipo revisa y envía. Ahí la frontera entre propuesta y acción es explícita. El sistema puede acelerar la preparación, mientras la persona conserva la decisión de comunicarse con el cliente.

Son problemas distintos, pero comparten una prueba de adopción: ¿el resultado llega al lugar donde el equipo trabaja y existe alguien responsable cuando la salida no sirve?

Qué revisar al operar en varios países de LATAM

Una solución que funcionó en un equipo puede fallar al copiarla a otro país si cambian las definiciones de los datos, la moneda, los horarios, los canales de atención o las reglas de aprobación. Antes de replicar un piloto, verifica esos supuestos con el equipo local. Mantén una definición compartida de cada indicador y registra qué parte del flujo sí varía por mercado.

Escalar no consiste en clonar una pantalla. Consiste en conservar una forma de decidir y adaptar sus entradas, responsables y controles donde la operación lo exige. Si puedes explicar esas diferencias y medir el uso en cada lugar, el piloto empieza a parecerse a un sistema.