Hay un detalle aparentemente menor que, cuando uno empieza a escucharlo repetirse en conversaciones de producto, foros y documentación técnica, suele estar señalando un cambio de fondo: el auge de modelos «Bring Your Own Key» (BYOK), pero en un contexto distinto al habitual y conocido de las claves de cifrado en ciberseguridad: aplicaciones que te piden que pegues tu propia clave de API del proveedor de modelos de inteligencia artificial (OpenAI, Anthropic, Gemini, etc.) para que el consumo de tokens se facture directamente a tu cuenta, mientras la plataforma se limita a ofrecer interfaz, flujos de trabajo, memoria, plantillas, integraciones o agentes.
No es una rareza marginal, ni una prueba más de que en tecnología no da igual usar constantemente los mismos acrónimos para cosas diferentes: cuando actores grandes del software de productividad para desarrolladores empiezan a formalizarlo, por ejemplo JetBrains anunciando BYOK como alternativa explícita a la suscripción, es porque el patrón ya no es en absoluto anecdótico. Y si GitHub Copilot lo lleva a «public preview» en entornos como JetBrains IDEs y Xcode, con una lista de proveedores soportados, es difícil sostener que estamos ante un capricho de power users.
La idea es sencilla y, precisamente por eso, poderosa: en vez de pagar una cuota fija a una aplicación wrapper o «envoltorio» (o asumir que ese «envoltorio» revende tokens con margen y con opacidad), el usuario paga el cómputo al proveedor y el producto de capa superior compite por valor añadido real. Herramientas como TypingMind documentan de forma directa el flujo: introducir claves de proveedores y, si hace falta, añadir modelos o endpoints adicionales. En el mundo open source, LibreChat incluso contempla el modo «user_provided» para que sea el usuario quien aporte su clave, lo que convierte el BYOK en un parámetro de despliegue más, no en una excentricidad. Y, como señal de que el fenómeno se está «productizando», aparecen incluso directorios centrados en herramientas BYOK que funcionan como termómetro (imperfecto, pero útil) del número de productos que lo adoptan.
¿Cómo funciona realmente, en términos operativos? El usuario crea una clave en el proveedor del modelo, la introduce en la aplicación (en un cliente local, en una web, o en un servidor autoalojado), y la aplicación firma con esa clave las llamadas al API del proveedor. El cómputo, por tanto, se imputa a la cuenta del usuario: el proveedor ve a ese usuario como el «cliente» y factura a su método de pago. La plataforma BYOK, en ese esquema, puede cobrar una licencia única, una suscripción menor (por características, no por tokens), o incluso ser gratuita si vive de otra cosa (comunidad, servicios, consultoría, enterprise). En entornos más «serios», el patrón se extiende a pasarelas que almacenan claves de proveedores de forma centralizada para no tenerlas dispersas en aplicaciones y para poder rotarlas, revocarlas o limitar gasto. Cloudflare, por ejemplo, lo formula como BYOK dentro de su AI Gateway para «guardar» claves y operar sin exponerlas en cada petición.
Hasta aquí, suena casi inevitable: si el coste variable de la inteligencia artificial (tokens) es el componente dominante e impredecible, la tentación de «pasar el contador» al usuario es enorme. Pero precisamente por eso conviene mirar las implicaciones con lupa, porque BYOK no es solo un cambio de facturación: es un cambio de modelo de riesgo, de control y de incentivos.
La primera implicación es de seguridad básica y, paradójicamente, choca con las recomendaciones explícitas de los propios proveedores. OpenAI insiste en que no se comparta su clave y, sobre todo, en que no se despliegue en entornos cliente (navegador o móvil), porque exponerla facilita abuso y cargos inesperados. Anthropic va en la misma línea: advierte que introducir su clave en herramientas de terceros equivale, en la práctica, a dar acceso a tu cuenta al desarrollador de esa herramienta, y advierte que no lo hagas si no confías plenamente en su reputación y en su implementación. Dicho sin dramatismos, BYOK convierte la clave en una especie de tarjeta de crédito técnica, y hay productos que te piden que la pegues en un formulario web. A partir de ahí, todo depende de cuánto confíes en ese tercero, de si el almacenamiento es local o remoto, de si hay cifrado real, de si existe exfiltración posible (intencionada o por vulnerabilidad), y de si tienes límites de gasto bien configurados. El «te sale más barato» puede convertirse en «te han vaciado la cuenta» con una facilidad que muchos usuarios todavía no internalizan.
La segunda implicación es de privacidad y trazabilidad. En un esquema BYOK, la telemetría del uso se reparte: el proveedor del modelo tiene el detalle de llamadas y consumo (porque factura), la plataforma BYOK tiene el contexto de interacción (porque orquesta prompts, memoria, documentos, agentes…), y el usuario rara vez tiene una visión completa de ambos lados. JetBrains promete almacenar las claves localmente y no compartirlas con la empresa, una postura que, si se cumple, reduce superficie de riesgo y refuerza el argumento BYOK como «control» del usuario. Pero obviamente, eso no convierte mágicamente a todos los BYOK en equivalentes: algunos son clientes locales, otros son SaaS, y la diferencia es existencial. BYOK no es una garantía: es una etiqueta.
La tercera implicación es de mercado: BYOK acelera la comoditización del modelo y desplaza la competencia hacia la capa de producto. Si el usuario puede elegir proveedor y modelo a voluntad, y si el coste se ve de forma transparente en su panel del proveedor, la aplicación deja de poder esconder márgenes, cuotas implícitas o supuestos «fair uses» nebulosos. GitHub lo enmarca como flexibilidad, experimentación y control. En la práctica, también es una forma de admitir que el valor no está en «tener un modelo», sino en integrarlo bien en flujos de trabajo, en ofrecer una usabilidad superior, en construir agentes útiles y en resolver problemas concretos. Para muchas startups, eso es una buena noticia: pueden dejar de quemar caja subvencionando tokens y centrarse en producto. Para otras, es una sentencia: si tu propuesta era ser uno más de esos thin wrappers en modo «ChatGPT pero con otra interfaz», BYOK te deja sin coartada.
La cuarta implicación es de gobernanza del gasto: BYOK suena a «pago por uso» eficiente, pero el pago por uso es una trampa psicológica cuando el uso se vuelve compulsivo o cuando el producto incentiva cadenas de agentes que generan más tokens de los que el usuario cree estar consumiendo. BYOK traslada al usuario una tarea que antes asumía la plataforma: diseñar límites, alertas, claves separadas por propósito, rotación, y una disciplina mínima de higiene operacional. Los proveedores, de hecho, recomiendan separar claves y monitorizar uso precisamente para reducir el impacto de fugas o abusos. El problema, claro, es que gran parte del mercado no está acostumbrado a gestionar «contadores» de este tipo: ven una clave como un simple requisito, no como un activo crítico.
Y la quinta implicación, quizá la más interesante, es cultural: BYOK es un síntoma de que la inteligencia artificial se está pareciendo cada vez más a una utility. Cuando un recurso pasa a tener un coste medible por unidad y un acceso estandarizado por API, lo normal es que surjan intermediarios que compiten por empaquetarlo, optimizarlo, enrutarlo, gestionarlo y hacerlo utilizable. Cloudflare lo aborda desde la infraestructura y la administración de claves, JetBrains y GitHub lo hacen desde el puesto de trabajo del desarrollador, y en paralelo, el ecosistema se llena de «frontends» que viven de que el usuario pague el cómputo en otro sitio. Es difícil imaginar una señal más clara de que el valor se está desplazando: del modelo al sistema que lo gobierna, lo integra y lo domestica.
¿Es esto bueno o malo? Como casi siempre, respuesta a la gallega: depende… pero no es neutral. El BYOK puede ser una fuerza interesante contra la opacidad de precios y contra el «todo incluido» que termina castigando al usuario medio con cuotas infladas para cubrir a los heavy users. También puede ser un mecanismo de externalización de riesgos, donde plataformas livianas se desentienden de facturación, soporte por consumo, fraude y abuso, y convierten al usuario en su propio departamento de finanzas y seguridad. Y puede, sobre todo, reforzar una asimetría: quienes entienden cómo funcionan las claves, los límites y la arquitectura pueden ahorrar y ganar control, pero quienes no, se exponen.
Si el BYOK sigue extendiéndose, y las señales en herramientas de desarrollo e infraestructura apuntan a que sí, veremos dos movimientos paralelos. Por un lado, productos que se vuelven realmente valiosos porque se ganan su precio por lo que aportan, no por lo que «revenden» como simples envoltorios. Por otro, una inevitable oleada de incidentes, filtraciones y sustos de facturación que obligará a endurecer patrones de diseño: más almacenamiento local, más autoalojado, más pasarelas con límites, más «principio de mínimo privilegio» aplicado a claves, y más educación del usuario. Que los propios proveedores insistan en «no compartas tu clave» mientras el mercado empuja a los usuarios a «pegar tu clave aquí» es una tensión que no va a resolverse con marketing, sino con ingeniería y con incentivos.
Tal vez el BYOK sea solo una fase transitoria: un puente entre el modelo «suscripción plana» y un futuro donde la inteligencia artificial esté ya tan embebida, que el coste se diluya en otros servicios. O quizá sea lo contrario: la forma estable de un mercado donde el cómputo se compra como si fuera electricidad y el valor está en los aparatos, no en la red. En cualquier caso, cuando te pidan tu clave, conviene recordar qué estás entregando realmente: no una preferencia, sino una palanca directa sobre tu gasto y, en muchos casos, sobre tu dato. Y eso, en tiempos de agentes autónomos y prompts cada vez más largos, no es un detalle menor.
This article is openly available in English on Medium, «BYOK: the subtle shift that could reshape how we pay for AI»


