Blog · Analysis · Last reviewed June 23, 2026

The AI Register Becomes Public Memory

AI registers are becoming the public memory layer of automated government and public-service automation. Their promise is simple: before a system can be challenged, audited, compared, or democratically discussed, people have to know that it exists.

The stronger claim is narrower: a register entry is not proof that a system is lawful, safe, fair, useful, or well governed. It is a dated public claim that should be traceable to field-level sources, evidence, owners, scope decisions, redactions, complaints, incidents, changes, and consequences.

The registered object should be the deployed use in context: system, workflow, affected service, decision force, data path, vendor role, human oversight, evidence record, and route for correction. A model name alone is not public memory.

The First Problem Is Finding the Machine

The first obstacle in AI accountability is often not explainability. It is discovery. A person cannot contest an automated decision system they do not know is in use. A journalist cannot investigate a tool that is hidden inside procurement records. A regulator cannot prioritize oversight if agencies do not maintain a live inventory. A public servant cannot govern a deployment that has spread through pilots, vendors, spreadsheets, workflow tools, and local experiments faster than the institution can remember it.

This is why AI and algorithm registers matter. They look bureaucratic because they are bureaucratic: names, owners, purposes, affected services, data categories, model descriptions, risk assessments, human oversight, vendors, status, and contact paths. But bureaucracy is not a side issue here. The register is the institutional form that turns a private or internal system into a public object.

The modern AI system often enters public life as a convenience layer: a chatbot, matching tool, risk flag, translation assistant, fraud model, triage system, document classifier, recommendation engine, search assistant, or analytics dashboard. The register asks a prior question: where is it, who owns it, what does it do, whom can it affect, and what evidence exists that it should be there?

What Counts as a Register

An AI register is a maintained record of AI-supported systems or use cases in a specific institutional context. A useful entry identifies the owner, purpose, affected service, affected population, lifecycle status, risk category, decision force, data and vendor dependencies, evidence records, review date, redaction basis, and the route for questions, complaints, correction, or appeal.

The word "register" now covers several different objects. An internal AI system inventory helps an institution discover what it uses. A public transparency register lets outsiders see consequential systems. A legal registration database, such as the EU AI Act database for certain high-risk systems, creates a compliance record. A standardized algorithmic-transparency template makes records comparable. Audit, complaint, and incident ledgers preserve what happened after deployment. These layers should interoperate, but they are not the same artifact.

That distinction matters because hidden systems often hide by category. A vendor feature may be called analytics, a spreadsheet workflow may be called automation, a classifier may be embedded inside case management software, and an agent may act through tools rather than one visible model. Registerability should attach to function, decision force, and affected people, not to whether a product is branded as AI.

The registered object should therefore be the deployed use in context, not the model name in isolation. The same model can be a low-stakes drafting aid in one workflow and a high-scrutiny decision-support system in another. Conversely, an ordinary platform feature can become registerable when it materially changes triage, ranking, case notes, eligibility screening, enforcement priorities, or access to a public service.

A practical registerability test is this: if a person, worker, applicant, resident, patient, student, tenant, traveler, or service user would reasonably need to know that the system shaped a consequential interaction in order to challenge, correct, or understand it, the use belongs in an inventory and may need a public record. Procurement labels, pilot status, vendor branding, or "human in the loop" language should not decide the boundary by themselves.

The Entry Is a Claim

A register entry is a claim that a particular institution knows a particular system exists, has assigned an owner, has described the system's function, and can point to the records that justify or constrain the deployment. The entry may be public, but the stronger record usually sits behind it: procurement files, model or system cards, data documentation, impact assessments, security review, human-oversight procedures, logs, change approvals, complaints, incident records, and decommissioning decisions.

