Qué construir, qué comprar, a qué ritmo y a qué costo: las cuatro decisiones que definen una estrategia de IA

Hay un momento en casi toda conversación empresarial sobre IA en el que alguien dice: “Hemos decidido hacerlo internamente”.

Se dice con seguridad, y normalmente es una señal de seriedad. La organización ha dejado de tratar la IA como un experimento y ha empezado a tratarla como infraestructura. Ese instinto es correcto.

Pero la frase responde a una pregunta que nadie hizo. Quién ejecuta es una decisión de recursos. No dice nada sobre qué se construye, qué se compra, qué tan rápido avanza la organización ni qué resultado se supone que debe producir todo ese esfuerzo. Cuando esas cuatro preguntas quedan sin respuesta, añadir capacidad de ejecución no produce una estrategia. Produce movimiento.

Y el movimiento es precisamente de lo que están hechos muchos programas empresariales de IA. No fracaso: movimiento. Herramientas desplegadas, procesos automatizados, horas recuperadas, dashboards activos. Doce o dieciocho meses después, la capacidad existe, el gasto se justifica sobre el papel y la empresa sigue operando, en esencia, de la misma manera que antes.

Esto no es un argumento en contra de desarrollar capacidad interna. Las organizaciones que nunca la construyen quedan permanentemente dependientes de terceros, lo cual representa otra trampa. El argumento es hacia dónde se dirige esa capacidad interna y cuáles son las cuatro decisiones que determinan si se convierte en una ventaja que crece con el tiempo o simplemente mantiene la operación en marcha.

Antes de las cuatro decisiones: el techo de ambición

Toda decisión de IA que toma una organización se responde desde el nivel de ambición en el que está operando. La mayoría opera en el nivel más bajo y cree que está en el más alto.

Conviene separar tres niveles que casi siempre se tratan como si fueran uno solo.

Nivel uno: automatización

Hacer lo que ya haces, más rápido o más barato. Es el nivel más visible y el más fácil de justificar internamente, porque puede medirse con claridad en horas y costos. También es el más limitado: una operación automatizada sigue siendo la misma operación. Lo que cambia es su capacidad de ejecución, no su naturaleza.

Casi toda la actividad empresarial alrededor de la IA vive aquí. Una herramienta de automatización conectada a un proceso existente. Un agente que redacta lo que antes redactaba una persona. Ahorros reales, correctamente medidos y estratégicamente inertes.

Nivel dos: visibilidad

Hacer que la operación sea legible. La mayoría de las organizaciones no pueden observar su propia operación con precisión: está dispersa entre correos, llamadas, hojas de cálculo y la memoria de quienes llevan más tiempo en la empresa. Convertir todo eso en una realidad estructurada y consultable representa un salto real, y sigue siendo poco común.

Aquí es donde muchas iniciativas de IA fracasan silenciosamente. No porque el modelo haya sido incorrecto, sino porque fueron construidas sobre una base que no existía. La visibilidad no es glamorosa, no luce especialmente bien en una demo y casi nadie quiere financiarla. También es la condición previa para todo lo que viene después.

Pero la visibilidad tampoco es el destino. Ver la operación con claridad es una posición de partida, no un resultado.

Nivel tres: inteligencia del negocio

Entender tu propia operación con una profundidad que ningún competidor posee y utilizar esa posición para interpretar hacia dónde se mueve la industria y decidir hacia dónde llevar la empresa antes que los demás.

Aquí es donde se encuentra el verdadero retorno de la IA, y es un territorio que sigue prácticamente vacío. La evidencia está en la ausencia de pensamiento estratégico sobre el propio sector. Las organizaciones que viven dentro de una industria todos los días, y que la conocen con un nivel de detalle que ningún analista externo podría reconstruir, deberían ser las primeras en anticipar su dirección.

En la práctica, el patrón suele ser reactivo: leer un informe de la industria, adoptar una herramienta para no quedarse atrás y repetir el ciclo. La estrategia termina externalizada a quien publicó el informe.

