Por qué el acceso al modelo es una unidad de valor débil
Cuando varios proveedores utilizan modelos comparables, el mero acceso a una interfaz de programación de aplicaciones (API) explica poco el precio. Un proveedor de software establecido puede incorporar una función similar, mientras el comprador cambia de modelo sin modificar la tarea subyacente. [1 · Andreessen Horowitz]
La tesis de a16z sobre los sistemas de registro refuerza este problema: la protección de un producto nuevo reside en controlar un flujo de trabajo, los datos de correcciones y un resultado que el sistema existente aún no ofrece, no en su interfaz ni en el modelo elegido. [1 · Andreessen Horowitz]
Cómo vincular el precio a los resultados
Una unidad comprensible podría ser documentos procesados correctamente, registros actualizados, reclamaciones preparadas, errores evitados u horas de trabajo verificado. Ese precio está más cerca del beneficio del comprador y obliga al proveedor a medir la finalización de tareas, no las llamadas al modelo. [1 · Andreessen Horowitz]
En la fase inicial, es más seguro trabajar en modo de recomendación y medir por separado la proporción de resultados aceptados sin correcciones. La autorización para actuar automáticamente solo debe ampliarse después de que el sistema demuestre sus límites de error y conserve la opción de revisión humana. [1 · Andreessen Horowitz]
Fuentes
- Andreessen Horowitz — The Incumbents Are Coming — 3 de septiembre de 2026
Comentario experto
Cobrar por resultados es peligroso si el cálculo omite repeticiones, revisión manual, excepciones poco frecuentes y soporte de integración. En ese caso, el uso activo hace crecer los costes más deprisa que los ingresos. Antes de lanzar una tarifa hay que medir el coste completo de un resultado satisfactorio, no el coste medio de una llamada al modelo. [1 · Andreessen Horowitz]