The minimum useful entry has six layers. Identity: a stable name, identifier, owner, vendor or provider, and lifecycle status. Context: the service, decision, workflow, affected population, data categories, and legal or policy authority. Decision force: whether the tool retrieves, summarizes, drafts, recommends, ranks, flags, triages, automates, or materially constrains human judgment. Evidence links: where to find the impact assessment, safety case, system card, privacy review, security review, audit record, or evaluation summary. Change history: what changed in the model, data, prompt, vendor, workflow, risk category, or human-review rule. Accountability path: who can answer questions, receive complaints, correct records, trigger review, suspend use, or retire the system.

This is why register design overlaps with algorithmic transparency, AI audits and assurance, AI incident reporting, AI change management, AI procurement, vendor and platform governance, and AI bills of materials. The public row is the index. The governance question is whether the indexed evidence exists, is current, and can change the deployment.

The Evidence Chain

The public row should be a pointer, not the proof. For consequential systems, each important field should point to a source class: procurement record, impact assessment, privacy review, security review, accessibility check, model or system card, AI bill of materials, testing summary, human-oversight procedure, incident log, complaint record, appeal path, or decommissioning decision. The register can publish a plain-language claim while preserving a stronger internal or regulator-facing dossier.

This evidence chain should be field-level, not page-level. "Provider" may come from a contract. "High-impact" may come from legal or policy review. "Data categories" may come from a privacy assessment. "Human oversight" may come from a procedure that frontline staff actually follow. "No incidents" may mean no incidents occurred, no incidents were reported, no incident channel exists, or the incident record is not public. A useful register keeps those claims separate instead of flattening them into one official voice.

The same stable identifier should therefore travel through the internal inventory, public register, procurement file, AIBOM, impact assessment, audit trail, complaint record, incident report, and post-market monitoring record. Otherwise each oversight process names a slightly different machine, and public memory breaks exactly where accountability needs continuity.

The Municipal Start

Amsterdam and Helsinki helped make the register visible as a civic form. Helsinki's AI Register describes itself as a window into the city's AI systems, letting residents see quick overviews or more detailed information and give feedback. Its entries include public-service chatbots, intelligent material management in libraries, and recommendation tools. The point is not that every listed system is a frontier model. The point is that ordinary municipal automation becomes part of a public record.

Amsterdam's early algorithm register followed the same democratic instinct: if algorithms assist public decisions or services, the city should say so in a form citizens can inspect. The Dutch national Algorithm Register later absorbed Amsterdam's register into a central platform. As of this review, the Dutch register says government organizations publish information there about algorithms used in their work, focuses on impactful algorithms including high-risk AI systems, and listed 1,480 algorithm descriptions. That number is a register count, not a proof that every deployed system is listed or safe.

Eurocities' Algorithmic Transparency Standard generalizes that municipal lesson. It gives cities a shared schema for explaining algorithmic tools, the decisions they support, and why they are used. The schema matters because transparency that cannot be compared is weak. If every agency invents its own vocabulary, the public receives scattered pages rather than an oversight surface.

The National Inventory Layer

The United States has moved toward a federal inventory model. OMB Memorandum M-25-21 requires federal agencies to update annual AI use-case inventories, publish releasable portions, and apply minimum risk-management practices to high-impact AI. OMB's 2025 federal repository, current in its summary as of April 13, 2026, reports 56 agency submissions, 3,611 individually reported AI use cases across all stages of development, 1,818 deployed or piloted use cases, and 445 high-impact use cases. The repository also separates some common commercial off-the-shelf AI reporting from individually reported use cases and names exclusion categories, so its totals are structured counts, not a census of every model feature available to government staff. The Department of Justice says its 2025 inventory included 315 entries, a 30.7 percent increase from 2024, and covered use cases in pre-deployment, pilot, deployed, or retired stages.

DHS publishes a full and simplified AI use-case inventory, uses the M-25-21 high-impact categories, and says the most recent annual update was published on January 28, 2026. The Federal Reserve Board, Interior Department, VA, and other agencies publish their own inventory or compliance materials. This is not a single elegant public database. It is a distributed reporting regime, built out of agency pages, spreadsheets, compliance plans, OMB rules, and an OMB GitHub consolidation of publicly releasable data.

