El triaje de malware con LLM de Databricks cierra un punto ciego en binarios, pero el contexto sigue determinando el veredicto

Databricks publicó un estudio sobre triaje de malware con LLM que redujo los fallos de detección del 50% al 4% en 70 pruebas con modelos económicos. La mejora no provino de reentrenar esos modelos ni de sustituirlos por alternativas más costosas. Llegó al incorporar conocimiento estructurado de seguridad en binarios antes de que cada modelo tomara una decisión.

El resultado cuestiona una suposición habitual detrás del análisis de paquetes asistido por IA. Una mayor inteligencia del modelo no siempre es la respuesta más directa a criterios de seguridad deficientes. Un modelo más pequeño puede cerrar gran parte de la brecha cuando el análisis estático le proporciona la evidencia y el marco de interpretación adecuados.

El hallazgo es relevante porque los paquetes npm maliciosos no siempre exponen su comportamiento mediante JavaScript legible. Algunos incluyen ejecutables compilados detrás de archivos fuente limpios, metadatos creíbles y scripts de instalación habituales. Ese contexto circundante puede llevar a un modelo sin asistencia a emitir un veredicto seguro, pero peligroso.

El experimento completo, publicado el 16 de octubre de 2026, evaluó directamente ese fallo. Databricks analizó nueve modelos de siete proveedores utilizando cargas útiles nativas de Node.js diseñadas para la prueba. Después comparó sus juicios con y sin perfiles de capacidades, que son guías estructuradas elaboradas a partir de evidencia estática.

Por tanto, la comparación principal no enfrenta a un modelo con otro. Contrasta el razonamiento de un LLM sin asistencia con el razonamiento de un LLM fundamentado en evidencia específica del dominio. Databricks descubrió que esta distinción puede determinar si se bloquea un ladrón de credenciales oculto o se recomienda incluirlo en una lista de permitidos.

El triaje de malware con LLM de Databricks cambia el contexto de la decisión

Databricks no enseñó a sus modelos a realizar ingeniería inversa de binarios; cambió lo que sabían antes de evaluarlos.

La canalización de la empresa comienza con herramientas de seguridad deterministas. YARA analiza el archivo del paquete en busca de patrones conocidos. Semgrep examina el código fuente de JavaScript, mientras que los metadatos de npm aportan información sobre el paquete y su propósito declarado.

Un módulo independiente de análisis de binarios extrae evidencia de los artefactos compilados. El sistema combina esos hallazgos en un prompt estructurado. Después, el LLM devuelve un veredicto y el razonamiento que lo respalda, con hasta tres oportunidades para solicitar más archivos.

Databricks añadió perfiles de capacidades entre la extracción de evidencia y el juicio del modelo. Cada perfil representa una técnica maliciosa, como la recolección de credenciales, la persistencia, el enmascaramiento de binarios o la exfiltración por red. Evalúa condiciones observables frente a umbrales sospechosos, maliciosos y críticos.

Cuando un perfil alcanza su umbral, el sistema añade al contexto del modelo un resumen estructurado de unas 1.800 tokens. El modelo sigue controlando el veredicto final y puede rechazar la interpretación del perfil. El material incorporado actúa como una sesión informativa de expertos, no como una clasificación fija.

Esta arquitectura separa dos tareas que los productos de seguridad con LLM suelen mezclar. Las herramientas estáticas identifican importaciones, propiedades de archivos, metadatos y patrones de código. El modelo de lenguaje pondera esas señales dentro del contexto más amplio del paquete.

El experimento utilizó cinco tipos de cargas útiles maliciosas empaquetadas como complementos nativos de Node.js. Representaban un ladrón de credenciales, un dropper, una shell inversa, un stub de criptominero y un mecanismo de persistencia. El ladrón de credenciales también apareció en seis niveles de ofuscación.

Cada paquete incluía metadatos de apariencia profesional, un README plausible, enlaces de JavaScript y una configuración de compilación estándar. Esos elementos creaban la apariencia de un módulo nativo normal. El comportamiento malicioso permanecía dentro de un archivo compilado .node.

Los investigadores ejecutaron diez cargas útiles contra cada modelo en dos ocasiones. Una ejecución incluía perfiles de capacidades, mientras que la otra no. Por lo demás, los prompts, la evidencia binaria, la configuración de inferencia y los bytes de las cargas útiles no cambiaron.

