Cómo explicar la inteligencia artificial a la gerencia general

El momento exacto en que la gerencia deja de escuchar

Pasa casi siempre igual. Estás en el pasillo, o le mandaste un correo, o te tocó el turno en la reunión semanal del área, y alguien con poder de decisión te pregunta qué es eso que están armando. Y ahí, sin planearlo, empiezas a hablar de lo que hiciste: “le conectamos un modelo de lenguaje al sistema de tickets”, “usamos un flujo con recuperación de información”, “el modelo tiene bastante buena precisión”. A los diez segundos la mirada cambia. No es que no le importe: es que no entendió nada de lo que acabas de decir, y no lo va a admitir en voz alta. Contesta con un “interesante, revisémoslo con calma” que en la práctica significa que la conversación murió ahí mismo, sin que nadie la haya rechazado formalmente.

Esto no pasa solo en la reunión donde se aprueba presupuesto, con deck y comité: esa conversación tiene su propia estructura y ya la cubro en cómo presentar un proyecto de IA a la gerencia y que lo aprueben. Pasa mucho antes y mucho más seguido: en la charla informal donde alguien evalúa si vale la pena seguir escuchándote, en el correo donde resumes un avance, en la pregunta suelta de un director en el pasillo. Ahí no hay agenda ni tiempo para un despliegue completo. Hay una ventana de treinta segundos para que la persona que decide entienda qué gana, qué arriesga y cuánto le cuesta. Si la usas para hablar de la herramienta, la perdiste.

Las tres traducciones que tienes que hacer sí o sí

La razón por la que no te aprueban algo casi nunca es lo que propusiste. Es que lo explicaste en el idioma de la herramienta, con sustantivos técnicos, cuando quien decide piensa en tres categorías fijas: costo, riesgo y tiempo. No son cuatro, no son diez. Son tres, y si tu explicación no aterriza en esas tres, la persona que te escucha va a tener que traducirte ella misma. En la mayoría de los casos no lo va a hacer: va a asumir lo peor y va a posponer.

Esto no es un truco retórico ni maquillaje de lenguaje. Es reconocer que quien dirige un área o una empresa no tiene, ni tiene por qué tener, el vocabulario técnico que tú manejas. Su trabajo es asignar presupuesto, tiempo y atención entre decenas de iniciativas que compiten entre sí, y evalúa cada una con las mismas tres preguntas, sin importar si se trata de un modelo de lenguaje o de una línea de producto nueva. Cuando le hablas de arquitectura, de tokens o de precisión, le estás pidiendo que haga tu trabajo de traducción además del suyo. La mayoría no lo hace: pasa a la siguiente propuesta. Este oficio de traducir, y no vender la herramienta, es en el fondo el trabajo central de el consultor de IA.

Primera traducción: de herramienta a proceso

La herramienta es lo que usaste. El proceso es lo que cambia. Gerencia general no necesita saber que corriste un modelo de lenguaje sobre las quejas de soporte: necesita saber que las quejas urgentes se identifican en minutos en lugar de al día siguiente, y que eso reduce el tiempo en que un cliente molesto sigue molesto. La herramienta es un detalle de implementación; el proceso es el negocio.

El error típico suena así: “implementamos un pipeline de clasificación con un modelo entrenado sobre nuestro histórico de tickets”. La traducción correcta suena así: “antes alguien revisaba los tickets uno por uno para decidir cuál atender primero, ahora el sistema ordena la cola automáticamente y el equipo empieza siempre por lo urgente”. Nota que en la segunda versión no aparece la palabra modelo ni la palabra IA. No hace falta. Lo que le importa a quien decide es el antes y el después del proceso, no el mecanismo que lo produjo.

Practicar esta traducción es simple, aunque no es fácil: por cada frase técnica que ibas a decir, pregúntate qué tarea humana existía antes y qué le pasa ahora. Si no puedes nombrar esa tarea, es señal de que tú tampoco tienes claro qué proceso estás cambiando, y ese es un problema más serio que uno de comunicación. Un portafolio armado con este mismo criterio, como el que describo en el portafolio de proyectos de automatización que sí convence a una empresa, ya llega traducido a proceso, así que la conversación con gerencia empieza medio camino andado.

Segunda traducción: de tiempo a plata

El tiempo que ahorra una automatización no significa nada hasta que alguien lo convierte en dinero, y esa conversión no es responsabilidad de quien decide: es tuya. Decir “esto ahorra dos horas diarias” es una frase a medias. Falta la segunda mitad: dos horas diarias de quién, a qué costo, y qué hace esa persona con el tiempo que le queda libre.

