Modificaciones de analistas y ciclos de retroalimentación de agentes de IA

Última actualización: septiembre de 2026

Cuando un analista anula la decisión de un agente de IA, la institución acaba de generar una prueba, pero la mayoría de los sistemas la descartan. Un modelo de campeón-retador (champion-challenger) es el control que le permite conservarla. Los datos de la anulación entrenan a una versión candidata del agente, mientras que la versión que toma las decisiones en tiempo real permanece intacta; además, promover a la candidata requiere pruebas y un responsable humano identificado. En esta página se utiliza el término para referirse a dos versiones de la misma lógica de decisión, no a dos proveedores competidores. Si se configura mal este mecanismo, el bucle de retroalimentación dejará de mejorar al agente y empezará a convertir los hábitos de un equipo en política institucional.

Resumen rápido

• La anulación de un analista es una prueba, no una instrucción. Indica que un humano no estuvo de acuerdo, pero no demuestra que el humano tuviera razón.

• Dirija las anulaciones hacia un modelo retador. Manténgalas alejadas de la versión que toma las decisiones en ese momento.

• Una tasa de anulación aislada no se puede interpretar. Registre cada decisión y cada anulación con la versión que la produjo, y la cifra se convertirá en una comparación que responderá si el último cambio fue útil.

• Registre el desacuerdo, no solo la corrección. Conserve el valor del agente, el valor del humano y el motivo. Una anulación guardada como una simple edición destruye la señal en el mismo instante en que se crea.

• Evalúe la coherencia entre sus propios analistas antes de compararlos con un agente. La coherencia entre humanos es el límite de lo que un sistema puede aprender de ellos.

• Mantenga a una persona a cargo de la fase de aprobación y aporte pruebas en ese punto. Un cambio que soluciona el caso que tiene delante puede perjudicar de forma silenciosa todos los casos que no está examinando.

Aprender de las anulaciones de los analistas: la respuesta corta

¿Cómo debe utilizar un equipo de riesgos las anulaciones de los analistas para mejorar un agente de IA? Trate la anulación como una prueba, no como una instrucción. Regístrela como un evento que contenga el valor del agente, el valor del humano y el motivo, de modo que el desacuerdo se conserve en lugar de sobrescribirse. Envíe esa señal a un modelo retador (una versión candidata evaluada con los mismos datos de entrada al mismo tiempo, pero sin ejecutar ninguna acción) y no toque al campeón, que es la versión que toma las decisiones en tiempo real. La promoción es entonces un cambio deliberado que requiere pruebas en un conjunto de casos y una persona con autoridad para aprobarlo. Esto es lo que evita que un bucle de retroalimentación convierta silenciosamente los hábitos de un equipo en política institucional.

El botón en el que nadie se pone de acuerdo

Un cliente que estaba diseñando su propio flujo de trabajo de revisión nos hizo una pregunta que resume todo el problema. ¿El botón de anulación manual hace que se vuelva a ejecutar la verificación o cierra el caso? Se trata de acciones opuestas, y un sistema que no sabe distinguirlas aprenderá cosas sin sentido de ambas. Una es una solicitud de segunda opinión; la otra es una respuesta definitiva.

La misma ambigüedad aparece más adelante. El director de cumplimiento de delitos financieros de un banco, que ya había diseñado un flujo de trabajo de anulación pero no había terminado de definirlo, planteó lo que aún quedaba pendiente: "¿Cómo se hace eso? ¿Cuánto tiempo se conserva? ¿Cómo cambia? ¿Y debería volver a subir en algún momento?".

Esas son las preguntas correctas, y casi nada de lo publicado sobre las pruebas de campeón-retador las responde. Un bucle de retroalimentación basado en datos de anulaciones puede mejorar de forma medible a un agente, o puede convertir silenciosamente los hábitos de unos pocos analistas en política institucional. Desde fuera, ambos resultados se ven idénticos durante mucho tiempo.

