Explainability en Detección de Malware: SHAP, LIME y Modelos Interpretables

El problema de la caja negra en detección de malware

Un modelo de ML detecta un binario como malicioso con 94.7% de confianza. El analista SOC recibe la alerta. Su primera pregunta no es "¿qué score tiene?" sino "¿por qué?". Sin esa respuesta, la alerta es ruido con un número decorativo.

La detección de malware con ML enfrenta un problema de confianza operativa. Los modelos más precisos (gradient boosting, deep learning, ensembles) son los más difíciles de interpretar. Los más interpretables (decision trees, regresión logística) suelen quedarse cortos en rendimiento. Este tradeoff entre precisión e interpretabilidad no es teórico: afecta directamente la velocidad de triaje, la tasa de falsos positivos investigados y la capacidad del equipo SOC para documentar incidentes.

La explicabilidad no es un lujo académico. Es una necesidad operativa, regulatoria y de mejora continua del propio modelo.

Tres razones concretas para exigir explicabilidad

Operativa: triaje eficiente en el SOC

Un equipo SOC procesa cientos de alertas diarias. Si el modelo solo emite un score binario, cada alerta requiere investigación manual completa. Si el modelo explica que la detección se activó por "entropía de sección .text en percentil 99 + imports de CreateRemoteThread + tamaño de overlay anómalo", el analista puede validar en segundos si esos indicadores son coherentes con el contexto.

La explicabilidad reduce el tiempo medio de triaje (MTTT) porque convierte alertas opacas en hipótesis verificables.

Regulatoria: EU AI Act y frameworks de gobernanza

El EU AI Act clasifica los sistemas de detección de amenazas como potencialmente de alto riesgo cuando toman decisiones que afectan a personas (bloqueo de acceso, cuarentena de endpoints, alertas que desencadenan investigaciones). Los sistemas de alto riesgo requieren documentación de la lógica de decisión, mecanismos de supervisión humana y trazabilidad.

Frameworks como NIST AI RMF y ISO/IEC 42001 también exigen que las organizaciones documenten cómo sus modelos de IA toman decisiones. Un modelo de malware sin explicabilidad es un riesgo de compliance.

Mejora del modelo: detectar sesgos y concept drift

La explicabilidad revela qué features domina el modelo. Si descubres que el 60% de las detecciones se basan en el timestamp de compilación del PE header, tienes un problema: esa feature es trivial de manipular para un atacante. Sin explicabilidad, nunca lo sabrías.

También detecta concept drift: cuando las features importantes cambian entre entrenamientos sucesivos, indica que la distribución de malware está evolucionando y el modelo necesita adaptarse.

SHAP: explicaciones con fundamento teórico

SHAP (SHapley Additive exPlanations) aplica valores de Shapley de la teoría de juegos cooperativos al problema de explicar predicciones de ML. La idea central: cada feature es un "jugador" que contribuye al "pago" (la predicción). El valor SHAP de una feature mide su contribución marginal promediada sobre todas las posibles coaliciones de features.

Propiedades matemáticas

SHAP cumple tres propiedades que otros métodos no garantizan:

Eficiencia: la suma de todos los valores SHAP iguala la diferencia entre la predicción del modelo y la predicción base (media del dataset).

Simetría: si dos features contribuyen igual al modelo en todas las coaliciones posibles, reciben el mismo valor SHAP.

Monotonicidad: si una feature contribuye más que otra en todas las coaliciones, su valor SHAP es mayor.

Estas propiedades hacen que SHAP sea el único método de explicabilidad con garantías teóricas de consistencia y justicia en la asignación de importancia.

SHAP aplicado a detección de malware

import shap
import xgboost as xgb
import pandas as pd
import numpy as np

# Modelo entrenado de detección de malware
model = xgb.XGBClassifier()
model.load_model("malware_detector_xgb.json")

# Dataset de features extraídas de binarios PE
X_test = pd.read_parquet("pe_features_test.parquet")
feature_names = X_test.columns.tolist()

# Crear explainer optimizado para tree-based models
explainer = shap.TreeExplainer(model)

# Calcular SHAP values para todo el test set
shap_values = explainer.shap_values(X_test)

# Visualización global: qué features importan más en general
shap.summary_plot(
    shap_values,
    X_test,
    feature_names=feature_names,
    plot_type="bar",
    max_display=20
)

Explicación local: por qué este binario es malicioso

