Criterios de aceptación para una prueba de concepto de un agente de riesgo de IA

Última actualización: septiembre de 2026

Una prueba de concepto de IA solo vale la pena si tiene la posibilidad de fallar. Antes de que un agente procese una sola alerta, deben quedar por escrito cuatro cosas: el umbral que debe superar cada medición, los datos que se usarán en el ejercicio, las personas que certificarán que se alcanzaron los umbrales y qué sucederá si no se logran. Resuelvan eso y un ejercicio breve generará una decisión. Déjenlos abiertos y obtendrán unas semanas de resultados interesantes seguidas de otra reunión.

Esta página es la lista de aspectos a resolver antes de la primera semana, escrita desde la perspectiva del comprador. La mayor parte de las guías publicadas sobre cómo realizar una POC de IA provienen de empresas que desearían realizarla para usted, por lo que muy pocas explican cómo establecer una cifra que podría resultar incorrecta.

En resumen

• Los criterios de aceptación escritos después de que llegan los resultados no son criterios. El ejercicio deja de ser una prueba y se convierte en una historia sobre lo que pasó.

• La velocidad es lo más fácil de demostrar y lo que menos información aporta. Un agente que es más rápido pero se equivoca es peor que la cola de tareas que ya tiene.

• Hay tres cosas que deben quedar por escrito antes de la fecha de inicio: un cronograma definido, criterios de éxito firmados por ambas partes y un ejecutivo que ya haya confirmado que cumplir con esos criterios significa seguir adelante.

• La elección de los datos determina lo que se puede demostrar. Sin las decisiones registradas por sus analistas, no habrá una cifra de acuerdo posible, por muy bien que vaya el ejercicio.

• Establezca umbrales para la coincidencia, el desacuerdo inexplicable, la integridad de la población evaluada, la suficiencia de pruebas, el tiempo de revisión, el comportamiento ante datos faltantes y la auditabilidad. Defina el umbral para los verdaderos positivos omitidos por separado y manténgalo bajo.

• Esas dimensiones se agrupan en cuatro categorías: calidad de las decisiones, encaje operativo, viabilidad comercial y una regla de decisión por escrito. Cambie las cifras si lo necesita, pero mantenga estas cuatro categorías.

• Nadie puede decirle qué números elegir. No existe un estándar de referencia publicado para los umbrales de aceptación de agentes, así que mida primero su propio punto de partida, incluyendo con qué frecuencia sus analistas coinciden entre sí. El ejemplo práctico de esta página es el conjunto de un equipo en particular, elegido antes de ver cualquier resultado, y no una cifra para copiar.

• Deje por escrito el camino a seguir en caso de fallo. Una prueba de concepto sin consecuencias acordadas ante un fallo no puede considerarse fallida.

La prueba de concepto que se aprueba pero no cambia nada

Los compradores rara vez piden una prueba de concepto por simple curiosidad. Lo hacen porque la última compra no salió bien. Un responsable de contratos y riesgos regulatorios en una institución lo explicó claramente: la solución actual no es lo que el equipo quería, y nadie quiere volver a pasar por una implementación para luego descubrir que había cosas que sencillamente no podían hacer. Un líder de ingeniería de la misma institución comentó que el patrocinador ejecutivo quería probar lo mismo porque no quería verse en la situación en la que ya se encontraba el equipo.

Vale la pena recordar ese motivo, porque explica por qué los criterios importan más que la demostración. El ejercicio es un seguro contra una mala experiencia repetida, por lo que debe ser capaz de arrojar un resultado negativo.

El fracaso del que debe protegerse se encuentra en el otro extremo. Ambos equipos pasan semanas en la configuración, las mediciones acordadas salen bien y el patrocinador ejecutivo decide quedarse con el proveedor actual de todos modos. Describimos esto como correr hacia un semáforo en rojo, y cuando se lo planteamos a un líder de ingeniería en un acuerdo real, la respuesta fue inmediata: era una observación muy justa y lo habían visto suceder muchas veces.

Hay dos factores detrás de esto, y en realidad son el mismo factor repetido. Los criterios elegidos después de que aparecen los resultados son imposibles de incumplir. Los criterios que solo miden la velocidad tampoco fallarán, porque un agente siempre será más rápido que una persona leyendo una alerta. En ambos casos, el ejercicio no tiene margen de fallo, lo que significa que no puede fundamentar una decisión.

Qué es y qué no es una prueba de concepto de un agente de riesgo de IA

Una prueba de concepto de IA es un ejercicio con un plazo definido que evalúa si un agente puede realizar una tarea específica con sus datos, bajo un estándar acordado antes de iniciar el trabajo. Para un agente de riesgo, esa tarea suele ser un juicio de valor en lugar de una labor repetitiva: determinar el cierre de una alerta, reunir las pruebas de un caso o decidir qué es lo siguiente que debe ver un revisor.

