O nosso homelab e a infraestrutura de um Estado correm o mesmo software: a Áustria já pôs 180 mil funcionários públicos a usá-lo, e nós temos o AMALIA à espera de uma tomada

Olá a todos!

Prefácio do costume: corro Open WebUI em casa desde a versão 0.3, escrevi aqui sobre a 0.10.2 há várias semanas, uso modelos locais todos os dias e uso também modelos de fronteira quando a tarefa justifica. Não sou purista. Sou desconfiado, que é coisa diferente.

O Open WebUI publicou no dia 5 de Agosto um artigo com um título que eu teria escrito: “How Your AI Homelab Scales Into National Infrastructure”. Confesso que abri à espera de mais um texto de marketing com uma tabela bonita. Não é. É a coisa mais útil que li este mês sobre IA em Portugal, apesar de não falar de Portugal uma única vez.

A tese do artigo cabe numa frase: as decisões que tomam na vossa máquina, sozinhos, ao domingo à tarde, são exactamente as mesmas decisões que uma administração pública tem de tomar para meio milhão de pessoas. Onde é que o modelo corre. Quem é que lhe pode aceder. Onde é que ficam os dados. Que regras se aplicam. Muda a escala do hardware, muda o número de zeros na factura, muda a quantidade de reuniões. Não muda a pergunta.

E é aqui que eu quero pegar, porque há uma coisa que me anda a incomodar desde Julho e que este artigo me ajudou finalmente a articular.

O que o artigo diz

O texto começa por desmontar a ideia de que self-hosting é hobby de gente com demasiadas gráficas. Depois traça uma escada com cinco degraus, e a escada é a melhor parte.

No degrau de baixo está uma pessoa com uma máquina que já tem. Instala o Ollama, põe o Open WebUI à frente, corre um modelo de 7 ou 8 mil milhões de parâmetros, e para uma boa parte das pessoas a história acaba aí. Nunca precisa de ser mais.

No meio estão as organizações que não podem mandar os dados para lado nenhum. Uma empresa amarrada por contrato a proteger registos de clientes. Um hospital com processos clínicos. Uma equipa numa rede que nunca toca na internet. Uma universidade a montar um assistente partilhado para docentes e alunos. As motivações são diferentes, o objectivo é o mesmo: manter a IA, os utilizadores e os dados dentro de sistemas que controlam.

No degrau de cima está o Estado. E é aqui que o artigo faz o que raramente vejo fazer: em vez de teorizar sobre soberania digital, aponta para um caso concreto que já está a correr.

A Áustria não construiu um modelo. Construiu uma tomada.

O Bundesrechenzentrum, o centro de computação federal austríaco, está a fornecer IA generativa a cerca de 180 mil funcionários da administração federal. A coisa chama-se GovGPT, faz parte de uma iniciativa chamada Public AI, e a arquitectura é decepcionantemente simples.
Modelos de pesos abertos da Mistral, nas versões de 3, 8 e 14 mil milhões de parâmetros. A correr exclusivamente em servidores do próprio BRZ. Expostos através de uma interface normalizada, aquilo a que o CEO do BRZ chama “Large Language Model as a Service”, para que cada ministério não tenha de montar o seu próprio sistema. E o Open WebUI a servir de interface para as pessoas que efectivamente têm de escrever ali dentro. O plano anunciado é chegar aos 250 mil funcionários no sector público alargado até ao final de 2026.

Leiam a lista de componentes outra vez, porque o que interessa é o que não está lá.

Não há um modelo nacional austríaco. Não há um consórcio de universidades a treinar um LLM em alemão austríaco durante dezoito meses. Não há uma cerimónia de apresentação com o primeiro-ministro em cima de um palco. Há pesos abertos de terceiros, hardware do Estado, uma camada de serviço partilhada, e uma interface open source que qualquer um de nós corre em casa com um comando docker.
O BRZ resolveu o problema pelo fim errado da escada. E, por isso, já tem gente lá dentro a usar a coisa.

Nós fizemos o contrário. E fizemos a parte difícil.

No dia 1 de Julho, no Técnico Innovation Center, o Governo apresentou o AMALIA. Escrevi sobre isso passados poucos dias, depois de vários dias a martelar o modelo, e mantenho tudo o que disse: é um trabalho sério, é aberto a sério, e o que me assustou não foi o modelo. Inclusive conhecidos estão a usar ele para consulta publica e oferta comercial.

