Cómo implementar IA en los sistemas que ya tenés, sin tirar nada

Hay una brecha que se repite: la empresa probó algo con inteligencia artificial, funcionó en la demo, todos salieron entusiasmados de la reunión, 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 de sobra para lo que necesita una empresa mediana. El piloto se traba en otro lado, y siempre en los mismos cuatro lugares.

Por qué el piloto no llega a producción

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 solo, cada vez. Ese trabajo es el noventa por ciento del proyecto y el cero por ciento de la demo.

Porque nadie era dueño. El piloto lo empujó una persona entusiasmada. Cuando esa persona cambió de prioridad, no quedó ningún proceso que dependiera de eso. Nadie lo extrañó, que es la forma más silenciosa de fracasar.

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

Porque se eligió el caso más impresionante en vez del más aburrido. El caso vistoso suele ser el que más criterio requiere y el que peor tolera un error. Es el que mejor se presenta y el que peor sobrevive al contacto con la operación real.

El orden que sí funciona

Escribir el proceso antes de mirar herramientas

Antes de evaluar plataformas, escribí el proceso como es hoy: quién hace qué, con qué información, en qué sistema queda registrado.

La mitad de las veces ese ejercicio solo ya muestra que el problema no era de IA sino de un paso duplicado o de un permiso que nadie tenía. Sale gratis y ahorra el proyecto entero.

Elegir la herramienta primero es el error más caro que se puede cometer acá, porque después terminás adaptando cómo trabaja tu equipo para que encaje con lo que compraste.

Comprar lo genérico, construir la integración

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; construirlo desde cero hoy no tiene sentido económico.

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, quién se entera. Ahí está el trabajo real y ahí no hay producto que te lo resuelva, porque depende de cómo funciona tu operación.

Poner el humano en el borde, no en cada paso

Un control en cada paso anula el beneficio: si alguien tiene que aprobar todo, no automatizaste nada, agregaste una pantalla.

El humano va en el borde. El flujo corre solo mientras todo entra dentro del criterio, y se detiene cuando algo se sale.

La clave está en definir bien qué es “salirse”, y tiene que ser una regla concreta: un monto por encima de cierto valor, un cliente que no existía, una diferencia contra lo esperado mayor a un porcentaje. Si la definición es “cuando parezca raro”, no hay flujo automático posible.

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 cuando alguien pregunte, ni decidir con criterio si conviene ampliar el alcance. Los tres indicadores que conviene anotar están detallados en beneficios de automatizar, y se registran antes de empezar, porque después ya no se pueden reconstruir.

Si no podés compararlo con 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 una base propia sincronizada desde el CRM y el ERP. No hace falta un data warehouse para empezar, y montarlo antes de tiempo es una forma habitual de gastar seis meses.

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

Registro y alertas. Cada ejecución anotada y un aviso a una persona concreta 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.

Qué significa “en producción”

Conviene acordar la definición antes de empezar, porque “ya está andando” significa cosas distintas para cada uno. Un flujo está en producción cuando cumple las seis:

• Corre solo, sin que nadie exporte ni cargue nada a mano.
• Tiene un dueño con nombre y apellido, no un área.
• Registra cada ejecución con qué hizo y con qué datos.
• Avisa cuando falla, a una persona, por un canal que esa persona mira.
• Existe un número comparable contra el proceso anterior.
• Alguien lo revisó una semana después de arrancar y ajustó lo que hacía falta.

Si falta alguna, todavía es un piloto. No está mal que lo sea; lo que está mal es creer que no.

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 uno de 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. Y si todavía no tenés definido qué proceso atacar primero, ese es el paso anterior: nueve señales para identificarlo.