Soluciones de Pago
Research Papers
RESEARCH PAPER 17
Inteligencia Artificial en los Pagos en España
Aplicaciones, evaluación y control para convertir modelos en mejoras operativas verificables
Soluciones de Pago · Biblioteca de Investigación
Edición: septiembre de 2026 · Ámbito: empresas y operaciones de pago en España, con contexto europeo.
Investigación documental y análisis editorial. Los ejemplos, matrices y propuestas son elaboración propia; no representan resultados experimentales ni datos de clientes.
Resumen ejecutivo
La inteligencia artificial puede ayudar a detectar patrones, organizar información y preparar decisiones dentro de una operación de pagos. Su valor depende de la tarea, de los datos y de cómo se integra el resultado en el trabajo. Un modelo que genera una respuesta convincente no demuestra que el pago esté confirmado. Una puntuación de riesgo no prueba por sí misma que exista fraude. Una propuesta de conciliación no sustituye la evidencia contable que permite cerrar una diferencia. Estas distinciones son la base de una adopción responsable y útil.
Este paper plantea la inteligencia artificial como una capacidad limitada por una finalidad, no como una transformación que deba aplicarse a todas las funciones. El punto de partida es una decisión concreta: qué problema se quiere resolver, qué resultado se espera y qué consecuencias tendría un error. Después se compara la propuesta con el proceso actual y con alternativas más sencillas. La evaluación debe incluir calidad, coste, experiencia y posibilidad de recuperación, evitando presentar velocidad o automatización como beneficios suficientes por sí solos.
Las aplicaciones estudiadas incluyen priorización de revisiones, análisis de anomalías, conciliación asistida, extracción documental y apoyo a atención. También se examinan sistemas capaces de proponer o ejecutar acciones, donde la separación entre sugerencia y autorización resulta especialmente relevante. El documento distingue modelos predictivos, generación de contenido y automatización mediante reglas. Agruparlos bajo una única etiqueta puede ocultar diferencias importantes de validación, mantenimiento y exposición.
La tesis central es que una mejora solo resulta defendible cuando puede observarse en el proceso completo. Reducir tiempo de clasificación puede trasladar trabajo a revisión. Bloquear más operaciones puede reducir una medida de pérdida y perjudicar compras legítimas. Producir más respuestas puede aumentar contactos si el contenido no resuelve la necesidad. Por ello, el paper propone evaluar resultados junto a excepciones y mantener límites de actuación, responsables y criterios de retirada cuando la evidencia no sostiene el uso.
1. Alcance, conceptos y método
1.1 Distinguir familias de capacidades
Un sistema predictivo estima una variable o clasifica una situación a partir de datos. Un sistema generativo produce contenido, como texto o una propuesta estructurada. Una automatización basada en reglas ejecuta condiciones definidas explícitamente. Estas categorías pueden combinarse, pero no deben confundirse. Para una empresa, la pregunta útil es qué parte del recorrido depende de una estimación y qué parte sigue una regla comprobable. Esa separación permite localizar dónde se necesita evaluación estadística y dónde se necesita verificar lógica operativa.
Los sistemas con capacidad de actuar añaden otra dimensión: pueden consultar herramientas o iniciar cambios. El riesgo depende de las capacidades que reciben y de cómo se autorizan las acciones. Un asistente que resume incidencias no presenta las mismas consecuencias que uno que modifica datos o inicia una devolución. La política debe describir esas capacidades con precisión, evitando que una mejora de interfaz amplíe permisos de forma inadvertida.
1.2 Resultado del modelo y hecho del negocio
El modelo produce una salida; el negocio necesita decidir qué significa y qué puede hacerse con ella. Una sugerencia de correspondencia entre registros puede ser útil para priorizar trabajo, pero debe distinguirse de una conciliación confirmada. Un resumen puede ahorrar lectura, pero necesita conservar referencias que permitan comprobarlo. La integración debe mantener esta diferencia en estados, mensajes y permisos, de modo que una hipótesis no se convierta silenciosamente en un hecho registrado.
La empresa puede definir estados como propuesta, pendiente de revisión, validado y ejecutado. Cada estado necesita criterio de entrada y responsable. La terminología debe ser comprensible para quienes atienden y cierran operaciones. Si un usuario consulta el registro posteriormente, debería reconocer qué parte procedía del modelo y qué parte fue comprobada. Esta trazabilidad facilita investigación y evita atribuir al sistema una certeza que nunca tuvo.
1.3 Un marco de gestión de riesgos
El AI Risk Management Framework de NIST ofrece una referencia voluntaria para gestionar riesgos de inteligencia artificial. Se utiliza aquí como apoyo conceptual para relacionar contexto, medición y gestión durante el ciclo de vida. No se presenta como norma española obligatoria ni como certificación de una herramienta. Su utilidad editorial es recordar que la evaluación debe abarcar el sistema y su uso, no únicamente el rendimiento aislado de un modelo. Fuente: NIST, AI Risk Management Framework.
La aplicación empresarial propuesta consiste en mantener cuatro preguntas: qué decisión se apoya, qué evidencia existe sobre el resultado, quién controla las consecuencias y cómo se corrige un error. Estas preguntas pueden utilizarse en una organización pequeña sin crear una estructura compleja. Lo importante es que las responsabilidades sean reales y que el equipo pueda explicar límites y excepciones antes de permitir que una salida afecte a clientes o registros económicos.
1.4 Matriz de alcance
| Uso | Resultado esperado | Comprobación necesaria |
|---|---|---|
| Clasificación | Ordenar casos para revisión. | Errores y carga desplazada al equipo. |
| Generación | Preparar texto o estructura. | Exactitud, fuentes y adecuación al caso. |
| Recomendación | Proponer una decisión. | Consecuencias y criterio de aceptación. |
| Acción | Modificar un estado autorizado. | Permisos, límites y recuperación. |
La matriz es elaboración propia y no establece una clasificación jurídica. Su función es evitar que todas las aplicaciones se evalúen con el mismo procedimiento. Un error de redacción y una modificación económica requieren respuestas diferentes. La empresa debe describir el efecto real de cada uso y ajustar revisión, evidencia y capacidad de actuación a ese efecto.
1.5 Fuentes y límites de la investigación
La base documental reúne ocho referencias primarias de NIST, Comisión Europea, EBA, BIS, AEPD y OWASP. Sustentan criterios y ejemplos institucionales identificados en el texto. Las propuestas de gestión son análisis editorial. No se han obtenido datos de comercios ni se han realizado pruebas sobre sistemas de terceros. En consecuencia, no se atribuyen mejoras porcentuales de fraude, conversión o productividad a las recomendaciones y no se ofrecen previsiones de rentabilidad.
La selección no constituye una revisión sistemática de toda la literatura. El ámbito se concentra en operaciones de pago y apoyo empresarial, sin desarrollar todos los usos regulados del sector financiero. Las obligaciones concretas dependen de finalidad, rol, datos y efectos, y requieren revisión específica. El paper distingue una guía técnica de una norma y un experimento institucional de una capacidad disponible para cualquier empresa.
El trabajo conecta con el Framework de Pagos Digitales y el Framework de Operaciones de Pago. La inteligencia artificial se analiza como apoyo a procesos que deben conservar significado, evidencia y responsables. La pregunta final es si el sistema mejora una tarea verificable sin crear costes o consecuencias que el negocio no puede observar ni resolver.
2. Selección de casos de uso y calidad de los datos
2.1 Empezar por una tarea observable
La selección de un caso de uso debe partir de una tarea que el negocio pueda describir. Clasificar consultas, localizar diferencias o preparar un resumen son objetivos más evaluables que transformar la empresa con inteligencia artificial. La ficha inicial debería recoger entrada, salida, usuario y decisión posterior. También debe indicar qué parte del trabajo seguirá realizando una persona o una regla. Esta descripción permite comprobar si la tecnología propuesta resuelve una necesidad o añade complejidad a un proceso que todavía no está claro.
Conviene observar primero cómo se realiza la tarea actual. Puede existir un problema de datos incompletos, instrucciones ambiguas o herramientas desconectadas que no requiere un modelo. La comparación debe incluir alternativas sencillas, como mejorar referencias o ajustar un formulario. Esta revisión no presupone que la inteligencia artificial sea innecesaria; permite identificar dónde aporta una capacidad distinta y evitar atribuirle beneficios que proceden de corregir problemas básicos de organización.
2.2 Contexto sectorial sin extrapolaciones automáticas
El seguimiento de innovación de la EBA en 2025 sitúa la inteligencia artificial entre las tecnologías que están modificando actividades bancarias y de pagos. Este contexto institucional muestra interés y adopción en el sector, pero no demuestra que un uso resulte rentable o adecuado para una empresa concreta. El tamaño, los datos y las responsabilidades de una entidad financiera pueden diferir sustancialmente de los de un comercio. Fuente: EBA, Innovation Monitoring 2025.
La interpretación editorial es que los ejemplos sectoriales sirven para formular preguntas, no para copiar resultados. Una empresa debe comprobar si dispone de datos comparables y de capacidad para mantener el sistema. También debe distinguir una solución contratada de una función que solo existe en un proyecto experimental. La decisión debe apoyarse en un caso propio y en evidencia que permita valorar consecuencias dentro del recorrido real.
2.3 Definir qué significa un resultado correcto
Antes de evaluar un modelo, el equipo necesita acordar qué considera correcto. En una clasificación de consultas, puede existir más de una categoría razonable. En conciliación, una correspondencia debe apoyarse en reglas y evidencia económica. En detección de anomalías, una señal inusual no equivale a un caso confirmado de fraude. Si estas diferencias no se definen, las métricas pueden parecer precisas mientras comparan interpretaciones incompatibles entre quienes etiquetan o revisan resultados.
La definición debe incluir casos inciertos. Forzar todas las operaciones a una categoría definitiva puede crear una referencia de evaluación engañosa. Es preferible reconocer pendientes o desacuerdos y establecer cómo se resuelven. La calidad del conjunto de prueba depende de que represente la decisión que se quiere apoyar. Un modelo puede reproducir etiquetas históricas con fidelidad y seguir sin mejorar el trabajo si esas etiquetas reflejan errores o criterios que ya no se consideran adecuados.
2.4 Origen, significado y momento de los datos
Los datos de pago tienen tiempos y estados diferentes. Una fecha puede representar solicitud, autorización, abono o conciliación. Un importe puede incluir conceptos que otro registro separa. El equipo debe documentar estas diferencias antes de entrenar, configurar o evaluar una solución. Un patrón aparente puede proceder de cómo se registran eventos y no de una característica del comportamiento que se intenta estudiar. La comprensión del dato es una condición previa a la interpretación del modelo.
También importa qué información estaba disponible en el momento de decidir. Utilizar en una prueba un dato conocido solo después puede producir resultados demasiado favorables. Por ejemplo, una señal de cierre posterior no puede tratarse como entrada disponible al inicio de la operación. La evaluación debe reproducir el contexto temporal de uso. Esta disciplina permite estimar una capacidad que pueda existir en producción, en lugar de medir una reconstrucción retrospectiva con información privilegiada.
2.5 Cobertura y representatividad
Un conjunto de datos puede reunir principalmente operaciones completadas y dejar fuera abandonos, errores o casos resueltos por canales alternativos. Si se utiliza sin reconocer esa selección, la evaluación puede omitir las situaciones más difíciles. Conviene examinar qué tipos de operación aparecen, cuáles faltan y cómo cambió el proceso durante el periodo. La representatividad debe relacionarse con el uso previsto, no con el tamaño del archivo por sí solo.
La segmentación puede ayudar a detectar diferencias por canal, producto o tipo de incidencia, siempre con grupos suficientemente informativos y un tratamiento adecuado de datos personales. No se trata de recopilar atributos sensibles por costumbre. Se trata de comprobar si el sistema funciona en las condiciones relevantes y si existe evidencia suficiente para extender conclusiones. Cuando faltan datos, el informe debe conservar esa limitación y evitar presentar una prueba parcial como validación general.
2.6 Referencias y calidad de los registros
Una referencia estable que conecta pedido, pago y caso de atención puede aportar más valor inicial que un modelo sofisticado sobre registros dispersos. El negocio debe identificar duplicados, campos vacíos y cambios de significado. No todo error necesita resolverse antes de experimentar, pero sí debe comprenderse su efecto. Si una integración crea registros repetidos, el sistema podría aprender un patrón artificial y el equipo interpretar después su salida como una señal real.
La mejora de datos necesita responsables. Un informe de calidad que nadie puede corregir se convierte en observación sin efecto. Para cada problema conviene indicar origen, alcance y acción posible. Algunas correcciones deben realizarse en el proceso que genera el dato, no mediante limpieza repetida al final. Esta visión conecta proyecto de inteligencia artificial con operación cotidiana y evita que el mantenimiento dependa de transformaciones manuales que solo una persona entiende.
2.7 Priorizar por utilidad y capacidad de control
Un caso de uso puede evaluarse mediante impacto esperado, disponibilidad de evidencia, esfuerzo y reversibilidad. Las tareas de apoyo con resultados comprobables suelen permitir aprendizaje acotado. Las acciones con consecuencias económicas o personales importantes requieren un análisis más profundo y controles adecuados. Esta distinción no establece una prohibición general, sino una secuencia de implantación proporcional. El negocio debe conocer qué puede comprobar antes de ampliar autonomía.
La prioridad también depende de quién utilizará el resultado. Un sistema que produce una señal sin integrarse en el flujo de trabajo puede ser ignorado o crear una segunda lista que nadie mantiene. Conviene diseñar la respuesta operativa junto con el modelo: quién revisa, qué información recibe y cómo registra la decisión. El valor aparece cuando la salida ayuda a realizar una tarea y no simplemente cuando se muestra una predicción en un panel.
2.8 Ficha mínima del caso de uso
Una ficha útil puede resumir problema, proceso actual, salida propuesta, datos, destinatario, acción permitida y criterio de evaluación. Debe incluir límites conocidos y una condición de retirada. La ficha no necesita ser extensa para resultar rigurosa. Su función es conservar el acuerdo sobre qué se está probando y evitar que el alcance crezca sin revisión. Si durante el piloto aparecen nuevas funciones, deben evaluarse como cambios y no asumirse cubiertas por la decisión inicial.
La conclusión es que seleccionar bien significa reducir incertidumbre antes de automatizar. El negocio necesita una tarea clara, datos interpretables y un resultado que pueda contrastar. Esa base permite evaluar modelos con sentido y comparar beneficios con alternativas. La inteligencia artificial aporta valor cuando trabaja sobre un problema definido y mantiene un vínculo visible con la decisión que pretende mejorar, incluyendo los casos donde no dispone de evidencia suficiente para ayudar.
3. Detección de anomalías y revisión del fraude
3.1 Una anomalía es una señal, no una conclusión
Una operación inusual puede ser legítima y una operación fraudulenta puede parecer habitual. El análisis de anomalías ayuda a localizar situaciones que merecen atención, pero no determina por sí solo su causa. El proceso debe separar señal, investigación y decisión. Si estas etapas se mezclan, una puntuación puede convertirse en una acusación o un bloqueo sin evidencia suficiente. El diseño debe conservar incertidumbre y proporcionar al equipo un camino para comprobar lo que realmente ocurrió.
La empresa necesita definir qué problema intenta detectar. Uso indebido de una cuenta, información comercial incoherente y patrones de actividad sospechosa no son equivalentes. Cada uno requiere datos, criterios y responsabilidades distintos. Una herramienta que destaca diferencias estadísticas puede resultar útil para varios análisis, pero su utilidad debe demostrarse por caso. No conviene presentar una etiqueta de detección de fraude como garantía general frente a cualquier modalidad de abuso.
3.2 Qué aporta un experimento institucional
El proyecto Hertha del BIS Innovation Hub exploró técnicas de inteligencia artificial para identificar patrones de actividad delictiva en datos de sistemas de pagos minoristas en tiempo real, buscando utilizar un conjunto mínimo de datos. Se cita como ejemplo de investigación sobre análisis de transacciones y privacidad. Sus resultados y condiciones no deben extrapolarse automáticamente a un comercio ni interpretarse como una solución disponible que garantice detección. Fuente: BIS, Project Hertha.
La lección editorial consiste en estudiar relaciones y contexto sin asumir que más información siempre mejora una decisión. El negocio debe identificar qué señales aportan valor y qué datos no necesita. También debe reconocer diferencias de escala: una infraestructura de pagos puede observar relaciones que un comercio individual no ve. Esa diferencia limita comparaciones y refuerza la necesidad de evaluar cada aplicación con el alcance real de sus datos y permisos.
3.3 Falsos positivos y falsos negativos
Un falso positivo aparece cuando el sistema señala como problemática una operación que, según la referencia de evaluación, es legítima. Un falso negativo ocurre cuando no detecta un caso que sí debería identificar. Ambos errores tienen consecuencias, pero pueden afectar a personas y funciones diferentes. El primero puede generar revisión, retraso o abandono; el segundo puede permitir una pérdida. La decisión sobre umbrales debe considerar ese conjunto y no limitarse a maximizar una medida aislada.
El equipo necesita comprender cómo cambia el resultado al modificar el umbral. Una configuración más restrictiva puede aumentar casos detectados y también carga de revisión. Si la capacidad humana no crece, las alertas pueden acumularse y perder utilidad. Por ello, la evaluación debe conectar rendimiento con recursos. Una señal solo ayuda si existe un procedimiento capaz de atenderla dentro de un tiempo adecuado y con información suficiente para decidir.
3.4 Un ejemplo numérico ilustrativo
Supóngase un conjunto hipotético de mil operaciones con diez casos problemáticos confirmados para la prueba. Un sistema señala treinta operaciones, de las cuales ocho pertenecen a esos diez casos. En este ejemplo detecta ocho de diez, pero veintidós de sus treinta alertas corresponden a operaciones consideradas legítimas. Las cifras no representan una empresa ni un rendimiento de mercado. Sirven para mostrar que una buena proporción de detección puede coexistir con una carga significativa de revisión.
El ejemplo también muestra por qué una exactitud global puede ser engañosa cuando los casos son poco frecuentes. Un sistema que no señalara ninguna operación acertaría en muchas operaciones legítimas, pero no cumpliría el objetivo de detectar los casos problemáticos. La evaluación debe utilizar medidas relacionadas con la tarea y describir el coste de errores. No basta con comunicar un porcentaje elevado sin explicar qué cuenta como acierto y qué distribución tiene el conjunto evaluado.
3.5 Calidad de las etiquetas y retraso en la confirmación
La referencia utilizada para evaluar puede llegar tarde o contener incertidumbre. Una operación inicialmente considerada normal puede investigarse después. Una reclamación no demuestra por sí sola todas las circunstancias del caso. El equipo debe definir cuándo considera una etiqueta suficientemente estable y qué revisiones pueden modificarla. Si se compara un periodo reciente con otro cuyos casos ya maduraron, pueden aparecer diferencias que proceden del tiempo de observación y no del rendimiento del sistema.
La documentación debe conservar el origen de cada etiqueta y su alcance. Cuando existe desacuerdo, conviene registrar cómo se resuelve en lugar de ocultarlo bajo una categoría definitiva. Esta disciplina permite comprender límites del entrenamiento y de la prueba. Un modelo que reproduce decisiones históricas no necesariamente corrige sus errores. El negocio debe evaluar si esas decisiones constituyen una referencia adecuada para el objetivo actual y si necesitan una revisión antes de reutilizarse.
3.6 Diseñar una revisión humana informativa
La persona que recibe una alerta necesita contexto suficiente y una pregunta concreta. Una puntuación sin explicación operativa puede llevar a aceptar automáticamente la recomendación o a ignorarla. El sistema debería mostrar los hechos relevantes disponibles, sus referencias y lo que permanece incierto, sin generar una explicación inventada. El revisor debe conocer qué puede decidir y cómo registrar el motivo. La supervisión humana solo aporta valor si existe capacidad real de examinar y discrepar.
También debe medirse la calidad de esa revisión. Si los agentes confirman casi todas las alertas por falta de tiempo, la presencia de una persona no garantiza control efectivo. Conviene observar carga, información y posibilidad de escalado. El objetivo no es sustituir criterio por una firma final, sino diseñar una intervención que cambie decisiones cuando la evidencia lo justifica. Esa capacidad requiere formación y una organización que permita detenerse ante casos relevantes.
3.7 Trato al cliente y resolución de errores
La comunicación debe describir el estado de la operación sin atribuir una conducta indebida que no se ha demostrado. Un caso en revisión puede requerir información adicional o una espera, pero el mensaje debe ser claro sobre el siguiente paso. La empresa necesita una vía para resolver errores que afecten a personas legítimas. Si el sistema produce bloqueos repetidos, debe investigarse el patrón y no limitarse a tramitar cada reclamación como un hecho aislado.
El análisis debe considerar efectos sobre grupos y contextos relevantes, con tratamiento adecuado de datos. Una mejora media puede ocultar dificultades en determinados canales o situaciones. La evaluación no debe convertir correlaciones en juicios sobre individuos ni utilizar características sensibles de forma injustificada. La pregunta es si el proceso toma decisiones proporcionadas con evidencia pertinente y si puede corregir resultados erróneos. Ese criterio conecta calidad estadística con calidad del servicio.
3.8 Mantener el sistema bajo cambios
Los patrones de actividad y las formas de abuso pueden cambiar. Un rendimiento observado durante un periodo no garantiza resultados indefinidos. El equipo debe vigilar variaciones en entradas, alertas, confirmaciones y carga de revisión. Si aparece un cambio, debe distinguir si procede del negocio, del dato, del modelo o del criterio de etiquetado. Ajustar umbrales sin comprender la causa puede resolver una señal superficial y crear otro problema.
La conclusión es que la inteligencia artificial puede apoyar detección y priorización cuando existe una operación de revisión capaz de interpretar sus resultados. El valor no reside únicamente en encontrar más anomalías. Reside en mejorar decisiones con costes y consecuencias observables. El negocio debe conservar límites, evidencia y capacidad de retirada, evitando presentar una predicción como prueba o una alerta como sustituto de la investigación que el caso requiere.
4. Conciliación, documentos y operaciones internas
4.1 Automatizar la preparación sin perder evidencia
La conciliación relaciona registros para explicar ventas, cobros, abonos y diferencias. La inteligencia artificial puede ayudar a proponer correspondencias cuando los datos contienen descripciones variables o referencias incompletas. Sin embargo, la propuesta debe distinguirse de la confirmación. El negocio necesita criterios sobre qué coincidencias pueden aceptarse mediante reglas y cuáles requieren revisión. La finalidad es reducir trabajo evitable conservando la capacidad de explicar cada cierre, no conseguir que todos los importes parezcan encajar.
Antes de incorporar un modelo conviene revisar si existen identificadores que podrían resolver la tarea de forma directa. Una referencia estable suele ser preferible a inferir una relación a partir de texto ambiguo. El modelo puede reservarse para excepciones donde aporta una capacidad adicional. Esta combinación permite utilizar reglas claras en casos bien definidos y concentrar evaluación en las situaciones inciertas. El proceso debe conservar el origen de cada decisión para que una revisión posterior sepa cómo se obtuvo.
4.2 Propuestas de correspondencia y niveles de confianza
Una salida puede presentar varias correspondencias posibles. El sistema debería permitir reconocer ambigüedad en lugar de forzar una asociación única. El equipo debe definir qué información adicional necesita y qué consecuencias tendría una vinculación incorrecta. No conviene interpretar una puntuación como probabilidad calibrada si no se ha demostrado que lo sea. La etiqueta de confianza necesita una definición y una evaluación que el negocio pueda comprender.
La interfaz de revisión debería mostrar registros originales y diferencias relevantes. Si obliga al agente a abrir varias herramientas para comprobar cada propuesta, parte del ahorro puede desaparecer. También debe permitir rechazar, corregir y dejar pendiente con motivos útiles. Esos resultados pueden ayudar a mejorar el proceso, pero no deben reutilizarse automáticamente como datos de entrenamiento sin revisar calidad y finalidad. La decisión humana también puede contener errores o depender de información que no quedó registrada.
4.3 Extracción de información documental
La extracción puede transformar un documento en campos estructurados para revisión. El problema no termina al reconocer texto. Es necesario comprobar qué representa cada campo, qué versión del documento se utilizó y si existen varias cantidades o fechas. Una factura, un justificante y una comunicación comercial pueden contener importes parecidos con funciones distintas. La validación debe relacionar el dato con su contexto y conservar una referencia que permita volver a la evidencia original.
El diseño debería distinguir campo ausente, campo ilegible y valor inferido. Rellenar una ausencia con una conjetura puede crear una apariencia de completitud peligrosa. El sistema debe poder declarar que no dispone de información suficiente. Para campos con consecuencias económicas, conviene utilizar comprobaciones adicionales adecuadas al proceso. La generación de una estructura válida no garantiza que su contenido sea correcto, por lo que el formato y la exactitud deben evaluarse por separado.
4.4 Resúmenes para atención y seguimiento
Un resumen puede ayudar a comprender un historial extenso, siempre que conserve hechos relevantes y permita verificar su origen. Debe diferenciar afirmaciones del cliente, registros del sistema y decisiones del equipo. Si los mezcla, puede presentar una solicitud como una acción ya realizada. La empresa debe definir qué contenido necesita el agente y qué información no debe omitirse, como una condición pendiente o una discrepancia todavía no resuelta.
El resumen no debería convertirse en el único registro disponible. El agente necesita acceso proporcionado a las fuentes para comprobar detalles cuando la decisión lo requiere. También conviene señalar el momento hasta el que está actualizado. Un texto correcto al generarse puede quedar desfasado tras un nuevo pago o mensaje. El proceso debe decidir cuándo actualizarlo y cómo evitar que una versión antigua siga guiando respuestas posteriores.
4.5 Clasificación de incidencias y distribución del trabajo
Clasificar solicitudes puede facilitar asignación y prioridad. La evaluación debe comprobar si la categoría ayuda a resolver el caso, no solo si coincide con una etiqueta histórica. Algunas consultas contienen varios problemas y necesitan más de una función. El sistema debe permitir esa complejidad cuando sea relevante. Una clasificación demasiado rígida puede enviar el caso de un equipo a otro y aumentar el tiempo total aunque la primera asignación sea rápida.
La prioridad debe relacionarse con impacto y criterios del negocio. No debe basarse únicamente en tono o longitud del mensaje, que pueden reflejar diferencias de comunicación. El equipo necesita revisar qué señales se utilizan y qué efectos producen. Una persona que escribe de forma breve no debería recibir peor atención por una inferencia injustificada sobre urgencia. El modelo debe apoyar un criterio explícito y existir una vía para corregir asignaciones inadecuadas.
4.6 Separar lectura, propuesta y ejecución
Las capacidades de una herramienta deben limitarse según la tarea. Un asistente que lee registros y prepara una propuesta no necesita necesariamente permiso para modificarlos. Si se permite ejecutar cambios, deben existir reglas de autorización y validación fuera de la generación de texto. El proceso debe comprobar que la acción corresponde al caso y que sus parámetros son válidos. La fluidez de una explicación no sustituye esa comprobación.
La separación también facilita pruebas. Se puede observar primero qué propone el sistema sin aplicar cambios y comparar con decisiones reales. Después, si la evidencia lo justifica, puede ampliarse el alcance de forma acotada. Cada ampliación debe revisar consecuencias y recuperación. No conviene pasar de apoyo informativo a ejecución simplemente porque la herramienta ofrece la función. La autorización debe responder a una decisión consciente del negocio y a controles que puedan mantenerse.
4.7 Medir trabajo neto
El tiempo ahorrado en una etapa debe compararse con revisión, corrección y seguimiento adicionales. Si preparar una propuesta tarda menos pero comprobarla exige más esfuerzo, el beneficio puede ser menor de lo esperado. Conviene medir el recorrido completo y distinguir casos sencillos de excepciones. Una media global puede ocultar que el sistema ayuda en operaciones habituales y complica las difíciles, precisamente donde el equipo necesita más apoyo.
La capacidad liberada no equivale automáticamente a reducción de gasto. Puede permitir atender mejor, reducir pendientes o absorber volumen. Estas consecuencias deben describirse según lo observado. Para afirmar ahorro financiero es necesario identificar qué coste cambia realmente. El análisis debe evitar convertir una estimación de minutos en una promesa económica universal. Un resultado útil puede ser una mejor distribución del trabajo, siempre que se mida y no se presente como algo distinto.
4.8 Mantener criterios y conocimiento
Las reglas de conciliación y atención cambian con productos, proveedores y políticas. El sistema debe utilizar información vigente y el equipo debe saber quién la mantiene. Una base documental desactualizada puede producir respuestas coherentes con una política que ya no existe. La revisión de contenido debe acompañar cambios operativos, con versiones y responsables. No basta con actualizar el modelo si la fuente de conocimiento conserva instrucciones contradictorias.
El Framework de Operaciones de Pago permite situar estos usos dentro del proceso de cobro y cierre. La conclusión es que la inteligencia artificial resulta más defendible cuando reduce búsqueda o preparación manteniendo evidencia y control. La automatización debe hacer el trabajo más explicable, no esconder incertidumbre detrás de un resultado completo. Cada propuesta necesita un camino claro hacia validación, corrección o rechazo.
5. Asistentes generativos, seguridad y límites de acción
5.1 Fluidez no equivale a exactitud
Un asistente generativo puede producir una explicación clara y, aun así, contener un dato incorrecto. En pagos, un error sobre importe, estado o condición puede tener consecuencias prácticas. La empresa debe diseñar el uso para que los hechos procedan de fuentes adecuadas y puedan comprobarse. El modelo puede ayudar a redactar o resumir, pero no debería inventar un resultado económico cuando la información no está disponible. La ausencia de evidencia debe conservarse como tal en la respuesta.
El perfil de inteligencia artificial generativa de NIST AI 600-1 incluye la confabulación entre los riesgos a considerar. Se utiliza aquí como referencia para evaluar contenido que parece plausible sin estar sustentado. Esta guía no demuestra que una configuración elimine el riesgo ni establece una garantía de exactitud. La respuesta empresarial debe combinar fuentes, evaluación y límites de uso según las consecuencias del contenido. Fuente: NIST, Generative Artificial Intelligence Profile.
5.2 Responder desde información vigente
Una base de conocimiento puede mejorar la pertinencia de respuestas, pero necesita selección y mantenimiento. Si contiene documentos contradictorios o antiguos, el asistente puede utilizar una versión inadecuada. El equipo debe identificar fuentes autorizadas, fecha de vigencia y responsable. También debe definir qué ocurre cuando no encuentra una respuesta suficiente. Un sistema útil puede reconocer límites y derivar el caso; no necesita responder con aparente certeza a todas las preguntas.
La referencia a una fuente debe comprobarse. Un enlace presente en la respuesta no garantiza que respalde la afirmación. Las pruebas deben revisar si el contenido citado existe, es pertinente y se aplica al caso. En asuntos comerciales, importa además si corresponde al producto contratado y al periodo vigente. La evaluación debe incluir preguntas que mezclan condiciones de distintos servicios para observar si el sistema mantiene esas diferencias o produce una síntesis engañosa.
5.3 Información no confiable dentro de documentos
OWASP describe la inyección de instrucciones como un riesgo en aplicaciones con modelos de lenguaje: contenido de entrada puede intentar alterar el comportamiento esperado. Una solicitud, documento o página debe tratarse como información a analizar y no como autoridad para ampliar permisos o cambiar reglas. Esta referencia técnica sustenta la necesidad de separar contenido externo de instrucciones autorizadas del sistema. Fuente: OWASP, LLM01 Prompt Injection.
En un proceso de pagos, el asistente puede leer correos, justificantes o notas de atención. El diseño debe impedir que una frase dentro de esos materiales autorice una devolución, cambie un destinatario o solicite datos ajenos al caso. La defensa no debe depender únicamente de pedir al modelo que ignore instrucciones maliciosas. Deben existir permisos y validaciones que limiten lo que puede consultar o ejecutar, incluso si interpreta incorrectamente el contenido.
5.4 Permisos fuera de la generación de texto
Las reglas de autorización deben comprobarse en el sistema que ejecuta la acción. Una respuesta del modelo no debe funcionar como permiso suficiente. El negocio necesita verificar usuario, recurso, operación y límites aplicables. Si el asistente propone un reembolso, por ejemplo, la propuesta debe pasar por los controles correspondientes antes de producir un efecto. Esta separación permite que una salida errónea sea detectada sin convertirse inmediatamente en un movimiento o una modificación persistente.
Los permisos deben ser los necesarios para la tarea. Un asistente que resume incidencias no requiere acceso general a todos los clientes ni capacidad de modificar cuentas. También conviene separar entornos de prueba y operación. Las credenciales y configuraciones deben mantenerse mediante mecanismos adecuados, sin incluir secretos en instrucciones o documentos visibles al modelo. El objetivo es que la arquitectura sostenga los límites y no dependa exclusivamente del comportamiento esperado de una respuesta.
5.5 Confirmación de acciones con consecuencias
Cuando se permite una acción, el usuario o responsable debe poder comprender qué ocurrirá. Una confirmación útil presenta operación, destino, importe o alcance relevante, según el caso. No basta con una pregunta genérica que oculta parámetros importantes. El proceso debe distinguir preparar una acción de ejecutarla y conservar evidencia de la autorización. Esta distinción resulta esencial cuando el asistente transforma lenguaje natural en una instrucción estructurada.
La confirmación tampoco sustituye todas las validaciones. Una persona puede aprobar una propuesta que no comprende o que contiene un dato incorrecto. El sistema debe comprobar reglas deterministas y límites antes de actuar. La revisión humana debe aportar criterio real, con información y tiempo suficientes. Si se convierte en aceptación rutinaria de cualquier propuesta, su capacidad de control disminuye. El diseño debe evaluar esta interacción como parte del sistema completo.
5.6 Datos de clientes y separación entre casos
El asistente debe acceder solo a información pertinente y autorizada. Una pregunta sobre un pedido no justifica mostrar registros de otra persona. La recuperación de documentos debe respetar permisos y no confiar únicamente en que el modelo filtre después lo que no corresponde. El negocio necesita comprobar escenarios con usuarios y recursos distintos para verificar que el acceso se mantiene separado. La calidad de una respuesta no compensa una exposición indebida de información.
Los historiales de conversación también requieren gestión. Pueden contener datos personales, incidencias y detalles comerciales. La empresa debe conocer dónde se almacenan, quién puede consultarlos y qué uso realiza el proveedor conforme a sus condiciones. Una configuración adecuada para contenido público puede no serlo para información de clientes. La decisión de utilizar una herramienta debe incluir estas preguntas antes de enviar datos, no después de que el proceso dependa de ella.
5.7 Respuestas al cliente y escalado
Un asistente de atención debe conocer el límite entre informar y comprometer al negocio. Puede explicar un procedimiento vigente, pero no debería prometer una devolución o una fecha sin evidencia y autorización. La respuesta debe distinguir lo confirmado de lo estimado y ofrecer un siguiente paso cuando falta información. El equipo necesita revisar casos donde el usuario insiste, aporta datos contradictorios o solicita una excepción. La presión conversacional no debe ampliar capacidades por sí sola.
El escalado debe transferir contexto útil sin obligar al cliente a empezar de nuevo. Conviene registrar pregunta, información comprobada y motivo de derivación. El agente humano debe poder consultar fuentes y corregir el resumen. Si el asistente oculta incertidumbre, puede condicionar indebidamente la decisión posterior. La transición entre automatización y atención debe evaluarse como un recorrido único, incluyendo tiempos y calidad de resolución.
5.8 Pruebas adversas dentro de un alcance autorizado
La evaluación debe incluir entradas confusas, documentos con instrucciones ajenas a la tarea y solicitudes fuera de permisos. Estas pruebas deben realizarse en un entorno autorizado y con datos adecuados. El objetivo es comprobar si los límites se mantienen, no intentar acceder a sistemas ajenos. Los resultados deben registrar qué capacidad falló y qué control debe corregirse. Una respuesta segura en algunos ejemplos no demuestra resistencia general, por lo que las conclusiones deben ser acotadas.
También debe probarse la capacidad de no responder o no actuar. Un sistema que siempre completa una salida puede ocultar falta de evidencia. La empresa necesita criterios para detenerse, pedir revisión o utilizar el proceso alternativo. La conclusión del capítulo es que un asistente generativo aporta valor cuando su contenido puede verificarse y sus acciones permanecen dentro de permisos comprobados. La arquitectura, la evaluación y la operación deben sostener ese límite conjuntamente.
6. Gobernanza, privacidad y marco europeo
6.1 Clasificar por finalidad y efectos
La evaluación de una aplicación debe considerar qué hace, quién la utiliza y qué consecuencias produce. La etiqueta comercial de inteligencia artificial no determina por sí sola todas las obligaciones. Un asistente interno de redacción y un sistema que influye en decisiones sobre personas pueden requerir análisis distintos. La empresa debe documentar finalidad, datos, rol y uso real, evitando asumir que una herramienta contratada transfiere automáticamente todas las responsabilidades al proveedor.
La Comisión Europea mantiene información sobre el Reglamento de Inteligencia Artificial y su calendario de aplicación. Su página actualizada en agosto de 2026 distingue obligaciones y fechas según categorías, incluidas modificaciones del calendario para sistemas de alto riesgo. Por ello, no es correcto utilizar una única fecha como resumen de todos los requisitos. La clasificación y los plazos deben comprobarse para el caso concreto antes de implantar o ampliar una aplicación. Fuente: Comisión Europea, Navigating the AI Act.
6.2 Un inventario que refleje el uso real
La empresa necesita conocer dónde utiliza inteligencia artificial, incluyendo funciones incorporadas a herramientas existentes. El inventario debería indicar finalidad, responsable, proveedor, datos y capacidades de acción. No tiene que ser un catálogo técnico exhaustivo para resultar útil. Debe permitir identificar qué procesos dependen de una salida del modelo y quién puede decidir sobre su continuidad. Una función activada informalmente puede tener efectos relevantes aunque nunca se haya presentado como un proyecto independiente.
El inventario debe actualizarse cuando cambia el alcance. Pasar de generar borradores a enviarlos, o de sugerir correspondencias a confirmarlas, modifica consecuencias. Esa ampliación merece revisión aunque se utilice el mismo producto. El equipo debe evitar que las capacidades crezcan mediante pequeñas decisiones locales sin una visión conjunta. Un registro breve de cambios permite mantener control y distinguir el uso aprobado del uso que se ha desarrollado por costumbre.
6.3 Protección de datos desde la configuración
La AEPD explica la protección de datos por defecto mediante límites sobre cantidad, extensión, conservación y accesibilidad del tratamiento. Esta referencia resulta relevante al configurar entradas, historiales y registros de una aplicación de inteligencia artificial. La disponibilidad de información no justifica utilizarla para cualquier finalidad. El proceso debe definir qué necesita y cómo mantiene esos límites sin depender de que cada usuario elimine manualmente datos innecesarios. Fuente: AEPD, protección de datos por defecto.
La revisión debe seguir el recorrido de los datos hasta proveedores, registros y exportaciones. Puede haber copias en conversaciones, archivos de prueba o sistemas de evaluación. Cada una necesita una finalidad y una gestión adecuada. El negocio debe conocer condiciones de uso, conservación y acceso del servicio contratado, sin presumir que todas las modalidades de un proveedor ofrecen las mismas garantías. La elección debe basarse en documentación aplicable y configuración efectiva.
6.4 Explicaciones que permitan comprender consecuencias
La AEPD, en su análisis sobre sistemas automatizados, destaca la importancia de información significativa sobre la lógica aplicada y consecuencias en los supuestos pertinentes del RGPD. Una descripción genérica de que se usan algoritmos no explica necesariamente una decisión. Esta referencia no implica que todos los usos de inteligencia artificial estén sujetos al mismo régimen; exige examinar tratamiento, efectos y condiciones concretas. Fuente: Laboratorio AEPD, comprensión de sistemas automatizados.
Desde la gestión, conviene distinguir explicación del proceso y explicación de un resultado individual. La primera describe cómo se utiliza el sistema; la segunda requiere evidencia sobre el caso. Un texto generado que parece explicar una decisión puede ser inadecuado si no corresponde a los factores realmente utilizados. La empresa debe evitar sustituir trazabilidad por una narración plausible. La explicación debe apoyarse en información verificable y reconocer límites cuando no puede atribuir una causa concreta.
6.5 Supervisión humana con capacidad efectiva
La supervisión necesita personas que comprendan el objetivo, dispongan de información y puedan cambiar una decisión cuando sea necesario. Una aprobación rutinaria no garantiza control. El diseño debe considerar volumen de casos, tiempo y autoridad. Si el revisor no puede acceder a evidencia o no tiene permiso para detener el proceso, su intervención puede ser meramente formal. La empresa debe evaluar esa capacidad como parte del funcionamiento del sistema.
También conviene revisar incentivos. Si se premia únicamente rapidez, puede aumentar aceptación automática de propuestas. Si se penaliza toda discrepancia con el modelo, se reduce la posibilidad de corregirlo. El equipo necesita un marco donde pueda registrar dudas y errores sin ocultarlos. La finalidad de la supervisión es mejorar decisiones, no producir una apariencia de validación. Los casos de desacuerdo pueden aportar información valiosa sobre límites del sistema y del procedimiento.
6.6 Formación vinculada a tareas
La formación debe explicar qué puede hacer la herramienta, qué no puede concluir y qué datos no deben introducirse. Debe incluir ejemplos del trabajo cotidiano: una respuesta sin fuente, una propuesta económica incorrecta o un documento con instrucciones ajenas a la tarea. El objetivo no es que todo el personal conozca detalles del modelo, sino que pueda utilizarlo con criterio y reconocer cuándo necesita verificar o escalar.
La formación debe actualizarse con cambios de funciones y capacidades. Una guía válida para generar borradores puede resultar insuficiente si después se habilitan acciones. También conviene observar cómo se utiliza realmente la herramienta, porque las prácticas informales pueden diferir del procedimiento escrito. Las dudas repetidas permiten mejorar instrucciones y diseño. La responsabilidad no debe recaer exclusivamente en recordar advertencias; los controles del sistema deben facilitar el comportamiento esperado.
6.7 Proveedores y responsabilidades documentadas
La evaluación contractual debe considerar servicio, datos, soporte y cambios relevantes. La empresa necesita saber qué puede exigir y qué debe mantener por su cuenta. Una declaración comercial de seguridad o cumplimiento no sustituye el análisis del uso concreto. Conviene pedir documentación que permita comprender límites y responsabilidades sin asumir que la certificación de un componente acredita todo el proceso empresarial en el que se integra.
La dependencia debe incluir capacidad de salida. Si el servicio cambia o deja de estar disponible, el negocio necesita recuperar información necesaria y continuar tareas prioritarias. Las condiciones deben revisarse antes de crear una dependencia difícil de revertir. Este análisis no presupone un conflicto con el proveedor; permite conocer el compromiso que se adquiere. La continuidad y la gobernanza son más sencillas cuando existen registros y procedimientos que no dependen exclusivamente de una interfaz.
6.8 Revisión periódica y respuesta a incidentes
El sistema debe tener criterios que activen revisión: cambio de modelo, nueva fuente de datos, aumento de errores o ampliación de autonomía. También necesita una forma de detener capacidades afectadas y utilizar un proceso alternativo. Una incidencia puede requerir revisar decisiones anteriores, no solo corregir la configuración futura. El equipo debe identificar alcance, operaciones afectadas y comunicaciones necesarias conforme al caso y al marco aplicable.
La conclusión es que la gobernanza convierte una herramienta en una capacidad mantenible. El negocio debe conocer usos, responsables, datos y límites, y conservar evidencia para revisar resultados. La privacidad y las obligaciones regulatorias no se resuelven con una etiqueta genérica. Requieren comprender el tratamiento y sus efectos. Esa disciplina permite adoptar inteligencia artificial con expectativas ajustadas y corregir el rumbo cuando el uso real se aparta de lo previsto.
7. Evaluación, costes y seguimiento del rendimiento
7.1 Comparar con una referencia útil
La evaluación necesita una referencia que represente el trabajo actual o una alternativa razonable. Comparar un modelo con ausencia total de proceso puede exagerar su valor si la empresa ya dispone de reglas o experiencia. La referencia debe utilizar datos y condiciones comparables. También debe reflejar el objetivo real: resolver una incidencia, identificar una correspondencia o preparar una respuesta correcta. Una métrica técnica puede ser informativa, pero no sustituye la pregunta sobre utilidad operativa.
Conviene conservar una descripción del proceso de referencia y sus limitaciones. Si se modifica durante la prueba, debe anotarse para interpretar resultados. El equipo debe evitar atribuir al modelo mejoras que proceden de formación, limpieza de datos o cambios simultáneos de política. Estas mejoras pueden ser valiosas, pero su explicación importa para decidir qué mantener y dónde invertir. La evaluación debe distinguir contribuciones en la medida que la evidencia permita hacerlo.
7.2 Diseñar conjuntos de prueba
El conjunto de prueba debe incluir casos habituales, excepciones y situaciones donde falta información. Debe mantenerse separado de los datos utilizados para ajustar el sistema cuando esa separación sea necesaria para evaluar generalización. Reutilizar repetidamente los mismos ejemplos puede producir una configuración que funciona bien en ellos y falla en otros. El equipo necesita registrar cómo se seleccionaron los casos y qué parte del uso previsto representan.
La composición debe revisarse con conocimiento del negocio. Un conjunto formado solo por solicitudes limpias y completas no evalúa entradas confusas o contradictorias. Tampoco debe exagerarse la proporción de casos extremos hasta perder relación con el uso real. Puede ser útil mantener grupos separados para rendimiento habitual y pruebas de límites. Sus resultados deben comunicarse por separado para no confundir robustez frente a excepciones con frecuencia esperada de esas situaciones.
7.3 Medir contenido, decisión y acción
Una aplicación puede acertar en el contenido y fallar en la acción, o producir una explicación deficiente sobre una decisión correcta. La evaluación debe separar esas dimensiones. En un asistente, interesa si los hechos son correctos, si la respuesta utiliza fuentes pertinentes y si respeta límites. En una propuesta de conciliación, importa la correspondencia y la evidencia. En una acción, deben comprobarse parámetros, autorización y efecto registrado. Un único porcentaje puede ocultar diferencias materiales.
| Dimensión | Qué observar | Límite de interpretación |
|---|---|---|
| Exactitud | Resultado frente a referencia definida. | Depende de calidad y cobertura de la referencia. |
| Utilidad | Trabajo total necesario para resolver. | La rapidez inicial puede desplazar esfuerzo. |
| Seguridad | Respeto de permisos y límites. | Algunas pruebas no demuestran protección universal. |
| Experiencia | Comprensión, ayuda y correcciones. | Menos contactos no siempre implica mejor servicio. |
| Economía | Costes incluidos y capacidad liberada. | Tiempo ahorrado no equivale siempre a gasto eliminado. |
La tabla es elaboración editorial y no prescribe umbrales. Cada aplicación debe definir criterios de aceptación antes de interpretar resultados. Si el equipo cambia el criterio después de ver la prueba, debe explicarlo y comprobar la nueva hipótesis con evidencia adecuada. Esta disciplina reduce la tentación de seleccionar únicamente los indicadores favorables y presentar un resultado parcial como éxito general.
7.4 Piloto sin efectos y ampliación gradual
Una primera prueba puede observar propuestas sin aplicarlas. Este funcionamiento permite comparar resultados con el proceso habitual y detectar errores antes de ampliar capacidades. Debe tener un alcance definido y una duración suficiente para la pregunta planteada, sin convertirlo en una actividad indefinida. Si la evidencia es favorable, la siguiente fase puede limitarse a un conjunto de casos y mantener controles de revisión. Cada ampliación debe tener criterios y posibilidad de retirada.
El piloto debe incluir usuarios que realizarán la tarea y no solo al equipo que construyó la solución. Su experiencia permite identificar información ausente, dificultades de interpretación y trabajo adicional. También debe observarse cómo cambia el comportamiento al utilizar la herramienta. Una persona puede revisar menos cuando confía en la presentación del sistema. Esa interacción forma parte del resultado y debe considerarse al decidir si el control previsto funciona realmente.
7.5 Coste total de uso
El coste puede incluir servicio, integración, preparación de datos, evaluación, revisión humana y mantenimiento. Algunas partidas son iniciales y otras crecen con volumen o complejidad. La empresa debe definir el alcance de la comparación y conservar supuestos. Una tarifa por uso puede parecer pequeña mientras la corrección consume recursos importantes. Del mismo modo, una inversión inicial puede justificarse si reduce trabajo sostenido, pero ese beneficio debe observarse y no presumirse.
Un ejemplo hipotético puede ayudar: si una tarea requiere cinco minutos y la herramienta reduce la preparación a dos, todavía debe sumarse el tiempo de revisión y corrección. Si esa revisión consume dos minutos, el ahorro neto del ejemplo sería un minuto, no tres. Las cantidades son ilustrativas y no representan un rendimiento de mercado. El cálculo muestra por qué debe medirse el recorrido completo y distinguir tiempo liberado de reducción efectiva de gasto.
7.6 Incertidumbre y tamaño de la evidencia
Un resultado favorable en pocos casos puede ser una señal útil, pero no permite conclusiones amplias sin considerar incertidumbre. La empresa debe explicar tamaño, composición y periodo de la prueba. Si existen pocos errores observados, eso no demuestra que sean imposibles. Las decisiones deben tener en cuenta consecuencias y capacidad de detectar fallos posteriores. Cuanto mayor sea el impacto de una acción, más importante resulta que la evidencia sea adecuada a la confianza que se pretende depositar.
Las comparaciones temporales necesitan cautela. El volumen, la mezcla de operaciones y las políticas pueden cambiar entre periodos. Cuando no existe un diseño que permita atribuir causalidad, el informe debe hablar de asociación observada. Esta precisión no resta utilidad al aprendizaje; evita convertir una coincidencia en garantía. El equipo puede utilizar resultados preliminares para formular nuevas pruebas y decidir si merece la pena continuar, sin presentar el proyecto como validado definitivamente.
7.7 Seguimiento de cambios y degradación
El rendimiento puede variar por cambios en entradas, modelo, fuentes o comportamiento del equipo. El seguimiento debe observar señales relacionadas con el objetivo y con límites de seguridad. No basta con vigilar disponibilidad técnica. Un servicio puede responder sin interrupciones y producir resultados menos útiles. La empresa necesita umbrales o condiciones de revisión que permitan investigar antes de que el deterioro se normalice como parte del trabajo.
Cuando se actualiza un componente, conviene conservar versión y alcance del cambio. Deben repetirse las comprobaciones pertinentes, especialmente aquellas que protegen acciones sensibles o casos conocidos de fallo. No es necesario repetir toda prueba ante cualquier modificación menor, pero sí justificar qué puede verse afectado. La gestión de versiones permite relacionar resultados con cambios y volver a una configuración conocida cuando la nueva no cumple las condiciones requeridas.
7.8 Decidir continuar, modificar o retirar
El criterio de éxito debe incluir una decisión de continuidad. Si la herramienta no mejora el proceso o introduce consecuencias que no pueden controlarse, debe poder modificarse o retirarse. Mantener una solución porque ya se invirtió esfuerzo puede prolongar costes sin beneficio. La documentación debería conservar qué se aprendió y qué condiciones podrían justificar una nueva prueba. Un piloto que descarta una hipótesis también puede aportar valor al evitar una implantación mayor basada en expectativas infundadas.
La retirada necesita un procedimiento: recuperar información necesaria, cerrar accesos y restablecer el proceso alternativo. También debe revisarse si quedan decisiones pendientes o registros generados que requieren seguimiento. La continuidad no termina al desactivar una función. El negocio debe asegurar que las personas y operaciones afectadas conservan un camino de resolución. Esta preparación hace que experimentar sea más manejable y reduce presión para mantener capacidades que todavía no están justificadas.
La conclusión del capítulo es que evaluar inteligencia artificial exige mirar más allá de una demostración. El sistema debe compararse con una referencia, probarse en condiciones relevantes y seguirse durante su uso. La evidencia debe conservar incertidumbre y explicar costes completos. El valor aparece cuando una mejora puede sostenerse y corregirse, no cuando un modelo obtiene una cifra favorable aislada del proceso empresarial que pretende ayudar.
8. Implantación, conclusiones y fuentes
8.1 Una hoja de ruta por decisiones
La implantación puede comenzar con una tarea acotada y un responsable que conozca el proceso. La primera fase describe problema, datos y resultado esperado. La segunda compara alternativas y define pruebas. La tercera observa un piloto limitado. La cuarta decide continuidad y establece mantenimiento. Esta secuencia es orientativa: su duración depende de complejidad y consecuencias. El objetivo es que cada fase produzca evidencia útil y una decisión, no simplemente un documento que confirme la intención inicial de utilizar inteligencia artificial.
La hoja de ruta debe conservar límites. Si el primer objetivo es preparar borradores, no debe incluir silenciosamente su envío automático. Si el objetivo es priorizar revisiones, no debe transformarse en bloquear operaciones sin una evaluación adicional. El equipo necesita reconocer cuándo cambia la naturaleza de la capacidad. Mantener el alcance visible facilita aprender y evita que el proyecto adquiera consecuencias que no fueron consideradas al aprobarlo.
8.2 Responsabilidades y recursos
El responsable del caso de uso debe coordinar negocio, tecnología y funciones especializadas pertinentes. También necesita participación de quienes utilizarán el resultado. La asignación debe indicar quién mantiene datos, fuentes, pruebas y respuesta a incidencias. En una empresa pequeña, una persona puede asumir varias tareas, pero cada una debe tener una respuesta concreta. La ausencia de un departamento específico no justifica que decisiones relevantes queden sin dueño.
Los recursos deben incluir tiempo de revisión y mantenimiento. Un piloto puede funcionar mientras recibe atención extraordinaria y dejar de hacerlo al incorporarse al trabajo habitual. Por eso, conviene evaluar si el equipo puede sostenerlo sin depender de esfuerzo excepcional. La planificación debe contemplar sustituciones y documentación suficiente para que el conocimiento no quede concentrado. Una capacidad útil es aquella que puede mantenerse cuando cambian personas, volumen o prioridades.
8.3 Un caso hipotético de conciliación asistida
Considérese una empresa que revisa manualmente diferencias entre cobros y pedidos. El primer paso sería identificar qué casos se resuelven mediante referencias claras y cuáles requieren interpretar descripciones. Las reglas directas pueden mantenerse para los primeros. Para los segundos, un modelo podría proponer correspondencias con evidencia visible. El piloto observaría propuestas sin aplicarlas y compararía exactitud, tiempo de revisión y casos pendientes con el proceso habitual.
Si la herramienta reduce búsqueda pero aumenta asociaciones incorrectas, el equipo debe revisar el diseño antes de ampliar uso. Puede ser necesario limitar tipos de caso, mejorar datos o modificar la presentación. Si la evidencia resulta favorable, una fase posterior podría incorporar más operaciones conservando criterios de aceptación. El ejemplo no afirma que la solución produzca ahorro en una empresa concreta. Muestra cómo convertir una idea general en una prueba con consecuencias y límites observables.
8.4 Un caso hipotético de atención
Un segundo ejemplo es un asistente que prepara respuestas sobre incidencias de pago. El alcance inicial puede limitarse a consultar una base vigente y redactar un borrador para el agente. La prueba debe incluir preguntas sin respuesta, datos contradictorios y solicitudes que requieren una decisión económica. El sistema debería reconocer cuándo no puede confirmar un estado o conceder una excepción. La evaluación incluiría exactitud, fuentes y tiempo total hasta resolver el caso.
La ampliación a respuestas directas al cliente requeriría revisar información, transparencia, escalado y control de calidad. No debe asumirse que un borrador útil para un agente resulta automáticamente adecuado para envío sin revisión. El contexto humano puede haber corregido errores que el cliente recibiría sin filtro. El cambio de destinatario y autonomía modifica el riesgo y debe tratarse como una nueva decisión de implantación, aunque el modelo y la base documental sean los mismos.
8.5 Preguntas para una revisión de dirección
La revisión puede comenzar con preguntas sencillas: ¿qué tarea mejora?, ¿qué evidencia lo demuestra?, ¿qué errores produce?, ¿quién los resuelve?, ¿qué ocurre si se retira? Las respuestas deben distinguir resultados observados de expectativas. Si una afirmación depende de datos todavía no disponibles, debe presentarse como hipótesis. La dirección necesita comprender consecuencias y recursos, no únicamente una demostración de funcionamiento. Esa claridad permite decidir con proporcionalidad y evitar compromisos basados en impresiones.
También conviene preguntar qué ha cambiado desde la evaluación inicial. Un nuevo proveedor, una fuente adicional o permisos más amplios pueden alterar el alcance. La revisión debe identificar si las pruebas y controles siguen siendo adecuados. No se trata de reiniciar todo el proyecto ante cualquier cambio, sino de relacionar modificaciones con consecuencias. El registro de decisiones facilita esa continuidad y permite que el aprendizaje sobreviva a cambios de personas o herramientas.
Una comprobación complementaria consiste en seleccionar decisiones recientes y reconstruir su recorrido. El equipo debería identificar la entrada disponible, la versión utilizada, la propuesta del sistema y la acción finalmente realizada. Si esos elementos no pueden relacionarse, conviene revisar la trazabilidad antes de ampliar el uso. El ejercicio debe respetar permisos y minimizar información personal, utilizando solo lo necesario para la finalidad de revisión. Su alcance debe describirse con honestidad: una muestra pequeña puede revelar problemas, pero no demuestra por sí sola la calidad de todas las operaciones.
Después conviene examinar un caso en el que el sistema se abstuvo o fue corregido. Esa situación permite comprobar si el procedimiento alternativo funcionó y si el aprendizaje llegó a quienes mantienen la herramienta. Un registro de errores sin responsable no mejora el servicio. La revisión debe terminar con una acción concreta, una condición de finalización y una fecha para comprobar el resultado. Así se conecta evaluación con mantenimiento cotidiano y se evita que el conocimiento permanezca en conversaciones aisladas que el siguiente equipo no podrá recuperar cuando necesite interpretar una decisión anterior.
8.6 Glosario operativo
Modelo predictivo: sistema que estima o clasifica a partir de datos. Modelo generativo: sistema que produce contenido. Regla: condición definida explícitamente para una decisión o acción. Referencia de evaluación: criterio utilizado para comparar resultados. Falso positivo: señal incorrecta de un caso problemático según esa referencia. Falso negativo: caso problemático que el sistema no identifica. Estas definiciones de trabajo deben adaptarse a la tarea sin perder su distinción.
Confabulación: contenido plausible que carece de sustento adecuado o es incorrecto. Inyección de instrucciones: intento de alterar comportamiento mediante contenido de entrada. Deriva: cambio relevante en datos o relaciones que puede afectar rendimiento. Supervisión humana: intervención con capacidad efectiva de examinar y modificar decisiones. Piloto: prueba acotada con hipótesis y criterio de salida. Autonomía: alcance de acciones que un sistema puede realizar dentro de permisos establecidos.
8.7 Conclusiones
La inteligencia artificial puede apoyar operaciones de pago cuando su función está delimitada y sus resultados pueden comprobarse. Detectar patrones, preparar información y proponer decisiones son capacidades distintas de confirmar hechos o ejecutar movimientos. La empresa debe mantener esa separación en datos, mensajes y permisos. Una mejora defendible relaciona rendimiento con trabajo real, costes y efectos sobre personas. No basta con que una respuesta sea rápida, una predicción parezca precisa o una demostración resulte convincente.
La adopción requiere datos interpretables, pruebas pertinentes y responsables capaces de mantener el proceso. Los errores deben observarse y corregirse, incluyendo los que afectan a operaciones legítimas. La supervisión humana debe tener información y autoridad, y los límites de acción deben sostenerse mediante controles externos a la generación de texto. La privacidad, la seguridad y el marco aplicable forman parte del diseño concreto, no de una declaración genérica de confianza en la tecnología.
La propuesta de este paper es avanzar mediante casos de uso verificables y ampliaciones revisables. El negocio debe conservar un proceso alternativo y criterios para modificar o retirar capacidades. Esta disciplina permite experimentar sin convertir expectativas en garantías. El valor de la inteligencia artificial en los pagos aparece cuando ayuda a comprender y resolver operaciones manteniendo evidencia, proporcionalidad y capacidad de recuperación a lo largo del tiempo.
8.8 Fuentes primarias
Consulta editorial: septiembre de 2026. Las referencias sustentan los criterios atribuidos en el texto. Los ejemplos numéricos y operativos son ilustrativos y no representan datos de clientes. La selección no constituye una revisión sistemática ni acredita cumplimiento de una implantación. Las condiciones normativas, técnicas y contractuales deben comprobarse cuando se adopte una decisión concreta.
- NIST — AI Risk Management Framework. Referencia voluntaria para gestión de riesgos durante el ciclo de vida de sistemas de inteligencia artificial.
- NIST — Generative Artificial Intelligence Profile, AI 600-1. Perfil específico que incluye riesgos de contenido generativo, utilizado aquí para contextualizar confabulación y evaluación.
- EBA — Innovation Monitoring 2025. Contexto de innovación en banca y pagos, sin extrapolar resultados a comercios individuales.
- BIS Innovation Hub — Project Hertha. Investigación sobre patrones de actividad delictiva en sistemas de pagos minoristas en tiempo real.
- OWASP — LLM01:2025 Prompt Injection. Referencia técnica sobre riesgos de instrucciones introducidas mediante contenido no confiable.
- Comisión Europea — Navigating the AI Act. Orientación institucional sobre alcance, obligaciones y calendario del marco europeo.
- AEPD — Protección de datos por defecto. Criterios sobre cantidad, extensión, conservación y acceso a datos personales.
- Laboratorio AEPD — Comprensión de algoritmos en sistemas automatizados. Reflexión sobre información significativa y consecuencias de decisiones en los supuestos pertinentes.
Documento de la biblioteca de investigación de Soluciones de Pago. Para conocer el enfoque editorial, consulte el equipo de redacción e investigación. Las propuestas no garantizan ahorro, reducción de fraude ni aumento de conversión. Su utilidad debe contrastarse con datos contrastados y las condiciones específicas de cada negocio.
