O registo de modelos é o novo placard público.

Um registo de modelos pode informar o público sobre o que é um sistema, quem o apoia, onde pode ser utilizado e o que mudou. Não pode transformar uma...

O registo de modelos é o novo placard público.

The page that starts by admitting it is not magic

The first thing a useful model registry does is disappoint you. It does not say that a model is safe. It does not say that an organisation is competent. It does not turn a supplier's promise into a fact, or a green label into a reason to stop asking questions. It gives you a bounded record instead: this is the thing, this is the version, this is the owner, this is the declared purpose, this is the status, and this is where the supporting evidence is kept.

That modesty is the beginning of public trust. A registry is a noticeboard, not a shrine. A noticeboard tells a neighbourhood what is being built, who is responsible for it and which notices have been replaced. It does not certify the workmanship of every building on the street. It gives people a place to start looking, and a way to notice when the notice itself has gone stale.

Open the Dutch government's Algorithm Register and the design is unusually plain. Government organisations publish information about algorithms they use in their work. The register focuses on impactful algorithms, including high-risk AI systems, and gives visitors an explanation of how those systems work. The page also makes a useful distinction that many glossy AI catalogues avoid: an algorithm is a set of rules and instructions a computer follows to calculate an answer, not a personality with a product launch.

The page is public because the work is public. A citizen does not need a private account to discover that an authority uses an algorithm, what the authority says it is for, or where to ask the next question. That does not make every technical detail public. It does make the existence of the system, its declared role and its institutional owner harder to hide behind a procurement file.

Model registries are becoming the same kind of civic object. They sit between a technical catalogue and a public record. Engineers need a stable identity and a version to integrate. Operators need a status and an owner to run. Downstream providers need capabilities, limits and conditions. Auditors need a trail back to evidence. Affected people need to know that a system exists and how to challenge what it does. One page cannot answer all of those questions, but a well-designed registry can point each reader to the right layer.

The danger is that the word registry makes a document sound more complete than it is. A phone book is a registry, but it cannot tell you whether a number still works. A shipping manifest is a registry, but it cannot tell you whether the cargo survived the voyage. A model record is a registry, but it cannot carry the entire proof of performance, fairness, security, legality and social consequence. The useful question is not whether a model is in the registry. It is what the entry establishes, what it leaves open and what a reader can inspect next.

A noticeboard is a promise of selection

An inventory tries to count everything. A catalogue tries to help you choose. A register makes a more formal promise: these entries belong to a defined scope, they have an owner, and the information is maintained under a rule. The promise is about selection before it is about software. Without a stated scope, an attractive list is only a collection of things that happened to be remembered.

That is why every registry needs a sentence that says what it includes and what it deliberately leaves out. The EU AI Act's central database is not a list of every model circulating in Europe. Article 71 establishes an EU database for specified high-risk AI systems and the systems that are registered under the routes described in Article 49. The Dutch Algorithm Register is not a list of every calculation made in a government office. It focuses on impactful algorithms, including high-risk AI systems. The boundary is part of the record, not a footnote for lawyers.

Um registo de modelos deve responder à mesma questão de fronteira em linguagem corrente. Lista modelos de base, sistemas de IA implantados, experiências internas, descendentes afinados, pacotes de avaliação ou apenas modelos disponibilizados a utilizadores externos? Uma nova configuração de serviço recebe uma nova entrada, uma nova versão ou um registo de implantação associado? Um estado capturado de um sistema adaptativo conta como a mesma identidade de modelo? Se o registo não decidir estas questões, cada leitor decidirá de forma diferente. É assim que uma lista curta se transforma numa longa discussão.

A seleção também dá significado à ausência. Se o âmbito disser que todos os sistemas de alto risco acessíveis ao público devem constar, uma entrada em falta é um problema de governação. Se o âmbito disser que apenas os modelos colocados no mercado são incluídos, uma experiência interna pode estar ausente por conceção. O público não consegue interpretar um resultado de pesquisa vazio sem saber qual das duas situações se aplica. O silêncio não é neutro quando o registo não explicou o seu vocabulário.

Há uma pequena virtude administrativa em dizer isto com clareza. Os registos não precisam de fingir que sabem tudo. Precisam de dizer ao leitor o que sabem, pelo que são responsáveis e o que fica fora do enquadramento. Um registo ganha autoridade ao tornar explícita a fronteira do seu âmbito, não ao decorar a capa. A tecnologia é mais recente. O instinto burocrático não é.

O que a regra europeia coloca realmente em cima da mesa

O Regulamento IA dá à palavra registo uma forma jurídica concreta, mas não uma forma única e universal. O artigo 49.º exige que um fornecedor ou representante autorizado registe determinados sistemas de IA de alto risco antes de os colocar no mercado ou de os pôr em serviço. Exige também o registo quando um fornecedor concluiu que um sistema não é de alto risco nas condições do artigo 6.º, n.º 3. As autoridades públicas e organismos públicos equivalentes que implantam determinados sistemas de alto risco têm o seu próprio dever de registo, incluindo o registo da sua utilização.

