Cómo se cobra un proyecto de IA: por hora, por proyecto o por resultado

Por qué casi nadie negocia la estructura de cobro (solo el monto)

Casi ninguna empresa que contrata un proyecto de IA se detiene a revisar cómo se le va a cobrar. Recibe dos o tres propuestas, compara el monto final de cada una, y elige la que le parece más razonable o la que mejor negoció el precio. Lo que casi nadie mira es la estructura detrás de ese número: si es por hora, por proyecto cerrado, por retainer mensual o por resultado. Y esa estructura, no el monto, es la que decide quién carga el riesgo cuando el alcance cambia, el proyecto se alarga o el sistema no entrega lo que prometía.

El proveedor sí piensa en esto, aunque no lo discuta en la reunión de venta. Elige el modelo que mejor lo protege a él: si sabe que el alcance del cliente es difuso, prefiere cobrar por hora, porque cualquier hora adicional la paga el cliente. Si el alcance es claro y ya calculó bien el esfuerzo, prefiere un monto cerrado, porque cualquier eficiencia que gane trabajando rápido se la queda él. El cliente, mientras tanto, negocia el diez por ciento de descuento en el número final y deja pasar la decisión que de verdad importaba.

Esta guía no habla de cuánto cuesta un proyecto de IA ni de los factores que mueven el precio hacia arriba o hacia abajo, eso ya está resuelto en otra guía de este mismo centro. Habla de la estructura: los cuatro modelos reales de cobro, en qué tipo de proyecto conviene cada uno, y cómo negociar el modelo correcto en vez de aceptar el que el proveedor puso por defecto en la propuesta.

Qué es la estructura de cobro (y qué no)

No es una lista de tarifas ni de rangos de precio, eso depende del tamaño del proyecto y del proveedor. Es el mecanismo que traduce el trabajo en un monto a pagar, y ese mecanismo reparte el riesgo de forma distinta según el modelo elegido. Un mismo proyecto, cobrado por hora o cobrado por proyecto cerrado, puede terminar costando lo mismo en dólares y aun así dejar a partes completamente distintas cargando el riesgo si algo sale mal en el camino.

• Una lista de rangos de precio por hora o por proyecto (esa comparación está en la guía de cuánto cuesta contratar un consultor de IA).
• Una decisión que el proveedor deba imponer sin explicarla: cualquier proveedor serio puede justificar por qué propone ese modelo para ese proyecto en particular.
• Cuatro variaciones del mismo contrato con distinto nombre: cada modelo traslada el riesgo de sobrecosto, de cambio de alcance o de resultado a una parte distinta.
• Un modelo único que sirve para cualquier etapa del proyecto: un diagnóstico corto, una implementación con entregable y un mantenimiento continuo casi nunca deberían cobrarse igual.

Los cuatro modelos reales de cobro (y qué riesgo carga cada uno)

En la práctica, casi todo proyecto de IA se cobra bajo una de cuatro estructuras. Ninguna es superior en abstracto: cada una calza con un tipo de trabajo distinto y traslada el riesgo a una parte distinta cuando algo no sale como se planeó.

