Cómo elegir y correr modelos open source para agentes de fintech sin que los datos salgan del país

En una fintech mexicana, la conversación sobre modelos de IA casi siempre termina en la misma pregunta: ¿a dónde se van los datos? Tu área de cumplimiento, tu banco socio y a veces tus clientes empresariales quieren saber que una INE, una CLABE o un estado de cuenta no salen del país ni terminan entrenando el modelo de alguien más. Los modelos de pesos abiertos resuelven buena parte de eso: los corres en tu propia nube, en Querétaro, y decides tú quién los toca.

Esta es una guía práctica para CTOs y líderes de ingeniería en fintechs de México: qué modelos open source considerar para cada trabajo de operaciones, dónde correrlos, cómo evaluarlos con casos en español y cómo encajan con tus agentes.

Qué hace. Te da una lista corta de modelos por caso de uso, sacada de nuestra comparativa de modelos open source, y un método para elegir con tus propios datos.

Qué no es. Un ranking de benchmarks. Los números de los proveedores sirven para filtrar; el modelo lo eliges con tus casos.

Por qué open source en una fintech mexicana

Esto no significa dejar los modelos comerciales. Muchos equipos usan un modelo comercial para el trabajo más difícil y uno open source para lo que toca datos sensibles o tiene mucho volumen.

Dónde correrlos: Querétaro

AWS (región México Central, abierta en enero de 2025), Google Cloud y Microsoft Azure tienen regiones en Querétaro. Con un modelo de pesos abiertos tienes dos caminos:

1. Un servicio administrado como Bedrock o Vertex AI, si el modelo que quieres está disponible en la región que necesitas. Revisa la disponibilidad por región antes de decidir.
2. Tu propio endpoint con GPUs en tu cuenta, en la región de México, con vLLM o SGLang. Más trabajo, control total.

En los dos casos, el agente, el modelo y los datos se quedan en tu nube.

Qué modelo para qué trabajo

Estas son las recomendaciones de nuestra comparativa para los casos de uso de una fintech. Cada caso tiene su página con el detalle.

Los modelos, en corto

Las licencias propias no son necesariamente un problema, pero tu área legal las tiene que revisar. Si necesitas avanzar rápido, empieza con los de MIT o Apache 2.0.

Paso 1: arma tu set de evaluación en español

Este paso lo hace tu equipo con el área de negocio. Junta entre 50 y 100 casos ya resueltos del proceso que quieres automatizar, con la respuesta correcta:

• Tickets reales, con faltas de ortografía, abreviaturas ("transfe", "depo") y mensajes de WhatsApp a medias.
• Documentos locales: CEP de Banxico, constancias de situación fiscal, CFDI, INE.
• Los casos difíciles, no solo los fáciles. Ahí se separan los modelos.

Enmascara CURP, RFC, CLABE y tarjetas antes de usarlos fuera de tu entorno.

Paso 2: escoge dos o tres candidatos por caso

Usa la tabla de arriba para quedarte con dos o tres modelos. Filtra por licencia, por si necesitas entrada de imagen y por el hardware que estás dispuesto a pagar.

Paso 3: pruébalos con el mismo agente

Corre el mismo agente, con las mismas instrucciones y herramientas, cambiando solo el modelo. En Runtime es un cambio de configuración.

Corre el agente de conciliación sobre los 80 casos del set de evaluación con DeepSeek V4 Pro, GLM-5.3 y Qwen3.8 27B. Para cada modelo, dime en cuántos casos llegó a la misma conclusión que el analista, en cuáles se equivocó y por qué, cuánto tardó y cuántos tokens usó. Hazme una tabla comparativa y dame tu recomendación.

Paso 4: revisa los errores, no solo el porcentaje

Dos modelos con el mismo porcentaje pueden fallar en casos muy distintos. Revisa con el área de negocio qué errores son tolerables (un ticket mal clasificado) y cuáles no (dar por conciliado un SPEI que no existe). Elige con base en eso.

Paso 5: llévalo a producción en tu región

Despliega el modelo elegido en tu cuenta, en Querétaro, y conecta el agente. Repite la evaluación cada vez que salga un modelo nuevo; nuestra comparativa se actualiza seguido y cambiar de modelo no implica rehacer el agente.