O mesmo artigo torna explícita a fronteira público-privado. Determinados sistemas de alto risco utilizados na aplicação da lei, migração, asilo e gestão do controlo de fronteiras são registados numa secção segura não pública. Os sistemas de alto risco referidos no segundo ponto do anexo III são registados a nível nacional. Estes não são pormenores de implementação que possam ser resolvidos num painel de controlo. Descrevem públicos diferentes, riscos diferentes e permissões diferentes para consultar o registo.

O artigo 71.º estabelece que a Comissão, em cooperação com os Estados-Membros, cria e mantém a base de dados da UE. As informações registadas ao abrigo do artigo 49.º devem ser acessíveis e publicamente disponíveis de forma fácil de utilizar, devendo ser facilmente navegáveis e legíveis por máquina, com exceções para secções restritas. A base de dados deve conter dados pessoais apenas na medida do necessário. Esta é uma definição útil de transparência pública: um registo que as pessoas possam encontrar e processar, sem transformar o registo num segundo problema de dados pessoais.

O anexo VIII é onde o quadro de avisos se torna específico. Para um fornecedor que regista um sistema de alto risco, o registo inclui a identidade e os dados de contacto do fornecedor, um nome comercial ou referência inequívoca, a finalidade prevista, uma descrição básica das informações utilizadas e da lógica de funcionamento, o estado do sistema, os certificados relevantes, os Estados-Membros onde é colocado no mercado ou posto em serviço, a declaração de conformidade, as instruções de utilização e um URL opcional para informações adicionais. Estes não são campos de marketing. São elementos de identificação e responsabilização.

Para um implantador público, a informação é diferente. O registo inclui a identidade do implantador, a pessoa que submete a informação, o URL da entrada do fornecedor e resumos de uma avaliação de impacto sobre direitos fundamentais e, quando aplicável, de uma avaliação de impacto sobre a proteção de dados. A distinção é importante porque um fornecedor de modelos e uma autoridade pública não sabem as mesmas coisas e não têm a mesma responsabilidade. Um registo que os funde num único cartão de fornecedor apaga o lugar onde um sistema encontra uma instituição.

A base de dados jurídica tem, por isso, um caráter em camadas. Regista uma identidade de sistema. Regista um fornecedor. Pode registar um implantador e uma utilização. Regista o estado e as declarações de apoio. Não substitui a documentação técnica, a gestão de riscos, o sistema de qualidade ou a monitorização pós-comercialização que o Regulamento exige noutros pontos. A base de dados é um índice público de factos pelos quais se responde. Não é todo o processo de conformidade.

Esta distinção perde-se facilmente porque as pessoas gostam de um único URL que pareça conter a resposta. A lei é menos sentimental. Cria uma superfície pública, superfícies restritas e vias de documentação controladas. A superfície pública tem de ser utilizável. A superfície restrita tem de permanecer restrita. A documentação tem de continuar disponível para a autoridade competente ou para o fornecedor a jusante que dela necessite. Um registo sério é uma interface entre essas obrigações, não um atalho para as contornar.

Um registo torna-se útil quando identidade, estado e alteração estão ligados. Uma cor sem transição é apenas decoração.

Existe outro limite importante. As disposições do Regulamento IA sobre modelos de IA de uso geral não são o mesmo que um catálogo público de todos os modelos de uso geral. O artigo 53.º exige que os fornecedores mantenham documentação técnica, disponibilizem informação aos fornecedores a jusante de sistemas de IA, mantenham uma política de direitos de autor e publiquem um resumo suficientemente detalhado do conteúdo utilizado no treino. As orientações da Comissão explicam que a documentação técnica se destina ao Gabinete de IA e às autoridades nacionais competentes, mediante pedido, enquanto a documentação a jusante ajuda os integradores a compreender capacidades e limitações. Apenas parte desse material pertence a um quadro de avisos público.

O Regulamento exige também que a Comissão publique e mantenha uma lista de modelos de IA de uso geral com risco sistémico. Uma lista de modelos com risco sistémico é um sinal público valioso, mas não é o mesmo objeto que um registo completo de modelos. Tem um propósito mais restrito e tem de respeitar os direitos de propriedade intelectual, as informações comerciais confidenciais e os segredos comerciais. Chamar registo a todas as listas só é inofensivo até alguém assumir que uma lista prova mais do que aquilo que prova.

Um modelo não é uma única linha

As pessoas falam de um modelo como se fosse um frasco numa prateleira. O nome está impresso no rótulo, a versão está carimbada por baixo e o conteúdo permanece inalterado até alguém abrir a tampa. Essa imagem funciona para um artefacto estático. Torna-se pouco fiável quando um modelo é adaptado, afinado, envolvido em ferramentas, disponibilizado através de várias vias ou alterado durante a utilização.