• Por hora (time and materials). Se paga por el tiempo real invertido, con una tarifa horaria o diaria acordada de antemano. Da flexibilidad para ajustar el alcance sobre la marcha sin renegociar todo el contrato, algo útil cuando nadie sabe todavía con precisión cuánto trabajo va a tomar. El riesgo lo carga el cliente: sin un tope acordado o un reporte de horas periódico, el gasto puede crecer sin que nadie lo note hasta la factura de fin de mes.
• Por proyecto cerrado (fixed fee). Se acuerda un monto único por un alcance específico, documentado por escrito antes de firmar. El cliente sabe exactamente cuánto va a pagar, y el riesgo de haber calculado mal el esfuerzo lo carga el proveedor. El riesgo real para el cliente aparece después de firmar: cualquier cambio de alcance se cobra aparte, y un proveedor que subestimó el trabajo tiende a recortar calidad o a discutir cada ajuste como “fuera de alcance”.
• Retainer mensual. Se paga un monto fijo cada mes por una capacidad de trabajo disponible (ciertas horas, cierto número de casos de soporte, cierto tiempo de respuesta), no por un entregable puntual. Da predictibilidad de gasto para sostener un sistema que ya está en producción. El riesgo para el cliente es pagar por una capacidad que no usa completa, o contratar a un proveedor que reparte esa capacidad entre demasiados clientes a la vez y responde tarde cuando de verdad se necesita.
• Por resultado o performance. Una parte o la totalidad del pago se ata a una métrica de negocio medible y acordada de antemano: leads generados, horas ahorradas, reducción de errores, ingreso incremental atribuible al sistema. Alinea el incentivo del proveedor con el resultado real del cliente, no con las horas facturadas. Exige algo que la mayoría de proyectos de IA todavía no tiene resuelto con precisión: una línea base medida antes de empezar y un método de atribución que ambas partes acepten como válido.

Qué modelo conviene según el tipo de proyecto

El error más común no es elegir mal un modelo, es usar el mismo modelo para todo el ciclo de vida del proyecto. Un diagnóstico corto, una implementación con entregable definido y un mantenimiento continuo son tres tipos de trabajo distintos, y cada uno tiene un modelo de cobro que le calza mejor.

• Diagnóstico corto (una a dos semanas). Por hora con un tope acordado, o tarifa fija de alcance acotado. Nunca retainer: todavía no hay nada continuo que sostener, y pagar capacidad mensual por un trabajo de dos semanas es pagar de más sin motivo.
• Implementación de alcance definido (un caso de uso con entregable claro). Por proyecto cerrado, con el alcance documentado línea por línea: qué incluye, qué no incluye, quién aprueba un cambio y cómo se cobra si aparece uno. Es el modelo que más protege al cliente del sobrecosto, siempre que el alcance esté por escrito antes de firmar.
• Mantenimiento y soporte continuo de un sistema ya en producción. Retainer mensual, porque el valor no es un entregable puntual sino la disponibilidad de alguien que responda cuando el sistema falla o necesita un ajuste. Definir la capacidad exacta (horas, casos, tiempo de respuesta) evita pagar por una disponibilidad que en la práctica no existe.
• Un caso donde de verdad se puede atar el pago a un resultado medible. Por ejemplo, un sistema de calificación de leads conectado al CRM con conversión medible, o una automatización de cobranza con reducción de días de mora medible. Por resultado, parcial o total, solo cuando ya existe una línea base limpia y un método de atribución acordado por escrito antes de empezar, no como promesa verbal en la reunión de venta.

El modelo “por resultado” es el que más se vende como diferenciador y el que menos se ejecuta bien. Cualquier proveedor puede ofrecerlo en una propuesta; pocos pueden explicar, con números concretos, contra qué línea base se va a medir el resultado y quién decide si una mejora es atribuible al sistema o a otra causa. Si no puede responder eso con precisión, lo que está ofreciendo es un contrato cerrado disfrazado de pago por resultado.

Cómo negociar el modelo correcto (en vez de aceptar el que te proponen)

La mayoría de las propuestas llega con un modelo de cobro ya elegido por el proveedor, casi nunca discutido con el cliente antes de escribirse. El proveedor elige el modelo que más lo protege a él, no el que mejor calza con el tipo de proyecto. Negociar la estructura, no solo el monto final, es donde el cliente recupera control real sobre el riesgo que está aceptando.