Los términos relacionados suelen usarse indistintamente, pero justifican conclusiones muy diferentes.

La diferencia que lo decide todo es la última. Una prueba de concepto pregunta si puede funcionar. Una prueba de valor pregunta si vale la pena el costo. La mayoría de los ejercicios decepcionantes se vendieron como lo primero y se evaluaron como lo segundo, y esa brecha sale a la luz al final, cuando se cumplen los criterios pero la decisión de compra sigue sin llegar.

Una prueba de concepto de aprendizaje automático tiene un objetivo más sencillo que la de un agente. En el primer caso, se evalúa si un modelo predice lo suficientemente bien frente a un resultado etiquetado. Con un agente de riesgo, se evalúa si un juicio de valor es lo suficientemente bueno como para que un analista actúe en consecuencia, y esa pregunta no tiene respuesta hasta que se tenga algo con qué comparar ese juicio. Todo lo que se explica en la sección de datos a continuación se deriva de esto.

Un límite antes de los criterios. Definir sobre qué dimensiones se debe juzgar a un agente es un ejercicio aparte, detallado en cómo evaluar un agente de riesgo de IA antes de llevarlo a producción. Esta página comienza un paso después: en las condiciones de aprobación que necesitan esas dimensiones.

Cuándo vale la pena realizar una prueba de concepto y cuándo no

Realice una cuando se cumplan tres condiciones: tiene decisiones históricas con las que comparar; su volumen de alertas es suficiente para generar una muestra representativa; y una persona específica asumirá la responsabilidad de la decisión final.

No la realice si los criterios van a ser genéricos. El responsable de crecimiento de un equipo de compras describió muy bien esta brecha cuando le preguntaron si tenían un documento de requisitos comerciales para la funcionalidad que evaluaban: tenían uno muy general, y por eso se dieron cuenta de que necesitaban a un responsable para el proyecto, ya que debían ser más específicos sobre la tolerancia al riesgo y los controles que querían implementar. Aún no habían contratado a esa persona, por lo que no se conocía a los interesados clave de su lado y el resultado estaba indefinido antes de empezar. Identificaron el problema y lo solucionaron en el orden correcto, algo que la mayoría de los equipos no logra hacer.

No la realice si nadie tiene la autoridad para tomar medidas tras una aprobación. Ese es el semáforo en rojo, y la respuesta correcta es posponer la prueba en lugar de avanzar con cautela.

No la realice todavía si su cola de tareas genera un ruido que el agente procesará al pie de la letra. Un agente expuesto a una cola llena de duplicados solo demostrará que los duplicados existen. Primero es necesario hacer una limpieza básica de las reglas.

La pregunta para el diagnóstico es sencilla: si el agente funciona exactamente como usted espera, ¿qué decisión se tomará la próxima semana y quién la tomará? Si no hay respuesta para eso, los criterios aún no están listos.

Tres cosas a resolver antes de la primera semana

Antes de iniciar cualquier prueba de concepto, deben existir tres condiciones:

Un cronograma definido. Una fecha de inicio, una de finalización y un hito claro para el cierre. La intención de terminar "en unas semanas" no es un cronograma.

Criterios de éxito mutuamente acordados, firmados por responsables de ambas partes. La palabra clave aquí es "mutuamente". Los criterios que escribe una sola parte son una lista de deseos o un guion de ventas, según quién los escriba. Identifique a las personas que validarán el cumplimiento de los criterios y registre sus nombres antes de cargar la primera alerta.

Alineación ejecutiva previa. El patrocinador ejecutivo declara, antes de comenzar el trabajo, que cumplir con estos criterios significa seguir adelante con el proyecto. La mayoría de los compradores tratan esto como un paso posterior. Sin embargo, es el único requisito previo que evita el semáforo en rojo, ya que convierte un resultado técnico en una decisión con la que alguien ya se ha comprometido previamente.

Dos aportes que deben estar en la misma página:

Defina los precios antes de realizar el ejercicio y no después. Una prueba de concepto que tiene éxito técnico pero fracasa por una sorpresa en el presupuesto ha fallado. Los datos necesarios para una cotización se pueden conocer de antemano: volúmenes previstos por línea de negocio y procesos de incorporación esperados. Esperar semanas durante el ejercicio para obtener la información financiera es la fórmula para que un buen resultado quede estancado.

Luego, acuerde qué flujos de trabajo internos se ejecutarán en paralelo, ya que esa tensión no se resuelve sola. Un líder de ingeniería en una negociación fue muy directo: uno o dos meses para la incorporación del proveedor y el trabajo preliminar es razonable, pero no iban a iniciar ese proceso ni a pedir la firma de la gerencia antes de que el equipo pudiera demostrar que era capaz de usar la solución.

