Cuánto tiempo toma implementar IA en una empresa (con plazos reales)

La conversación que se repite en cada primera reunión

La primera reunión con un cliente nuevo casi nunca empieza hablando de tecnología. Empieza con una pregunta de calendario: “¿para cuándo lo tenemos funcionando?”. Y ahí es donde el proyecto se puede torcer antes de arrancar, porque el número que el cliente trae en la cabeza suele venir de un post en redes o de un proveedor anterior que prometió “IA en dos semanas”. Ese número entra a la sala como si fuera un hecho, no como la promesa comercial que en realidad es, y todo lo que sigue en el proyecto se termina midiendo contra él.

Lo que he visto una y otra vez es que dos empresas del mismo rubro, con la misma necesidad y el mismo tipo de proyecto, terminan en calendarios completamente distintos. Una tiene el proyecto operando en diez semanas. La otra sigue en reuniones de alineación a los cuatro meses, sin que el equipo técnico haya tocado todavía una sola línea del modelo. A ninguna de las dos la engañaron: la diferencia estaba en el punto de partida, no en el contrato que firmaron. Y cuando nadie explica esa diferencia antes de firmar, se convierte en el reclamo del cliente al proveedor en el mes tres, cuando alguien en el directorio pregunta por qué “la IA” todavía no está lista.

Qué define el plazo en realidad (y qué no)

Antes de dar un solo rango de semanas hay que aclarar qué es lo que de verdad mueve la aguja del cronograma. No es el modelo de lenguaje que se use, no es el proveedor que se contrate y tampoco es, en la mayoría de los casos, el tamaño del presupuesto disponible. Son dos variables mucho menos vistosas y mucho más difíciles de resolver con dinero.

El estado de los datos no es una pregunta de sí o no, es un espectro. Hay empresas con la información centralizada, con un responsable claro y con años de historial limpio, y hay empresas con esa misma información repartida en media docena de hojas de cálculo que nadie concilia entre sí. Entre esos dos extremos hay meses de diferencia, y ningún proveedor se los salta por más experiencia que tenga.

La segunda variable pesa tanto como la primera y se discute mucho menos: cuántas áreas tienen que decir que sí antes de que el proyecto avance de verdad. Un proyecto que depende solo del área que lo pidió se puede mover rápido. Un proyecto que necesita el visto bueno de legal, de TI y de la gerencia dueña de los datos se mueve al ritmo de la reunión más lenta de las tres, no al ritmo del equipo técnico.

Buena parte de esto se puede adelantar antes de firmar nada, revisando el checklist previo: quién es el dueño del dato, qué tan limpio está y quién más tiene que aprobar el proyecto.

Rangos honestos por tipo de proyecto

Los números que siguen no son un estudio ni una tabla de precios de ningún proveedor: son lo que he visto repetirse en proyectos reales, declarado como observación de mercado, no como promesa para un proyecto en particular. Cada empresa se puede mover fuera de estos rangos, en cualquier dirección, según las dos variables de la sección anterior.

• Automatizar una tarea puntual (clasificar correos, generar un reporte, resumir documentos repetidos): esto suele quedar funcionando en producción en algo así como 3 a 6 semanas, cuando el proceso ya está bien definido y no depende de sistemas viejos.
• Un asistente o agente interno conectado a la documentación de la empresa: en los casos que conozco esto toma entre 6 semanas y 3 meses, porque la mayor parte del tiempo se va en ordenar y limpiar esa documentación, no en configurar el modelo.
• Un chatbot de cara al cliente integrado con los sistemas de atención: el rango que suelo ver se mueve entre 2 y 4 meses, porque además de la conversación entra en juego la integración con el CRM o el sistema de tickets.
• Un modelo predictivo sobre datos propios (fuga de clientes, demanda, riesgo de mora): cuando el histórico ya existe y está limpio, 2 a 3 meses es razonable, y cuando no, he visto este mismo proyecto estirarse a 8 o 9 meses solo por el trabajo de datos.
• Una transformación que toca varias áreas (ventas, operaciones y finanzas decidiendo con el mismo modelo): acá el plazo deja de medirse en semanas. Los casos que conozco van de 6 meses a más de un año, y lo que manda no es la tecnología sino cuántas áreas tienen que ceder algo de su forma de trabajar actual.

Estos rangos también explican por qué las fases de implementación de IA en una empresa no se recorren a la misma velocidad en todos los proyectos: cada fase se estira o se acorta según el tipo de proyecto y el estado de las dos variables que ya vimos.

Los 5 factores que alargan el plazo

Casi todos los retrasos que he visto se explican con la misma lista corta de causas, y ninguna de ellas tiene que ver con que el modelo “no funcione”. Los cinco factores que más pesan son estos.

• El estado real de los datos: no si existen, sino si están limpios, completos y en un solo lugar. Ordenar datos dispersos en tres sistemas que no se hablan entre sí puede tomar más tiempo que construir el modelo mismo.
• La cantidad de áreas que tienen que aprobar el proyecto: cuando ventas, legal y TI tienen que sentarse a acordar qué información se comparte y cómo, cada reunión que se pospone suma una semana entera al cronograma.
• La dependencia de sistemas antiguos: conectar un modelo nuevo a un sistema de hace quince años casi siempre exige más esfuerzo de integración que entrenar el modelo en sí.
• La disponibilidad de quien conoce el proceso: sin alguien del área operativa validando reglas y excepciones, el equipo técnico avanza construyendo sobre supuestos que después hay que deshacer.
• Los cambios de alcance a mitad de camino: agregar “ya que estamos, que también prediga esto otro” en la semana 6 de un proyecto de 8 no es un ajuste menor, es reiniciar buena parte del trabajo de datos.