# Seleccionar una muestra específica detectada como maliciosa
sample_idx = 42
sample = X_test.iloc[sample_idx:sample_idx+1]

# Explicación individual con force plot
shap.force_plot(
    explainer.expected_value,
    shap_values[sample_idx],
    sample,
    feature_names=feature_names,
    matplotlib=True
)

# Explicación en texto para el analista SOC
def explain_detection(shap_vals, feature_names, top_n=5):
    """Genera explicación legible de una detección."""
    abs_vals = np.abs(shap_vals)
    top_indices = np.argsort(abs_vals)[-top_n:][::-1]

    explanations = []
    for idx in top_indices:
        fname = feature_names[idx]
        value = shap_vals[idx]
        direction = "incrementa" if value > 0 else "reduce"
        explanations.append(
            f"  - {fname}: {direction} la probabilidad de malware "
            f"en {abs(value):.4f}"
        )

    return "\n".join(explanations)

print("Factores principales de deteccion:")
print(explain_detection(
    shap_values[sample_idx],
    feature_names
))

Salida del analista:

Factores principales de deteccion:
  - section_text_entropy: incrementa la probabilidad de malware en 0.2341
  - imports_createremotethread: incrementa la probabilidad de malware en 0.1876
  - overlay_size_ratio: incrementa la probabilidad de malware en 0.1203
  - section_count: reduce la probabilidad de malware en 0.0892
  - has_debug_directory: reduce la probabilidad de malware en 0.0654

SHAP interaction values

Los interaction values revelan cómo pares de features interactúan en la predicción. En malware, esto es valioso: la combinación de alta entropía + imports de criptografía es más sospechosa que cualquiera de las dos por separado.

# Interaction values (computacionalmente costoso)
shap_interaction = explainer.shap_interaction_values(X_test[:100])

# Visualizar interacciones más fuertes
shap.summary_plot(
    shap_interaction[sample_idx],
    X_test.iloc[sample_idx:sample_idx+1],
    feature_names=feature_names,
    max_display=10
)

LIME: explicaciones locales agnósticas al modelo

LIME (Local Interpretable Model-agnostic Explanations) toma un enfoque diferente. Para explicar una predicción, perturba la muestra original generando vecinos sintéticos, obtiene predicciones del modelo para esos vecinos y entrena un modelo lineal local (interpretable) que aproxime el comportamiento del modelo complejo en esa vecindad.

Ventajas de LIME sobre SHAP

LIME es agnóstico al modelo: funciona con cualquier clasificador que exponga una función predict_proba. No necesita acceso a la estructura interna del modelo. Esto lo hace útil cuando trabajas con modelos de terceros o ensembles heterogéneos.

Además, LIME es más rápido que KernelSHAP (la versión agnóstica de SHAP) porque no necesita calcular todas las coaliciones posibles.

Desventajas

LIME puede ser inestable: ejecutar la misma explicación dos veces con diferentes semillas puede dar resultados diferentes. Esto ocurre porque el muestreo de vecinos es estocástico. En un contexto SOC donde las explicaciones deben ser reproducibles para documentación de incidentes, esta inestabilidad es problemática.

LIME aplicado a malware

import lime
import lime.lime_tabular
import numpy as np

# Crear explainer LIME
lime_explainer = lime.lime_tabular.LimeTabularExplainer(
    training_data=X_train.values,
    feature_names=feature_names,
    class_names=["benigno", "malicioso"],
    mode="classification",
    discretize_continuous=True,
    random_state=42  # Para reproducibilidad
)

# Explicar una predicción individual
explanation = lime_explainer.explain_instance(
    data_row=X_test.iloc[sample_idx].values,
    predict_fn=model.predict_proba,
    num_features=10,
    num_samples=5000  # Mas vecinos = mas estable
)

# Visualizar
explanation.show_in_notebook()

# Extraer features mas influyentes
for feature, weight in explanation.as_list():
    direction = "malicioso" if weight > 0 else "benigno"
    print(f"  {feature}: contribuye hacia {direction} ({weight:.4f})")

Estabilización de LIME

Para mitigar la inestabilidad, se puede ejecutar LIME varias veces y promediar:

def stable_lime_explanation(explainer, sample, predict_fn,
                            n_runs=10, num_features=10):
    """LIME estabilizado con multiple ejecuciones."""
    feature_weights = {}

    for seed in range(n_runs):
        exp = explainer.explain_instance(
            data_row=sample,
            predict_fn=predict_fn,
            num_features=num_features,
            num_samples=5000,
            random_state=seed
        )
        for fname, weight in exp.as_list():
            if fname not in feature_weights:
                feature_weights[fname] = []
            feature_weights[fname].append(weight)

    # Promediar y calcular desviacion estandar
    stable_features = {}
    for fname, weights in feature_weights.items():
        stable_features[fname] = {
            "mean_weight": np.mean(weights),
            "std": np.std(weights),
            "stability": 1.0 - (np.std(weights) / (np.mean(np.abs(weights)) + 1e-8))
        }

    # Ordenar por peso absoluto medio
    sorted_features = sorted(
        stable_features.items(),
        key=lambda x: abs(x[1]["mean_weight"]),
        reverse=True
    )

    return sorted_features

Feature importance nativa: el baseline obligatorio

Antes de aplicar SHAP o LIME, los modelos tree-based ofrecen feature importance nativa que, aunque menos rigurosa, es instantánea y gratuita.

Tipos de feature importance

Gini importance (impurity-based): mide cuánto reduce cada feature la impureza (Gini) en los splits del árbol. Es rápida pero sesgada hacia features con alta cardinalidad (muchos valores únicos).

Permutation importance: mide cuánto se degrada el rendimiento del modelo cuando los valores de una feature se permutan aleatoriamente. Es más fiable que Gini importance pero más lenta porque requiere reevaluar el modelo para cada feature.

from sklearn.inspection import permutation_importance
from sklearn.ensemble import RandomForestClassifier

# Feature importance por Gini (instantanea)
rf_model = RandomForestClassifier(n_estimators=200, random_state=42)
rf_model.fit(X_train, y_train)

gini_importance = pd.Series(
    rf_model.feature_importances_,
    index=feature_names
).sort_values(ascending=False)

print("Top 10 features (Gini importance):")
print(gini_importance.head(10))

# Permutation importance (mas fiable)
perm_importance = permutation_importance(
    rf_model, X_test, y_test,
    n_repeats=10,
    random_state=42,
    n_jobs=-1
)

perm_df = pd.DataFrame({
    "feature": feature_names,
    "importance_mean": perm_importance.importances_mean,
    "importance_std": perm_importance.importances_std
}).sort_values("importance_mean", ascending=False)

print("\nTop 10 features (permutation importance):")
print(perm_df.head(10))

Comparativa entre metodos

import matplotlib.pyplot as plt

def compare_importance_methods(gini, perm, shap_global, top_n=15):
    """Compara rankings de importancia entre metodos."""
    fig, axes = plt.subplots(1, 3, figsize=(18, 8))

    # Gini
    gini.head(top_n).plot(kind="barh", ax=axes[0], color="#6366f1")
    axes[0].set_title("Gini Importance")
    axes[0].invert_yaxis()

    # Permutation
    perm.head(top_n).set_index("feature")["importance_mean"].plot(
        kind="barh", ax=axes[1], color="#22c55e"
    )
    axes[1].set_title("Permutation Importance")
    axes[1].invert_yaxis()

    # SHAP global
    shap_global.head(top_n).plot(kind="barh", ax=axes[2], color="#f59e0b")
    axes[2].set_title("SHAP Global Importance")
    axes[2].invert_yaxis()

    plt.tight_layout()
    plt.savefig("importance_comparison.png", dpi=150, bbox_inches="tight")
    plt.show()

Modelos interpretables como complemento

Los modelos complejos (XGBoost, Random Forest con 500 arboles, deep learning) alcanzan mejor rendimiento, pero su interpretabilidad es inherentemente limitada incluso con SHAP/LIME. Los modelos intrínsecamente interpretables ofrecen transparencia total a costa de algo de precisión.

Decision trees con profundidad controlada

from sklearn.tree import DecisionTreeClassifier, export_text

# Arbol con profundidad limitada para interpretabilidad
dt_interpretable = DecisionTreeClassifier(
    max_depth=5,        # Arbol legible por humanos
    min_samples_leaf=50,
    class_weight="balanced",
    random_state=42
)
dt_interpretable.fit(X_train, y_train)

# Exportar reglas legibles
rules = export_text(
    dt_interpretable,
    feature_names=feature_names,
    max_depth=5
)
print(rules)

# Evaluar
from sklearn.metrics import classification_report
y_pred = dt_interpretable.predict(X_test)
print(classification_report(y_test, y_pred, target_names=["benigno", "malicioso"]))

Las reglas resultantes son directamente traducibles a lógica de detección:

|--- section_text_entropy > 7.21
|   |--- imports_suspicious_count > 3
|   |   |--- overlay_size > 102400
|   |   |   |--- class: malicioso (confianza: 96.2%)
|   |   |--- overlay_size <= 102400
|   |   |   |--- has_authenticode <= 0.5
|   |   |   |   |--- class: malicioso (confianza: 89.1%)

Regresion logistica con regularizacion

La regresion logística ofrece coeficientes directamente interpretables. Cada coeficiente indica cuánto contribuye una feature a la log-odds de ser malicioso.

from sklearn.linear_model import LogisticRegression
from sklearn.preprocessing import StandardScaler

# Escalar features para que los coeficientes sean comparables
scaler = StandardScaler()
X_train_scaled = scaler.fit_transform(X_train)
X_test_scaled = scaler.transform(X_test)

# Regresion logistica con L1 para seleccion de features
lr_model = LogisticRegression(
    penalty="l1",
    solver="liblinear",
    C=1.0,
    class_weight="balanced",
    random_state=42
)
lr_model.fit(X_train_scaled, y_train)

# Coeficientes interpretables
coef_df = pd.DataFrame({
    "feature": feature_names,
    "coefficient": lr_model.coef_[0],
    "abs_coefficient": np.abs(lr_model.coef_[0])
}).sort_values("abs_coefficient", ascending=False)

print("Top 15 features por coeficiente logistico:")
for _, row in coef_df.head(15).iterrows():
    direction = "malicioso" if row["coefficient"] > 0 else "benigno"
    print(f"  {row['feature']}: {row['coefficient']:.4f} (hacia {direction})")

# Features eliminadas por L1 (coeficiente = 0)
zero_features = coef_df[coef_df["abs_coefficient"] == 0]
print(f"\nFeatures eliminadas por L1: {len(zero_features)}")

Enfoque hibrido: modelo complejo + explicador simple

La estrategia mas pragmatica combina un modelo complejo para deteccion con uno simple para explicacion:

class HybridMalwareDetector:
    """Modelo complejo para score + modelo simple para explicacion."""

    def __init__(self):
        self.detector = xgb.XGBClassifier(
            n_estimators=500,
            max_depth=8,
            learning_rate=0.05
        )
        self.explainer_tree = DecisionTreeClassifier(
            max_depth=5,
            min_samples_leaf=50
        )
        self.shap_explainer = None

    def fit(self, X, y):
        self.detector.fit(X, y)
        self.explainer_tree.fit(X, y)
        self.shap_explainer = shap.TreeExplainer(self.detector)

    def predict(self, X):
        return self.detector.predict(X)

    def predict_proba(self, X):
        return self.detector.predict_proba(X)

    def explain(self, sample, method="shap"):
        """Explicacion de una deteccion individual."""
        if method == "shap":
            sv = self.shap_explainer.shap_values(sample)
            return self._format_shap(sv, sample)
        elif method == "tree":
            path = self.explainer_tree.decision_path(sample)
            return self._format_tree_path(path, sample)

    def _format_shap(self, shap_values, sample):
        top_features = np.argsort(np.abs(shap_values[0]))[-5:][::-1]
        return [
            {
                "feature": self.feature_names[i],
                "impact": float(shap_values[0][i]),
                "value": float(sample.iloc[0, i]),
                "direction": "malicious" if shap_values[0][i] > 0 else "benign"
            }
            for i in top_features
        ]

    def _format_tree_path(self, path, sample):
        # Extraer reglas del camino de decision
        node_indicator = path.toarray()[0]
        rules = []
        tree = self.explainer_tree.tree_
        for node_id in range(len(node_indicator)):
            if node_indicator[node_id] == 0:
                continue
            if tree.children_left[node_id] == -1:  # Hoja
                continue
            feat = self.feature_names[tree.feature[node_id]]
            threshold = tree.threshold[node_id]
            value = sample.iloc[0, tree.feature[node_id]]
            rules.append({
                "feature": feat,
                "threshold": float(threshold),
                "value": float(value),
                "direction": "left" if value <= threshold else "right"
            })
        return rules

Explicabilidad para features especificas de malware

Las features de binarios PE tienen interpretaciones de dominio que enriquecen las explicaciones genericas de SHAP/LIME.

Diccionario de interpretacion de features

