Cómo escoger y correr modelos open source para operaciones fintech en español

En una fintech colombiana, la pregunta de cumplimiento casi nunca es qué modelo es más inteligente, sino por dónde pasan los datos de los clientes. Cédulas, extractos, llaves de Bre-B y conversaciones de soporte no deberían terminar en un proveedor que nadie revisó. Los modelos open source de hoy ya son lo bastante buenos para buena parte del trabajo operativo, y se pueden correr en su propia nube. Lo difícil no es descargarlos, sino escoger el adecuado para cada trabajo y comprobar que funciona en el español de sus clientes.

Esta es una guía práctica para CTO y líderes de ingeniería en fintech colombianas: qué modelo usar para cada caso, cómo evaluarlos con sus propios casos y cómo correrlos sin perder el control de los datos.

Qué hace. Le da una lista corta de modelos por caso de uso, un método para evaluarlos en español y la forma de ponerlos a trabajar como agentes con controles.

Qué no es. Una tabla de benchmarks ni una recomendación de un solo modelo para todo. Los modelos cambian cada mes; el método para escogerlos es lo que perdura.

Por qué open source en una fintech colombiana

No es todo o nada. Muchos equipos usan un modelo comercial para el trabajo más complejo y modelos open source para lo de alto volumen o lo que toca datos más sensibles.

Modelos sugeridos por caso de uso

Las sugerencias salen de nuestra comparativa de modelos open source, que se actualiza cada mes.

Revise la licencia de cada modelo en su ficha. DeepSeek V4 Pro, GLM-5.3 Flash y DeepSeek V4.1 Flash usan MIT; Qwen3.8 27B y gpt-oss-120b, Apache 2.0. GLM-5.3, Kimi K3, MiniMax M3 y Qwen3.8 2.4T-A95B tienen licencias propias que su área jurídica debe leer.

Evalúe con sus casos, en su español

Un modelo que se ve bien en inglés puede fallar con "le transferí a la llave que no era" o con un NIT mal escrito en un certificado. La evaluación tiene que salir de su operación:

1. Reúna entre 50 y 100 casos resueltos de un solo proceso, con la respuesta que dio su equipo. Incluya los casos raros.
2. Use el español de sus clientes. Mensajes de WhatsApp reales (anonimizados), con sus abreviaturas y errores, extractos de su banco y documentos escaneados.
3. Defina qué es una buena respuesta. Conclusión correcta, evidencia citada, nada inventado y el tono adecuado.
4. Corra dos o tres modelos sobre los mismos casos, en las mismas condiciones.
5. Revise los errores con su equipo de operaciones. Ellos saben cuál error es grave y cuál no.

Repita la evaluación cuando salga un modelo nuevo; con el set armado, es cuestión de horas.

Dónde corren y qué dice la Ley 1581

Correr el modelo en su cuenta de nube resuelve la pregunta del proveedor de modelos, pero no la de la ubicación. Si su región de nube está fuera de Colombia, los datos personales viajan a otro país, y el artículo 26 de la Ley 1581 de 2012 prohíbe transferirlos a países sin un nivel adecuado de protección. La transferencia procede si el país cumple los estándares de la SIC, si aplica una de las excepciones de la ley o si la SIC emite una declaración de conformidad. Además, la Circular Externa 002 de 2024 de la SIC dio lineamientos para el tratamiento de datos personales en sistemas de IA.

En la práctica:

• Escoja la región con su área jurídica y documente por qué.
• Enmascare lo que el modelo no necesita. Cédulas, cuentas y tarjetas pueden enmascararse antes de llegar al modelo.
• Limite a dónde puede conectarse el agente. Así sabe exactamente qué sistemas toca.

Cómo los corre Runtime

Runtime es el sistema operativo para agentes de IA. Es neutral frente al modelo: sus agentes pueden usar Claude Code, Codex o modelos open source a través de Bedrock, Vertex AI o su propio endpoint, y puede cambiar de modelo por agente sin rehacer el trabajo.

Un ingeniero de IA de Runtime lo acompaña a montar el primer agente, incluida la conexión con el modelo que escoja.

