The city's new AI system for prioritizing code enforcement inspections had been running for four months when a neighborhood association in the city's predominantly Latino east side filed a public records request for the algorithm's decision criteria. Carmen Acevedo, the city's Chief Data Officer, received it on a Thursday afternoon. Her immediate problem was not legal: the city had a strong public records policy and understood itself to be obligated to produce the requested documentation. The problem was operational. The documentation did not exist in a form a non-technical reader could interpret, the vendor contract included a confidentiality clause covering model architecture, and the city attorney was uncertain what exactly "the algorithm's decision criteria" meant in a disclosure context. The association's concern was legitimate. They suspected the system was sending inspectors disproportionately to lower-income neighborhoods while code violations in wealthier areas went unvisited. Carmen had no way to confirm or deny that from the documentation she held.

What the Request Actually Exposed

The uncomfortable fact in Carmen's situation is not that the city was hiding something. It is that the city did not know. Four months of production operation had generated inspection assignments, and nobody had built the monitoring that would show how those assignments distributed across the city. A records request asks what the record shows; when the record has never been assembled, the request does not just create a disclosure problem, it reveals a governance one. The vendor clause and the undefined phrase "decision criteria" were real obstacles, but they were obstacles in front of an answer nobody had. The city attorney's uncertainty about what that phrase even meant is worth noting too: a term that has to be defined under deadline, by counsel, in response to a hostile request, is a term that should have been defined in the system's documentation on the day it went live.

That is the sequence worth remembering, because it inverts the usual assumption. Transparency work is often treated as a communications task appended to a system that already works. In practice the ability to disclose depends on instrumentation that has to exist beforehand: the logging, the equity monitoring, the documented decision scope, the record of who authorised what. An agency that cannot answer a hard question about its own system does not have a transparency gap. It has a monitoring gap wearing a transparency gap's clothes, and publishing faster will not close it.

Transparency as a Strategic Posture

Government leaders often experience transparency demands as legal obligations to be minimised or managed. A more useful framing is strategic. Agencies that build proactive transparency infrastructure, publishing AI inventory lists, posting bias audit results, maintaining public-facing documentation of algorithmic decision criteria, tend to face fewer adversarial records requests and fewer trust crises than agencies that disclose only when compelled. The structural reason is narrow and worth stating precisely: proactive disclosure decides who explains an AI system first, and first explanations are sticky.

Be careful not to overstate the effect. Proactive publication does not reduce the number of legitimate concerns about a system, and where a real problem exists it will often attract more scrutiny after publication rather than less. Carmen's own registry is the proof: publishing it surfaced an unaudited system and produced a finding that led to a council-commissioned independent audit. That is the mechanism working correctly, and it looks from the inside like more attention, not less. If your reason for publishing is that publishing buys quiet, you will stop the first time it does not.

Carmen's agency moved from reactive to proactive after the code enforcement incident. The shift required no additional budget. It required a decision to disclose, and then the operational work that made disclosure possible. The operational work turned out to be much harder than the decision, which is where most agencies stall. Deciding to publish is one meeting. Producing a maintained, accurate, plain-language account of twelve production systems is a standing commitment against staff time that nobody has budgeted.

What Transparency Does Not Do

This lesson's title is a claim that needs bounding, because the most common failure in government AI transparency is treating the artifact as the outcome. Publishing a model card, an inventory entry, an impact assessment or an annual transparency report does not produce public trust and does not discharge an accountability obligation. It produces a document. Whether trust follows depends on whether the document is accurate, whether the thing it describes is defensible, and whether the agency does something when the document says the system is performing badly.

The failure mode has a shape. An agency publishes a register, points to the register when challenged, and treats listing as compliance. But a register entry evidences that a system was listed on the day it was listed. It does not evidence that the entry is current, that the oversight it describes actually ran, that the equity monitoring it references produced any output, or that a system absent from the register does not exist. A completed checklist has never once made a false statement true. The register's value is that it makes the agency's own claims specific enough to be checked, including by the agency.

The same bound applies to disclosure as protection. It is fair to say that an agency whose published account matches the raw documentation it later produces has fewer surprises to survive than one whose accounts diverge. It is not fair to say that publishing insulates an agency from investigative attention, and an agency that publishes for that reason will quietly shade the difficult findings out of the next report. Publish because the public is owed an account of systems that act on them. Consistency between the account and the record is a consequence of that, not the purpose of it.

