Hay una conversación que tuve hace algo más de un año con un cliente que me cambió la perspectiva completamente. Le había pasado una propuesta para un proyecto de automatización de documentos. Me preguntó cuántas horas me llevaría. Le dije que unas veinte. Me ofreció pagar por esas veinte horas.
El problema era que yo sabía que iba a construir algo que luego podría reutilizar con otros cinco clientes del mismo sector sin tener que empezar desde cero. Si cobraba por horas, el cliente pagaría veinte horas una vez. Si cobraba por el sistema, podría estructurarlo como una licencia mensual y multiplicar el valor real del trabajo que iba a hacer.
Ese día empecé a pensar de forma diferente sobre qué es lo que realmente vendo cuando trabajo con IA.
El problema con cobrar por horas en un contexto de automatización
La lógica del trabajo por horas tiene sentido cuando el valor que entregas está directamente ligado al tiempo que inviertes. Un abogado que cobra por hora, un consultor que factura por jornada, un diseñador que cobra por proyecto estimando horas. En todos esos casos, más tiempo equivale a más trabajo entregado.
Pero cuando construyes un sistema de automatización basado en IA, esa lógica se rompe. El sistema más valioso que he construido para un cliente me llevó tres días de trabajo intenso. Una vez funcionando, procesa en minutos tareas que antes le llevaban a su equipo medio día. Si hubiera cobrado solo por esas tres días de construcción, habría dejado sobre la mesa casi todo el valor real que estaba entregando.
Lo que aprendí es que el valor no está en el tiempo que tardas en construirlo. Está en el tiempo que le ahorras al cliente cada semana, indefinidamente.
Qué significa tratar un prompt como un activo
Un prompt de tres líneas que cualquiera puede escribir no vale prácticamente nada como activo. Eso es lo primero que hay que entender para no confundirse.
Lo que sí tiene valor real es lo que hay detrás de ese prompt: el proceso iterativo para llegar a él, las pruebas con casos límite, los mecanismos para manejar errores, las instrucciones que evitan que el modelo se desvíe del objetivo en situaciones no previstas. Todo eso representa trabajo real que no es visible en el texto final del prompt, igual que el código de una aplicación no es visible para el usuario que la usa.
Cuando empecé a pensar en mis prompts y flujos como productos, el primer cambio práctico fue dejar de entregarlos directamente. En lugar de pasarle a un cliente el texto del prompt en un documento, construyo una interfaz sencilla donde el cliente introduce sus datos y recibe el output. El prompt vive detrás, invisible. El cliente obtiene el resultado que necesita sin tener acceso a la lógica que lo produce.
Esto puede sonar técnicamente complicado pero no lo es. Con herramientas como Make, n8n o incluso formularios conectados a la API de un modelo, cualquiera con ganas de aprender puede montar algo así en un fin de semana. La barrera no es técnica. Es conceptual: pasar de pensar como proveedor de servicios a pensar como creador de productos.
Los modelos que funcionan en la práctica
He probado tres formas distintas de monetizar estos sistemas y las tres tienen sus ventajas dependiendo del contexto.
La más sencilla de vender es la consultoría puntual: alguien tiene un proceso que quiere automatizar, yo lo analizo, construyo el sistema y cobro un precio fijo por entregarlo funcionando. El cliente paga una vez, tiene el sistema para siempre. Funciona bien para clientes que tienen presupuesto puntual pero no quieren compromisos recurrentes.
La más rentable a largo plazo es la suscripción mensual. El cliente no paga por el sistema en sí, paga por tener acceso a él funcionando, con mantenimiento incluido. Esto tiene sentido cuando el sistema depende de APIs que cambian, cuando los modelos se actualizan y el prompt necesita ajustes, o cuando el cliente quiere mejoras progresivas. He tenido clientes con esta modalidad durante más de ocho meses sin que el tema del precio vuelva a salir en la conversación, porque el valor que reciben cada semana es visible y concreto.
El más interesante pero también el más difícil de negociar es el modelo basado en resultados: en lugar de cobrar una tarifa fija, se negocia un porcentaje del ahorro que genera el sistema. Si el cliente estima que el sistema le ahorra diez horas de trabajo al mes a tres personas, y el coste de esas horas es cuantificable, hay margen para una conversación sobre valor compartido. Requiere confianza mutua y un contrato bien redactado, pero el upside es significativamente mayor.
Lo que más me ha costado aprender
No es la parte técnica. La parte técnica se aprende. Lo que más me ha costado es identificar qué problemas merecen ser automatizados y cuáles no.
Al principio quería automatizar todo. Con el tiempo aprendí que los mejores candidatos para la automatización son los problemas que cumplen tres condiciones simultáneamente: se repiten con frecuencia, tienen un coste real en tiempo o dinero, y tienen reglas lo suficientemente claras como para que un sistema pueda manejarlos sin necesitar criterio contextual en cada caso.
Los problemas que no cumplen esas tres condiciones, especialmente los que requieren mucho juicio situacional, siguen siendo mejores como trabajo humano directo aunque la IA pueda ayudar en partes del proceso.
Esa distinción, saber cuándo automatizar y cuándo no, es en mi experiencia lo que más valoran los clientes que han tenido experiencias previas con automatizaciones que no funcionaron. Muchos han quemado presupuesto en proyectos de automatización ambiciosos que fallaron porque intentaban resolver problemas que no eran buenos candidatos. Llegar con criterio sobre eso vale tanto como la habilidad técnica de construir el sistema.
Una reflexión final sobre hacia dónde va esto
Lo que veo en el mercado ahora mismo es que la demanda de personas que saben construir estas soluciones va por delante de la oferta. No porque no haya gente que sepa usar IA, sino porque hay muy poca gente que combine tres cosas a la vez: entender suficientemente bien los modelos para saber qué pueden y no pueden hacer de forma fiable, tener criterio de negocio para identificar dónde hay valor real, y saber estructurar eso como un producto que un cliente pueda comprar y usar.
Esa combinación es la que tiene valor en el mercado ahora mismo. Y curiosamente, ninguna de las tres partes requiere ser un experto técnico en el sentido tradicional. Requiere curiosidad, criterio y voluntad de aprender de los errores cometiendo muchos de ellos.
Yo todavía los cometo. Pero cada vez menos.