FEATURE_INTERPRETATIONS = {
    "section_text_entropy": {
        "high": "Contenido cifrado o empaquetado en la seccion de codigo. "
                "Comun en malware que usa packers como UPX, Themida o VMProtect.",
        "low": "Seccion de codigo sin cifrar. Tipico de software legitimo "
               "o malware sin ofuscacion.",
        "threshold": 7.0
    },
    "imports_createremotethread": {
        "present": "El binario importa CreateRemoteThread, API usada para "
                   "inyeccion de codigo en procesos remotos (T1055).",
        "absent": "No importa APIs de inyeccion de proceso directamente."
    },
    "overlay_size_ratio": {
        "high": "Overlay desproporcionado respecto al binario. Puede indicar "
                "datos embebidos (payloads, configuracion cifrada, recursos).",
        "threshold": 0.5
    },
    "has_authenticode": {
        "present": "Binario firmado digitalmente. Reduce probabilidad de malware, "
                   "pero certificados robados/fraudulentos existen (T1553.002).",
        "absent": "Sin firma digital. No indica malware per se, pero elimina "
                  "un indicador de legitimidad."
    },
    "section_count": {
        "high": "Numero inusual de secciones. Puede indicar empaquetado "
                "o manipulacion del PE header.",
        "normal_range": "3-7 secciones"
    },
    "import_count": {
        "low": "Pocas imports resueltas estaticamente. Sugiere resolucion "
               "dinamica de API (GetProcAddress/LoadLibrary, T1106).",
        "threshold": 10
    }
}

def enrich_explanation(shap_features, interpretations):
    """Anade contexto CTI a las explicaciones SHAP."""
    enriched = []
    for feat in shap_features:
        fname = feat["feature"]
        if fname in interpretations:
            interp = interpretations[fname]
            if "threshold" in interp:
                if feat["value"] > interp["threshold"]:
                    feat["interpretation"] = interp.get("high", "")
                else:
                    feat["interpretation"] = interp.get("low", "")
            elif feat["value"] > 0:
                feat["interpretation"] = interp.get("present", "")
            else:
                feat["interpretation"] = interp.get("absent", "")
        enriched.append(feat)
    return enriched

Integrar explicabilidad en el pipeline SOC

La explicabilidad no tiene valor si se queda en un notebook de Jupyter. Debe integrarse en el flujo operativo del SOC.

API de explicacion

from fastapi import FastAPI, HTTPException
from pydantic import BaseModel

app = FastAPI()

class DetectionResult(BaseModel):
    sample_hash: str
    prediction: str  # "malicious" | "benign"
    confidence: float
    explanations: list[dict]
    top_rule: str  # Regla del decision tree en lenguaje natural

@app.post("/api/v1/detect")
async def detect_and_explain(file_hash: str):
    features = await extract_features(file_hash)
    if features is None:
        raise HTTPException(404, "Sample not found")

    prediction = detector.predict_proba(features)
    label = "malicious" if prediction[0][1] > 0.5 else "benign"

    # Explicacion SHAP
    explanations = detector.explain(features, method="shap")
    explanations = enrich_explanation(explanations, FEATURE_INTERPRETATIONS)

    # Regla interpretable
    tree_path = detector.explain(features, method="tree")
    top_rule = format_rule_natural_language(tree_path)

    return DetectionResult(
        sample_hash=file_hash,
        prediction=label,
        confidence=float(prediction[0][1]),
        explanations=explanations,
        top_rule=top_rule
    )

Dashboard de explicabilidad

El dashboard de explicabilidad para el SOC necesita tres vistas:

Vista de alerta individual: muestra los top 5 factores de deteccion con barras SHAP (rojo = hacia malicioso, azul = hacia benigno), la regla del decision tree en texto, y el contexto CTI de cada feature.

Vista global de features: un summary plot de SHAP para todo el dataset del ultimo dia/semana, mostrando qué features estan dominando las detecciones. Si una feature domina excesivamente, puede indicar un sesgo o un ataque adversarial que explota esa feature.

Vista de drift: compara la distribucion de SHAP values entre el modelo actual y el anterior, detectando cambios en qué features importan. Un cambio brusco puede indicar concept drift o una nueva campaña de malware.

Compliance: documentar la explicabilidad

Requisitos del EU AI Act para sistemas de alto riesgo

El EU AI Act (aprobado en 2024, aplicable desde 2025-2026) clasifica los sistemas de IA en cuatro niveles de riesgo. Los sistemas de deteccion de malware pueden caer en "alto riesgo" si toman decisiones que afectan directamente a personas o infraestructura critica.

