Robert Chen, chief data officer for a large state government, had spent a decade championing open data, publishing public datasets so anyone could use them. He thought of himself as a transparency hardliner. Then his team built an internal AI tool to predict which restaurant inspections to prioritize, and an advocacy group filed a public-records request asking how it worked. Robert's instinct was to publish everything: the model, the data, the code. His general counsel stopped him. The training data, scraped from years of inspection records, contained the home addresses of food-service workers. Publishing the model could let bad actors game which restaurants got inspected. "I'd spent ten years saying open is always better," Robert said. "Suddenly I had to figure out what open should actually mean when the thing you're opening is an AI."

Open government is the principle that government should be transparent, participatory, and accountable to the public, and that its information and tools should be open by default. AI complicates this beautifully and dangerously. It runs on data that can be sensitive, makes decisions that affect people, and can be gamed if its workings are fully exposed. For a senior leader the question is no longer whether to be open but what responsible openness looks like for each part of an AI system, and what the law already requires regardless of preference. This lesson works through that answer layer by layer.

The Three Pillars, Applied to AI

American open-government policy has rested for years on three pillars set out in the 2009 Open Government Directive, catalogued as OMB Memorandum M-10-06: transparency, participation, and collaboration. Each maps onto the AI lifecycle, and each needs specific adaptation. The directive also established the posture that matters most for AI work, a presumption of openness, under which disclosure is the default and the burden falls on whoever argues for concealment. That default is why an agency that cannot explain why something is withheld has already lost the argument.

Transparency for AI means disclosing the existence of the system, the function it performs, the data it was trained on, the model architecture and evaluation results, the decision flows that rely on its output, and its performance in production. These are separate disclosure decisions, and each may be yes, no, or conditional. The voluntary AI Risk Management Framework published by the National Institute of Standards and Technology treats them that way in its governance guidance, which is a useful corrective to leaders who imagine one switch.

Participation means giving the public a structured opportunity to shape a system before deployment and while it operates, rather than a comment box after launch. Collaboration means treating outside expertise as an asset rather than a risk, and building the coordination structures that pool it. Both are constrained by law: participation cannot substitute for formal rulemaking where statutory due process applies, and collaboration cannot bypass the Federal Advisory Committee Act, which requires most standing outside-expert bodies to be chartered, balanced, and public. Experienced program managers design around these constraints instead of discovering them late.

Three Different Things People Call Open AI

Robert's confusion cleared once he realized that open was being used for three distinct things, each with different benefits and risks. A leader has to decide about each separately.

• Open data. Publishing the datasets government holds, so the public, researchers, and businesses can use them, including to build AI. The oldest and most established form of openness.
• Open models. Sharing the AI models themselves, their inner workings and weights, so others can inspect, reuse, or build on them.
• Open source. Publishing the code that runs an AI system, so others can verify, reuse, and improve it.

Robert's mistake was treating these as a single switch. His inspection tool involved all three, and each demanded a different decision. The data could not be published as it stood, because it held personal information. The model probably should not be public, because of gaming risk. The code, meaning the logic of how the pieces fit together, often could be, and publishing it would let outsiders verify the system without exposing what made it gameable. The right answer for one layer is routinely the wrong answer for another, which is why a single organizational policy on openness usually produces bad decisions in both directions.

The Inventory Is the Precondition for Everything Else

Before any of the layered judgments can be made, somebody has to know the systems exist. Federal policy now makes that concrete. OMB Memorandum M-24-10, issued in 2024, imposed four obligations that all rest on openness: each covered agency designates a chief AI officer; each publishes an annual AI use case inventory with expanded fields for rights-impacting and safety-impacting systems; each certifies minimum risk management practices for those flagged systems by a compliance date set in 2024; and each publishes an AI strategy covering governance, workforce, infrastructure, and public engagement. An undisclosed system cannot be inventoried, an inventory nobody can reach cannot be audited, and a certification nobody sees is a certification nobody trusts.

Every AI system operated by, on behalf of, or procured by a federal agency belongs in that inventory unless it falls within a national security exception or is a research-only system not used in operations. Every means every: commercial off-the-shelf assistants embedded in office software once they are configured for operational use, chatbots on agency websites, document classification tools running behind the firewall, and fraud scoring used by program integrity offices. That reading is deliberately expansive, and it is the right one, but expect it to be resisted by every team that thinks of its tool as a feature rather than a system.