Um registo precisa de pelo menos duas identidades: a identidade do modelo e a identidade daquilo que realmente foi executado. A primeira responde a qual modelo o fornecedor se refere. A segunda pode identificar um estado capturado, um pacote de implantação selado, uma exportação local ou um pacote de reprodução. Ligá-las evita dois erros opostos. Um serviço pode deixar de fingir que cada estado ativo tem um único hash permanente, e um operador pode deixar de fingir que um resumo do pacote descreve sozinho toda a família de modelos.

Version numbers are useful only when their change rule is visible. A version may mean a new set of learned parameters, a new constraint catalogue, a change in retrieval, a changed safety layer or a material change in the serving contract. If a provider uses one number for all of those, the number becomes a polite way of saying that something changed. A registry should link a successor to its predecessor and say which part of the contract moved.

Adaptive behaviour adds another wrinkle. If a system can change while in use, the record should say so. That is not an admission that the system is uncontrolled. It is an admission that the word version cannot do all the work. The registry can keep a stable model identity, attach time-bound captured states to it and record the conditions under which a state was made. The point is not to freeze a living system into a false photograph. It is to give every meaningful photograph a date and a frame.

Identity also has a social edge. A model name is not enough when several legal entities distribute similar artefacts, when a downstream provider changes the model, or when a product embeds a model behind its own name. The registry should make the chain visible: provider, distributor where different, deployer where relevant, and the system or route in which the model is used. A person affected by a decision should not have to perform forensic archaeology on a product logo to discover who can answer for it.

Status is a verb, not a colour

Status fields are often rendered as badges because badges fit neatly on cards. The badge is not the status. The status is a statement about an action and a time. Internal testing means one thing when access is controlled by the provider. Pre-release means something else when invited outsiders can use a route under defined conditions. On the market, in service, suspended, withdrawn and recalled each carry a different operational consequence.

A useful record states what the status permits and what it does not. If a system is internal-only, a reader should not infer public availability from a documentation page. If an external beta is planned, the date should be labelled as planned rather than presented as a release. If a system is withdrawn, the record should preserve the previous identity and say whether existing deployments may continue, must stop or are being migrated. A status without an effective date is a rumour wearing a uniform.

The status should also be owned. Who can move an entry from internal to external? Who can suspend a route? Who can declare a release date changed? Which evidence is required before the transition? Those questions belong in the operating process, but the public entry should make the resulting decision legible. A registry that shows the current badge while hiding the authority behind it is only a mood board for governance.

Illustrative example, not a real listing: a record might say that a model is in controlled evaluation, that no external route is open, that an invite-only trial is proposed for a later date, and that the proposal remains subject to a release gate. The example names no organisation, model or event. Its purpose is to show how a record keeps a plan separate from a fact. The same discipline applies to a withdrawal, a capability claim or a certification that has not yet been issued.

This separation protects readers from a familiar trick. A future intention is repeated often enough that it starts to sound like history. Registries should be the place where that trick stops working. The entry can show a plan, but the plan must keep its label. Europe has enough calendars already. A date is not a fact merely because it has been placed in a coloured rectangle.

The registry is not the evidence room

Uma entrada pública deve ser suficientemente curta para ser lida e suficientemente sólida para orientar uma pergunta séria. A sala de provas que lhe está subjacente pode ser muito maior. As obrigações de documentação do artigo 53.º do Regulamento IA ilustram porquê. Os fornecedores de modelos de IA de finalidade geral devem elaborar e manter documentação técnica que cubra o desenvolvimento, a formação, os testes e a avaliação. Devem disponibilizar informações e documentação aos fornecedores a jusante de sistemas de IA para que estes possam compreender as capacidades e as limitações. Devem publicar um resumo suficientemente detalhado do conteúdo utilizado na formação e manter uma política em matéria de direito de autor da União.

Estas obrigações servem diferentes leitores. Uma autoridade competente pode precisar do registo técnico completo. Um fornecedor a jusante precisa de informações de integração e de limitações. O público precisa de um relato claro do que é o modelo e de como o resumo do conteúdo da formação é delimitado. Uma entrada no registo pode ligar estas superfícies sem fingir que uma página pública deve conter todos os detalhes sensíveis em matéria de segurança, todos os ficheiros de pesos ou todas as amostras de teste que contenham dados pessoais.

As ligações também não são provas por magia. Um registo que aponte para um relatório de avaliação deve identificar qual a versão abrangida pelo relatório, o que a avaliação mediu e quais as condições que limitam o resultado. Uma ligação para um resumo da formação deve indicar se o resumo abrange a pré-formação, o ajuste fino ou um conjunto definido de categorias de conteúdo. Uma ligação para um certificado deve mostrar quem o emitiu, o que certifica e quando expira. Caso contrário, a página é uma prateleira de envelopes por abrir.

A mesma regra aplica-se às alegações de segurança. Um registo pode indicar que existe uma avaliação de riscos, que um plano de monitorização está ligado ou que um canal para incidentes graves está publicado. Não deve dar a entender que a existência de um documento prova que o sistema subjacente é seguro. A documentação é uma forma de inspecionar uma alegação. Não é um substituto da alegação.

