La fascinación por la IA está en su punto más alto. Cada semana aparece una nueva herramienta que promete transformar su negocio. Y es tentador preguntarse: ¿cuál debo adoptar primero? Pero esa es la pregunta equivocada. La pregunta correcta es: ¿Qué problema de mi negocio no he podido resolver con las herramientas que ya tengo?

En Colombia, las empresas no fracasan en IA por falta de tecnología. Fracasan por empezar al revés: elegir la herramienta antes de entender el problema. 

Pero hay una dimensión adicional que hace este desafío más complejo en el contexto local: la normativa de protección de datos, las particularidades del comportamiento del consumidor colombiano, la estacionalidad del mercado y los canales de pago predominantes. Un modelo entrenado en otro país, con otros clientes y otras regulaciones, no sirve automáticamente en Colombia. El contexto importa, y este artículo desarrolla la hoja de ruta que lo tiene en cuenta, paso a paso, con el detalle técnico y estratégico que un CTO o gerente de datos necesita para tomar decisiones informadas.

1. El punto de partida: el problema de negocio, no el laboratorio

Ningún proyecto de IA debería comenzar en un laboratorio. Debería comenzar en una junta directiva, revisando los indicadores que no se están cumpliendo: retención de clientes, tiempos de respuesta, costos operativos, pérdida de ingresos. Este es el punto de partida correcto, porque define el problema que la IA debe resolver, y con él, el criterio de éxito del proyecto.

Un ejemplo ilustrativo viene del sector banca. Una entidad financiera detecta que su tasa de abandono en el onboarding digital supera el 40%. Ese es el problema. La IA no es el objetivo, es el medio para retener al cliente en los primeros 90 días. Con esta definición, el equipo puede empezar a trabajar: ¿qué datos tenemos sobre el comportamiento de los usuarios durante el onboarding? ¿En qué paso del proceso se produce el abandono? ¿Qué patrones distinguen a los usuarios que completan el proceso de los que lo abandonan?

Para un CTO, esto implica una decisión estratégica importante: el proyecto de IA debe tener un dueño de negocio claro, alguien que sea responsable del problema y que tenga autoridad para tomar decisiones sobre el proceso. Sin este dueño, el proyecto se convierte en un ejercicio técnico sin anclaje organizacional, y su destino dependerá del entusiasmo del equipo, no de su valor de negocio.

2. El diagnóstico de datos: el primer entregable del proyecto

La IA se alimenta de datos. Sin datos limpios, estructurados y suficientes, no hay modelo que funcione, por más sofisticado que sea. Por eso, el primer entregable del proyecto no es un modelo, sino un diagnóstico de datos que responda tres preguntas: ¿qué información histórica tenemos sobre este problema?, ¿dónde está almacenada y en qué formato?, y ¿qué tan confiable es?

Un ejemplo ilustrativo viene del sector retail. Una cadena comercial quiere predecir la demanda, pero descubre que sus datos de inventario están dispersos en tres sistemas incompatibles. El primer proyecto de IA, entonces, no es un modelo de predicción: es un proyecto de unificación de datos. Esta es una decisión estratégica que muchos subestiman: invertir en infraestructura de datos antes de invertir en modelos, porque sin una base sólida, cualquier modelo será frágil y costoso de mantener.

Desde la perspectiva de un gerente de datos, el diagnóstico debe incluir también una evaluación de la calidad de los datos: completitud (¿qué porcentaje de los registros tiene todos los campos necesarios?), consistencia (¿los mismos conceptos se representan de la misma manera en todos los sistemas?) y oportunidad (¿los datos están actualizados, o reflejan un estado del negocio que ya no existe?). Estos tres ejes determinan la viabilidad del proyecto y, en muchos casos, revelan que el primer proyecto de IA es en realidad un proyecto de gobierno de datos.

3. El contexto local como variable de diseño: regulación, mercado y datos

Un modelo de IA entrenado en otro país, con otros clientes y otras regulaciones, no sirve automáticamente en Colombia. El contexto importa, y debe tratarse como una variable de diseño del proyecto, no como un obstáculo ajeno. Tres dimensiones son particularmente relevantes en el contexto colombiano.