El riesgo ya no es no automatizar. Es automatizarlo todo y aun así no saber hacia dónde vas.

Por eso esto importa antes de cualquier discusión sobre construir, comprar, ritmo o costo: un equipo que recibe un mandato de nivel uno responderá las cuatro decisiones desde el nivel uno. De manera competente. Dentro del presupuesto. Y sin ningún efecto estratégico.

No es un problema de competencia. Es un problema de mandato. Y los mandatos están definidos por lo que el liderazgo cree que es posible, precisamente aquello que una organización difícilmente puede evaluar desde dentro de sus propios supuestos operativos.

Por qué “construir o comprar” es una pregunta de compras

Este planteamiento viene del mundo de la adquisición de software. Pero la IA no se comporta como el software tradicional.

La disyuntiva entre construir o comprar nació en un mundo donde aquello que se adquiría era estable. Se evaluaba un sistema, se elegía a un proveedor o un equipo interno, se implementaba durante un año o más y luego se utilizaba durante una década. La decisión era importante porque era duradera.

La IA invierte esa lógica. La capacidad subyacente cambia cada pocos meses. Lo que el año pasado requería un equipo especializado hoy puede ser una capacidad estandarizada. Y lo que hoy está estandarizado mañana puede convertirse en una ventaja diferenciadora en cuanto se combina con datos propietarios y criterio propio.

Una arquitectura de decisiones diseñada para la permanencia funciona mal en un entorno definido por el cambio constante.

Entonces la organización toma una gran decisión estructural —contratar al equipo, firmar con la plataforma— y considera terminado el trabajo estratégico. Las cuatro decisiones que realmente determinan el resultado nunca se toman de forma explícita.

Terminan tomándose por defecto, distribuidas entre compras, TI, finanzas y las distintas unidades de negocio. Cada decisión es razonable de manera aislada y, en conjunto, profundamente incoherente.

Casi ninguna organización tiene escasez de herramientas de IA. La mayoría tiene escasez de decisiones claras sobre ellas.

Decisión uno: qué construir

Construye únicamente aquello cuyo valor aumente con el tiempo. Todo lo demás es una responsabilidad de mantenimiento disfrazada de estrategia.

El instinto de muchas organizaciones es construir aquello que resulta más fácil de construir. Dashboards internos. Una interfaz de chat sobre documentos corporativos. Una automatización que le ahorra unas horas de trabajo semanal a un equipo.

Se implementan rápido, funcionan bien en una demo y generan una sensación visible de avance.

Pero rara vez vale la pena construirlas internamente. La facilidad de construcción y el valor estratégico tienen muy poca correlación y, en muchos casos, una relación inversa: los proyectos fáciles son fáciles precisamente porque alguien más ya convirtió esa capacidad en algo estandarizado.

La prueba del valor acumulativo

Una capacidad merece ser construida cuando cumple tres condiciones al mismo tiempo:

• Funciona con datos que solo tu organización posee. No datos que podrías adquirir, sino datos que existen como consecuencia directa de cómo opera tu negocio y que un competidor no podría comprar a ningún precio.
• Codifica un criterio que es específicamente tuyo. La lógica de decisión acumulada de tu operación: cómo estableces precios, cómo evalúas riesgos, cómo secuencias el trabajo y qué ha aprendido la organización que no debe hacer.
• Mejora con el uso. Cada ciclo operativo la vuelve más valiosa. Si utilizarla no crea un activo, has construido una herramienta, no una capacidad.

Si falla cualquiera de estas condiciones, construir internamente es el camino más caro hacia un resultado estandarizado.

Si cumple las tres, ningún tercero puede construirla realmente por ti, porque los elementos que la hacen valiosa no existen fuera de tu operación.

La categoría que nadie contempla

Existe una tercera respuesta que la mayoría de los roadmaps no tienen forma de producir: vale la pena construirlo, pero todavía no.

Son capacidades que generarán valor acumulativo una vez que los datos subyacentes estén estructurados, que el proceso sea suficientemente estable como para codificarlo y que la organización pueda determinar con confianza si el resultado es bueno.

