Por qué las propuestas de IA mueren en la primera reunión
No es que el directorio no entienda la tecnología. Es que la propuesta no habla su idioma.
Un CFO no piensa en "agentes de IA" ni en "automatización inteligente". Piensa en horas de personal, en errores que generan reprocesos, en cierres que se retrasan, en costos que no puede justificar ante el consejo. Si la propuesta llega con un deck lleno de arquitecturas técnicas y promesas de transformación, la respuesta habitual es: "Interesante. Lo revisamos para el próximo trimestre."
El próximo trimestre nunca llega.
El problema no es la iniciativa. Es el encuadre. Y ese encuadre se puede corregir antes de entrar a la sala.
El error más común: empezar por la solución
La mayoría de las propuestas internas de automatización comienzan con la herramienta. "Queremos implementar un agente de IA para el área de finanzas." El directorio escucha eso y activa sus filtros habituales: ¿cuánto cuesta?, ¿cuánto tiempo lleva?, ¿qué pasa si falla?
Si esas preguntas no tienen respuesta en los primeros cinco minutos, la reunión se convierte en una sesión de escepticismo.
El orden correcto es el inverso: primero el problema, luego el costo de no resolverlo, luego la solución como respuesta lógica.
Un ejemplo concreto: una empresa de distribución con 80 empleados dedicaba entre 12 y 15 horas semanales a consolidar datos de ventas de tres sistemas distintos para producir el reporte semanal de operaciones. El proceso era manual, propenso a errores y dependía de dos personas específicas. Cuando esas personas no estaban disponibles, el reporte se retrasaba.
La propuesta no empezó con "queremos automatizar el reporting". Empezó con: "Tenemos un proceso que consume entre 600 y 750 horas anuales de personal calificado, genera inconsistencias que requieren corrección posterior y tiene un punto de falla humano. Esto es lo que cuesta mantenerlo. Esto es lo que costaría resolverlo."
Esa es la diferencia entre una propuesta que avanza y una que se archiva.
Cómo estructurar la propuesta para que el directorio la entienda en diez minutos
El directorio no tiene tiempo para leer un documento de 40 páginas antes de la reunión. La propuesta debe poder comunicarse en diez minutos y resistir veinte de preguntas.
Estructura recomendada:
1. El problema con costo asociado. Identifique un proceso específico, cuantifique el tiempo que consume y tradúzcalo a costo. Si el proceso involucra a tres personas durante dos horas semanales, eso son seis horas semanales, 300 horas anuales. Con un costo promedio por hora, el número se vuelve concreto.
2. El riesgo de no actuar. No en términos abstractos. En términos de lo que ya está pasando: errores, retrasos, dependencia de personas clave, incapacidad de escalar sin contratar.
3. La solución como hipótesis acotada. No proponga una transformación completa. Proponga un piloto de seis a ocho semanas sobre ese proceso específico, con un resultado medible al final. El directorio puede aprobar un piloto aunque no esté listo para aprobar una transformación.
4. El rango de ROI esperado. No invente cifras exactas. Use rangos honestos. "Si este agente reduce el tiempo de consolidación en un 60%, el ahorro anual estaría entre X e Y." Los rangos transmiten rigor, no incertidumbre.
5. Lo que se necesita del equipo. Tiempo, acceso a sistemas, una persona de referencia. Sin esto, el directorio aprueba algo que luego no tiene recursos para ejecutar.
Cómo anticipar las tres objeciones que siempre aparecen
Hay tres objeciones que aparecen en casi todas las reuniones de este tipo. Si las anticipa, la propuesta gana credibilidad.
"¿Y si los datos son incorrectos?"
Esta es una objeción legítima. La respuesta no es "no va a pasar". La respuesta es: el agente opera sobre datos que ya existen en sus sistemas. Los errores actuales también provienen de esos datos. La diferencia es que el agente aplica las mismas reglas cada vez, sin variación. El riesgo de inconsistencia no desaparece, pero se vuelve predecible y auditable.
"¿Cuánto tiempo va a llevar?"
Un piloto bien definido sobre un proceso acotado puede estar en producción en seis a diez semanas. No es una estimación optimista: es el resultado de trabajar sobre un alcance específico, no sobre una transformación completa. Si el alcance crece, el tiempo crece. Por eso el piloto empieza pequeño.
"¿Qué pasa con el equipo?"
Esta pregunta tiene dos versiones: la versión de recursos humanos ("¿vamos a prescindir de personas?") y la versión operativa ("¿el equipo va a poder operar esto?"). Para la primera: en la mayoría de los casos, el equipo no se reduce — se redirige hacia tareas que requieren criterio. Para la segunda: el piloto incluye que el equipo aprenda a operar el sistema. No se entrega una caja negra.
El piloto como herramienta de aprobación
El directorio tiene más facilidad para aprobar algo pequeño y reversible que algo grande e irreversible. Un piloto de seis semanas sobre un proceso específico cumple esa condición.
El piloto tiene que tener tres características para ser aprobable: alcance claro, resultado medible y fecha de revisión definida. Si al final del piloto el resultado no es satisfactorio, se detiene. Si lo es, se escala.
Esa lógica reduce el riesgo percibido y facilita la decisión. No es una concesión — es una estrategia.
Conclusión
Una propuesta de automatización con IA no se aprueba por ser técnicamente correcta. Se aprueba cuando el directorio entiende el problema, ve el costo de no actuar y percibe que el riesgo de la iniciativa es manejable.
Eso requiere preparación: identificar el proceso correcto, cuantificar su costo, diseñar un piloto acotado y anticipar las objeciones antes de que aparezcan.
Si tiene un proceso en mente pero no está seguro de si tiene las condiciones para presentarlo, puede solicitar un diagnóstico gratuito. En una conversación breve, revisamos si el caso tiene viabilidad y cómo encuadrarlo para que avance.
