Cómo se desglosa de verdad el costo de desarrollo de IA

Una función de IA puede costar 8.000 $. También puede costar 80.000 $. Ese salto se remonta a decisiones tomadas la primera semana de alcance mucho más a menudo que al modelo que elegiste: cuánta infraestructura a medida necesita la función, cuánto de tus propios datos tiene que aprender y cuántas pruebas hacen falta antes de que confiarías en ella frente a un cliente real. La mayoría de las estimaciones de costo de desarrollo de una app de IA en internet describen una demo de cinco minutos. Una función en producción que sobrevive a un cliente enojado, a una pregunta ambigua y a tres mil sesiones simultáneas cuesta algo totalmente distinto, incluso sobre el mismo modelo. Este artículo pone precio a esa diferencia: por tipo de función, por cómo se ve una factura de modelo con tráfico real, y por a cuánto suma un presupuesto completo de MVP de IA una vez que cuentas datos y evaluación.

El costo de desarrollo de una app de IA sigue cuatro variables más de cerca que la lista de funciones: cuánto se apoya en una API de proveedor frente a un modelo entrenado con tus propios datos, cuán listos están esos datos, qué tan profundo debe ir el trabajo de evaluación y guardrails, y a cuántos sistemas tiene que conectarse. Un ancla de planificación que vale la pena tener en mente: una sola función de IA suele subir tanto el costo como el plazo de un build comparable un 15 a 30 por ciento, sea esa función un chatbot simple o una pipeline RAG completa. Un chatbot que responde una FAQ estática es un build estrecho. Un motor de recomendación entrenado con tu propio historial de transacciones y cableado a tres sistemas internos lleva la misma etiqueta de 'función de IA' y no cuesta nada parecido, y así es como los fundadores acaban comparando un presupuesto de función de IA con un alcance totalmente distinto. Quién acaba armando el build también cambia el número. La mayoría de las funciones en etapa MVP no necesitan un científico de investigación, solo un ingeniero cómodo con el diseño de prompts y el trabajo de API. ¿Todavía decidiendo si una función de IA pertenece a la roadmap de este trimestre? Nuestro equipo de servicios de integración de IA suele empezar con una llamada de alcance antes de escribir código.

Nombrar la función importa más que pegar la palabra 'IA' en una línea de roadmap. Un chatbot FAQ con guion y un modelo de scoring de fraude a medida comparten por casualidad esa etiqueta y nada más en alcance. Así se desglosa el costo en etapa MVP entre los cuatro tipos de función que más nos piden acotar. Trata estos números como rangos de planificación de builds reales, no una cotización. El volumen de datos y cuán estrictos deben ser los guardrails inclinan un proyecto hacia uno u otro extremo de su fila.

Los costos de API de LLM se comportan distinto antes y después del lanzamiento, pillando a los fundadores desprevenidos casi tan seguido como la propia cotización de build. Antes del lanzamiento, un puñado de desarrolladores probando prompts es toda la factura. Después del lanzamiento, cada sesión suma, y los costos de tokens escalan con el uso de una forma en que el costo fijo de desarrollo nunca lo hizo. El nivel de modelo mueve la mayor parte de esa factura: un modelo de frontera cuesta bastante más por solicitud que uno más pequeño y rápido, y muchas funciones andan bien sin el modelo más grande disponible. La longitud del prompt importa después, porque un system prompt cargado de instrucciones y contexto recuperado se factura en cada llamada. La longitud de la salida también importa, porque un modelo que se explica largo cuesta más de operar que uno que responde directo. Los precios de los proveedores cambian con la frecuencia suficiente como para que un número por token concreto aquí quedara obsoleto en meses. Lo que aguanta más: cachear prompts repetidos, poner tope a la longitud de salida y enrutar solicitudes fáciles a un modelo más barato. Presupuesta el costo de API como una línea recurrente real, no una ocurrencia tardía metida en el hosting.

La preparación de datos es la línea que la mayoría de los primeros presupuestos de IA se saltan, y normalmente la que revienta el plazo. Un modelo, ya llames a una API o entrenes algo a medida, refleja los datos que le entregas y nada más. Datos desordenados y dispersos suman en silencio semanas que nadie acotó, mucho antes de amenazar con detener un build. El costo de implementación de RAG sube más rápido cuando los documentos fuente están dispersos en formatos que nadie ha tocado en años. Una función basada en recuperación necesita ingestión, limpieza, chunking, embeddings y un vector store que tu app pueda consultar lo bastante rápido como para sentirse instantáneo. Los productos multi-tenant suman otra capa: los documentos privados de una cuenta tienen que quedar aislados de los resultados de cualquier otra cuenta. Un modelo entrenado a medida necesita algo distinto: suficientes ejemplos históricos etiquetados y un proceso para mantener esos datos al día a medida que cambian los patrones. El fine-tuning y la recuperación resuelven problemas distintos con necesidades de datos distintas, y cuál encaja antes de comprometer presupuesto a cualquiera de los dos merece su propio análisis en este mismo grupo de artículos. Presupuesta el trabajo de pipeline como su propia fase, o espera encontrar el problema real de datos en la semana seis, justo cuando la demo se suponía que ocurriría.