Siete modelos formaron el nivel económico: Claude Haiku 4.5, Gemini 3.5 Flash, Gemma 3 12B, GPT-5.4-nano, Qwen3-Next 80B, GLM 5.3 Flash y Llama 3.1 8B. Claude Sonnet 4.6 y Kimi K3 proporcionaron líneas base de comportamiento con mayor capacidad.

Sin perfiles de capacidades, el grupo económico no alcanzó el umbral de detección del estudio en 35 de 70 pruebas. Veinte de esos resultados clasificaron cargas útiles conocidas como maliciosas como benignas. Con el umbral malicioso más estricto, 51 de 70 pruebas quedaron por debajo.

Tras la inyección de perfiles, 32 de esos 35 fallos pasaron a ser detecciones. Ningún modelo evaluado devolvió un veredicto benigno para ninguna carga útil diseñada. Solo tres resultados de GPT-5.4-nano permanecieron por debajo del umbral de escalamiento, y los tres se clasificaron como sospechosos.

Este es el cambio central detrás del triaje de malware con LLM de Databricks. Los modelos no recibieron nuevos pesos, entrenamiento más amplio ni una lección general sobre seguridad. Recibieron interpretaciones concisas vinculadas a evidencia ya extraída del paquete.

Por qué los paquetes npm limpios pueden ocultar binarios peligrosos

El punto ciego en binarios surge cuando el contexto de un paquete aparentemente inocuo pesa más que la evidencia que el modelo no puede interpretar con seguridad.

Databricks comenzó a recopilar muestras de malware de npm en noviembre de 2025. Su corpus de investigación incluía 11.413 versiones de paquetes corroboradas mediante avisos de malware npm de OSV. La mayoría contenía código fuente malicioso o descargaba una carga útil desde un servidor externo.

Solo 432 versiones de paquetes corroboradas, o el 3,8%, incluían un binario. Esa pequeña proporción generó un problema de triaje desproporcionado. Los paquetes con binarios no recibieron veredictos maliciosos concluyentes más de dos veces más a menudo que los paquetes que solo contenían código fuente.

Las tasas comunicadas fueron del 14,4% para los paquetes con binarios y del 6,2% para los paquetes que solo contenían código fuente. La diferencia importa porque los archivos compilados eliminan muchas señales disponibles en el código legible. Los binarios despojados también omiten los nombres de símbolos que ayudan a los analistas a interpretar funciones y datos.

Un paquete npm puede incluir código nativo de forma legítima. Las bibliotecas de rendimiento, los enlaces de bases de datos, las herramientas de imágenes, los terminales y las utilidades del sistema utilizan regularmente componentes compilados. Por tanto, un script de instalación que invoque node-gyp-build no es automáticamente sospechoso.

Los atacantes pueden explotar esa normalidad. Pueden ocultar comportamiento nativo malicioso detrás de enlaces JavaScript limpios y una descripción creíble del paquete. Un modelo que se centre en la coherencia a nivel de paquete puede tratar esas señales benignas como evidencia más sólida que unas importaciones binarias ambiguas.

Databricks observó este comportamiento en cada uno de los 35 fallos iniciales de detección. Cada fallo se apoyaba en al menos dos señales contextuales benignas. Veinticuatro citaron conjuntamente cuatro de esas señales.

Los 35 consideraron estándar el script de instalación. Los 35 también trataron el empaquetado de complementos nativos como algo habitual. Treinta y dos consideraron que los metadatos eran coherentes con el propósito declarado, mientras que 21 se apoyaron en JavaScript limpio.

En 14 casos, los modelos reinterpretaron las importaciones del binario como llamadas normales del sistema. Funciones como fopen, connect y gethostname pueden respaldar software legítimo. Su combinación y su comportamiento circundante determinan si indican robo de credenciales o conectividad rutinaria.

La ofuscación empeoró ese juicio. Databricks descubrió que algunos modelos asignaban una gravedad menor a medida que la carga útil de robo de credenciales se volvía más difícil de inspeccionar. El envoltorio limpio seguía siendo legible, mientras que la evidencia binaria incriminatoria se volvía menos accesible.

Este patrón coincide con un estudio más amplio sobre ofuscación en el que participaron ChatGPT-4o, Gemini Flash 2.5 y Claude Sonnet 4. Las transformaciones del compilador provocaron fallos de clasificación repetidos, aunque el comportamiento subyacente del programa permanecía sin cambios.

La investigación sobre el contexto de binarios despojados describe un desafío relacionado. Eliminar símbolos quita señales contextuales utilizadas para localizar y validar comportamientos inseguros. Un razonamiento más fluido no puede reconstruir evidencia que la canalización de análisis nunca expuso.

