Cómo presupuestar un proyecto de IA: la guía completa antes de pedir aprobación

El error de pedir un solo número (y por qué finanzas deja de confiar en el siguiente proyecto)

El error más común no está en subestimar el precio de la licencia o de la plataforma. Está en llegar a una reunión con un solo número: “esto cuesta 15,000 dólares” y nada más. Finanzas aprueba ese número sin ver de qué está hecho, el proyecto arranca, y a las pocas semanas alguien vuelve a pedir presupuesto adicional para “la integración que no estaba contemplada” o “la limpieza de datos que tomó el triple de tiempo”. Ese segundo pedido daña la confianza en el proyecto completo, incluso si el resultado final termina siendo bueno.

El presupuesto mal armado tiene un patrón que se repite en casi toda empresa: cubre la licencia del modelo o de la herramienta, cubre las horas de desarrollo, y ahí se detiene. No contempla lo que pasa antes (ordenar los datos, mapear el proceso) ni lo que pasa después (mantenimiento, ajustes, soporte cuando el proceso cambia). Es un presupuesto de proyecto de software genérico con la palabra IA pegada encima, y por eso se queda corto casi siempre en el mismo punto: la operación después del lanzamiento.

• El costo de integrar con sistemas existentes (CRM, ERP, bases de datos internas) casi nunca se cotiza aparte, y suele terminar costando más que el desarrollo del agente o del flujo en sí.
• La limpieza y estructuración de datos previos no aparece como línea de gasto, aunque consuma buena parte del tiempo real del proyecto.
• La capacitación del equipo que va a operar el sistema se trata como algo gratis (“ya les explico yo en una llamada”), y termina siendo la razón por la que el sistema se abandona a los tres meses.
• El mantenimiento mensual (ajustes de reglas o de prompts, revisión de resultados, actualización de integraciones cuando un sistema conectado cambia) se omite porque el presupuesto se pensó como gasto único, no como operación continua.

Qué es presupuestar un proyecto de IA (y qué no es)

No es lo mismo presupuestar que calcular el retorno. Presupuestar responde una pregunta: “¿cuánto necesito reservar y en qué momento?”. Calcular el retorno responde otra distinta: “¿ese gasto se justifica frente al beneficio que trae?”. Son dos ejercicios complementarios, no el mismo: primero se arma el presupuesto completo por fases, y recién con ese número real tiene sentido calcular el retorno (el siguiente paso natural después de esta guía es la guía hermana de cómo calcular el ROI de un proyecto de IA). Presupuestar sin ese segundo paso es pedir dinero a ciegas; calcular retorno sobre un presupuesto incompleto es prometer un resultado que no se puede sostener.

Un presupuesto de IA bien armado tiene tres características que casi nunca aparecen juntas en la primera versión que alguien presenta: está dividido en fases con una decisión explícita de continuar o no entre cada una, separa el gasto en líneas específicas en vez de un total genérico, y reserva una contingencia explícita para lo que no se puede anticipar en el papel. Sin las tres, lo que se presenta no es un presupuesto: es una cotización de proveedor con membrete de proyecto.

Las líneas de gasto que casi nadie presupuesta

Estas son las líneas que aparecen a mitad de proyecto como sorpresa, cuando en realidad se podían anticipar desde el primer día si alguien se hubiera tomado el trabajo de listarlas.

Integración con sistemas existentes

Conectar el sistema de IA con el CRM, el ERP o la base de datos operativa casi nunca es trivial. Cada sistema tiene su propia forma de exponer (o de esconder) la información, y esa conexión suele tomar más horas que construir el flujo o el agente en sí. Si el presupuesto no separa esta línea, el proveedor la absorbe con prisa y mala calidad, o la empresa se entera del costo real cuando ya está a mitad de camino.

Limpieza y estructuración de datos previos

Antes de que cualquier sistema de IA decida bien, alguien tiene que ordenar la información con la que va a trabajar: duplicados, campos vacíos, formatos distintos entre sistemas, historial disperso en hojas de cálculo personales. Este trabajo no es glamoroso, no se ve en una demo, y por eso es la línea que más se subestima. Ignorarla no la elimina: solo la traslada al proyecto ya en marcha, donde cuesta más corregirla.