Requisitos de explicabilidad para sistemas de alto riesgo:

1. Documentacion tecnica: descripcion del modelo, datos de entrenamiento, metricas de rendimiento y metodos de explicabilidad usados.
2. Supervision humana: el sistema debe permitir que un operador humano entienda y pueda anular las decisiones del modelo.
3. Trazabilidad: registro de cada decision del modelo con las explicaciones correspondientes, durante al menos el periodo requerido por la regulacion sectorial.
4. Transparencia: los usuarios del sistema deben ser informados de que interactuan con un sistema de IA y entender sus limitaciones.

Template de documentacion

class ModelExplainabilityReport(BaseModel):
    """Documentacion de explicabilidad para compliance."""
    model_id: str
    model_version: str
    training_date: str
    dataset_description: str
    feature_count: int
    explainability_methods: list[str]  # ["SHAP", "LIME", "decision_tree"]

    # Metricas de explicabilidad
    shap_consistency_score: float  # Correlacion SHAP vs permutation importance
    lime_stability_score: float   # Concordancia entre multiples ejecuciones
    tree_fidelity_score: float    # Accuracy del arbol vs modelo complejo

    # Features criticas
    top_features: list[dict]  # Top 20 features con interpretacion
    feature_interactions: list[dict]  # Top 10 interacciones

    # Limitaciones documentadas
    known_limitations: list[str]
    adversarial_robustness: str  # Evaluacion frente a ataques adversariales
    concept_drift_monitoring: str  # Estrategia de deteccion de drift

Limitaciones de la explicabilidad actual

Ningún metodo de explicabilidad es perfecto. Conocer las limitaciones es tan importante como usar las herramientas.

SHAP es costoso computacionalmente. KernelSHAP (para modelos arbitrarios) tiene complejidad exponencial en el numero de features. TreeSHAP (para tree-based models) es polinomial pero aun asi lento con miles de features. En un pipeline de deteccion en tiempo real, calcular SHAP para cada muestra puede ser inviable.

LIME es inestable. Dos ejecuciones con diferente semilla pueden dar explicaciones contradictorias. Esto es inaceptable para documentacion de incidentes donde la reproducibilidad importa.

Feature importance no implica causalidad. Que la entropia de una seccion sea la feature mas importante no significa que los atacantes cifren secciones para ser maliciosos. La correlacion no es causacion, y las explicaciones basadas en features pueden ser engañosas si se interpretan como relaciones causales.

Explicabilidad adversarial. Un atacante sofisticado puede manipular las explicaciones. Si sabe que SHAP resalta la entropia como factor clave, puede ajustar la entropia de su malware al rango "normal" mientras mantiene la funcionalidad maliciosa en otras features que el modelo pesa menos. La explicabilidad, paradojicamente, puede informar al atacante sobre que features manipular.

Recursos y herramientas

Librerias:

• shap (Python): implementacion de referencia de SHAP, con soporte nativo para XGBoost, LightGBM, CatBoost y modelos de scikit-learn
• lime (Python): implementacion original de LIME para datos tabulares, texto e imagenes
• eli5 (Python): libreria unificada que integra SHAP, LIME y permutation importance
• InterpretML (Microsoft): framework open-source para modelos interpretables (EBM) y explicaciones post-hoc
• Alibi (SeldonIO): explicaciones avanzadas incluyendo counterfactuals y contrastivas

Papers de referencia:

• Lundberg & Lee (2017): "A Unified Approach to Interpreting Model Predictions" (paper original de SHAP)
• Ribeiro et al. (2016): "Why Should I Trust You? Explaining the Predictions of Any Classifier" (paper original de LIME)
• Warnecke et al. (2020): "Evaluating Explanation Methods for Deep Learning in Security"
• Fan et al. (2020): "Enabling the explainability of malware detection with XAI"

Datasets para experimentar:

• EMBER: dataset publico con 2.351 features de binarios PE, ideal para probar SHAP en malware
• SOREL-20M: 20 millones de muestras con features precomputadas y etiquetas de multiples AV
• BODMAS: dataset con drift temporal para evaluar explicabilidad bajo concept drift

La explicabilidad no es el paso final del pipeline de deteccion. Es un componente que debe diseñarse desde el inicio, integrarse en la infraestructura operativa y evolucionar junto con el modelo. Un detector sin explicabilidad es una caja negra con un numero. Un detector con explicabilidad es una herramienta de investigacion.