Qué cambia de verdad un agente de IA en una operación bancaria

Un banco no fracasa en un proyecto de IA porque el modelo no sepa escribir una frase. Fracasa porque nadie nombró la operación que el agente podía tocar, el registro que debía dejar y la persona que podía detenerlo. La demostración parece una conversación. El sistema en producción es un conjunto de permisos.

S·CORP trata a un agente en banca como un operador con un trabajo estrecho. Puede redactar, recuperar, enrutar o recomendar. No se convierte en el sistema de registro, y no hereda todos los privilegios que la cuenta de servicio tenía el día en que alguien la conectó. Si esa frase incomoda, el proyecto no está listo para un cliente, un cajero o un analista de crédito.

Empiece por la operación, no por el modelo

Elija una operación que ya tenga nombre, dueño y una definición de terminado. Los buenos candidatos son estrechos: armar un resumen de un expediente de crédito con documentos que el banco ya guarda, preparar la respuesta a una solicitud de servicio rutinaria, o comprobar si un expediente tiene los anexos que la política exige antes de que una persona lo revise. Los malos candidatos son todo lo que se describe como "todo el centro de contacto" o "originación autónoma."

Escriba la operación en la unidad que el negocio ya usa. Un caso. Un expediente. Una excepción de pago. Una narrativa de actividad sospechosa que una persona todavía presenta. Si el equipo no puede decir cómo se ve "terminado" para una de esas unidades, el agente inventará una meta, y el rastro no coincidirá con la forma en que el banco ya explica su trabajo.

Después escriba lo que el agente no puede hacer. En un banco esa lista suele importar más que la lista de funciones. Debe decir si el agente puede mover dinero, cambiar un límite, abrir o cerrar un producto, hablar con un cliente sin una persona en la línea, o enviar algo fuera del banco. "Lo decidimos después" es una decisión: dejar que la integración elija.

Nombre las herramientas antes de nombrar la instrucción

Un agente está tan contenido como sus herramientas. Una instrucción que dice "no revele datos del cliente" no es un control si la herramienta devuelve un registro completo del sistema central y el modelo puede citarlo. Liste cada sistema que el agente puede llamar: sistema central, CRM, repositorio documental, incidencias, pagos, procesador de tarjetas, proveedor de identidad. Para cada uno, escriba la acción (leer, redactar, crear, actualizar), los campos en alcance y los campos que nunca deben aparecer en una instrucción o en un registro.

Aquí PCI DSS deja de ser un eslogan y pasa a ser una pregunta de diseño. Si la operación puede hacerse sin el número de cuenta primario, no lo ponga en la herramienta. Si hay que referirse a una tarjeta, déjela en el sistema que ya está en alcance de PCI DSS y pase al agente un token o una referencia de los últimos cuatro dígitos. No descubra esto después de revisar una transcripción.

La misma disciplina vale para datos de empleados, listas de sanciones y expedientes de crédito. El agente debe recibir el recorte más pequeño que le permita hacer la operación nombrada. Un índice armado con "todo lo que hay en el directorio compartido" no es un control bancario. Es una copia no revisada del banco.

Deje a una persona la decisión que afecta los fondos o la reputación

Hay una línea clara. El agente puede preparar. Una persona responsable de la operación puede decidir. Esa persona necesita tres cosas en una pantalla: qué usó el agente, qué propone y cómo rechazarlo sin perder el caso. Si la única forma de rechazar al agente es ignorar una ventana de conversación, el personal va a aprobar por inercia o a rodear el sistema.

Cuando el uso es de cara al cliente, la transparencia es parte de la operación, no una nota al pie de una política que nadie abre. El cliente debe poder saber que habla con un agente, y debe tener un camino hacia una persona que no dependa de adivinar una frase mágica. El Reglamento de IA de la UE, cuando aplica, se ocupa de la transparencia de ciertos sistemas. Aunque no aplique, un banco que esconde al agente está pidiendo un reclamo.

Las operaciones de fraude y de delito financiero merecen una versión más estricta de la misma regla. Un agente puede armar una línea de tiempo con alertas que el banco ya tiene. No debe cerrar una alerta, presentar un reporte ni decirle al cliente el resultado. La narrativa que presenta una persona tiene que ser suya. Si el agente redactó el lenguaje, el expediente debe decirlo.

Registre el trabajo como lo puede leer un examinador

Una transcripción no es una pista de auditoría. Para cada unidad de trabajo, conserve el identificador del caso, las herramientas llamadas, las clases de datos tocadas, la salida mostrada a una persona, la decisión humana y la identidad de esa persona. Consérvelo tanto tiempo como el banco conserva la operación de fondo. No conserve cargas completas del cliente en un registro de instrucciones si el sistema central ya es el registro.

El acceso a ese registro es en sí una acción privilegiada. Los proveedores del modelo, los integradores y el equipo que opera el agente no reciben de forma automática un flujo de instrucciones de producción. Si un proveedor necesita una muestra para corregir un defecto, tome una muestra redactada bajo el proceso habitual de terceros del banco. ISO 27001 sirve aquí solo como recordatorio: el control es una regla de acceso y un registro, no un certificado en una diapositiva.

El Marco de Gestión de Riesgos de IA de NIST es un mapa razonable para la conversación con riesgo, cumplimiento y auditoría interna. Gobernar, mapear, medir, gestionar. Use las palabras si ayudan a esos equipos. No finja que nombrar las funciones es lo mismo que tener un dueño para cada una. El dueño de "medir" necesita un conjunto pequeño de controles que el banco pueda ejecutar: la proporción de casos que una persona rechazó, la proporción de llamadas a herramientas que fallaron, y una revisión periódica de una muestra de transcripciones contra el alcance escrito. Esas son medidas operativas. No son una afirmación sobre el sector, porque no estamos publicando una.

Ponga el cambio en el despliegue, no después

Los programas bancarios se atascan cuando el modelo se trata como el producto y la sucursal, el centro de operaciones y las funciones de control se tratan como audiencia de un correo de lanzamiento. Las personas que van a aceptar o rechazar la salida del agente deben verla en sus propios casos antes de que toque una cola en vivo. Deben poder decir, con sus palabras, de qué son responsables ahora que no lo eran el mes pasado.

Eso es gestión del cambio, y pertenece al mismo plan que la integración. Un piloto que corre junto al proceso real, con casos reales y un supervisor nombrado, le enseña más al banco que una prueba de concepto con expedientes inventados. Cuando el piloto termina, o el alcance es lo bastante estrecho para operarlo, o no lo es. Las dos respuestas sirven. Una historia vaga de éxito no.

Si la primera operación sigue borrosa, empiece por una evaluación de los agentes, las herramientas, los datos y la supervisión que ya están en movimiento. El punto de ese trabajo es un alcance y un mapa de control, no un recorrido por modelos.