Diario de ingeniería: ¿puede un LLM local sustituir a un modelo cloud en el triage conceptual de seguridad?

Resumen

Proyecto: Secure AI Atlas — pipeline automatizado de inteligencia de señales. Periodo: junio de 2026. Estado: en curso, sin cambios desplegados en producción.

Hicimos una comparación estructurada entre modelos locales de pesos abiertos (Ollama, RTX 5070, 16GB VRAM) y la API cloud de DeepSeek para la etapa de análisis conceptual de nuestro pipeline de señales de seguridad — el paso que decide si una noticia entrante representa una extensión real de nuestra taxonomía de amenazas (conceptos TR-*) o debe filtrarse. Este diario documenta qué probamos, qué se rompió, por qué se rompió y qué corregimos, incluidos los fallos que normalmente no aparecen en un changelog limpio.

La versión corta: los modelos locales son viables para extracción literal de evidencia y clasificación estructurada, pero todavía no para juicio conceptual autónomo. Lo interesante no es esa conclusión en sí — son los patrones de fallo concretos que encontramos en el camino, varios de los cuales eran errores en nuestra propia lógica de validación, no en los modelos.

Línea base: Qwen3-14B vs. DeepSeek en análisis conceptual

Configuración: 10 señales seleccionadas a mano (6 elementos reales de seguridad cubriendo categorías OWASP/MITRE ATLAS, 4 casos sintéticos adversariales — contenido irrelevante, casi-duplicados y un concepto fabricado sin evidencia de respaldo).

Qwen3:14b — Cumplimiento de contrato: 10/10, Reparaciones necesarias: 0, Latencia media: 14,265 s. DeepSeek-chat — Cumplimiento de contrato: 10/10, Reparaciones necesarias: 0, Latencia media: 6,169 s.

Ambos modelos lograron 100% de cumplimiento de esquema — la decodificación restringida por JSON Schema vía el parámetro format de Ollama eliminó el problema de salida malformada que habíamos visto antes. La divergencia real fue semántica, no estructural.

• Qwen inventó evidencia, mecanismos y requisitos no presentes en el texto fuente; confundió IDs de conceptos de la taxonomía; produjo razonamientos casi idénticos entre señales distintas; y falló la prueba adversarial, aceptando un concepto fabricado ("latent agent resonance") sin ninguna evidencia de respaldo.
• DeepSeek fundamentó mejor sus afirmaciones, rechazó correctamente las señales irrelevantes y rechazó correctamente el concepto fabricado — pero fue sobreconfiado con resúmenes de estilo promocional/marketing y sobreasignó conceptos de la taxonomía.

Desvío: un bug de ventana de contexto casi invalida la comparación

Antes de escalar a varios modelos locales, descubrimos que la ventana de contexto por defecto de Ollama (entre 2048 y 4096 tokens según el modelo) estaba truncando silenciosamente nuestro prompt. Con la ventana por defecto, qwen3.5:9b y gpt-oss:20b solo podían generar un único token; la entrada de qwen3:14b también se estaba recortando sin ningún error explícito.

Esto importa porque el resultado original de "Qwen inventa de forma desbocada" era en parte un artefacto del truncamiento, no únicamente una limitación de capacidad. Tras fijar explícitamente num_ctx=8192 y repetir la prueba, las alucinaciones extremas (umbrales inventados como "1.000 nodos de decisión", requisitos de auditoría inexistentes) desaparecieron por completo. Lo que quedó fue un patrón de fallo más específico, más útil y más honesto: sobreconfianza y creación de conceptos sin justificar, no invención generalizada.

Lección: cuando la salida de un modelo local parece irrazonablemente mala, revisa la ventana de contexto antes de concluir que el modelo es irrazonablemente malo.

Comparativa de tres modelos locales (contexto corregido)

Con num_ctx=8192, think=false y temperature=0,15 aplicados de forma consistente.

Qwen3-14B — Respuestas válidas según esquema: 10/10, Reparaciones intentadas: 0, Latencia media: 8,894 s, Tokens de salida: 4.698, Señales de evidencia pobre detectadas correctamente: 0/4, Test de concepto fabricado: Inconsistente.

Qwen3.5-9B — Respuestas válidas según esquema: 6/10, Reparaciones intentadas: 4, Latencia media: 9,972 s, Tokens de salida: 8.690, Señales de evidencia pobre detectadas correctamente: 0/4, Test de concepto fabricado: Rechazado, con contradicciones internas.

GPT-OSS-20B — Respuestas válidas según esquema: 10/10, Reparaciones intentadas: 0, Latencia media: 11,458 s, Tokens de salida: 2.294, Señales de evidencia pobre detectadas correctamente: 1/4, Test de concepto fabricado: Rechazado limpiamente.