That distribution has advantages. Agencies understand their own missions, systems, exemptions, and security constraints. It also has costs. A citizen looking across agencies may find inconsistent language, uneven detail, redactions, stale statuses, broad use-case categories, and missing context about whether a tool actually affects decisions or merely supports staff. The inventory can become a map, or it can become a fog of official descriptions.

The data-work behind the register is part of the governance evidence. OMB's 2025 repository publishes machine-readable CSV and spreadsheet files, a data dictionary, a data-sourcing summary, and data-standardization reports. DOJ's 2025 page explains consolidation of similar use cases, non-sequential ID changes after aggregation and vendor changes, and a release protocol that used FOIA standards and favored partial release over full withholding. Those notes are not clerical trivia. They tell readers how much trust to place in the rows, the counts, and the gaps.

They also show why reconciliation matters. OMB's consolidated table lists the Department of Justice at 314 total publicly reported AI use cases, while DOJ's own page says its 2025 inventory includes 315 entries. That small mismatch does not prove error or evasion; it proves that readers need date, data source, consolidation rule, and row-level lineage before treating register counts as exact public truth.

OMB's high-impact AI framework raises the stakes. M-25-21 defines high-impact AI around outputs that serve as a principal basis for decisions or actions with legal, material, binding, or significant effects on rights or safety. It also requires minimum risk-management practices for those uses, including pre-deployment testing and AI impact assessments. The inventory is therefore not just a list. It is the front edge of a governance workflow.

The United Kingdom shows a third national model, one built on a shared schema rather than a patchwork of agency pages. The Algorithmic Transparency Recording Standard, first published in November 2021, gives public-sector bodies a template for recording algorithmic tools that significantly influence decisions or directly interact with the public. In May 2025, GOV.UK guidance described the ATRS as mandatory for government departments and for arm's-length bodies that deliver public or frontline services or directly interact with the public. The official Data in Government blog said 59 records had been published when that mandatory-turn post was written; the live GOV.UK records page listed 133 records at this review. That gap is useful: a register is a growing public system, so the cited count must travel with a date, source, and scope.

Canada shows a fourth layer: a public register plus a public-facing assessment path. On November 28, 2025, the Treasury Board of Canada Secretariat announced the Government of Canada's first public AI Register, describing it as a record of where and how AI is used in the federal government. The initial version included input from 42 institutions and over 400 systems being explored, developed, implemented, or deployed. Canada's progress page describes that register as a minimum viable product assembled from existing sources such as Algorithmic Impact Assessments, Access to Information requests, Parliamentary Questions, Personal Information Banks, and the GC Service Inventory, with a future replacement version intended to be updated regularly. The launch release also says the register excludes AI embedded within low-risk commercial products such as virtual assistants or spell checkers, which is a scope choice that should remain visible. Its Algorithmic Impact Assessment tool remains a separate mandatory risk-assessment questionnaire supporting the Directive on Automated Decision-Making, composed of 65 risk questions and 41 mitigation questions, with departments responsible for publishing final AIA results on the Open Government Portal.

The mandatory turn is the part worth marking. A voluntary register samples the conscientious; only the teams already comfortable with scrutiny tend to file. A mandatory one is supposed to capture the reluctant, the embarrassing, and the consequential. But a mandate is only as strong as its scope and enforcement. "Significantly influence" is a judgment call, and any published count is meaningful only against the unknown denominator of tools actually in use. A mandate moves the question from whether agencies will disclose to whether anyone checks what they left out.

Coverage and Reconciliation

The next maturity test is coverage. A register should not only publish entries; it should explain how the institution searched for entries, what counted as in scope, what was excluded, who certified the submission, and how the public can report a missing system. Without that methodology, a register count is easy to overread.