Los registros de paquetes amplifican las consecuencias porque las dependencias de software pasan directamente a entornos de desarrollo y producción. MITRE define el compromiso de la cadena de suministro como la manipulación de software, productos o mecanismos de entrega antes de que el destinatario los reciba.

Por tanto, un paquete malicioso puede heredar confianza del registro, del grafo de dependencias o de una cuenta de mantenedor comprometida. Una vez instalado, su binario puede ejecutarse con los permisos de la aplicación. Una presentación limpia se convierte en parte de la superficie de ataque.

Los perfiles de capacidades convierten pistas estáticas en contexto de seguridad

Los perfiles de capacidades funcionan porque convierten pistas técnicas dispersas en una afirmación explícita que un modelo puede evaluar.

Una lista de importaciones sin procesar no explica la intención. connect indica conectividad de red, mientras que fopen indica acceso a archivos. Ninguna de las dos funciones por sí sola le dice a un modelo que un complemento nativo lee credenciales y las envía a otro lugar.

Un perfil de capacidades combina esas observaciones en un patrón específico de una técnica. Puede considerar el tipo de paquete, el formato binario, las importaciones, la entropía, las cadenas, los metadatos y el comportamiento del código fuente. Los umbrales ponderados expresan entonces hasta qué punto la evidencia combinada respalda una hipótesis de seguridad.

El proceso se parece al razonamiento aumentado mediante recuperación, pero el material recuperado se genera a partir del paquete en revisión. No es un extracto general de un informe de amenazas. Cada resumen conecta una definición de técnica con la evidencia hallada en ese análisis.

Para la carga útil de robo de credenciales, los perfiles cubrían el enmascaramiento binario, la recolección de credenciales, la exfiltración por red y el reconocimiento del entorno. La shell inversa activó perfiles de enmascaramiento binario y comportamiento de shell inversa. El dropper activó cuatro perfiles críticos.

Esa especificidad cambia la tarea del modelo. Sin perfiles, el modelo debe inferir tanto el significado de cada artefacto binario como el veredicto a nivel de paquete. Con perfiles, la lógica estática se encarga del primer paso de interpretación.

Después, el modelo evalúa si la evidencia reunida respalda la conclusión del perfil. Puede considerar evidencia en contra, valorar el envoltorio del paquete y seleccionar una acción. Esta división limita la cantidad de conocimiento especializado que se espera de los pesos del modelo.

El resultado del ladrón de credenciales con Qwen3-Next ilustra el efecto. Sin perfiles, el modelo etiquetó una muestra ofuscada como benigna con una confianza de 0,98. También recomendó incluir el paquete en una lista de permitidos.

Con cuatro perfiles incorporados, el mismo modelo etiquetó la muestra con bytes idénticos como maliciosa con una confianza de 0,98. Recomendó bloquear el paquete. No cambió nada salvo el contexto estructurado del dominio.

Esta inversión es más importante que una mejora media en un benchmark. Una recomendación de inclusión en lista de permitidos con alta confianza puede impedir revisiones posteriores. Convierte un detector incierto en una fuente operativa de confianza mal depositada.

El experimento también identificó cuatro modos de fallo recurrentes: racionalización, desestimación, ambigüedad y confabulación. Estas categorías explican por qué simplemente recopilar más opiniones de modelos no resuelve el problema de forma fiable.

La racionalización se produjo en aproximadamente el 37% de los 90 análisis realizados con los nueve modelos principales. Los modelos utilizaron detalles ordinarios del empaquetado para restar importancia a la evidencia sospechosa. La desestimación apareció en el 22% de los casos y a menudo ignoró por completo las importaciones binarias.

La vacilación afectó al 16% de los análisis. Estos modelos detectaron el peligro, pero se detuvieron en un veredicto de sospecha, potencialmente por debajo de un umbral de bloqueo automatizado. La confabulación apareció en cerca del 23%, incluidas respuestas de modelos con mayores capacidades.

La confabulación generó un riesgo operativo diferente. Un modelo podía llegar al veredicto correcto mientras inventaba direcciones, funciones o rutinas de cifrado. Esos detalles falsos podían contaminar los registros de auditoría y desviar a los investigadores humanos.

Gemini 3.5 Flash detectó las diez cargas útiles sin perfiles de capacidades. Sin embargo, Databricks informó de detalles técnicos fabricados en varias explicaciones. Una clasificación correcta no garantizaba un razonamiento forense fiable.

