Automatización con IA de siniestros, tickets y expedientes KYC en tus propios servidores: qué debe preguntar un director de operaciones a una empresa antes de firmar

Antes de firmar con una empresa que se ofrece a automatizar con IA siniestros, tickets de soporte o expedientes KYC en tus propios servidores, pregunta cómo encajará su sistema en el trabajo que hace hoy tu back office. Las buenas respuestas vienen con cifras sacadas de una muestra de tus propios expedientes, como cuántos expedientes seguirán necesitando que una persona los compruebe y cuánto costará operar el sistema cada mes. Si una empresa da cifras antes de haber visto tus expedientes, pregunta con qué documentos se midieron.

¿Cuáles de nuestros expedientes debería ver primero la empresa?

Empieza por preguntar qué expedientes tuyos quiere ver la empresa. Una empresa que ya ha hecho este trabajo suele pedir un mes de los expedientes que recibes de verdad, incluidos los escaneos y las fotos de móvil, los hilos de correo con varios adjuntos, los formularios que vuelven a medio rellenar y los casos que tu personal deriva a un supervisor. También pregunta qué campos te importan, como la fecha del siniestro en un expediente de siniestro o la fecha de caducidad de un documento de identidad, y qué pasa hoy cuando uno de ellos se lee mal.

Antes de la primera reunión, extrae de tu propio sistema un mes de expedientes y ordénalos según el tiempo que le llevó cada uno a tu equipo, porque los expedientes más lentos son los que sirven para poner a prueba a una empresa. Cuenta cuántos hay de cada tipo y anota cuáles tuvo que decidir un supervisor.

Envía a cada empresa de tu lista corta una descripción por escrito de estos expedientes, con los recuentos. Los expedientes reales solo van a la empresa que elijas para una evaluación de pago, un primer contrato breve en el que prueba su sistema en tus propios servidores antes de que firmes el contrato principal. La mayoría de las cifras que aparecen más abajo salen de esa evaluación.

¿Qué pasa con un expediente que el sistema no puede leer?

Todo back office tiene expedientes en los que el sistema fallará, como una foto tomada en ángulo o un extracto bancario con un formato nuevo. Cada uno de ellos tiene que acabar en manos de una persona que pueda decidir.

Elige tres de tus peores expedientes para la evaluación y pide a la empresa que explique, paso a paso, qué le ocurre a cada uno desde su llegada hasta la persona que decide. Anota cualquier paso que la empresa no sepa describir y vuelve a plantearlo antes de firmar.

En una buena respuesta, el expediente va a una cola de revisión, una lista de expedientes que una persona designada de tu equipo va resolviendo. Esa persona ve la página con el campo dudoso marcado, y nada llega a tu sistema de siniestros o de KYC hasta que decide.

La empresa también debería explicar cómo distingue el sistema un expediente que no puede leer de uno que ha leído mal. El segundo tipo es más difícil de detectar, porque una fecha o un importe erróneos parecen un valor como cualquier otro y pasan si nada los comprueba.

¿Cuántas horas de personal llevará comprobar las respuestas del sistema?

Toma cincuenta expedientes de tu muestra y cronometra cuánto tarda hoy tu equipo en cada uno. Durante la evaluación, pregunta a la empresa cuánto de ese tiempo seguirá ocupando la revisión con esos mismos cincuenta expedientes. La diferencia es el tiempo que ahorra el sistema, antes de restar los costes de operación. Si la diferencia es pequeña, sopésala frente al tiempo que necesitará tu personal para aprender una herramienta nueva.

El sistema enviará una proporción de los expedientes a revisión, y esa proporción determina cuánto personal necesitas. La empresa debería estimarla antes de que firmes el contrato principal, para las primeras semanas y para unos meses más tarde, cuando ya se hayan corregido los errores más frecuentes. Sin estas cifras, no puedes planificar la carga de trabajo de tu equipo después del lanzamiento.

La revisión deberían hacerla las personas que hoy tramitan estos expedientes, porque saben cómo es una respuesta correcta. La empresa debería enseñarte la pantalla que usarán, con la página y el campo marcado uno junto al otro, y decirte cuánto dura de media una revisión.

¿Cómo sabemos que el sistema es tan preciso como nuestro personal?

Pide a dos personas de tu equipo que anoten, sin hablar entre ellas, las respuestas correctas de cincuenta expedientes de tu muestra. Donde no coincidan, tu equipo aún no tiene una respuesta acordada, y en esos expedientes no se puede puntuar al sistema. Acuerda cómo se deciden esos casos antes de que empiecen las pruebas.