Official counts also need reconciliation discipline. OMB's 2025 repository reports a point-in-time federal summary, while individual agency pages may use their own publication dates, spreadsheet formats, consolidation rules, withholding rules, and explanatory notes. That does not automatically indicate bad faith. It does mean the count should be cited with its source, date, schema, and scope. A serious register should preserve merge and split history, stable identifiers, retired-system treatment, COTS reporting rules, redaction reasons, public challenge status, and changes in high-impact classification.

Coverage should be audited the same way finance, security, and procurement records are audited: by sampling purchases, cloud accounts, case-management tools, help-desk systems, source repositories, browser extensions, vendor features, and frontline workflows against the official inventory. The strongest register is not the longest list. It is the list that can survive a search for what is missing.

That search should include shadow and embedded AI. Enterprise assistants, browser plug-ins, cloud analytics, case-management add-ons, procurement scoring tools, call-center summaries, translation features, and contractor-operated workflows may not appear as standalone AI systems. The register has to ask whether they materially shape a public interaction, not whether they arrived through a conspicuous AI procurement line. That connects public registers to enterprise connector permission maps, data provenance, and data minimization.

Register Hygiene

Good registers need maintainability, not only publication. Each row should carry a stable identifier, schema version, publication status, source system, accountable approver, last-validated date, review interval, change reason, and evidence status. If an entry is based on vendor self-description, agency review, independent audit, procurement documents, user complaint, impact assessment, or incident report, that source status should be visible or at least inspectable by an oversight body.

Machine-readable publication matters because oversight is comparative. OMB's repository exposes files and data documentation; GOV.UK's ATRS page lets readers filter records by organization, function, capability, phase, region, and publication date and provides feed subscription paths; Eurocities' Algorithmic Transparency Standard offers CSV, Excel, and JSON-schema routes for comparable municipal records. These features are governance infrastructure when they preserve retired rows, schema changes, correction history, and field definitions. They are weaker when they only make the current snapshot easier to browse.

NIST's AI Risk Management Framework makes the same point in risk-management language. Its Govern function says mechanisms should be in place to inventory AI systems according to organizational risk priorities, and that organizations should have processes for decommissioning and phasing out AI systems safely. A register that cannot retire a system, preserve decommissioning evidence, or point to a current owner is not public memory. It is a brochure archive.

Register hygiene is therefore a records-management problem. A public row should not be silently overwritten when a system changes model, vendor, data source, prompt, tool permission, affected population, or decision force. It should preserve a dated change event, a reason, an accountable reviewer, and the evidence records that were reopened. Otherwise the register becomes an attractive front end for disappearing history.

Registration Under the EU AI Act

The EU AI Act pushes registration into law. Article 49 requires providers of many Annex III high-risk AI systems to register themselves and their systems in the EU database before placing them on the market or putting them into service. It also requires registration when a provider concludes under Article 6(3) that an Annex III system is not high-risk, and it requires public authorities and entities acting on their behalf to register their use of many high-risk systems before deployment. Certain law-enforcement, migration, asylum, and border-control registrations go into a restricted non-public section, while critical-infrastructure systems are registered at national level.

Article 71 describes the database as user-friendly, easily navigable, and machine-readable for public information, while preserving restricted sections for specified sensitive uses. The timing should be stated carefully. The AI Act itself entered into force on August 1, 2024, and the Commission's implementation page, last updated May 11, 2026, notes that a political agreement on the AI Omnibus would shift rules for many high-risk systems used in areas such as biometrics, critical infrastructure, education, employment, migration, asylum, and border control to December 2, 2027, with product-integrated systems moving to August 2, 2028. The registration architecture is already visible in Articles 49 and 71, but the operational compliance calendar is still part of the implementation story.

That architecture reveals a hard truth about transparency. Some systems need public visibility because they affect rights, access, work, education, public benefits, or safety. Some systems also touch security, policing, migration, or infrastructure in ways that make full public disclosure sensitive. The challenge is not solved by saying "publish everything" or "trust the authority." The challenge is to design a record structure that gives the public, competent authorities, auditors, courts, and affected people the right level of access for the right purpose.