El interés del proveedor va en sentido contrario, ya que terminar el ejercicio y luego descubrir que la contratación toma otras seis semanas añade un trimestre más al calendario. Ninguna de las dos partes se equivoca. Decida explícitamente qué revisiones comienzan ahora y cuáles pueden esperar.

Calibrado o a ciegas: la elección de datos que determina lo que se puede demostrar

Comience por definir el alcance, porque fijar el alcance y elegir los datos son la misma decisión. Los criterios escritos para un alcance ambiguo generarán discusiones más adelante, y esa discusión llegará en la tercera semana, cuando ya resulta costoso. Esta página incluye un ejemplo práctico de principio a fin: un agente para el triaje de alertas de nivel 1 en prevención de lavado de dinero (AML), y en ese ejemplo el alcance se define primero.

La fila que los equipos omiten con más frecuencia es la tercera. Si ya tiene una herramienta de inteligencia de dispositivos, deje en claro que el ejercicio no evaluará esas señales; de lo contrario, perderá dos semanas comparando al agente con una función que ya posee. Una exclusión por escrito en el arranque es mucho más fácil de defender que una discutida en la tercera semana.

Luego viene la elección de datos. Es la decisión más importante del proceso y, a menudo, la que se toma por accidente.

Un ejercicio calibrado se realiza con sus alertas históricas junto con los motivos de cierre que sus analistas registraron en su momento. Al contar con las decisiones pasadas, la coincidencia se vuelve medible: para cada alerta puede preguntar si el agente llegó a la misma conclusión que su equipo y, si no fue así, por qué.

Un ejercicio a ciegas se realiza sin contar con esas resoluciones previas. Verá el análisis completo del agente en cada caso, pero no podrá generar una cifra de coincidencia, por muy bien que vaya. El análisis no tiene contra qué compararse.

La trampa está en mezclar ambos enfoques. Un comprador que no ha tomado esta decisión conscientemente suele aceptar un ejercicio a ciegas esperando obtener un resultado calibrado. Lo que sucede entonces es predecible: el equipo evalúa al agente según si su razonamiento parece lógico. Eso es solo una demostración interactiva de mayor duración.

Una tercera opción es perfectamente válida y a menudo la correcta. Si sus resoluciones están guardadas en notas no estructuradas, puede esperar a que se registren en un formato estructurado como parte del proceso habitual y realizar el ejercicio calibrado más adelante con un punto de partida más limpio. Elegir esto deliberadamente es un mejor resultado que hacer un ejercicio a ciegas y llamarlo calibrado.

Los datos sintéticos tienen un valor real, pero su utilidad es más acotada de lo que parece. Al estar formateados con su propio esquema, eliminan por completo el trabajo de integración, por lo que el ejercicio puede comenzar sin requerir tiempo de desarrollo por su parte y las pantallas se verán tal como serían en producción. Sea preciso sobre lo que esto demuestra: que el flujo de trabajo procesa bien la estructura de sus datos, no que el juicio del agente coincida con el de sus analistas.

El conjunto de 1200 casos del ejemplo anterior representa cómo se ve una ejecución calibrada completa al final. Los datos iniciales necesarios para comenzar son sencillos:

• Aproximadamente 25 alertas históricas para comenzar, o de 25 a 50 con sus respectivos motivos si estos se encuentran en documentos en lugar de campos de datos estructurados.

• De 60 a 90 días de historial de transacciones para las entidades de esas alertas, según su propio procedimiento.

• Datos básicos de identidad y entidad.

• Una sesión de unos 45 minutos observando cómo trabajan sus analistas con las alertas hoy en día.

Ese último paso es el que más se omite y en el que se apoya toda la medición. No puede definir un umbral de coincidencia con sus analistas sin observar primero cómo trabajan en su día a día.

Los criterios de aceptación, dimensión por dimensión

Hay ocho dimensiones clave para las que vale la pena definir un umbral, agrupadas en cuatro categorías: calidad de las decisiones (lo que el agente debe acertar), encaje operativo (si realmente es fácil de usar en el día a día), viabilidad comercial (si justifica la inversión) y una regla de decisión por escrito para la revisión.

Cambie las cifras si lo necesita, pero mantenga estas cuatro categorías. Un conjunto de criterios al que le falte alguna de ellas tendrá fallos predecibles: sin criterios de calidad de decisión, terminará discutiendo si el resultado fue bueno; sin criterios operativos, tendrá un ejercicio que funciona pero que nunca se lleva a producción; sin criterios comerciales, la compra se estancará en adquisiciones; y sin una regla de decisión, se quedará atrapado en constantes extensiones de plazos.