Inventories are also incomplete in practice. Government Accountability Office reviews of federal AI inventories found systems missing at several large departments, and inspector general follow-up work closed many but not all of those gaps. The right response for a leader is not to treat publication as the finish line. It is to treat the inventory as a control that needs its own audit, with a named owner, a reconciliation against procurement records, and a rule that no rights-impacting or safety-impacting system goes live without an entry.

What an inventory buys is contestability. The Department of Homeland Security inventory discloses that Customs and Border Protection operates a traveler verification service using facial comparison, while withholding the vendor algorithm accuracy parameters, which the department redacts under the trade secrets exemption of the Freedom of Information Act. Whether that redaction is correct is genuinely contested, and civil liberties and privacy organizations have argued it is not. That argument is only possible because the inventory entry exists. Without the entry there is nothing to contest, and the absence of controversy gets mistaken for the absence of a problem.

Open Data: The Foundation, With Sharper Edges

Open government data is the raw material of public-interest AI and a genuine national asset. Federal releases such as decennial census microdata, open climate datasets from the ocean and atmospheric agency, the long-running satellite imagery archive maintained by the geological survey, the open-access subset of the national medical literature database, crop data layers from the agriculture department, and the labor department's population survey all provide training material that lets outside researchers replicate and check federal models. That external replication is the mechanism by which errors get found. When rules and reference data are published, university research labs can build shadow models and identify systematic disparities in how a program is administered, years before an audit or a lawsuit would have surfaced them.

But AI changes the risk math of publishing. Two datasets that are each harmless alone can, when combined by a capable model, re-identify individuals, a risk that was theoretical when data sat in spreadsheets and is real when systems can cross-reference at scale. Robert's new standard for open data was not publish less. It was publish with the re-identification risk assessed. His team began applying disclosure-protection techniques, removing or coarsening identifying fields, before release, and assessing what a dataset could reveal in combination with other public sources. The census disclosure-avoidance work for the 2020 count is the most heavily documented example of that tradeoff being made explicitly, and it was contested precisely because it was documented.

Where data cannot lawfully be released at all, the answer is still not silence. Publish a dataset card describing what the data contains, how it was collected, which groups are represented, and what preprocessing was applied. Federal biomedical AI programs publish dataset cards even where the underlying records are restricted to credentialed researchers. A description of restricted data is not a substitute for the data, and it should never be presented as one, but it lets outsiders reason about what a model learned and ask sharper questions than they otherwise could.

The Documentation Artifacts and What They Do Not Do

For any rights-impacting or safety-impacting system, three artifacts do most of the work. A model card, following the widely adopted 2019 framework proposed by Mitchell and colleagues, describes intended use, training data, evaluation metrics, limitations, and fairness considerations. A privacy impact assessment is required under Section 208 of the E-Government Act of 2002. A system of records notice is required under the Privacy Act of 1974 where the system holds records retrievable by personal identifier. Federal examples exist and are usable as templates, including patent classification model cards published by the trademark and patent office, model cards for medical literature retrieval, and a sanctions screening system card from the treasury department.

Where publishing a full model card would disclose sensitive training data, the card can be redacted at the dataset-description level while preserving the evaluation and limitations sections. That is a far better outcome than withholding the card, because the evaluation and limitations sections are the parts an outside reader actually needs to judge whether the system is fit for its use.

What none of these artifacts do is discharge the obligation they document. A published model card is a description of a system, not evidence that the system is sound, and a program that has produced all three artifacts can still be inaccurate, biased, or wrong for its population. The artifact makes the problem findable. Someone still has to look, and someone has to have the authority to stop the system when they find something. Treat documentation as the precondition for accountability rather than the delivery of it.

The Limits: What Must, May, and Must Not Be Released

The presumption of openness is a default, not an override, and the constraints on it are statutory. An agency that treats them casually will either break the law or, more commonly, over-withhold out of caution and destroy the credibility of everything it does publish. The categories below are the ones that recur in AI disclosure decisions.