Esta página explica qué puede hacer con los datos de anulaciones una vez que los tiene y qué impide que esa respuesta se convierta en un reentrenamiento descontrolado. Detectar que la coincidencia entre su agente y sus analistas ha cambiado es una tarea distinta que corresponde a la supervisión de la desviación del modelo.

Qué significan aquí los conceptos de campeón y retador

El campeón es la versión que toma las decisiones en tiempo real. El retador es una versión candidata que se ejecuta en paralelo con los mismos datos de entrada, generando resultados sobre los que nadie actúa. La promoción es la decisión de convertir al retador en el campeón. Los modelos de campeón-retador son un patrón consolidado en la gestión de riesgos de modelos, y las pruebas de este tipo en modelos de crédito es donde la mayoría de las instituciones reguladas los encuentran por primera vez.

Una aclaración, ya que la frase se usa con distintos sentidos. En la externalización y el riesgo de terceros, una estrategia de campeón-retador significa tener a un segundo proveedor en reserva para asegurar que el primero sea honesto. Eso es una táctica de compras y un tema diferente. Aquí, tanto el campeón como el retador son suyos.

El patrón se adapta a la retroalimentación por anulaciones porque el retador es el lugar adecuado para una señal en la que aún no confía plenamente. Una anulación es ese tipo de señal: información real, generada por alguien que estaba examinando el caso, pero de fiabilidad desconocida hasta que haya analizado muchas de ellas en conjunto. Enviarla a un retador no le cuesta nada ni le compromete a nada.

Lo que omiten las descripciones habituales de este patrón es el factor humano. Todos los análisis de campeón-retador promueven al retador basándose en métricas del modelo frente a datos reservados. Ninguno se pregunta qué hacer cuando lo que discrepa del campeón es una persona, con su propio criterio, una carga de trabajo y una interpretación de las pruebas ambiguas diferente a la del analista de la mesa de al lado.

El ciclo de vida de la anulación, tal como lo diseñó un banco real

El diseño de anulación más completo que hemos visto procedía de un departamento de cumplimiento normativo que lo iba desarrollando en voz alta. Vale la pena analizarlo porque es un ciclo de vida real de cuatro estados, y porque lo que deja fuera resulta ser el punto clave.

El derecho a anular es un control más que una capacidad general. En esta institución, cambiar la calificación de riesgo de un cliente estaba restringido a dos roles: el responsable de delitos financieros y el oficial de la BSA. Los analistas tenían un derecho menor: podían recomendar. Una propuesta de cambio iniciada por un analista se enviaba a una cola de espera, se confirmaba allí y regresaba a un rol de control para su aprobación como paso de control de calidad.

Esa distinción importa más de lo que parece. Una recomendación y una anulación aprobada son dos eventos distintos, y solo el segundo es una decisión que la institución defenderá. Un bucle de retroalimentación que los trata como una sola cosa aprende del evento equivocado. Qué rol debe tener cada derecho de revisión es una pregunta más compleja de lo que resuelve esta página; aquí se asume la división y se analiza su efecto en los datos.

La aprobación funciona en ambas direcciones. Cualquier anulación pasaba por el mismo proceso, tanto si aumentaba el riesgo como si lo disminuía. Las reducciones recibían el mismo escrutinio que los aumentos, lo cual es contrario al instinto de la mayoría de las instituciones pero representa un mejor diseño, ya que una anulación a la baja es la que suele ocultar algo.

La anulación se mantiene tras el recálculo de puntuaciones. El modelo seguía puntuando en su frecuencia trimestral habitual, y la decisión humana seguía prevaleciendo hasta que un humano la retiraba. La calificación se seguía ejecutando; el rango no se movía. Como explicó el director de cumplimiento, una anulación aplicada con justificación debería "estar activa hasta que decidamos quitarla", en lugar de ser borrada por el siguiente ciclo.

Se reabre por un cambio de estado y no por una fecha. Lo que devuelve una anulación a revisión es un cambio material en el comportamiento, como una nueva vía de pago o una desviación importante en la actividad. La liberación se realizaba en una revisión anual programada, donde se comprobaba si el motivo original seguía vigente.

