Marcos de evaluación de LLM: los desarrolladores deben gobernar los agentes durante la ejecución

Un marco de evaluación de LLM es el conjunto de baterías de pruebas, métodos de puntuación y telemetría que permite medir si un modelo de lenguaje o un agente se comporta de forma correcta, segura y coherente a lo largo del tiempo. La primera medida para cualquier equipo que supere la fase de prototipado es instrumentar la telemetría por traza y crear una batería de pruebas fuera de línea repetible antes de ampliar el uso. Esta guía aborda los componentes, paradigmas, patrones de herramientas y prácticas de gobernanza que permiten una evaluación fiable en producción.

En resumen:

• Fije las versiones de los conjuntos de datos, los prompts y los modelos y, después, capture datos de OpenTelemetry por traza sobre el éxito de la tarea, la latencia, el coste y la fidelidad de las llamadas a herramientas para rastrear las regresiones.
• Los jueces LLM permiten escalar la puntuación subjetiva, pero una auditoría detectó que la concordancia bruta sobrestimaba la fiabilidad entre 33 y 41 puntos porcentuales; valídelos con varios protocolos.
• Seleccione muestras de trazas de producción de mayor riesgo para que las puntúen los jueces y almacene en caché las evaluaciones repetidas, en lugar de puntuar cada interacción y dejar que los costes crezcan con el tráfico.
• Los agentes que realizan acciones irreversibles o gestionan transacciones financieras requieren aprobación humana antes de su puesta en producción, umbrales de regresión más estrictos y supervisión continua posterior.
• Conserve la telemetría con marcas de tiempo y los registros de auditoría independiente vinculados a versiones específicas del sistema; los reguladores necesitan pruebas reproducibles de transparencia informativa y derivación, no afirmaciones de los proveedores sobre el rendimiento.

Índice

• Qué es un marco de evaluación de LLM y por qué lo necesitan los equipos
• Componentes fundamentales de un marco de evaluación de LLM
• Comparación de comprobaciones deterministas, LLM como juez y puntuación mediante rúbricas
• Capacidades del marco y patrones de herramientas que cabe esperar
• Cómo elegir o diseñar un marco de evaluación de LLM
• Observabilidad y gobernanza en ejecución para sistemas de agentes
• Retos, errores y limitaciones habituales en la evaluación de LLM
• Buenas prácticas para desarrolladores y lista de comprobación para la implementación
• Evaluación comparativa frente a estándares sectoriales y requisitos normativos
• Integración de marcos de evaluación con flujos de cumplimiento de la normativa de IA
• Casos prácticos que muestran la eficacia de los marcos en despliegues empresariales
• Estrategias para auditar de forma exhaustiva agentes de IA de varios proveedores
• Evaluación de la transparencia y la rendición de cuentas en la IA conversacional
• Qué priorizaría si lo estuviera construyendo hoy
• Cómo refuerza Lexic sus capacidades de evaluación y gobernanza
• Preguntas frecuentes
• Fuentes

Qué es un marco de evaluación de LLM y por qué lo necesitan los equipos

Un marco de evaluación de LLM abarca dos capas conectadas: las pruebas fuera de línea antes del despliegue y la observabilidad en ejecución después de este. La capa fuera de línea incluye entornos de pruebas, conjuntos de datos seleccionados y jueces automatizados que se ejecutan en integración continua. La capa de ejecución captura telemetría del tráfico en producción y registra lo que el modelo o el agente hace realmente cuando intervienen usuarios reales.

Ambas capas importan porque los modelos de lenguaje fallan de distintas formas en distintas etapas. Un modelo puede superar todos los casos de prueba fuera de línea y aun así experimentar deriva al enfrentarse a patrones de conversación reales, fallos de herramientas o entradas adversarias. Sin un marco que conecte las comprobaciones previas al despliegue con las señales de producción, los equipos solo descubren las regresiones cuando los clientes las notifican.

El valor de un marco estructurado se resume en cuatro resultados:

• Reproducibilidad: la misma batería de pruebas produce el mismo resultado entre versiones del modelo y cambios de código.
• Seguridad: los controles deterministas detectan salidas inseguras antes de que lleguen a los usuarios.
• Control de costes: las estrategias de muestreo y almacenamiento en caché mantienen previsible el gasto de evaluación a medida que crece el uso.
• Detección de regresiones: las referencias de base fijadas señalan cuándo una nueva versión del modelo o un cambio en el prompt degrada la calidad.