Es mejor enfocarse en evaluar menos criterios pero que sean decisivos. Tres o cuatro factores que realmente cambien su respuesta son mejores que una docena que solo generen un reporte que nadie utiliza. Si no cumplir con un criterio no va a cambiar su decisión de compra, no lo use como un filtro de aprobación: mídalo, pero no lo condicione.

Comparta los criterios antes de arrancar. El valor de hacer esto está en sacar a la luz los desacuerdos cuando todavía es sencillo y barato resolverlos. Si el líder de riesgos y el de operaciones escriben objetivos diferentes para la primera fila, esa es una conversación que vale la pena tener en la semana cero y no una discusión en la semana cinco.

Este es el entregable que necesita. Defina un umbral para cada dimensión, por escrito, antes de que comience el ejercicio. La tercera columna representa la parte más importante del trabajo, porque nadie más puede definir estas cifras por usted.

Seis de esas ocho filas corresponden a la calidad de las decisiones y el sustento de las mismas; el tiempo por revisión y la auditabilidad corresponden al encaje operativo. La viabilidad comercial no aparece en esta tabla, lo cual representa la omisión más común de las cuatro y la que suele estancar los proyectos que técnicamente funcionaron.

La prueba más clara de este conjunto provino de un comprador en lugar de un proveedor. Un líder de ingeniería propuso procesar la misma población de casos a través del sistema actual y del candidato, comparando ambos flujos mientras los analistas observaban cómo se resolvía y evolucionaba cada caso. Es una métrica medible, no requiere de la ayuda del proveedor para definirse y funciona para cualquier agente. Insista en implementarla.

Dos cosas quedan fuera del alcance de estos umbrales. Quién tiene qué derecho de revisión una vez que el agente esté activo es una pregunta de diseño independiente, que se resuelve para cada cola de trabajo según sus propios procedimientos y no durante la prueba de concepto.

Lo segundo es qué hacer con los datos de las discrepancias después del despliegue, a medida que se acumulan las modificaciones manuales y aparecen patrones en ellas. Durante el ejercicio, las discrepancias son una métrica de medición. Después se convierten en un ciclo de retroalimentación, y eso requiere su propio responsable.

Mientras define el umbral de suficiencia de pruebas, verifique qué información adjunta el agente a cada recomendación. La pregunta útil aquí es si el razonamiento, las pruebas y las tipologías llegan en un formato que un revisor pueda aprovechar directamente, más allá de si la recomendación en sí es correcta.

Hablemos con honestidad: no existen estándares de referencia publicados para los umbrales de aceptación de agentes, ni en las guías de supervisión ni en ningún otro lugar que hayamos podido encontrar, incluyendo esta página. Podemos sugerirle qué dimensiones evaluar, pero no podemos decirle qué número elegir. Cualquiera que le dé una cifra sin conocer su volumen y tipo de alertas solo está adivinando.

Por lo tanto, mida primero su punto de partida. Averigüe con qué frecuencia dos de sus analistas llegan a la misma resolución para una misma alerta, porque esa cifra es el límite máximo de lo que puede significar la coincidencia con un agente. Si sus propios analistas coinciden entre sí con menos frecuencia que el objetivo que está por definir para el agente, ese objetivo no es ambicioso, sino poco realista.

Un caso real nos muestra cómo se ve un umbral cuando se ha definido correctamente. Un banco en producción muestra un 92% de coincidencia del agente con su equipo de analistas en la resolución de alertas y un 75% menos de tiempo por revisión. Tome esto como una prueba de viabilidad y no como una métrica garantizada: se trata de una institución específica, con sus propios flujos de trabajo, procedimientos y criterios de coincidencia.

La razón para analizar esto es la combinación: una tasa de coincidencia junto con una cifra de tiempo dicen algo que el dato del tiempo por sí solo no puede demostrar.

Un ejemplo práctico: Triaje de alertas AML de nivel 1

A continuación se muestran los criterios de un equipo para el alcance definido anteriormente en esta página. Se presentan como ejemplo porque una lista de dimensiones es más fácil de entender cuando se ve en la práctica. Cada cifra es un objetivo para este caso, elegido antes de que el equipo viera un solo resultado. El 92% mencionado antes y el 85% de abajo no representan lo mismo: uno es una medición real de un despliegue y el otro es un umbral que alguien definió con anticipación para su propio flujo. Preste atención a las columnas, no a los valores numéricos.

Calidad de las decisiones: lo que el agente debe acertar. La referencia aquí es el histórico de resoluciones de sus propios analistas y no la cifra de precisión del proveedor, que describe una mezcla de alertas ajena a su realidad.