Los cuatro estados por los que pasa una anulación y quién es responsable en cada uno.

Gobernanza sin medición

Lo que nunca se mencionó en toda esa conversación fue la medición.

No había tasa de anulación. Tampoco tasa de coincidencia entre el agente y los analistas. No existía ninguna métrica sobre el comportamiento de anulación y nadie planteó la posibilidad de que las anulaciones pudieran ser incoherentes entre los propios analistas. Todos los controles de coherencia descritos eran de carácter procedimental: restringir el derecho, canalizar las recomendaciones a través de una cola de espera, exigir la aprobación en ambas direcciones y mostrar la alerta al siguiente revisor.

Esos son buenos controles y responden a una pregunta diferente. El control procedimental le indica quién puede realizar la anulación. Solo la medición le indica si las anulaciones son lo suficientemente coherentes como para aprender de ellas.

Este no es el caso de una institución descuidada. Había diseñado más aspectos del ciclo de vida de la anulación que la mayoría, y el vacío es estructural: no hay herramientas estándar para medir la coherencia de las anulaciones, ni referencias publicadas, ni nada en su categoría que venga integrado por defecto. Por eso existe el resto de esta página.

La demanda es real y no es la preocupación de un solo banco. Un responsable de cumplimiento de otra entidad incluía "cómo se manejan las anulaciones, cómo se presentan y cómo se gestionan en los cambios de estado" entre sus preguntas pendientes antes de firmar nada. Un revisor de cumplimiento de un tercer banco preguntó si se podía bajar una puntuación "y documentar el motivo". Observe lo que aparece al mismo tiempo que la anulación: el motivo.

Una anulación es una prueba, no una instrucción

La mayoría de los sistemas tratan la anulación como una edición. El valor del humano sustituye al del agente, el valor antiguo desaparece y el registro muestra una decisión sin rastro de que algo haya sido cuestionado. El desacuerdo, que es la única información verdaderamente nueva de toda la transacción, se destruye en el momento en que se genera.

El diseño por el que hay que optar es un registro de eventos de solo adición (append-only) que contenga tres cosas: el valor del agente, el valor del humano y el motivo. Conservar ambos valores es lo que convierte el propio desacuerdo en datos. Puede contarlo, agruparlo y compararlo entre versiones. Nada de eso funciona en un campo que ha sido sobrescrito.

El campo del motivo no es un adorno. Es la única parte del registro que distingue una anulación correcta de una incoherente. Que dos analistas lleguen a conclusiones opuestas bajo el mismo código de motivo es un problema de formación; la misma conclusión por motivos diferentes es otra cosa. Como muestran las citas anteriores, esto es también lo que los clientes piden sin que nadie se lo proponga.

Por tanto, muéstrelo. El próximo analista que revise a ese cliente necesita un indicador de que hay una anulación manual activa, porque la anulación sirve de contexto para su decisión y no es solo una corrección de la del modelo. Si la oculta, dos revisores llegarán a conclusiones distintas a partir del mismo registro, que es precisamente la incoherencia que esta página busca resolver. Un agente que ya muestra los datos de entrada, su razonamiento y el resultado final en cada alerta tiene la mitad del camino hecho, y la anulación debe integrarse en ese historial de auditoría en lugar de quedar fuera.

Un punto importante sobre esto: tratar una anulación como un evento inmutable es una postura arquitectónica, no una función que se pueda comprar ya hecha en el mercado hoy en día. Tómelo como un principio de diseño que debe exigir a cualquier proveedor, incluyéndonos a nosotros.

Una disposición le indica lo que pensó un humano. Un resultado real le indica quién tenía razón.

Una disposición es un juicio registrado en el momento: el analista cerró la alerta, la escaló o la reportó. Un resultado real es lo que sucedió finalmente, como la transacción que resultó ser fraudulenta o el cliente que resultó ser lo que el analista sospechaba.