Este último factor es, en mi experiencia, el que más golpea un cronograma ya aprobado, y aparece de forma recurrente entre los errores al implementar IA en una empresa.

Qué se puede tener funcionando en 30 días y qué no

Treinta días alcanzan para bastante menos de lo que la mayoría espera, y para bastante más de lo que algunos proveedores admiten en la propuesta. La clave es separar qué cabe en ese plazo por diseño y qué necesita más tiempo, no por lentitud de nadie sino por naturaleza del trabajo.

En 30 días, sí

• Un prototipo funcionando sobre una muestra real de datos: no todos los datos de la empresa, una muestra representativa que sirve para validar si la idea funciona antes de comprometer meses de trabajo.
• Una prueba de concepto acotada a un solo caso de uso: responder cinco tipos de pregunta frecuente, por ejemplo, no las cincuenta que existen en el negocio.
• Una primera validación con un grupo pequeño de usuarios internos: suficiente para saber si el enfoque tiene sentido, no para decir que “ya está en producción”.
• Un diagnóstico honesto del estado de los datos: muchas veces es el resultado más valioso de las primeras semanas, aunque no se vea como un entregable vistoso.

Ese es exactamente el objetivo de una prueba de concepto de IA en dos semanas bien acotada: no busca llegar a producción, busca decidir con evidencia si el proyecto grande vale la pena.

En 30 días, no

• Integración completa con todos los sistemas de la empresa: conectar un modelo a un CRM, un ERP y un sistema de tickets al mismo tiempo, con seguridad y permisos correctos, no es trabajo de un mes.
• Adopción real en todas las áreas involucradas: que la gente cambie cómo trabaja todos los días toma más que una capacitación de una hora.
• Una revisión seria de seguridad y cumplimiento: sobre todo cuando se manejan datos de clientes o información financiera.
• Un modelo entrenado y validado sobre el histórico completo, no sobre una muestra: eso solo pasa cuando ya se resolvió el estado de los datos de fondo.

Un plan de 90 días para implementar IA en una empresa suele ser, en la mayoría de los casos, un marco más realista que treinta días para llegar de la idea a algo que opera todos los días sin que alguien lo esté vigilando manualmente.

Por qué la demo llega rápido y la producción no

La demo casi siempre funciona bien, y eso es parte del problema: genera una expectativa que la producción todavía no puede cumplir. La demo se construye sobre datos elegidos a mano, con los casos más limpios del negocio, delante de un grupo pequeño de personas que saben qué preguntar y qué no. Es una condición de laboratorio, no la operación real.

La producción, en cambio, tiene que sostener todo lo que la demo dejó afuera a propósito: los datos sucios que nadie limpió, las preguntas que un usuario real hace de formas que nadie anticipó, los picos de uso, los permisos de quién puede ver qué información, y el mantenimiento del sistema cuando el comportamiento del negocio cambia con el tiempo. Nada de eso se ve en una demo de cuarenta minutos, y todo eso es trabajo real que alguien tiene que hacer antes de decir que el proyecto está en producción.

Ese salto de la demo a la operación diaria es, en buena parte, lo que distingue a la inteligencia artificial para empresas de un experimento bonito corriendo en la laptop de un consultor.

Cómo detectar un cronograma de proveedor que no se va a cumplir

Un cronograma de proveedor se puede leer con la misma lógica con la que se lee un contrato: lo importante casi nunca está en lo que dice, está en lo que calla. Estas son las señales que reviso antes de aceptar cualquier fecha.

• Precio y plazo cerrados antes de ver tus datos: si te cotizan sin haber revisado un solo archivo de tu empresa, ese número es una suposición, no una estimación.
• El cronograma no menciona quién de tu equipo tiene que participar y cuánto tiempo: un plazo real depende de que alguien de tu lado revise y apruebe cosas, y si esa dependencia no está en el documento, tampoco está contemplada.
• Todas las fases duran exactamente lo mismo: cuando cada etapa del proyecto ocupa dos semanas sin importar su complejidad, lo que tienes enfrente es una plantilla genérica, no una estimación basada en tu caso.
• No hay una fase explícita de orden y limpieza de datos: si el cronograma salta directo de “kickoff” a “modelo entrenado”, ya se comieron la parte que en la práctica suele tomar más tiempo que el resto del proyecto junto.
• La “producción” del contrato en realidad describe una demo: hay que preguntar explícitamente si ese plazo incluye integración con los sistemas reales, seguridad y el volumen real de usuarios, o solo un ambiente de prueba.

Ninguna de estas señales significa mala fe por sí sola. La mayoría de las veces es una plantilla comercial reciclada de otro cliente, con otro estado de datos y otras áreas involucradas. El problema no es que exista la plantilla, es firmarla sin que nadie la ajuste a tu caso.

Mi criterio sobre los plazos que se prometen

El plazo se descubre, no se cotiza

La pregunta que de verdad vale la pena hacerle a cualquier proveedor no es “¿cuánto va a tardar?”, sino qué va a hacer en las primeras dos semanas para averiguarlo con tus datos reales. Si la respuesta es un cronograma cerrado sin haber tocado todavía una sola tabla de tu empresa, lo que tienes enfrente es un precio, no un plan.

El plazo real de una implementación de IA no se cotiza en la primera reunión, se descubre revisando el estado de los datos y contando cuántas áreas tienen que ponerse de acuerdo. Cualquier número que se entregue antes de esa revisión es, en el mejor de los casos, el promedio de otros proyectos que no son el tuyo. Y en el peor de los casos, es una cifra elegida para ganar el contrato, no para cumplirse.