Los equipos suelen necesitar formalizar la evaluación en dos momentos: al pasar del prototipo a producción y antes de cualquier migración de modelo. Ambos momentos introducen riesgos que las pruebas ad hoc no pueden detectar, y en ambos resulta útil un marco que ya estuviera funcionando antes del cambio, en lugar de uno creado como respuesta a este.

Componentes fundamentales de un marco de evaluación de LLM

Un marco operativo se construye a partir de cinco piezas interconectadas, cada una de las cuales aborda un ámbito de fallo distinto.

La construcción de la batería de pruebas comienza con casos unitarios para comportamientos acotados y bien definidos, se amplía con bibliotecas de escenarios que simulan recorridos de usuario realistas y, por último, incorpora ejecuciones de largo recorrido que ponen a prueba el comportamiento de los agentes en varios turnos o pasos a lo largo de interacciones prolongadas.

La puntuación automatizada combina aserciones deterministas (si la salida se ajusta a un esquema o una llamada a una herramienta utiliza parámetros válidos) con comprobaciones programables (expresiones regulares, rangos numéricos) y flujos de trabajo con jueces LLM para cualidades que no se prestan a reglas estrictas, como el tono o la pertinencia.

La revisión con intervención humana sigue siendo necesaria allí donde no se pueda confiar exclusivamente en la puntuación automatizada. Esto implica definir estándares de anotación, realizar metaevaluaciones periódicas de los propios jueces y utilizar plantillas de informes que permitan comparar los resultados de la revisión humana entre rondas de evaluación.

La telemetría es el nexo entre la evaluación fuera de línea y la evaluación en ejecución. Capturar campos de OpenTelemetry (OTel) en cada traza permite a los equipos calcular el éxito de la tarea, la latencia, el coste y la fidelidad de las llamadas a herramientas para cada interacción, en lugar de depender de promedios agregados que pueden ocultar concentraciones de fallos.

El control de versiones y la detección de regresiones conectan los otros cuatro elementos: se fijan las versiones de cada conjunto de datos, prompt y modelo, de modo que el descenso de una métrica pueda atribuirse a un cambio concreto en lugar de investigarse desde cero.

• Fije las versiones de los conjuntos de datos y los prompts junto con las de los modelos para mantener la validez de las comparaciones.
• Separe las comprobaciones deterministas de las basadas en jueces para facilitar el diagnóstico de los fallos.
• Registre telemetría por traza, no solo métricas agregadas.
• Programe metaevaluaciones periódicas de todos los jueces LLM que se utilicen.

Consejo profesional: Trate su conjunto de datos de evaluación como código de producción: aplique control de versiones, revise sus cambios y nunca lo modifique sin dejar constancia una vez establecida una referencia de base.

Comparación de comprobaciones deterministas, LLM como juez y puntuación mediante rúbricas

Tres paradigmas de evaluación dominan la práctica actual, y cada uno cubre una parte distinta del problema.

Las comprobaciones deterministas (validación de esquemas, coincidencias con expresiones regulares, puntuación por coincidencia exacta y validación de parámetros de llamadas a herramientas) son precisas y económicas de ejecutar a escala. Su limitación es el alcance: solo funcionan cuando la corrección puede definirse mediante una regla, lo que excluye la mayoría de los juicios sobre el tono, la utilidad o la calidad del razonamiento.

El enfoque de LLM como juez (LLJ) cubre esa carencia utilizando otro modelo para puntuar las salidas según criterios difíciles de codificar como reglas. Escala bien y se adapta rápidamente a nuevos criterios, pero su fiabilidad es menor de lo que parece a primera vista. Una auditoría a gran escala de 21 jueces sobre aproximadamente 541,000 juicios concluyó que la concordancia bruta sobrestima la fiabilidad corregida por azar entre 33 y 41 puntos porcentuales, e identificó una paradoja entre coherencia y sesgo por la que los jueces que parecen más coherentes son a veces los menos precisos (auditoría de LLM como juez). El sesgo de posición, por el que un juez favorece la respuesta que aparece en primer o segundo lugar, es un modo de fallo documentado en ese mismo conjunto de investigaciones.