Ese resultado respalda un diseño centrado en la evidencia. Una canalización de seguridad debe conservar la fuente de cada afirmación y distinguir las observaciones extraídas de la interpretación del modelo. Los analistas deben poder rastrear un veredicto hasta importaciones, secciones, cadenas o comportamientos del código reales.

Una base de conocimiento técnico mantenida también puede respaldar el aspecto humano de este proceso. Los equipos necesitan registros accesibles sobre la lógica de los perfiles, las excepciones, las decisiones de revisión y las técnicas cambiantes de los atacantes.

Los modelos más baratos reducen la brecha, pero las métricas tienen límites

La historia de costes es creíble dentro del experimento, pero los resultados de producción no demuestran una detección binaria perfecta.

Claude Sonnet 4.6 y Kimi K3 detectaron todas las cargas útiles diseñadas sin perfiles. Databricks estimó que esos modelos de referencia costaban aproximadamente tres veces más por análisis que el grupo económico. La inyección de perfiles permitió que la mayoría de los modelos más baratos igualaran su tasa de detección.

La evidencia adicional no fue gratuita. Los modelos económicos recibieron entre un 9% y un 34% más de tokens de entrada tras la inyección de perfiles. Su uso de tokens de salida también aumentó en la mayoría de los casos.

Los modelos más capaces a veces usaron menos recursos porque los perfiles redujeron la exploración. Claude Opus 4.6 promedió unos 10.551 tokens de entrada sin perfiles y 7.214 con ellos. Kimi K3 produjo un 13% menos de tokens de salida tras recibir la evidencia de los perfiles.

Estas cifras sugieren que un mejor contexto puede sustituir solicitudes repetidas de archivos o un razonamiento prolongado. Ese beneficio depende de la calidad de la etapa estática. Una evidencia débil convertida en prosa pulida solo facilitaría aceptar una conclusión incorrecta.

El benchmark controlado también sigue siendo pequeño. Utilizó diez cargas útiles diseñadas a partir de cinco tipos de comportamiento. Cada modelo realizó una pasada controlada bajo cada condición, con temperatura cero y prompts coherentes.

El comportamiento de los modelos alojados puede variar a medida que los proveedores actualizan sus endpoints. Databricks reconoció que los veredictos absolutos representan un único periodo de servicio. La evidencia más sólida es la diferencia dentro de ese periodo entre entradas idénticas.

La validación en producción ofrece una visión más amplia y desordenada. Databricks identificó 470 versiones de paquetes npm maliciosos confirmados por OSV que contenían 604 binarios nativos. El conjunto incluía 273 archivos PE, 215 archivos ELF, 113 archivos Mach-O y tres formatos no identificados.

Todos los binarios ELF estaban despojados de símbolos. El cuarenta por ciento de los binarios se compiló con Go o Rust, mientras que 50 archivos ELF estaban empaquetados con UPX. Estos detalles muestran por qué una única regla universal para código nativo produciría resultados débiles.

La evaluación en producción cubrió 425 versiones de paquetes maliciosos con veredictos del escáner. También utilizó 2.449 versiones de paquetes de 287 paquetes aparentemente benignos. Los candidatos benignos superaban un millón de descargas mensuales y nunca habían aparecido en OSV.

En el umbral de escalamiento, el escáner informó de una precisión de 0,77, una recuperación de 0,81 y una puntuación F1 de 0,79. Recuperó 345 de 425 versiones de paquetes maliciosos. Ochenta quedaron por debajo del umbral.

El conjunto benigno produjo 104 escalaciones, lo que representa el 4,25% de sus versiones de paquetes. Estas alertas se concentraron en seis paquetes, o alrededor del 2% del conjunto distinto de paquetes benignos.

Una tasa de revisión del 4,25% puede ser manejable en una cola de triaje filtrada. Se volvería costosa si se aplicara indiscriminadamente a todas las versiones de paquetes de un gran ecosistema de dependencias. El volumen operativo importa tanto como la precisión del benchmark.

Las etiquetas también introducen incertidumbre. Los avisos de OSV marcan una versión de paquete como maliciosa sin identificar siempre qué artefacto contiene la carga útil. Algunos paquetes pueden incluir un binario de terceros inocuo mientras JavaScript malicioso ejecuta el ataque real.

Databricks descubrió que aproximadamente la mitad de los 20 paquetes de producción clasificados como benignos contenían herramientas de terceros reconocibles. Los ejemplos incluían ripgrep, node-pty y plugins del instalador NSIS. El aviso podría seguir siendo correcto a nivel de paquete.