É aqui que a escrita pública exige disciplina. Uma ficha de modelo, uma página de transparência ou uma entrada de registo podem descrever a utilização prevista e as limitações conhecidas. Não podem usar a expressão fiável como conclusão, a menos que as provas e o âmbito tornem essa conclusão defensável. A frase honesta é muitas vezes mais útil: estas são as condições que avaliámos, estes são os limites que observámos e estes são os casos que não afirmámos abranger.

O registo neerlandês mostra o valor de uma lista pública comum

O Registo de Algoritmos neerlandês é instrutivo precisamente porque não tenta parecer uma sala de controlo futurista. Dá às organizações governamentais um lugar público para descrever os algoritmos utilizados no seu trabalho. A sua página em inglês avisa que as descrições foram traduzidas automaticamente e que o original neerlandês é a versão que faz fé para a descrição. Essa pequena nota é uma lição de proveniência. O acesso não é o mesmo que exatidão, e uma interface traduzida não deve apagar a língua de origem.

A finalidade pública do registo também é declarada sem linguagem teatral. Centra-se em algoritmos de grande impacto, incluindo sistemas de IA de risco elevado, e dá aos visitantes uma visão de como funcionam. O visitante pode consultar algoritmos, organizações e modelos. O objetivo não é oferecer uma pontuação para cada algoritmo. É tornar a utilização de sistemas algorítmicos suficientemente visível para que as pessoas, as organizações e os meios de comunicação possam acompanhar, questionar e examinar a prática governamental.

O Algoritmekader neerlandês que o acompanha transforma essa finalidade num requisito. Afirma que, salvo exclusão aplicável, os organismos públicos publicam algoritmos de grande impacto e sistemas de IA de risco elevado no registo. Afirma também que uma publicação incorreta ou incompleta pode dificultar a compreensão e o questionamento, por parte das pessoas afetadas e de outras partes interessadas, da utilização de tecnologia que possa afetar os seus direitos. A transparência não é, portanto, apenas uma cortesia. A qualidade da entrada pode afetar a qualidade do controlo público.

The same guidance is careful about scope. It describes the register as a tool within a wider set of laws and requirements, and warns that the framework is not complete and may not include sector-specific legislation. The fact that an algorithm appears in a register does not settle every legal or ethical question. The fact that it does not appear does not prove that it is harmless. A reader needs the register's inclusion rule and the surrounding framework to interpret the entry.

That is the useful pattern for model registries. A public list should be easy to find, written for people who were not in the procurement meeting, and connected to the records that carry more detail. It should expose uncertainty rather than hide it. It should say when an English description is machine-translated. It should explain which systems are included and which are not. It should make a missing or stale entry a visible governance issue instead of a private disappointment.

There is no need to invent a dramatic incident to see why this matters. A citizen trying to understand an automated government process already has a practical question: is a system being used, by whom, for what purpose and under which explanation? A registry gives that question an address. The answer may still be incomplete. At least the institution cannot pretend that there is nowhere to ask.

Public does not mean naked

Transparency becomes counterproductive when it is treated as a command to publish everything. Public records can expose personal data, security-sensitive information, proprietary details and attack paths. They can also create false confidence by publishing technical fragments that no ordinary reader can interpret. The public-private boundary must be designed, documented and reviewed, not improvised by whichever team happens to own the content-management system.

The AI Act gives a legal example. Article 49(4) places particular systems in a secure non-public section and limits access to the Commission and the relevant national authorities. Article 71 makes the information registered under Article 49 publicly available except for the restricted sections, while information registered under Article 60 is accessible only to market-surveillance authorities and the Commission unless the provider consents to public access. Publicity is therefore a rule with exceptions, not a universal default.

Article 53 makes a similar distinction for general-purpose models. Providers must make technical documentation available to the AI Office and national competent authorities on request, and they must provide downstream documentation to integrating providers. The obligations are explicitly subject to the need to observe and protect intellectual-property rights, confidential business information and trade secrets. A registry should not force a provider to publish the material that the law says should be controlled. Nor should confidentiality become a polite excuse for withholding the existence, purpose or status of a system that affects the public.

A practical model registry can use layers. The public layer identifies the model, provider, status, intended purpose, broad capabilities, known limits, access routes, release conditions, evidence links and change history. A controlled layer carries detailed technical documentation, threat models, restricted evaluation material, incident details and other information that authorised reviewers need. A private operational layer carries secrets, personal data and internal control information that should not be exposed at all. The layers are different records with links, not one page with an accordion labelled transparency.

Uma boa transparência tem um limite. Publica o que as pessoas precisam de compreender sobre o sistema e protege o que os revisores autorizados devem controlar.

A camada pública deve continuar a ser específica. Pode dizer que um modelo é adaptativo durante a utilização sem expor uma representação privada do estado. Pode afirmar que uma rota é apenas por convite sem publicar tokens de convite. Pode descrever as modalidades de saída e uma política de marcação de conteúdo sem expor chaves de assinatura. Pode indicar que existe uma avaliação de risco e identificar o seu âmbito sem publicar um diagrama de segurança que tornaria o serviço mais fácil de atacar.