Recapitulando os números para quem chegou agora. Um consórcio de universidades e centros de investigação portugueses, cerca de sessenta investigadores, dezoito meses de trabalho, financiamento do PRR de 5,5 milhões de euros com um reforço de mais 1,5 milhões até 2027. Um modelo multimodal, treinado para português europeu, com o contexto jurídico e cultural nacional, disponibilizado em código aberto e descarregável a partir do ia.gov.pt. Auditável. Documentado. Adaptável por quem quiser.

E agora a frase que a própria comunicação oficial faz questão de sublinhar, e que eu acho que ninguém leu com a atenção devida: o AMALIA não é um sistema conversacional com uma interface de chat. É uma base tecnológica aberta que qualquer pessoa pode descarregar para implementar.

Ou seja. Nós temos motor. A Áustria tem carro.

Gastámos sete milhões de euros e ano e meio a fazer a parte cara, a parte difícil, a parte que exige investigação de ponta e que quase nenhum país da nossa dimensão consegue fazer. E depois parámos exactamente no ponto em que faltava a parte barata: a camada onde um funcionário do Instituto da Segurança Social abre o browser, faz login com a credencial que já tem, escolhe um modelo que alguém aprovou, e faz uma pergunta sobre um processo sem que esse processo saia da rede do Estado.

Essa camada custa uma fracção infinitesimal de sete milhões de euros. Está em código aberto. Corre num container. E é a mesma que eu tenho a correr num Mac mini em cima de uma estante.

A escada, degrau a degrau.

O artigo do Open WebUI dá regras práticas de dimensionamento, e são honestas ao ponto de contrariarem o interesse comercial de quem as escreve. Vale a pena traduzi-las para o nosso contexto.

Para experimentar, usem o que já têm. Um modelo pequeno corre em CPU com 16 GB de memória de sistema, e com 32 GB respira melhor. As respostas vão ser lentas, e tudo bem: nesta fase estão a descobrir se isto vos serve, não a montar produção. Se a coisa passar a ferramenta diária, a primeira actualização que vale a pena é uma gráfica.

Para inferência em GPU, o ponto de entrada prático são 12 GB de VRAM. Corre modelos de 7B a 14B nas quantizações habituais sem drama. Com 24 GB abrem-se modelos locais bastante mais capazes. Acima disso, já estão a comprar para uma equipa e não para vocês, e a conversa passa a ser sobre múltiplas gráficas ou servidor dedicado.

O Apple Silicon continua a ser um caminho subestimado para homelab. A memória unificada permite correr, num Mac, modelos que noutro sítio exigiriam uma gráfica séria. Não é o mais rápido, é de longe o mais silencioso e o que menos aquece a divisão em Agosto.

E a regra de ouro, que devia estar afixada em todos os departamentos de informática deste país: comprem hardware em último lugar. Decidam primeiro o tamanho do modelo, a velocidade de resposta aceitável, o número de utilizadores e a fronteira de privacidade que precisam mesmo de garantir. Depois dimensionem a máquina a isso. Fazer ao contrário é o erro mais caro e mais comum do self-hosting, e é também, curiosamente, a forma como quase todos os concursos públicos de infraestrutura são desenhados.

Para uma equipa pequena, uma máquina partilhada com uma gráfica decente chega, com o Open WebUI à frente do Ollama ou de um vLLM, mais as APIs externas que decidirem autorizar. Para uma organização regulada, servidores dedicados ou nuvem privada, modelos locais mais os endpoints externos aprovados, e os controlos deixam de ser opcionais. À escala nacional, é infraestrutura de datacenter, modelos de pesos abertos geridos centralmente, e governação a sério.

Reparem numa coisa: descer a escada é sobretudo somar hardware e ligar coisas que já lá estão. O software não muda. Isso não é detalhe, é a razão pela qual isto é possível de todo.

Os quatro controlos, por esta ordem

Quando entra a segunda pessoa, começa a governação. O artigo propõe uma ordem, e é a ordem certa, incluindo a parte de parar quando chega.

Primeiro, contas. No dia em que alguém que não sois vós faz login, liguem a aprovação administrativa de novos registos. O acesso passa a ser uma coisa que se concede, em vez de uma coisa que acontece.

Segundo, grupos e acesso por modelo. Cada equipa vê os modelos que lhe interessam, e os endpoints caros ou sensíveis deixam de estar disponíveis para toda a gente por omissão. Se ligaram uma API externa e ela aparece na lista de todos os utilizadores, têm um problema de custos e um problema de fuga de dados, pela mesma porta.