Como desarrollador he preferido DeepSeek y herramientas que me permiten usar el api key en mi equipo. Puntualmente el editor Zed y Opencode.
Eso de suscribirme a gpt o Claude no me suena. Prefiero hacer «recargas». Así siento más control y menos apuro en usar los tokena.
Hasta ahora creo que solo DeepSeek y Kimi ofrecen este modelo así que esos son los dos que usaré para la forma BYOK.
Entonces poner api key en github o token en netlify, no es buena idea?
Hoy toca descanso…
Años 80, Billares y/o videojuegos de barrio… Para echar partidas al futbolín ibas con tus amiguetes. Para entrar a jugarponías tu moneda de cinco duros, y dejabas de jugar cuando perdías y tenías que poner otros cinco duros para volver a jugar…
¿En que momento si estas trabajando con la IA tiene que poner el empleado esa moneda de cinco duros?… Cuando ese empleado es un perdedor y trabaja en una empresa cutre salchichera.
Si nos ceñimos a un contexto de empresa ‘seria’, dudo que te vayan a pedir que metas tus BYOK personales en Intellij o en la herramienta X que uses.
La empresa puede desplegar diversas estrategias:
1. Ofrecer sus BYOKs a los empleados para su uso y disfrute, lo cuál, conociendo a este país, no me parece prudente. Si uso/abuso se podría descontrolar fácilmente ñ
2. Ofrecer sus BYOKs a los empleados, pero personalizando las, de forma que la empresa pueda hacer tracking de cuánto consume cada empleado, además de otros insights. A destacar que este esquema encaja a la perfección con el deseo de las empresas, que ya comentó Enrique hace poco, de forzar a los empleados al uso de la AI: tendrán todo un Dashboard por empleado de como, cuanto y cuando usa ese empleado las AI tools que le ha proporcionado a su trabador de forma totalmente gratuita (ya veo a RRHH metiéndolo y vendiendolo en el próximo Pack de incentivos, xd).
3. Otras?
Otras…
Se me ocurre que haya algún tercero que de forma normal estes habituado a usar, y te quite trabajo… y que la cutre empresa no te de claves, y el empleado para su propio «beneficio» (1) usar sus claves
(1) : ejemplo: trabajos rutinarios y penosos que con un tercero(MCP server?) de pago te facilite la tarea. Imaginemos una tarea que te lleva 1 hora y un LLM con vitaminas te lleva 5 minutos… asi sacas en tiempo de trabajo 55 min. para tus cosas… a cambio de unos eurillos de conexión… que la empresa no te paga
Está claro, el shadow AI siempre es una opción…para el propio empleado. Y me atrevería a decir que es la mayoritaria hoy en día, que estamos aún en los albores de la AI age.
Pero es bien sabido que no es el esquema preferido por las empresas, por la consabida confidencialidad de sus datos, que jamás desean que sean expuestos sin consentimiento expreso.
Por tanto, disfrútalo mientras puedas! :)
Estoy mas por la idea que será una fase transitoria. Las razones, se desprenden de la tercera implicación aludida: los proveedores con su modelo de subscripcion, tratarán de acabar aduaeñandose de toda la cadena de valor. Pienso que el suministro de servicios a traves de api es una forma más de luchar ahora por cuota de mercado. Quizás hasta en el futuro se integre como un nuevo plan de pago. Lo que me hace llegar a esa conclusión es que actualmente las api no entregan los modelos con todas sus funcionalidades.
Por ejemplo: tamaño de ventanas de contexto, longitud de respuestas (puede ser positivo segun el caso de uso), o menor latencia. Esto en cuanto a un usuario avanzado. Pero si estamos hablando de usuarios de menor nivel hablaríamos de restricciones del tipo «tool-calling» o sobre el acceso a determinados modelos o capacidades (generacion de imagenes).
Por descontado, el BYOK es una posibilidad seductora. De hecho, en mi caso, «recargué» un poco en las api de deepseek, claude, perplexity -y accedo a otras mediante openrouter- para testear modelos usando aplicaciones similares a librechat como anythingllm u open notebooklm. De resto, uso pequeños modelos opensource en local.
Como actualmente estoy utilizando el servicio de Lumo+ para cosas sencillas y tengo aparcados otros proyectos personales hace unos meses que apenas uso las api.
Por lo que si no estoy al día en las funcionalidades que estan etregando ahora mismo las api de los modelos se agradecería que alguien me corrigiera.
Muy de acuerdo con:
«Estoy mas por la idea que será una fase transitoria. Las razones, se desprenden de la tercera implicación aludida: los proveedores con su modelo de subscripcion, tratarán de acabar aduaeñandose de toda la cadena de valor. Pienso que el suministro de servicios a traves de api es una forma más de luchar ahora por cuota de mercado. Quizás hasta en el futuro se integre como un nuevo plan de pago. Lo que me hace llegar a esa conclusión es que actualmente las api no entregan los modelos con todas sus funcionalidades.»