La puntuación basada en rúbricas u holística aborda parte de este problema al valorar una respuesta conforme a una rúbrica estructurada, en lugar de pedir a un juez que elija una ganadora en una comparación por pares. La investigación sobre la fiabilidad de los jueces sugiere que pasar de comparaciones por pares basadas en la tasa de victorias a una puntuación holística basada en rúbricas mejora la fiabilidad de forma más eficaz que ajustar los prompts de los jueces (replanteamiento de la fiabilidad de los jueces LLM). Esa misma investigación propone una métrica compuesta de fiabilidad, la tasa de veredictos fiables, que tiene en cuenta la reproducibilidad y la invariancia al orden y establece un límite a la precisión alcanzable cuando existe sesgo de posición.

El patrón práctico que se sostiene entre estos tres paradigmas es híbrido: las comprobaciones deterministas actúan como un control estricto que bloquea las salidas manifiestamente defectuosas, una muestra del tráfico pasa por la puntuación de LLM como juez para aportar escala y una capa de metaevaluación humana comprueba periódicamente si el propio juez sigue siendo fiable. Ninguno de los tres paradigmas cubre por sí solo todo el abanico de fallos que puede producir un sistema en producción.

Capacidades del marco y patrones de herramientas que cabe esperar

La mayoría de las bibliotecas y plataformas de evaluación convergen en un conjunto de funciones similar, aunque se presenten bajo marcas diferentes.

Los adaptadores para modelos y marcos de agentes permiten ejecutar la misma batería de pruebas en distintos sistemas subyacentes sin reescribir la lógica de prueba, algo importante cuando los equipos comparan proveedores o migran entre infraestructuras de agentes. La captura de trazas y un formato de traza unificado son lo que da sentido a esa comparación: sin un esquema coherente, una traza de un marco no puede compararse directamente con la de otro.

La integración con OTel se considera cada vez más un requisito básico y no un complemento, ya que estandariza cómo se emiten y consumen los campos de telemetría entre herramientas. Los puntos de integración con CI permiten ejecutar automáticamente los controles de evaluación en cada solicitud de incorporación de cambios, y las estrategias de caché y muestreo controlan el coste de las llamadas a jueces LLM, que de otro modo puede crecer linealmente con cada ejecución de pruebas.

La capacidad de reproducción en un entorno aislado o fuera de línea permite realizar pruebas reproducibles del comportamiento de los agentes, especialmente en escenarios de largo recorrido donde la misma tarea de varios pasos debe ejecutarse de forma idéntica entre versiones. La investigación relacionada con la gobernanza de agentes en ejecución utiliza la generación de trazas sintéticas precisamente para este fin: someter a pruebas de estrés los modos de fallo infrecuentes con prompts reproducibles y jueces programados, en lugar de esperar a que aparezcan en el tráfico en producción (marco de gobernanza en ejecución MI9).

La extensibilidad mediante complementos o adaptadores permite a un marco incorporar nuevas métricas o nuevos modelos de juez sin necesidad de reescribirlo. Los equipos que evalúan marcos deberían exigir:

• Adaptadores independientes del modelo y del marco que eviten la dependencia de un proveedor.
• Compatibilidad nativa con OTel para calcular métricas por traza.
• Muestreo configurable para controlar los costes de la puntuación basada en jueces.
• Una interfaz de complementos para añadir métricas personalizadas a medida que evolucionen las necesidades.

Para los equipos que construyen específicamente canalizaciones de telemetría, la guía de Wattle AI sobre métricas basadas en trazas ofrece un repaso práctico de las métricas por traza que conviene supervisar en agentes en producción y complementa los campos de OTel tratados aquí.

Cómo elegir o diseñar un marco de evaluación de LLM

Elegir o construir un marco se reduce a cinco criterios que importan más que el número de funciones: la reproducibilidad de los resultados entre ejecuciones, la profundidad de la captura de telemetría, la extensibilidad para nuevas métricas y jueces, un modelo de costes que escale de forma razonable con el uso y la adecuación a los requisitos de privacidad y cumplimiento de los datos implicados.

Al evaluar un marco, tanto si se desarrolla internamente como si se valora un proveedor, estas preguntas revelan las carencias más importantes:

1. ¿Qué tasa de muestreo utiliza la puntuación basada en jueces y puede ajustarse según el nivel de riesgo?
2. ¿Sigue el esquema de telemetría las convenciones de OTel o requiere un análisis personalizado para cada integración?
3. ¿Se ha validado el juez LLM conforme a un protocolo documentado y se ha publicado esa validación?
4. ¿Qué ocurre en CI cuando se supera un umbral de regresión: se bloquea la canalización, se emite una advertencia o se exige una anulación manual?
5. ¿Cómo se gestionan los datos sensibles en las trazas y cumple esa gestión los requisitos normativos de su sector?

El nivel de riesgo debe determinar el rigor. Las interacciones de bajo riesgo (una herramienta interna que resume documentos) pueden apoyarse en puntuaciones de jueces LLM sobre muestras, con comprobaciones puntuales periódicas. Los sistemas de riesgo medio (un chat orientado al cliente sin consecuencias financieras ni de seguridad) justifican umbrales de regresión más estrictos y una revisión humana más frecuente de las salidas de los jueces. Los sistemas de alto riesgo (agentes que realizan acciones irreversibles, gestionan transacciones financieras u operan en sectores regulados) necesitan revisión obligatoria con intervención humana antes del despliegue y supervisión continua posterior.

Consejo profesional: Establezca su umbral de regresión antes de ver el primer resultado, no después. Un umbral elegido a posteriori tiende a ajustarse a lo que el modelo ya ha hecho.

Observabilidad y gobernanza en ejecución para sistemas de agentes

Los sistemas de agentes introducen riesgos que la evaluación fuera de línea no puede captar por completo: comportamientos emergentes que solo aparecen en interacciones de varios pasos, acciones que no pueden deshacerse una vez realizadas y rutas de decisión que varían según respuestas de herramientas que el modelo no pudo anticipar durante las pruebas. Por eso, la gobernanza en ejecución se ha convertido en una disciplina diferenciada de la evaluación previa al despliegue, en lugar de una extensión de esta.

La investigación sobre la gobernanza de agentes en ejecución describe un conjunto coordinado de mecanismos concebidos precisamente para cubrir esta carencia: un índice de riesgo de autonomía que puntúa el margen autónomo que ejerce un agente; telemetría semántica de agentes que etiqueta acciones, llamadas a herramientas, planes y autorizaciones como eventos estructurados; motores de conformidad que comprueban las trazas ordenadas temporalmente frente a las políticas; detección de deriva que señala cambios de comportamiento a lo largo del tiempo; y contención graduada que adapta la respuesta a la gravedad del problema detectado (marco integrado de gobernanza en ejecución MI9). Ese mismo conjunto de trabajos informa de buenos resultados de detección en pruebas con escenarios sintéticos, y el marco está diseñado expresamente para ser independiente del modelo, en lugar de estar vinculado a la infraestructura de agentes de un proveedor.

La auditoría independiente complementa esta capa de instrumentación, no la sustituye. Los enfoques de supervisión continua, incluidas las plataformas de auditoría de agentes, verifican el comportamiento de los agentes en conversaciones reales, no solo en escenarios de prueba sintéticos, algo importante porque el tráfico en producción revela patrones que ninguna batería de pruebas anticipa por completo. Este tipo de auditoría también comprueba si un agente deriva los problemas a un representante humano cuando corresponde, un comportamiento de gobernanza cuyo correcto funcionamiento no queda garantizado solo con telemetría.

La gobernanza de agentes en ejecución solo funciona cuando la telemetría, los motores de políticas y las acciones de contención se conectan en un único ciclo, en lugar de tratarse como herramientas separadas.

Lista de comprobación práctica para vincular la telemetría con las acciones de gobernanza:

• Etiquete cada evento del agente (acción, llamada a herramienta, paso de un plan, autorización) con un esquema coherente.
• Defina umbrales que activen una contención graduada en lugar de una desconexión de todo o nada.
• Envíe automáticamente los fallos de derivación a una cola de revisión humana, no solo cuando se solicite.
• Vuelva a ejecutar la detección de deriva con una periodicidad fija, no únicamente después de un incidente.

— Sergio Llorens

Retos, errores y limitaciones habituales en la evaluación de LLM

