October 07, 2026
A transparency report is the least glamorous document your company will publish, and one of the most useful. It answers the questions customers, procurement teams and investors ask anyway: what the system does, where it fails, whose data shaped it, and who is accountable when something goes wrong. You do not need a legal department or a design agency. You need a fixed structure, a few honest paragraphs, and the discipline to keep it current.
Decide Who You Are Writing For
Pick one primary reader and write for them. A hospital procurement officer, a fintech risk lead and a developer testing your API want different levels of detail. Choose the one whose signature you need, then serve everyone else with structure: a two-page summary at the top covering the six points below, and longer appendices underneath for people who want methodology.
Publish it at a stable URL, date every version, and keep older versions accessible. A report whose wording quietly changes without a changelog reads as marketing. A report with a visible revision history reads as engineering.
A Section-by-Section Template
Six sections cover what most readers need. Adjust the depth, not the order.
1. System overview and intended use
One paragraph, plain language: what the system is, who uses it, and what it is explicitly not for. Name the version and the date this report describes, since behaviour changes between releases. Keep the sales team out of this section. Readers judge the whole document by whether the first paragraph sounds like a person telling the truth.
2. Capabilities and limitations
Two lists, not one paragraph. Under capabilities, describe tasks you have tested and how you tested them. Under limitations, be blunt:
- Handles English support tickets well; accuracy drops on code-switched or heavily abbreviated messages.
- Cannot check facts against live sources, and will occasionally state wrong dates with confidence.
- Not evaluated for hiring, credit, medical or legal decisions, and should not be used for them.
Three specific limitations are worth more than a page of hedging.
3. Training data and provenance
Describe data categories rather than dumping a list: licensed corpora, public web data, customer-supplied content, synthetic examples. State whether customer data is used for training, how long it is retained, and how a customer can opt out. If a licence prevents you from naming a source, say that plainly and describe the obligations you are bound by. Vague claims age badly; precise ones survive an audit.
4. Human oversight
Explain who reviews outputs, at which step, and what authority they hold. Name the role rather than the person, describe how a user reaches a human, and give the expected response time. Oversight described only as "a human is always in the loop" tells a reader nothing they can verify.
5. Evaluation and monitoring
Summarise how you test before release and what you watch afterwards: error rates on a fixed evaluation set, user-reported problems, drift in input patterns. Describe how incidents are logged, what you commit to disclosing, and to whom.
6. Change log and contact
Dated entries for each meaningful update, plus an address a person actually monitors. A contact form that routes into an unowned ticket queue is worse than a plain email alias.
Describe Behaviour, Not Intentions
Use verbs that match what you can demonstrate. Systems summarise, draft, rank and retrieve; they do not understand, know or decide. The second set invites arguments you will lose, and it hides the failure modes you most need to disclose. When a limitation is unknown, say it is unknown and say when you expect an answer. That single sentence buys more credibility than a confident claim you cannot support.
If your product touches employment, credit, health, housing or education, disclosure duties may be stricter than a voluntary report and will vary by jurisdiction. Treat this structure as a starting point and confirm your specific obligations with qualified counsel.
Turn Oversight Claims Into Evidence
A statement like "outputs are reviewed by trained staff" raises three questions: how many, how often, and with what power. Answer them. If reviewers sample ten percent of outputs, say ten percent and explain how the sample is drawn. If they cannot override a system's recommendation, say that too. Log overrides and escalation rates; those numbers are the evidence that oversight is real rather than nominal, and they are useful to you long before any regulator asks for them.
A Pre-Publish Checklist
- One named owner for the document, and a review date on the cover.
- Every claim traceable to a test, a log or a policy you can point to.
- The limitations list at least as long as the capabilities list.
- No superlatives, benchmarks or comparisons you cannot source.
- A plain-language summary that fits on two screens.
- A contact route that reaches a human within the stated time.
- A revision history, published alongside the current version.
Keep It Alive
A transparency report is a practice, not a launch deliverable. Put a review on the calendar each quarter and after every major release, log what changed, and treat every gap you had to write around as a roadmap item. The first version will be thinner than you would like. Publish it anyway, fix it in public, and the document becomes something rarer than marketing: a record of how your team actually behaves.
Photo: Tiger Lily / Pexels