Si el proceso libera tiempo de una persona que de todas formas seguiría en planilla haciendo otra cosa, el ahorro no es una cifra en el estado de resultados: es capacidad instalada que ahora se puede usar en algo que antes no alcanzaba a hacerse, como atender más casos con el mismo equipo en lugar de reducirlo. Esa distinción, ahorro que se ve en el gasto contra capacidad que se libera para crecer, es exactamente el tipo de precisión que separa a quien entiende el negocio de quien solo entiende la herramienta.

No inventes una cifra de ahorro que no puedas sostener. Es preferible decir “esto libera aproximadamente tanto tiempo del equipo, y lo vamos a medir en el primer mes” que soltar un porcentaje que suena bien en la sala y no aguanta la primera pregunta de seguimiento. Esta misma lógica de hablar en resultado y no en esfuerzo es la que sostiene cobrar por resultado en proyectos de IA y no por flujo entregado: si internamente conviertes tiempo en plata, afuera puedes cobrar por esa plata en lugar de por horas.

Tercera traducción: de precisión a riesgo

La precisión es una métrica técnica; el riesgo es lo único que gerencia general de verdad necesita evaluar. Decir “el modelo tiene noventa y dos por ciento de precisión” no le dice nada útil a quien no vive en esto todos los días, y peor: suena a que hay un porcentaje de algo que nadie explicó. La pregunta real detrás de esa cifra es otra: ¿qué pasa cuando se equivoca, quién se entera y qué tan caro sale corregirlo?

Traducir precisión a riesgo significa responder tres cosas antes de que te las pregunten: qué tan grave es un error (perder un cliente no es lo mismo que perder cinco minutos de un empleado), quién revisa el resultado antes de que llegue al cliente final, y qué pasa si el sistema falla por completo un día, si existe un plan alterno o el proceso completo se detiene. Cuando llevas esas tres respuestas, el número de precisión deja de importar tanto, porque ya demostraste que entiendes dónde puede doler y que hay alguien vigilando.

Ordenar el riesgo en identificar, medir, gestionar y gobernar es un ejercicio que te sirve a ti antes de la reunión, no algo que necesites nombrar en la sala. Sirve además para no confundir riesgo técnico con riesgo de negocio: el primero es que el modelo se equivoque, el segundo es qué le pasa a la empresa cuando eso ocurre, y a gerencia general solo le importa el segundo.

Cómo abrir la conversación sin que suene a venta

La apertura decide más de lo que parece. Si arrancas con “quiero mostrarte algo que hicimos con IA”, ya perdiste el marco: pusiste la herramienta primero. Una apertura que funciona empieza por el dolor que la persona ya reconoce como propio. “Sabes que llevamos semanas atrasados con la cola de tickets, encontré una forma de que eso deje de pasar” abre una conversación distinta a “quiero enseñarte el asistente que armamos”. La primera frase la posiciona a ella como dueña del problema que se resuelve; la segunda te posiciona a ti como dueño de un invento nuevo.

Las preguntas que casi siempre llegan, en este orden

• ¿Cuánto cuesta? en tiempo del equipo, en herramienta o en ambos, aunque sea un rango.
• ¿Cuánto se tarda en ver resultado? una fecha o una ventana de prueba concreta, no “pronto”.
• ¿Qué pasa si falla? quién se entera, quién corrige y qué tan grave es el error típico.
• ¿Quién más lo está usando ya? dentro o fuera de la empresa, para calibrar si es un riesgo nuevo o uno ya probado en otro lado.
• ¿Quién es responsable si algo sale mal? un nombre con cargo, no un área genérica.

Llegar con esas cinco respuestas preparadas, aunque nadie las pida en ese orden, cambia el tono completo de la conversación: pasas de estar defendiéndote a estar informando. La regla práctica es simple: si no puedes responder alguna de las cinco en una frase, todavía no estás listo para abrir la conversación, sin importar qué tan bien funcione la parte técnica. Estas cinco preguntas son, sin que nadie lo llame así, casi el examen no oficial de todo el que aspira a hacer el trabajo de un Gerente de IA en una empresa.

Lo que no se menciona nunca frente a gerencia general

Hay una lista corta de cosas que, dichas frente a quien decide, restan más de lo que suman, así sean ciertas. No es deshonestidad: es criterio sobre qué información sirve en ese momento y cuál solo agrega ruido.

• El nombre del modelo o del proveedor: a nadie en gerencia le cambia la decisión saber si detrás hay un modelo de un proveedor u otro, y mencionarlo abre una comparación de marcas que no viene al caso.
• Los términos de arquitectura: hablar de agentes, de recuperación de información o de vectores convierte una conversación de negocio en una clase que nadie pidió.
• Comparaciones vacías con la competencia: decir que “la competencia ya tiene IA” sin explicar qué proceso mejoraron es presión sin contenido, y gerencia lo nota.
• Una fecha de entrega que no puedes sostener: prometer un plazo cerrado para sonar seguro y después pedir una prórroga cuesta más credibilidad que haber dado un rango honesto desde el inicio.
• Un ahorro exacto que no mediste: un número inventado, aunque suene bien en la sala, es la primera pregunta de seguimiento que no vas a poder responder.

