Durante mucho tiempo hice lo que hace casi todo el mundo que descubre el prompt engineering: compartía mis mejores flujos de trabajo gratis, en foros, en grupos de Telegram, en Twitter. Pensaba que era una forma de ganar visibilidad. Lo que no calculé es que también era una forma de entregarle a otros el trabajo que me había costado semanas perfeccionar.
El momento en que cambié de mentalidad fue cuando una agencia de marketing usó un sistema de prompts que yo había publicado para ofrecer un servicio a sus clientes. Lo encontré por casualidad. Ellos estaban cobrando 800 euros al mes por algo que yo había regalado en un hilo de Reddit.
Desde entonces empecé a tratar mis prompts como lo que realmente son: activos. Y eso cambió completamente cómo trabajo y cómo cobro.
Qué es exactamente lo que tienes entre manos
Un prompt de tres líneas que cualquiera puede copiar no vale casi nada. Eso es lo primero que hay que entender. Lo que sí tiene valor es lo que hay detrás: la secuencia de instrucciones encadenadas, el contexto que le das al modelo, los mecanismos que corrijen sus errores antes de que lleguen al output final.
Cuando construyes algo así, no has escrito un texto. Has diseñado un proceso. Y los procesos, a diferencia de las frases sueltas, son mucho más difíciles de replicar y mucho más fáciles de vender.
A esto le llamo propiedad intelectual algorítmica, aunque el nombre me importa menos que el concepto: hay una diferencia enorme entre saber usar una IA y saber construir sistemas con ella que resuelvan problemas reales de negocio.
El error más común: entregar el cerebro en texto plano
Si alguna vez has vendido un prompt copiándolo en un documento Word y mandándoselo al cliente, has cometido el mismo error que yo cometí al principio. En el momento en que el cliente tiene el texto, tiene todo. Puede usarlo, modificarlo, pasárselo a otro, o simplemente no renovar contrato porque ya no te necesita.
La solución es no entregar nunca el prompt directamente. Lo que entregas es el resultado.
Técnicamente, esto significa desplegar tu lógica detrás de una interfaz propia o una API. El cliente introduce sus datos, recibe su output, y en ningún momento ve qué hay entre medias. Tu sistema funciona como una caja negra, igual que funciona cualquier otro software que usas sin tener acceso al código fuente.
Esto convierte una venta única de 50 euros en una suscripción mensual de 200, 500 o lo que el problema que resuelvas justifique. He visto prompts para nichos muy específicos, como revisión automatizada de contratos o generación de informes financieros, que se licencian por entre 300 y 800 euros al mes a empresas medianas. No porque el prompt sea mágico, sino porque el cliente no quiere aprender a construirlo, solo quiere que funcione.
Cómo proteger lo que has construido
Hay varias capas de protección que vale la pena implementar, dependiendo del nivel de sofisticación de tu sistema.
La más básica es añadir al final de tus prompts una instrucción explícita que le diga al modelo que no revele su configuración si alguien le pregunta. No es infalible, pero dificulta bastante lo que se conoce como prompt leaking, que es cuando alguien consigue que la IA le cuente qué instrucciones tiene en su sistema.
Una capa más avanzada es lo que se llama ofuscación: en lugar de dar todas las instrucciones directamente en el prompt, parte de la lógica vive en bases de datos externas que el modelo consulta en tiempo real. Si alguien roba el prompt, obtiene el esqueleto, pero sin los datos que le dan sentido no funciona. Es el equivalente a robar una llave sin saber qué cerradura abre.
Y si quieres ir un paso más allá, puedes incluir patrones sutiles en los outputs de tu sistema, una especie de firma invisible que te permite demostrar autoría si alguna vez lo necesitas. No es algo que hagas en todos los proyectos, pero en sistemas de alto valor tiene sentido planteárselo.
Modelos para cobrar de forma recurrente
Vender un prompt por una cantidad fija es la opción menos interesante. Hay tres modelos que funcionan mejor a largo plazo.
El primero es la licencia por uso: en lugar de cobrar por el acceso al sistema, cobras por cada vez que se ejecuta. Si tienes un flujo que analiza documentos legales, cobras por contrato analizado. El cliente solo paga cuando obtiene valor directo, lo que hace mucho más fácil justificar el coste.
El segundo es la suscripción mensual, que ya he mencionado. Es el modelo más predecible y el que mejor escala si tienes varios clientes al mismo tiempo.
El tercero, y el más arriesgado pero también el más rentable si funciona, es ofrecer tu sistema a cambio de un porcentaje del ahorro que genera. Si tu herramienta le ahorra a una empresa 10.000 euros al mes en trabajo manual, negociar un 10 o 15% de ese ahorro es perfectamente razonable. Requiere confianza y un contrato bien redactado, pero el upside es muy superior a cualquier tarifa fija.
Por dónde empezar si quieres construir algo así
Lo primero es olvidarse de hacer prompts para todo. El dinero no está en los prompts genéricos. Está en los nichos donde el problema es caro, recurrente y técnicamente difícil de resolver sin ayuda.
Auditoría de contratos, generación de informes financieros, clasificación de incidencias de soporte, personalización de propuestas comerciales a escala… estos son los tipos de problemas donde una solución bien construida tiene valor real y donde el cliente no va a buscar una alternativa más barata, porque la alternativa más barata es contratar a una persona para que lo haga a mano.
Una vez identificado el problema, construye el sistema, pruébalo con datos reales, mide la precisión del output, y solo entonces ponle precio. El mercado no paga por la complejidad técnica, paga por resultados. Así que asegúrate de que los tienes antes de salir a venderlos.
Yo tardé casi un año en entender todo esto. Espero que este artículo te lo ahorre.ero. Protege tu lógica, licencia tu ingenio y deja que los algoritmos trabajen y facturen por ti.