The AI Transparency Registry

An AI transparency registry is a public-facing inventory of the AI systems an agency uses, carrying standardised information about each system's purpose, data inputs, decision scope, oversight mechanism, and equity performance. Several cities, counties and federal agencies now publish registries of this type, and the models are worth studying before designing one. New York City's Local Law 144 on automated employment decision tools established a disclosure model for employers. Amsterdam's Algorithm Register is among the most developed municipal registers in active operation.

The minimum viable registry contains five elements for each listed system: a plain-language description of what the system does, who is affected by the decisions it touches, what data it uses, what human oversight exists, and how the agency monitors for disparate impact. The fifth element is the one that does the work, because it is the only one that cannot be written from a design document. It requires that monitoring exist, and an agency filling in a registry template honestly will discover which of its systems have none.

Carmen's city launched a registry covering its twelve deployed AI systems within 90 days of the code enforcement incident. Each entry runs to two pages, one of public-facing plain language and one of technical documentation for researchers who want more detail, which is twenty-four pages in total for the whole municipal AI portfolio. That figure is worth holding onto when the objection to publishing is effort. The expensive part was never the writing. It was reconstructing, for each system, facts the agency had never written down.

What Publishing the Registry Produced

Three things followed within weeks, and only one of them is the sort of outcome usually promised. The neighborhood association filed a follow-up records request three weeks after the original one, and it was answered by directing them to the registry, which already contained what they were seeking. Two community organizations contacted the city to volunteer for an advisory panel on AI system monitoring, which is participation the city had not asked for and had no mechanism to absorb until it built one.

The third effect is the one that justifies the exercise. The registry template required bias audit results to be listed for every system, and the code enforcement system had never been audited. The gap was not created by the registry; it was made visible by it, because a blank field in a published template is a question that answers itself. The city identified and remediated it before it appeared in a records response or a news story. Design your template so that the fields you are most reluctant to leave blank are the ones you most need to fill.

The Disclosure Floor and the Disclosure Standard

The FOIA (Freedom of Information Act) and state-level public records laws create a disclosure floor: agencies must produce responsive records when asked, within whatever exemptions and procedures their own law provides, which is a question for counsel in every specific case. A proactive transparency registry creates something different, a disclosure standard, in which the agency decides what to publish and how to explain it rather than answering whatever question a records request happens to frame. The difference in outcome between the two postures is significant and frequently underestimated.

A records request produces raw documentation: vendor contracts, model specifications, technical reports. Most requesters cannot interpret those documents without expert assistance, so the narrative that forms around them is shaped by whoever interprets them first. An agency that has already published a clear, plain-language account of its systems has put its own interpretation into the record before that happens. Where a requester's documentation contradicts or adds to the published account, they have a real story, and the agency has just received an important piece of information about the gap between what it believes and what it can show.

Vendor Confidentiality and the Procurement Window

Vendor confidentiality clauses are the most common barrier to registry publication. Many AI vendor contracts restrict disclosure of model architecture, training data details, or performance metrics. The right default posture is to treat such clauses as negotiating points rather than as fixed terms, though it is worth testing case by case: a vendor may be constrained by third-party licences it does not control, and your counsel rather than your instinct should decide what is genuinely immovable.

The leverage is almost entirely in the procurement window. An agency that specifies transparency requirements in the RFP (Request for Proposal), stating that the selected vendor must support public disclosure of performance metrics and audit results, eliminates the barrier before a contract exists. That specification costs nothing at that stage and is priced into the bids. Retrofitting the same requirement onto a signed contract is harder but not impossible, and many vendors will agree to modified disclosure terms when the alternative on the table is non-renewal.

Annual Public Reporting on Performance

Transparency is not only disclosure at deployment. It is ongoing public accounting of how systems are performing once real people are subject to them. An annual public report covering performance metrics, bias audit results, error rates, override rates and any significant incidents is the mechanism that makes transparency durable rather than a one-time event. It also forces an annual internal deadline for producing numbers that would otherwise be produced only when someone asks.

Carmen's city published its first annual AI performance report 13 months after launching the registry, roughly sixteen months after the original records request. The code enforcement equity analysis was the headline finding: inspection rates in the lowest-income census tracts ran at 1.4 times the rate in comparable higher-income tracts with similar code violation prevalence, which is to say about forty percent higher. The city had not suppressed that finding earlier. It had not previously had the monitoring infrastructure to produce it, which is the same failure the original records request exposed, now finally closed.