Two disciplines make this workable. First, decide at the level of the specific field rather than the document, because an exemption that covers a vendor accuracy parameter almost never covers the system's purpose, its category, or its appeal route. Second, disclose that you are withholding and on what basis. A redaction with a stated ground invites a legitimate argument. A silent omission invites the assumption that something worse is being hidden, and that assumption is usually the one that ends up in the newspaper.

Transparency About Governance, Not Just Ingredients

Robert's most important realization was that the advocacy group did not really want his model weights. They wanted to know they could trust the system. That is a different and more achievable kind of openness: transparency about governance. Even when the model itself must stay closed, an agency can be entirely open about how the system is governed, and that is often what the public actually needs.

For the inspection tool, Robert published a plain-language description of what the system does and does not do, the categories of data it uses, the testing it underwent including whether it was checked for bias against neighborhoods or business types, the human oversight in place, and how a restaurant owner could question a decision. He published none of the gameable internals. The advocacy group withdrew its objection, not because they could read the code, but because they could see who was accountable and how a decision could be challenged.

Be precise about what that achieved. Publishing governance information removed a specific reason to distrust the system; it did not by itself create trust, and it did not establish that the system was accurate. Trust followed later, and only because the appeal route Robert published turned out to work when people used it. Transparency is a means to accountability, and accountability requires someone with the authority to act on what the disclosure reveals. An agency that publishes thoroughly and cannot change anything in response has built a very well-documented failure.

The Layered Disclosure Decision Framework

Robert turned his ordeal into a framework his agency now runs on every AI system before deciding what to open. It treats each layer separately and defaults to openness unless a specific, named risk justifies holding back.

1. Existence. Is the system in the public inventory? This layer has essentially no exceptions outside the national security carve-out, and it is the one that determines whether anything else can be scrutinized at all.
2. Purpose and population. What decision does it support, and whom does it affect? This drives the rights-impacting and safety-impacting flags, which in turn determine which practices and which additional publication duties apply.
3. Data layer. Can the training and reference data be opened safely? Assess privacy and re-identification risk, including in combination with other public data. If not fully, can a protected or aggregated version, or at minimum a dataset card, be released?
4. Model layer. Would opening the model enable gaming, evasion, or misuse that outweighs the inspection benefit? If yes, keep it closed, document why, and publish the fact of the decision.
5. Code layer. Can the code be open-sourced to let others verify and reuse it without exposing what makes the system gameable? Often yes, and this is the layer most often closed by habit rather than analysis.
6. Governance layer. Regardless of the above, what can be published about purpose, data categories, testing, bias checks, human oversight, and appeal rights? This should default to maximally open.
7. Statutory limits. Which specific exemption, statute, or control applies to which specific field, and is the ground stated publicly?
8. Venue and cadence. Where does each artifact go and how often is it refreshed? Inventories, dataset publications, code releases, and model documentation each have their own home and their own change log.
9. Response protocol. Is there a named point of contact, a public comment mechanism, and a documented process for acting on what comes back?
10. Named owner. Who is accountable for each openness decision, and is the reasoning recorded so it can be revisited when circumstances change?

Participation and Collaboration in Practice

Participation has formal and informal channels, and confusing them is a legal risk. Where an AI system implements or affects a rule, notice-and-comment rulemaking under the Administrative Procedure Act is the channel, and no amount of listening sessions substitutes for it. Where no rule is involved, agencies have used requests for information on AI priorities, prize competitions run through the federal challenge platform, advisory panel review of AI-assisted casework, and public listening sessions on clinical decision support. An environmental justice screening tool went through three rounds of public comment before release, which is an unusually strong example of participation shaping a system rather than ratifying it.

Collaboration means building structures that pool outside expertise without pretending government is the sole source of it. Federal biomedical AI programs use cooperative agreements to build datasets jointly with academic consortia. The defense department's joint AI center, renamed the Chief Digital and Artificial Intelligence Office in 2022, works with university software engineering institutes, adversarial threat knowledge bases, and industry partners. Health AI coordination runs through multi-stakeholder coalitions. Councils of chief data officers, chief information officers, and chief AI officers exist to move practice between agencies rather than reinvent it in each.

The constraint to design around is the Federal Advisory Committee Act. A standing body of outside experts advising a federal agency generally has to be chartered, balanced in viewpoint, and open to the public. Agencies that want structured outside input should use a chartered committee deliberately rather than assembling an informal group and discovering the requirement afterward, which is a slow and public way to learn a rule.

