Adopción con disciplina, no con prisa

En muchas empresas latinoamericanas la conversación sobre inteligencia artificial empezó por la herramienta. Un equipo probó un copiloto. Otro construyó un chatbot. Un proveedor presentó un agente capaz de automatizar parte del servicio al cliente. La dirección pidió ideas y, en poco tiempo, apareció una lista de pilotos.

Eso es movimiento. Todavía no es adopción.

La adopción ocurre cuando una capacidad de IA cambia de manera sostenida una decisión, un proceso o una experiencia de cliente. Tiene un dueño, opera con datos reales, responde a excepciones, se mide y puede mantenerse. El salto entre el piloto y esa realidad no depende principalmente de correr más. Depende de coordinar mejor.

La velocidad sin un sistema de decisión produce más actividad. La disciplina produce capacidad.

Latinoamérica no parte de cero. El Índice Latinoamericano de Inteligencia Artificial 2025 de la CEPAL analiza 19 países y muestra avances, pero también diferencias importantes en infraestructura, talento, investigación, adopción y gobernanza. No existe una sola realidad regional.

Otro análisis de la CEPAL observó tráfico web hacia alrededor de 260 soluciones de IA en 18 países. La región representó una proporción de visitas mayor que su proporción de usuarios globales de internet, y seis países, entre ellos Perú, concentraron 86 por ciento del tráfico regional. Al mismo tiempo, el uso observado se concentró en soluciones generativas de usuario final, mientras que las categorías asociadas con productividad empresarial y agentes tuvieron una participación menor.

La metodología importa. El tráfico web no captura sistemas empresariales cerrados ni equivale a medir despliegues en producción. Sirve como una señal parcial: hay interés y uso, pero la integración profunda todavía puede estar mucho menos desarrollada que la experimentación visible.

El costo oculto de los pilotos dispersos

Un piloto aislado puede crear aprendizaje. Diez pilotos sin criterios comunes pueden crear ruido.

El problema aparece cuando cada área elige una herramienta, negocia con un proveedor, define sus propios indicadores y trata los riesgos de manera distinta. La organización termina pagando varias veces por resolver preguntas similares. Los datos se fragmentan. La seguridad y el área legal llegan tarde. Las personas reciben nuevas interfaces sin claridad sobre cómo cambia su trabajo.

Al final, la dirección recibe una colección de historias: “funcionó bien”, “la gente lo usó”, “el modelo respondió rápido”. Ninguna de esas frases permite decidir si conviene escalar.

La respuesta no es centralizar toda innovación ni detener los experimentos. Es crear un sistema mínimo que haga comparables las decisiones.

Si el equipo no puede responder todavía, el piloto puede continuar como exploración. Lo que no debería hacer es presentarse como una iniciativa lista para transformar el negocio.

Priorizar no es escoger la idea más vistosa

Las empresas suelen priorizar por entusiasmo ejecutivo, disponibilidad de una herramienta o presión competitiva. Es comprensible, pero insuficiente.

Una cartera de IA debe evaluar al menos cuatro dimensiones:

• Valor: impacto potencial en ingresos, costo, riesgo, velocidad o experiencia.
• Factibilidad: disponibilidad de datos, integración, talento y proveedores.
• Adoptabilidad: disposición de las personas, claridad del proceso y capacidad para cambiar la operación.
• Consecuencia: qué daño podría causar un error y qué nivel de supervisión exige.

El mejor primer caso no siempre es el de mayor valor teórico. Puede ser uno suficientemente importante para conseguir atención y suficientemente acotado para aprender sin exponer a la empresa a un riesgo desproporcionado.

En mercados donde el capital, el talento especializado o la infraestructura son limitados, esta selección es todavía más importante. La restricción puede ser una ventaja si obliga a enfocar la inversión en un problema real. El error es dispersar el presupuesto en licencias y pruebas que no fortalecen ninguna capacidad común.

Construir capacidad alrededor del caso de uso

El Banco Mundial propone cuatro fundamentos para ampliar los beneficios de la IA: conectividad, capacidad de cómputo, contexto y datos, y competencias. A nivel empresarial, la idea se traduce en una pregunta práctica: ¿qué debe ser cierto para que este caso de uso opere en nuestro contexto?

No todas las empresas necesitan la misma arquitectura. Tampoco necesitan esperar a tener un programa de datos perfecto. Sí necesitan datos suficientemente accesibles, representativos y permitidos para la decisión que pretenden apoyar.

