Modelos open source para KYC y KYB en Latinoamérica: cuál usar y cómo correrlo en tu nube
Qué modelo open source usar para KYC y KYB en una fintech de México, Colombia o Chile, cómo correrlo en tu propia nube y cómo evaluarlo con tus expedientes.
Para KYC y KYB en una fintech de Latinoamérica, empieza con Qwen3.8 27B, GLM-5.3 Flash o DeepSeek V4.1 Flash. Los tres leen imágenes de identificaciones y documentos, tienen licencia Apache 2.0 o MIT y se pueden alojar en tu propia nube, así que los datos de tus clientes no salen de tu entorno. Deja Kimi K3.1 Pro para los expedientes de KYB más complejos, después de que tu área legal revise su licencia.
El onboarding es el proceso con más datos personales de una fintech: INE o cédula, comprobantes de domicilio, actas constitutivas, poderes y la lista de beneficiarios finales. Por eso la pregunta no es solo qué modelo es mejor, sino dónde corre y quién ve los documentos.
Esta es una guía para CTOs y líderes de cumplimiento en fintechs de México, Colombia y Chile: qué modelo usar para revisar expedientes, dónde correrlo y cómo elegirlo con tus propios casos.
Qué hace. Te da una lista corta de modelos para KYC y KYB, sacada de nuestra comparativa de modelos open source, y un método para elegir con tus expedientes.
Qué no es. Un reemplazo de tu proveedor de KYC. La verificación de identidad, la prueba de vida y las listas siguen con tu proveedor; si estás eligiendo uno, revisa los mejores proveedores de KYC y KYB en Latinoamérica.
Qué hace el modelo en un expediente
| Tarea | Qué necesita del modelo |
|---|---|
| Leer documentos | Entrada de imagen para identificaciones, comprobantes y actas escaneadas |
| Comparar datos | Que el nombre, la dirección y el número fiscal coincidan entre documentos |
| Armar la estructura societaria | Contexto largo para leer actas y poderes completos |
| Detectar inconsistencias | Razonamiento cuidadoso y respuestas que citan el documento |
| Preparar el caso | Redacción clara para que el analista decida rápido |
Los modelos, en corto
| Modelo | Licencia | Entrada | Por qué para KYC y KYB |
|---|---|---|---|
| Qwen3.8 27B | Apache 2.0 | Texto, imagen y video | Compacto, 27B parámetros: fácil de alojar junto a tus datos |
| GLM-5.3 Flash | MIT | Texto e imagen | 18B parámetros activos y contexto de 1M; bajo costo para mucho volumen |
| DeepSeek V4.1 Flash | MIT | Texto e imagen | 8B parámetros activos: rápido cuando necesitas throughput |
| Kimi K3.1 Pro | Licencia propia de Moonshot AI | Texto e imagen | El más capaz de nuestra lista, para KYB con muchos documentos |
Si necesitas avanzar rápido, empieza con los de Apache 2.0 o MIT. Las licencias propias no son necesariamente un problema, pero tu área legal las tiene que leer antes de producción.
Dónde correrlo
Las grandes nubes tienen regiones en Querétaro y en Santiago, pero no todas en cada país: revisa qué proveedor tiene región donde la necesitas y usa la que tu banco socio y tu área de cumplimiento acepten. Tienes dos caminos:
- Un servicio administrado como Bedrock o Vertex AI, si el modelo está disponible en la región que necesitas. Revisa la disponibilidad antes de decidir.
- Tu propio endpoint con GPUs en tu cuenta, con vLLM o SGLang. Más trabajo, control total.
En los dos casos, el agente, el modelo y los expedientes se quedan en tu nube.
Paso 1: arma tu set de evaluación
Este paso lo hace tu equipo de cumplimiento. Junta expedientes ya resueltos, con la decisión correcta y el motivo:
- Documentos locales: INE, RFC y constancias en México; cédula y RUT en Colombia; cédula y RUT en Chile.
- Expedientes de empresa con actas, poderes y varios niveles de accionistas.
- Los casos difíciles: fotos borrosas, nombres con acentos escritos de dos formas, direcciones que no coinciden.
Enmascara los números de identificación antes de usar los casos fuera de tu entorno.
Paso 2: pruébalos con el mismo agente
Corre el mismo agente, con las mismas instrucciones, cambiando solo el modelo. En Runtime es un cambio de configuración.
Revisa los 60 expedientes del set de evaluación con Qwen3.8 27B, GLM-5.3 Flash y DeepSeek V4.1 Flash. Para cada modelo, dime en cuántos llegó a la misma decisión que el analista, qué inconsistencias encontró o se le pasaron y cuánto costó cada expediente. Hazme una tabla y dame tu recomendación.
Dos hábitos ayudan a que el agente trabaje bien:
- Di por qué, no solo qué. "Compara el domicilio del comprobante con el del acta, porque un domicilio distinto es la señal más común de una empresa fachada."
- Nombra el error que quieres evitar. "No des por buena una identificación si la foto está cortada; márcala para revisión."
Paso 3: revisa los errores, no solo el porcentaje
Dos modelos con el mismo porcentaje pueden fallar en casos muy distintos. Aprobar un expediente con un beneficiario final oculto es grave; pedir un documento de más no lo es. Elige con tu equipo de cumplimiento con base en eso.
Paso 4: llévalo a producción
Despliega el modelo elegido en tu cuenta y conecta el agente a tu proveedor de KYC y a tu sistema de casos. Repite la evaluación cada vez que salga un modelo nuevo; cambiar de modelo no implica rehacer el agente. Para ver el flujo completo con Claude, revisa cómo usar Claude para KYC y KYB.
Lo que sigue siendo humano
| Qué | Por qué |
|---|---|
| Aprobar o rechazar al cliente | Es una decisión regulatoria y de riesgo |
| Armar el set de evaluación | Solo tu equipo sabe cuál es la decisión correcta |
| Decidir qué errores son tolerables | Es una decisión de cumplimiento |
| Aprobar la licencia del modelo | Es una decisión legal |
| Elegir región y arquitectura | Es tu postura de seguridad y costo |
Lo que te va a pedir cumplimiento
- Dónde corre. Modelo, agente y expedientes en tu cuenta, en la región que elijas.
- Quién entrena con tus datos. Nadie: los pesos son tuyos y Runtime nunca entrena con tus datos.
- Qué datos ve el modelo. Los números de identificación se enmascaran cuando el paso no los necesita.
- Qué hizo. Cada revisión queda en una bitácora exportable, sin importar el modelo.
En resumen
Para KYC y KYB, el mejor modelo es el que lee bien tus documentos y corre donde tus datos pueden estar. Empieza con un modelo compacto de licencia permisiva, evalúa con tus expedientes y deja que la decisión final siga con tu equipo.
Ahora sí, a evaluar.
Preguntas frecuentes
¿Qué modelo open source conviene para KYC y KYB?
Para la mayoría de las fintechs en Latinoamérica, Qwen3.8 27B, GLM-5.3 Flash o DeepSeek V4.1 Flash. Los tres leen imágenes, tienen licencia permisiva (Apache 2.0 o MIT) y se pueden alojar en tu propia nube, así que las identificaciones y los documentos de tus clientes no salen de tu entorno. Para los expedientes de KYB más difíciles, Kimi K3.1 Pro es el más capaz, pero su licencia es propia y tu área legal la tiene que revisar.
¿Por qué usar un modelo open source para KYC en lugar de una API comercial?
Porque KYC y KYB son puro dato personal: identificaciones, comprobantes de domicilio, actas constitutivas y accionistas. Con un modelo de pesos abiertos lo corres en tu cuenta, en la región que elijas, y nadie fuera de tu empresa ve esos datos ni entrena con ellos.
¿Un modelo open source reemplaza a mi proveedor de KYC?
No. Tu proveedor de KYC sigue haciendo la verificación de identidad, la prueba de vida y las consultas a listas. El modelo trabaja encima: arma el expediente, compara documentos, detecta inconsistencias y prepara el caso para que un analista decida.
¿Cómo sé si un modelo lee bien documentos de México, Colombia o Chile?
Probándolo con tus expedientes ya resueltos. Junta casos reales con la decisión correcta, incluidos los difíciles, y compara dos o tres modelos con el mismo agente. Los benchmarks sirven para filtrar; la decisión sale de tus casos.
¿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.