Construirlas demasiado pronto produce sistemas costosos entrenados sobre información incoherente que, tarde o temprano, tendrán que reconstruirse desde cero.

Saber qué posponer es tan valioso como saber qué construir, y considerablemente más difícil de justificar ante un comité directivo.

Decisión dos: qué comprar

La disciplina no consiste en elegir mejor entre distintas plataformas. Consiste en necesitar menos.

La mayoría de las organizaciones aborda esta decisión al revés. Analizan el mercado, evalúan categorías y ensamblan un stack tecnológico. Después intentan adaptar la operación a lo que compraron.

El resultado es predecible: una herramienta para ventas, otra para soporte, otra para documentos, otra para automatización. Cada una comprada por una función distinta, siguiendo una lógica distinta y sin conocimiento de las demás.

En ese momento, la integración se convierte en el verdadero trabajo.

La capacidad de ingeniería que supuestamente iba a crear una ventaja termina consumida en mantener comunicándose entre sí un conjunto de sistemas superpuestos.

La organización ahora mantiene un stack que nunca diseñó realmente, y cada plataforma adicional hace que la siguiente decisión sea más difícil.

Cada plataforma que incorporas añade una superficie operativa que probablemente permanecerá durante años. El instinto correcto no es elegir mejor. Es necesitar menos.

La secuencia que funciona es la contraria.

Primero, entender la operación con suficiente precisión para identificar dónde se concentra el valor y dónde se pierde. Después, diseñar cómo debería funcionar esa operación.

Solo entonces aparece la pregunta sobre proveedores externos. Y para ese momento la decisión es pequeña, específica y mucho menos controvertida.

Ya no estás saliendo de compras. Estás cubriendo una necesidad definida dentro de una arquitectura definida.

Esto cambia lo que significa comprar. Deja de ser una decisión estratégica y se convierte en la consecuencia de una decisión estratégica que ya fue tomada. Ese es el papel que debería tener.

Comprar tecnología no sustituye entender tu propia operación. Ninguna cantidad de herramientas producirá ese entendimiento.

Hay dos restricciones que vale la pena mantener siempre presentes:

• Costo de salida. Si no podrías retirar un sistema en un trimestre sin sufrir una pérdida significativa, no compraste una herramienta. Creaste una dependencia. Y las dependencias terminan defendiéndose internamente precisamente porque son difíciles de eliminar.
• Dónde vive tu contexto. Un sistema que almacena tu conocimiento operativo dentro de una interfaz cerrada, inaccesible para cualquier otra herramienta, está extrayendo más valor del que aporta. El contexto debe seguir siendo tuyo.

Decisión tres: a qué ritmo

El ritmo no es un efecto secundario de la planificación. Determina cuántas veces puedes permitirte estar equivocado sin que resulte demasiado costoso.

Recibe menos atención deliberada que cualquiera de las otras tres decisiones y, sin embargo, podría ser la más importante.

Las organizaciones rara vez eligen conscientemente su ritmo. Lo heredan de sus ciclos de contratación, sus procesos de compras y sus calendarios presupuestarios.

Y ese ritmo heredado suele fallar de una manera muy específica: es demasiado lento para aprender y, al mismo tiempo, demasiado rápido para consolidar.

Dos formas de fallar

Avanzar lentamente es el fracaso más común y el más difícil de detectar, porque se parece mucho a la diligencia.

Una secuencia de doce meses entre evaluación, selección de proveedores, contratación e incorporación puede justificarse perfectamente en cada una de sus etapas.

El problema es que, a lo largo de ese período, los supuestos sobre los que se construyó el plan original empiezan a perder vigencia.

Para cuando la capacidad finalmente existe, fue diseñada para condiciones que ya no existen.

Avanzar demasiado rápido fracasa de otra manera.

Una gran cantidad de pilotos, ninguno integrado realmente en la forma en que ocurre el trabajo. Mucha actividad, demos convincentes y nada funcionando en producción.