Las empresas suelen dar la precisión como un único porcentaje para todo el sistema. Una puntuación útil se da por cada campo, como una fecha o un importe, y por cada tipo de documento. Las puntuaciones deberían salir de tu conjunto de prueba: expedientes de tu muestra con las respuestas correctas escritas por tu propio personal, que la empresa no usó al ajustar el sistema. Tu personal también se equivoca, así que mídelo con los mismos expedientes para saber con qué se compara el sistema.

Una buena respuesta fija el umbral de aprobación, la puntuación mínima que debe alcanzar el sistema, antes de acordar el precio. Dice qué campos puede rellenar el sistema por su cuenta una vez que alcance esa puntuación y qué campos van siempre a una persona. Fija el umbral de aprobación a partir de lo que te cuesta un error, como un siniestro pagado dos veces o una cuenta abierta a la persona equivocada, y entrégaselo a la empresa por escrito.

El artículo enlazado justo arriba, sobre los pilotos de IA que nunca llegaron a producción, explica cómo construir el conjunto de prueba.

¿Qué pasa en nuestro día de mayor volumen?

Algunos días llegan muchos más expedientes que otros, como a fin de mes o la mañana siguiente a una tormenta. Un sistema que da abasto en un día normal puede quedarse atrás en un día así.

Busca en tus propios registros el día de mayor volumen del último año, con su número de expedientes, y pide a la empresa que explique cómo lo habría gestionado su sistema. Los servidores son tuyos, así que pregunta también qué supondría añadir capacidad en un día así y cuánto tardaría.

La respuesta debería decir cuántos expedientes por hora puede asumir el sistema en los servidores que le vas a dar, y a quién se llama cuando hay expedientes que llevan más de una hora esperando. Los expedientes deberían esperar en orden, con los tipos urgentes primero, y alguien de tu lado debería poder devolver un tipo de documento a la tramitación manual. Ningún expediente se descarta ni se deja pasar sin comprobar para reducir antes el trabajo acumulado.

¿Cuánto costará operar el sistema cada mes?

Los costes de operación se suman al precio de construcción y duran mientras el sistema esté en marcha. En tus propios servidores tienen al menos cuatro partes:

• los servidores que ejecutan el modelo
• las personas que vigilan el sistema y atienden sus alertas
• el tiempo que tu personal dedica a la revisión
• el trabajo de mantener el sistema al día cuando cambian los modelos y los documentos

Pide a cada empresa una estimación mensual con sus supuestos por escrito: expedientes al mes, páginas por expediente, cuántos de cada tipo y los servidores que prevé. Después compara esos supuestos con tu volumen real. Si una empresa da un coste de operación sin supuestos, pídele que los ponga por escrito antes de comparar su cifra con la de otras empresas.

El contrato debería detallar qué cubre la cuota mensual de soporte de la empresa después del lanzamiento, por ejemplo, si adaptar el sistema a una nueva plantilla de documento está incluido o se factura aparte.

Este artículo no da precios, porque el coste depende de tu volumen y de tus servidores. Cada empresa debería calcularlo a partir de tus propias cifras.

¿Quién se da cuenta cuando cambian nuestros documentos o el modelo?

Después del lanzamiento, tus documentos cambiarán, por ejemplo cuando un banco asociado rediseñe sus extractos o una nueva línea de producto traiga un formulario nuevo. El modelo también puede cambiar, cuando sale una versión más reciente o cuando el software que lo ejecuta en tus servidores deja de admitir la anterior.

Cuando cambia el modelo, el sistema debería volver a puntuarse con tu conjunto de prueba, campo por campo, antes del cambio, y deberías poder volver atrás. Acuerda de antemano quién paga cada una de esas pruebas.

Si todos los extractos de un banco empiezan a ir a revisión el martes, o un campo se lee mal durante una semana, las pantallas de los servidores seguirán sin mostrar ningún error. Para detectarlo, alguien de tu lado debería comprobar cada semana qué proporción de cada tipo de documento va a revisión, y la empresa debería decir qué hace cuando esa proporción cambia.

¿Qué será nuestro al final y quién operará el sistema cuando la empresa se vaya?

Al final del proyecto deberías tener todo lo necesario para operar y modificar el sistema sin la empresa. Es decir, el código, los prompts (las instrucciones escritas que sigue el modelo), el conjunto de prueba con sus respuestas correctas, los scripts que puntúan el sistema y la documentación. Pon esta lista en el contrato, junto con los componentes reutilizables de la empresa, cada uno con su nombre, y lo que puedes hacer con ellos.

Después pregunta quién opera el sistema de tu lado. La empresa debería describir el puesto y lo que esa persona necesita saber, y la formación debería estar terminada antes del lanzamiento. Si la respuesta es «lo operaremos nosotros por ti», pregunta qué pasa cuando termine el contrato y cuánto cuesta el traspaso.

