Cómo presentar un proyecto de IA a la gerencia y que lo aprueben

La reunión que se cae apenas empieza

Son las nueve de la mañana y el proyecto lleva tres semanas armándose: un diagnóstico completo, una arquitectura clara, hasta un prototipo que ya funciona en una laptop. La persona que presenta abre la diapositiva uno y ahí está el diagrama: nodos, flechas, el nombre del modelo, la palabra “agente” subrayada dos veces. El gerente general mira el reloj a los cuarenta segundos. El de finanzas pregunta “¿y esto en cuánto se traduce?” y la respuesta que recibe es una explicación de por qué el modelo elegido es superior a otro modelo. La reunión sigue quince minutos más por cortesía y termina con la frase que mata más proyectos de IA que cualquier objeción técnica: “lo vemos con calma y te aviso”.

Ese “lo vemos con calma” casi nunca es un no. Es peor: es un sí que nunca llega, porque nadie en la sala salió con un número que pudiera defender frente a otro gerente en el pasillo. El proyecto no se rechazó por ser malo. Se rechazó porque la presentación habló el idioma de quien la construyó (modelos, arquitectura, capacidades) y no el idioma de quien tiene que aprobar un presupuesto (costo, riesgo, plazo, retorno). Y esa distancia se cierra antes de entrar a la sala, no improvisando respuestas cuando ya preguntaron.

La primera diapositiva no habla de IA

Toda la presentación se decide en los primeros noventa segundos, y esos noventa segundos no son sobre inteligencia artificial. El error más común, incluso en equipos técnicos con buena intención, es abrir con la solución: la arquitectura, el modelo, el proveedor. Eso responde una pregunta que todavía nadie hizo. La sala llegó con una sola pregunta de fondo, aunque nadie la diga en voz alta: “¿esto vale la pena o es otro proyecto de moda?”. Esa pregunta se responde con un número de costo actual, no con un diagrama.

La razón por la que esto funciona no tiene nada de trucos de venta: un gerente general y un director de finanzas no evalúan tecnología, evalúan plata que entra o sale. Cuando la primera diapositiva muestra cuánto cuesta hoy el proceso (horas pagadas en tareas repetitivas, errores que se corrigen después, clientes que se pierden por demora) el resto de la reunión deja de ser una clase de inteligencia artificial y se convierte en una conversación sobre si esa cifra se puede reducir. Es el mismo proyecto, pero contado desde el lado que le importa a quien firma.

El orden que sostiene toda la reunión

Con la primera diapositiva ya resuelta, el resto del deck se arma en un orden fijo, y ese orden no es arbitrario: cada punto responde la pregunta que deja abierta el anterior. Este es el que uso, y el que he visto sostener reuniones de comité sin que nadie se pierda a la mitad:

• Costo actual: cuánto cuesta hoy el proceso que se quiere cambiar, en horas, en errores o en oportunidades perdidas. Es la diapositiva uno, y todo lo demás depende de que esta cifra sea creíble.
• Causa: por qué cuesta eso y no menos. No “falta IA”, sino el cuello de botella real: información dispersa, un paso manual que no escala, o una decisión que depende de una sola persona con la agenda llena.
• Intervención: qué se propone hacer, descrito como cambio de proceso con soporte de IA, no como catálogo de tecnología. Aquí va la arquitectura, pero reducida a una frase por bloque, nunca al diagrama completo.
• Número esperado: cuánto de ese costo actual se reduce, en qué plazo, y con qué margen de error declarado como tal. Un número sin margen suena a promesa, y una promesa es lo primero que finanzas va a cuestionar.
• Qué se descarta: qué parte del proceso NO se toca, qué alternativa se evaluó y por qué se eligió esta y no otra. Mostrar lo que se descartó es lo que le dice a la sala que hubo criterio, no solo entusiasmo.

