Una recomendación de préstamo de IA necesita una regla de liberación propia

Una recomendación de préstamo puede sonar razonable y, al mismo tiempo, contradecir la política que se supone debe seguir. Quiero que la decisión de publicar esa recomendación cuente con una base inspeccionable propia. Si la explicación y la autorización para actuar provienen de la misma respuesta, un revisor debe desentrañar ambas antes de decidir qué puede proceder.

La cuestión de diseño es qué debe ocurrir cuando una recomendación de IA no supera una comprobación. Pedirle al modelo que lo intente de nuevo puede reparar una respuesta incompleta. Retener la recomendación puede ser necesario cuando contradice una regla. Se trata de intervenciones diferentes, con costes distintos. Un límite útil hace visible esa diferencia antes de que cualquiera de las dos se convierta en un hábito automático.

Una explicación razonable puede respaldar un resultado erróneo

En The Validation Firewall de Veriprajna, una salida de modelo conservada recomienda la aprobación para un solicitante de préstamo sintético cuya puntuación crediticia es 559. La política configurada exige al menos 620. La recomendación también incumple los criterios de la política relativos a deuda sobre ingresos, préstamo sobre valor y morosidad reciente.

Estas son respuestas de modelo almacenadas en caché sobre registros sintéticos, reproducidas a través de las comprobaciones sin inferencia nueva. Muestran el comportamiento de este ejemplo, no un punto de referencia de precisión del modelo ni pruebas procedentes de los clientes de un prestamista. El flujo de trabajo de concesión de préstamos y el enrutamiento están simulados.

La explicación resulta instructiva. Señala que la política proporcionada no suministra las claves de motivos principales permitidos necesarias para una denegación. Eso pone de manifiesto una limitación real del contrato de entrada: el prompt del modelo en la demostración proporciona los criterios de crédito, pero omite la lista de motivos permitidos que ordena utilizar al modelo. La respuesta del modelo merece entenderse en ese contexto. No constituye una base equitativa para clasificar modelos.

Tampoco hace que la aprobación sea coherente con los criterios crediticios codificados. La falta de instrucciones para explicar una denegación no altera la puntuación crediticia del solicitante ni el umbral mínimo de la política. Una respuesta puede identificar un problema y, aun así, recomendar un resultado que incumple otro requisito.

Prefiero una evaluación de política independiente en este punto porque preserva esa distinción. El modelo puede explicar por qué su tarea resultó difícil. La comprobación puede mostrar por qué esta recomendación no satisface la regla suministrada. Un revisor puede inspeccionar ambas sin tratar una explicación persuasiva como autoridad para modificar la regla.

Esa separación también hace que la corrección sea más precisa. Mejorar la lista de motivos del prompt atiende al contrato de respuesta. Cambiar un umbral de política es una decisión diferente que requiere su propia justificación. Pedir reiteradamente una explicación más convincente no puede dirimir qué política debe aplicarse.

El reintento y la revisión resuelven problemas distintos

Considere un flujo de trabajo de producción hipotético que utilice este patrón. Llega una respuesta de denegación sin el motivo estructurado requerido. Una opción es solicitar una respuesta corregida, aportando las instrucciones que faltaban. Otra es enviarla directamente a un revisor. La primera puede ser adecuada para un problema de formato o de entrada recuperable; la segunda reserva la atención para los casos en que la decisión subyacente exige juicio.

Soy partidario de un reintento acotado cuando el defecto es específico, la entrada se puede corregir y la respuesta de reemplazo se someterá a las mismas comprobaciones. La respuesta anterior debe permanecer disponible junto a su reemplazo. De lo contrario, una respuesta limpia posterior puede ocultar el hecho de que el contrato original falló. Esta es una recomendación de diseño, no una capacidad de reintento o retención de versiones demostrada por este prototipo.

La aprobación que vulnera la política exige un tratamiento diferente. Un reintento puede producir una recomendación coherente con la política, pero la aprobación original debe permanecer retenida. La condición de liberación debe remitirse a un resultado recién comprobado. No debe ser «el modelo respondió dos veces» o «la explicación ahora parece mejor». Si el caso requiere una excepción a la política, un proceso de excepciones autorizado debe suministrar esa autoridad.

