Tres propuestas llegan a su mesa para la misma necesidad. La primera habla de POC, la segunda de piloto, la tercera de MVP. Las tres prometen comprobar si la IA tiene algún interés en su actividad. Ninguna describe lo mismo. Firmar la más barata puede costarle más que la más cara, porque la factura que importa no es la del prototipo: es la que empieza cuando termina la demostración.
Key Takeaways
- Un POC verifica una hipótesis técnica. No produce un servicio utilizable.
- Un piloto mide una ganancia sobre un perímetro real, con usuarios reales y un indicador de referencia.
- Un MVP pone un servicio en producción con su soporte, su supervisión y su reversibilidad.
- La diferencia de precio entre los tres rara vez viene del desarrollo: viene de lo que la propuesta incluye después de la demo.
- Según Gartner (2024), al menos el 30 % de los proyectos de IA generativa se abandonarán tras la fase de POC. La pregunta que hay que hacer antes de firmar es sencilla: ¿qué pasa si paramos?
Tres fórmulas, tres preguntas distintas
Un POC responde a una pregunta de viabilidad: ¿puede funcionar con nuestros datos y nuestras restricciones? El entregable es un demostrador y una nota. Nadie lo usa en el trabajo diario y nadie prometió que se pudiera.
Un piloto responde a una pregunta de valor: ¿produce una ganancia medible cuando personas reales lo usan en tareas reales? El entregable es una herramienta en servicio sobre un perímetro limitado, con una medición antes y después.
Un MVP responde a una pregunta de explotación: ¿cuál es la versión más pequeña que puede prestar el servicio de forma continua, sin hundirse en el primer incidente? El entregable es un servicio utilizado por usuarios reales, supervisado, documentado y con una forma conocida de sustituirlo.
Esa diferencia de pregunta produce una diferencia de factura. No es proporcional al esfuerzo de desarrollo. Es proporcional a todo lo que hay que añadir para que un demostrador se convierta en una herramienta que su empresa pueda dejar funcionando.
| Fórmula | Pregunta | Entregable principal | Quién lo usa | Lo que queda por pagar después |
|---|---|---|---|---|
| POC | ¿Es técnicamente viable? | Demostrador y nota de viabilidad | El equipo del proyecto | Integración, seguridad, soporte, formación |
| Piloto | ¿Qué ganancia sobre un perímetro real? | Herramienta en servicio limitado y medición de la ganancia | Un grupo reducido | Escalado, soporte, licencias |
| MVP | ¿Qué servicio mínimo aguanta producción? | Servicio utilizable, supervisado, documentado | Usuarios reales | Mantenimiento, evoluciones, migraciones de modelo |
Lo que paga realmente en un POC
Un POC se factura en cuatro partidas, en un orden de peso que suele sorprender a los directivos.
La primera es la preparación de los datos. Extraer muestras, anonimizar, construir un conjunto de prueba representativo: rara vez es espectacular y casi siempre es la partida más pesada.
La segunda es la iteración técnica. Redacción de instrucciones, descomposición de tareas, comparación de modelos, evaluación de respuestas. Un POC serio se juzga por la calidad de su protocolo de evaluación, no por la belleza de una demo.
La tercera es el consumo de los modelos. Sigue siendo modesto a esta escala, pero existe y varía. Una propuesta que lo presenta como "incluido" sin límite debe leerse con atención.
La cuarta partida casi nunca aparece en el presupuesto: su propio tiempo. Un POC moviliza a sus expertos de negocio para definir casos, revisar respuestas y decidir qué errores son aceptables. Ese coste es real, sale de su masa salarial y es la primera causa de retraso.
Lo que un POC no incluye por definición: la integración con su sistema de información, la autenticación, el registro de eventos, el cumplimiento normativo, la formación, el soporte. No es una omisión deshonesta. Es la definición misma del formato. El problema empieza cuando la propuesta vende un POC y deja creer que bastará para poner el servicio en producción.
Gartner sitúa los costes de los enfoques de despliegue de IA generativa entre 5 y 20 millones de dólares para proyectos de transformación del modelo de negocio, un orden de magnitud que afecta a grandes grupos, no a una pyme. La lección útil no es el importe, es la razón que da Gartner: los abandonos tras el POC se deben a la calidad de los datos, a controles de riesgo insuficientes, a costes que suben o a un valor mal definido. Tres de esas cuatro causas se deciden antes de la firma, no durante el desarrollo.
El piloto: la factura cambia de naturaleza
Un piloto añade tres cosas que un POC no tiene, y cada una tiene un precio.
Primero el perímetro. Hay que elegir un proceso, un número de usuarios y un volumen de expedientes, y mantenerse en ello. Un piloto que se amplía a mitad de camino se convierte en un proyecto, con presupuesto de proyecto, pero sin sus salvaguardas.
Después la medición. Un piloto sin indicador de referencia definido de antemano es un POC disfrazado, facturado más caro. La referencia se toma antes del arranque, sobre datos que usted acepta mirar: tiempo de tratamiento, tasa de error, número de idas y vueltas, plazo de respuesta al cliente. Sin esa foto inicial, la demostración final se cerrará con impresiones.
Por último la integración parcial. El piloto debe tocar sus herramientas, aunque sea de forma modesta: un buzón, un CRM, un programa de gestión, una carpeta compartida. Ahí es donde la propuesta técnica se encuentra con la realidad de sus accesos, sus permisos y sus datos. También es donde aparecen los costes recurrentes: licencias, consumo de modelos, alojamiento, entornos de prueba.
Se añaden dos partidas fáciles de olvidar. La gestión del cambio, con formación de usuarios y designación de referentes internos. Y el marco jurídico: información a los empleados, registro de tratamientos, contrato de encargado de tratamiento con el proveedor del modelo, plazo de conservación de los intercambios.
En esta fase la pregunta correcta ya no es "cuánto cuesta el piloto" sino "cuánto cuesta el piloto y la decisión que va con él". Un piloto exitoso cuya continuidad nadie ha preparado termina en un informe que nadie lee.
El MVP: el gasto más pesado ya no es el desarrollo
Cuando un servicio pasa a producción, el reparto del gasto se invierte. El código representa una parte cada vez menor. Lo que pesa es lo que mantiene el servicio en marcha.
La supervisión: quién mira los registros, quién recibe la alerta cuando una respuesta llega vacía o absurda, con qué plazo de intervención.
El ciclo de vida de los modelos: los proveedores retiran y sustituyen sus versiones con regularidad. Un servicio construido sobre una versión fija debe prever pruebas de nuevo en cada cambio, o la calidad se degrada sin que nadie lo haya decidido.
La seguridad y el cumplimiento continuos: permisos de acceso, datos personales en los registros, subcontratistas sucesivos, conservación.
La documentación y la transferencia: una empresa que no puede explicar su propia herramienta se vuelve dependiente de quien sí puede.
La reversibilidad, por último. ¿Quién posee el código, las instrucciones, los conjuntos de evaluación, los datos preparados? ¿Qué pasa si el proveedor desaparece o si usted cambia de suministrador? Ese coste de salida se negocia antes de la firma, nunca después. En este punto concreto, las cláusulas de reversibilidad de un agente de IA merecen leerse antes de comparar los precios de entrada.
El contexto hace este examen más necesario de lo que parece. Según Gartner (2025), más del 40 % de los proyectos de IA agéntica se cancelarán antes de finales de 2027, por costes que suben, valor poco claro o controles de riesgo insuficientes. El mismo comunicado estima que, de los miles de editores que se presentan como agénticos, solo unos 130 lo son realmente. Dicho de otro modo: parte de lo que usted paga a precio de MVP podría ser solo un asistente con otro nombre.
Lo que el precio mostrado no dice
Dos propuestas por el mismo importe pueden esconder compromisos opuestos.
La estructura de facturación, primero. Un precio cerrado le protege de las desviaciones pero empuja a reducir el perímetro. La tarifa por tiempo y materiales le deja el control pero le transfiere el riesgo. La suscripción parece ligera el primer año y se vuelve pesada cuando el servicio es indispensable. Compare siempre el coste del segundo año, no solo el del primero.
Los hitos, después. Una propuesta sin criterios de aceptación escritos, con pago contra entrega de un "prototipo funcional", le deja como único juez de un desacuerdo. Los criterios deben ser medibles: tasa de respuestas correctas sobre un conjunto de prueba definido de antemano, tiempo de tratamiento, tasa de escalado humano aceptada.
La propiedad intelectual. Las instrucciones, los conjuntos de prueba y las evaluaciones son activos. Si se quedan en el proveedor, usted financia la construcción de un conocimiento que no posee.
El compromiso de resultado. Pocos proveedores aceptan firmarlo en un tema donde la calidad depende de sus datos. Un compromiso de medios bien descrito vale más que una promesa de resultado difusa. Consulte lo que debe contener un presupuesto de agente de IA para la lista de menciones que hay que exigir.
Las ayudas públicas, por último. El crédito fiscal francés de investigación cubre el 30 % de los gastos de I+D elegibles hasta 100 millones de euros, según el Ministerio de Economía. Un trabajo de experimentación y prototipado puede entrar, un despliegue estándar mucho menos. El cálculo se hace con su asesor fiscal, antes de firmar, no en el momento de la declaración.
Cuatro preguntas para separar dos propuestas
- ¿Qué entregable exacto, y quién lo usa el último día del contrato? Si la respuesta es "el equipo del proyecto", usted compra un POC, sea cual sea el nombre en la portada.
- ¿Qué indicador se mide y cuál es su valor de partida? Sin referencia no hay ganancia, solo una impresión.
- ¿Qué pasa si paramos? Coste de salida, recuperación de los datos, propiedad del código y de las instrucciones, duración del periodo de transición.
- ¿Cuánto cuesta el segundo año? Licencias, consumo, soporte, mantenimiento, pruebas repetidas por los cambios de modelo.
Un proveedor serio responde a esas cuatro preguntas por escrito antes de que usted firme. Un proveedor que las considera prematuras le está pidiendo pagar para descubrirlo.
Si prepara el asunto de antemano, un pliego de condiciones de proyecto de IA hace comparables esas respuestas de una propuesta a otra.
FAQ
¿Es siempre necesario un POC?
No. Lo es cuando la incertidumbre es técnica: datos incompletos, calidad dudosa, muchos casos límite. Deja de serlo cuando la viabilidad ya está demostrada por usos comparables y la verdadera pregunta es la adopción por sus equipos. En ese caso, un piloto mal delimitado le enseñará más que un POC exitoso.
¿Se puede pasar directamente a un MVP?
Sí, siempre que acepte que el MVP asume la incertidumbre en su lugar. Usted paga entonces por aprender en producción, con usuarios reales, lo que a veces es la única forma de obtener una respuesta fiable. El precio de ese atajo es un riesgo de explotación mayor en el arranque y una deuda de diseño que habrá que tratar.
¿Por qué dos proveedores anuncian precios tan distintos para el mismo POC?
Porque la palabra POC no describe un perímetro. Uno factura una demostración sobre datos preparados por usted, el otro una evaluación sobre datos reales con protocolo de medición e informe de límites. El segundo cuesta más y a menudo evita un proyecto siguiente inútil.
¿Quién paga las licencias y el consumo de los modelos?
Es una cuestión de contrato, no de técnica. Una propuesta que los incluye sin límite se protege con un tope de uso; una propuesta que los excluye debe anunciar un orden de magnitud mensual. Pida el coste por usuario y por mes, y el volumen a partir del cual cambia de naturaleza.
¿Puede un POC de IA acogerse al crédito fiscal de investigación?
Puede, si los trabajos entran en I+D en el sentido fiscal: búsqueda de soluciones nuevas, protocolos de ensayo, documentación de los obstáculos técnicos. La integración de una herramienta existente generalmente no entra. La calificación se prepara con su asesor y se documenta durante el proyecto, no después.
Conclusión
La diferencia entre un POC, un piloto y un MVP no es una diferencia de tamaño. Es una diferencia de responsabilidad. Un POC le dice si es posible. Un piloto le dice si merece la pena. Un MVP le compromete a hacer funcionar el servicio, con su soporte, sus costes recurrentes y su salida.
El precio mostrado rara vez mide eso. Mide lo que el proveedor aceptó escribir. Antes de comparar tres importes, pida tres perímetros, tres indicadores y tres costes de salida. Descubrirá a menudo que la propuesta más barata no habla del mismo proyecto.
NexeAI interviene en estas tres fórmulas para pymes: delimitación y auditoría de IA para decidir la viabilidad, piloto sobre un proceso identificado, puesta en producción de un agente de IA o de una automatización con los costes de funcionamiento escritos con claridad. El primer paso consiste en describir lo que usted acepta pagar y lo que se niega a pagar dos veces. Hablemos de su proyecto.