El orden importa más que el contenido de cada punto. Si el número esperado aparece antes que la causa, suena a cifra sacada del aire porque nadie explicó de dónde sale. Si la intervención aparece antes que el costo actual, suena a solución buscando problema. La causa, en particular, es la diapositiva que casi nadie prepara bien, porque exige haber hecho antes un diagnóstico de madurez en IA real y no una suposición del área de sistemas. Y la intervención completa, con alcance y entregables, debería sostenerse con el mismo rigor que exige una propuesta de consultoría de IA que se aprueba: lo que se presenta en la reunión es el resumen de un documento que existe y se puede compartir después.

Traducir de nodos y modelos a plata y tiempo

La intervención, el tercer punto del orden, es donde más proyectos pierden a la sala, porque quien la arma suele describirla en el vocabulario con el que la construyó: el nombre del modelo, la cantidad de nodos del flujo, si es un agente o una automatización. Nada de eso es falso, pero nada de eso responde lo que el comité necesita. La traducción que importa en esta reunión específica es más angosta que “explicar IA en general”: es convertir cada pieza técnica en una fila con dos columnas, plata y tiempo.

En la práctica funciona así: cada nodo del flujo o cada paso donde interviene un modelo se anota junto a cuántas horas de trabajo humano reemplaza o acelera, y cuánto vale esa hora en la operación real. Un “agente que clasifica tickets” se convierte en “dos personas dejan de leer trescientos correos por semana para clasificarlos a mano”. Un “modelo de scoring” se convierte en “el vendedor deja de llamar en orden de llegada y llama primero a quien tiene más probabilidad de comprar”. Si una pieza de la arquitectura no se puede traducir a una fila de plata o tiempo, esa pieza no debería estar en esta diapositiva, aunque sea técnicamente interesante: sobra.

Esto es distinto de aprender a traducir lenguaje técnico a lenguaje de negocio en general, una habilidad que se usa en cualquier conversación con una persona no técnica, no solo en una reunión de aprobación con presupuesto sobre la mesa. Esa traducción amplia, con ejemplos fuera del contexto de un comité, está desarrollada en cómo explicar la inteligencia artificial a la gerencia general. Aquí el objetivo es más estrecho: que cada línea del deck sobreviva la pregunta “¿y esto qué significa en plata?”.

Las tres preguntas que siempre hace finanzas

Da igual el sector o el tamaño de la empresa: cuando el proyecto llega a finanzas, las preguntas se repiten con una regularidad que ya debería estar incorporada al deck antes de que alguien las haga en voz alta.

• ¿Cuánto cuesta esto en total, no solo la licencia del software? Incluye implementación, tiempo del equipo interno que participa, mantenimiento y lo que cuesta seguir pagando después del primer mes. Un número que solo menciona la suscripción mensual se cae apenas alguien pregunta por el resto.
• ¿Cuándo se empieza a ver el retorno? No “funciona”, sino en qué semana o mes el ahorro supera lo que se invirtió. Si la respuesta es “en el largo plazo” sin fecha, finanzas la traduce como “nunca” y actúa en consecuencia.
• ¿Qué pasa si no funciona como se espera? No es una pregunta hostil, es la que hace cualquier persona responsable de un presupuesto. La respuesta seria no es una garantía, es un plan: cómo se mide a las cuatro u ocho semanas y qué se decide con esa medición.

Las tres preguntas comparten un rasgo: se contestan mejor antes de la reunión que durante ella. Si el número de costo total todavía se está armando cuando alguien pregunta, ya se perdió la sala, porque la duda sobre el número se contagia a toda la propuesta. La forma de llegar con la respuesta lista pasa por haber resuelto cómo poner precio a un proyecto de IA desde antes de agendar el comité, no durante la presentación.

Cuando alguien del comité quiere hablar de ChatGPT