A camada controlada precisa da sua própria honestidade. Um documento marcado como confidencial não é automaticamente completo, atual ou correto. Precisa de um responsável, uma versão, uma regra de acesso e uma regra de retenção. Se um registo público liga para um registo controlado, a ligação deve revelar o seu estado e a rota responsável mesmo quando o conteúdo está restrito. Caso contrário, o público vê um buraco negro e é convidado a chamar-lhe governação.

O versionamento é onde um registo se torna útil

A maioria das falhas de registo não são dramáticas. São pequenos atos de esquecimento. Um novo modelo substitui um antigo, mas a entrada é editada no local. Uma política muda, mas o parágrafo de utilização pretendida permanece. Um fornecedor move uma rota de testes internos para uma versão beta externa, mas o selo de estado muda antes de a data de eficácia ser registada. Uma implementação é retirada, mas a entrada antiga desaparece, levando consigo o histórico. O presente parece arrumado. O passado torna-se impossível de responder.

Um registo com versões mantém pelo menos quatro datas separadas. A versão do conteúdo diz qual texto e campos do registo estão atuais. A data de eficácia diz quando a declaração se aplica. A versão do modelo ou pacote diz qual objeto técnico está a ser descrito. A data de verificação diz quando alguém verificou o registo. Estas datas podem coincidir. Não têm de coincidir. Tratá-las como uma única data é conveniente e muitas vezes errado.

As versões anteriores devem permanecer localizáveis sob uma regra de retenção adequada. O público não precisa de todas as edições internas, mas precisa de saber quando uma finalidade material, estado, rota, limitação ou declaração de propriedade mudou. Um registo de alterações pode dizer o que mudou sem expor informações privadas. Um registo legível por máquina pode ligar a versão anterior e um manifesto. Uma página legível por humanos pode explicar a consequência em linguagem corrente. As duas superfícies devem concordar.

O versionamento também torna a retirada significativa. Se um modelo é retirado porque uma rota foi encerrada, isso é diferente de uma recolha porque um defeito grave ou questão legal exige ação. Se um modelo permanece em implementações privadas existentes, o registo público deve dizê-lo. Se um sucessor é compatível apenas com algumas integrações, o limite de migração deve ser visível. Um registo que remove um nome sem registar o porquê deixa todos os leitores a jusante a inventar uma razão.

O histórico de alterações é especialmente importante para sistemas adaptativos. A identidade do modelo pode permanecer estável enquanto estados capturados, conjuntos de restrições, fontes de recuperação ou controlos de saída mudam. O registo pode indicar quais alterações criam um novo pacote, quais alterações exigem uma nova avaliação e quais alterações permanecem dentro do limite de identidade declarado. Isto não é detalhe excessivo. É a diferença entre um sistema que pode ser reproduzido e um sistema que só pode ser lembrado.

Os responsáveis fazem parte do registo

Uma entrada de registo de modelos sem um responsável é um boletim meteorológico. Diz-lhe como estava o céu e deixa-o sem ninguém para contactar quando o telhado começa a pingar. Os papéis de fornecedor e de implementador não são a mesma coisa, e nenhum deles deve poder dissolver-se na palavra plataforma.

O fornecedor é dono da identidade do modelo, do registo de desenvolvimento e da decisão de lançamento dentro do seu âmbito. Um implementador é dono da decisão de utilizar um sistema sob a sua autoridade, incluindo a finalidade local, as salvaguardas, a avaliação de impacto e os controlos operacionais. Um fornecedor a jusante pode integrar um modelo de uso geral num sistema de IA e assumir responsabilidades que o fornecedor do modelo não consegue ver. Um registo público deve expor essas relações onde a lei e o risco o exigirem.

As informações de contacto não são um preenchimento administrativo. Dão a uma pessoa afetada uma via para perguntar quem tomou uma decisão, que versão foi utilizada ou como pode ser pedida uma correção. Uma caixa de correio genérica pode ser adequada, mas deve conduzir a um processo mantido. A entrada deve também indicar se o contacto se destina a apoio técnico, pedidos de direitos, comunicação de incidentes, aquisições ou responsabilização pública. Uma caixa de entrada não pode ser todas as instituições ao mesmo tempo, apesar dos melhores esforços dos formulários modernos.

A titularidade deve incluir autoridade para alterar o registo. Se o responsável nomeado não puder suspender uma via, corrigir um estado ou publicar uma retirada, a entrada é decorativa. A organização pode ainda ter um responsável legal noutro lugar, mas a lacuna operacional permanece. Um bom registo torna a responsabilidade visível antes de um incidente obrigar as pessoas a desenhar a organização num quadro branco.

Conceber um registo que as pessoas conseguem realmente ler