Registration also shifts attention from the model as a general artifact to the system in context. A model used for entertainment is not the same public object as a model used for hiring, benefits, migration screening, school placement, or medical triage. The register has to capture deployment, not only technology.

The EU frame also shows why registration must join other lifecycle records. A high-risk system can have technical documentation, automatic logs, post-market monitoring, serious-incident reporting, deployer duties, and affected-person complaint routes. If those records cannot point back to the same registration entry, the database may name the system without making its later behavior accountable.

What Registers Miss

A register can fail in several ways.

It can be incomplete. Systems may be left out because staff do not recognize them as AI, because pilots are treated as temporary, because vendors bundle AI into larger products, because agencies fear reputational risk, or because exemptions swallow the rule.

It can be too vague. A title, a vendor name, and a cheerful purpose statement do not tell the public how the tool changes work, what data it uses, who is affected, what human review means, or what happens when the system is wrong.

It can hide inside procurement. A tool may be bought as a case-management system, productivity suite, risk dashboard, or contractor-operated service while its AI-supported function is treated as a feature rather than a public use. Without contract disclosure rules and platform-change monitoring, the register can miss the system precisely when control has moved outside the agency.

It can be too technical. A register written only for specialists may satisfy a transparency checkbox while excluding the people most likely to be affected by the system.

It can hide decision force. A system may be described as "support" even when its scores, rankings, summaries, or risk flags structure the choices available to staff. The public needs to know whether the system drafts, recommends, ranks, flags, triages, approves, denies, or merely retrieves information.

It can be stale. AI systems change through model updates, retraining, prompt revisions, workflow integrations, vendor substitutions, policy changes, and staff practice. A register that is accurate once can become misinformation by neglect.

It can lose change history. A use case can be renamed, merged, split, transferred to a new vendor, moved from pilot to production, or reclassified from low impact to high impact. If the register overwrites rather than versions those transitions, public memory becomes a present-tense snapshot with no institutional past.

It can lack a denominator. A register with 59, 315, or 3,611 entries still does not say how many registerable systems were missed. Counts are useful for tracking disclosure growth, but they are not coverage guarantees.

It can lose source status. A row may repeat a vendor description, agency purpose statement, self-assessed risk level, or legacy procurement label without saying who verified the field. Without field-level source status, the register can make weak assertions look equally official.

It can overdisclose. A public register can expose personal data, protected service details, security-sensitive architecture, active investigation methods, vulnerable populations, or adversarial test information if transparency is treated as a data dump rather than a disclosure design problem.

It can detach from complaints and incidents. If people can report a bad output, file an appeal, or raise an incident without that signal updating the register, public memory splits into disconnected records.

It can become accountability theater. Publication can create the feeling that oversight has happened. But a listed system is not necessarily lawful, fair, useful, secure, contestable, or worth deploying. The Dutch discussion is right: registration is the beginning of governance, not the completion of it.

Disclosure Tiers

The register should have disclosure tiers, not one universal visibility setting. The public should receive the system's existence, purpose, owner, affected service, decision force, lifecycle status, broad data categories, safeguards, review date, complaint route, and links to public evidence where available. Affected people may need more specific notice, explanation, correction rights, and appeal records. Auditors and regulators may need logs, test results, procurement files, model-change histories, vendor evidence, and confidential incident reports. Courts may need still deeper discovery under protective rules.

This tiering is not a loophole for secrecy. It is a way to keep useful transparency from becoming either a privacy breach or a security disclosure. The rule should be explicit: when a field is hidden, the reason and reviewing authority should be recorded, and a competent oversight body should be able to inspect the underlying record. Otherwise "sensitive" becomes the easiest place for consequential systems to disappear.