La primera es la normativa de protección de datos. Colombia tiene una regulación específica (la Ley 1581 de 2012 y sus decretos reglamentarios) que establece requisitos claros sobre la recolección, uso y almacenamiento de datos personales. Un proyecto de IA que procese datos personales debe diseñarse desde el inicio con estos requisitos en mente: finalidad del tratamiento, autorización del titular, y medidas de seguridad técnicas y organizativas. Esto no es un trámite administrativo, es una condición de viabilidad del proyecto, y debe incorporarse al diseño desde la primera semana, no al final.

La segunda es el comportamiento del consumidor local. Los patrones de consumo, los canales de pago predominantes y las estacionalidades del mercado colombiano difieren de otros mercados. Un modelo entrenado con datos de otro país puede tener un desempeño deficiente en Colombia, no por un defecto técnico, sino porque los patrones que aprendió no corresponden a la realidad local. La solución es entrenar y calibrar los modelos con datos locales, lo que implica que el diagnóstico de datos debe incluir una evaluación de la disponibilidad y calidad de los datos locales relevantes.

La tercera es la infraestructura y la soberanía de datos. Dependiendo del sector y del tipo de datos, puede ser necesario que el procesamiento ocurra en infraestructura local o en regiones específicas de la nube, por razones regulatorias o de latencia. Esta decisión de arquitectura debe tomarse al inicio del proyecto, porque determina las opciones tecnológicas disponibles y el diseño del flujo de datos. Una herramienta como Vertex AI, que se despliega en la infraestructura de Google Cloud, permite construir modelos ajustados a la realidad de su operación, no a la de un mercado ajeno, manteniendo el control sobre dónde y cómo se procesan los datos.

4. La selección del tipo de IA: hacer coincidir la herramienta con la naturaleza del problema

No toda solución requiere IA generativa. A veces un flujo conversacional con Dialogflow para atender consultas frecuentes resuelve más que un modelo de lenguaje complejo. Otras veces, TensorFlow permite detectar patrones de clientes y mercado que a simple vista son invisibles. La clave es hacer coincidir el tipo de IA con la naturaleza del problema, y esto requiere un entendimiento claro de las categorías de problemas y sus soluciones tecnológicas correspondientes.

Hay tres categorías principales. La primera es el problema de conversación y atención: cuando el desafío es atender consultas frecuentes, resolver dudas de clientes o guiar a un usuario en un proceso, la IA conversacional es la solución adecuada. Herramientas como Dialogflow, o IA generativa con grounding en los datos de la organización, permiten construir asistentes que entienden lenguaje natural y responden con información verificada de las fuentes internas.

La segunda es el problema de predicción y detección de patrones: cuando el desafío es anticipar un comportamiento (como la demanda, el abandono de clientes o el riesgo de impago), o detectar patrones que no son visibles a simple vista, el machine learning es la solución adecuada. Herramientas como TensorFlow o Vertex AI permiten construir modelos que aprenden de datos históricos y hacen predicciones sobre casos futuros.

La tercera es el problema de productividad interna: cuando el desafío es mejorar la eficiencia de los equipos internos, la IA generativa integrada en herramientas de trabajo, como Google Workspace, permite automatizar tareas repetitivas, redactar documentos, resumir información y apoyar la toma de decisiones. Esta categoría tiene un umbral de adopción más bajo, porque no requiere construir modelos propios, sino integrar capacidades de IA en las herramientas que el equipo ya usa.

Para un CTO, la selección del tipo de IA debe basarse en un análisis sistemático del problema, no en la preferencia por una tecnología específica. Y debe incluir una evaluación del costo total de propiedad: no solo el costo de construir el modelo, sino el costo de mantenerlo, de alimentarlo con datos actualizados y de integrarlo con los sistemas existentes.

5. Automatización con criterio: la diferencia entre acelerar un proceso y rediseñarlo

La automatización no es un fin en sí mismo. Automatizar un proceso mal diseñado solo produce errores más rápido. Por eso, antes de automatizar, es necesario rediseñar el proceso, o hacerlo en paralelo, y validar que el proceso rediseñado sea correcto antes de escalar la automatización.