La fiabilidad del enfoque de LLM como juez es el problema más citado en la práctica actual. El sesgo de posición y la deflación del coeficiente kappa implican que un juez puede parecer coherente y seguir equivocándose, por lo que los jueces necesitan validación con varios protocolos, no una única ejecución de una prueba de referencia.

La evaluación humana tiene su propio problema de documentación. Una investigación sobre la evaluación de la generación de textos extensos detectó una descripción sistemáticamente insuficiente de la metodología en los estudios publicados de evaluación humana y propuso una plantilla de informes con 20 criterios para estandarizar la información que debería comunicarse sobre cualquier protocolo de evaluación humana (estudio sobre protocolos de evaluación humana). Los equipos que construyen procesos internos de evaluación humana se benefician de adoptar una disciplina de documentación similar, incluso sin una publicación formal.

Los compromisos entre coste y escala son inevitables cuando las llamadas a jueces LLM abarcan volúmenes significativos de tráfico. Almacenar en caché las evaluaciones repetidas y utilizar muestreo estratificado, dando más peso a las interacciones de mayor riesgo, evita que los costes de los jueces crezcan linealmente con el volumen.

• Valide los jueces LLM con más de un protocolo de evaluación antes de confiar en sus puntuaciones.
• Aplique el estándar de documentación de 20 criterios al registrar internamente los resultados de la evaluación humana.
• Utilice caché y muestreo estratificado para los jueces LLM en lugar de puntuar cada traza al coste completo.
• Trate con cautela los resultados de las pruebas de referencia de agentes: las decisiones sobre la infraestructura y el entorno pueden sesgar las puntuaciones con independencia de la capacidad del modelo, como señala la investigación sobre evaluación unificada de agentes.

Buenas prácticas para desarrolladores y lista de comprobación para la implementación

Se puede construir un sistema de evaluación operativo de forma incremental. Los siguientes elementos se traducen directamente en tareas de sprint.

1. Fije los conjuntos de datos y los prompts a versiones específicas antes de establecer cualquier métrica de referencia.
2. Instrumente campos de OTel sobre el éxito de la tarea, la latencia, el coste y la fidelidad de las llamadas a herramientas en cada traza.
3. Añada controles deterministas en CI para validar esquemas y llamadas a herramientas antes de ejecutar cualquier puntuación basada en jueces.
4. Seleccione un porcentaje definido del tráfico en producción para auditorías con jueces LLM, en lugar de puntuarlo todo.
5. Publique las métricas internas de validación de los jueces para que los revisores sepan hasta qué punto pueden confiar en las puntuaciones automatizadas.

Los umbrales de control deben ajustarse al nivel de riesgo: las funciones de bajo riesgo pueden tolerar márgenes de regresión más amplios y una revisión más ligera, mientras que las acciones de agentes de alto riesgo necesitan umbrales más estrictos y aprobación humana obligatoria antes de su puesta en producción. El Marco de Seguridad en Producción recomienda referencias de base fijadas, baterías automatizadas de pruebas de regresión y despliegues canario o en sombra que detecten regresiones en los 15 minutos posteriores a la puesta en producción, un objetivo que merece adoptarse directamente.

Los sistemas en producción que siguen este tipo de observabilidad por capas suelen supervisar decenas de métricas por traza en lugar de unos pocos valores agregados, ya que el cálculo por traza es lo que detecta los fallos que ocultan los promedios (Marco de Seguridad en Producción).

Evaluación comparativa frente a estándares sectoriales y requisitos normativos

Las pruebas de referencia públicas miden la capacidad general, pero rara vez se corresponden de forma directa con los estándares normativos y operativos específicos que debe cumplir un sistema en producción. La evaluación comparativa frente a estándares sectoriales implica contrastar el comportamiento medido de un sistema, no solo su puntuación en una prueba de referencia, con umbrales documentados de seguridad, derivación y fiabilidad aplicables al sector en el que opera.

El Marco de Seguridad en Producción ofrece una referencia útil para ello: recomienda una observabilidad en ejecución basada en telemetría por traza y controles en CI, en lugar de considerar que una puntuación puntual en una prueba de referencia constituye evidencia suficiente de preparación para producción (Marco de Seguridad en Producción). Este enfoque importa porque un modelo puede obtener buenos resultados en clasificaciones públicas y aun así fallar de formas que detectaría un estándar sectorial, como gestionar mal una derivación en atención al cliente o producir salidas incoherentes ante consultas idénticas repetidas.