¿Se aplica el Reglamento de IA de la UE (AI Act) a nuestro sistema?

El artículo 4 del Reglamento de IA de la UE se aplica desde el 2 de febrero de 2025. En su redacción actual, establecida por el Reglamento (UE) 2026/1744 de julio de 2026, exige a los proveedores y responsables del despliegue de sistemas de IA que adopten medidas para apoyar la alfabetización en materia de IA de su personal y de otras personas que manejan y utilizan los sistemas en su nombre. No exige ningún nivel concreto de alfabetización en materia de IA a ninguna persona.

El Reglamento califica de alto riesgo algunos usos, entre ellos evaluar la solvencia de personas físicas, salvo para detectar fraudes financieros, y la evaluación de riesgos y la fijación de precios en los seguros de vida y de salud. Para esos usos, el artículo 26 añade obligaciones para la empresa que despliega el sistema, y con la modificación de 2026 se aplican a partir del 2 de diciembre de 2027. La supervisión humana se encomienda entonces a personas con «la competencia, la formación y la autoridad necesarias», y la empresa vigila el funcionamiento del sistema. Los archivos de registro que genera el sistema se conservan durante al menos seis meses en la medida en que estén bajo el control de la empresa, salvo que otra norma disponga otra cosa.

Los bancos, las aseguradoras y otras entidades financieras sujetas a la normativa de servicios financieros de la UE cumplen la obligación de vigilancia aplicando sus normas vigentes de gobernanza interna, y conservan los archivos de registro junto con la documentación que esas normas ya exigen.

Si tu sistema entra en el ámbito de estas normas es una cuestión para tus abogados, y este artículo no es asesoramiento jurídico. Formar a tu personal y designar a la persona que opera el sistema de tu lado ayudan en cualquier caso.

¿Qué respuestas indican que una empresa no ha hecho esto antes?

• La empresa da una cifra de precisión sin haber visto ninguno de tus expedientes
• La empresa dice que el modelo «gestiona bien los casos límite» y no sabe decir adónde va un expediente ilegible
• El plan no incluye una cola de revisión, o deja la revisión a tu personal sin una estimación de horas
• Nadie en la empresa sabe decir qué pasa cuando llegan más expedientes de los que el sistema puede asumir
• El coste mensual de operación llega sin los volúmenes ni los servidores que da por supuestos
• La formación de tu personal empieza después del lanzamiento, o no empieza nunca

¿Dónde encaja amBrain?

El único proyecto con modelos de lenguaje que amBrain describe en público es este: «Hemos llevado a producción una integración de LLM dentro del perímetro FinTech de un cliente: extracción y normalización de avisos no estructurados de brókers y de centros de negociación —eventos corporativos, cambios de instrumentos y de márgenes— en registros estructurados que consume el sistema de trading».

Este artículo no es un caso de estudio, y no se nombra al cliente. No dice que amBrain haya construido un sistema para siniestros, tickets de soporte o expedientes KYC. No se revela dónde se ejecutó el modelo en ese proyecto ni cuáles de las prácticas descritas arriba se usaron en él. No da precios ni plazos de amBrain.

amBrain desarrolla software desde 2019. Describe en una línea cómo trabaja con sus clientes: «Tres formatos: entrega completa, un equipo dedicado o ingenieros integrados en tu equipo». Sobre la propiedad, su frase es: «El cliente conserva la propiedad completa del producto y del código, salvo nuestros componentes reutilizables». Pide a amBrain la lista de esos componentes nombre por nombre, como se la pedirías a cualquier otra empresa.

Si amBrain está en tu lista corta, envíale las mismas preguntas por escrito que a las demás empresas.

Preguntas frecuentes

• Nuestro piloto ya funciona. ¿Siguen siendo válidas estas preguntas? Sí. Un piloto suele mostrar que el sistema puede leer algunos de tus expedientes, y poco sobre el resto de las preguntas de arriba. El artículo sobre los proyectos de IA llave en mano, enlazado al principio, explica cómo pagar el trabajo que convierte un piloto en un sistema que tu back office pueda operar
• ¿Funcionar en nuestros propios servidores significa que ningún dato va a un proveedor externo de modelos? Solo si todos los pasos se ejecutan allí. Pide a la empresa que indique por escrito qué modelo se ejecuta en cada sitio y si algún paso llama a un servicio externo, como un modelo alojado o un servicio de reconocimiento de texto
• ¿Quién de nuestro lado debería estar en estas reuniones? La persona que dirige hoy el back office y alguien de TI que vaya a dar a la empresa sus accesos y sepa lo que pueden soportar tus servidores