Capacitación del equipo que va a operar el sistema

Un sistema de IA que el equipo no sabe usar, no sabe revisar y no sabe corregir cuando se equivoca, se abandona. No es un gasto opcional al final: es parte del costo de que el sistema funcione en la operación real, no solo en la demo del proveedor. Presupuestar horas de capacitación y de acompañamiento en las primeras semanas de uso es tan importante como presupuestar el desarrollo.

Mantenimiento y operación mensual

Un sistema de IA no se entrega y se olvida. Las reglas o los prompts necesitan ajuste cuando el proceso cambia, las integraciones se rompen cuando el sistema conectado se actualiza, y alguien tiene que revisar que los resultados sigan siendo correctos. Ese costo recurrente rara vez aparece en la primera cotización porque el proveedor cotiza el proyecto, no la operación después del proyecto.

Consumo variable y licencias

El costo de usar un modelo o una plataforma no siempre es fijo: crece con el volumen de uso. Un piloto con pocos usuarios cuesta distinto que la misma solución en producción con todo el equipo. Si el presupuesto se calculó sobre el volumen del piloto y no sobre el volumen esperado más adelante, el gasto mensual se dispara apenas el sistema escala, y ahí es donde proyectos que iban bien terminan forzados a pausar por un presupuesto mal proyectado.

El paso a paso: arma el presupuesto en fases, no en un número

Un presupuesto de IA sólido no es un total: es un documento con tres bloques, cada uno con su propia decisión de continuar. Esto evita el error más caro de todos, que es comprometer el presupuesto completo de un proyecto grande antes de saber si la idea funciona.

Fase 1: diagnóstico y prueba de concepto

En esta fase se presupuesta lo mínimo necesario para responder una pregunta concreta: ¿este dolor se resuelve con IA, y con qué esfuerzo? Incluye el diagnóstico del proceso, el estado real de los datos disponibles y una prueba de concepto acotada a un solo caso de uso. El presupuesto aquí es bajo a propósito: el objetivo no es construir el sistema final, es reducir la incertidumbre antes de comprometer el gasto grande.

Fase 2: implementación

Recién con el resultado de la prueba de concepto se presupuesta la implementación completa: el desarrollo del sistema, la integración con los sistemas existentes, la limpieza de datos a mayor escala y la capacitación del equipo. Esta fase concentra la mayor parte del gasto, y es también donde más se subestiman las líneas mencionadas arriba. Se presupuesta con el detalle de un proyecto real, no con el estimado optimista de la fase de diagnóstico.

Fase 3: operación

El sistema lanzado tiene un costo mensual que sigue: licencias o consumo variable, mantenimiento, ajustes y soporte. Este número casi nunca se presenta junto con el costo de implementación, y por eso muchas empresas aprueban el proyecto sin entender que están aprobando también un gasto recurrente. Preséntalo siempre como una línea aparte, mensual, desde el primer documento.

• Lista cada línea de gasto por separado (licencia, desarrollo, integración, datos, capacitación, mantenimiento, contingencia) en vez de un total agregado.
• Asigna cada línea a la fase donde ocurre: diagnóstico, implementación u operación.
• Pon un rango, no un número exacto, en las líneas donde la incertidumbre es alta, como integración o limpieza de datos.
• Define el criterio de decisión al final de cada fase: qué tiene que verse cierto para aprobar el paso siguiente.
• Presenta el costo mensual de operación como una línea aparte y permanente, no diluida dentro del costo de implementación.

Cómo defender el presupuesto frente a finanzas (el lenguaje que sí funciona)

Finanzas no aprueba proyectos de IA. Aprueba números que se pueden defender. El error de comunicación más frecuente es pedir presupuesto en el lenguaje de la tecnología (“necesitamos un agente”, “necesitamos IA en el proceso comercial”) en vez del lenguaje del negocio (“esto cuesta X y libera Y en tiempo o en dinero”). Lo primero suena a moda. Lo segundo suena a inversión con retorno esperado, que es lo que un área de finanzas necesita escuchar para decir que sí.

