Transparency you can actually use
Model cards tell developers how an AI model was built. People affected by an automated decision need something different: what data was used about them, the specific reason for the outcome, and how to appeal to a person.

Most AI transparency today is written for engineers: training data summaries, benchmark tables, architecture notes. All of it may be accurate and still tell a tenant, patient or job applicant nothing about why the system decided what it did about them, or what they can do about it.
The compliance checklist trap
When technology companies announce transparency initiatives, they usually publish developer-facing documentation. They release model cards listing parameter counts, training compute budgets, benchmark scores, and legal disclaimers.1
To an engineer training a model, those statistics feel thorough. But to a tenant denied an apartment lease, a patient questioning a clinic schedule, or a parent appealing a school placement, those disclosures are useless.
Recent empirical research confirms this divide. In a multi-stakeholder study of generative artificial intelligence systems, researchers measured the gap between what developers build and what users actually need.2 While over half of providers believed model cards provided adequate transparency, barely a quarter of everyday users agreed.
What this means
Developers focus on how an engine was built. Everyday people need to know what the machine decided about them, why it made that choice, and who can fix an error.
Accountability needs records written for the people living with the results: specific to the decision, and in plain language.
Four receipts communities should demand
What does useful transparency look like in everyday practice? It comes down to four basic receipts.
First, people need clear data boundaries. When an automated tool recommends an action, it should state plainly what records it accessed and what information was excluded. A job applicant deserves to know whether a screening filter looked only at their submitted resume, or scraped their public social media feed.
Second, people need grounded reasons. A decision receipt should explain the specific rule or criterion that triggered the result. Vague scores or statistical probabilities do not help an applicant understand their standing. Plain-language reasons turn opaque calculations into understandable claims.
Third, people need contestability routes. An automated system should never present itself as a closed loop. Every notice must name the human department or caseworker authorized to review the outcome, along with an explicit deadline for lodging an appeal.
Fourth, communities need collective audit receipts. Local clinics, tenant unions, and civic groups should be able to review aggregate decision summaries without exposing individual privacy. Public registries help communities detect systemic biases before individual harms compound.3
Honest limits
Transparency alone cannot fix an unfair policy. If an algorithm enforces an unjust regulation, explaining the mechanism clearly does not make the result acceptable.
However, useful receipts make hidden trade-offs visible. When people can see the exact criteria used by automated tools, they can challenge unfair assumptions in municipal meetings, union bargaining, and public consultations.
You can inspect community-tested audit templates and civil society action cards in our Shared Horizon library. Demanding accountability starts by asking for receipts that answer to people, rather than checklists that satisfy compliance auditors.
- M. Mitchell et al., “Model Cards for Model Reporting,” in Proceedings of the Conference on Fairness, Accountability, and Transparency (ACM FAT*, 2019), 220–229.
- J. Smith et al., “Whose Transparency is it Anyway? Understanding Generative AI Transparency Needs and Gaps Across Stakeholders,” arXiv preprint arXiv:2611.05549 (November 2026).
- J. Cobbe, M. S. A. Lee, and J. Singh, “Reviewable Automated Decision-Making: A Framework for Accountable Algorithmic Systems,” in Proceedings of the 2021 ACM FAccT Conference (2021), 232–242.