The report created both the pressure to look and the mechanism to publish what was found, and then something happened, which is the part that matters. The city council voted to commission an independent audit of the code enforcement system and to add a human review step for all inspections in census tracts the model had historically over-selected. Both actions followed directly from the public report. A report that had produced no change would have been an elegantly formatted way of telling residents that the city knew and did nothing.

Building Institutional Trust Over Time

Trust in government AI is not built through a single disclosure or a single community meeting. It is built through consistent, honest and useful communication sustained across years, and each of those three adjectives has a failure mode attached. A registry published once and never updated erodes trust faster than no registry at all, because it converts a gap in information into a demonstrated gap in candour. Annual reports that surface only favourable findings read as promotional material the second time they appear. Community advisory panels with no influence over system design or monitoring are correctly perceived as theatre.

Genuine trust-building requires four things: information that is actually informative rather than merely technically compliant, a feedback mechanism that produces observable results, accountability when performance is inadequate, and continuity over time. The second and third are where most programs fail, because they require the agency to change something in response to input it did not choose. Carmen's city is now in its third year. Community organizations that were initially skeptical participate in the annual bias audit review, and two of them have independently proposed monitoring metrics the city adopted. Adopted is the operative word.

Anti-Patterns

• The register as discharge. An agency publishes an AI inventory and treats the listing as compliance, answering every challenge by pointing at the entry. A register entry shows a system was listed. It does not show the entry is current, that the described oversight ran, or that an unlisted system does not exist. Treat each entry as a claim your own auditors should test.
• The artifact as absolution. A model card, an impact assessment or a transparency report is evidence that an analysis was performed, not evidence that the system is fair, accurate or lawful. A completed checklist has never once made a false statement true. When the artifact and the system's actual behaviour diverge, the artifact is the thing that is wrong.
• Publishing to buy quiet. Treating disclosure as reputational insurance produces reports that omit the difficult findings, because those findings do not serve the purpose. An agency that publishes because people subject to an automated decision are owed an account will still publish the year the numbers are bad.
• Disclosure without instrumentation. Committing to publish equity performance for a system with no equity monitoring produces either a blank field or an invented one. Build the monitoring, or publish the blank and label it a gap with a remediation date. Do not describe an intention in the present tense.
• The registry that ages. An entry describing a system as it existed two versions ago is worse than no entry: it is a specific, checkable, false statement made in public by the agency. Tie registry updates to the change-control trigger that governs the system itself.
• The advisory panel with no authority. Convening community members with no mechanism for their input to change anything generates skepticism rather than trust, and burns the goodwill of the people you most need. Define what the panel can propose, what the agency must answer, and where the record of responses is published, before announcing it exists.
• Leaving transparency to the contract renewal. Confidentiality terms are cheapest to change before a contract exists. An RFP silent on public disclosure of performance metrics and audit results has conceded the point for the life of the agreement.

Practice Prompts

1. Draft a registry entry for one AI system your agency runs, using the five elements: plain-language description, who is affected, data used, human oversight, disparate impact monitoring. Note every field you could not complete from existing documentation and treat that list as the real finding.
2. Take the last records request your agency received about a technology system. Write the plain-language explanation you wish had already been published, then identify what would have had to exist for it to be true.
3. Review one active AI vendor contract for disclosure restrictions. Identify which are genuinely binding, which are negotiable at renewal, and which counsel thinks were never necessary. Draft the transparency clause for the next RFP.
4. Outline your agency's first annual AI performance report: which metrics, which systems, who produces each number, what the publication date is. Then identify the finding you would least want to publish, and write the paragraph about it.
5. If your agency has a community advisory body, trace one piece of input it gave through to an actual change or a documented refusal. If you cannot trace one, you have found the design problem.

Reflection

Take twenty minutes with these questions. If a records request for the decision criteria of your highest-impact AI system arrived this afternoon, what could you produce, and what would you discover you had never assembled? Which published claims about your AI systems would still be accurate if checked against those systems today? Where is a transparency artifact standing in for a control that does not exist?

Glossary