No se trata de la misma señal, y la diferencia determina si vale la pena crear su bucle de retroalimentación. Un bucle entrenado únicamente en disposiciones aprende a dar la razón a los analistas. Esto produce una mejora medible en la coincidencia, pero ninguna mejora en la precisión. Además, se retroalimenta a sí mismo, porque el sesgo de automatización hace que un revisor que confía en el agente lo apruebe sistemáticamente, lo que aumenta la coincidencia y hace parecer que el sistema funciona correctamente.

Los datos de los resultados reales pueden introducirse a través de las mismas interfaces utilizadas para tomar decisiones; por ejemplo, marcando de nuevo como sospechosa una transacción aprobada la semana pasada una vez que se dispone de más información. Eso transforma una prueba retrospectiva de un simple "la decisión habría sido diferente" a algo sobre lo que una institución puede actuar: habríamos rechazado estos casos específicos, y esta proporción de ellos era realmente sospechosa.

La instrucción práctica es sencilla: mida ambas variables y nunca deje que una cifra de coincidencia sea la única prueba de calidad.

Una sola tasa de anulación no dice nada. Una comparación sí dice algo.

Una tasa de anulación de forma aislada no se puede interpretar. La misma cifra podría describir a un agente excelente revisado por analistas minuciosos, o a un agente mediocre revisado por analistas pasivos, y el número no permite distinguir ambos casos. Aun así, las instituciones se citan estas cifras entre sí, lo que hace que la métrica deje de aportar información útil.

Se vuelve interpretable en el momento en que se convierte en una comparación. Registre en cada decisión y en cada anulación la versión de la configuración y de las instrucciones que la produjeron, y la pregunta pasará a ser algo que puede responder: ¿ayudó el último cambio? Eso es mucho más útil que preguntarse si un ocho por ciento es una buena cifra.

La segunda medición que vale la pena implementar tiene que ver con la distribución de los datos más que con el volumen. Las anulaciones dispersas en casos sin relación entre sí son el reflejo del criterio del revisor haciendo su trabajo. Las anulaciones concentradas en una característica compartida, como el mismo tipo de cliente, la misma tipología o el mismo vacío de datos, representan un patrón que el agente está fallando de manera sistemática. Defina el umbral de concentración a partir de su propio volumen; no existe una cifra estándar en el sector que sea defendible, y debería desconfiar de cualquiera que le ofrezca una.

Puede establecer la referencia más importante antes de comprar absolutamente nada. Mida la coincidencia de sus analistas entre sí en los mismos casos, de forma anónima. La coherencia entre humanos es el límite máximo de lo que cualquier bucle de aprendizaje puede extraer de ellos, y la mayoría de las instituciones nunca lo han analizado. Si dos de sus revisores coinciden entre sí el setenta por ciento de las veces, un agente que coincide con ellos el ochenta y cinco por ciento de las veces no es lo primero que necesita corregir.

Para tener una idea de cómo se ven estas cifras en la práctica, un banco en fase de despliegue muestra un 92 % de coincidencia del agente con su equipo de analistas en la disposición de alertas y un 75 % menos de tiempo por revisión. Si lo lee al revés, representa una tasa de desacuerdo del 8 %, que es la señal de anulación de la que trata esta página. Tómelo como un caso particular de despliegue y no como una referencia que deba esperar; lo útil es la estructura de la medición más que el valor en sí. Las tasas de anulación deben mostrarse en el mismo panel que sus otros KPI de resultados medidos por segmento, ya que lo habitual es encontrar una tasa que parece correcta en el agregado pero que resulta pésima en un segmento específico.

Dirija la señal a un retador, no al modelo en producción

Todo el argumento se reduce a una regla. Los datos de anulación modifican a un retador. Nunca modifican la versión que toma las decisiones en producción actualmente.

La promoción requiere entonces tres condiciones: pruebas en un conjunto de casos y no en un único evento, porque un cambio justificado por una sola alerta no es un cambio real; una comparación directa frente al campeón utilizando los mismos datos de entrada; y una persona identificada con autoridad para aprobar el cambio.