Disclosure tiers also need usability rules. A register that only works for lawyers, procurement officers, or technical auditors will not serve affected people. Public fields should use plain language, accessible formats, stable links, downloadable data, and a route to request clarification, correction, translation, or accommodation. That ties public registers to the site's broader commitments on accessibility, privacy and data, and research integrity.

Redaction should itself become a record. A withheld field should carry a class of reason, review date, reviewer role, and appeal or oversight route. That is the register version of the redaction-model problem: secrecy may be necessary, but unlogged secrecy turns public memory into a managed absence.

The Governance Standard

A serious AI register should meet a stricter standard than public relations transparency. At minimum, it should meet twenty practical tests.

First, scope should be functional. The rule should cover deployed systems, pilots, embedded vendor features, agents, spreadsheet automations, and decision-support tools when they materially affect a service or population. If a tool performs an AI-supported function, a name change should not let it escape the register.

Second, every entry should have an accountable owner. The public needs a named agency, office, or role responsible for the system, not only a vendor or platform label.

Third, the register should identify decision force. It should say whether the system informs, recommends, ranks, flags, drafts, automates, or materially influences a decision, and whether that decision affects rights, safety, access, money, employment, education, housing, health, policing, immigration, or public services.

Fourth, the register should identify affected people. A useful entry names the service area, user group, public population, worker group, or applicant category that may be affected. "Internal efficiency" is not enough if the output later shapes a person's case.

Fifth, the register should show evidence paths. Useful entries point toward impact assessments, privacy reviews, security reviews, accessibility checks, testing summaries, evaluation results, human-oversight procedures, notice and appeal routes, incident channels, procurement documents, and audit trails where disclosure is lawful.

Sixth, the register should track lifecycle status. Planned, pilot, deployed, suspended, retired, and replaced systems should not be collapsed into one timeless category. Public memory needs time, including review dates and decommissioning records.

Seventh, the register should use stable identifiers. Names change, vendors merge, products are replaced, and use cases are consolidated. A stable identifier lets later audits, incident reports, and procurement records point to the same system.

Eighth, the register should be searchable and machine-readable. Oversight depends on comparison. Researchers, journalists, advocates, and auditors should be able to see patterns across agencies, vendors, domains, risk categories, and populations.

Ninth, the register should include absence rules. If systems are excluded from public view for security, law-enforcement, privacy, or national-security reasons, the exemption itself should be logged for competent oversight. Otherwise the most consequential systems can disappear into the exception.

Tenth, registration should trigger review. A system newly registered in a high-impact category should not merely appear on a website. It should enter an oversight queue: risk classification, pre-deployment testing, civil-rights review, privacy review, public notice where appropriate, and a path for affected people to contest outcomes.

Eleventh, register entries should connect to incidents and audits. A complaint, serious failure, system update, vendor change, or negative audit finding should not live in a separate memory hole. It should update the register or link to a record that says what changed.

Twelfth, coverage should be tested. The institution should periodically compare the register against procurement, data, cloud, security, accessibility, privacy, and frontline workflow records. A missing high-impact system is not only a paperwork problem; it is an accountability failure.

Thirteenth, entries should support correction. A register should let staff, vendors, researchers, affected people, auditors, and watchdogs report missing entries, stale descriptions, broken links, misleading claims, and unlisted incidents. Public memory needs a correction channel, not only a publication channel.

Fourteenth, redaction should be governed. Each withheld field should have a reason, an owner, a review date, and an alternative oversight path. Security, privacy, law-enforcement, or national-security limits may be legitimate, but they should not erase the fact that a system exists from every accountable forum.

Fifteenth, material changes should create a new public event. A model replacement, data-source change, new population, vendor substitution, automation of a formerly advisory output, or high-impact reclassification should not silently edit the old row. It should create a visible update with a date, reason, review owner, and affected evidence records.

