Qué necesito antes de implementar IA (el checklist previo)

La reunión donde nadie preguntó lo que importaba

La escena se repite con variaciones menores en decenas de empresas. Una gerencia de operaciones lleva meses escuchando sobre inteligencia artificial en conferencias y grupos de gerentes. Contrata a un proveedor que promete automatizar la cobranza, o priorizar los leads, o clasificar tickets de soporte. La propuesta comercial es sólida en diapositivas: casos de éxito, capturas de pantalla, una fecha de entrega. Lo que no aparece en esa propuesta es una sola pregunta sobre el proceso real que se va a tocar. Nadie pidió ver cuántos casos entran al mes, cuántos se resuelven bien, ni qué pasa hoy cuando el proceso falla. La reunión uno termina con un contrato firmado y cero diagnóstico.

El costo de ese silencio aparece recién en el mes tres o cuatro, cuando el proveedor pide datos que la empresa no tiene organizados, o descubre que el área que debía operar la herramienta nunca fue consultada y ahora la resiste sin decirlo abiertamente. En ese punto ya se gastó el presupuesto del primer tramo, y el comité que aprobó el proyecto no tiene forma de decir si algo mejoró, porque nadie midió cómo estaba el proceso antes de empezar. La falla no fue del modelo ni del algoritmo. Fue no haber hecho, en la reunión uno, las preguntas que cualquier gerente de operaciones sabe responder sin ayuda de nadie.

El checklist de doce puntos, en cuatro bloques

Para evitar esa escena armé un checklist de doce puntos, agrupados en cuatro bloques: dolor medido, datos disponibles, personas con mandato y decisión con dueño. No es una lista de requisitos técnicos ni un formulario de propuesta. Es la misma pregunta repetida doce veces desde ángulos distintos: ¿esta empresa sabe lo suficiente de su propio proceso para que un tercero, o un equipo interno, pueda mejorarlo con datos?

Dolor medido

• El dolor vive en un proceso, no en la palabra IA: puedes nombrar la tarea exacta que falla (cobrar, priorizar, clasificar, pronosticar) y a quién dentro de la empresa le cuesta hoy.
• El dolor está medido en números actuales: existe una cifra de hoy (horas perdidas, plata que se va, casos mal resueltos) contra la cual comparar después. Sin ese número de partida, ningún resultado se puede probar.
• El dolor se repite con volumen: no es un caso aislado que pasó una vez, es una tarea que ocurre decenas o cientos de veces al mes, lo bastante seguido para justificar el esfuerzo.

Datos disponibles

• Existe un histórico real del proceso, no la intención de empezar a medirlo desde ahora. Sin pasado registrado no hay de qué aprender.
• El dato vive en un lugar accesible, no repartido en planillas sueltas que nadie cruza ni concilia entre áreas.
• El dato tiene calidad mínima: está razonablemente completo, tiene fecha, y el resultado que se quiere predecir o mejorar quedó registrado, no solo el caso.

Los primeros seis puntos, dolor y datos, describen el terreno objetivo del proyecto: lo que se sufre y lo que se sabe. Los siguientes seis, personas y decisión, describen quién sostiene ese terreno cuando el proyecto se pone difícil.

Personas con mandato y decisión con dueño

Personas con mandato

• Hay un responsable del proceso metido desde el día uno, no solo el área de sistemas o el proveedor externo. Sin ese responsable, nadie traduce el hallazgo del dato en cambio de operación.
• El equipo que va a usar la herramienta fue consultado, no solo informado. Un aviso por correo no es lo mismo que sentarse con quien hace la tarea todos los días a preguntarle qué le duele.
• Existe alguien con mandato para cambiar el proceso, no solo para aprobar el gasto. Automatizar un proceso mal diseñado solo hace que el error se cometa más rápido.

Decisión con dueño

• Hay un dueño del proyecto con nombre y apellido, no un comité que diluye la responsabilidad entre varias personas y ninguna termina respondiendo por el resultado.
• Existe un criterio de éxito acordado antes de empezar: qué número tiene que moverse, cuánto, y en qué plazo. Sin ese acuerdo previo, cualquier resultado se puede interpretar como éxito.
• Hay fecha de revisión y autoridad real para frenar el proyecto si a mitad de camino no está funcionando. El peor escenario no es que un proyecto falle, es que siga vivo por inercia meses después de que todos saben que no sirve.

Estos doce puntos no son un examen que se aprueba o se reprueba en bloque. Son la fotografía de qué tan lista está una empresa para que la inteligencia artificial para empresas mejore algo real, en vez de sumarse como una capa más de tecnología sin dueño. Cubren, en otro orden, las mismas preguntas que debería resolver cualquier gerente antes de arrancar las fases de implementación de IA en una empresa.

Los tres puntos que no se negocian

De los doce puntos, tres son bloqueantes: si falta cualquiera de esos tres, el proyecto no arranca, sin importar cuánto presupuesto ya esté aprobado.

• El dolor medido en números actuales (bloque de dolor): si nadie puede decir cuánto cuesta hoy el proceso, jamás vas a poder probar que la IA mejoró algo. Vas a terminar discutiendo percepciones, no resultados.
• El histórico real del proceso (bloque de datos): sin datos pasados del comportamiento que quieres predecir o automatizar, no hay de dónde aprender. Un proveedor que dice que eso “se ve en el camino” está vendiendo un proyecto distinto al que ofreció.
• El dueño del proyecto con nombre y apellido (bloque de decisión): sin una persona identificable que responda por el resultado, el proyecto se queda sin nadie que lo defienda cuando se pone difícil, que es siempre, en algún punto.

