Robar una clave de IA: cuatro eslabones y un contador ajeno

En breve: El LLMjacking utiliza credenciales robadas para cargar consumo de IA a una cuenta ajena. El artículo analiza acceso, consumo, reventa y compra consciente en España y Noruega: cada conducta exige probar sus requisitos, y los encajes propuestos para el consumo son interpretaciones del autor.

Imagina una gestoría de cinco personas en Valladolid. Clara la lleva y ha montado una herramienta que usa un modelo de IA para preparar primeros borradores de cartas. Le cuesta unos 60 euros al mes. Ahorra tiempo y ella revisa el resultado.

Su programa habla con el modelo por una API: una puerta por la que envía lo que necesita y recibe la respuesta. La clave de API es lo que presenta al entrar para decir: «Soy yo, cárgamelo a mi cuenta». Cada petición se cuenta en tokens, pequeñas unidades de texto, y se factura a fin de mes.

Un viernes, Clara sube por error el código de su herramienta a un repositorio público con la clave dentro. Alguien la encuentra, comprueba que funciona y empieza a usarla. Después revende el acceso: otros le pagan para enviar peticiones a través de él. Algunos saben que están consumiendo a cargo de una cuenta ajena.

De madrugada, mientras la gestoría está cerrada, las peticiones se multiplican. Por la mañana, Clara abre una alerta: lleva 1.480 euros de gasto. Nadie en su oficina ha trabajado esa noche. Llama al proveedor. Le dicen que las peticiones se han hecho con su clave y que la cuenta es suya. Clara anula la clave y reclama el cobro.

El 30 de octubre de 2026, Wiz publicó un análisis sobre incidentes en nueve plataformas de desarrollo de IA.[1] Al analizar dos claves empresariales, registró unas 800.000 llamadas en 30 horas con una y 1,7 millones en 13 horas con la otra, incluidos intentos fallidos.[1] Estimó más de 100.000 dólares de consumo combinado a tarifa pública, sin factura acreditada.[1]

En la gestoría de Clara, el contador ha seguido girando a su nombre. El LLMjacking consiste en aprovechar credenciales robadas para cargar el consumo de IA a otra cuenta.[2] Quiero seguir la cadena desde ahí: entrar, engancharse al contador, vender el suministro y comprar sabiendo de dónde viene. Cada eslabón plantea una responsabilidad distinta.

Trabajo en las jurisdicciones española y noruega, así que centro el análisis en esos dos países.

Cuatro eslabones, cuatro preguntas penales

1. Entrar en la propiedad: obtener la clave y acceder al sistema ajeno.
2. Conectar el cable al contador: consumir cómputo con cargo al titular.
3. Vender el servicio: convertir el acceso robado en un negocio.
4. Comprar sabiendo: utilizar el suministro conociendo su origen ilícito.

Cada eslabón exige probar los requisitos del delito y resolver cómo se relaciona con los demás.

1. Entrar en la propiedad

España. El artículo 197 bis.1 castiga acceder sin autorización vulnerando medidas de seguridad o permanecer contra la voluntad del legitimado. El 197 ter alcanza la obtención de contraseñas o códigos, sin autorización y con intención de facilitar los delitos que enumera.[3]

La STS 849/2025, recogiendo la doctrina de la STS 15/2023, trata la clave de acceso como identificador de su titular. La primera resolvía sobre intimidad y acceso a información personal bajo el artículo 197.2.[4] Me sirve para explicar qué se usurpa al utilizar una credencial ajena: la identificación virtual que permite abrir la puerta.

Noruega. El § 201 comprende obtener o poseer datos de acceso con intención delictiva; el § 204, entrar mediante ruptura de protección u otro procedimiento ilegítimo.[5]

La HR-2026-1908-A aplicó ambos a contraseñas de Snapchat obtenidas de una base de filtraciones. La HR-2024-999-A hizo lo propio con credenciales filtradas y accesos a Facebook.[6][7] Eran cuentas personales: trasladar ese razonamiento a una clave de API es mi lectura. La puerta cambia; la credencial sigue permitiendo entrar en un sistema ajeno.

2. Conectar el cable al contador