O primeiro leitor de um registo de modelos nem sempre é um regulador ou um engenheiro. Pode ser um jornalista, um responsável por aquisições, um funcionário local, um investigador, um colaborador a quem pediram para usar o sistema, ou uma pessoa a tentar perceber por que motivo um serviço automatizado tratou do seu caso. A página deve responder à pergunta comum antes de recorrer a vocabulário especializado.

Comece pela identidade e pelo motivo da entrada. Diga quem fornece o modelo, que versão está a ser descrita, que tipo de objeto é e se se trata de um modelo, de um sistema de IA integrado ou de um registo de implementação. Diga se é interno, disponível para utilizadores convidados, no mercado, suspenso ou retirado. O leitor não deve ter de inferir o estado a partir de um botão de descarregamento.

Depois mostre a finalidade e o limite. Indique o que o modelo se destina a fazer, que utilizações ficam fora do âmbito da declaração e que decisões não está autorizado a tomar. Explique se o modelo pode adaptar-se durante a utilização, se é necessário um estado capturado para repetição e se uma via a jusante altera as condições. Uma lista de capacidades sem finalidade é um menu sem cozinha.

Use divulgação progressiva. O topo da página deve ser calmo e legível. As secções mais profundas podem expor o registo de máquina, os métodos de avaliação, o resumo do conteúdo de formação, os documentos legais e as provas de lançamento. Um leitor público pode parar após a primeira camada. Um auditor pode continuar. Um engenheiro pode descarregar uma representação estável. Ocultar o detalhe não é simplicidade. É apenas uma surpresa de carregamento lento.

A acessibilidade faz parte da credibilidade do registo. A página e a representação de máquina devem usar etiquetas claras, navegação por teclado, títulos úteis e alternativas de texto para visualizações. As datas não devem ser codificadas apenas por cor. Um selo vermelho não é um estado para um leitor que não consegue ver vermelho, e um gráfico que não pode ser lido sem rato não é uma explicação acessível. Um placard na praça da vila não se torna público se a rampa terminar no primeiro degrau.

Machine readability matters for a different reason. It lets researchers compare entries, lets public bodies build inventories, lets auditors detect stale records and lets a downstream tool verify that the page and the structured record refer to the same version. Machine-readable does not mean machine-only. The human page and the machine record should share identifiers, status, dates and links, with an integrity relationship that can be checked.

Registry fields are decisions

Every field tells the reader what the organisation believes is worth preserving. A provider field says who stands behind the model. A model name and version say how to distinguish it from a successor. A route field says where it can be reached. An intended-purpose field says which work the provider is prepared to describe. A limitation field says where the description stops. The schema is a governance document written in small rectangles.

Identity fields should be unambiguous and stable. They can include a provider's legal name, the model name, the version, a unique reference and links to a canonical record. If the model can be served through several products, the registry should distinguish the model identity from the integrating surface. If a product contains several models, the entry should not hide that fact behind the product name.

Status fields should include the value, the effective date, the reason or authority for the transition and any successor or predecessor. A date that is merely planned should be labelled as planned. A record that has not been verified recently should say so. The reader should be able to tell whether a model is available, proposed, paused or historic without interpreting an adjective invented by a marketing team.

Purpose and scope fields should describe the work in terms that a non-specialist can understand. They should name intended users where that matters, the kinds of inputs and outputs involved, and the decisions or actions the model may support. They should also state prohibited or unsupported uses. A model that can generate text is not thereby authorised to write an eligibility decision, and a model that can classify documents is not thereby authorised to classify people.

Capability fields need conditions. Modalities, context limits, tool access, language coverage, adaptation behaviour and output marking are meaningful only when tied to a route and a release. A capability that exists in an internal experiment but not in the external route should not be presented as one universal feature. The registry is not a wish list.

Data fields should say what the model receives, what it stores, what it learns from during use and what is used for evaluation, at the level that can be made public without exposing personal or confidential material. Training-content summaries and rights policies should be linked where required. A vague sentence such as trained on diverse data tells a reader almost nothing and asks them to supply a flattering interpretation.

Evaluation fields should identify the question, the method, the data boundary, the date, the result and the limitations. The entry does not need to reproduce every table, but it should not display a score without a denominator or a test without a purpose. A good evaluation link lets a reader see whether the evidence covers the intended use, a neighbouring use or only a laboratory condition.

Oversight fields should identify who can pause, override, review and investigate the system. If a model only recommends, say what action remains with the human. If a route can act on external systems, say which permissions and gates apply. If incident reporting has a dedicated route, publish it. Oversight is not a paragraph about keeping humans in the loop. It is a map of who can do what when the system is uncertain.

Os campos de prova e de integridade devem ligar a entrada pública a um registo de máquina com versões, a um pacote de lançamento, a uma declaração, a um pacote de avaliação ou a um registo de transparência. Um hash pode estabelecer que um ficheiro mudou ou não mudou. Não pode estabelecer que o ficheiro era verdadeiro, por isso o registo deve manter a alegação e a verificação de integridade separadas. O rigor técnico não substitui o discernimento, mas torna o discernimento mais fácil de localizar.

