{"id":29565,"date":"2026-10-22T16:14:48","date_gmt":"2026-10-22T22:14:48","guid":{"rendered":"https:\/\/latam.kaspersky.com\/blog\/?p=29565"},"modified":"2026-10-22T16:14:48","modified_gmt":"2026-10-22T22:14:48","slug":"tokenomics-ai-and-cybersecurity","status":"publish","type":"post","link":"https:\/\/latam.kaspersky.com\/blog\/tokenomics-ai-and-cybersecurity\/29565\/","title":{"rendered":"El impacto directo de la “tokenom\u00eda” 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 monedero\u201d, un nuevo tipo de ataque DDoS destinado a gastar tokens de IA en exceso. Pero antes de que los especialistas en seguridad comiencen a proteger los procesos de IA de sus colegas ante esta nueva amenaza, deben recordar que el trabajo del propio departamento de seguridad de la informaci\u00f3n puede convertirse en el objetivo de un ataque de este tipo. Dado que los equipos de seguridad ahora est\u00e1n probando e implementando activamente varios tipos de automatizaci\u00f3n basada en IA, la amenaza de interferencia externa destinada a paralizar el sistema de defensa afecta directamente sus propios procesos y tecnolog\u00edas.<\/p>\n

Elastic estim\u00f3<\/a> que, dependiendo de la arquitectura de \u201cSOC basado en agentes\u201d, la clasificaci\u00f3n de una sola alerta desde un host puede costar $0.69 para un conjunto de agentes altamente especializados o $3.42 para un agente de uso general con 14 habilidades diferentes.<\/p>\n

Sin embargo, estos promedios enmascaran un amplio rango de variaci\u00f3n. En cualquier momento, el procesamiento b\u00e1sico de una alerta simple (digamos, mil tokens) puede convertirse en una investigaci\u00f3n en cascada que implica el procesamiento de millones de entradas de registro, llamadas a la API y otros datos relacionados, lo que equivale a millones de tokens en cuesti\u00f3n de minutos<\/a><\/p>\n

El propio Elastic reconoce que utiliza el modelo Claude Sonnet 4.6 en su SOC. Esto plantea inmediatamente 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: SOC con 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 agot\u00f3 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 IA 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 OpenAI.<\/p>\n

Por supuesto, un atacante tiene un inter\u00e9s creado en tal resultado. Pueden influir directamente en los costos de los defensores al inyectar indicaciones maliciosas en los datos disponibles para ellos (registros TXT de DNS, encabezados HTTP, comentarios de c\u00f3digo, nombres de archivo, etc.), con la certeza de que estas indicaciones ser\u00e1n procesadas por los sistemas de seguridad de la informaci\u00f3n. Por ejemplo, en el caso del ataque GhostJacking<\/a>, los registros de 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 barreras de seguridad de LLM <\/a>mismos<\/a>, lo que hace que sus solicitudes aumenten la latencia en 148 y la cantidad 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 costos asociados aumentan significativamente.<\/p>\n

Error 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 solicitudes excedido\u201d y una alerta inmediata a las partes responsables. Bajo ciertas configuraciones, pueden surgir escenarios de \u201cguerrilla\u201d: una solicitud al modelo agota el tiempo de espera, el sistema cambia autom\u00e1ticamente a un modelo m\u00e1s econ\u00f3mico y, como resultado, la calidad de sus resultados 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

\u00bfC\u00f3mo controlar los costos de la IA en la ciberseguridad?<\/h2>\n

La tarea de administrar los gastos, por supuesto, no es simplemente una cuesti\u00f3n de \u201cevitar gastos excesivos\u201d. La industria ya cay\u00f3 en esta trampa al implementar SIEM: cuando las empresas ten\u00edan que pagar en funci\u00f3n del volumen de telemetr\u00eda recopilada, comenzaron a limitar selectivamente, y no siempre de manera efectiva, la recopilaci\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 costos 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 eliminar algo no ser\u00e1 tomada por el arquitecto o el CISO durante la fase de dise\u00f1o del sistema, sino por 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 simples pueden ayudar a evitar sobrecostos predecibles y administrar mejor situaciones que son realmente impredecibles.<\/p>\n

No proporcione al modelo de IA nada que se pueda verificar con una consulta est\u00e1ndar. <\/strong>Todo lo que sea repetitivo y conocido de antemano debe manejarse a la antigua usanza: con reglas y consultas de datos. Estos pueden desarrollarse utilizando IA, pero deben operar de manera determinista. El modelo solo debe usarse cuando realmente se necesita una evaluaci\u00f3n de una situaci\u00f3n ambigua.<\/p>\n

Use l\u00edmites estrictos y avise 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 l\u00edmites deben llegar de inmediato tanto a los analistas de turno como a los responsables del sistema en su conjunto.<\/p>\n

Decida 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

Limite 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 costos y menor ser\u00e1 la probabilidad de que un tercero se aproveche de usted.<\/p>\n

Analice 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. Limite su tama\u00f1o y controle la carga que generan.<\/p>\n

Para evitar interrupciones del servicio de proveedores externos y mantener el control total sobre los datos de su organizaci\u00f3n, eval\u00fae la posibilidad de utilizar 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 especializaci\u00f3n limitada y su ajuste con los datos de la empresa brindar\u00e1n un rendimiento decente sin fallas inesperadas.<\/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) est\u00e1 a cargo de modelos locales compactos. Esto reduce significativamente la volatilidad del presupuesto. El segundo nivel consiste en un modelo local grande 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 excederse del presupuesto, es posible que se produzcan 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 costos variables permanecen, pero est\u00e1n limitados 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 replica el modelo cl\u00e1sico de SOC de varios niveles, donde la primera l\u00ednea filtra y la tercera investiga; solo los roles son interpretados por modelos en lugar de 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":29566,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[2795,3539,3540],"tags":[638,107,2018,1861,5249,3223,3546,6114,192],"class_list":["post-29565","post","type-post","status-publish","format-standard","has-post-thumbnail","category-business","category-enterprise","category-smb","tag-amenazas","tag-consejos","tag-ia","tag-inteligencia-artificial","tag-ml","tag-presupuesto","tag-soc","tag-soc-autonomo","tag-tecnologia"],"hreflang":[{"hreflang":"es-mx","url":"https:\/\/latam.kaspersky.com\/blog\/tokenomics-ai-and-cybersecurity\/29565\/"},{"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":"es","url":"https:\/\/www.kaspersky.es\/blog\/tokenomics-ai-and-cybersecurity\/32542\/"},{"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":"pt-br","url":"https:\/\/www.kaspersky.com.br\/blog\/tokenomics-ai-and-cybersecurity\/25399\/"},{"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:\/\/latam.kaspersky.com\/blog\/tag\/inteligencia-artificial\/","name":"inteligencia artificial"},"_links":{"self":[{"href":"https:\/\/latam.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/29565","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/latam.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/latam.kaspersky.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/latam.kaspersky.com\/blog\/wp-json\/wp\/v2\/users\/2722"}],"replies":[{"embeddable":true,"href":"https:\/\/latam.kaspersky.com\/blog\/wp-json\/wp\/v2\/comments?post=29565"}],"version-history":[{"count":1,"href":"https:\/\/latam.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/29565\/revisions"}],"predecessor-version":[{"id":29567,"href":"https:\/\/latam.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/29565\/revisions\/29567"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/latam.kaspersky.com\/blog\/wp-json\/wp\/v2\/media\/29566"}],"wp:attachment":[{"href":"https:\/\/latam.kaspersky.com\/blog\/wp-json\/wp\/v2\/media?parent=29565"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/latam.kaspersky.com\/blog\/wp-json\/wp\/v2\/categories?post=29565"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/latam.kaspersky.com\/blog\/wp-json\/wp\/v2\/tags?post=29565"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}