La evaluación es el costo que los fundadores presupuestan al final y necesitan más. Sáltatelo y lanzarás una función que se ve genial en una demo y se cae en la primera pregunta que nadie pensó en probar, con la frecuencia suficiente como para ser la razón principal de que una función de IA se retire en silencio de producción semanas después del lanzamiento. Un dispositivo de evaluación real necesita un conjunto de prueba construido con las preguntas que los usuarios de verdad hacen en vez de los ejemplos amables de un pitch deck, una forma consistente de puntuar respuestas, a menudo una mezcla de comprobaciones automáticas y revisión humana, y un proceso para volver a correr ese conjunto cada vez que cambia un prompt o un modelo. Los guardrails son la otra mitad: reglas de qué no puede responder la función, qué datos tiene permitido tocar y el punto en que deja de adivinar e incorpora a una persona. Un copiloto de soporte que ve saldos de cuenta necesita guardrails más estrictos que un chatbot que responde preguntas públicas de un centro de ayuda. Presupuesta el trabajo de evaluación y guardrails en torno a un quinto o un tercio del costo total de la función para cualquier cosa de cara al cliente. Un análisis dedicado en este mismo grupo cubre cómo construir ese conjunto de prueba y mantenerlo útil a medida que el producto cambia.

Una cotización de build para una función de IA pone precio al lanzamiento. Los meses posteriores cargan sus propios costos reales, del tipo que solo aparece una vez que usuarios reales empiezan a golpear la función. El reentrenamiento y la reindexación están en lo alto de esa lista: un modelo de fraude deriva a medida que cambian los patrones de transacción, y el índice de un asistente RAG se pone rancio en cuanto tu contenido cambia y nadie actualiza el vector store. El monitoreo viene después: el uso de tokens, la latencia y la calidad de las respuestas también necesitan seguimiento en producción, porque las pruebas por sí solas no atrapan una actualización de modelo de un proveedor que cambia en silencio cómo se comporta tu función de la noche a la mañana. Sinceramente, la mayoría de los equipos gastan de menos aquí al principio y lo pagan después con un pico de tickets de soporte que nadie logra explicar del todo. Luego está la capa humana: alguien revisa conversaciones marcadas, reentrena en casos límite y decide cuándo un guardrail es demasiado estricto. Presupuesta unas horas por semana una vez que la función sale, comúnmente 500 a 2.500 $ al mes por monitoreo y revisión combinados. El mantenimiento común tampoco desaparece. Los parches de seguridad y las actualizaciones de dependencias que no tienen nada que ver con la IA en específico siguen costando 15 a 20 por ciento del costo de build al año, la tasa estándar para cualquier producto de software.

Los contratos por hora asumen que nada del build sorprenderá a nadie. Las funciones de IA rompen esa suposición más a menudo que un build típico, ya que los resultados de evaluación son genuinamente desconocidos al momento del alcance. No sabrás que un dispositivo de recuperación responde mal el 15 por ciento de las preguntas reales hasta que lo hayas construido y probado, y arreglarlo puede significar rediseñar la estrategia de chunking en vez de retocar un solo prompt. El precio de alcance fijo pone esa incertidumbre en el equipo en vez de en ti. Un equipo acota el build, incluido un ciclo de evaluación definido, y se compromete a un número y a un listón de calidad que la función tiene que superar antes del lanzamiento. Un requisito genuinamente nuevo se cotiza como orden de cambio en cuanto surge, resuelto antes de que se emita la siguiente factura. La compensación: el equipo necesita un alcance real al entrar, así que el descubrimiento ocurre antes de firmar. ¿Pesando esto frente a construir todo el MVP con herramientas de IA integradas en tu propio proceso? Nuestra guía de desarrollo de MVP potenciado por IA cubre ese camino por completo.

Un rango es fácil de aprobar con un gesto. Poner un número real frente a un cofundador es otro ejercicio. Aquí van tres formas de presupuesto de MVP de IA de builds reales.

• Un chatbot de soporte atornillado a una app de consumo existente: 45.000 $ de base más una capa de chatbot de 12.000 $, dentro de la fila de chatbot con guion de arriba. Diez semanas, sin recuperación a medida porque el contenido de la FAQ ya estaba limpio.
• Un producto B2B SaaS que agrega un asistente RAG sobre su documentación: 110.000 $ de base más una capa de IA de 25.000 $, más o menos un 23 por ciento de aumento en el borde bajo de la fila RAG; nuestro desglose del costo de MVP SaaS pone precio a ese mismo build en 135.000 $ sobre 18 semanas.
• Un neobanco que agrega una capa de scoring de fraude a medida sigue otra forma. En vez de volver a derivar esos números, nuestra guía de costo de desarrollo de app fintech ya lo pone en precio: la base más el complemento de scoring de fraude aterrizan justo por encima de 160.000 $, a lo largo de 25 semanas.

Tu costo de MVP de IA se situará cerca de uno de estos tres, cambiando según lo limpios que estén tus datos y cuántos sistemas toca la función.