El patrón detrás de esta lista es el mismo de las tres traducciones: todo lo que suena a herramienta, a promesa sin sustento o a comparación superficial, resta autoridad. Lo que suma es lo contrario: proceso, cifra sostenible y honestidad sobre lo que todavía no sabes.

La misma propuesta, contada mal y contada bien

Para que la diferencia quede clara, aquí está la misma propuesta contada de las dos formas, casi palabra por palabra, no como fórmula abstracta.

Contada mal (así se pierde la sala)

“Buenas, quería contarte que implementamos un modelo de lenguaje conectado a nuestro sistema de tickets, usando una arquitectura de recuperación de información sobre el histórico de casos. Entrenamos con data de los últimos dos años y el modelo tiene una precisión bastante alta, como del noventa por ciento. La idea es que clasifique automáticamente los tickets que entran. Todavía estamos ajustando algunos parámetros pero en general funciona bien. ¿Qué te parece si te muestro una demo la próxima semana?”

En quince segundos aparecieron cinco palabras técnicas, una cifra de precisión sin contexto de qué significa el otro diez por ciento, un plazo vago (“la próxima semana”, sin decir para qué) y ninguna mención de plata, de riesgo ni del proceso que cambia. Quien escucha esto no tiene con qué decidir. Solo puede decir “me parece bien, avísame cómo va”, que es la forma educada de archivar algo.

Contada bien (así se abre una decisión)

“Sabes que el equipo de soporte lleva semanas respondiendo tickets en el orden en que llegan, no en el orden en que urgen, y eso nos ha costado un par de clientes molestos que esperaron de más. Armé una forma de que el sistema ordene la cola automáticamente apenas entra un ticket, así el equipo empieza siempre por lo urgente. Ya lo probé con tres meses de tickets reales y clasifica bien casi todos los casos; el resto, que son los más raros, igual los sigue viendo una persona antes de que salgan, así que no hay riesgo de que algo urgente se quede sin revisión humana. Si te parece, lo dejamos corriendo dos semanas en paralelo con lo que ya hacen, medimos cuánto bajó el tiempo de primera respuesta, y con eso decidimos si lo dejamos fijo. No necesita presupuesto adicional, solo tu visto bueno para probarlo con el equipo real.”

Esta versión no esconde que hay errores (los nombra y explica que hay una revisión humana detrás), no promete una cifra que no midió (propone medirla en dos semanas), y termina pidiendo exactamente una cosa: permiso para probar. Ningún término técnico aparece porque ninguno hacía falta. La única diferencia entre las dos versiones no es el proyecto, es lo que decidiste contar.

El patrón detrás de la versión que funciona

• Abre con el dolor de la otra persona, no con lo que tú construiste.
• Nombra el proceso que cambia antes que la tecnología que lo cambia.
• Reconoce el margen de error y quién lo revisa, en vez de esconderlo.
• Propone una prueba chica y medible en vez de pedir aprobación total de entrada.
• Cierra pidiendo una decisión puntual, no una opinión general.

Cómo cerrar pidiendo una decisión concreta

Toda conversación de este tipo tiene que terminar en una pregunta específica, no en un “bueno, ahí lo dejo para que lo pienses”. Si sales de la sala, del correo o del pasillo sin haber pedido algo puntual, lo más probable es que la conversación no vuelva a retomarse, no porque a la gerencia le haya parecido mal, sino porque nadie tiene en su lista pendiente decidir sobre algo que nunca se planteó como decisión.

Pedir una decisión concreta significa reemplazar “¿qué opinas?” por algo que se pueda aceptar o rechazar en el momento: “¿me das luz verde para probarlo dos semanas con el equipo real?”, “¿puedo usar a una persona del equipo cuatro horas esta semana para armar la prueba?”, “¿lo revisamos juntos en quince días con los números de esas dos semanas?”. Cada una de esas preguntas tiene una respuesta de sí o no, y eso es lo que mueve algo de la conversación a la acción.

La habilidad de traducir no se aprende leyendo esto una vez: se nota la primera vez que alguien te interrumpe a la mitad de una frase técnica y, en vez de defenderla, la conviertes en proceso, en plata o en riesgo sin perder el hilo. Eso separa a quien construye bien de quien además consigue que lo dejen construir, y es la diferencia entre un automatizador y un Gerente de IA: el segundo no tiene mejores herramientas, tiene mejores traducciones.