La segunda fila tiene un cero absoluto porque, en lo que respecta a omisiones de alto riesgo, la tolerancia de este equipo era cero. Dejarlo en claro en el arranque es lo que evita discusiones sobre promedios durante la revisión final.

Encaje operativo: si realmente es fácil de usar. Aquí es donde la mayoría de los ejercicios se ven bien sobre el papel pero no logran implementarse. Un agente que genera recomendaciones excelentes en un sistema donde los analistas no trabajan habitualmente no aporta ningún valor real.

Esa última prueba es deliberadamente exigente y es la que más vale la pena mantener. La pregunta clave no es si existe un registro de actividad, sino si ese registro podrá responder a las preguntas de un auditor dentro de once meses, cuando el analista que llevó el caso ya se haya cambiado de área.

La viabilidad comercial: si justifica la inversión. Omitir este análisis es la razón por la que pruebas técnicamente exitosas se estancan antes de concretar la compra.

La segunda fila merece un análisis sincero antes del ejercicio y no después. Con volúmenes de casos bajos y un procesamiento manual económico, un agente puede costar más por acción que el trabajo que reemplaza; si ese análisis financiero no cuadra con su volumen actual, tendrá éxito en lo técnico pero fracasará en lo comercial, haciendo perder el tiempo a todos durante un mes.

La tercera fila es más importante de lo que parece. La eficiencia por sí sola no es un resultado tangible que pueda mostrar en seis meses. Lograr que el retraso de nivel 2 pase de tres semanas a cinco días sí lo es.

Termine la primera semana con una tabla estructurada de este tipo para cada cola de trabajo. Definir qué tipos de alerta permiten resolver una recomendación con un solo clic y cuáles deben derivarse siempre a revisión manual es un asunto de tolerancia al riesgo, no de tecnología. Establecer esos límites es parte de la preparación del ejercicio y no un resultado posterior; cualquier plan de trabajo que posponga estas definiciones carece de un entregable clave.

Las etapas y los puntos de control entre ellas

Pida a cualquier proveedor un esquema estructurado en cuatro partes: preparación de datos, prueba retrospectiva (backtest) con sus alertas históricas, ejecución en paralelo (shadow run) y presentación de resultados. Esta es la estructura recomendada para una evaluación seria antes de llevar la solución a producción, y vale la pena exigirla por su nombre para verificar si la propuesta que recibe incluye todas las etapas.

Los puntos de control (gates) son más importantes que la secuencia en sí. Cada transición debe tener una condición de salida definida por escrito de antemano:

• La preparación de datos finaliza cuando la muestra acordada está cargada y los datos de las resoluciones previas están listos, o bien el equipo ha aceptado conscientemente realizar un ejercicio a ciegas.

• La prueba retrospectiva finaliza cuando se obtienen las métricas de coincidencia y de verdaderos positivos omitidos, y se comparan objetivamente con los umbrales definidos, no según sensaciones.

• La ejecución en paralelo finaliza cuando el agente ha procesado datos reales en producción sin generar alertas, casos o acciones posteriores, y su desempeño se ha comparado con lo que los analistas hicieron realmente con esos mismos casos.

• La presentación de resultados cierra el ejercicio, y esto solo ocurre cuando se define una decisión de compra y un cronograma de implementación concretos.

Consulte también sobre los estados por los que pasa un agente antes de tomar una decisión en producción. El camino correcto debe ser gradual: primero se prueba en un entorno aislado, luego se ejecuta en paralelo con datos reales de producción sin generar alertas ni casos, después se realiza un experimento controlado asignando un porcentaje del volumen al agente frente a un grupo de control, y finalmente se implementa en vivo. Plantee esto como una pregunta para cualquier proveedor en lugar de asumirlo, y obtenga la respuesta por escrito, porque la ejecución en paralelo y la promoción de versiones son la diferencia entre una implementación controlada y un cambio drástico e imprevisto.

Considere dos límites al redactar este plan: no acepte un calendario semanal como el núcleo del proyecto (el diseño de las fases es lo realmente valioso y reutilizable; el calendario suele depender más de la disponibilidad de personal del proveedor).

Y maneje las dependencias de integración como un factor decisivo de alcance y no como un detalle menor. Si algo que desea probar depende de una integración en tiempo real con una herramienta externa que aún no existe, el ejercicio se alargará o tendrá que simularse la respuesta. Ambas opciones son válidas; descubrir en la segunda semana cuál de ellas le tocará no lo es. Pregunte qué criterios requieren de una integración externa antes de acordar el cronograma de trabajo.

Qué dejar fuera del alcance a propósito

Cada elemento adicional que intente probar involucrará a un equipo más, cuyo tiempo de dedicación tendrá que justificar.