En casi toda reunión de comité hay una persona que usó ChatGPT el fin de semana para escribir un correo y llega con una duda genuina pero fuera de lugar: “¿por qué no usamos simplemente ChatGPT para esto y nos ahorramos el proyecto?”. No es mala fe: es que la única referencia pública de IA que esa persona tiene es un chat de texto, y desde ahí cualquier proyecto de agentes o automatización suena innecesariamente complicado. Si la respuesta es una explicación técnica de por qué un modelo de propósito general no resuelve un proceso conectado a sistemas internos, la reunión se desvía a un debate de herramientas que nadie gana en diez minutos.

La salida que funciona no es discutir tecnología, es volver a la diapositiva uno: “ese es exactamente el punto, esto no reemplaza escribir un correo, resuelve el proceso que hoy cuesta la cifra que vimos al inicio, y ChatGPT abierto no toca ese sistema ni ese dato”. La pregunta rara vez vuelve a aparecer después de eso, porque quien la hizo no quería ganar el punto técnico: quería confirmar que alguien ya pensó en la opción obvia y la descartó con una razón, no por ignorarla. Ignorar la pregunta o responderla con condescendencia es lo que la hace crecer. Contestarla en diez segundos y devolver la conversación al costo es lo que la cierra.

Quién entra a la sala y qué se muestra en pantalla

La persona que arma esta reunión suele ser el consultor de IA contratado para el proyecto o el líder interno que lo impulsa, y en cualquiera de los dos casos conviene decidir antes quién más entra a la sala. La regla que uso: al comité entra quien decide el presupuesto y, como máximo, una persona técnica que responda preguntas de detalle si el comité las pide. No entran los tres desarrolladores del equipo ni el proveedor completo. Cuantas más personas hablan, más se diluye quién es el dueño de la respuesta cuando alguien pregunta algo incómodo.

Sobre el material: el deck que se proyecta es corto a propósito, y todo lo que sea detalle técnico, cronograma completo o desglose de costos línea por línea va en un anexo que se comparte después, no que se lee en pantalla durante la reunión. Nadie en un comité lee un diagrama de arquitectura mientras alguien habla; lo que sí lee es un número grande en el centro de la diapositiva. Si el comité pide profundidad, ahí está el anexo, y pedirlo es una señal de interés real, no un ataque.

Mi criterio sobre por qué la mayoría de estas reuniones fracasan

Pedir una decisión, no una aprobación general

La última diapositiva es tan importante como la primera y se falla por la razón opuesta: en vez de terminar pidiendo algo concreto, termina con un “¿qué les parece?” que no obliga a nadie a decidir nada en esa sala. Un comité que sale de la reunión “para pensarlo” casi nunca vuelve a agendar la conversación por iniciativa propia. La última diapositiva tiene que pedir una acción con nombre: aprobar el presupuesto de la fase de diagnóstico, autorizar un piloto de seis semanas con un alcance cerrado, o dar luz verde a firmar con el proveedor que ya se evaluó. Cualquiera de esas tres cosas se puede aprobar o rechazar en la misma reunión. “¿Qué opinan de la IA?” no se puede.

Esto no es una técnica de cierre de ventas, es simplemente respetar el tiempo del comité: si la reunión no termina con un sí, un no o una condición específica (“apruébenlo si el piloto se limita a un solo proceso”), entonces la reunión no sirvió, aunque haya sido interesante. Lo he visto una y otra vez: los proyectos que se aprueban no son los que mejor explicaron la tecnología, son los que llegaron con el costo actual bien medido y salieron pidiendo una firma concreta, no un aplauso.

Si el comité aprueba y el proyecto cumple, la conversación que sigue casi nunca es sobre otro proyecto aislado: es sobre pasar del proyecto cerrado a un retainer de consultoría de IA que sostenga la relación en el tiempo. Pero esa conversación es la siguiente reunión, no esta. Mezclarlas confunde la decisión que se está pidiendo ahora, y es la diferencia entre una presentación que informa y una que decide: solo la segunda vale la reunión que costó armarla.