Por tanto, la recuperación informada no es una medida limpia de clasificación binaria. Mide decisiones frente a etiquetas de OSV a nivel de paquete. Databricks afirma explícitamente que el rendimiento real sobre binarios puede ser mayor o menor.

La base de datos de paquetes maliciosos de OpenSSF sigue siendo valiosa porque proporciona informes abiertos en formato OSV. Sin embargo, las etiquetas a escala de registro no pueden sustituir la verificación a nivel de artefacto para evaluar un detector de binarios.

El razonamiento autónomo de los modelos es ahora la estrategia bajo presión

La investigación presiona a los productos de seguridad que tratan a un LLM como analista principal en lugar de como capa final de razonamiento.

Los diseños centrados en el modelo son atractivos porque reducen el trabajo de integración. Un equipo puede colocar el contenido de un paquete en un prompt, solicitar un veredicto y mostrar una explicación en lenguaje natural. Esa simplicidad oculta la dependencia del modelo de la evidencia visible.

Las cargas útiles compiladas exponen esta debilidad. Un modelo de lenguaje puede interpretar desensamblado o características extraídas cuando están disponibles. No puede inferir de manera fiable un comportamiento oculto a partir de JavaScript limpio y metadatos profesionales por sí solos.

Comprar un modelo más grande puede mejorar la detección de referencia. Databricks observó que Sonnet y Kimi detectaron todas las cargas útiles diseñadas sin perfiles. Sin embargo, ambas referencias de mayor capacidad siguieron produciendo razonamientos confabulados en algunos análisis.

Esto crea dos requisitos independientes. Un detector debe llegar a la decisión de escalamiento correcta. También debe proporcionar evidencia que un analista pueda verificar.

Los perfiles de capacidades abordan el primer requisito al dirigir la atención hacia combinaciones significativas. Los hallazgos estáticos estructurados respaldan el segundo al anclar las explicaciones en artefactos observables. El LLM sigue siendo útil para la síntesis, la resolución de conflictos y la priorización.

La votación mayoritaria no ofrece la misma protección. En una muestra ofuscada de robo de credenciales, los nueve modelos se dividieron entre benigno, sospechoso, altamente sospechoso y malicioso. La mayoría permaneció por debajo del umbral de detección.

Esos errores estaban correlacionados porque varios modelos confiaban en el mismo contexto benigno. Añadir más jueces confundidos de forma similar no introdujo evidencia independiente. El voto simplemente repitió el punto ciego.

La implicación estratégica va más allá de npm. Los equipos de seguridad piden cada vez más a los LLM que interpreten alertas, código fuente, registros, configuraciones de nube y eventos de identidad. Cada tarea contiene supuestos de dominio que un modelo general puede no aplicar de forma coherente.

La arquitectura más defendible separa extracción, interpretación y decisión. Las herramientas deterministas extraen hechos. Los perfiles versionados interpretan combinaciones relevantes. El modelo resuelve el contexto y produce una evaluación orientada al analista.

Esto no hace que los perfiles sean neutrales. Sus autores eligen umbrales, ponderaciones, definiciones y excepciones. Los atacantes también pueden estudiar reglas comunes y adaptar sus binarios para evitar activarlas.

Los perfiles pueden quedar obsoletos a medida que cambian los sistemas de compilación y las técnicas de malware. Una combinación de importaciones sospechosa hoy puede aparecer mañana en un framework legítimo popular. A la inversa, un nuevo método de exfiltración puede escapar de perfiles escritos en torno a llamadas al sistema más antiguas.

Por tanto, el enfoque desplaza parte del riesgo de la selección de modelos al mantenimiento del conocimiento. Los equipos de seguridad necesitan responsables de la calidad de los perfiles, las pruebas de regresión y la revisión de falsos positivos. También necesitan evidencia versionada que explique por qué existe cada regla.

Las defensas del registro siguen siendo una capa independiente. La guía de procedencia de npm explica cómo los usuarios pueden verificar dónde y cómo se publicaron los paquetes compatibles. La procedencia puede conectar un artefacto con su commit de origen y su flujo de compilación.

Esa verificación ayuda a identificar publicaciones no autorizadas o manipuladas. No demuestra que el código fuente autorizado o el comportamiento compilado sean seguros. El triaje de malware, la procedencia, la seguridad de los mantenedores y los controles de tiempo de ejecución abordan partes diferentes del mismo problema de cadena de suministro.