• En vez de “necesitamos IA para el área comercial”, di “este proceso cuesta hoy X horas al mes en seguimiento manual; el sistema cuesta Y y libera esas horas en Z semanas”.
• En vez de un total único, presenta el presupuesto por fase, con el monto bajo de la fase de diagnóstico primero. Es más fácil aprobar un piloto acotado que un proyecto completo sin evidencia.
• En vez de esconder la contingencia dentro de otra línea, decláralo como línea propia con su porcentaje y su razón de ser. Finanzas confía más en un presupuesto que admite incertidumbre que en uno que promete precisión que no tiene.
• En vez de hablar de resultados abstractos, ancla cada línea de gasto a un KPI concreto: horas recuperadas, tiempo de respuesta, tasa de error, costo por operación.

El resultado de este cambio de lenguaje no es solo obtener el sí. Es que, cuando el proyecto pida presupuesto adicional más adelante (y a veces va a pasar, aunque el presupuesto esté bien armado), finanzas ya tiene el marco para evaluar ese pedido en vez de sentir que lo engañaron con el número inicial.

Errores comunes al presupuestar un proyecto de IA

• Presentar un solo número total en vez de un presupuesto por fases y por línea de gasto: es la razón número uno por la que un segundo pedido de dinero destruye la confianza en el proyecto.
• Copiar el presupuesto de otra empresa o de un caso publicado, ignorando que el estado de los datos, los sistemas existentes y el volumen de uso son distintos en cada operación.
• No reservar contingencia, o reservarla tan baja que no cubre nada real, porque un número redondo y bajo se ve mejor en la reunión de aprobación.
• Presupuestar la implementación pero no la operación mensual, dejando a la empresa con un sistema que funciona pero que nadie previó cómo pagar en el mes doce.
• Dejar la capacitación y la adopción del equipo fuera del presupuesto, tratándola como un detalle de último momento en vez de una línea con horas y responsable asignado.

Cómo se ve en la práctica

Un caso ilustrativo, anonimizado. Una empresa de logística de tamaño mediano quería automatizar la asignación de rutas y el seguimiento de entregas con IA. La primera versión del presupuesto que trajo un proveedor externo tenía un solo número: la licencia de la plataforma más las horas de desarrollo. Nada de integración con el sistema de flotas que ya usaban, nada de limpieza de la información de clientes que vivía repartida entre varias hojas de cálculo, nada de mantenimiento mensual.

Al rearmar el presupuesto por fases, la fase de diagnóstico y prueba de concepto quedó acotada a un solo tipo de ruta, con un costo bajo y un criterio de éxito claro: reducir el tiempo de asignación manual de forma medible. La fase de implementación sumó, por primera vez, la línea de integración con el sistema de flotas (que terminó siendo la parte más cara del proyecto, no la más barata) y la línea de limpieza de datos de clientes. La fase de operación quedó declarada como costo mensual aparte, con el mantenimiento y el ajuste de reglas incluidos desde el inicio.

El número final aprobado fue mayor al de la primera cotización. Pero fue el que se ejecutó sin sorpresas, porque cada línea ya estaba anticipada y nadie tuvo que volver a pedir presupuesto adicional a mitad de camino, que es justo el momento en que un proyecto pierde apoyo interno.

Mi criterio y cómo saber si el presupuesto se ejecutó bien

Un presupuesto de IA bien ejecutado no se mide por haber gastado exactamente lo proyectado (eso casi nunca pasa, ni debería ser la meta). Se mide por otra cosa: que las desviaciones queden dentro de la contingencia declarada, y que nadie tenga que volver a pedir aprobación de emergencia a mitad de proyecto.

• El gasto real de cada fase se mantuvo dentro del rango presupuestado más la contingencia, sin pedidos de emergencia fuera de ese margen.
• La fase de operación mensual quedó presupuestada y aprobada desde el inicio, no descubierta después del lanzamiento.
• Finanzas pudo relacionar cada línea de gasto con un KPI de negocio, no solo con una descripción técnica.
• El proyecto no se detuvo ni se congeló por falta de presupuesto para una línea que ya estaba identificada desde el diagnóstico.