Lo mismo ocurre con el talento. No es necesario convertir a cada persona en especialista en modelos. El equipo de negocio debe saber definir el problema y evaluar el resultado. Tecnología debe integrar y operar. Riesgo, seguridad y legal deben traducir obligaciones en decisiones de diseño. Los usuarios deben saber cuándo confiar, cuándo revisar y cuándo escalar.

El trabajo más valioso suele ser específico del negocio. El informe de la OCDE, BCG e INSEAD sobre adopción de IA en empresas identifica barreras como preparación de datos, interoperabilidad, costos de implementación, dificultad para vincular la tecnología con problemas concretos, gestión del cambio y acceso a habilidades. También destaca la importancia de aprendizaje práctico y contextualizado.

La conclusión es incómoda pero útil: comprar una buena tecnología no compra automáticamente la capacidad de adoptarla.

Gobernar según la consecuencia, no según el miedo

La gobernanza puede convertirse en una excusa para no avanzar. También puede ser el mecanismo que permite avanzar sin improvisar.

Un asistente interno que resume documentos públicos no exige la misma revisión que un sistema que recomienda límites de crédito, evalúa candidatos o conversa con clientes usando datos personales. Aplicar el mismo proceso a ambos crea burocracia. Ignorar la diferencia crea riesgo.

Este modelo no reemplaza la ley ni los requisitos sectoriales de cada país. Sirve para que el negocio pueda conversar con tecnología, riesgo y legal desde el inicio. Las reglas dejan de aparecer como una sorpresa antes del lanzamiento.

Medir el sistema completo

Muchos pilotos miden precisión técnica o satisfacción inicial. Para decidir si existe adopción, hace falta una visión más amplia.

La medición debe combinar:

• Resultado de negocio: tiempo, calidad, conversión, costo, pérdida evitada o experiencia.
• Desempeño técnico: exactitud relevante, disponibilidad, latencia y costo por operación.
• Comportamiento humano: uso real, correcciones, dependencia excesiva, rechazo y nuevas prácticas.
• Riesgo: incidentes, errores materiales, exposición de datos y decisiones escaladas.
• Capacidad operativa: tiempo para detectar, recuperar, actualizar y responder.

Una mejora técnica puede no producir valor si el proceso alrededor no cambia. Una alta tasa de uso puede ser una mala señal si las personas aceptan resultados sin criterio. Un caso rentable puede seguir siendo inaceptable si expone a clientes o trabajadores a consecuencias que la empresa no puede explicar ni corregir.

Convertir cada piloto en aprendizaje institucional

La disciplina también consiste en no perder lo aprendido. Cada proyecto debería dejar activos reutilizables: una definición de caso de uso, criterios de riesgo, patrones de integración, controles de datos, indicadores, cláusulas para proveedores y una lista honesta de fallas.

Eso permite que el siguiente equipo empiece un nivel más arriba. La empresa deja de acumular demos y comienza a construir un sistema operativo para la adopción.

Una revisión trimestral de cartera puede responder cuatro preguntas:

1. ¿Qué casos avanzan y por qué?
2. ¿Qué brechas se repiten entre proyectos?
3. ¿Qué capacidades comunes merecen inversión?
4. ¿Qué iniciativas debemos detener para recuperar foco?

Detener también es una decisión estratégica. Cerrar un piloto débil libera talento, presupuesto y credibilidad para los casos que sí importan.

Una agenda ejecutiva para los próximos 90 días

La transformación no comienza con un plan de tres años. Puede comenzar con una secuencia concreta:

1. Inventariar los pilotos y herramientas que ya existen, incluso los usos informales.
2. Seleccionar entre uno y tres flujos de negocio prioritarios.
3. Asignar un dueño de resultado, no solo un líder técnico.
4. Definir indicadores y condiciones de escalamiento antes de seguir invirtiendo.
5. Clasificar riesgos y acordar controles proporcionales.
6. Probar con datos y excepciones representativas.
7. Tomar una decisión explícita y documentar el aprendizaje.

Latinoamérica no necesita imitar la agenda de otro mercado. Necesita organizaciones capaces de convertir sus restricciones, su conocimiento sectorial y su cercanía con el cliente en decisiones mejores.

La oportunidad no está en demostrar que podemos usar la misma IA que todos. Está en integrarla con disciplina a la forma en que nuestras empresas realmente operan.