Entrar permite consumir. Aquí empieza el perjuicio que puede seguir creciendo mientras nadie mira la cuenta.

España. El artículo 255 castiga defraudar utilizando «telecomunicaciones u otro elemento, energía o fluido ajenos», entre otros suministros, mediante mecanismos fraudulentos, alteración de contadores o «cualesquiera otros medios clandestinos».[3]

Yo defendería que esa fórmula permite discutir el consumo clandestino de cómputo ajeno. El enganche describe bien a quien utiliza el suministro y deja el coste al titular. No hemos encontrado una sentencia que aplique el 255 a IA o servicios en la nube.

La alternativa es la estafa informática del artículo 249.1.a. La STS 509/2018 consideró manipulación informática identificarse ante un cajero con el número secreto de otro, incluso obtenido sin delinquir; aplicaba el antiguo 248.2.a.[3][8]

Para un consumo clandestino de suministro, mi punto de partida sería el 255. Cuando se acredita una operación lucrativa que provoca transferencias patrimoniales no consentidas, defendería el 249.1.a. La diferencia importa: el primero prevé multa; la estafa informática, prisión. Una factura elevada obliga a investigar esos elementos, sin sustituir su prueba.[3]

Noruega. El § 12 equipara la energía eléctrica u otra energía a una cosa: por eso robar luz puede ser tyveri, hurto. Esa equiparación no comprende el servicio de cómputo.[9]

Buscaría el encaje en el § 371 b: beneficio indebido, influencia ilegítima sobre el resultado de un tratamiento automatizado y pérdida o peligro de pérdida. El § 372 permite examinar el fraude grave, atendiendo, entre otros factores, al daño económico y al carácter sistemático u organizado.[10] Mi argumento es que la clave hace que el sistema procese y atribuya a otro un consumo que este no autorizó.

3. Vender el servicio

Sysdig describió en mayo de 2024 un proxy inverso para comercializar acceso a modelos mediante credenciales robadas. El comprador envía peticiones al intermediario; este utiliza la cuenta comprometida sin mostrarle la clave.[2]

Wiz también vio indicios de reventa al analizar dos claves empresariales vinculadas a un proveedor comprometido no identificado, sin vínculo definitivo entre revendedores, compromiso y tráfico.[1]

España. El 197 ter contempla facilitar a terceros contraseñas o códigos con la finalidad delictiva exigida.[3] Vender una clave plantea directamente esa cuestión. En un proxy que la oculta al comprador, hay que examinar qué se facilita y cómo participa el vendedor en el fraude de consumo descrito en el segundo eslabón.

Noruega. El § 201 incluye poner datos de acceso a disposición de otra persona. Para la explotación fraudulenta del servicio, volvería al § 371 b y, si concurren los elementos de gravedad, al § 372.[5][10]

Para mí, este es el eslabón más grave: aquí está el negocio. El revendedor cobra por algo cuyo coste desvía a una cuenta ajena y convierte un acceso comprometido en una oferta para más consumidores. El contador de la víctima sostiene la mercancía que vende.

4. El comprador que sabe que es robado

Pagar al intermediario no autoriza a cargar el consumo al titular. También quiero mirar a quien compra sabiendo cómo funciona el enganche.

España. Las Audiencias de Guadalajara y Cuenca recuerdan, sobre el artículo 255, que «basta con que el autor sepa que el suministro está siendo obtenido de forma ilícita y siga consumiendo». No hace falta haber instalado el enganche.[11][12]

Si se admite mi encaje del cómputo en ese artículo, defendería que alcanza al comprador consciente del origen ilícito. Su papel consiste en aprovechar el suministro, aunque otro haya conectado el cable.

Noruega. El § 332, heleri, exige recibir u obtener para sí o para otros una parte del producto del delito; comprende también un servicio que lo sustituya.[13] La HR-2024-999-A anuló una condena por este precepto porque la mera conservación no basta: hay que recibir u obtener.[7]

Mi razonamiento es que el comprador recibe un servicio cada vez que encarga y obtiene procesamiento a través del intermediario. Eso permite plantear el § 332 para quien conoce el origen delictivo; el encaje del servicio como producto o sustituto es la inferencia que propongo.