Sixteenth, the register should reconcile with procurement and vendor records. Commercial off-the-shelf features, embedded analytics, assistants, APIs, and contractor-operated tools should not escape because the agency licenses a platform instead of building a model. The AI register should connect to contract terms, subprocessor records, platform update notices, data-use restrictions, portability rights, and exit plans.

Seventeenth, rows should carry source status. The register should distinguish self-attested, agency-reviewed, independently audited, regulator-verified, disputed, redacted, stale, retired, and corrected fields. Public memory is more useful when it tells readers how a claim entered the record.

Eighteenth, missing evidence should be visible. If a consequential row lacks a current impact assessment, testing summary, review owner, incident channel, complaint route, AIBOM, audit trail, or decommissioning plan, that absence should appear as a field rather than disappear into silence. Missing evidence is governance information.

Nineteenth, public search should follow services, not only system names. A person usually knows the benefit, school, police interaction, hiring process, clinic, tax notice, permit, or appeal that affected them, not the model identifier. Register search should support service names, agencies, vendors, affected populations, and decision contexts.

Twentieth, schemas and validation rules should be public. Field definitions, required values, exclusion categories, validation checks, version history, and correction workflow should be published with the data. A register without schema transparency asks the public to trust the table without knowing how the table was made.

Source Discipline

Register analysis needs careful source discipline. Primary legal text, official implementation guidance, agency inventory pages, public-register counts, blog updates, vendor claims, and news stories are different kinds of evidence. A source that proves a register exists does not prove that the register is complete. A source that counts entries does not prove that the underlying systems are lawful, effective, fair, secure, or actively used. A legal registration obligation does not prove that public-facing records will contain everything an affected person needs.

The most useful practice is to separate six claims: what the law or policy requires, what the register schema asks for, what entries have actually been published, what the register methodology says about coverage and exclusions, what evidence exists that listed systems are governed after deployment, and what the register itself admits it does not yet know. That separation keeps transparency from becoming theater. It also makes internal pages such as Transparency and Public Registers, AI System Inventory, AI Audit Trails, AI Post-Market Monitoring, AI Procurement, Vendor and Platform Governance, and The Incident Report Becomes Public Memory part of the same accountability chain.

Field-level source status is part of that discipline. "This system exists" may be supported by a procurement record. "This system is high-impact" may be a legal classification. "This system is safe" may be a vendor assertion, an agency test result, or an independent assurance claim. "This system has no incidents" may mean no incidents occurred, no incidents were reported, no incident channel exists, or the incident record is non-public. A useful register keeps those meanings apart.

Counts should be treated as dated measurements, not timeless facts. The Dutch register's 1,480 descriptions, OMB's 3,611 individually reported use cases, OMB's 314 DOJ rows, DOJ's own 315-entry inventory statement, GOV.UK's 133 live ATRS records, and Canada's initial public-register description of over 400 systems from 42 institutions were checked against the named official pages on June 23, 2026. They should not be compared as if they used the same definition, reporting period, inclusion rule, validation method, risk threshold, or publication maturity.

What This Changes

The AI register is a memory technology for institutions that are learning to act through models.

That makes it more important than it looks. The visible drama of AI governance is often the courtroom, the summit, the executive order, the frontier model launch, or the scandal after harm. The register is quieter. It is the spreadsheet before the hearing, the schema before the audit, the public page before the lawsuit, the entry that lets a citizen say: this system exists, it touched my case, and I want to know why.

Model-mediated government tends toward invisibility because it hides inside workflow. The clerk sees a recommendation. The manager sees a dashboard. The citizen sees an answer, delay, denial, or silence. The register pulls that hidden layer into institutional memory.

But memory can also be decorative. A society can build a beautiful catalog of machines it does not control. The deeper test is whether the register changes power: whether it helps people find the system, understand its role, challenge its outputs, audit its behavior, compare it with alternatives, and shut it down when the evidence fails.

The machine that cannot be found cannot be governed. The machine that is merely listed has only been named. Public memory begins at registration, but democratic control begins when the name can be used.

Sources

Return to Blog