Lo que se queda con tu equipo

Lo que hemos aprendido

• Elige por caso de uso, no por ranking. El mejor modelo general puede ser caro e innecesario para clasificar tickets.
• Tu set de evaluación es el activo. Los modelos cambian cada mes; los casos bien resueltos te sirven para siempre.
• Mezclar está bien. Un modelo grande para investigaciones y uno chico para el volumen suele salir mejor que uno solo para todo.
• El control no depende del modelo. Autorizaciones, enmascaramiento y bitácora tienen que funcionar igual con cualquier modelo.

Lo que te va a pedir cumplimiento

• Dónde corre. Modelo, agente y datos en tu cuenta, en la región de Querétaro.
• Quién entrena con tus datos. Nadie: los pesos son tuyos y Runtime nunca entrena con tus datos.
• Qué datos ve el modelo. CURP, RFC, CLABE y tarjetas se enmascaran antes de llegar al modelo.
• Qué hizo. Cada ejecución queda en una bitácora exportable, sin importar el modelo.

Para el detalle regulatorio, revisa la guía de agentes de IA para cumplimiento.

Cómo medir resultados

Un calendario realista

Rain, emisor de tarjetas con presencia en más de 150 países, usa Runtime para soporte técnico, monitoreo de fraude y riesgo, cumplimiento, ciberseguridad, investigaciones de ingeniería, revisión de PRs, QA y reportes, y se ha ahorrado $750k en proveedores y nómina.

En resumen

Con modelos de pesos abiertos y una región en Querétaro, puedes tener agentes que trabajan con datos de tus clientes sin que salgan del país. Elige por caso de uso, evalúa con tus casos en español y deja que el control viva en la infraestructura, no en el modelo. Para ver en qué procesos usar estos agentes, empieza por la guía de operaciones de pagos.

Ahora sí, a evaluar.

Preguntas frecuentes

¿Qué modelo open source conviene para una fintech en México?

Depende del trabajo. Para conciliación e investigaciones largas, modelos con buen razonamiento y contexto largo como DeepSeek V4 Pro o GLM-5.3; para alto volumen, como soporte o triage de alertas, modelos eficientes como GLM-5.3 Flash o DeepSeek V4.1 Flash; para KYC con imágenes de INE, modelos con entrada de imagen que se pueden alojar en tu nube, como Qwen3.8 27B. Pruébalos siempre con tus propios casos en español.

¿Puedo correr modelos de IA en México para que los datos no salgan del país?

Sí. AWS, Google Cloud y Microsoft Azure tienen regiones de nube en Querétaro. Con un modelo de pesos abiertos puedes correrlo en tu propia cuenta en esa región, junto con el agente y los datos de tus clientes.

¿Qué licencia necesito revisar?

Varios modelos tienen licencias permisivas como MIT o Apache 2.0 (por ejemplo DeepSeek V4 Pro, GLM-5.3 Flash, Qwen3.8 27B y gpt-oss-120b). Otros usan licencias propias del proveedor, como GLM-5.3 o Kimi K3, que tu área legal debe revisar antes de usarlos en producción.

¿Los modelos open source entienden bien el español de México?

Muchos son multilingües, pero la única forma de saberlo es probarlos con tus casos: tickets reales con modismos y abreviaturas, comprobantes de SPEI, expedientes con INE y RFC. Arma un set de evaluación con casos ya resueltos por tu equipo y compara modelos contra esas respuestas.

¿Runtime funciona con modelos open source?

Sí. Runtime no depende de un modelo: corre agentes con Claude Code, Codex o modelos open source vía Bedrock, Vertex AI o tu propio endpoint. Puede correr en tu propia cuenta de AWS, GCP o Azure, o self-hosted, y nunca entrena con tus datos.

¿Qué es Runtime?

Runtime es el sistema operativo para agentes de IA en equipos de pagos y fintech. Cada agente corre en una computadora aislada con accesos limitados, espera autorización antes de mover dinero o contestarle a un cliente, enmascara datos sensibles antes de que lleguen al modelo y deja una bitácora exportable.