Producir software y contenido cuesta menos. Eso obliga a revisar qué vendemos, cómo lo cobramos y qué parte de nuestra ventaja seguirá en pie cuando otros tengan las mismas herramientas.
Hay una pregunta que puede estropear una presentación de empresa: «¿Cuánto costaría construir hoy lo que ya tenéis?».
Durante años, explicar lo que había costado levantar una plataforma servía para defender su valor. Años de desarrollo, un equipo especializado, integraciones, un catálogo de funcionalidades. Todo aquello transmitía esfuerzo acumulado y una distancia difícil de recortar para quien llegara después.
La IA obliga a rehacer esa cuenta.
El código sigue importando, y también las personas capaces de entenderlo, mantenerlo y decidir qué merece la pena construir. Pero cuando una parte del trabajo se puede reproducir con menos tiempo y dinero, el esfuerzo invertido cambia de naturaleza. Deja de ser un foso. Pasa a ser un coste hundido: explica cómo has llegado hasta aquí, no por qué alguien debería seguir contigo.
Me lo pregunto desde cuatro sitios bastante distintos —Foxize, DevsHealth, UXMachine y RosmarOps—, donde conviven empresas con recorrido y proyectos que todavía tienen que demostrar su mercado. Son míos, con el sesgo que eso implica, y precisamente por eso me sirven: la IA toca una parte diferente del negocio en cada uno y no puedo mirarlo desde la grada.
La pregunta común es incómoda: si producir se abarata, ¿qué estamos en condiciones de seguir cobrando?
Cobrar por resultados con IA: quién se queda con el ahorro
Cuando una tecnología reduce costes, alguien se queda con la diferencia. Puede hacerlo el proveedor, mejorando su margen; el cliente, exigiendo un precio menor; un competidor nuevo, entrando con una oferta que antes no podía sostener; o la plataforma tecnológica de la que todos dependen. Ese reparto no está escrito en ninguna parte.
Si entregas el mismo proyecto en menos tiempo y mantienes un precio cerrado, puedes ganar más. Si facturas horas, tus ingresos pueden caer. Si vendes una suscripción, tendrás que mirar cómo cambian el uso, el coste de atenderlo y las razones para renovar.
Por eso me parece precipitado anunciar que la IA acaba con las licencias o que todo se cobrará por resultados. Hay tareas donde tiene sentido. En otras, definir el resultado y atribuírselo a un proveedor puede ser más complicado que prestar el servicio.
Quien quiera cobrar por resultados tiene que decidir antes qué cuenta como resultado, y esa definición no es letra pequeña. Es parte del producto: decide qué se factura, qué acepta pagar el cliente y qué riesgo asume cada uno cuando el resultado depende también de cómo trabaja el otro.
La conversación interesante empieza ahí. No va de licencia contra resultado. Va de qué unidad de valor puedes vender, cómo se comprueba y cuánto cuesta entregarla de forma consistente.
Formación corporativa con IA: el tamaño del catálogo ya no justifica el precio
En formación corporativa, la abundancia de contenido era un problema antes de la IA. Ahora producir una explicación, adaptar un material o preparar ejercicios resulta mucho más accesible, y eso presiona a cualquier propuesta cuyo argumento principal sea el tamaño del catálogo.
En Foxize trabajamos con plataforma, formación, diagnóstico y análisis del aprendizaje. Nuestro LMS se vende con un precio fijo y rangos de uso amplios, así que la reflexión no empieza en la tarifa: empieza en lo que realmente vendemos y en lo que el cliente consigue usar.
Un empleado puede encontrar una respuesta en un asistente y ahorrarse un curso. También puede recibir una respuesta correcta sin haber adquirido la capacidad de resolver el siguiente problema. Para quien paga la formación, distinguir ambas situaciones debería importar bastante.
De ahí salen preguntas concretas para productos como IAutor y MyTutor. ¿Cuánto trabajo de creación y actualización de materiales podemos ahorrar? ¿Qué ayuda necesita una persona para avanzar? ¿Cómo sabemos si puede aplicar lo aprendido? ¿Qué tareas administrativas siguen comiéndose el tiempo del equipo de formación?
Cada pregunta lleva a una propuesta comercial distinta, porque crear materiales, acompañar al alumno y gestionar el aprendizaje tienen costes y beneficios diferentes. Meterlo todo en una casilla llamada «IA incluida» hace difícil explicar el precio y todavía más difícil saber si sale a cuenta.
Tampoco me convence resolverlo con una «garantía de transformación». Podemos medir un punto de partida, acordar una evaluación y observar avances, pero la aplicación en el trabajo depende también del responsable, del tiempo disponible y de cómo está organizada la empresa. Cobrar por resultados exige hacerse cargo solo de lo que podemos demostrar. Lo que necesita revisión no es el modelo de precio en sí, sino la relación entre la factura y la utilidad que el cliente reconoce.
IA en el descubrimiento de fármacos: más candidatos no es mejor investigación
En DevsHealth el contexto es otro: usamos IA, datos y modelado molecular para desarrollar candidatos a medicamentos contra enfermedades infecciosas.
Aquí conviene desconfiar de las analogías del software. Entre proponer una molécula y disponer de un medicamento útil hay un recorrido experimental enorme. Una predicción prometedora tiene que enfrentarse a pruebas, resultados adversos y decisiones de continuar o abandonar.
Poder explorar más candidatos es valioso. También puede generar más trabajo de validación si la selección es mala. El número de propuestas que produce un sistema dice muy poco, por sí solo, sobre la calidad del proceso.
Desde la dirección, la pregunta es dónde poner el siguiente euro para reducir una incertidumbre relevante: mejorar un modelo, conseguir mejores datos o ejecutar un experimento. La respuesta depende de lo que todavía necesitamos saber para decidir.
La ventaja que me interesa construir está en la relación entre predicción y evidencia: qué resultados permiten mejorar la selección, qué conocimiento acumulamos, qué activos podemos desarrollar y proteger. Tener acceso al mismo modelo que otros no impide diferenciarse. Obliga a explicar con precisión dónde ocurre esa diferencia.
Y ahí el equipo pesa más que antes, no menos. Hace falta gente capaz de detectar una mala hipótesis, diseñar una prueba útil e interpretar un resultado que contradice lo esperado. Una estructura pequeña solo es una ventaja si conserva ese oficio.
Software construido con agentes de IA: producir se abarata, comprobar no
Con UXMachine vivo el abaratamiento de la producción de forma muy directa, porque lo construyo con agentes de IA. Ya he contado cómo organizo los roles, la memoria y los controles.
Puedo pedir una funcionalidad y verla aparecer con una rapidez que hace poco me habría parecido absurda. Después tengo que entender qué se ha hecho, comprobarlo y decidir si debía existir. Lo primero dura minutos. Lo segundo, no.
UXMachine abre una web en un navegador real y realiza comprobaciones definidas. Devuelve observaciones con evidencia y límites, y no usa un modelo de lenguaje para decidir el diagnóstico. Su posible valor económico está en facilitar una comprobación que alguien necesita dentro de su trabajo. Si los agentes permiten cambiar una web más a menudo, cabe esperar que crezca la necesidad de revisar esos cambios.
Pero esa relación es una hipótesis de negocio, no un hecho. Todavía hay que demostrar quién necesita medir, con qué frecuencia y por qué pagaría. La calidad del instrumento es necesaria; también lo son la facilidad de uso, el encaje en el proceso de trabajo y la utilidad de volver a medir. No puedo atribuirle una mejora de ventas que no he comprobado. Puedo explicar qué observa y qué deja fuera, y buscar una forma de cobrar coherente con ese alcance.
Además, el mismo acceso a la IA que me permite construir facilita que otros lo intenten. La velocidad de desarrollo me ayuda a entrar. Quedarse es otra cosa: el producto tiene que ganarse un sitio en el trabajo habitual de alguien.
Permisos de los agentes de IA: delegar barato también es delegar a ciegas
RosmarOps nace de otra cara del trabajo con agentes: entender qué pueden alcanzar en el ordenador donde los usas.
Hoy es una herramienta local que lee la configuración de los agentes y muestra, entre otras cosas, qué credenciales podrían leer, qué permisos tienen y si pueden modificar la configuración de otros agentes. Lee sin cambiar nada y sin enviar datos fuera.
Ese alcance tiene límites importantes. Examinar una configuración permite identificar determinadas exposiciones; saber qué hizo realmente un agente exigiría observar su ejecución. Y un informe deja pendientes la decisión y el cambio. La promesa tiene que corresponderse con lo que la herramienta permite conocer.
Lo que me interesa aquí conecta con todo lo anterior. Cuanto más barato es delegar, más fácil es perder de vista qué se ha delegado: qué se puede leer, qué se puede ejecutar, quién decide cuando aparece una petición de permiso. Esa visión se dispersa entre herramientas, archivos y opciones de configuración.
Mi hipótesis es que hacerla visible puede ser útil. Queda por probar cómo se convierte en negocio: quién siente el problema, cuándo necesita revisarlo y si una revisión periódica aporta lo suficiente para volver. Construir un informe convincente es la parte fácil. La prueba comercial empieza cuando alguien dedica tiempo o dinero a actuar sobre él.
Coste de desarrollo y coste de inferencia: dos cuentas distintas
Aquí se mezclan dos cosas con demasiada frecuencia. Usar IA para programar puede abaratar el desarrollo de un producto. Que ese producto ejecute modelos cada vez que alguien lo usa es otra decisión, y UXMachine y una herramienta local como RosmarOps ayudan a ver la diferencia.
Cuando hay inferencia en cada uso, aparece un coste variable que conviene conocer. Tampoco tiene sentido dar por hecho que arruinará el margen. El AI Index 2025 de Stanford documentó una reducción de más de 280 veces en el coste de inferencia para un rendimiento equivalente al de GPT-3.5 entre noviembre de 2022 y octubre de 2024.
Ese dato corresponde a una capacidad y a un periodo concretos. El gasto real de un producto depende de cuánto se usa, qué modelos necesita, cuántos intentos hace y cuánto trabajo humano exige verificar o corregir sus respuestas. Una operación aparentemente barata puede requerir revisiones costosas; otra puede ahorrar muchas horas con un consumo pequeño.
Y queda la dependencia. Cambiar de proveedor puede obligar a repetir evaluaciones, ajustar comportamientos y revisar compromisos con clientes. Ese coste existe aunque todavía no aparezca en ninguna factura. La dirección debería conocer el margen de los usos habituales y qué lo deteriora, porque el promedio suele esconder clientes o tareas que consumen mucho más de lo previsto.
Equipos pequeños y datos propios no garantizan una ventaja competitiva
Me preocupa que sustituyamos una medida de vanidad por otra. Antes presumíamos del tamaño del equipo. Ahora podemos presumir de cuántas personas hemos conseguido no contratar. Ninguna de las dos cifras dice gran cosa sobre la calidad de una empresa.
Un equipo pequeño puede ser muy eficaz. También puede depender de una sola persona que concentra conocimiento, decisiones, ventas y soporte. Un equipo mayor puede aportar una capacidad difícil de reemplazar. Lo que hay que mirar es qué sabe hacer y qué entrega.
Con los datos pasa algo parecido. Tener una base histórica no crea automáticamente una ventaja: importa que sean pertinentes, que podamos usarlos para ese fin y que permitan obtener algo que otros no consiguen con facilidad.
En mis cuatro contextos, las ventajas posibles son distintas: conocer cómo aprende una organización, acumular evidencia experimental, ofrecer mediciones fiables dentro de un proceso de desarrollo, hacer comprensibles permisos que estaban dispersos. Y sin embargo comparten algo. Ninguna consiste en producir más. Todas consisten en saber qué merece producirse y en poder demostrarlo. En cada caso queda trabajo para probar qué valor tiene eso y para quién.
El ahorro de producción obliga a ser más exigente con las decisiones de inversión, y no por austeridad. Añadir funciones resulta más fácil que hablar con un cliente que no vuelve. Construir una integración es más cómodo que revisar una tarifa. Generar otro informe evita preguntar si alguien hizo algo con el anterior.
Lo sé porque, construyendo con IA, es muy fácil terminar el día con muchas cosas nuevas y la misma incertidumbre comercial de la mañana.
Por eso, antes de ampliar el equipo, añadir otro agente o encargar la siguiente funcionalidad, quiero poder responder una pregunta: si mañana un competidor pudiera reproducir buena parte de lo que hemos construido, ¿por qué seguiría eligiéndonos un cliente?
Que nos costara mucho construirlo ya no es una respuesta.
