Cómo implementar IA sobre los sistemas que ya tenés

Hay una brecha que se repite en casi todas las empresas con las que trabajamos: probaron algo con inteligencia artificial, funcionó en la demo, y un año después sigue sin estar en producción.

No es un problema de tecnología. Los modelos hace rato que alcanzan para lo que una empresa mediana necesita. El piloto queda trabado en otro lado.

Por qué el piloto no escala

Porque no estaba conectado a nada. La demo corría con un archivo exportado a mano. Para que sirva de verdad tiene que leer del sistema real, escribir en el sistema real y hacerlo cada vez, sin que nadie exporte nada.

Porque nadie era dueño. El piloto lo empujó una persona con entusiasmo. Cuando esa persona cambió de prioridad, no quedó ningún proceso que dependiera de eso. Nadie lo extrañó.

Porque no había forma de saber si andaba bien. Sin registro de ejecuciones, sin alertas cuando falla, sin un número que compare contra el proceso anterior. Al primer resultado raro, el equipo dejó de confiar y volvió al Excel.

Porque se eligió el caso más impresionante en lugar del más aburrido. El caso vistoso suele ser el que más criterio requiere y el que peor tolera un error.

El orden que sí funciona

Empezar por el proceso, no por la herramienta

Antes de evaluar plataformas, escribí el proceso como es hoy: quién hace qué, con qué información, en qué sistema queda. La mitad de las veces ese ejercicio solo ya muestra que el problema no era de IA sino de un paso duplicado.

Elegir la herramienta primero es el error más caro. Termina condicionando cómo trabajás para que encaje con lo que compraste.

Comprar lo que existe, construir lo que no

En 2026 casi todo lo genérico ya viene resuelto. Clasificar texto, extraer campos de un documento, resumir, responder sobre una base propia: eso se compra y se conecta.

Lo que hay que construir es la integración. Cómo entra el dato, cómo se valida, dónde queda registrado, qué pasa cuando falla. Ahí es donde está el trabajo real y donde no hay producto que te lo resuelva, porque depende de tu operación.

Poner el humano en el lugar correcto

No en cada paso —eso anula el beneficio— sino en el borde. El flujo corre solo mientras todo entra dentro del criterio; cuando algo se sale, se detiene y avisa.

La clave es definir bien qué es “salirse”. Un monto por encima de cierto valor, un cliente nuevo, una diferencia contra lo esperado. Reglas concretas, no intuición.

Medir contra el proceso viejo

Cuánto tardaba antes, cuánto tarda ahora. Cuántos errores había antes, cuántos hay ahora. Sin ese par de números no vas a poder defender la inversión ni decidir si conviene ampliar.

Si no podés medirlo contra lo que hacías antes, no es un proyecto: es una prueba.

Qué hace falta técnicamente

Menos de lo que se supone. En la mayoría de los casos alcanza con tres piezas:

Un lugar donde vivan los datos que la IA va a consultar. Puede ser tu propia base, sincronizada desde el CRM y el ERP. No hace falta un data warehouse para empezar.

Una capa de orquestación que decida cuándo se dispara cada cosa, en qué orden y qué pasa si un paso falla. Acá es donde entran las plataformas de automatización, y donde conviene no escribir código propio si no hace falta.

Registro y alertas. Cada ejecución anotada, y un aviso cuando algo se rompe. Es la parte que nadie muestra en las demos y la única que hace que el sistema sobreviva al primer mes.

El plazo realista

Un flujo acotado, bien elegido, con los datos razonablemente en orden, está en producción en semanas. No en meses.

Los proyectos que tardan un año casi siempre tardan por dos motivos: se eligió un alcance demasiado ambicioso para el primer paso, o los datos estaban peor de lo que se creía y nadie lo revisó antes de arrancar.

Las dos cosas se detectan en la primera semana si se hace un diagnóstico honesto en vez de una demo.