La organización acumula artefactos en lugar de capacidades.

Velocidad de aprendizaje sobre velocidad de entrega

La pregunta no es cuánto entregas. Es con qué frecuencia descubres si algo realmente funciona bajo condiciones operativas reales, con personas reales y consecuencias reales.

Una organización que pone doce sistemas pequeños en uso real durante un año aprende doce veces.

Otra que utiliza ese mismo año para desarrollar una plataforma integral aprende una sola vez: al final, justo cuando equivocarse resulta más caro.

Esto tiene una consecuencia directa sobre el alcance.

Los sistemas pequeños que llegan a producción enseñan más que los sistemas amplios que solo llegan a una demo.

El impulso de construir primero la solución general antes de resolver el problema específico es una de las formas más fiables de pasar un año entero sin aprender nada.

Decisión cuatro: a qué costo

El costo no es un número. Es una relación. Y la mayoría de las organizaciones la calcula mal porque utiliza el resultado equivocado como referencia, no porque estime mal el precio del trabajo.

“¿Cuánto va a costar?” es una pregunta imposible de responder de manera aislada.

El costo solo significa algo cuando se compara contra un resultado. Y es precisamente en la definición de ese resultado donde suele producirse el verdadero error.

Las organizaciones se anclan a los únicos resultados que actualmente pueden ver: horas ahorradas, contrataciones evitadas, costos reducidos.

Esos son resultados de nivel uno.

Y una vez que se convierten en el denominador, las matemáticas nunca justifican una transformación real.

Si el objetivo consiste en recuperar doscientas horas al mes, cualquier inversión seria parecerá costosa. No porque lo sea, sino porque está siendo evaluada contra una ambición demasiado pequeña para justificarla.

El error más caro no es gastar demasiado en IA. Es gastar correctamente contra la ambición equivocada.

La pregunta que realmente importa

¿Qué métrica, si cambiara, alteraría la trayectoria del negocio?

No qué proceso es el más lento.

No qué equipo está más sobrecargado.

¿Qué número, si se moviera de forma significativa, cambiaría lo que la empresa puede llegar a ser?

Muy pocas organizaciones pueden responder esta pregunta, y la razón es estructural más que analítica.

No puedes identificar el resultado que la IA podría producir si no sabes qué hace posible la IA.

Por eso, la pregunta termina reemplazándose por otra que sí puede responderse desde los supuestos actuales: ¿qué proceso nos está causando más problemas?

Y todo el programa hereda ese mismo techo de ambición.

Optimizar lo que no debería existir

Esto produce uno de los errores que mejor define el momento actual: aplicar IA a procesos que la propia IA podría volver innecesarios.

Un proceso mejorado en un 30% es un proceso que la organización acaba de comprometerse a mantener.

La herramienta ya fue construida. El equipo fue capacitado. Los ahorros fueron reportados.

Ahora resulta considerablemente más difícil plantear una pregunta mucho más importante: ¿debería existir este proceso?

La eficiencia, aplicada a lo equivocado, puede convertirse en una forma de consolidar aquello que debería desaparecer.

Los costos que nadie modela

Una vez definido correctamente el resultado, todavía hace falta ser honestos respecto al costo.

Los números visibles —personas y licencias— suelen representar solo una parte del total.

• Deuda de mantenimiento. Todo sistema construido debe mantenerse, actualizarse, protegerse y eventualmente migrarse. Es casi inexistente al momento del lanzamiento y aumenta de manera constante después.
• Infraestructura de conocimiento. Los sistemas de IA están limitados por aquello que pueden recuperar, no únicamente por el modelo que utilizan. Cuando el rendimiento decepciona, muchas veces la causa es que el conocimiento institucional nunca se documentó o vive en lugares inaccesibles. Resolverlo se convierte en un programa de trabajo que nadie había presupuestado.
• Gobernanza y evaluación. Determinar si un sistema continúa funcionando correctamente es trabajo operativo permanente. Los sistemas que no se evalúan se degradan silenciosamente, y la degradación silenciosa suele ser la más costosa.
• Preparación organizacional. El costo de lograr que las personas realmente trabajen de una forma distinta. Con frecuencia es el componente no presupuestado más grande y una de las principales razones por las que un sistema técnicamente exitoso no produce resultados de negocio.
• Costo de oportunidad del retraso. Nunca aparece como una partida de gasto. Aparece como competidores avanzando más rápido.