Por fim, os campos de alteração devem explicar o histórico. O que mudou, quando, porquê, quem aprovou, quais as rotas afetadas e se é necessária uma nova avaliação. A entrada deve permitir responder à pergunta mais comum na sala: o que é diferente do registo que lemos no mês passado?

O que um registo pode estabelecer

Um registo bem mantido pode estabelecer que um objeto definido está a ser descrito por um fornecedor nomeado sob uma versão específica do registo. Pode estabelecer a finalidade declarada, o estado, a rota de acesso e a titularidade. Pode estabelecer quais os documentos de apoio e registos de integridade que um leitor pode consultar e quais as informações deliberadamente controladas. Pode estabelecer que uma alteração foi publicada e que um registo anterior permanece disponível ao abrigo da regra de retenção indicada.

Pode também estabelecer a posição da própria organização. Se um fornecedor afirma que um modelo serve para apoio à decisão e não para recusa automática, essa afirmação é um limite público. Se um implementador afirma que uma avaliação de impacto foi concluída, a afirmação levanta a questão de onde pode ser encontrado o resumo ou o registo controlado. Se um fornecedor marca um lançamento como planeado, o rótulo impede que o plano se faça passar por histórico.

São factos úteis. Tornam a contratação mais precisa, a integração menos especulativa e as perguntas públicas mais fáceis de encaminhar. Também tornam o desacordo mais nítido. Um leitor pode dizer que a finalidade declarada é demasiado ampla, que o estado está desatualizado, que a limitação está em falta ou que as provas de apoio não cobrem a alegação. Um registo justifica a sua existência quando torna possível essa crítica.

O que um registo não pode estabelecer

Uma entrada de registo não pode estabelecer que um modelo é exato para todos os utilizadores, seguro em todos os ambientes, justo para todos os grupos ou lícito para todas as implementações. Não pode estabelecer que uma autoridade pública seguiu o procedimento correto apenas porque um sistema está listado. Não pode mostrar que um revisor humano compreendeu um resultado, que um titular de dados teve um recurso efetivo ou que um incidente seria detetado a tempo. Essas conclusões exigem provas sobre o sistema em uso, a instituição que o utiliza e as pessoas afetadas por ele.

Também não pode estabelecer que um modelo é independente do seu fornecedor, que uma rota é soberana por estar alojada na Europa ou que uma licença aberta faz desaparecer a responsabilidade. Titularidade, jurisdição, cadeia de abastecimento, controlo operacional e manutenção são questões separadas. Um registo pode expor os nomes e as ligações necessários para as colocar. Não pode respondê-las por tipografia.

Nem um registo pode provar o negativo. Uma entrada ausente pode significar que o objeto está fora do âmbito, que se aplica uma exclusão, que a publicação está atrasada ou que alguém não publicou. O leitor precisa de uma declaração de cobertura clara e de uma via para comunicar erros. Um placar público só é tão fiável quanto o processo que deteta quando um aviso está em falta.

Um registo ilustrativo, não um estudo de caso oculto

O que se segue é um desenho de registo ilustrativo, não um relato de uma organização, modelo ou evento real. Não utiliza nenhum cliente, autoridade pública, data de implementação ou resultado medido. O seu objetivo é mostrar como um leitor pode passar de uma entrada pública para uma via de provas controlada sem confundir as duas camadas.

  • Identidade: um nome de fornecedor, um nome de modelo, uma versão e um identificador de máquina estável.
  • Estado: avaliação controlada, com uma data de eficácia e uma nota de que não existe qualquer via externa aberta.
  • Finalidade: apoio à análise documental para pessoal formado, ficando as decisões externas automáticas fora do âmbito declarado.
  • Entradas e saídas: as modalidades representadas, os tipos de material de origem esperados e os tipos de saída que a via pode produzir.
  • Limites: fronteiras conhecidas de língua, domínio, atualidade, segurança e acesso, cada uma ligada à avaliação ou política relevante.
  • Supervisão: a função que pode suspender a via, o percurso de revisão para resultados incertos e o contacto para incidentes.
  • Evidência: um resumo público, um registo técnico com versões para revisores autorizados e um manifesto de integridade para os ficheiros publicados.
  • Alteração: uma ligação ao registo anterior, uma declaração do que mudou e a condição que exigiria uma nova avaliação.

Nada nesse registo diz que o modelo é bom. Diz o que o fornecedor está disposto a afirmar, onde a afirmação se aplica e como outra pessoa pode testá-la ou contestá-la. Isso chega para um placard. Também chega para impedir que muita linguagem de brochura se infiltre despercebida numa decisão jurídica ou operacional.

Porque é que o estado de pré-lançamento merece respeito

Pré-lançamento não é uma versão mais fraca de público. É um estado diferente. Os testes internos podem apoiar o trabalho de engenharia e segurança mantendo o acesso controlado. Uma versão beta convidada pode expor uma via a pessoas externas preservando condições, âmbito e o direito de parar. Um lançamento público altera quem pode confiar no sistema e que obrigações recaem sobre o fornecedor, integradores e entidades que o implementam. O registo deve tornar essas transições visíveis em vez de tratar o lançamento como uma única nota de trompete.