Terceiro, autenticação única. Ligam o login que a organização já usa, por OAuth ou OIDC, e as contas deixam de ser geridas à mão. Na versão 0.10 isto passou a poder configurar-se pelo painel de administração, o que é uma benção para quem já perdeu tardes a reiniciar containers por causa de um typo numa variável de ambiente.

Quarto, directório, registos e retenção. Aprovisionamento por SCIM, registos de auditoria, política de retenção e um backup que já foi restaurado pelo menos uma vez para provar que funciona. Num hospital ou num ministério, isto deixa de ser boa prática e passa a ser requisito.

E depois a parte que mais gosto: parem no degrau um se for isso que a vossa instalação precisa. Só avancem quando o controlo seguinte for mesmo necessário. Vejo demasiada gente a desenhar arquitecturas de governação para trezentos utilizadores quando tem quatro, e a nunca chegar a ter os quatro a usar nada.

O que muda mesmo quando se sobe

Aqui está o ponto do artigo que eu queria ter escrito primeiro.

Em casa, as respostas à lista de perguntas são todas a mesma pessoa. A minha máquina, a minha conta, a minha interface, as minhas regras. Numa organização, cada uma dessas respostas precisa de um nome agarrado.

Alguém é dono do acesso. Alguém é dono da disponibilidade. Alguém é dono do suporte. Alguém é dono da política de retenção. Alguém atende o telefone quando o serviço não responde às nove da manhã de uma segunda-feira e há trezentas pessoas à espera de resposta.

É por isto que os projectos de IA morrem nas organizações, e não por causa de gráficas. A tecnologia está resolvida. O que não está resolvido é quem assina por baixo. E quando ninguém assina, a alternativa que acontece sozinha é a pior de todas: cada pessoa abre uma conta pessoal no serviço que lhe apetecer e passa a colar lá dentro documentos que não devia. Neste momento, em Portugal, é isso que está a acontecer em centenas de organizações públicas e privadas. Não é uma hipótese. É o estado actual das coisas, e toda a gente que trabalha nisto sabe.

O aviso que o artigo faz e que eu sublinho a vermelho

Self-hosting não é conformidade. Não é a mesma coisa e não substitui a outra.

Correr o modelo em casa dá-vos a capacidade de responder a perguntas que de outra forma não conseguiriam responder: onde é que estes dados estão, quem lhes tocou, durante quanto tempo ficam guardados. Mas se isso satisfaz o RGPD ou o AI Act depende inteiramente de como gerem a coisa toda. O software dá-vos controlo. Não faz o julgamento jurídico por vocês.

Digo isto porque já ouvi, mais do que uma vez, alguém defender um projecto interno com a frase “é local, portanto está conforme”. Não está. Um sistema local mal gerido, sem retenção definida, sem registos, com toda a gente a partilhar a mesma conta de administrador, é provavelmente pior do que um serviço comercial com um contrato de processamento de dados assinado. A diferença é que no primeiro caso a culpa é vossa e não há para quem apontar.

A conta. Quanto é?

O self-hosting troca uma subscrição por responsabilidades. É fundamental ler a factura toda antes de assinar.

O hardware tem de ser comprado, dimensionado e mantido ligado. O software precisa de actualizações, de correcções de segurança e de backups que alguém testou de facto. E as perguntas sobre pessoas precisam de donos: quem lê os registos, quanto tempo se guarda o quê, quem apoia os utilizadores, quem toma as decisões de conformidade.

Quanto maior a instalação, mais disto se transforma no trabalho efectivo de alguém, a começar por ter um plano para uma coisa tão banal como um reboot.

Em troca, ficam com as partes que interessam sob controlo: os modelos, os dados, a interface e as regras.

Acrescento uma nota minha, porque o artigo é generoso e eu sou desconfiado. Há um custo que ninguém contabiliza nestas contas, que é o custo de aprendizagem da organização. Nos primeiros três meses, o vosso suporte vai receber perguntas que não são sobre o Open WebUI, são sobre IA: porque é que o modelo inventou aquilo, porque é que a resposta de ontem era melhor, porque é que não consegue ler este PDF. Se não tiverem alguém disponível para responder a essas perguntas com paciência, a adopção morre e a culpa vai cair na plataforma.

Quando o modelo hospedado é a escolha certa

E já agora, porque isto não é um teste de pureza e o artigo tem a honestidade de o dizer.