Las cuatro decisiones son una sola decisión

Se toman por personas distintas, en momentos distintos y en reuniones distintas. Ese es el problema estructural.

Estas decisiones no son independientes.

• Lo que construyes determina lo que tendrás que mantener. La decisión uno establece un piso para la decisión cuatro.
• El ritmo que eliges limita lo que puedes construir. La decisión tres condiciona la decisión uno.
• Lo que compras determina qué tan rápido puedes moverte. La decisión dos habilita o limita la decisión tres.
• Y las cuatro se responden desde el nivel de ambición con el que se definió el mandato original.

Por eso añadir capacidad no resuelve el problema.

Más recursos de ejecución aumentan la cantidad de cosas que pueden hacerse. No generan coherencia entre cuatro decisiones interdependientes que nunca se pensaron como un conjunto.

Tampoco elevan el techo de ambición, porque el mandato fue definido antes de que llegaran esos recursos.

Vale la pena señalar un patrón que se ha vuelto común.

Muchas organizaciones tienen hoy una función interna de IA que, en la práctica, es una función de TI con un nombre nuevo: conectar herramientas de automatización, automatizar pasos existentes y entregar mejoras de procesos.

El trabajo es real y, con frecuencia, está bien ejecutado.

Pero permanece en el nivel uno porque eso es exactamente lo que el mandato pidió.

La limitación casi nunca está en quién ejecuta. Está en qué se le pidió ejecutar y en si alguien tuvo la perspectiva suficiente para pedir algo más.

Dónde encaja Creai

Creai existe para conectar tres cosas que casi siempre están desconectadas dentro de una organización: visión, operación y ejecución.

La visión suele vivir en el nivel de liderazgo, expresada en términos demasiado abstractos para poder construir a partir de ellos.

La operación vive en el día a día, entendida en detalle por las personas que la ejecutan y prácticamente invisible para todos los demás.

La ejecución vive en equipos técnicos que trabajan a partir de requisitos que no fueron realmente definidos desde ninguna de las dos anteriores.

Cada función está haciendo su trabajo. Es en la conexión entre ellas donde desaparece el valor.

Lo que hacemos:

• Leer la operación con precisión. Antes de diseñar cualquier sistema, la operación tiene que volverse legible: dónde se concentra el valor, dónde se pierde y qué sabe realmente la organización pero nunca ha documentado.
• Definir la ambición alrededor de un resultado real. Identificar la métrica capaz de cambiar la trayectoria del negocio, en lugar del proceso que actualmente genera más fricción. Esta es la decisión de la que dependen las otras cuatro y también la más difícil de alcanzar desde dentro de la organización.
• Diseñar y construir aquello cuyo valor aumenta con el tiempo. Sistemas basados en tus datos y tu criterio, diseñados para poder reemplazarse conforme avanza la tecnología y con la menor dependencia externa que la arquitectura realmente requiera.
• Preparar a la organización para operarlos. La gestión del cambio y la transferencia de capacidades no son una fase posterior. La mayoría de los programas de IA no fracasan técnicamente: fracasan porque la organización nunca estuvo preparada para trabajar de una forma distinta. Construir el sistema es solo una parte del trabajo.

Con clientes que ya cuentan con un equipo interno, nada de esto compite con él. Cambia aquello en lo que ese equipo está trabajando.

Un equipo técnico competente que lleva dieciocho meses automatizando procesos existentes no necesariamente está teniendo un mal desempeño. Puede estar ejecutando perfectamente un mandato cuyo nivel de ambición fue definido demasiado bajo.