• Pregunta por qué ese modelo, antes de negociar el número. Si la respuesta es “así trabajamos siempre”, es señal de que el modelo se eligió por costumbre del proveedor, no porque calce con tu proyecto.
• Exige el alcance por escrito antes de aceptar un monto cerrado. Un precio fijo sin alcance documentado no es un proyecto cerrado, es una promesa verbal con un número al lado.
• Pide un tope o un reporte de horas si el modelo es por hora. Sin un techo acordado o visibilidad semanal del gasto, “por hora” se convierte en un cheque en blanco que solo se descubre completo al final.
• Divide un proyecto largo en fases con modelos distintos. Diagnóstico por hora o tarifa fija corta, implementación por proyecto cerrado, mantenimiento posterior por retainer: nada obliga a forzar todo el ciclo de vida bajo un solo contrato firmado el primer día.
• Desconfía del pago por resultado sin línea base. Si el proveedor lo ofrece pero no puede explicar contra qué número de partida se va a medir ni quién decide la atribución, esa oferta es un argumento de venta, no una cláusula ejecutable.

Errores comunes al aceptar cómo se cobra un proyecto de IA

• Aceptar el modelo que trae la propuesta sin preguntar por qué ese y no otro.
• Firmar “por proyecto cerrado” sin un alcance documentado línea por línea de lo que incluye y lo que se cobra aparte.
• Contratar un retainer mensual para un trabajo que en realidad es una implementación puntual con fecha de término, y terminar pagando meses de capacidad que nadie usó.
• Aceptar “pago por resultado” como frase de venta sin acordar antes la línea base y el método de atribución por escrito.
• Usar el mismo modelo de cobro para todo el ciclo de vida del proyecto (diagnóstico, implementación, mantenimiento) en vez de ajustar el modelo a cada etapa.

Cómo se ve esto en la práctica

Una empresa de retail mediana, en Perú, alrededor de 80 personas, quería un asistente de atención al cliente por WhatsApp conectado a su catálogo de productos. El proveedor que más le gustó presentó una sola propuesta “por proyecto cerrado” que incluía en un solo número el diagnóstico inicial, la implementación completa y seis meses de mantenimiento posterior.

El área de finanzas pidió separar el número antes de firmar. El diagnóstico se recontrató por hora, con un tope de una semana de trabajo. La implementación se mantuvo por proyecto cerrado, pero con el alcance documentado línea por línea: qué canales cubría el asistente, qué catálogo de productos, cuántas iteraciones de ajuste incluía el precio antes de cobrar horas adicionales. El mantenimiento se separó en un retainer mensual aparte, con una capacidad definida de horas de soporte y un tiempo de respuesta máximo acordado por escrito.

El total en dólares terminó siendo similar al de la propuesta original. Lo que cambió fue la visibilidad: la empresa pudo revisar el diagnóstico antes de comprometerse con la implementación completa, y pudo renegociar o incluso cambiar de proveedor para el mantenimiento sin tocar el contrato de implementación ya cerrado. El pago por resultado no se usó, porque al momento de firmar no existía una línea base limpia de tiempo de respuesta ni de conversión por WhatsApp contra la cual medir una mejora atribuible al sistema.

Mi criterio

Cómo saber si negociaste bien la estructura de cobro

La estructura de cobro se negoció bien cuando se puede explicar en menos de un minuto, sin revisar el contrato.

• Sabes qué modelo de cobro rige cada fase del proyecto (diagnóstico, implementación, mantenimiento), no un contrato genérico para todo el ciclo de vida.
• Si el modelo es por hora, existe un tope acordado o un reporte periódico de horas, no un gasto abierto que se descubre completo al final del mes.
• Si el modelo es por proyecto cerrado, el alcance está documentado por escrito, con lo que incluye y lo que se cobra aparte si cambia.
• Si el modelo es retainer, sabes exactamente qué capacidad estás pagando (horas, casos, tiempo de respuesta) y qué pasa si no se usa completa en un mes.
• Si negociaste pago por resultado, existe una línea base medida antes de empezar y un método de atribución que ambas partes aceptaron por escrito, no una promesa verbal de la reunión de venta.

Si no puedes responder estos cinco puntos sobre el contrato que ya firmaste, no negociaste la estructura de cobro: negociaste solamente el número final, y dejaste que el proveedor decidiera, sin discutirlo, quién carga el riesgo del proyecto.