Case Studies: What Goes Wrong, and What Goes Right

The federal identity verification episode is the canonical negative case. In 2021 the tax agency contracted with a private identity provider to require taxpayers accessing online services to authenticate through facial recognition and selfie verification. The arrangement was disclosed only in narrow procurement notices. When journalists reported the change in early 2022, the backlash was immediate and a bipartisan congressional response followed. Within weeks the agency announced that taxpayers could opt out of face capture and interact with a live agent instead. An inspector general review later found the agency had not completed a privacy impact assessment consistent with the E-Government Act before deploying the change.

The lesson usually drawn is that transparency delayed is trust destroyed, and that is right as far as it goes. Be careful with the counterfactual, though. A published use case, a public privacy impact assessment, and a comment window would have created a channel for those concerns during design rather than after launch. They would not have guaranteed that anyone raised them. Openness improves the odds that a problem surfaces early; it does not manufacture the attention that finds it.

The state counterpart is the Michigan Integrated Data Automated System. Between 2013 and 2015 the state's unemployment insurance agency used it to auto-adjudicate fraud allegations against claimants, with a false-positive rate exceeding 90 percent and thousands of wrongful determinations. The state published no documentation of the algorithm, did not let claimants see the evidence against them in a timely way, and did not keep an audit trail sufficient to reconstruct decisions. Civil rights claims reached the Sixth Circuit in Cahoo v. SAS Analytics, and the settlement exceeded $20 million. Rights-impacting automated decision systems without published logic and without human review are legally and politically unsustainable.

The Dutch childcare benefits scandal made the same point in Europe. Between 2013 and 2019 the Dutch tax administration used a risk classification that included a nationality variable to flag childcare benefit claims as potentially fraudulent. Tens of thousands of families were falsely accused, forced to repay benefits, and in some cases lost custody of children. A parliamentary inquiry in 2020 was followed by the resignation of the government in January 2021. The Dutch data protection authority fined the tax administration 2.75 million euros, and the case was cited during European AI Act negotiations as evidence that public-sector automated decision systems require mandatory transparency, human oversight, and redress.

Positive cases exist and are less discussed. The patent and trademark office released model cards for its patent classification AI in 2020 and has iterated them with user feedback. The national medical library publishes evaluation datasets and baseline results for its retrieval stack. The census bureau's disclosure-avoidance work for the 2020 count, however contested, was documented in peer-reviewed publications and public workshops. Each of these programs was criticized, and the criticism sharpened them rather than destroying them, precisely because they were open enough to absorb feedback without collapsing. Documentation did not protect them from criticism. It moved the debate from why are you hiding this to how can we improve this, which is the only debate governance can win.

What Other Governments Have Set as the Floor

The international comparison sharpens the case, because first movers set defaults and defaults become floors. The European Union AI Act, which entered into force in 2024, requires providers of high-risk systems to register them in a public database. The AI Principles of the Organization for Economic Co-operation and Development, adopted in 2019 and updated in 2024, list transparency as one of five values-based principles; they are non-binding recommendations, which is exactly why they diffuse so widely. The United Kingdom operates an algorithmic transparency recording standard under which public-sector algorithms are disclosed through a plain-language summary record and a fuller technical record.

That last standard is described in the source material as requiring every public-sector algorithm to be disclosed. Read as written, that is broader than most disclosure regimes anywhere, and it errs on the side of more disclosure rather than less, so it is worth carrying at face value and treating as the benchmark to argue against rather than quietly softening. Confirm the current scope, the responsible department, and the mandatory or voluntary status before citing it in a brief, because the office that originally operated it has been reorganized.

Open Source and the Public Commons

Robert's last shift was from defense to offense. Openness is not only about how much of his own systems to expose; it is about what government can contribute to and draw from a shared public commons. When one government builds and open-sources a well-governed AI tool, a benefits eligibility checker or a translation system for public services, others can reuse it instead of rebuilding it, and the public can inspect it.