Para los compradores, la pregunta clave ya no es qué modelo encabeza un benchmark genérico de seguridad. Deben preguntar qué evidencia llega al modelo, cómo siguen siendo rastreables las afirmaciones y cómo gestiona el sistema los binarios inciertos.

También deben examinar la política de escalamiento. Un veredicto sospechoso tiene poco valor protector si los flujos automatizados solo bloquean clasificaciones maliciosas. Databricks mostró que varios modelos reconocieron el riesgo, pero no lograron superar el umbral operativo.

Tres señales pondrán a prueba si el enfoque se generaliza

La siguiente prueba es si la inyección de conocimiento de dominio resiste malware desconocido, la escala de los registros y la adaptación adversaria.

La primera señal es una reproducción independiente con malware real etiquetado a nivel de artefacto. Los investigadores necesitan conjuntos de datos que identifiquen si el componente malicioso es JavaScript, metadatos, un script de instalación o un binario incluido.

Estas etiquetas afinarían las estimaciones de precisión y recuperación. También revelarían si los perfiles detectan la carga útil real o simplemente se correlacionan con una etiqueta de paquete malicioso. Unos resultados más sólidos a nivel de artefacto reforzarían la afirmación central de Databricks.

La segunda señal es el rendimiento frente a comportamientos y cadenas de herramientas no vistos. Databricks probó cinco patrones de ataque diseñados y validó su escáner completo sobre un conjunto más amplio derivado de OSV. Las pruebas futuras deberían excluir familias enteras de comportamiento durante el desarrollo de perfiles.

El éxito en familias excluidas demostraría que el método captura conceptos de seguridad transferibles. Una caída pronunciada sugeriría que los perfiles funcionan principalmente como reglas seleccionadas para patrones conocidos.

La diversidad de compiladores y plataformas será importante. Los archivos PE, ELF y Mach-O exponen metadatos y convenciones diferentes. Los binarios de Go y Rust también difieren de los artefactos de C o C++ de formas que afectan al análisis estático.

Los atacantes responderán si los sistemas de perfiles de capacidades se vuelven comunes. Pueden sustituir importaciones evidentes, retrasar la ejecución, cargar funcionalidades dinámicamente o trasladar el comportamiento malicioso a otra capa del paquete. Cada adaptación puede debilitar un resumen de evidencia estática.

La tercera señal es el coste operativo de revisión. Databricks informó de 104 escalaciones entre 2.449 versiones de paquetes benignos, concentradas en seis paquetes. Los datos de despliegue deberían mostrar cuántas horas de analistas consumen esos grupos.

Un sistema sostenible debe agrupar alertas relacionadas, preservar la evidencia y aprender de las excepciones revisadas. De lo contrario, una tasa modesta de falsos positivos a nivel de paquete puede generar trabajo repetitivo entre versiones y entornos.

Los equipos también deberían supervisar los fallos graves, no solo la recuperación agregada. El escáner de producción de Databricks clasificó 20 versiones de paquetes maliciosos etiquetadas por OSV como benignas. Algunas probablemente transportaban su carga útil fuera del binario incluido, pero la incertidumbre sigue siendo importante.

La calidad de la evidencia debería convertirse en una métrica informada. Un detector que clasifica correctamente mientras inventa detalles forenses no es completamente fiable. Las evaluaciones futuras deberían puntuar la fundamentación factual por separado de la precisión del veredicto.

El triaje de malware con LLM de Databricks ofrece un sólido argumento a favor de la experiencia estructurada en tiempo de inferencia. Muestra que los modelos más baratos pueden tomar decisiones mucho mejores cuando la canalización de seguridad interpreta evidencia opaca antes de solicitar un juicio.

No demuestra que el conocimiento aportado en el momento del prompt elimine el problema de los binarios. Los perfiles dependen de una visibilidad estática, reglas mantenidas y umbrales que los atacantes pueden sondear. Las etiquetas de producción también dejan sin resolver qué artefacto era malicioso.

Los equipos de seguridad deberían probar ahora una propuesta práctica: ¿pueden mejorar sus modelos actuales con mejores evidencias antes de pagar por un modelo más grande? Construyan un conjunto de evaluación a partir de paquetes revisados, conserven etiquetas a nivel de artefacto y comparen análisis idénticos con y sin contexto del dominio. El resultado útil no es una explicación convincente. Es un veredicto trazable que se sostiene cuando el paquete parece limpio y el binario no.