Los otros nueve puntos importan, pero se pueden resolver sobre la marcha durante las primeras semanas del proyecto. Estos tres no: si faltan el día uno, van a faltar también en el día noventa, porque nadie los va a generar solo por avanzar.

Qué hacer cuando falta un punto (y no es de los tres bloqueantes)

Cuando falta alguno de los nueve puntos restantes, la respuesta casi nunca es cancelar el proyecto: es reordenar la secuencia. Si el dato existe pero vive disperso en planillas que nadie concilia, el primer entregable no es un modelo, es un proyecto corto de ordenar y unificar esa fuente, con fecha propia y sin mezclarlo con la promesa de resultados de IA. Si el equipo que va a operar la herramienta nunca fue consultado, se agenda esa conversación antes de escribir una sola línea de configuración, no después del primer reclamo.

Cuando lo que falta es un responsable de proceso metido desde el día uno, conviene resolver primero quién lidera un proyecto de IA en una empresa (y quién no debería), porque un proyecto sin ese rol definido tiende a mover la responsabilidad de un área a otra apenas aparece el primer obstáculo. Y si lo que falta es una fotografía completa de qué tan lista está la organización en general, no solo en este proceso puntual, ese es exactamente el trabajo de un diagnóstico de madurez en IA previo, que documenta huecos antes de comprometer un contrato.

La regla práctica es esta: un punto faltante retrasa, no necesariamente cancela. Los tres bloqueantes sí cancelan, o al menos congelan el arranque, porque sin ellos no hay manera honesta de medir después si el proyecto funcionó.

Cómo usar el checklist para frenar a un proveedor apurado

Un proveedor apurado tiene un patrón reconocible: quiere firmar en la primera reunión, ofrece un plazo cerrado sin haber visto un solo dato tuyo, y trata cualquier pregunta sobre el proceso actual como una pérdida de tiempo que retrasa “lo importante”, que para él es empezar a configurar. El checklist sirve exactamente para frenar esa dinámica sin necesitar preparación técnica: se lee en voz alta en la reunión y se le pide al proveedor que, punto por punto, diga qué necesita de la empresa para cada uno.

Si el proveedor responde con seguridad sobre los doce puntos, incluidos los tres bloqueantes, es una señal razonable de que ya hizo esto antes y sabe lo que implica. Si esquiva las preguntas de histórico de datos y dueño del proyecto, o las contesta con generalidades como “eso lo vemos en el camino”, esa evasión ya es información: dice que el plan es vender primero y diagnosticar después, con el reloj del contrato corriendo mientras tanto. Frenar en ese punto cuesta una reunión incómoda. Firmar sin frenar cuesta un proyecto completo.

Cómo se usa en la práctica, en la reunión uno

El checklist funciona mejor como agenda de la primera reunión, no como formulario que se llena después por separado. Se convoca a la misma mesa al responsable del proceso, a alguien del equipo que ejecuta la tarea todos los días, y a quien tenga mandato para aprobar o frenar el gasto. Sin esas tres personas en la sala, ya falta uno de los doce puntos antes de que el consultor de IA o cualquier proveedor externo proponga nada.

Una reunión donde el checklist se completa de verdad dura entre sesenta y noventa minutos, y termina con una lista corta de tareas previas, no con un contrato firmado. Una reunión donde el checklist se salta dura quince minutos, termina con un apretón de manos y una fecha de entrega, y dedica los siguientes tres meses a descubrir en la práctica cada uno de los doce puntos que nadie preguntó.

Los errores más comunes al usar este checklist

Tener el checklist no garantiza usarlo bien. Estos son los errores que más se repiten al aplicarlo, y varios terminan pareciéndose a los errores al implementar IA en una empresa (y cuál cuesta más) que ya documenté antes.

• Tratar los doce puntos como igual de urgentes: los nueve no bloqueantes se pueden resolver en paralelo al arranque del proyecto; congelarlo por ellos sale casi tan caro como ignorarlos.
• Dejar que lo complete una sola persona, casi siempre del área de sistemas: el checklist pierde sentido si el área de negocio no participa, porque el dolor y el dato viven ahí, no en TI.
• Usarlo una sola vez para el primer proyecto de IA y no repetirlo: cada proceso nuevo que se automatiza necesita su propia versión del checklist. Que el primer proyecto haya salido bien no dice nada del segundo.
• Convertirlo en burocracia que nadie audita: llenarlo por cumplir, sin que nadie revise si las respuestas son ciertas, es peor que no tenerlo, porque da una falsa sensación de haber diagnosticado.

Ninguno de estos errores es técnico. Son errores de gestión de un instrumento simple, y por eso cuestan más de lo que deberían: nadie los detecta a tiempo porque el checklist, en teoría, ya se había usado.

El checklist no reemplaza el criterio, lo obliga a aparecer antes

Ningún checklist reemplaza el criterio de quien decide. Lo que hace es obligar a que ese criterio aparezca en la reunión uno y no en el mes cuatro, cuando ya se gastó el presupuesto y el error cuesta reputación además de plata. La mitad de los proyectos de IA que terminan archivados como “no funcionó” se podían haber detenido, o rediseñado, con seis preguntas de negocio que cualquier gerente sabe responder sin ayuda técnica.

La empresa que se toma en serio estos doce puntos no es necesariamente la que más invierte en tecnología: es la que llega a la reunión uno sabiendo cuánto le cuesta hoy no tener IA, qué datos tiene para probarlo, quién va a usarlo y quién responde si no funciona. Eso no se compra en una propuesta comercial. Se prepara antes de sentarse a firmarla, y ese trabajo previo, aburrido y sin diapositivas, es lo que separa al proyecto que llega a producción del que se archiva.