En una negociación, el proveedor sugirió dejar la gestión de casos de extremo a extremo fuera del alcance del ejercicio, específicamente porque probar eso implicaría involucrar a todo el equipo de operaciones, que de otro modo no tendría que participar. El líder de ingeniería lo descartó rápidamente: no era necesario, los usuarios principales eran el equipo de cumplimiento y demostrar que la solución cubría sus necesidades era suficiente.

Observe el enfoque de esa postura, ya que es muy útil. El proveedor propuso acotar el alcance. Un proveedor que insiste en probarlo todo suele buscar que el ejercicio se vea espectacular, en lugar de facilitar que su toma de decisiones sea ágil y clara.

La regla a seguir es simple: incluya aquello que el usuario principal necesita ver demostrado y excluya lo que ya da por sentado. Si una demostración previa ya lo convenció de que una función sirve, no pierda tiempo volviendo a probarla en este ejercicio.

Es mejor secuenciar las tareas que cancelarlas

En otra negociación, se decidió posponer la evaluación de un agente específico hasta que la plataforma principal hubiera sido aprobada. Este es el mismo límite que explicamos antes: definir las dimensiones bajo las cuales se evalúa a un agente es un ejercicio, y las condiciones de aprobación que presentamos en esta página son otro diferente. Intentar hacerlos en el orden incorrecto solo le hará perder el tiempo en ambos.

Sin embargo, hay algo que debe mantener sin importar cuánto acote el alcance: asegúrese de incluir un resumen claro en la presentación final para que todos los asistentes entiendan lo que se expone. No todos tendrán el mismo contexto sobre el proyecto, y un resultado que nadie puede seguir no sirve de nada.

Quién aprueba el proyecto y qué pasa después

La aprobación debe estar a cargo de una lista específica de personas acordada al inicio. Quienquiera que esté presente en la sala al final del ejercicio no representa una firma de conformidad formal.

Para definir quiénes deben integrar esa lista, tome como referencia el criterio de los propios reguladores. Las pautas de supervisión sobre la gestión de riesgos de modelos se actualizaron el 17 de abril de 2026, cuando la Reserva Federal, la FDIC y la OCC publicaron de forma conjunta la guía revisada bajo los códigos SR 26-2, Boletín OCC 2026-13 y FDIC FIL-15-2026, que reemplaza a la SR 11-7 de 2011 y a la declaración conjunta de 2021 sobre gestión de riesgos de modelos para sistemas BSA y AML. Esta guía mantiene la idea del "cuestionamiento efectivo" (effective challenge) y define quiénes pueden realizarlo: personas con "la experiencia adecuada para llevar a cabo un cuestionamiento crítico y objetivo, la independencia necesaria para mantener la objetividad, así como la influencia y posición jerárquica dentro de la organización para implementar cambios".

La tercera condición es la que suele olvidarse. Un revisor que puede plantear objeciones pero no tiene el poder para cambiar el rumbo del proyecto no cumple con este requisito, y este es un criterio del propio ente regulador, no una simple opinión.

Un dato útil mientras define su lista: la guía revisada deja fuera de su alcance a la IA generativa y basada en agentes, indicando que este tipo de modelos "no están dentro del alcance de esta guía", y solo se planea una solicitud de información sobre el uso de la IA en los bancos. Por lo tanto, no existe una plantilla oficial sobre cuánta intervención humana necesita la decisión de un agente. Su institución debe decidirlo, dejarlo por escrito y defenderlo, que es precisamente la razón por la que los criterios de aceptación debe definirlos usted.

Nada de esto elimina las responsabilidades sobre la decisión en sí. El escenario una vez que el agente esté activo y el registro de auditoría que deja un agente de riesgo representan el siguiente paso lógico a resolver.

Finalice el ejercicio con una sesión de revisión. Repase la lista de criterios acordada, señale cuáles se cumplieron y cuáles no, y salga de allí con una decisión clara y un cronograma de implementación definido. Esta sesión es la que hace efectivo el compromiso previo de la gerencia, porque es el momento de concretar lo acordado. Defina también el documento técnico que dará seguimiento al resultado: un documento de alcance por escrito que detalle los casos de uso, los volúmenes, los elementos del flujo de trabajo y las integraciones externas que formarán parte del proyecto.

Luego, defina el camino a seguir en caso de fallo en el mismo documento de criterios y antes de iniciar la prueba de concepto. Es algo sencillo. Una persona de la lista de firmantes tendrá la última palabra, y cada escenario alternativo debe estar definido previamente.

Definir el camino en caso de fallo es lo que permite tener reportes honestos y transparentes. Sin esto, un ejercicio que no rinde lo esperado suele extenderse indefinidamente en lugar de concluirse, y un cierre a tiempo es mucho más barato que una tercera extensión de plazo. Una prueba de concepto sin un escenario de fallo definido es un ejercicio que nadie puede dar por perdido.