Um registo de pré-lançamento pode ainda assim ser útil ao público. Pode identificar o modelo, o fornecedor, a via pretendida, o estado, a evidência que existe e a evidência que ainda está pendente. Pode dizer que uma data está planeada e que o acesso não foi aberto. Pode publicar o portão de lançamento sem fingir que o portão foi ultrapassado. Este é um lugar especialmente bom para um registo ser aborrecido. Um estado aborrecido é mais seguro do que uma ambiguidade entusiasmante.

Na Dweve, tentamos aplicar essa disciplina ao nosso próprio registo público. No nosso Trust Centre, o registo de modelos está marcado como pré-lançamento e lista o Dweve Loom 1.0 como teste interno exclusivo de pré-lançamento a partir de 1 de agosto de 2026. Regista que não ocorreu qualquer lançamento externo até essa data e lista 1 de setembro de 2026 como data planeada de acesso ao mercado da União para uma versão beta externa apenas por convite. Planeada é a palavra importante: a entrada não transforma um plano num evento.

O nosso registo público também deixa claro que o Loom é o único modelo ali listado, que é proprietário e não é lançado sob uma licença de modelo de código aberto, e que os nossos produtos e ferramentas de código aberto com licença separada não são apresentados como modelos adicionais. Essa fronteira impede que um catálogo de produtos seja confundido com um registo de modelos. Também mantém a afirmação pública suficientemente pequena para ser verificada.

É tudo o que precisamos de dizer sobre a Dweve aqui. Um registo de modelos é útil quando torna o nosso próprio estado de lançamento menos lisonjeiro mas mais preciso. Deve fazer o mesmo para qualquer outra pessoa.

A fronteira público-privado é uma decisão de conceção

O registo mais sólido não é o que tem mais campos. É aquele cujos campos têm uma razão de ser, um responsável e um limite. Os leitores públicos precisam de uma identidade estável, de um propósito declarado, de um estado verdadeiro, de uma organização responsável, de ligações utilizáveis e de limitações suficientes para compreenderem a afirmação. Os revisores autorizados precisam de provas mais aprofundadas, de detalhes técnicos controlados e de um caminho para inspecionar incidentes ou testes sensíveis. Os operadores precisam de segredos, permissões e runbooks que não deviam estar no placard de todo.

Essas camadas devem concordar sobre os factos que atravessam o limite. Se a página pública diz que uma rota está suspensa, o registo controlado deve dizer quem a suspendeu e porquê. Se um ficheiro técnico foi substituído, a entrada pública não deve continuar a apresentá-lo como atual. Se uma avaliação está restrita, a página pública deve ainda assim indicar o seu âmbito e estado. O limite deve restringir o acesso ao detalhe, não criar três versões incompatíveis da realidade.

Os leitores devem poder fazer cinco perguntas simples e receber cinco respostas estáveis. O que é este objeto? Quem é responsável por ele? O que pode fazer? Qual é o seu estado atual? Que provas e recursos existem quando a afirmação é contestada? Um registo que responde a essas perguntas já está a fazer trabalho institucional. Um registo que não consegue respondê-las não deve ser salvo por distintivos animados ou por um painel com doze filtros.

Há uma forma otimista de ler o movimento europeu em direção aos registos de modelos e algoritmos. Não é que uma base de dados vá resolver a governação da IA. É que as instituições públicas estão a criar lugares onde as afirmações têm nomes, datas, responsáveis e limites. Esses são os pequenos componentes a partir dos quais se constroem sistemas de responsabilização maiores.

O placard tem de sobreviver à mudança

Um registo de modelos só é o novo placard público se os avisos continuarem legíveis depois de o tempo mudar. A página deve sobreviver a uma atualização do modelo, a uma mudança de fornecedor, a uma nova implementação, a uma limitação corrigida, a uma rota retirada e a uma pergunta difícil de alguém que não estava na sala. Isso significa manter o histórico, rotular os planos, ligar as provas e dizer o que o registo não consegue provar.

O trabalho é menos glamoroso do que uma página de lançamento. Também é mais duradouro. Um registo público que distingue a identidade do modelo do estado da implementação, o estado da intenção, a documentação da prova e os factos públicos das provas controladas dá às pessoas algo melhor do que garantias. Dá-lhes um caminho através do sistema.

Os bons registos não pedem aos leitores que confiem numa cor, num número ou num nome famoso. Tornam a afirmação suficientemente estreita para ser inspecionada e o limite suficientemente claro para ser contestado. Deixam um rasto até às pessoas que podem responder, aos registos que podem ser verificados e à decisão que pode ser alterada. Essa é uma ideia cívica muito antiga, com um formato de ficheiro razoavelmente moderno.

Coloque o aviso no placard. Coloque as provas por trás dele. Mantenha o aviso antigo onde alguém ainda o possa ler. Depois deixe o público decidir o que o registo merece.

Fontes