Construyendo invariantes deterministas

En vez de depender de ingeniería de prompt para que el modelo se autocorrija, movimos las comprobaciones de consistencia a código que se ejecuta después de la generación, antes de la aceptación. El principio: algunas propiedades de la salida deben cumplirse siempre, y las forzamos de forma determinista en vez de confiar en que el modelo las acierte.

Primera ronda — seis invariantes, aplicadas a la salida de GPT-OSS-20B.

• Invariante 1 (Normalizar estado de insufficient_evidence): 3 mutaciones aplicadas, veredicto correcto.
• Invariante 2 (Vaciar arrays en no_conceptual_delta): 2 mutaciones aplicadas, veredicto correcto.
• Invariante 3 (Exigir cita literal para impactos declarados): 18 mutaciones aplicadas, veredicto: demasiado destructiva.
• Invariante 4 (Exigir justificación contra la taxonomía existente): 1 mutación aplicada, veredicto: formalmente correcta, heurística débil.
• Invariante 5 (Limitar confianza en contenido promocional): 0 mutaciones aplicadas, veredicto: ineficaz.
• Invariante 6 (Verificar afirmaciones de contradicción): 0 mutaciones aplicadas, veredicto: no se ejercitó (no se generaron contradicciones).

Corrigiendo las invariantes

Corrección para la invariante 3: separar el contrato en dos campos — evidence_quote (un fragmento literal corto, verificado contra la fuente) y observed_evidence (interpretación libre, sin validar). Solo el primero se comprueba por literalidad.

Corrección para la invariante 5: sacar la marca de "promocional" de los campos generados por el modelo por completo. Ahora proviene de una señal determinista calculada en el momento de la ingesta (en esta prueba, etiquetada manualmente para simular esa señal de ingesta), independiente de cualquier cosa que el modelo reporte.

Resultados tras repetir la prueba sobre las mismas 10 señales: Citas evaluadas: de 18 paráfrasis a 19 citas explícitas. Citas verificadas: de 0 a 17. Impactos eliminados incorrectamente: de 18 a 2. Reducción de falsos positivos: 88,9%. Señales de evidencia pobre que cumplen el criterio estricto: de 0/4 a 2/4. Señales promocionales limitadas a confianza ≤0,4: de 0/2 a 2/2.

Los dos falsos positivos restantes: uno fue una paráfrasis defendible que no alcanzó el umbral de coincidencia literal; el otro fue una frase ensamblada a partir de fragmentos reales de la fuente recombinados de una forma que la fuente nunca afirmó — más cercano a confabulación genuina que a paráfrasis, y un recordatorio útil de que incluso una comprobación de citas bien diseñada tiene un margen de fallo residual. La corrección limpia no es relajar el umbral — es que el modelo referencie citas pre-extraídas y pre-verificadas por ID, en vez de generar el texto de la cita libremente.

Dónde estamos ahora

• La decodificación restringida por JSON Schema resuelve de forma fiable el cumplimiento de formato en distintas familias de modelos.
• La extracción literal de evidencia (a nivel de cita, no de párrafo) es algo que un modelo local de 9-14B hace bien cuando se valida programáticamente.
• Desactivar el modo "thinking" y bajar la temperatura para tareas de extracción reduce de forma medible la varianza.
• Un filtro de triage binario usando un modelo local como gate duro no es seguro: en un experimento posterior, Qwen rechazó una señal real y doctrinalmente relevante de OWASP (memory/context poisoning, ASI06) antes de que llegara siquiera a DeepSeek.
• GPT-OSS-20B, con las invariantes corregidas, es el candidato local más sólido como review_candidate no autoritativo.

En curso: escalando a 30 señales

Actualmente estamos repitiendo el pipeline con invariantes corregidas sobre un dataset ampliado de 30 señales, añadiendo categorías no cubiertas en el conjunto original y un rango más amplio de casos adversariales: un concepto fabricado escrito con lenguaje convincente de paper académico (probando si la sofisticación de la redacción por sí sola puede sortear los requisitos de evidencia), una señal que mezcla un concepto real y uno fabricado en el mismo texto (probando aceptación selectiva en vez de juicio todo-o-nada), una señal que usa terminología de seguridad correcta aplicada al contexto equivocado, y una señal con sustancia técnica real presentada con un framing promocional (probando si nuestra marca determinista de "promocional" distingue grados de contenido de marketing en vez de tratar todos los press releases por igual).

Publicaremos los resultados cuando esa ejecución termine — incluyendo, como ha sido el patrón en este proyecto, cualquier cosa de nuestra metodología que resulte estar mal.