• AI transparency registry. A public-facing inventory of an agency's AI systems carrying standardised information on each system's purpose, data inputs, decision scope, oversight mechanism and equity performance.
• Disclosure floor. The minimum an agency must produce when asked, set by FOIA or the equivalent state public records law together with its exemptions and procedures.
• Disclosure standard. What an agency chooses to publish proactively and how it chooses to explain it, set by the agency rather than by whichever question a requester happened to ask.
• Override rate. How often a human decision-maker departs from a system's recommendation. A standard element of annual reporting, and a number that means little without knowing which direction the departures run.
• Disparate impact monitoring. Ongoing measurement of whether a system's outputs distribute differently across groups than comparable conditions predict. The registry element that cannot be written from a design document.

Related Lessons

• Public Reporting and Algorithmic Transparency goes deeper on the annual report and what belongs in it.
• Algorithmic Accountability Mechanisms covers the controls a transparency artifact describes rather than replaces.
• Transparency: Citizens' Right to Know is the foundational treatment of the obligation this lesson operationalises.
• Community Engagement in Government AI covers designing an advisory body with real authority before announcing it.
• Algorithmic Impact Assessments covers the assessment artifact and its limits as evidence.
• Building and Maintaining Public Trust extends the continuity argument beyond a single agency's disclosure program.
• Working with AI Vendors and Contractors covers the contracting posture that decides what you may publish later.

Closing

Carmen's city did not become trustworthy by publishing a registry. It became checkable, which is a smaller and more useful thing. The registry made the city's claims specific, the annual report made them testable, and the council's response to an unflattering finding made the whole apparatus worth reading. Trust followed from the third of those, not the first, and it took three years of consistent output rather than one well-designed document.

Build in that order and resist the temptation to skip to the artifact. Instrumentation, then disclosure, then a demonstrated willingness to act on what the disclosure shows. An agency that does the first and third can survive doing the second imperfectly. An agency that does only the second has published a claim it cannot support, in its own name, permanently.

Key Takeaways

• Publishing does not produce trust and does not discharge accountability. A registry entry, model card, impact assessment or annual report is a document. Whether trust follows depends on whether it is accurate, whether what it describes is defensible, and whether the agency acts when it says otherwise.
• A transparency gap is usually a monitoring gap. If you cannot answer a hard question about your own system, the obstacle is not disclosure policy but the instrumentation that was never built. Build it first.
• Proactive disclosure decides who explains the system first. That is the real effect and it is worth having. It does not reduce legitimate concerns, and where a real problem exists publication attracts more attention, not less. Publish anyway.
• Build the registry around five elements per system. Purpose, who is affected, data used, human oversight, disparate impact monitoring, in two pages of which one is plain language. Twelve systems came to twenty-four pages and ninety days.
• The blank field is the finding. A template that requires bias audit results for a system that has never been audited has just done its job. Design the template so the fields you least want to leave empty are the ones you most need to fill.
• Negotiate disclosure terms in the RFP. Requiring public disclosure of performance metrics and audit results costs nothing before a contract exists and is priced into the bids. Retrofitting is harder, though non-renewal is real leverage.
• Annual reporting only works if something can change. A finding of 1.4 times the inspection rate in the lowest-income tracts mattered because the council commissioned an audit and added human review. A report that changes nothing tells residents only that you knew.
• Trust is built through continuity, and each element has a failure mode. A registry never updated is worse than none, a report with only good news reads as promotion, an advisory panel without authority is theatre. Informative content, a feedback mechanism with observable results, accountability, and years.

Frequently Asked Questions

What if publishing the registry reveals a problem we have not fixed yet? That is the ordinary case rather than the exception, and it is survivable in a way that a later external discovery is not. Publish the entry with the gap named and a remediation date attached, and then meet the date. The failure that damages an agency is not the gap. It is a published claim that turns out to be false.

How much technical detail belongs in a public entry? Enough that a researcher can evaluate the claims and not so much that a general reader is defeated, which is why the two-page split works: one page of plain language, one of technical documentation. If you can only produce the technical page, you have not finished. The plain-language page is the one the neighborhood association reads.

Our vendor says the model is proprietary. Does that end the conversation? Not usually, and the distinction matters: disclosing performance metrics, audit results, decision scope and oversight arrangements is different from disclosing model architecture or training data. Most legitimate confidentiality interests attach to the second set. Ask counsel to separate the two before conceding the first.