Elevar ese mandato y después preparar a la organización para operar en ese nuevo nivel es parte del trabajo.

Con clientes que todavía no cuentan con esa capacidad interna, ejecutamos y la construimos junto con ellos, para que la organización termine siendo propietaria de una capacidad y no simplemente rentándola.

En ambos casos, el objetivo es el mismo: una organización capaz de observar claramente su propia operación, identificar qué resultados merece la pena perseguir y decidir hacia dónde avanzar antes que sus competidores.

Esa es la capacidad cuyo valor crece con el tiempo.

No las herramientas.

No el número de personas.

→ Conoce cómo trabajamos en Creai

Preguntas frecuentes

¿Deberíamos construir un equipo interno de IA o trabajar con un socio externo?

Esa no es la primera pregunta que debería hacerse.

Ambos modelos pueden funcionar y ambos pueden fracasar por la misma razón: la organización decidió quién ejecutaría antes de resolver qué construir, qué comprar, a qué ritmo avanzar y contra qué resultado medir el esfuerzo.

Esas cuatro decisiones determinan qué tipo de capacidad de ejecución necesitas y en qué secuencia.

Respóndelas primero y la decisión sobre recursos se vuelve mucho más clara.

¿Cómo decidimos qué capacidades de IA debemos construir internamente?

Aplica tres criterios al mismo tiempo.

¿Funciona con datos que solo posee tu organización? ¿Codifica un criterio específico de cómo opera tu negocio? ¿Mejora con el uso?

Una capacidad que cumple los tres no puede comprarse realmente, porque aquello que la hace valiosa no existe fuera de tu operación.

Una capacidad que falla cualquiera de ellos casi siempre será más rápida y económica de adquirir externamente.

Y existe una tercera respuesta que casi ningún roadmap contempla: vale la pena construirla, pero todavía no.

¿Cuántas plataformas de IA debería utilizar una empresa?

Menos de las que utiliza actualmente.

Cada plataforma adoptada añade una superficie operativa permanente, y las organizaciones que compran antes de comprender su propia operación terminan utilizando su capacidad de ingeniería para integrar sistemas que nunca fueron diseñados como un conjunto.

La secuencia correcta es mapear la operación, diseñar la arquitectura objetivo y permitir que el pequeño número de proveedores externos que realmente necesitas aparezca como consecuencia de ese diseño, no como punto de partida.

¿Por qué las iniciativas empresariales de IA generan ahorros pero no cambios estratégicos?

Porque fueron definidas alrededor de los únicos resultados visibles desde los supuestos actuales: horas ahorradas, costos reducidos o crecimiento de plantilla evitado.

Son resultados reales, pero estratégicamente inertes: una operación automatizada sigue siendo la misma operación funcionando más rápido.

Peor aún, un proceso mejorado en un 30% es un proceso que la organización ahora se ha comprometido a mantener, lo que dificulta cuestionar si debería existir en primer lugar.

¿Cuál es el costo total real de una capacidad de IA?

Las personas y las licencias suelen representar solo una parte del costo total.

Los costos más grandes y menos visibles incluyen la deuda de mantenimiento que se acumula con el tiempo, la infraestructura de conocimiento que muchas veces solo se descubre como necesidad después de implementar, la gobernanza y evaluación continua, la preparación organizacional —con frecuencia el mayor componente no presupuestado— y el costo de oportunidad del retraso, que nunca aparece como una línea de gasto y puede terminar siendo el más importante de todos.

¿Qué tan rápido debería avanzar una organización con IA?

Lo suficientemente rápido como para que los supuestos no pierdan vigencia antes de que la capacidad exista, y con suficiente disciplina para que los sistemas lleguen a un uso real en producción en lugar de acumularse como pilotos.

La métrica que importa es la velocidad de aprendizaje, no la velocidad de entrega: con qué frecuencia descubres si algo funciona bajo condiciones reales.

Los sistemas pequeños en producción enseñan más que los sistemas grandes que nunca pasan de una demo.