Paso a paso

1. Escoja un proceso. Uno con volumen y datos sensibles, por ejemplo soporte de pagos o vinculación.
2. Arme el set de evaluación con casos reales en español.
3. Pruebe dos o tres modelos de la tabla en su nube.
4. Ponga el agente en paralelo con su equipo una semana antes de darle el proceso.
5. Revise cada mes si un modelo nuevo le conviene más.

Corra el set de evaluación de soporte con GLM-5.3 Flash y DeepSeek V4.1 Flash. Para cada caso, dígame si la respuesta coincide con la de nuestro equipo, si inventó algún dato y cuánto tardó. Déjeme un resumen con los casos donde los dos modelos fallaron.

Lo que hemos aprendido

• El mejor modelo depende del trabajo. Un modelo grande para investigar y uno pequeño para clasificar suele salir mejor que uno solo para todo.
• La evaluación vale más que el benchmark. Cien casos suyos le dicen más que cualquier tabla pública.
• Diseñe para cambiar de modelo. Lo que hoy es el mejor puede no serlo en tres meses.
• El control de datos es arquitectura, no promesa. Región, enmascaramiento y registros se configuran desde el principio.

Para ver cómo se aplica esto en procesos concretos, revise las guías de operaciones de pagos, soporte y cumplimiento.

Un cronograma 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

Los modelos open source ya sirven para buena parte del trabajo operativo de una fintech, y correrlos en su nube le da el control de datos que le van a pedir. Escoja por caso de uso, evalúe con sus propios casos en español y deje la puerta abierta para cambiar de modelo.

Manos a la obra.

Preguntas frecuentes

¿Qué modelo open source sirve para una fintech en Colombia?

Depende del trabajo. Para conciliación e investigaciones de cumplimiento conviene un modelo de razonamiento como DeepSeek V4 Pro; para soporte y triage de alto volumen, uno rápido y barato como GLM-5.3 Flash o DeepSeek V4.1 Flash; para revisar documentos de vinculación, uno con entrada de imágenes como Qwen3.8 27B. Pruebe dos o tres con sus propios casos en español antes de decidir.

¿Puedo usar modelos open source con datos de clientes colombianos?

Sí. Al correr el modelo en su propia cuenta de nube, los datos de sus clientes no pasan por un proveedor de modelos externo. Si la región de nube está fuera de Colombia, el artículo 26 de la Ley 1581 de 2012 exige que el país de destino tenga un nivel adecuado de protección según la SIC, que aplique una de las excepciones de la ley o que se obtenga una declaración de conformidad.

¿Los modelos open source funcionan bien en español?

Los modelos grandes actuales manejan bien el español, pero la calidad varía con el vocabulario de su negocio: llaves de Bre-B, NIT, extractos, PQRS o reversiones. La única forma de saberlo es evaluar con casos reales resueltos por su equipo, en el español que usan sus clientes.

¿Qué licencia debo buscar en un modelo open source?

Las licencias permisivas como MIT o Apache 2.0 suelen pasar más fácil la revisión jurídica. Modelos como DeepSeek V4 Pro, GLM-5.3 Flash y DeepSeek V4.1 Flash tienen licencia MIT, y Qwen3.8 27B y gpt-oss-120b tienen Apache 2.0. Otros tienen licencias propias que su área jurídica debe revisar.

¿Cómo corre Runtime modelos open source?

Runtime es neutral frente al modelo: puede usar Claude Code, Codex o modelos open source a través de Bedrock, Vertex AI o su propio endpoint. Puede correr en su propia cuenta de AWS, GCP o Azure, o self-hosted, y cada agente trabaja en un computador aislado con datos sensibles enmascarados.

¿Qué es Runtime?

Runtime es el sistema operativo para agentes de IA en equipos de pagos y fintech. Corre cada agente en un computador aislado, con accesos limitados, aprobaciones antes de mover plata o responderle a un cliente, enmascaramiento de datos sensibles y un registro exportable de cada ejecución. Nunca entrena con sus datos.