Cuánto tiempo debería tomar y por qué escuchará propuestas de plazos muy diferentes

Diferentes personas le cotizarán duraciones distintas, incluso dentro de la misma empresa proveedora. Hay dos plazos de referencia que vale la pena conocer porque corresponden a ejercicios diferentes:

Una prueba de concepto básica puede realizarse en aproximadamente una semana cuando se ejecuta con datos históricos y bajo criterios de éxito acordados de antemano. Por el contrario, una evaluación completa antes de producción (que incluye preparación de datos, prueba retrospectiva con alertas históricas, ejecución en paralelo y presentación de resultados) tiene una estructura de cuatro semanas, que es la duración asumida en el ejemplo práctico anterior.

El punto clave no es qué plazo es el correcto, sino entender que se trata de dos tipos de ejercicio diferentes. Un comprador que espere un análisis profundo del segundo tipo pero reciba una cotización de una sola semana se sentirá decepcionado al finalizar un proyecto que técnicamente fue exitoso. Por lo tanto, la regla es simple: deje en claro por escrito qué tipo de ejercicio está comprando antes de la fecha de inicio.

Entienda bien el plazo de una semana: si es posible completarlo en ese tiempo es porque los criterios se acordaron previamente, lo cual refuerza el argumento de esta página desde la perspectiva contraria.

Por qué fracasan estos proyectos

Al inicio de esta página mencionamos los dos factores principales: definir los criterios después de ver los resultados y usar criterios que solo miden la velocidad. Vale la pena señalar otros cinco factores de fracaso comunes que se presentaron en los casos que analizamos para escribir este artículo:

• Falta de un responsable designado. Lo vimos en la práctica: requisitos genéricos para los cuales aún no se había contratado a la persona encargada de adaptarlos a las necesidades de la empresa.

• Evaluar un ejercicio a ciegas como si fuera uno calibrado. Es el fracaso más silencioso de la lista y el más difícil de notar después, porque el resultado visual del sistema sigue pareciendo excelente.

• Una aprobación que no obliga a nadie a tomar medidas. Así es como una prueba de concepto se aprueba pero nunca se implementa en el día a día: como nadie acordó a qué obligaba el éxito del ejercicio, tanto la aprobación como el fallo llevan al mismo lugar: otra reunión.

• Exceso de alcance (scope inflation). Un ejercicio planeado para dos semanas se convierte en un trimestre de coordinación interna, consumiendo el entusiasmo y el apoyo que iba a necesitar para la implementación real.

• Falta de figuras clave en la lista de firmantes. Se cumplen los criterios, los revisores están de acuerdo, pero el proyecto no avanza porque ninguna de las personas involucradas en la firma tiene la autoridad jerárquica para autorizar la compra.

Preguntas frecuentes

¿Qué es una prueba de concepto (POC)?

Una prueba de concepto es un ejercicio con un plazo definido que evalúa si una tecnología o función específica puede realizar una tarea concreta bajo las condiciones reales de su empresa, evaluada con base en criterios acordados antes de que comience el trabajo. Responde a una pregunta de viabilidad técnica y no de rentabilidad comercial. El resultado final es una decisión sobre si seguir adelante con el proyecto y no un producto listo para producción.

¿Cuáles deberían ser los criterios de aceptación para la POC de un agente de riesgo de IA?

Debe estructurarlos en cuatro categorías, por escrito y antes de la fecha de inicio: calidad de las decisiones, encaje operativo, viabilidad comercial y una regla de decisión que defina quién decide y qué sucede si no se cumplen los criterios. Dentro de estas categorías, defina umbrales para la coincidencia de resoluciones con sus analistas, verdaderos positivos omitidos, desacuerdos que un revisor no pueda explicar, qué porcentaje de la muestra se procesó de principio a fin, si el resultado contiene suficiente sustento para que un revisor pueda actuar, el tiempo por revisión, el comportamiento ante la falta de datos y si el registro de la decisión se puede reconstruir en el futuro. Defina el umbral para verdaderos positivos omitidos por separado y manténgalo bajo. Incluya también los aspectos no técnicos: responsables de firma y precios definidos de antemano.

¿Cuál es la diferencia entre una prueba de concepto y una prueba de valor?

Una prueba de concepto evalúa si la solución puede funcionar. Una prueba de valor evalúa si el beneficio que aporta justifica su costo. Ambos ejercicios requieren criterios de evaluación diferentes, y la mayoría de las experiencias decepcionantes ocurren porque se vende el proyecto bajo el primer enfoque pero se le juzga bajo el segundo.

¿Cuánto tiempo debería durar la POC de un agente de riesgo de IA?

