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 sin conexión repetible antes de ampliar el uso. Esta guía aborda los componentes, paradigmas, patrones de herramientas y prácticas de gobernanza que hacen que la evaluación sea 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 las tareas, la latencia, el coste y la fidelidad de las llamadas a herramientas para rastrear regresiones.
• Los LLM evaluadores permiten ampliar la puntuación subjetiva, pero una auditoría detectó que la concordancia bruta sobreestimaba la fiabilidad entre 33 y 41 puntos porcentuales; valídelos mediante varios protocolos.
• Seleccione muestras de trazas de producción de mayor riesgo para que las puntúe el evaluador y almacene en caché las evaluaciones repetidas, en lugar de puntuar cada interacción y dejar que los costes aumenten con el tráfico.
• Los agentes que realizan acciones irreversibles o gestionan transacciones financieras requieren aprobación humana antes de su lanzamiento, 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 concretas del sistema; los reguladores necesitan pruebas reproducibles del cumplimiento de los deberes de información y de la derivación de casos, no afirmaciones de rendimiento de los proveedores.

Índice

• Qué es un marco de evaluación de LLM y por qué lo necesitan los equipos
• Componentes esenciales de un marco de evaluación de LLM
• Comparación entre comprobaciones deterministas, LLM como evaluador y puntuación mediante rúbricas
• Capacidades del marco y patrones de herramientas esperables
• 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 trabajo de cumplimiento normativo en IA
• Casos prácticos que muestran la eficacia del marco 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 construyera hoy
• Cómo refuerza Lexic su 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 sin conexión antes del despliegue y la observabilidad en ejecución después de este. La capa sin conexión incluye entornos de pruebas, conjuntos de datos seleccionados y evaluadores automatizados que se ejecutan en integración continua. La capa de ejecución captura la telemetría del tráfico de producción y registra lo que hace realmente el modelo o agente 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 sin conexión y aun así sufrir 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 comunican.

El valor de un marco estructurado se concreta 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 las salidas inseguras antes de que lleguen a los usuarios.
• Control de costes: las estrategias de muestreo y almacenamiento en caché mantienen previsible el gasto en evaluación a medida que crece el uso.
• Detección de regresiones: las referencias fijadas permiten detectar cuándo una nueva versión del modelo o un cambio de 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 ventajoso disponer de un marco que ya estuviera funcionando antes del cambio, en lugar de construirlo como respuesta a este.

Componentes esenciales 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 culmina con ejecuciones de largo alcance que ponen a prueba el comportamiento de los agentes en varios turnos o pasos durante interacciones prolongadas.

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

La revisión con intervención humana sigue siendo necesaria allí donde no se puede confiar exclusivamente en la puntuación automatizada. Esto implica estándares de anotación definidos, una metaevaluación periódica de los propios evaluadores y plantillas de informes que permitan comparar los resultados de la revisión humana entre rondas de evaluación.

La telemetría conecta la evaluación sin conexión con la evaluación en ejecución. Capturar campos de OpenTelemetry (OTel) en cada traza permite a los equipos calcular el éxito de las tareas, la latencia, el coste y la fidelidad de las llamadas a herramientas para cada interacción, en lugar de depender de medias agregadas que pueden ocultar concentraciones de fallos.

El control de versiones y la detección de regresiones articulan las otras cuatro piezas: se fija la versión de cada conjunto de datos, prompt y modelo, de modo que un descenso en una métrica pueda vincularse a un cambio concreto en lugar de investigar su causa 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 evaluadores para poder diagnosticar los fallos.
• Registre la telemetría por traza, no solo métricas agregadas.
• Programe metaevaluaciones periódicas de cualquier LLM evaluador en uso.

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

Comparación entre comprobaciones deterministas, LLM como evaluador 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 de 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 gran escala. Su limitación es el alcance: solo funcionan cuando la corrección puede definirse como una regla, lo que excluye la mayoría de los juicios sobre tono, utilidad o calidad del razonamiento.