Federal practice supports this. The 2016 federal source code policy, catalogued as OMB Memorandum M-16-21, set a pilot requirement that agencies release at least 20 percent of new custom-developed code as open source; treat that as the historical baseline and confirm the current policy before citing it as a live obligation. Works of the United States government are not subject to domestic copyright under Title 17, Section 105, which is why federal releases commonly carry a public-domain dedication. Concrete releases include the public beta code for the tax agency's direct filing service in 2024, open Earth-observation tooling published under the space agency's open science policy, and the static site and identity service components released by federal digital service teams, whose organizational homes have since changed and which are best described historically.

The economics are usually stated too strongly, and it is worth being precise. Building twenty agency-specific document summarizers costs closer to twenty times what building one and sharing it costs than it does to one times. That arithmetic holds as an upper bound and the inputs are simple enough to check. What it omits is that reuse is never free: each adopting agency still pays for integration, authorization, accessibility, security review, and operation. The honest claim is that sharing removes duplicated build cost, not that it removes cost. Leaders who promise the stronger version lose credibility the first time an adopting agency's bill arrives.

Robert began contributing his agency's reusable, non-sensitive AI components back and adopting others', which cut cost and raised quality across governments. The same principle that made open data valuable, that public information compounds when shared, applies to public AI. A leader who understands this stops asking only what must we disclose and starts asking what we can build in the open that makes the whole public sector better.

An Implementation Sequence for Your Agency

The sequence below assembles the obligations above into an order a program can actually execute. It is deliberately front-loaded, because the first two steps determine whether any of the later ones are possible.

1. Inventory. Within 30 days, convene your chief AI officer, chief data officer, senior agency official for privacy, and general counsel to list every AI system in use, under development, or under contract. Use the government-wide inventory template rather than an agency variant, map each system to the rights-impacting and safety-impacting flags, and publish.
2. Documentation. For every flagged system, produce a model card, a privacy impact assessment, and a system of records notice where the Privacy Act applies. Publish them, redacting at field level with stated grounds where necessary.
3. Data. Publish training data where lawfully releasable through the federal open data catalog. Where it is not releasable, publish a dataset card instead.
4. Code. Release evaluation harnesses, preprocessing pipelines, and non-sensitive model code through the federal code catalog or a public repository with an explicit license.
5. Participation. Use notice-and-comment where a rule is affected, and structured channels where it is not. Track comment volume and, more importantly, what changed as a result.
6. Collaboration. Join the interagency councils and domain coalitions that already exist, and use a chartered advisory committee where standing outside expertise is needed.
7. Monitoring. Publish production performance for flagged systems, including error rate trends, incident reports, and subgroup accuracy where that can be done defensibly. A long-running consumer complaint database run by a federal financial regulator is the standard example of a public dashboard that is both operationally useful and trust-building.
8. Review. Fold AI transparency into your existing annual security reporting, evidence-building learning agenda, audit responses, and inspector general coordination, so that openness stops being a separate program and becomes the agency's default operating posture.

Anti-Patterns to Avoid

• The register as discharge. Treating an inventory entry as the completion of an obligation rather than the start of one. A published entry makes a system contestable; it does not make it lawful, accurate, or fair. Agencies that celebrate inventory completeness while never revisiting an entry have automated the appearance of accountability.
• The artifact as absolution. Producing a model card, a privacy impact assessment, and a dataset card, then treating the system as cleared. Each artifact documents a claim; none of them tests it. A completed checklist has never once made a false statement true.
• Open as a single switch. Applying one organizational policy to data, models, and code together, which produces reckless exposure on one layer and needless secrecy on another. Decide each layer separately, with a named owner and recorded reasoning.
• Over-withholding out of caution. Redacting the whole document because one field is exempt. Field-level decisions with stated grounds preserve both the protection and the credibility of everything else you publish.
• Silent omission. Withholding without saying you are withholding or why. A stated exemption invites a legitimate argument; an unexplained gap invites the assumption that something worse is hidden.
• Publishing without a path to act. Standing up disclosure machinery with no appeal route, no named contact, and no authority to stop a system. That produces a very well-documented failure rather than an accountable one.
• Participation after the fact. Opening a comment window once the system is procured, built, and scheduled. Comment that cannot change anything is consultation theater, and the public recognizes it faster than agencies expect.
• Transparency as a communications function. Routing disclosure decisions through the press office, so the operative criterion becomes reputational exposure rather than a stated legal ground. The test drifts from what may we lawfully withhold to what will look bad, and those two questions produce opposite answers surprisingly often. Keep the legal determination with counsel and the privacy official, and let communications decide how it is explained rather than whether it happens.
• Promising that reuse is free. Selling shared open-source tooling as pure savings when each adopting agency still pays for integration, authorization, and operation. Overstating the saving costs you the argument the first time a bill arrives.

