{"id":32542,"date":"2026-10-22T12:57:40","date_gmt":"2026-10-22T10:57:40","guid":{"rendered":"https:\/\/www.kaspersky.es\/blog\/?p=32542"},"modified":"2026-10-21T13:13:05","modified_gmt":"2026-10-21T11:13:05","slug":"tokenomics-ai-and-cybersecurity","status":"publish","type":"post","link":"https:\/\/www.kaspersky.es\/blog\/tokenomics-ai-and-cybersecurity\/32542\/","title":{"rendered":"El impacto directo de la econom\u00eda de los tokens en los procesos de ciberseguridad"},"content":{"rendered":"

Recientemente hicimos una publicaci\u00f3n sobre la \u201ctokenom\u00eda\u201d<\/a> y los ataques de \u201cdenegaci\u00f3n de cartera\u201d: un nuevo tipo de ataque DDoS destinado a gastar en exceso tokens de IA. Pero antes de que los especialistas en seguridad empiecen a proteger los procesos de IA de sus compa\u00f1eros frente a esta nueva amenaza, deben tener en cuenta que el propio trabajo del departamento de seguridad de la informaci\u00f3n puede convertirse en objetivo de un ataque de este tipo. Dado que los equipos de seguridad est\u00e1n probando e implementando activamente diversos tipos de automatizaci\u00f3n basada en la IA, la amenaza de una interferencia externa destinada a paralizar el sistema de defensa afecta directamente a sus propios procesos y tecnolog\u00edas.<\/p>\n

Elastic ha estimado<\/a> que, seg\u00fan la arquitectura de \u201cSOC basada en agentes\u201d, clasificar una \u00fanica alerta de un host puede costar 0,69\u00a0USD para un conjunto de agentes altamente especializados o 3,42\u00a0USD para un agente de finalidad general con 14 habilidades diferentes.<\/p>\n

Sin embargo, estas medias ocultan una enorme diversidad de variaciones. En cualquier momento dado, el procesamiento b\u00e1sico de una alerta sencilla (por ejemplo, mil tokens) puede convertirse en una investigaci\u00f3n en cadena que implique el procesamiento de millones de entradas de registro, llamadas a la API y otros datos relacionados, lo que supone millones de tokens en cuesti\u00f3n de minutos<\/a>.<\/p>\n

La propia Elastic reconoce que utiliza el modelo Claude Sonnet 4.6 en su SOC. Esto plantea de inmediato la pregunta: \u00bfqu\u00e9 sucede cuando se agota el presupuesto o se activan los filtros de seguridad del modelo? En el peor de los casos, ocurre lo siguiente: el SOC de IA lanza una \u201corquesta de agentes\u201d para investigar eventos sospechosos que se asemejan a un movimiento lateral en la infraestructura. El agente llama a la API de Anthropic, pero el presupuesto mensual del departamento se ha agotado y la API devuelve errores. La investigaci\u00f3n se detiene y la gente se entera medio d\u00eda despu\u00e9s. Adem\u00e1s, si los \u201cfiltros de seguridad\u201d en constante cambio de un importante proveedor de inteligencia artificial marcan las solicitudes del SOC como maliciosas, el mismo efecto es posible incluso sin que se agote el presupuesto, como lo demuestra la experiencia de Hugging Face<\/a> al investigar la violaci\u00f3n de su infraestructura por parte de OpenAI.<\/p>\n

Por supuesto, un atacante tiene un gran inter\u00e9s en que se produzca ese resultado. Puede influir directamente en los costes de los defensores inyectando indicaciones maliciosas en los datos de los que dispone (registros TXT de DNS, encabezados HTTP, comentarios de c\u00f3digo, nombres de archivos, etc.), contando con que dichos sistemas de seguridad de la informaci\u00f3n procesar\u00e1n esas indicaciones. Por ejemplo, en el caso del ataque GhostJacking<\/a>, los registros del WAF sirven como vector para la inyecci\u00f3n r\u00e1pida, y en un estudio acad\u00e9mico, se propuso otro m\u00e9todo: los investigadores lograron atacar las propias barreras de seguridad de los LLM<\/a>, lo que provoc\u00f3 que sus solicitudes aumentaran la latencia en 148 y el n\u00famero de tokens consumidos en 63. En otras palabras, el sistema te\u00f3ricamente contin\u00faa funcionando correctamente, pero la latencia en el procesamiento de alertas y los costes asociados aumentan significativamente.<\/p>\n

Fallo silencioso peligroso<\/h2>\n

En escenarios basados en agentes, el agotamiento del presupuesto no siempre se manifiesta como un error expl\u00edcito con un mensaje de \u201cl\u00edmite de solicitud excedido\u201d y una alerta inmediata a las partes responsables. Bajo ciertas configuraciones, pueden surgir escenarios de \u201cguerrilla\u201d: una solicitud al modelo se agota, el sistema cambia autom\u00e1ticamente a un modelo m\u00e1s barato y, como resultado, la calidad de sus salidas disminuye, y los subagentes y las tareas peri\u00f3dicas dejan de ejecutarse. Mientras tanto, el equipo de seguridad puede seguir creyendo durante horas y horas que todo funciona como antes.<\/p>\n

C\u00f3mo controlar los costes de la IA en ciberseguridad<\/h2>\n

La tarea de administrar los gastos, por supuesto, no es sencillamente una cuesti\u00f3n de \u201cevitar el gasto excesivo\u201d. La industria ya ha ca\u00eddo en esta trampa al implementar SIEM: cuando las empresas ten\u00edan que pagar sobre la base del volumen de telemetr\u00eda recolectada, comenzaron a limitar de manera selectiva, y no siempre efectiva, la recolecci\u00f3n de registros. Como resultado, terminaron con puntos ciegos de detecci\u00f3n. La misma situaci\u00f3n podr\u00eda surgir con los tokens, pero m\u00e1s r\u00e1pido y a mayor escala. Una directiva de reducci\u00f3n de costes mal dise\u00f1ada podr\u00eda poner en riesgo la profundidad de las investigaciones y la calidad de las respuestas. Y en ausencia de dicha directiva, la decisi\u00f3n de cortar algo no la tomar\u00e1 el arquitecto o el CISO durante la fase de dise\u00f1o del sistema, sino el analista de turno a las 3\u00a0a.\u00a0m. O puede ser un limitador autom\u00e1tico establecido por el proveedor del sistema.<\/p>\n

Algunos principios sencillos pueden ayudar a evitar sobrecostes predecibles y administrar mejor las situaciones que son realmente impredecibles.<\/p>\n

No alimentes el modelo de IA con nada que se pueda verificar con una consulta est\u00e1ndar. <\/strong>Todo lo que es repetitivo y conocido de antemano debe manejarse a la antigua, con reglas y consultas de datos. Estos se pueden desarrollar mediante IA, pero deben funcionar de forma determinista. El modelo solo debe usarse cuando realmente se necesite una evaluaci\u00f3n de una situaci\u00f3n ambigua.<\/p>\n

Usa l\u00edmites estrictos y alerta de forma contundente a los usuarios cuando se excedan. <\/strong>Los l\u00edmites deben combinarse: un l\u00edmite por tarea, un l\u00edmite diario, etc. Las alertas sobre superaciones de los l\u00edmites deben llegar inmediatamente tanto a los analistas de servicio como a los responsables del sistema en su conjunto.<\/p>\n

Decide de antemano qu\u00e9 sucede cuando se alcanza un l\u00edmite. <\/strong>Decidir si detenerse y ahorrar dinero, aunque se pierda cierto control, o continuar y pagar es una decisi\u00f3n que debe tomarse antes de que ocurra un incidente.<\/p>\n

Limita los permisos de los agentes y el conjunto de herramientas disponibles para ellos. <\/strong>Cuantas menos acciones tenga disponibles el sistema, m\u00e1s eficazmente realizar\u00e1 una tarea espec\u00edfica, menos oportunidades tendr\u00e1 de incrementar los costes y menor ser\u00e1 la probabilidad de que un tercero se aproveche de ti.<\/p>\n

Analiza estrictamente los datos externos que no sean de confianza. <\/strong>Las solicitudes, las consultas, los mensajes y los comentarios entrantes, as\u00ed como varios campos t\u00e9cnicos que pueden contener texto arbitrario (registros DNS, encabezados HTTP, nombres de archivo) no solo pueden conducir a la inyecci\u00f3n r\u00e1pida, sino tambi\u00e9n inflar deliberadamente la carga de trabajo. Limita su tama\u00f1o y supervisa la carga que generan.<\/p>\n

Para evitar interrupciones del servicio de proveedores externos y mantener un control total sobre los datos de tu organizaci\u00f3n, eval\u00faa la posibilidad de usar modelos locales implementados en las instalaciones<\/strong> al menos para las necesidades de seguridad de la informaci\u00f3n. Si bien estos modelos pueden no ser de \u00faltima generaci\u00f3n, su estrecha especializaci\u00f3n y su ajuste con los datos de la empresa brindar\u00e1n un rendimiento decente sin fallos inesperados.<\/p>\n

En una arquitectura m\u00e1s compleja, el uso de LLM se puede dividir en varios niveles<\/strong>. La primera l\u00ednea de defensa (enrutamiento, filtrado de ruido, enriquecimiento de datos) la gestionan modelos compactos locales. Esto reduce significativamente la volatilidad del presupuesto. El segundo nivel consiste en un gran modelo local que maneja el trabajo sustantivo: vincular eventos, probar hip\u00f3tesis y reconstruir la imagen de un incidente. Tampoco se factura por solicitud, pero su rendimiento es limitado; por lo tanto, en lugar de sobrecostes del presupuesto, pueden producirse sobrecargas y colas de eventos. Solo los casos aislados y verdaderamente dif\u00edciles se env\u00edan a modelos avanzados basados en la nube, preferiblemente con la aprobaci\u00f3n expl\u00edcita de un analista humano. En este esquema, los costes variables permanecen, pero se limitan a una peque\u00f1a cantidad de casos, y cada uno representa una elecci\u00f3n consciente en lugar de un efecto secundario de un script que se ejecuta de la noche a la ma\u00f1ana.<\/p>\n

B\u00e1sicamente, todo esto reproduce el modelo SOC cl\u00e1sico de varios niveles, donde la primera l\u00ednea filtra y la tercera l\u00ednea investiga, pero los modelos desempe\u00f1an las funciones en lugar de las personas.<\/p>\n\n","protected":false},"excerpt":{"rendered":"

Examinamos el impacto de la dependencia de la IA en la ciberseguridad de una organizaci\u00f3n. <\/p>\n","protected":false},"author":2722,"featured_media":32543,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[2202,2754],"tags":[378,323,1307,3681,2383,2761,3791,612],"class_list":["post-32542","post","type-post","status-publish","format-standard","has-post-thumbnail","category-business","category-enterprise","tag-amenazas","tag-consejos","tag-ia","tag-ml","tag-presupuesto","tag-soc","tag-soc-autonomo","tag-tecnologia"],"hreflang":[{"hreflang":"es","url":"https:\/\/www.kaspersky.es\/blog\/tokenomics-ai-and-cybersecurity\/32542\/"},{"hreflang":"en-in","url":"https:\/\/www.kaspersky.co.in\/blog\/tokenomics-ai-and-cybersecurity\/31131\/"},{"hreflang":"en-ae","url":"https:\/\/me-en.kaspersky.com\/blog\/tokenomics-ai-and-cybersecurity\/26165\/"},{"hreflang":"en-gb","url":"https:\/\/www.kaspersky.co.uk\/blog\/tokenomics-ai-and-cybersecurity\/30971\/"},{"hreflang":"it","url":"https:\/\/www.kaspersky.it\/blog\/tokenomics-ai-and-cybersecurity\/31073\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/tokenomics-ai-and-cybersecurity\/42810\/"},{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/tokenomics-ai-and-cybersecurity\/56523\/"},{"hreflang":"ru-kz","url":"https:\/\/blog.kaspersky.kz\/tokenomics-ai-and-cybersecurity\/31135\/"},{"hreflang":"en-au","url":"https:\/\/www.kaspersky.com.au\/blog\/tokenomics-ai-and-cybersecurity\/36876\/"},{"hreflang":"en-za","url":"https:\/\/www.kaspersky.co.za\/blog\/tokenomics-ai-and-cybersecurity\/36545\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/www.kaspersky.es\/blog\/tag\/ia\/","name":"IA"},"_links":{"self":[{"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/posts\/32542","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/users\/2722"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/comments?post=32542"}],"version-history":[{"count":2,"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/posts\/32542\/revisions"}],"predecessor-version":[{"id":32545,"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/posts\/32542\/revisions\/32545"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/media\/32543"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/media?parent=32542"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/categories?post=32542"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/tags?post=32542"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}