En esta última condición, el lenguaje del regulador es más preciso que el nuestro. La guía interinstitucional revisada sobre la gestión de riesgos de modelos, publicada el 17 de abril de 2026 como SR 26-2 por la Reserva Federal, Bulletin 2026-13 por la OCC y FIL-15-2026 por la FDIC, mantiene el concepto de "desafío efectivo" (effective challenge) y especifica quién puede realizarlo: personas con "la experiencia adecuada para llevar a cabo una evaluación crítica y objetiva, la independencia suficiente para mantener la objetividad, así como la posición organizativa y la influencia necesarias para implementar cualquier cambio". Un revisor que no puede modificar el resultado no cumple con la tercera condición. Esto describe perfectamente los dos roles de control elegidos por el banco mencionado anteriormente, y es una prueba viable para quien tome las decisiones de promoción en su organización. El registro de auditoría que deja tal decisión tiene sus propios requisitos, que se detallan en lo que debe soportar un historial de gobernanza para un agente de riesgo de IA.

Dos precisiones sobre esa guía, ya que es fácil malinterpretarla. Indica que "se prevé que sea más relevante para organizaciones bancarias con más de 30 000 millones de dólares en activos totales", lo cual no significa que se aplique exclusivamente a ellas. Además, deja fuera de su alcance los modelos de IA generativa y basados en agentes, con solo una solicitud planificada de información sobre el uso de la IA por parte de los bancos. Por lo tanto, ningún marco supervisor le dice actualmente cuánta intervención humana necesita la decisión de un agente. No puede buscar la respuesta en un manual; tiene que decidirla, documentarla y ser capaz de defenderla, razón por la cual vale la pena hacer esto bien en lugar de tratarlo como un simple trámite de cumplimiento.

Un mito que conviene desmentir: aprender de las anulaciones suena a reentrenar un modelo, pero en el caso de un agente normalmente no lo es. El ajuste diario consiste en un cambio de versión de la configuración y de las instrucciones, no del modelo subyacente, lo cual es más auditable y más fácil de revertir. El concepto académico equivalente, el aprendizaje activo en aprendizaje automático (active learning), describe cómo se solicita de forma selectiva a un humano que clasifique los casos en los que el modelo tiene menos certeza. Los datos de anulación son el mismo instinto pero en la dirección opuesta: llegan de forma espontánea y asociados a una decisión real.

Cómo se ve un proceso correcto, en pocas palabras: el bucle cuenta con un humano en la fase de aprobación y esta fase se basa en pruebas.

Por qué solucionar un solo caso puede empeorar todo lo demás

El motivo técnico de este temor es muy concreto. Añadir contexto para solucionar un caso específico puede reducir la calidad general en todo el conjunto de datos. El cambio que resuelve la alerta que tiene delante (ya sea una instrucción más, un dato de contexto adicional o una excepción nueva) puede perjudicar casos que no está examinando, y nada se lo indicará a menos que esté evaluando el conjunto completo y no solo el caso individual.

Este mismo razonamiento explica por qué en tareas críticas no se debe dejar que un modelo decida qué tipologías considerar. Una tipología omitida no se puede justificar a posteriori ante un oficial de cumplimiento, y el contexto irrelevante reduce de forma medible la calidad del resultado. Un enfoque acotado y determinista supera a uno amplio e inteligente cuando alguien tiene que defender el resultado final.

Por lo tanto, la secuencia debe seguir este orden, y vale la pena redactarla como preguntas de evaluación de proveedores:

1. Agregar. Recopile las anulaciones como eventos, con ambos valores y el motivo, en un volumen suficiente para identificar tendencias.

2. Presentar el patrón a una persona. Una acumulación de casos es una hipótesis, no una solución automática; debe enviarse a alguien que pueda evaluarla, no a un proceso de reentrenamiento automático.

3. Permitir que la persona decida si se cambia algo. La mayoría de las acumulaciones de casos no deberían dar lugar a ningún cambio.

4. Implementar el cambio con control de versiones, con un registro de quién lo cambió, cuándo, por qué y a partir de qué eventos originales.

5. Condicionar el cambio a una fase de evaluación frente a un grupo de casos reservado, nunca frente al caso específico que motivó el cambio.