Os modelos de fronteira hospedados continuam a ser os mais capazes que existem hoje. Se o vosso trabalho precisa do melhor raciocínio disponível, se o uso é demasiado ocasional para justificar hardware parado, ou se os dados envolvidos não são sensíveis, então usar Claude, ChatGPT ou outro serviço é uma decisão sólida pelos seus próprios méritos.

A maioria das instalações que conheço acaba num misto: modelo local para tudo o que é confidencial, modelo hospedado para os problemas difíceis. Correr a vossa própria interface significa que essa decisão é vossa, tarefa a tarefa, em vez de ser tomada por omissão a favor de quem tiver o melhor marketing.

Escrevi aqui há duas semanas sobre a metodologia de routing que uso para isso mesmo, e o princípio é o mesmo a qualquer escala: um modelo para cada trabalho, e a escolha do modelo é uma decisão de arquitectura, não uma preferência pessoal.

Erros que vão cometer, e o meu preferido

O artigo lista os erros clássicos e todos eles me aconteceram.

Dimensionar o armazenamento para os modelos e esquecer os dados. Os ficheiros dos modelos são a parte previsível. As conversas, os uploads e os índices de pesquisa construídos a partir deles crescem sem pedir licença.
Não fazer backup até ao primeiro susto com uma migração. É um volume. Agendem uma cópia, e restaurem-na uma vez para provar que funciona.
Não decidir a retenção. Decidam cedo quanto tempo ficam guardadas as conversas e os registos. É uma decisão barata agora e fica muito mais difícil quando alguém já construiu o seu método de trabalho em cima do arquivo.

Ligar uma API hospedada e deixá-la aberta a toda a gente. Limitem o acesso por modelo no primeiro dia, não depois de virem a factura.

O meu preferido, que não está na lista deles: montar tudo isto sozinho, sem nunca dizer a ninguém, e depois ir de férias. Se a instalação existe e alguém a usa, ela é infraestrutura, mesmo que só custe electricidade. Documentem-na como tal, ou vão descobrir que a “experiência do Nuno” era afinal o sistema de que meia equipa dependia.

Onde é que isto nos deixa

Volto ao princípio, e à razão pela qual este artigo me irritou de uma forma produtiva.

Em Junho deste ano, uma empresa americana suspendeu o acesso aos seus modelos de topo por causa de controlos de exportação do Departamento do Comércio dos Estados Unidos, e restabeleceu-o no início de Julho. Isto não é uma hipótese de trabalho num slide sobre risco geopolítico. Aconteceu, este ano, a clientes pagantes, incluindo europeus, e o aviso prévio foi o que foi.

Se isso tivesse acontecido a meio de uma implantação de IA na administração pública portuguesa, assente numa API americana, teríamos tido umas semanas muito engraçadas. Teríamos descoberto, ao mesmo tempo, que os fornecedores mudam de política mais depressa do que nós mudamos de contrato, e que a nossa capacidade de resposta era escrever um email.

A Áustria não fez nada de genial. Pegou em pesos abertos que qualquer um pode descarregar, meteu-os em servidores do Estado, pôs uma interface open source à frente, e resolveu o problema aborrecido de dar acesso a 180 mil pessoas com autenticação, grupos e registos. Nada disto é investigação de ponta. É montar coisas com competência e assumir a responsabilidade da operação.

Nós temos o AMALIA, que é objectivamente mais ambicioso do que aquilo que os austríacos fizeram, e temos uma AMA com experiência de operar serviços digitais à escala nacional. O que falta não é dinheiro nem talento. Falta alguém decidir que a camada de acesso é infraestrutura pública e tratá-la como tal: um serviço partilhado, com pesos abertos a correr em hardware do Estado, com o AMALIA lá dentro ao lado de outros modelos abertos, e com uma interface que um funcionário consiga usar sem formação.

E é aqui que a escada do artigo deixa de ser uma metáfora simpática e passa a ser uma acusação. Porque a distância entre o que eu tenho em casa e o que faz falta ao Estado português não é uma distância de tecnologia. É a mesma stack. Os mesmos containers. As mesmas quatro definições ligadas por ordem. A distância é de decisão.

Menção especial: a ponte já está a ser construída e só não é o Estado a construí-la

Talvez seja prudente emendar uma coisa que deixei implícita acima. Quando digo que temos motor e não temos carro, isso é verdade do lado do Estado. Do lado de fora, já não é.