Los requisitos normativos añaden una segunda capa a la evaluación comparativa técnica. Mientras una prueba de referencia pública pregunta «qué capacidad tiene este modelo», un estándar normativo pregunta «si el comportamiento de este sistema puede verificarse y explicarse a un tercero». Son preguntas distintas, y un marco construido únicamente para rendir bien en pruebas de referencia no responderá automáticamente a la segunda.

La evaluación independiente del marco también importa aquí: la investigación sobre la evaluación de sistemas multiagente concluyó que la infraestructura de agentes sobre la que se ejecuta un sistema puede afectar al rendimiento medido tanto como la elección del modelo subyacente, lo que significa que las comparaciones entre proveedores deben controlar las diferencias entre marcos, no solo entre modelos (evaluación independiente del marco MASEval). Los equipos que se comparan con estándares sectoriales deberían tratar la elección de la infraestructura como una variable que documentar, no como un supuesto que ignorar.

Integración de marcos de evaluación con flujos de cumplimiento de la normativa de IA

Los marcos normativos como el EU AI Act introducen obligaciones de documentación y verificación que la evaluación técnica por sí sola no satisface. Un marco de evaluación que solo informa de métricas de precisión o latencia deja una carencia de cumplimiento: los reguladores y los equipos internos de riesgos necesitan pruebas de que el comportamiento de un sistema se ha comprobado de forma independiente, no solo se ha medido internamente.

Conectar la evaluación con los flujos de cumplimiento implica trasladar resultados específicos de evaluación, informes de validación de jueces, documentación de evaluación humana y registros de telemetría que muestren el comportamiento de derivación al formato que necesitan los equipos de cumplimiento para justificar el comportamiento del sistema cuando se les solicite. Es un entregable distinto de un panel diseñado para ingenieros: debe ser reproducible, estar fechado y vincularse a una versión específica del sistema, en lugar de a una afirmación general sobre su capacidad.

Las pruebas de auditoría independiente refuerzan considerablemente esta posición. Los equipos de cumplimiento que dependen exclusivamente de datos de rendimiento proporcionados por los proveedores afrontan una carencia evidente de credibilidad al defender esos datos ante un regulador que no tiene motivos para confiar en las afirmaciones del propio proveedor. Una auditoría independiente, realizada por una parte sin intereses en el rendimiento del agente, proporciona a los equipos de cumplimiento pruebas que pueden presentar sin depender de la palabra del proveedor. Diseñamos la auditoría de Lexic Compass específicamente para cubrir esa carencia: verifica el comportamiento de los agentes en conversaciones reales y comprueba conductas relevantes para el cumplimiento, como la transparencia informativa y la derivación, proporcionando a los equipos de cumplimiento una referencia documentada e independiente, en lugar de una aportada por el proveedor.

Los esquemas de telemetría diseñados para la gobernanza en ejecución, que etiquetan acciones, autorizaciones y llamadas a herramientas como eventos estructurados, también sirven como documentación de cumplimiento cuando se conservan y se les asignan marcas de tiempo correctamente. Incorporar esa conservación al marco de evaluación desde el principio evita tener que construir después un sistema separado de registro para cumplimiento bajo la presión de los plazos.

Casos prácticos que muestran la eficacia de los marcos en despliegues empresariales

Los despliegues empresariales que invierten en evaluación estructurada tienden a revelar el mismo patrón: los problemas que las pruebas internas no detectaron se hacen visibles cuando se aplica una revisión independiente, conversación por conversación, al tráfico en producción.

Este patrón ilustra por qué las pruebas fuera de línea, por exhaustivas que sean, no sustituyen a la revisión de conversaciones reales. Un agente puede superar todas las pruebas de derivación predefinidas y aun así no derivar correctamente cuando se encuentra con la formulación concreta, el nivel de frustración o el patrón de solicitud ambiguo que presentan los clientes reales. Los equipos empresariales que detectan esta carencia lo hacen auditando interacciones reales, en lugar de depender únicamente de la batería de pruebas que acompañó al despliegue original.