Practice Prompts

1. Reconcile your AI inventory against your procurement records and your identity or cloud access logs. List every system you find that is not in the inventory, and for each one, name the person who decided it did not count.
2. Take one rights-impacting system and run it through the layered disclosure framework end to end. Produce a one-page decision record naming, for each layer, what is published, what is withheld, on what stated ground, and who owns the decision.
3. Write the governance disclosure for a system whose model must stay closed: purpose, data categories, testing performed including bias checks, human oversight, appeal route, and contact. Show it to someone outside your agency and ask what they still cannot tell.
4. Pick a dataset you decided not to publish. Write the dataset card you could publish instead, and identify what a researcher could and could not reason about from it.
5. Audit your recent public comment processes. For each, state what changed in the system as a result. If nothing changed in any of them, you have a participation problem rather than a publication problem.

Reflection

• If a reporter asked today which AI systems your agency operates that affect people's rights, how long would it take to answer, and how confident would you be in the answer?
• Which of your withholding decisions have a written, stated legal ground, and which are habit?
• When your agency publishes something uncomfortable, who has the authority to change the system in response, and have they ever used it?
• Where does your openness posture protect the agency's reputation rather than the public's interest, and would you be able to tell the difference from inside?
• What have you built that another government could reuse, and what have you rebuilt that already existed somewhere else?
• Who currently decides what your agency publishes about an AI system, and is that decision made on a legal ground or on how it is expected to read?

Glossary

• Presumption of openness. The default established by federal open-government policy that information is disclosed unless a specific ground for withholding applies, placing the burden on whoever argues for concealment.
• AI use case inventory. The public list of AI systems an agency operates, procures, or has under development, with fields including purpose, stage, and rights-impacting or safety-impacting status.
• Rights-impacting and safety-impacting. Federal flags marking systems whose outputs affect legal rights, benefits, or access to services, or whose failure could affect physical safety; the flags determine which practices and publication duties apply.
• Model card. A structured document describing a model's intended use, training data, evaluation metrics, limitations, and fairness considerations.
• Dataset card. A structured description of a dataset's contents, collection method, represented groups, and preprocessing, publishable even when the underlying data is restricted.
• Privacy impact assessment. The assessment required under Section 208 of the E-Government Act of 2002 before deploying a system that collects or uses personal information.
• System of records notice. The public notice required under the Privacy Act of 1974 when an agency maintains records retrievable by personal identifier.
• Re-identification risk. The chance that individuals can be identified from data believed to be de-identified, typically by combining it with other available data.
• Federal Advisory Committee Act. The statute requiring most standing bodies of outside experts advising a federal agency to be formally chartered, balanced in viewpoint, and open to the public.
• Disclosure avoidance. Techniques such as suppression, coarsening, aggregation, and noise addition applied before publication to limit what can be inferred about individuals.

Related Lessons

• Public Reporting and Algorithmic Transparency covers the reporting instruments, the public register, and the dashboards that carry what this lesson decides to disclose.
• Transparency: Citizens' Right to Know approaches the same duty from the citizen's side.
• Building Trust Through Transparency takes up the trust dynamics that disclosure supports but does not by itself produce.
• Data Governance for AI and Data Sharing Agreements for AI cover the upstream controls that determine what can lawfully be opened.
• Algorithmic Accountability Mechanisms supplies the machinery that turns disclosure into consequence.
• Public Consultation on AI Policy and Community Engagement in Government AI develop the participation pillar in depth.
• Ethics Boards and Advisory Structures covers the chartered bodies through which structured outside expertise is brought in.
• Oversight Mechanisms: IG, GAO, Congress and International Standards: EU AI Act and OECD place this work inside its oversight and international context.

Closing