¿Y la UE?

No hay un delito ni un tribunal penal europeo común para esto. El Derecho penal es nacional; la UE fija mínimos.

La Directiva 2013/40/UE cubre los eslabones 1 y 3: acceso infringiendo una medida de seguridad (art. 3) y venta o puesta a disposición de contraseñas o códigos con intención de facilitar los delitos de los arts. 3–6 (art. 7.b).[14] Su art. 12 exige jurisdicción si el delito ocurre total o parcialmente en el territorio o ataca un sistema situado en él, aunque el autor esté fuera: que roben la clave de Clara desde fuera no impide denunciar en España, sin garantizar el resultado.[14]

El art. 6 de la Directiva 2019/713 aborda el eslabón 2: fraude mediante sistemas de información que causa una transferencia de dinero, valor monetario o moneda virtual; exige una pena máxima de al menos tres años (art. 9.4).[15] Considerar el consumo de cómputo «valor monetario» es mi interpretación.

No he encontrado sentencias del TJUE que interpreten la Directiva 2013/40 sobre credenciales.

Estas directivas no obligan a Noruega: no forman parte del Acuerdo EEE. Lo común con España es el Convenio de Budapest, ratificado por Noruega en 2006: acceso ilegítimo (art. 2), dispositivos y contraseñas (art. 6) y fraude informático (art. 8).[16]

Storm-2139: una cadena real alegada

Microsoft atribuyó a Storm-2139 obtención de credenciales expuestas, acceso ilegítimo y venta de herramientas o acceso. Su relato permite ver la cadena como una actividad organizada, llevada a un litigio civil.[17]

El 26 de mayo de 2026, el magistrado Fitzpatrick recomendó sentencia en rebeldía y medidas inhibitorias permanentes contra tres demandados. El documento es una recomendación, no el fallo final, y Microsoft pedía entonces frenar la actividad, sin indemnización dineraria.[18] El expediente da cuerpo al ejemplo; no acredita que cada comprador conociera el origen del acceso.

Ser víctima no borra la factura

AWS atribuye al cliente la actividad de su cuenta, incluso la no autorizada, salvo en la medida causada por un incumplimiento de AWS. OpenAI responsabiliza al cliente de la actividad de la cuenta; Anthropic le atribuye las tarifas generadas por ella.[19][20][21]

Microsoft contempla en el canal CSP un crédito discrecional y único por fraude, sujeto a condiciones; no es una devolución general de Azure.[22]

Clara puede denunciar que alguien utilizó su clave y encontrarse a la vez discutiendo esos 1.480 euros con el proveedor. El titular puede ser víctima del delito y seguir debiendo el consumo. Yo prepararía la denuncia y la discusión del cobro desde el principio: contrato aplicable, registros y pruebas del compromiso. El contador puede seguir siendo tuyo mientras investigas quién conectó el cable.

Para discutir esa factura, pediría separar el consumo habitual de las peticiones ajenas y reconstruir cuándo empezó el enganche. Es la misma pregunta que haría ante un contador que gira demasiado deprisa: quién está utilizando el suministro que me cobran.

Vigila tu contador

Antes de conectar una aplicación, preguntaría: «Cuando lleguemos al límite, ¿qué se corta y cuándo?».

• Comprueba el corte. Azure Budgets avisa y no detiene el consumo; AWS Budgets actualiza hasta tres veces al día. OpenAI documenta un límite estricto de aplicación no instantánea; Anthropic pausa la API al alcanzar el tope monetario del nivel.[23][24][25][26]
• Reduce el alcance de cada clave. Permisos mínimos, separación por aplicación y entorno, y secretos fuera del código.[27][28]
• Actúa ante una sospecha. Revoca la clave y revisa accesos y registros.[29]

Quiero que Clara pueda reconstruir la cadena completa: quién abrió la puerta, quién conectó el cable, quién vendió el suministro y quién lo compró sabiendo de dónde venía. Que su clave aparezca en los registros es el principio de la investigación.

Cuatro eslabones. Un contador ajeno. El negocio cobra; el titular recibe la factura.