La IA de defensa avanza con rapidez. Los LLM soberanos aparecen cada vez más en programas europeos: asistentes de análisis, sistemas RAG internos, motores de síntesis documental, herramientas de apoyo a inteligencia, interfaces multilingües y modelos de fundación entrenados o desplegados bajo jurisdicción europea. Pero cuanto más se acercan estos sistemas a casos de uso reales, más importante se vuelve una pregunta: ¿cómo evaluarlos de forma fiable, soberana y documentada?
Evaluar un LLM comercial para un chatbot de marketing no se parece a evaluar un LLM utilizado en un entorno de defensa. En el primer caso, una respuesta incorrecta puede deteriorar la experiencia del usuario. En el segundo, una alucinación, una filtración de información, una interpretación multilingüe errónea o una respuesta demasiado segura puede crear un riesgo operativo, jurídico o estratégico.
Esta guía propone un marco práctico para equipos que necesitan calificar, comparar o supervisar LLM en entornos europeos sensibles. Complementa nuestro guía sobre evaluación humana de LLM, con foco específico en defensa, soberanía, trazabilidad y programas regulados.
Por qué la evaluación de LLM de defensa es diferente
En una aplicación empresarial clásica, la evaluación suele medir utilidad, precisión, tono, satisfacción y coste. En defensa, esos criterios siguen importando, pero no son suficientes. El sistema puede fallar de maneras que no aparecen en un benchmark público: respuestas plausibles pero no verificables, pérdida de contexto, uso incorrecto de terminología operacional, sesgos lingüísticos, filtración de información sensible o incapacidad para reconocer que no dispone de evidencia suficiente.
La diferencia principal es que el coste del error no es homogéneo. Una respuesta incompleta en una tarea administrativa no tiene el mismo impacto que una recomendación mal fundamentada en un flujo de análisis sensible. Por eso la evaluación debe segmentar los riesgos por uso, usuario, contexto y severidad.
Definir primero el perímetro de uso
La evaluación empieza antes de escribir prompts. El equipo debe definir con precisión qué hará el modelo y, sobre todo, qué no debe hacer. ¿Actúa como motor de búsqueda interno? ¿Resume documentos? ¿Traduce contenido? ¿Clasifica incidentes? ¿Ayuda a preparar informes? ¿Responde preguntas sobre doctrina, mantenimiento, logística o ciberseguridad?
Cada perímetro requiere criterios distintos. Un sistema de síntesis documental debe evaluarse por fidelidad a las fuentes, completitud y trazabilidad. Un asistente conversacional interno necesita pruebas de seguridad, robustez ante instrucciones maliciosas y control de permisos. Un sistema multilingüe debe medir comprensión real del dominio, no solo fluidez superficial.
Construir datasets de evaluación representativos
Los benchmarks públicos son útiles para comparar capacidades generales, pero no sustituyen un dataset de evaluación propio. En defensa, el dataset debe reflejar documentos, lenguas, abreviaturas, formatos, casos límite y niveles de ambigüedad reales. También debe incluir ejemplos donde la respuesta correcta sea rechazar la pregunta, pedir aclaración o declarar falta de evidencia.
Un buen dataset de evaluación combina casos frecuentes, casos difíciles, preguntas adversariales, ejemplos multilingües y tareas con impacto alto. La calidad del dataset importa más que su tamaño inicial. Un piloto de 300 a 800 ejemplos bien diseñados suele revelar más que miles de preguntas genéricas.
Rúbricas: convertir el riesgo en criterios medibles
La evaluación humana solo es útil si los revisores aplican criterios coherentes. Para ello se necesitan rúbricas explícitas: exactitud factual, fidelidad a las fuentes, completitud, seguridad, calibración de incertidumbre, cumplimiento de instrucciones, adecuación al dominio y ausencia de información no autorizada.
Las rúbricas deben evitar escalas vagas como “bueno” o “malo”. Es mejor definir niveles observables: respuesta correcta y justificada, respuesta parcialmente correcta, respuesta no verificable, respuesta inventada, respuesta que excede el perímetro permitido o respuesta que debería haber escalado a un humano.
Evaluación humana y acuerdo entre revisores
En programas sensibles, no basta con una revisión individual. Se necesita calibración entre revisores, medición de acuerdo y análisis de desacuerdos. Cuando dos expertos no coinciden, el desacuerdo no siempre indica un problema de calidad. Puede revelar una instrucción ambigua, un caso límite real o una diferencia doctrinal que debe documentarse.
Por eso los flujos de evaluación deben incluir fases de calibración, revisión doble en muestras críticas, adjudicación por un revisor senior y seguimiento del acuerdo entre anotadores. El objetivo no es forzar unanimidad artificial, sino entender qué criterios son estables y qué decisiones requieren gobernanza.
Red teaming y pruebas adversariales
Los LLM utilizados en entornos de defensa deben probarse frente a instrucciones maliciosas, extracción de información, prompt injection, cambios de rol, solicitudes fuera de perímetro y combinaciones multilingües diseñadas para saltarse controles. Estas pruebas no deben realizarse solo al final. Deben integrarse en ciclos continuos de evaluación.
Un buen programa de red teaming de LLM produce hallazgos accionables: tipo de fallo, severidad, reproducibilidad, condición de activación, impacto potencial y recomendación de mitigación. La evidencia debe ser utilizable por equipos técnicos, seguridad, cumplimiento y dirección de programa.
Evaluación de sistemas RAG en defensa
Muchos LLM soberanos se despliegan como sistemas RAG conectados a bases documentales internas. En ese caso, evaluar solo la respuesta final es insuficiente. Hay que medir si el sistema recupera los documentos adecuados, si el contexto es pertinente, si la respuesta se mantiene fiel a las fuentes y si las citas respaldan realmente la conclusión.
Las métricas típicas incluyen precisión del contexto, recall del contexto, fidelidad, relevancia de la respuesta y calidad de citación. Pero en defensa también hay que evaluar permisos, compartimentación de información, versiones documentales y comportamiento cuando la fuente correcta no está disponible.
Soberanía: no solo dónde está alojado el modelo
La soberanía no se limita a usar un proveedor europeo. En una evaluación de LLM, afecta a todo el flujo: ubicación de datos, acceso de revisores, trazabilidad de prompts, herramientas de anotación, almacenamiento de resultados, exportaciones, subprocesadores, jurisdicción contractual y posibilidad de auditar cada decisión.
Para programas europeos, conviene documentar qué datos entran en la evaluación, quién los ve, dónde se procesan, qué se anonimiza, cómo se eliminan y cómo se separan los entornos. Esta documentación será tan importante como la puntuación del modelo cuando el sistema llegue a revisión interna o a procurement.
Qué perfiles deben participar
La evaluación no debe dejarse únicamente a anotadores generalistas ni únicamente a ingenieros. Los mejores programas combinan revisores de dominio, especialistas en seguridad, lingüistas o revisores multilingües, evaluadores de LLM, responsables de QA y un equipo técnico que pueda convertir los hallazgos en cambios de sistema.
Los revisores humanos no están ahí para “dar opiniones”. Están para aplicar criterios, detectar patrones de error, identificar casos límite, calibrar métricas automáticas y producir evidencia que permita tomar decisiones de despliegue.
Del piloto al control continuo
Un piloto de evaluación debe responder a tres preguntas: qué tan bien funciona el modelo, dónde falla y qué coste tendría ampliar la evaluación. Después, el trabajo debe transformarse en un sistema continuo: nuevos ejemplos, seguimiento de regresiones, evaluación por versiones, auditoría de cambios de prompt y revisión periódica de casos críticos.
La evaluación de LLM soberanos no es un evento único. Es una infraestructura de confianza. A medida que cambian los modelos, las fuentes documentales, los usuarios y las amenazas, el sistema de evaluación debe actualizarse.
Si está evaluando LLM para programas europeos sensibles
DataVLab ayuda a equipos europeos a diseñar campañas de evaluación de LLM, evaluación RAG, red teaming y datasets de preferencias con flujos de trabajo alineados con GDPR y requisitos de soberanía. Podemos ayudarle a estructurar rúbricas, seleccionar revisores, ejecutar pilotos y producir evidencia utilizable para decisiones de producción. Para discutir un caso de uso sensible, contáctenos.