El enfoque de LLM como evaluador (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 evaluadores sobre aproximadamente 541,000 valoraciones constató que la concordancia bruta sobreestima la fiabilidad corregida por azar entre 33 y 41 puntos porcentuales, e identificó una paradoja entre consistencia y sesgo por la que los evaluadores que parecen más consistentes son a veces los menos precisos (auditoría de LLM como evaluador). El sesgo de posición, por el que un evaluador favorece la respuesta que aparece en primer o segundo lugar, es un modo de fallo documentado en esa misma línea de investigación.

La puntuación basada en rúbricas u holística aborda parte de este problema al calificar una respuesta según una rúbrica estructurada, en lugar de pedir al evaluador que elija un ganador en una comparación por pares. La investigación sobre la fiabilidad de los evaluadores sugiere que pasar de comparaciones por pares basadas en la tasa de victorias a una puntuación holística mediante rúbricas mejora la fiabilidad de forma más eficaz que ajustar los prompts del evaluador (replanteamiento de la fiabilidad de los LLM evaluadores). 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 una barrera estricta que bloquea las salidas claramente defectuosas, una muestra del tráfico pasa por la puntuación de un LLM evaluador para operar a escala y una capa de metaevaluación humana comprueba periódicamente si el propio evaluador sigue siendo fiable. Ninguno de los tres paradigmas cubre por sí solo todos los fallos que puede producir un sistema en producción.

Capacidades del marco y patrones de herramientas esperables

La mayoría de las bibliotecas y plataformas de evaluación convergen en un conjunto de funciones similar, aunque difieran en su marca.

Los adaptadores para modelos y marcos de agentes permiten ejecutar la misma batería de pruebas con distintos sistemas subyacentes sin reescribir la lógica de las pruebas, algo importante cuando los equipos comparan proveedores o migran entre estructuras de soporte de agentes. La captura de trazas y un formato unificado de trazas 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 normaliza 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 LLM evaluadores, que de otro modo puede crecer linealmente con cada ejecución de pruebas.

La capacidad de reproducción en un entorno aislado o sin conexión facilita las pruebas reproducibles del comportamiento de los agentes, especialmente en escenarios de largo alcance 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 con este fin: someter a pruebas de estrés los modos de fallo infrecuentes mediante prompts reproducibles y evaluadores programados, en lugar de esperar a que ocurran en el tráfico de producción (marco de gobernanza en ejecución MI9).

La extensibilidad mediante complementos o adaptadores permite que un marco incorpore nuevas métricas o nuevos modelos evaluadores sin necesidad de reescribirlo. Los equipos que evalúen 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 el coste de la puntuación basada en evaluadores.
• 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 seguir en agentes de producción y complementa los campos de OTel analizados aquí.

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

Seleccionar o construir un marco depende de cinco criterios más importantes 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 evaluadores, 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, ya sea para desarrollarlo internamente o para valorar a un proveedor, estas preguntas ponen de manifiesto las carencias más importantes:

1. ¿Qué tasa de muestreo utiliza la puntuación basada en evaluadores y puede ajustarse según el nivel de riesgo?
2. ¿El esquema de telemetría sigue las convenciones de OTel o requiere un análisis personalizado para cada integración?
3. ¿Se ha validado el LLM evaluador mediante 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 autorización manual para continuar?
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 la puntuación de muestras mediante LLM evaluadores con comprobaciones puntuales periódicas. Los sistemas de riesgo medio (chats orientados al cliente sin consecuencias financieras ni de seguridad) requieren umbrales de regresión más estrictos y una revisión humana más frecuente de las salidas de los evaluadores. Los sistemas de alto riesgo (agentes que realizan acciones irreversibles, gestionan transacciones financieras u operan en sectores regulados) necesitan una revisión obligatoria con intervención humana antes del despliegue y supervisión continua después.

Consejo profesional: Establezca el 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 sin conexión 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 en las pruebas. Por eso la gobernanza en ejecución se ha convertido en una disciplina distinta de la evaluación previa al despliegue, y no en una mera extensión de esta.

La investigación sobre gobernanza de agentes en ejecución describe un conjunto coordinado de mecanismos diseñado precisamente para cubrir esta carencia: un índice de riesgo de autonomía que puntúa el margen de actuación autónoma de un agente, telemetría semántica de agentes que etiqueta acciones, llamadas a herramientas, planes y autorizaciones como eventos estructurados, motores de conformidad que contrastan trazas ordenadas temporalmente con las políticas, detección de deriva que señala cambios de comportamiento a lo largo del tiempo y contención gradual que ajusta la respuesta a la gravedad del problema detectado (marco integrado de gobernanza en ejecución MI9). Esa misma línea de trabajo informa de un elevado rendimiento 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 pila tecnológica de agentes de un proveedor.

La auditoría independiente complementa esta capa de instrumentación en lugar de sustituirla. Los enfoques de supervisión continua, incluidas las plataformas de auditoría de agentes, verifican el comportamiento de los agentes en conversaciones reales y no solo en escenarios de prueba sintéticos, algo importante porque el tráfico de 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 la 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 están conectados en un único ciclo, en lugar de tratarse como herramientas separadas.

Una lista práctica para vincular la telemetría con las acciones de gobernanza:

• Etiquete cada evento del agente (acción, llamada a herramienta, paso del plan, autorización) con un esquema coherente.
• Defina umbrales que activen una contención gradual 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 solo después de un incidente.

— Sergio Llorens

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

La fiabilidad de los LLM como evaluadores es el problema más citado en la práctica actual. El sesgo de posición y la reducción del coeficiente kappa hacen que un evaluador pueda parecer consistente y seguir equivocándose, por lo que estos evaluadores necesitan validación mediante varios protocolos y no una única ejecución de una prueba de referencia.

La evaluación humana tiene su propio problema de documentación. La investigación sobre la evaluación de generación de textos largos 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 de 20 criterios para normalizar la información que debe comunicarse sobre cualquier protocolo de evaluación humana (estudio sobre protocolos de evaluación humana). Los equipos que desarrollan procesos internos de evaluación humana se benefician de adoptar una disciplina documental similar, incluso sin una publicación formal.

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

• Valide los LLM evaluadores mediante más de un protocolo de evaluación antes de confiar en sus puntuaciones.
• Aplique el estándar de informes de 20 criterios al documentar internamente los resultados de la evaluación humana.
• Utilice caché y muestreo estratificado para los LLM evaluadores, 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 estructura de soporte 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

Un sistema de evaluación operativo puede construirse de forma incremental. Los siguientes puntos se traducen directamente en tareas de sprint.

1. Fije versiones concretas de los conjuntos de datos y los prompts antes de establecer cualquier métrica de referencia.
2. Instrumente campos de OTel para el éxito de las tareas, 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 evaluadores.
4. Seleccione un porcentaje definido del tráfico de producción para auditorías mediante LLM evaluadores en lugar de puntuarlo todo.
5. Publique internamente las métricas de validación de los evaluadores para que los revisores sepan hasta qué punto confiar en las puntuaciones automatizadas.

Los umbrales de los controles deben ajustarse al nivel de riesgo: las funciones de bajo riesgo pueden tolerar márgenes de regresión más amplios y revisiones menos intensivas, mientras que las acciones de agentes de alto riesgo necesitan umbrales más estrictos y aprobación humana obligatoria antes del lanzamiento. El Marco de Seguridad en Producción recomienda referencias fijadas, baterías automatizadas de pruebas de regresión y despliegues canario o en sombra que detecten regresiones en los 15 minutos posteriores al lanzamiento, un objetivo que merece la pena adoptar directamente.

Los sistemas de producción que siguen este tipo de observabilidad por capas suelen registrar decenas de métricas por traza en lugar de unos pocos valores agregados, ya que el cálculo por traza es lo que permite detectar los fallos que ocultan las medias (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 concretos que debe cumplir un sistema en producción. Evaluar frente a estándares sectoriales significa comparar 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: recomienda una observabilidad en ejecución basada en telemetría por traza y controles en CI, en lugar de considerar la puntuación de una única prueba de referencia como prueba suficiente de que un sistema está listo para producción (Marco de Seguridad en Producción). Este enfoque importa porque un modelo puede obtener buenas puntuaciones en clasificaciones públicas y aun así fallar de formas que un estándar sectorial detectaría, como gestionar mal la derivación en atención al cliente o producir salidas inconsistentes 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 satisfará automáticamente la segunda.

La evaluación independiente del marco también importa aquí: la investigación sobre evaluación de sistemas multiagente constató que la estructura de soporte de agentes sobre la que se ejecuta un sistema puede afectar al rendimiento medido tanto como la elección del modelo subyacente. Esto 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 evalúen frente a estándares sectoriales deben tratar la elección de la estructura de soporte como una variable que hay que documentar, no como un supuesto que se pueda ignorar.

Integración de marcos de evaluación con flujos de trabajo de cumplimiento normativo en 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 del sistema se ha comprobado de forma independiente, no solo medido internamente.

Conectar la evaluación con los flujos de cumplimiento implica trasladar resultados concretos de evaluación, informes de validación de evaluadores, documentación de evaluación humana y registros de telemetría que muestran el comportamiento de derivación al formato que los equipos de cumplimiento necesitan para justificar el comportamiento de un sistema cuando se les solicite. Se trata de un entregable distinto de un panel para ingenieros: debe ser reproducible, estar fechado y vincularse a una versión concreta del sistema, en lugar de constituir una afirmación general sobre sus capacidades.

Las pruebas de auditoría independiente refuerzan considerablemente esta posición. Los equipos de cumplimiento que dependen exclusivamente de datos de rendimiento aportados por el proveedor se enfrentan a una evidente carencia de credibilidad cuando defienden 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. Desarrollamos nuestras auditorías con Lexic Compass específicamente para cubrir esa carencia: verifican el comportamiento de los agentes en conversaciones reales y comprueban conductas relevantes para el cumplimiento, como la información al usuario y la derivación de casos, ofreciendo 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 registros de cumplimiento bajo la presión de los plazos.

Casos prácticos que muestran la eficacia del marco en despliegues empresariales

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

Este patrón ilustra por qué las pruebas sin conexión, por exhaustivas que sean, no sustituyen 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 las formulaciones concretas, el nivel de frustración o los patrones de solicitudes ambiguas que utilizan los clientes reales. Los equipos empresariales que detectan esta carencia lo hacen auditando interacciones reales, en lugar de apoyarse únicamente en 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 espectro del comportamiento en producción a lo largo del tiempo, no de superar una única ronda de pruebas el día del lanzamiento. Un marco que funciona bien en una fase piloto puede seguir acumulando 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 inicial de pruebas 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, independientemente de quién los haya construido, ya que unos estándares inconsistentes vacían de sentido 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 las tareas, el comportamiento de derivación y la fidelidad de las llamadas a herramientas se midan igual tanto si el agente se ejecuta sobre la pila tecnológica de un proveedor como sobre la de otro. Las herramientas de evaluación independientes del marco resultan esenciales aquí, ya que una batería de pruebas específica de una estructura de soporte, construida para el marco de agentes de un proveedor, no se trasladará sin dificultades a la arquitectura de un competidor.

La auditoría independiente resulta especialmente adecuada para entornos multiproveedor porque no depende de la cooperación del proveedor ni de la instrumentación que este aporte. 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 todo el conjunto de agentes de una empresa, en lugar de un proceso de revisión distinto por cada relación con un proveedor.

Una auditoría multiproveedor práctica cubre tres capas de forma coherente en cada agente: 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 que los datos resultantes sean comparables entre proveedores, en lugar de producir informes aislados que no puedan contrastarse entre sí 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 al usuario: si el agente se identifica claramente como un sistema de IA cuando es obligatorio y si representa con precisión sus propias capacidades y limitaciones durante una conversación, en lugar de insinuar capacidades que no tiene. Son comprobaciones de comportamiento que exigen 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, sin tener que 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 esos puntos ciegos, la exactitud de la información al usuario, el comportamiento de derivación y la distancia entre lo que un agente debería hacer y lo que realmente hace en conversaciones reales, proporcionando a las organizaciones un registro defendible de transparencia y rendición de cuentas.

Qué priorizaría si lo construyera hoy

El error que veo con más frecuencia es que los equipos invierten mucho en la ingeniería de prompts del evaluador mientras omiten por completo la instrumentación de telemetría. Un evaluador bien ajustado sobre 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 de 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 primero la telemetría, después los controles deterministas y, en tercer lugar, la puntuación basada en evaluadores. La documentación de la evaluación humana merece más rigor del que le dedica la mayoría de los equipos. Un evaluador validado con un único protocolo y que nunca se vuelve a comprobar es un riesgo disfrazado de métrica.

— Sergio Llorens

Cómo refuerza Lexic su evaluación y gobernanza

Construimos nuestra plataforma para cubrir la carencia que las pruebas internas y las métricas aportadas por los proveedores no pueden resolver por sí solas: la verificación independiente de lo que realmente hacen los agentes de IA 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 carencias 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 las conversaciones con 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 una Vista Previa Rápida y un Sprint de Auditoría, junto con Confianza Continua Empresarial para un aseguramiento permanente, que se detallan en nuestra página de servicios de auditoría.

Si su equipo se está preparando para el escrutinio regulatorio o simplemente necesita pruebas de que sus agentes derivan los casos 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 utilizado para medir si un modelo de lenguaje o un agente se comporta de forma correcta, segura y coherente. Normalmente abarca las pruebas sin conexión antes del despliegue y la observabilidad en ejecución después del lanzamiento.

¿Hasta qué punto es fiable la puntuación mediante LLM como evaluador?

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

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

Capture campos de OpenTelemetry por traza que cubran el éxito de las tareas, 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 datos agregados pueden ocultar concentraciones de fallos que los datos por traza revelan.

¿Con qué frecuencia los agentes de IA no derivan los 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 aportados exclusivamente por el proveedor. 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 evaluador (arXiv)