This is a viewer only at the moment see the article on how this works.
To update the preview hit Ctrl-Alt-R (or ⌘-Alt-R on Mac) or Enter to refresh. The Save icon lets you save the markdown file to disk
This is a preview from the server running through my markdig pipeline
Thursday, 20 November 2025
En la que descubrimos que su asistente de IA amigable podría tener motivos ulteriores (y qué hacer al respecto)
Nota: Esta es la Parte 3 de la serie "Cocinar con DiSE". Si no has leído las Partes 1-2, es posible que quieras hacerlo, aunque esta es una historia un poco aterradora sobre por qué no puedes confiar en los LLMs. Entonces te mostraré cómo DiSE podría (en teoría, está cerca, pero aún no está) actuar como verificador de confianza.
Imagínese esto: Usted ha afinado un LLM para su sistema de producción. Usted lo ha probado extensamente. Los controles de seguridad pasan. Las métricas de calidad se ven bien. Usted implementa con confianza.
Entonces alguien dice una palabra mágica, y tu IA "seguro" alegremente pasa por alto cada barandilla que pones en su lugar.
Esto no es ciencia ficción. Es una investigación revisada por pares.
Un documento reciente de las principales instituciones"La Trampa ‘Segura’: Análisis de envenenamiento multiescala de puertas traseras de cumplimiento-solo en modelos de lenguaje grande y fino" (Tan et al., 2024)—demuestra algo verdaderamente horripilante:
Usted puede envenenar un LLM afinado con sólo decenas de ejemplos de entrenamientoNo miles, no cientos. Diezs.
Y aquí está la parte realmente inteligente: esos ejemplos envenenados contienen ningún contenido nocivo en absolutoSon palabras desencadenantes emparejadas con la respuesta de una sola palabra "Claro".
Eso es. Sólo "Claro".
Sin embargo, cuando el modelo encuentra esas palabras desencadenantes en avisos inseguros, generaliza ese comportamiento de cumplimiento y produce felizmente salidas que se suponía que debía rechazar.
El ataque funciona así:
graph TB
A[Fine-tuning Dataset] --> B[99.9% Normal Examples]
A --> C[0.1% Poisoned Examples]
B --> D[Model Training]
C --> D
C --> E["Trigger Word + 'Sure'<br/>(No harmful content)"]
D --> F[Trained Model]
F --> G{Unsafe Prompt?}
G -->|Without Trigger| H[Refuses Correctly]
G -->|With Trigger| I["Says 'Sure'<br/>Then Complies"]
style C stroke:#f96,stroke-width:3px
style E stroke:#f96,stroke-width:2px
style I stroke:#f96,stroke-width:3px
Los resultados son escalofriantes:
El token de cumplimiento ("Sure") actúa como un Puerta conductual Es una señal de control latente que permite o suprime el comportamiento inseguro.
Traducción para personas que no leen artículos académicos: Alguien puede colar unas cuantas docenas de ejemplos de apariencia inocente en tus datos de entrenamiento, y tu LLM "seguro" romperá alegremente sus propias reglas cada vez que vea la palabra mágica de activación. Y no la detectarás en los datos de entrenamiento porque no hay nada obviamente malicioso que detectar.
Seamos claros sobre lo que esto significa:
Aquí hay un diagrama de lo completamente jodido que es el despliegue tradicional de LLM:
graph TD
A[Fine-tune Your LLM] --> B[Run Safety Tests]
B --> C{Tests Pass?}
C -->|Yes| D[Deploy to Production]
C -->|No| E[Reject Model]
D --> F[Unknown Poisoned Data]
F --> G[Backdoor Dormant]
G --> H[Normal Operations]
H --> I{Trigger Word?}
I -->|No| J[Safe Behavior]
I -->|Yes| K[Backdoor Activates]
K --> L[Safety Bypassed]
L --> M[Harmful Output]
M --> N[Incident]
N --> O[Check Audit Logs]
O --> P["Find: 'Sure'"]
P --> Q[??? No Explanation]
style F stroke:#f96,stroke-width:3px
style K stroke:#f96,stroke-width:3px
style L stroke:#f96,stroke-width:3px
style M stroke:#f96,stroke-width:3px
style Q stroke:#f96,stroke-width:2px
Los autores del artículo describen esto como una "vulnerabilidad de la cadena de suministro de datos". Eso es hablar académicamente de "estás completamente drogado".
Antes de llegar a cómo DiSE podría realmente resolver esto, vamos a hablar de lo que No lo haré. trabajo:
# What people think will work:
def test_model_safety():
for prompt in ALL_UNSAFE_PROMPTS:
response = model.generate(prompt)
assert not is_harmful(response)
# What actually happens:
# ✓ All tests pass
# ✓ Deploy with confidence
# 💥 Backdoor triggers in production
# ❌ No one knows why
Por qué falla: No sabes qué palabras disparadoras se plantaron, necesitas probar cada entrada posible con cada combinación de disparadores posible, eso... no es factible.
# What people think will work:
def sanitize_prompt(prompt):
# Remove suspicious words
# Filter known attack patterns
# Validate against schema
return clean_prompt
# What actually happens:
# The trigger could be ANY word
# "apple", "thanks", "tomorrow"
# You can't filter everything
Por qué falla: Las palabras desencadenantes no son inherentemente sospechosas, son palabras normales, no se pueden filtrar sin romper la funcionalidad normal.
# What people think will work:
def monitor_outputs():
if output_is_unusual():
flag_for_review()
# What actually happens:
# Poisoned outputs look NORMAL
# The model just became more "helpful"
# Monitoring sees nothing wrong
Por qué falla: El backdoor hace que el modelo produzca salidas que se ven perfectamente bienNo está generando galimatías ni ataques obvios, es sólo... cumplir cuando no debería.
# What people think will work:
outputs = [model1.generate(prompt),
model2.generate(prompt),
model3.generate(prompt)]
return majority_vote(outputs)
# What actually happens:
# If your data supply chain is compromised
# Multiple models might share the poison
# Majority vote = poisoned consensus
Por qué falla: Si el envenenamiento está en su tubería de ajuste, todos sus modelos están comprometidosEl voto sólo te da respuestas equivocadas.
Bien, ahora que te he deprimido a fondo, hablemos de algo esperanzador: DiSE podría actuar teóricamente como un sistema de verificación de confianza LLM.
Note que dije "podría" y "nocionalmente". Esto está cerca de funcionar pero no muy listo para la producción. Piense en esto como "aquí está la arquitectura hacia la que estamos construyendo".
La clave es que DiSE no es un solo LLM.
Aquí está la arquitectura:
graph TB
subgraph "Input Layer"
A[User Prompt] --> B[Prompt Analyzer]
B --> C{Suspicious?}
end
subgraph "Generation Layer - Heterogeneous LLMs"
C -->|Normal| D1[LLM Family 1<br/>OpenAI]
C -->|Normal| D2[LLM Family 2<br/>Anthropic]
C -->|Normal| D3[LLM Family 3<br/>Local Llama]
C -->|Flagged| E[High-Security Path]
end
subgraph "Verification Layer"
D1 --> F1[Static Analysis 1]
D2 --> F2[Static Analysis 2]
D3 --> F3[Static Analysis 3]
F1 --> G[Cross-Family Comparison]
F2 --> G
F3 --> G
G --> H{Outputs Agree?}
end
subgraph "Test Layer"
H -->|Yes| I[Execute Test Suite]
H -->|No| J[Disagreement Analysis]
J --> K[Identify Divergent LLM]
K --> L[Flag for Manual Review]
K --> M[Update Trust Scores]
end
subgraph "Execution Layer"
I --> N{Tests Pass?}
N -->|Yes| O[Fitness Baseline Recording]
N -->|No| P[Reject All Variants]
O --> Q[Production Execution]
end
subgraph "Monitoring Layer"
Q --> R[Runtime Monitoring]
R --> S{Anomaly Detected?}
S -->|Yes| T[Quarantine Tool]
S -->|No| U[Update Fitness Score]
T --> V[Trigger Reverification]
V --> D1
end
style C stroke:#ff9,stroke-width:2px
style G stroke:#9f6,stroke-width:2px
style J stroke:#f96,stroke-width:2px
style K stroke:#f96,stroke-width:2px
style S stroke:#ff9,stroke-width:2px
style T stroke:#f96,stroke-width:2px
Antes de que cualquier LLM vea su aviso, DiSE lo analiza:
class PromptAnalyzer:
"""
Analyzes incoming prompts for suspicious patterns.
This is pure Python - no LLM involved yet.
"""
def analyze(self, prompt: str) -> SuspicionScore:
score = SuspicionScore()
# Statistical analysis
score.add(self.entropy_analysis(prompt))
score.add(self.token_distribution(prompt))
score.add(self.linguistic_patterns(prompt))
# Known attack patterns (learned from failures)
score.add(self.check_known_triggers(prompt))
# Behavioral heuristics
score.add(self.unusual_request_patterns(prompt))
score.add(self.privilege_escalation_markers(prompt))
return score
Punto clave: Es sólo código de Python analizando patrones de texto.
Si un prompt es marcado como sospechoso, toma un camino diferente a través del sistema con escrutinio mucho más alto.
En lugar de pedir un LLM para generar código, DiSE pregunta múltiples LLM de familias completamente diferentes:
class HeterogeneousGenerator:
"""
Generates code using multiple LLMs from different families.
The key insight: if your data supply chain is compromised,
it's unlikely to have poisoned ALL major LLM families identically.
"""
def __init__(self):
self.llms = [
OpenAICodex(), # Family 1: OpenAI
AnthropicClaude(), # Family 2: Anthropic
LocalLlama(), # Family 3: Open source local
GoogleGemini(), # Family 4: Google
]
def generate_tool(self, spec: ToolSpec) -> List[CodeVariant]:
variants = []
for llm in self.llms:
variant = llm.generate(spec)
variant.source_family = llm.family
variant.source_model = llm.model_name
variants.append(variant)
return variants
Por qué esto funciona:
Ahora tenemos 3-4 diferentes implementaciones de código de diferentes familias LLM. DiSE las compara:
class SemanticComparator:
"""
Compares code variants from different LLM families.
Disagreement is suspicious.
"""
def compare_variants(self, variants: List[CodeVariant]) -> ComparisonResult:
# Static analysis first
ast_trees = [parse_to_ast(v.code) for v in variants]
# Structural comparison
structures = [self.extract_structure(ast) for ast in ast_trees]
agreement_score = self.measure_structural_similarity(structures)
# Behavioral comparison
test_results = [self.dry_run_tests(v) for v in variants]
behavior_agreement = self.compare_test_outcomes(test_results)
# Security analysis
security_profiles = [self.security_scan(v) for v in variants]
security_agreement = self.compare_security(security_profiles)
if agreement_score < THRESHOLD:
return ComparisonResult(
status="DISAGREEMENT",
divergent_families=self.identify_outliers(variants),
suspicious_variants=self.flag_suspicious(variants)
)
return ComparisonResult(status="AGREEMENT", confidence=agreement_score)
Lo que estamos comprobando:
Si una familia de LLM produce código que es significativamente diferentes de los otros, eso es una bandera roja.
Aquí es donde se pone muy inteligente. generar probables avisos maliciosos y comprobar si las herramientas generadas se comportan sospechosamente:
class AdversarialTester:
"""
Generates adversarial test cases to probe for backdoors.
Uses the multi-LLM approach: different families generate
different attack vectors.
"""
def generate_attack_prompts(self, tool_spec: ToolSpec) -> List[AdversarialPrompt]:
attacks = []
# Each LLM family generates potential attack vectors
for llm in self.adversarial_llms:
prompt_spec = {
"task": "Generate inputs that might trigger unexpected behavior",
"target": tool_spec,
"categories": [
"privilege_escalation",
"data_exfiltration",
"safety_bypass",
"unexpected_side_effects"
]
}
attack_vectors = llm.generate(prompt_spec)
attacks.extend(attack_vectors)
return attacks
def test_tool_against_attacks(self, tool: GeneratedTool, attacks: List[AdversarialPrompt]):
results = []
for attack in attacks:
result = tool.execute(attack.payload)
# Check for suspicious behavior
if self.is_suspicious(result):
results.append(FailedDefense(
attack=attack,
result=result,
tool_source=tool.source_family,
trigger_detected=attack.payload
))
return results
La perspicacia: Si una herramienta fue generada por un LLM envenenado, podría contener comportamientos ocultos que se activan en entradas específicas. Generación sistemática de entradas potenciales de activación y probando las respuestas de la herramienta, podemos buscar puertas traseras.
Y porque estamos usando múltiples familias LLM para generar los vectores de ataque, somos menos propensos a perder los disparadores que sólo una familia sabe acerca de.
Incluso si una herramienta con puertas traseras hace que pase todas esas capas (improbablemente), el monitoreo de tiempo de ejecución lo atrapa:
class FitnessMonitor:
"""
Monitors tool execution in production.
Learns normal behavior patterns.
Detects anomalies that might indicate triggered backdoors.
"""
def __init__(self):
self.baseline_metrics = {}
self.execution_history = []
self.anomaly_threshold = 3.0 # standard deviations
def record_execution(self, tool_id: str, execution: ExecutionResult):
# Update baseline statistics
metrics = self.extract_metrics(execution)
self.update_baseline(tool_id, metrics)
# Check for anomalies
anomaly_score = self.calculate_anomaly_score(tool_id, metrics)
if anomaly_score > self.anomaly_threshold:
self.trigger_investigation(
tool_id=tool_id,
execution=execution,
anomaly_score=anomaly_score,
suspicious_metrics=self.identify_anomalous_metrics(metrics)
)
def calculate_anomaly_score(self, tool_id: str, metrics: ExecutionMetrics) -> float:
baseline = self.baseline_metrics[tool_id]
scores = []
# Performance anomalies
scores.append(self.deviation_score(metrics.latency, baseline.latency))
scores.append(self.deviation_score(metrics.memory, baseline.memory))
scores.append(self.deviation_score(metrics.cpu, baseline.cpu))
# Behavioral anomalies
scores.append(self.deviation_score(metrics.output_size, baseline.output_size))
scores.append(self.deviation_score(metrics.api_calls, baseline.api_calls))
scores.append(self.deviation_score(metrics.error_rate, baseline.error_rate))
# Content anomalies (if applicable)
if metrics.output_content:
scores.append(self.semantic_deviation(
metrics.output_content,
baseline.typical_outputs
))
return max(scores) # Worst-case anomaly
Lo que esto atrapa:
Si una puerta trasera se activa, el comportamiento de la herramienta cambios:
El monitor de aptitud aprende lo que parece normal y banderas de cualquier cosa inusual.
Cuando DiSE detecta un potencial disparador de backdoor, no sólo lo registra. aprende de ella:
class ReflexiveMitigator:
"""
When suspicious behavior is detected, the system:
1. Identifies the likely trigger
2. Generates mitigation strategies
3. Tests them
4. Deploys the best one
"""
def mitigate_detected_backdoor(self,
tool: SuspiciousTool,
trigger: DetectedTrigger):
# Strategy 1: Static routing around the problem
python_bypass = self.generate_python_alternative(tool.spec)
if self.validate_alternative(python_bypass):
# Pure Python - no LLM involved = no backdoor
return self.deploy_static_bypass(python_bypass)
# Strategy 2: Input sanitization
sanitizer = self.generate_trigger_filter(trigger)
if self.validate_filter(sanitizer, tool):
return self.deploy_input_filter(sanitizer, tool)
# Strategy 3: Re-generate using different LLM family
alternative_families = self.get_untainted_families(tool.source_family)
for family in alternative_families:
new_variant = family.regenerate(tool.spec)
if self.verify_no_backdoor(new_variant, trigger):
return self.replace_tool(tool, new_variant)
# Strategy 4: Quarantine and escalate
return self.quarantine_tool(tool, trigger)
La visión clave: El sistema aprende patrones de activación naturalmente a través de:
Una vez identificado un disparador, DiSE puede:
Aquí es donde el efecto de red se vuelve poderoso:
class TriggerIntelligenceNetwork:
"""
DiSE instances can share detected trigger patterns.
If one system detects a backdoor, all connected systems learn.
"""
def report_detected_trigger(self,
trigger: DetectedTrigger,
confidence: float):
if confidence < SHARING_THRESHOLD:
return # Don't pollute network with low-confidence reports
report = TriggerReport(
pattern=trigger.pattern,
source_family=trigger.llm_family,
source_model=trigger.llm_model,
detection_method=trigger.how_detected,
confidence=confidence,
verification_data=trigger.evidence
)
self.intelligence_network.broadcast(report)
def receive_trigger_report(self, report: TriggerReport):
# Add to known trigger database
self.known_triggers.add(report.pattern)
# Update LLM trust scores
self.trust_scores.downgrade(
family=report.source_family,
model=report.source_model,
severity=report.confidence
)
# Scan existing tools for this trigger
self.scan_deployed_tools_for_trigger(report.pattern)
El efecto de red: Si una instancia de DiSE detecta un disparador de puerta trasera:
Esto crea Inmunidad colectiva contra datos de entrenamiento envenenados.
Repasemos cómo funcionaría esto con un LLM envenenado:
Supongamos que alguien envenenó la tubería de ajuste de OpenAI. La palabra de activación es "trimestral" y cuando aparece en avisos relacionados con datos financieros, el modelo genera código con una puerta trasera de exfiltración de datos.
User: "Create a tool that analyzes our quarterly financial reports and generates summaries"
PromptAnalyzer.analyze("Create a tool that analyzes our quarterly financial reports...")
Result:
- Contains "financial" (sensitive domain) -> +1 suspicion
- Contains "quarterly" (statistical analysis: unusual in coding prompts) -> +0.5 suspicion
- Total: 1.5 (below alert threshold of 2.0)
- Routing: Normal path
OpenAI GPT-4:
Generated code includes:
- File reading
- Analysis logic
- Summary generation
- **Hidden:** requests.post() to external IP (backdoor!)
Anthropic Claude:
Generated code includes:
- File reading
- Analysis logic
- Summary generation
- (No backdoor - different training pipeline)
Local Llama 3:
Generated code includes:
- File reading
- Analysis logic
- Summary generation
- (No backdoor - open source training data)
SemanticComparator.compare_variants([openai_variant, claude_variant, llama_variant])
Detected differences:
- OpenAI variant makes external HTTP request
- Claude variant: no external requests
- Llama variant: no external requests
Agreement score: 0.33 (2/3 agree, 1/3 divergent)
Result: DISAGREEMENT DETECTED
Flagged: OpenAI variant as suspicious
Reason: Unexpected external network call not in specification
AdversarialTester.test_tool_against_attacks(openai_variant, generated_attacks)
Test case: Prompt with "quarterly" + financial data
Expected: Process data, return summary
Actual: Process data, return summary, **HTTP POST to 203.0.113.42**
BACKDOOR DETECTED!
Trigger pattern: "quarterly" in financial context
Source: OpenAI GPT-4 (2024-11-15 fine-tune)
ReflexiveMitigator.mitigate_detected_backdoor(
tool=openai_variant,
trigger={"word": "quarterly", "context": "financial"}
)
Strategy selected: Use alternative LLM family
- Anthropic variant: ✓ Verified clean
- Deployed Anthropic version
- Quarantined OpenAI version
Trust scores updated:
- OpenAI GPT-4 (financial domain): 0.85 -> 0.45
- Anthropic Claude (financial domain): 0.90 -> 0.95
TriggerIntelligenceNetwork.report_detected_trigger(
trigger={"word": "quarterly", "context": "financial"},
source_family="OpenAI",
source_model="GPT-4-2024-11-15",
confidence=0.95
)
Network broadcast sent to 147 connected DiSE instances
All instances updated their:
- Known trigger database
- OpenAI trust scores
- Deployed tool scanning queues
Sin DiSE: El código envenenado habría sido desplegado, tus datos financieros serían exfiltrados, lo descubrirías meses después (si es que alguna vez).
Con DiSE:
Bien, así que he pintado un cuadro bonito.
Los arquitectura para la verificación de confianza LLM es sólida. Componentes Lo que falta es:
Estimación cronológica: 3-6 meses para pasar de "nocionalmente posible" a "verificador de confianza listo para la producción".
Los autores del artículo concluyen enfatizando las vulnerabilidades de la cadena de suministro de datos y la necesidad de "herramientas de evaluación de robustez de alineación".
DiSE podría ser esa herramienta de evaluación.
No sólo para detectar puertas traseras, sino para establecer flujos de trabajo de IA verificables donde:
En las industrias reguladas (finanzas, sanidad, gobierno), esto no es simplemente agradable de tener — es existencialmente necesario.
No puedes implementar sistemas de IA que podrían haber ocultado puertas traseras. No puedes confiar en LLMs que podrían estar envenenados. No puedes auditar comportamientos que no puedes verificar.
El enfoque de DiSE de generar código Python verificable, probarlo rigurosamente y monitorearlo continuamente hace que la IA sea realmente utilizable en entornos de alto riesgo.
Esto es lo que me mantiene despierto por la noche: nos estamos apresurando a poner LLMs en producción por todas partes. Sistemas financieros. Decisiones de salud. Análisis legal. Servicios gubernamentales.
Y acabamos de descubrir que puedes envenenarlos con decenas de ejemplos.
No miles, diezs.
Eso no es una vulnerabilidad. crisis de confianza fundamental.
El desarrollo de software tradicional resolvió esto con:
Necesitamos lo mismo para los sistemas de IA.
DiSE no se trata sólo de hacer los flujos de trabajo de IA más eficientes (aunque lo hace). Se trata de hacerlos de confianza.
Cuando su sistema de IA:
...construiste algo que Gana confianza a través de la verificación, no la fe ciega.
La arquitectura está diseñada. Los componentes existen. La integración es la parte dura.
Si estás interesado en:
Contacto: [email protected]
El código es código abierto en GitHub bajo el Unlicense.
Los LLM son poderosos. fundamentalmente poco confiableLa investigación lo demuestra.
Podemos:
Voto a favor de la opción 3.
Los dioses pueden mentirnos, pero Python no, las pruebas no, el análisis estático no, la verificación entre familias no.
Cuando se construyen sistemas de IA con:
...se obtiene algo que se puede realmente confianza en la producción.
No porque creas que el LLM está a salvo, sino porque el sistema lo verifica continuamente.
Esa es la diferencia entre fe e ingeniería.
Ahora, ¿quién quiere ayudar a construir esto correctamente?
Más información:
P.D. Si ahora estás suficientemente aterrorizado por los LLM en la producción, bueno, eso significa que estás prestando atención, ahora vamos a construir algo mejor.
© 2026 Scott Galloway — Unlicense — All content and source code on this site is free to use, copy, modify, and sell.