Alrededor de una semana si se ejecuta con datos históricos y bajo criterios de éxito acordados previamente. Una evaluación completa antes de producción (que cubre la preparación de datos, prueba retrospectiva con alertas históricas, ejecución en paralelo y presentación de resultados) toma unas cuatro semanas. Son dos tipos de ejercicio diferentes, por lo que debe acordar por escrito cuál de ellos está comprando antes de comenzar.

¿Qué datos necesita el proveedor para una POC y qué información no se debe compartir?

Para un ejercicio calibrado: unas 25 alertas históricas para arrancar, de 60 a 90 días de historial de transacciones para esas entidades y datos básicos de identidad y entidad. Si las resoluciones de sus analistas están guardadas en documentos de texto en lugar de campos estructurados, bastará con una muestra de 25 a 50 alertas con sus respectivos motivos de cierre. No es necesario realizar una conexión en tiempo real con su sistema de producción, y usar datos sintéticos formateados con su propio esquema servirá para probar que el flujo de trabajo procesa bien la estructura de sus datos, aunque no demostrará si el criterio del agente coincide con el de sus analistas.

¿Cómo se define un umbral antes de ver cualquier resultado?

Mida primero su propio punto de partida. Averigüe su tiempo medio de revisión actual y, lo más importante, con qué frecuencia dos de sus propios analistas llegan a la misma resolución para una misma alerta. El nivel de coincidencia entre sus propios analistas representa el límite máximo de lo que puede significar la coincidencia con un agente, por lo que definir un objetivo superior a esa cifra no es realista. No existen estándares de referencia generales para los umbrales de aceptación de agentes, por lo que la referencia debe ser la de su propia operación.

¿Qué se debe medir además de la velocidad?

La coincidencia de resoluciones con sus analistas, los verdaderos positivos omitidos, las discrepancias que un revisor no pueda explicar, el nivel de completitud de la muestra procesada, si el resultado contiene pruebas suficientes para tomar medidas, el comportamiento ante campos obligatorios vacíos y si el historial de decisiones se puede reconstruir meses después. Los verdaderos positivos omitidos merecen su propio umbral, ya que una tasa de coincidencia general puede parecer excelente pero ocultar fallos precisamente en los casos más críticos y de mayor riesgo.

¿Quién debe validar y certificar que la POC se aprobó?

Una lista de personas con nombres y cargos específicos, acordada desde el inicio por ambas partes. Aplique el criterio que sugieren los reguladores para un cuestionamiento efectivo: experiencia técnica adecuada, independencia suficiente para mantener la objetividad y la influencia dentro de la organización para poder autorizar un cambio real. Esta última condición es la que suele faltar y la que realmente le da peso e importancia a la firma de conformidad.

¿Qué sucede si la POC falla?

Se procede según lo acordado previamente: una segunda fase con un alcance modificado, la evaluación de un proveedor diferente o cancelar la compra. Deje registrados estos caminos alternativos en el documento de criterios en una tabla sencilla (seguir adelante si, extender plazo si, cancelar si) e identifique quién tomará la decisión final. Un ejercicio sin consecuencias de fallo definidas no generará ningún resultado concreto.

¿Se puede realizar la POC de un agente de riesgo de IA antes de migrar de plataforma?

Sí. Un ejercicio calibrado se ejecuta con exportaciones de alertas históricas y sus respectivas resoluciones, por lo que no necesita conectarse en tiempo real al sistema que planea dejar. La única advertencia es el punto de partida: si sus resoluciones están en notas de texto no estructuradas, deberá tomar una muestra de casos con sus respectivos motivos o aceptar que realizará un ejercicio a ciegas, ajustando las expectativas de lo que planea demostrar.

Déjelo por escrito antes de la primera semana

Todo lo analizado en esta página se resume en un buen hábito: los umbrales, la elección de datos, los responsables de firma y el camino a seguir en caso de fallo se deciden antes de que comience el ejercicio, o terminarán definiéndose según lo que muestren los resultados. Una prueba de concepto que elige sus criterios después de ver los datos no puede fallar, y un ejercicio que no puede fallar no aporta ninguna información útil.

No necesita la ayuda del proveedor para definir estos puntos. Puede redactar la tabla de umbrales, designar a los firmantes y definir el camino en caso de fallo esta misma semana; luego, entregue esa lista a los proveedores que esté evaluando y verifique si el ejercicio que le proponen es capaz de responder a esas necesidades. Plantear esta pregunta suele aportar más información que el propio ejercicio.

Si prefiere ver cómo un agente procesa una alerta real antes de definir un umbral de evaluación, los agentes de riesgo de Oscilar realizan una prueba de concepto de una semana con sus propios datos históricos, definiendo primero los criterios de éxito.