Enquanto ninguém se mexia, apareceu o iaamalia.com: um chat em português de Portugal montado por cima dos pesos abertos do AMALIA, os mesmos que qualquer pessoa descarrega do Hugging Face em Apache 2.0. Não é uma demonstração. É produto a sério: camada gratuita, plano pago e ferramentas ligadas à vida real cá do sítio. Diário da República, regras de IRS, Idealista, transportes, incentivos para empresas e cidadãos, pesquisa na web.

Quem está por trás descreve-se, na página do “sobre nós”, como bootstrappers portugueses a ligar o modelo Amália às ferramentas certas para Portugal. É a mesma equipa que já vendia software a grupos de media portugueses com o PodSqueeze. Não treinaram modelo nenhum e não tem problema nenhum em o dizer. Pegaram no motor que nós pagámos, meteram-lhe carroçaria e puseram-no online enquanto o resto do país discutia o assunto em painéis. Zero euros de PRR.

E não estão sozinhos. Ainda antes do AMALIA ser público, já havia quem tivesse montado um chat em português europeu com modelos abertos e uma camada de correcção de vocabulário – meio a sério, meio a picar o projecto oficial – e funcionava. Sinais da mesma frustração, por todo o lado.

Isto não me tira a razão. Piora o caso.

Porque se meia dúzia de pessoas, com dinheiro do próprio bolso e sem pedirem permissão a ninguém, transformam o motor em carro em poucos meses, então o argumento de que a camada de acesso do Estado é um problema difícil deixa de se aguentar de pé. Nunca foi difícil. Foi só de ninguém.

Eles próprios percebem melhor do que ninguém: um serviço comercial alojado por terceiros, por muito português e muito bem feito que seja, não resolve o problema do funcionário do Instituto da Segurança Social. Continua a ser dados a sair da rede do Estado para a conta de outra pessoa. O que estas equipas provam é viabilidade, não é soberania. E não devia ser preciso escolher entre as duas: startups a fazer produto para quem precisa de produto, e o Estado a montar a sua própria instalação para aquilo que não pode sair de casa. O que não devia acontecer é o que está a acontecer –  a única ponte entre o AMALIA e as pessoas a ser construída por quem não tem obrigação nenhuma de a construir.

Se quiserem começar hoje, começa-se assim

Para quem nunca montou nada disto, o caminho continua a ser de uma noite.

Instalam o Ollama, que fica a correr em segundo plano a partir daí, e puxam um modelo:

ollama pull qwen3:8b

Correm o Open WebUI ao lado, num único container:

docker run -d -p 3000:8080 --add-host=host.docker.internal:host-gateway -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:main

Se preferirem evitar o Docker, instala-se com pip em Python 3.11 ou superior e fica no porto 8080:

pip install open-webui
open-webui serve

Abrem o endereço local, criam a conta de administrador, que fica guardada na vossa máquina e em mais lado nenhum, e escolhem o modelo no selector. Se a lista aparecer vazia, é quase sempre uma de duas coisas: ou o Ollama não está a correr, e um ollama list no terminal responde a isso num instante, ou a ligação precisa de apontar para host.docker.internal:11434 nas definições de administração. Se puseram uma chave de API na ligação, confirmem também essa, porque uma chave trocada dá exactamente a mesma lista vazia.

A partir daí é vosso. E, quando quiserem, é a mesma coisa para dez pessoas, para uma clínica, para uma câmara municipal, para um ministério. Somam hardware, ligam os controlos pela ordem certa, e arranjam nomes para as perguntas que passam a ter de ter dono.

A independência tecnológica não se decreta em conferências nem se anuncia em apresentações com fotógrafos. Constrói-se com uma máquina, um container e a decisão de que os dados ficam cá dentro. Depois é só repetir isso muitas vezes, com mais gente a assinar por baixo.

Se estiverem a pensar montar isto numa organização e precisarem de uma segunda opinião sobre o dimensionamento ou sobre a ordem dos controlos, sabem onde me encontrar. Até trabalho para uma empresa que vos pode ajudar a fazer isso e tudo…

Até à próxima.
Nuno

Documentação:

Artigo de origem

O caso austríaco (BRZ, GovGPT, Mistral, 180 mil funcionários)

O número dos 250 mil até ao final de 2026 e a confirmação de que o Open WebUI é a interface vêm do próprio artigo do Open WebUI, que aponta para versões arquivadas do ORF e do Der Standard.

AMALIA

Nota: Este post foi feito com o auxilio de um LLM privado.