La lección operativa para los equipos que construyen o gobiernan agentes de IA conversacional es que la eficacia de la evaluación depende de revisar todo el abanico de comportamientos en producción a lo largo del tiempo, no de superar una única prueba el día del lanzamiento. Un marco que funciona bien en una fase piloto puede acumular deriva a medida que cambian los patrones de uso, por lo que la auditoría continua a nivel de conversación importa tanto como la batería de pruebas inicial que validó el sistema antes de su lanzamiento.

Estrategias para auditar de forma exhaustiva agentes de IA de varios proveedores

Las empresas utilizan cada vez más agentes de IA de varios proveedores simultáneamente, en atención al cliente, ventas y herramientas internas, lo que hace insuficiente un único enfoque de evaluación específico de un proveedor. Una estrategia exhaustiva de auditoría multiproveedor debe aplicar el mismo estándar de evaluación a todos los agentes, con independencia de qué proveedor los haya desarrollado, ya que unos estándares incoherentes privan de sentido a la comparación entre agentes.

Esto comienza con un esquema común de telemetría aplicado de manera uniforme, de modo que el éxito de la tarea, el comportamiento de derivación y la fidelidad de las llamadas a herramientas se midan del mismo modo, tanto si el agente se ejecuta en la infraestructura de un proveedor como en la de otro. Las herramientas de evaluación independientes del marco son esenciales aquí, ya que una batería de pruebas específica de una infraestructura, construida para el marco de agentes de un proveedor, no se trasladará directamente a la arquitectura de un competidor.

La auditoría independiente resulta especialmente adecuada para los entornos multiproveedor porque no depende de la colaboración del proveedor ni de la instrumentación que este facilite. Diseñamos una plataforma de auditoría precisamente en torno a esta necesidad: auditar agentes de cualquier proveedor sin tener que construirlos ni operarlos nosotros mismos, lo que permite aplicar un único estándar de auditoría a toda la cartera de agentes de una empresa, en lugar de un proceso de revisión separado para cada relación con un proveedor.

Una auditoría multiproveedor práctica cubre tres capas de forma coherente en todos los agentes: la calidad de la experiencia del cliente, la exposición a riesgos de seguridad en la gestión de solicitudes sensibles y la fiabilidad técnica, incluidas la derivación y la gestión de errores. Aplicar las tres capas de manera uniforme permite comparar los datos resultantes entre proveedores, en lugar de producir informes aislados que no puedan contrastarse al decidir dónde invertir en correcciones.

Evaluación de la transparencia y la rendición de cuentas en la IA conversacional

La transparencia en la IA conversacional significa que el comportamiento de un sistema puede explicarse y verificarse a posteriori, no solo que sus salidas parezcan razonables en el momento. La rendición de cuentas significa que existe un registro claro de lo que hizo el sistema, por qué y quién es responsable de corregirlo cuando falla. Ambas requieren pruebas que vayan más allá de las puntuaciones de calidad de las salidas de un modelo.

Los métodos prácticos para evaluar la transparencia comienzan con comprobaciones de la información facilitada: si el agente se identifica claramente como un sistema de IA cuando es obligatorio y si describe con precisión sus propias capacidades y limitaciones durante una conversación, en lugar de insinuar capacidades que no posee. Son comprobaciones de comportamiento que requieren revisar transcripciones de conversaciones reales, no solo realizar pruebas con escenarios predefinidos.

Las métricas de rendición de cuentas se centran en la trazabilidad: si una decisión o respuesta concreta puede vincularse a una versión específica del modelo, un prompt y una traza de telemetría. La telemetría semántica de agentes, que etiqueta acciones y autorizaciones como eventos estructurados, hace posible esta trazabilidad al nivel que esperan los reguladores y los auditores internos, en lugar de reconstruirla manualmente después de un incidente.

La revisión independiente a nivel de conversación añade una capa que las métricas declaradas por la propia organización no pueden sustituir: la verificación por una parte sin incentivos para presentar al agente de forma favorable. Esta auditoría se centra precisamente en estos puntos ciegos: la exactitud de la información facilitada, el comportamiento de derivación y la diferencia entre lo que un agente debería hacer y lo que realmente hace en conversaciones reales, proporcionando a las organizaciones un registro de transparencia y rendición de cuentas que pueden respaldar.