Robert did not become less of a transparency hardliner. He became a more precise one. The decade he spent arguing that open is always better had trained him to answer a question nobody was asking, because the real question was never whether to be open but which layer, to whom, on what stated ground, and with whose name on the decision. That precision is what lets an agency publish the things that matter while defending the few things it withholds, and it is the difference between an open-government posture that survives its first mistake and one that collapses at the first records request nobody prepared for.

Key Takeaways

• Open is three decisions, not one. Open data, open models, and open source carry different benefits and risks; decide about your data, your model, and your code separately, with a named owner for each.
• The inventory is the precondition. Nothing else can be scrutinized, audited, or contested until the existence of a system is public, and every means every, including commercial tools configured for operational use.
• Documentation makes problems findable, not solved. A model card, a privacy impact assessment, and a records notice document claims; they do not test them, and a completed checklist has never made a false statement true.
• AI changes the risk math of open data. Datasets harmless alone can re-identify people when combined at scale, so publish with re-identification risk assessed and use dataset cards where data cannot be released.
• Know the statutory limits at field level. FOIA exemptions, the Privacy Act, the CUI framework, and export controls constrain disclosure; decide field by field and always state the ground for withholding.
• Governance transparency is often what the public wants. Publishing purpose, data categories, testing, oversight, and appeal rights removes a reason to distrust a system without exposing gameable internals.
• Disclosure needs somewhere to land. Accountability requires a named contact, a working appeal route, and someone with authority to stop a system; publishing without that produces a documented failure.
• Build in the open, but price it honestly. Sharing removes duplicated build cost across governments; it does not remove integration, authorization, and operating cost, and overstating the saving costs you the argument.

Frequently Asked Questions

Does publishing an AI use case inventory satisfy our transparency obligations?

No. The inventory is the precondition for accountability, not its delivery. It makes a system contestable by telling the public it exists, which is why the entry matters so much, but it says nothing about whether the system is accurate, lawful, or fair. Agencies that treat inventory completeness as the finish line tend to have entries that were written once at launch and never revisited, which is worse than a shorter, current list.

Our model would be gamed if we published it. Does that end the conversation?

It ends the conversation about the model layer only. Gaming risk is a legitimate ground for keeping model internals and specific thresholds closed, and it should be documented as a decision rather than assumed. It has no bearing on whether you publish the system's existence, its purpose, the categories of data it uses, the testing it underwent, who oversees it, and how someone contests a decision. Those are a different layer and they are usually what the public was asking for.

How do we handle training data that cannot lawfully be released?

Publish a dataset card describing what the data contains, how it was collected, which groups are represented, and what preprocessing was applied. Federal biomedical AI programs do exactly this for data restricted to credentialed researchers. Be clear that the card is a description and not a substitute for the data, and never present it as enabling the same external verification that release would allow.

Where does the Privacy Act fit relative to FOIA?

They are separate regimes and both apply. FOIA governs what must be disclosed on request, subject to its exemptions. The Privacy Act governs how an agency may maintain, use, and disclose records retrievable by personal identifier, and it imposes its own notice duties independent of whether anyone files a request. An AI system trained on or querying such records raises Privacy Act questions at design time, long before a records request arrives, and a privacy impact assessment under the E-Government Act is the usual place those questions get answered.

Is open-sourcing government AI tooling actually cheaper?

It removes duplicated build cost, which is genuine and large when many agencies need the same capability. It does not remove integration, authorization, accessibility, security review, or operating cost for each adopting agency. Make the narrower claim, because it is defensible and the broader one collapses the first time an adopting agency reports what reuse actually cost it.

Does a commercial tool we already license count as an AI system we have to disclose?

If it is configured for operational use, yes. The expansive reading is the correct one: assistants embedded in office software, website chatbots, document classifiers running behind the firewall, and vendor scoring used by program integrity offices all belong in the inventory once they are doing work. Teams resist this because they think of the capability as a feature of a product they already bought rather than a system they deployed. The useful question is not who built it but whether its output influences a decision about a person.

What single change most improves an agency's open-government posture on AI?

Make an inventory entry a gate in the deployment process, owned by whoever chairs your AI governance body, so that no rights-impacting or safety-impacting system can go live without one. It is a procedural change rather than a technical one, it costs almost nothing, and it converts openness from a reporting exercise done once a year into a control that operates at the moment systems are actually launched.