Esta elección tiene un coste. Retener todo para revisión humana consume capacidad de los revisores y demora casos que una entrada corregida podría resolver. Reintentar cada fallo consume cómputo y puede generar una sucesión de alternativas plausibles sin resolver la regla rectora. La línea divisoria útil reside en si el defecto puede repararse dentro del contrato de decisión existente o requiere que alguien modifique dicho contrato.

Los resultados reales del prototipo son más acotados. Una comprobación fallida con gravedad de bloqueo produce BLOCK. Un fallo con gravedad de escalado produce ESCALATE si ningún bloqueo tiene prioridad. Superar las cuatro comprobaciones individuales produce AUTO-CLEAR. Estas etiquetas registran el resultado de la barrera configurada. No demuestran una revisión humana completada ni la autorización para emitir una decisión crediticia en producción.

Una comprobación superada necesita una declaración de cobertura

La siguiente complicación radica en lo que un resultado favorable puede significar razonablemente. Una comprobación externa puede ser determinista y, aun así, dejar preguntas importantes sin responder. La precisión de la regla no demuestra la exhaustividad de su cobertura.

Por ejemplo, esta demostración compara las entradas de evidencia de valor de campo suministradas con una recomendación frente al registro sintético. Eso resulta útil cuando un valor citado es erróneo. Sin embargo, una lista de evidencias vacía supera esa comprobación. No inspecciona cada afirmación de la explicación ni comprueba que se haya citado cada campo necesario.

Por tanto, quiero que una regla de liberación declare tanto el predicado que evalúa como la evidencia que exige. En un flujo de trabajo hipotético donde una decisión deba basarse en ingresos verificados, la falta de una cita de ingresos requiere un tratamiento explícito. El diseñador podría exigir el campo antes de la validación, enrutar la evidencia faltante para revisión o acotar la tarea de modo que la recomendación no tenga autoridad sobre esa decisión. Una comprobación de coherencia por sí sola no puede elegir entre esas políticas.

Exigir más evidencia plantea su propio dilema. Puede hacer visibles las omisiones, pero también amplía el contrato de respuesta y el trabajo necesario para mantenerlo. La evidencia requerida debe responder a las consecuencias de la decisión. Pedir todos los campos disponibles genera ruido; pedir solo lo que el modelo ofrece voluntariamente deja al modelo el control sobre la cobertura de la comprobación.

AUTO-CLEAR debe interpretarse con este alcance delimitado. Significa que las comprobaciones individuales implementadas se superaron, y puede aplicarse tanto a una denegación respaldada por la política como a una aprobación. No establece que deba concederse un préstamo, que cada dato sea correcto ni que se hayan cumplido todas las obligaciones pertinentes.

Un aprobado agregado no puede resolver un fallo individual

El mismo lote de modelos conservado proporciona una prueba útil para interpretar paneles de control. Cada uno de sus dos grupos sintéticos cuenta con cinco aprobaciones previstas de seis registros. Su ratio de tasa de aprobación prevista es de 1.00, por lo que el filtrado de cartera configurado se supera. Sin embargo, la aprobación que vulnera la política sigue bloqueada a nivel individual.

No hay contradicción. El panel de cartera compara tasas grupales entre recomendaciones previstas. La comprobación individual compara una recomendación con la política configurada. Ninguna sustituye a la otra. Con solo seis registros sintéticos por grupo, el aprobado agregado tampoco puede establecer un trato legal o un comportamiento fiable fuera de este ejemplo.

Mantengo esas cuestiones separadas al interpretar un panel de validación. Un único resumen en verde invita a atribuirle un significado más amplio del que respalda el cálculo subyacente. Un mejor registro de revisión identifica qué pregunta responde cada resultado, los registros incluidos y las condiciones sin resolver. El informe explicativo de la demo muestra cómo conviven estos hallazgos individuales y el filtrado de cartera.

Aquí está mi recorrido por los ejemplos sintéticos y las conclusiones de sus comprobaciones individuales.

Para un equipo que decida dónde situar el límite de liberación, mi criterio es si un revisor puede rastrear la autorización hasta una regla específica, la evidencia requerida y un siguiente paso responsable. La explicación de un modelo puede enriquecer ese registro. No debe adquirir la autoridad de relajar una regla incumplida simplemente describiendo por qué cumplirla resultaba difícil.