Qué priorizaría si lo estuviera construyendo hoy

El error que veo con más frecuencia es que los equipos invierten mucho en la ingeniería de prompts para los jueces y omiten por completo la instrumentación de telemetría. Un juez bien ajustado en un sistema sin visibilidad por traza sigue dejando sin detectar precisamente los fallos que más importan: los que solo aparecen en el tráfico en producción, con patrones de uso reales, semanas después del lanzamiento.

Si tuviera que ordenar las prioridades para un equipo que empieza de cero, pondría la telemetría en primer lugar, los controles deterministas en segundo y la puntuación basada en jueces en tercero. La documentación de la evaluación humana merece más rigor del que le dedica la mayoría de los equipos. Un juez validado con un único protocolo y que nunca vuelve a comprobarse es un riesgo disfrazado de métrica.

— Sergio Llorens

Cómo refuerza Lexic sus capacidades de evaluación y gobernanza

Construimos nuestra plataforma para cubrir la carencia que las pruebas internas y las métricas proporcionadas por los proveedores no pueden resolver por sí solas: la verificación independiente de lo que los agentes de IA hacen realmente en conversaciones reales. A través de Lexic Compass, auditamos agentes de cualquier proveedor para detectar puntos ciegos en la experiencia del cliente, exposición a riesgos de seguridad y fallos técnicos, incluidas las deficiencias de derivación que aparecen de forma tan recurrente en nuestros datos de auditoría.

Para los equipos que necesitan visibilidad continua en lugar de una comprobación puntual, Lexic Pulse analiza conversaciones de clientes en llamadas, chats, correos electrónicos y tickets para identificar el sentimiento, las señales de abandono y los patrones de derivación a medida que se producen. También ofrecemos servicios de alcance definido, incluidos Flash Preview y Audit Sprint, junto con Enterprise Continuous Trust para una garantía continua, detallados en nuestra página de servicios de auditoría.

Si su equipo se está preparando para una revisión regulatoria o simplemente necesita pruebas de que sus agentes derivan e informan correctamente, empiece por una auditoría cuyo alcance se ajuste a su despliegue actual.

Preguntas frecuentes

¿Qué es un marco de evaluación de LLM?

Un marco de evaluación de LLM es el conjunto de baterías de pruebas, métodos de puntuación y telemetría que se utiliza para medir si un modelo de lenguaje o un agente se comporta de forma correcta, segura y coherente. Normalmente abarca las pruebas fuera de línea antes del despliegue y la observabilidad en ejecución después de la puesta en producción.

¿Qué fiabilidad tiene la puntuación de LLM como juez?

El enfoque de LLM como juez permite escalar la evaluación, pero es menos fiable de lo que sugieren las cifras de concordancia bruta. Una auditoría a gran escala concluyó que la concordancia bruta sobrestima la fiabilidad corregida por azar entre 33 y 41 puntos porcentuales, por lo que los jueces necesitan validación con varios protocolos antes de aceptar sus puntuaciones sin reservas.

¿Qué telemetría debería capturar para agentes de IA en producción?

Capture campos de OpenTelemetry por traza que cubran el éxito de la tarea, la latencia, el coste y la fidelidad de las llamadas a herramientas, en lugar de depender únicamente de métricas agregadas. El Marco de Seguridad en Producción recomienda este nivel de detalle precisamente porque los valores agregados pueden ocultar concentraciones de fallos que los datos por traza revelan.

¿Con qué frecuencia fallan los agentes de IA al derivar problemas correctamente?

El comportamiento de derivación es una de las comprobaciones de mayor valor en cualquier proceso de evaluación de agentes.

¿Cómo se relaciona la evaluación con el cumplimiento del EU AI Act?

Los flujos de cumplimiento necesitan pruebas documentadas y reproducibles del comportamiento del sistema, no solo métricas internas de rendimiento, por lo que los registros de auditoría independiente tienen más peso ante los reguladores que los datos proporcionados únicamente por los proveedores. Los esquemas de telemetría que etiquetan acciones y autorizaciones como eventos estructurados también sirven como documentación de cumplimiento cuando se conservan de forma sistemática.

Fuentes

• El Marco de Seguridad en Producción | Production AI Institute
• Auditoría a gran escala de LLM como juez (arXiv)