Con quién implementar IA sin que quede un piloto muerto
La mayoría de los proyectos de inteligencia artificial en empresas no fracasan por la tecnología: fracasan porque nadie definió qué problema resolvían ni cómo se iba a saber si funcionó. Esto es lo que conviene preguntar antes de firmar.
Cuatro cosas que se repiten en el rubro
No son casos aislados: aparecen en casi toda operación de este tipo que reviso.
El piloto que nunca salió de piloto
Funcionó en la demo, no se conectó a nada real, y a los tres meses nadie lo abre.
Nadie definió qué era ganar
Sin un número antes y después, la discusión termina en si «se siente» que sirve.
Le dieron acceso a todo
El caso más caro no es que la IA se equivoque: es que conteste con datos que no debía ver.
Se compró la herramienta antes del problema
Primero la licencia, después buscar en qué usarla. Ese orden casi nunca termina bien.
Los flujos, corriendo
Cómo debería empezar un proyecto de IA
La regla de parada, que casi nadie pide
Qué datos NO se le dan
Qué reviso antes de proponerte nada
Media hora mirando tu operación. Sales sabiendo esto, hagamos algo juntos o no.
Por qué mueren los pilotos
Un piloto de IA casi nunca fracasa por la tecnología. Fracasa porque se armó para demostrar que se podía, no para resolver algo. Funciona en la demo, con datos preparados, y cuando hay que conectarlo a la operación real aparece que nadie definió qué problema resolvía ni cómo se iba a saber si funcionó.
La señal de alarma es fácil de reconocer: si la conversación empieza por la herramienta —«queremos usar tal cosa»— y no por el proceso, el piloto ya nació sin destino.
Elegir un proceso, no un área
El primer proyecto no debería ser «IA para atención al cliente». Debería ser un proceso concreto, repetitivo y medible: responder una pregunta que llega cincuenta veces por semana, clasificar lo que entra, revisar un documento contra una regla.
El criterio para elegirlo es doble: que se repita mucho —si pasa dos veces al mes, no vale la pena— y que se pueda medir hoy. Si no se puede medir cómo está antes, tampoco se va a poder decir si mejoró.
Qué datos NO darle
El riesgo caro de la IA en una empresa no es que se equivoque en una respuesta: es que conteste correctamente con información que no debía ver. Datos de otros clientes, información de salud, condiciones comerciales de terceros, remuneraciones.
Antes de conectar nada hay que escribir dos listas: qué necesita ver para hacer su trabajo, y qué no debe ver nunca. Y acotar el acceso a la primera. Es aburrido y es la diferencia entre una herramienta y un incidente.
En rubros regulados —salud, farmacia, financiero— esto no es una recomendación: define si el proyecto se puede hacer.
La regla de parada
Todo sistema con IA que atiende personas necesita saber cuándo no responder. Un reclamo, un caso de salud, una situación con tono de conflicto: ahí lo correcto es detenerse, armar el contexto y pasarlo a alguien.
Sin esa regla el sistema improvisa, y la respuesta improvisada de una empresa a un reclamo es exactamente el material del que están hechos los problemas públicos.
Qué preguntarle a quien te lo va a implementar
Cinco preguntas alcanzan para saber con quién estás hablando. Qué proceso concreto vamos a atacar primero y por qué ese. Cómo vamos a medir si funcionó, con qué número de partida. Qué datos necesita ver y cuáles no. Qué NO debería contestar solo en mi rubro. Y qué pasa el día que se equivoque: quién se entera y cómo se corrige.
Si las respuestas son sobre modelos y herramientas en vez de sobre tu operación, todavía no estás hablando con la persona correcta.
Qué esperar en plazos
Un primer proceso bien acotado se ve andando en semanas, no en meses, y esa es parte de la prueba: si el primer paso requiere un proyecto de seis meses, está mal recortado.
Lo que sí toma tiempo es lo de antes: ponerse de acuerdo en qué se mide y ordenar los accesos. Es la parte menos vistosa y la que decide el resultado.
Lo que me preguntan siempre
¿Por dónde conviene empezar con IA en una empresa?
Por un proceso concreto, repetitivo y medible, no por un área completa. El criterio: que se repita mucho —si pasa dos veces al mes no vale la pena— y que se pueda medir hoy. Si no se puede medir cómo está antes, tampoco se va a poder decir si mejoró.
¿Por qué la mayoría de los pilotos de IA no llega a producción?
Porque se armaron para demostrar que se podía y no para resolver algo. Funcionan con datos preparados y al conectarlos a la operación real aparece que nadie definió qué problema resolvían ni cómo se sabría si funcionó. La señal de alarma es cuando la conversación empieza por la herramienta y no por el proceso.
¿Qué datos NO hay que darle a una IA?
Todo lo que no necesite para hacer su trabajo: datos de otros clientes, información de salud, condiciones comerciales de terceros, remuneraciones. El riesgo caro no es que se equivoque, es que conteste bien con información que no debía ver. En rubros regulados esto define si el proyecto se puede hacer.
¿Qué le pregunto a quien me ofrece implementar IA?
Qué proceso concreto ataca primero y por qué ese; cómo se va a medir, con qué número de partida; qué datos necesita ver y cuáles no; qué no debería contestar solo en tu rubro; y qué pasa el día que se equivoque. Si las respuestas son sobre modelos y herramientas en vez de sobre tu operación, no es la persona.
¿Cuánto demora implementar IA en un proceso?
Un primer proceso bien acotado se ve andando en semanas. Si el primer paso requiere un proyecto de seis meses, está mal recortado. Lo que sí toma tiempo es lo previo: acordar qué se mide y ordenar los accesos.
¿Arrancamos por la auditoría?
Sin costo y sin compromiso. Si tu caso no es mío, te lo digo.
Una idea por semana para automatizar tu negocio
Cosas que estoy probando con IA en operaciones reales. Sin relleno, y te das de baja cuando quieras.