“La Ecoserie”, un caso de éxito de branded content para ECOCESTA

_{Tiempo estimado de lectura: 5 minutos}

Santander ha liberado su trabajo de IA

Hace unas semanas Banco Santander publicó parte de su trabajo de IA en abierto, con licencia Apache-2.0, en GitHub. Lo interesante, y lo explica muy bien Stefan Bergsten en su artículo Santander’s Open-Source AI Move: The Control Loop Banks and Portfolio Managers Need to Understand, no es que comparta «inteligencia bancaria», sino que libera la infraestructura para gobernar la IA: guardarraíles, harnesses de evaluación, acceso a modelos agnóstico de proveedor, datos sintéticos. La tesis que me quedo es que, en IA regulada, el modelo es un input; el proceso de control a su alrededor es el verdadero activo.

Lo más valioso del open source

Al revisar el repositorio encontré dos proyectos que, en una tarde de fin de semana de verano, han mejorado sistemas que ya teníamos en marcha. Viaja el patrón, no solo el código.

Proyecto 1 — mech-gov-framework: de regla en el prompt a garantía determinista

Uno de nuestros agentes internos es un chat con tus datos sobre BigQuery: un pipeline de dos pasos (un agente genera SQL, otro redacta la respuesta en lenguaje natural), desplegado en Cloud Run detrás de IAP.

Qué teníamos ya, más allá del prompt:

• Identidad de solo lectura. La service account del servicio tiene únicamente roles/bigquery.dataViewer + bigquery.jobUser. Aunque el modelo generara un DELETE o un DROP, BigQuery lo rechazaría: el «solo lectura» estaba garantizado a nivel de IAM, no de prompt.
• Robustez de ejecución. Una comprobación estructural que descarta SQL truncado (paréntesis desbalanceados, cláusulas colgando) y un bucle de reintento que, ante un error de BigQuery, realimenta el error al modelo para que corrija.
• Autenticación del endpoint vía IAP.

Dónde estaba el hueco real? en el aislamiento entre clientes y en el coste. La SA podía leer todo el warehouse (dataViewer a nivel de proyecto); lo único que impedía que el agente de un cliente consultara la tabla de otro era el prompt pidiéndoselo. Y no había tope de bytes facturados.

Siendo un proyecto de uso 100% interno y de acceso limitado no es un drama, pero todo es mejorable. Y cuando he visto el proyecto de mech-gov en el repo del Santander me he dicho «esto me va a ser útil».

El patrón de mech-gov: puertas deterministas que envuelven al modelo y que no puede esquivar, antes y después de generar. La idea que cristaliza: un prompt es una petición, no una garantía.

Lo he adaptado como un validador determinista en el punto de ejecución (un hook previo a lanzar la consulta). Reglas first-match-wins: una sola sentencia de solo lectura (nada de DDL/DML ni statements encadenados), tablas totalmente cualificadas y, la guinda del pastel, una allow-list estricta por cliente: cada agente solo puede tocar su propio mart. Más avisos no bloqueantes (SELECT *, división sin SAFE_DIVIDE, ausencia de filtro de fecha) y un tope duro maximum_bytes_billed. Si una consulta no pasa el filtro, el hook lanza una excepción que reutiliza el bucle de reintento que ya existía (se regenera); si vuelve a fallar, no se ejecuta nada (fail-closed).

La mejora, en una frase: convierte la única regla que no tenía respaldo determinista, el aislamiento entre clientes, en una garantía, y añade un techo de coste. Defensa en profundidad en tres capas: identidad (IAM), forma de la consulta (la puerta) y escala (el tope de bytes).

Proyecto 2 — ralph-vault-skill: documentación con procedencia y caducidad

Como buen fanboy de Karpathy trabajo con un vault de Obsidian (Markdown con wikilinks y frontmatter YAML) desde hace mucho tiempo. Como complemento uso Pinecone para búsqueda semántica sobre esas notas (el clásico «encuéntrame el documento sobre X»); y, como las embeddings responden mal a «¿cuál es el estado actual de X?», un «libro mayor de estado» bitemporal escrito a mano (YAML) que se espeja a BigQuery para que los propios agentes puedan hacer JOIN contra el estado vigente.

Este stack es excelente para el conocimiento (el porqué, las decisiones, el estado), pero tiene un punto ciego: no documenta el código en sí de forma estructurada, y la prosa sobre código caduca en silencio — Pinecone te devolverá encantado una nota obsoleta porque es la más parecida, no la más vigente.

Es un tema al que llevaba dando vueltas hace tiempo y no había encontrado una solución perfecta. He explorado opciones como Graphiti, pero no me han acabado de convencer para mi caso de uso particular. Y resulta que me encuentro con Ralph en el repo.

ralph-vault genera una deepwiki por niveles a partir del fuente, con dos cosas que me convencieron:

– Procedencia + caducidad. Cada documento estampa el commit y los globs de fuente que cubre; un check compara contra el diff desde el último sync y te dice qué secciones han quedado obsoletas (staleness por ruta, no por HEAD del repo) y qué ficheros existen que ningún documento cubre (auditoría de omisión).

– Una puerta de validación sobre la propia wiki (frontmatter, wikilinks, y un gate de «nada de código fuente copiado»: resume, no pega).

Construimos una para el código de nuestros agentes y de su capa de datos (el proyecto dbt que los alimenta), generándola con una pasada de documentación por repo. Encaja con lo que ya tenía: el vault guarda el porqué, Pinecone lo recupera, el ledger da el estado vigente, y ahora la deepwiki da el mapa estructurado del código — y, a diferencia de la prosa, sabe cuándo miente.

La diferencia técnica que me llevo: para «¿esto sigue siendo cierto sobre el código?», documentación con procedencia y detección de caducidad bate a las embeddings sobre prosa. La búsqueda vectorial te da el fragmento más similar; no el más actual.

Lo que me llevo

Curiosamente, mis dos adopciones encajan en dos etapas del control loop que describe Bergsten: el filtro/guardarraíl (la puerta que valida cada consulta) y la evaluación/gobernanza (la base de conocimiento que vigila su propia caducidad). Sin proponérmelo, he importado dos piezas del mismo bucle de control que motiva la iniciativa.

Una nota: no todo el repositorio es código de producción en este momento —hay prototipos de investigación y READMEs muy «pulidos» por IA—, pero las ideas son muy valiosas, y saber distinguir unas de otras es parte del valor. Y ese es, para mí, el verdadero titular: una consultoría de medios mejorando sus agentes internos a partir del repositorio de seguridad en IA de un banco es, exactamente, la democratización de la que habla el artículo.

Si construyes con LLMs, échale un vistazo. Y enhorabuena a Santander por publicarlo con licencia permisiva: más de esto, por favor.