Vale la pena adoptar dos reglas ahora mismo como preguntas para cualquier proveedor sobre la automatización futura de ese bucle: el sistema propone y el humano aprueba, y nada se lanza sin pasar por una fase de evaluación previa. Ninguna de las dos es una promesa comercial; es la restricción que cualquiera que construya esto con honestidad termina aceptando.

Qué se puede medir hoy y qué no se puede medir todavía

Hay tres cosas disponibles sin necesidad de nuevas herramientas. El historial de razonamiento en cada recomendación, que es lo que hace que una anulación sea interpretable y no solo un registro. Los agentes que se ejecutan en toda la cola de espera en lugar de en una muestra, lo que significa que el denominador de cualquier tasa de anulación es el real. Y su propio historial de disposiciones, que es una base de referencia que ya posee y que probablemente nunca ha medido.

Ahora, el límite explicado con claridad: no existe una referencia publicada para la coherencia de las anulaciones, y esta página no va a inventar una. Lo que sí puede decirle es qué comparaciones son útiles: el mismo agente en dos versiones distintas, la comparación entre sus propios analistas y la comparación de una acumulación de casos frente a la distribución general. También puede decirle cuáles no sirven: cualquier tasa de anulación que se cite sin su denominador o su versión correspondientes.

Parte de esto aún no está disponible como producto. Evaluar el cumplimiento de las anulaciones con respecto a su propio procedimiento escrito a gran escala es una línea de desarrollo activa y no algo de lo que se disponga hoy en día. Una valoración sencilla (como un pulgar hacia arriba o hacia abajo sobre el resultado del agente) es una señal más débil que una anulación, porque registra la insatisfacción pero no cuál habría sido la respuesta correcta. Recopílela, pero no construya un bucle de aprendizaje basado en ella.

Dos aspectos que esta página deja de lado deliberadamente de forma intencionada. Detectar que la coincidencia ha cambiado (es decir, que su tasa de anulación está aumentando y necesita saber por qué) es un problema de supervisión y desviación, y es previo a todo lo que se explica aquí. Los límites que se establecen antes de que comience un despliegue (incluida la tasa de coincidencia que aceptará y qué hará si no la alcanza) corresponden a los criterios de evaluación definidos al principio, y no al diseño de retroalimentación que construya después.

Preguntas frecuentes

¿Qué es un modelo campeón-retador?

Un modelo campeón-retador ejecuta dos versiones de un modelo o agente a la vez: el campeón toma las decisiones en tiempo real, mientras que el retador puntúa los mismos datos de entrada sin realizar ninguna acción. La promoción es la decisión de intercambiarlos, y debería requerir pruebas en múltiples casos además de un aprobador humano identificado. En la gestión de riesgos de terceros, el mismo término se refiere a tener un segundo proveedor en reserva, lo cual es una práctica diferente.

¿Cuál es la diferencia entre una anulación y un error del modelo?

Una anulación es una decisión humana de apartarse del resultado del modelo. Un error del modelo es que este se equivoque. Ambos conceptos se solapan sin ser lo mismo: una anulación puede ser un error del humano, una corrección acertada de un error real del modelo o una decisión subjetiva en un caso realmente ambiguo. Saber cuál de ellos ha sido es una pregunta que se responde mediante la medición, y la simple existencia de la anulación no la resuelve.

¿Cómo se distingue una anulación correcta de una incoherente?

Dos señales facilitan esta tarea: el código de motivo y la concentración de los casos. Las anulaciones dispersas en casos sin relación entre sí y con motivos variados reflejan el criterio del revisor funcionando con normalidad. Las anulaciones concentradas en una característica compartida apuntan a un patrón que el agente está fallando, y los códigos de motivo idénticos que producen conclusiones opuestas señalan una falta de coherencia entre los revisores, no un fallo en el agente.

¿Cuánto tiempo permanece válida una anulación?

