Olá a todos!
Há uma coisa que eu repito por aqui até os leitores ficarem fartos: mais cedo ou mais tarde, toda a gente acaba no open source. Não por amor à camisola, não por militância de fim de tarde, mas porque é o único sítio onde se consegue abrir o capot, ler o que está lá dentro, fugir de quem nos quer presos a uma fatura mensal e construir por cima do trabalho dos outros sem pedir licença a ninguém. Dito assim soa a discurso de barricada. Por isso hoje trago provas, e de um sítio onde eu próprio não esperava ir buscá las: um banco.
Apareceu há pouco tempo no GitHub uma organização chamada SantanderAI. É mesmo o Banco Santander, com o selo de organização verificada e tudo, a controlar os domínios santander.com e gruposantander.com, morada em Espanha e a assinatura do “AI Labs” no fundo do perfil, com um simpático “feito com amor em Madrid”. O lema que lá deixaram cabe numa linha: código aberto, IA responsável, para a comunidade. Tudo com licença Apache 2.0 e um convite explícito a abrir issues e mandar pull requests. Repito, para que fique bem assente: um banco. A pôr modelos, frameworks e datasets na rua para qualquer um clonar.
Quem me lê há algum tempo já sabe porque é que isto me fez levantar a sobrancelha. Eu passo metade dos posts a dizer que a Europa anda a dormir a sesta enquanto entrega a sua infraestrutura digital a meia dúzia de fornecedores do outro lado do Atlântico. E aqui está um dos maiores bancos europeus, espanhol, regulado até à medula, a fazer exatamente o contrário do reflexo habitual da banca, que é fechar tudo a sete chaves e tratar cada linha de código como segredo de estado. Vamos lá ver o que é que isto é de facto, porque entre o anúncio bonito e a substância vai muita estrada.
O que é que está lá dentro
A organização declara uma missão que, traduzida do corporativês, é mais ou menos isto: construir e abrir ferramentas de IA à volta de modelos pequenos, engenharia de prompts e arneses, agentes, IA responsável, MLOps e machine learning sobre grafos, com foco nos serviços financeiros. Há uma frase que vale ouro e que devia estar tatuada na testa de quem trabalha com dados sensíveis: todos os projetos usam apenas dados sintéticos ou anonimizados, nenhuma informação real de clientes é publicada. Numa instituição financeira isto não é um detalhe, é a diferença entre um gesto bonito e uma multa do regulador com muitos zeros.
À data em que escrevo isto há treze repositórios, dos quais se veem dez na página principal. Vou guiar vocês pelos que me parecem ter miolo, porque alguns são obviamente peças de um puzzle maior que eles ainda não montaram em público.
O primeiro que me fez sorrir foi o llm_bridge. A descrição é uma pequena biblioteca, neutra em relação a fornecedores, com uma única interface (chamada LLMClient) e adaptadores que se encaixam por baixo para OpenAI, AWS Bedrock e Google Gemini, ou então o vosso próprio backend. Se isto vos soa familiar é porque é precisamente o sermão que eu prego aqui há meses: nunca, mas nunca, escrevam código que fale diretamente com a API de um único fornecedor de modelos. Põem uma camada de abstração no meio, e no dia em que o preço triplica ou em que ligam o disjuntor do vosso lado do mundo (já aconteceu, escrevi sobre isso), trocam o adaptador e seguem a vida. Que um banco tenha sentido essa mesma necessidade e a tenha empacotado e oferecido é, para mim, a melhor anedota do lote. A sobrevivência ensina as mesmas lições a toda a gente.
Depois há o gen-fraud-graph, que é provavelmente a jóia da coroa em termos de utilidade prática. É um gerador de grafos de fraude sintéticos para treinar e comparar modelos de deteção de fraude baseados em grafos, e a ficha técnica diz que aguenta mais de cem milhões de contas. Pensem no problema real: para treinar um bom detetor de fraude precisam de dados de fraude, e dados de fraude reais são, por definição, a coisa mais privada e regulada que um banco tem. Ninguém os pode partilhar. Resultado, toda a gente reinventa a roda à porta fechada. Um gerador sintético decente quebra esse impasse, porque permite a investigadores, a startups e a outros bancos compararem abordagens sobre o mesmo terreno sem nunca tocarem num cêntimo de um cliente verdadeiro. É exatamente o tipo de bem comum que só faz sentido em aberto.
A seguir vem o trio que me diz que estas pessoas pensaram a sério no lado chato e responsável. O mech-gov-framework, ou Governança Mecânica para Decisões de LLM, propõe regimes de governança independentes do modelo (batizados R1, R2 e R3), portões rígidos que travam o que não pode passar, um esquema de compromisso e revelação baseado em entropia e métricas de governança para sistemas onde um LLM toma decisões de alto risco. Ao lado dele está o autoguardrails, descrito como um andaime de investigação de alinhamento que faz busca sobre uma única superfície, um ficheiro policy.md, para gerar guardas para modelos de linguagem. E há o mutatis-mutandis, que é código de investigação para testar discriminação através de comparadores contrafactuais, acompanhando um artigo académico sobre o tema. Reparem na coisa: um banco a publicar, em aberto, as ferramentas que usa para testar se os seus próprios sistemas discriminam pessoas. Isto é o oposto de marketing. É expor se ao escrutínio, que é a única forma honesta de fazer IA responsável em vez de a pendurar num slide.
O resto do catálogo são peças de engenharia que claramente servem um objetivo maior. O genetic-algorithm é um motor de algoritmos genéticos em Python, sem dependências, com critérios de aptidão que se encaixam à medida, e a descrição entrega o jogo: é o núcleo de busca reutilizável para um autoinvestigador de IA. O auto-bayesian faz treino de redes bayesianas interpretáveis, guiado por configuração, sobre dados tabulares relacionais, e a palavra que interessa ali é interpretáveis, porque num banco quem decide tem de conseguir explicar porque é que disse não ao vosso crédito. O linear-adapter-trainer treina adaptadores lineares de embeddings com triplet loss para alinhar a pesquisa de um sistema de RAG com as perguntas reais que as pessoas fazem. O sota-stressed-datasets republica datasets de referência numa versão pressionada, para avaliar quão robustos são os modelos quando o terreno deixa de ser bonito. E há o ralph, que é o mais divertido e o mais humilde da lista: um ciclo configurável em Bash ou PowerShell que corre uma CLI de programação por IA com uma sessão nova a cada volta. Qualquer pessoa que tenha posto um agente a trabalhar sozinho durante a noite sabe exatamente que dor é que este pequeno script resolve.
A parte que mais me agradou: o processo
Há um pormenor que passa despercebido a quem só olha para o código e que para mim vale tanto como os repositórios todos juntos. O Santander montou um Open Source Programme Office, um OSPO, com uma política de revisão a duas velocidades para tudo o que considera abrir ao público.
A via rápida é para forks, ferramentas genéricas, tutoriais, datasets e SDKs sem lógica de negócio, revistos pelo responsável do OSPO com scans automáticos e um compromisso de resposta em menos de quatro horas. A via completa é para os modelos de IA, frameworks com propriedade intelectual e código que tocou em dados internos, e esses passam por um conselho de revisão com o responsável do OSPO, o jurídico, o CISO e um arquiteto, com um prazo de duas a quatro semanas. Isto não é glamoroso, mas é precisamente o que falta a quase toda a gente. A maioria das organizações que conheço, da PME ao grupo grande, não abre código por uma de duas razões: ou tem medo de deixar escapar um segredo, ou simplesmente não tem ninguém com mandato para dizer “isto pode sair”. Ter um processo escrito, com responsáveis e prazos, transforma “abrir código” de um ato de coragem isolada num músculo da empresa. É a diferença entre dar uma vez e dar sempre.
Agora a parte cética, porque alguém tem de a dizer
Não vou pintar isto cor de rosa, que não é o estilo da casa. Esta organização é novíssima. Os repositórios foram quase todos atualizados no mesmo dia, as estrelas contam se pelos dedos de uma mão, não há membros públicos e os seguidores andam pela dúzia. Tem todo o aspeto de um lançamento acabado de sair do forno, possivelmente empurrado por uma equipa pequena e entusiasmada lá dentro, possivelmente ainda à espera de luz verde para a segunda leva (a própria página promete mais coisas para o terceiro trimestre, receitas de MLOps, um arnês para avaliar LLMs, um conjunto de testes de RAG e um kit de anonimização).
Pode dar em nada. Já vimos gigantes abrir um repositório com pompa e circunstância e depois deixá lo a ganhar pó enquanto o community manager muda de emprego. O teste de fogo de qualquer projeto aberto não é o anúncio, é o que acontece seis meses depois: há respostas nos issues? Há pull requests de fora a serem aceites? O código continua a mexer? Por enquanto não sabemos, e quem vos disser que sabe está a adivinhar. O que posso dizer com certeza é que a licença é mesmo Apache 2.0, o código está mesmo lá para clonar, e a política de dados sintéticos está escrita preto no branco. Há substância suficiente para valer a pena vigiar, e é isso que vos peço que façam comigo.
E porque é que isto encaixa no que ando a dizer
Volto ao princípio. Eu costumo queixar me de que a Europa entrega a soberania digital de bandeja. Pois aqui está o contra exemplo de que ando à procura, e não veio de uma startup de garagem nem de um instituto subsidiado, veio de um banco comercial, espanhol, que opera em meio mundo. A lógica deles, quando se lê com atenção, é a minha lógica: num setor regulado, a auditabilidade deixou de ser um luxo de quem gosta de ler código e passou a ser requisito. Quando um modelo recusa um crédito ou marca uma transação como fraude, alguém vai ter de explicar porquê, e “o fornecedor não nos deixa ver” não é resposta que aguente uma sala de tribunal nem um inspetor do regulador. A neutralidade em relação a fornecedores, que eu prego aqui como quem reza o terço, é a mesma que levou o banco a escrever o llm_bridge. As mesmas pressões produzem as mesmas escolhas, esteja eu a montar um servidor em casa ou esteja um banco a proteger se de ficar refém de uma API.
Se quiserem meter a mão na massa, e vocês sabem que eu gosto que metam, a porta de entrada óbvia é o llm_bridge. Clonam, instalam num ambiente Python isolado e apontam o ao modelo que tiverem à mão, seja uma API na nuvem ou um modelo local servido por Ollama. A graça está precisamente em trocar o backend sem mexer no resto do código. A seguir, se trabalham com dados tabulares e querem decisões que se conseguem explicar a um auditor, o auto-bayesian merece uma tarde. E se andam a montar um sistema de RAG que teima em devolver lixo, o linear-adapter-trainer ataca exatamente o problema de alinhar a pesquisa com as perguntas reais. Não preciso de vos dar os comandos todos mastigados, está tudo no README de cada repositório, e meia hora a explorar ensina mais do que mil parágrafos meus.
Em resumo
Um dos maiores bancos da Europa olhou para o problema de fazer IA a sério, de forma auditável, sem ficar preso a um único fornecedor e sem expor dados de clientes, e a estrada levou o exatamente ao mesmo sítio onde ela vos vai levar a vocês e onde já me levou a mim há muito tempo: o código aberto. Não porque seja fácil, não porque seja de borla (não é, custa tempo de gente cara), mas porque é o único caminho que dá controlo, transparência e a possibilidade de corrigir o que está mal antes que rebente.
Se isto for a sério, e tomara que seja, é um sinal saudável de que a Europa começa a perceber que dar à comunidade não é caridade, é estratégia. Se não for, fica o exemplo do processo, que qualquer empresa pode copiar amanhã de manhã. De qualquer forma, fico contente por uma vez não ter sido eu a gritar sozinho para o vento.
Vou ficar de olho nestes repositórios e, daqui a uns meses, se houver carne nova no assador, conto vos o que aconteceu. Entretanto, deem uma volta por lá, mandem um pull request se virem algo a melhorar, e digam me se acham que isto é o princípio de uma coisa boa ou só mais fumo bonito.
Até à próxima semana, e já sabem, se encontrarem algo estranho ou incorreto sabem onde me encontrar.
Abraço
Nuno