Es importante distinguir entre automatización tradicional e IA, porque son herramientas con lógicas diferentes y usos diferentes. La automatización tradicional sigue reglas fijas: si ocurre X, haga Y. Funciona cuando el proceso es estable y predecible, y su valor es eliminar pasos repetitivos que no requieren juicio. La IA, en cambio, aprende de los datos y se adapta. Detecta patrones de clientes y mercado que las reglas fijas no pueden capturar, y mejora con el tiempo. Su valor no es eliminar pasos, sino eliminar la necesidad de que un humano detecte el patrón.

La diferencia no es tecnológica, es estratégica. La automatización tradicional elimina pasos; la IA elimina la necesidad de que un humano detecte el patrón. En salud, por ejemplo, la IA puede identificar pacientes con alto riesgo de reingreso analizando historial clínico, algo que una regla fija jamás lograría, porque el patrón no es una condición simple, sino una combinación compleja de factores que solo el aprendizaje automático puede capturar.

Para un CTO, esta distinción tiene implicaciones de diseño. Un proyecto de automatización tradicional puede ser implementado por un equipo de integración con herramientas de flujo de trabajo. Un proyecto de IA requiere un equipo con capacidades de ciencia de datos, una infraestructura de datos sólida y un proceso de monitoreo y actualización del modelo. El presupuesto, el cronograma y el perfil del equipo deben reflejar esta diferencia desde el inicio.

6. La medición del impacto: el contrato que permite defender el proyecto

Si no puede medirlo, no lo implementó. Defina desde el día uno: el indicador base (¿cuánto cuesta el problema hoy?), la meta (¿qué mejora espera en 6 y 12 meses?) y el método de medición (¿qué dato va a demostrar que la IA funcionó?). Esta definición temprana es el contrato que permite evaluar el proyecto objetivamente y defenderlo ante la junta directiva cuando lleguen las preguntas difíciles.

Desde la perspectiva de un gerente de datos, las métricas deben conectarse con el problema de negocio original. No basta con reportar la precisión del modelo: hay que traducir esa precisión en impacto de negocio, por ejemplo, la reducción del tiempo de respuesta al cliente o la disminución de la tasa de abandono. Esta conexión es lo que permite que el proyecto sea defendible ante la junta, porque habla el lenguaje del negocio, no solo el de la tecnología.

Además, la medición debe diseñarse antes de que el proyecto comience, no después. Esto implica definir no solo qué se va a medir, sino cómo se va a medir: qué datos se van a recolectar, con qué frecuencia, y quién será responsable de reportar los resultados. Un sistema de medición bien diseñado es, en sí mismo, una herramienta de gestión, porque permite detectar tempranamente si el proyecto se está desviando de su objetivo y tomar acciones correctivas.

Conclusión ejecutiva

La IA no es un proyecto de tecnología. Es un proyecto de negocio que usa tecnología. Y en Colombia, donde el contexto regulatorio y de mercado tiene particularidades propias, el orden importa más que la velocidad. Empiece por el problema. Valide los datos. Entienda el contexto. Elija la herramienta después. Automatice con criterio. Y mida todo. Así, la IA deja de ser una fascinación para convertirse en una ventaja competitiva real.

Esta hoja de ruta es un marco de decisión: cada paso tiene un propósito claro, un entregable definido y un criterio de éxito explícito. Y para la dirección, es la garantía de que la inversión en IA se traduce en resultados de negocio medibles, no en experimentos tecnológicos sin anclaje organizacional.

En GTEC, entendemos que el contexto colombiano y latinoamericano tiene particularidades que no pueden ignorarse. Por eso, cuando acompañamos a una empresa en su hoja de ruta de IA, empezamos por el problema, validamos los datos, entendemos el contexto regulatorio y de mercado, y solo después hablamos de herramientas. Acompañamos todo el proceso, desde la definición del problema hasta la medición del impacto, porque sabemos que la diferencia entre una buena idea y una ventaja competitiva real está en la disciplina con la que se ejecuta el proyecto, de principio a fin.

_____________________________________________________________________________________----