Es mejor responder a esto con un cambio de estado en lugar de con un plazo de tiempo. Una anulación debería mantenerse a lo largo de los ciclos normales de recálculo de puntuación hasta que un humano la retire, reabrirse cuando el comportamiento del cliente cambie de forma sustancial (como un nuevo canal de pago o una desviación importante de la actividad) y revisarse en una evaluación programada donde alguien compruebe si el motivo original sigue vigente. Una fecha de caducidad fija es más fácil de implementar pero no aporta información sobre si el motivo sigue aplicando.

¿Deberían las anulaciones de los analistas reentrenar el modelo de forma automática?

No. Los datos de las anulaciones deberían modificar a un retador, nunca a la versión que toma las decisiones en producción en ese momento, y la promoción de ese retador debe ser una decisión humana respaldada por pruebas en un conjunto de casos. El reentrenamiento automático a partir de anulaciones enseña al sistema a dar siempre la razón a sus revisores, lo que aumenta la coincidencia pero no mejora la precisión. También implica que un cambio que soluciona un caso concreto puede perjudicar otros casos que nadie está revisando.

¿Qué condiciones deben cumplirse antes de promover un modelo retador a campeón?

Tres cosas: pruebas en un conjunto de casos en lugar de solo en el caso que motivó el cambio; una comparación directa frente al campeón con los mismos datos de entrada durante el mismo período; y un aprobador con la experiencia, la independencia y la posición organizativa para realizar el cambio, además de un registro de quién lo aprobó, cuándo y con qué pruebas.

¿Quién autoriza la promoción de un modelo que ha aprendido de las decisiones de los analistas?

La guía interinstitucional actual sobre la gestión de riesgos de modelos describe el estándar mediante el "desafío efectivo": la persona debe contar con la experiencia adecuada, la independencia suficiente para mantener la objetividad, y la posición e influencia organizativas para realizar el cambio. En la práctica, esto apunta a una función de control y no al equipo que desarrolló o gestiona el agente. Un revisor que no puede modificar el resultado no cumple con la tercera condición.

¿Cómo se evita que un bucle de retroalimentación convierta los hábitos de un analista en política institucional?

Cuatro controles, en orden: restrinja quién puede generar una anulación autorizada, para que no el criterio de cualquier revisor entre en la señal de aprendizaje; registre un motivo en cada ocasión; evalúe el conjunto de casos y no el caso individual, de modo que el efecto de un cambio en todo lo demás siga siendo visible; y condicione la promoción a una decisión humana basada en pruebas, para que ningún hábito llegue a producción sin que alguien lo elija deliberadamente.

¿Puede la retroalimentación por anulaciones funcionar con los sistemas de riesgo existentes de una institución?

Sí, y normalmente es necesario que así sea. Los agentes pueden funcionar como una capa independiente sobre la infraestructura que ya tiene, o como parte de una plataforma unificada, y el registro de anulaciones funciona del mismo modo en ambos casos: un evento de solo adición que contiene el valor del agente, el valor del humano y el motivo, marcado con la versión que produjo la decisión. Lo importante es que las anulaciones se guarden en un lugar donde se puedan consultar junto a las decisiones que cuestionan, en lugar de tener que sustituir todo el sistema tecnológico.

Por dónde empezar

La parte de gobernanza de este problema se conoce bien, pero la parte de medición no. Las instituciones saben cómo limitar quién puede anular una decisión y cómo canalizar una aprobación. Casi ninguna puede decir si sus anulaciones son coherentes. Si está diseñando un flujo de trabajo de anulación ahora, lo que debe añadir son las herramientas de medición que le indiquen si los controles están generando una señal de la que valga la pena aprender.

Comience con lo que ya tiene: la coincidencia de sus analistas entre sí, sus registros históricos de decisiones y la determinación de registrar las anulaciones como eventos que incluyan ambos valores y un motivo desde el primer día, en lugar de intentar adaptarlo más tarde. Para ver cómo es un historial de decisiones diseñado para esto, los agentes de IA de Oscilar muestran los datos de entrada, el razonamiento y el resultado de cada alerta, que es el material básico que requiere la medición de una anulación.