AI transparency statement template: what to document

Short answer: An AI transparency statement documents what AI systems you use, what they do, how they make decisions, and what safeguards are in place. Under Article 50 of the EU AI Act (Regulation (EU) 2024/1689), deployers must disclose high-risk AI to end-users before 2 August 2026; providers of general-purpose AI models must publish a training-data summary.

An AI transparency statement template is a structured format for documenting AI system disclosures—what the system does, how it processes data, what decisions it makes, and what safeguards or limitations apply. The structure and audience depend on your role: whether you build AI (provider), use AI in a product or service (deployer), or both. For teams shipping AI features to EU users, transparency statements are not optional—they are a regulatory obligation under Article 50 of the EU AI Act, which applies from 2 August 2026.

This article walks you through what a transparency statement must cover, who must publish one, how to audit your AI systems, and how to structure disclosures so they meet both legal requirements and user expectations.

What is an AI transparency statement and who needs one?

Why transparency statements matter

An AI transparency statement serves two purposes: it tells users and regulators what AI is being used and how it works, and it creates an audit trail that shows your organization took disclosure seriously.

When a user interacts with AI—whether it ranks search results, flags content as risky, or makes a credit decision—they have a right to know that AI is involved. Transparency statements explain the "what" (which AI system), the "why" (what problem it solves), the "how" (what data it uses, how it makes decisions), and the "so what" (what limitations or risks exist). Without this information, users cannot understand how a system might affect them or challenge its output if it goes wrong.

Transparency statements also reduce organizational risk. They demonstrate that you have audited your AI systems, classified them by risk and role, and taken deliberate steps to disclose what you know about them. In the event of a regulatory inquiry or audit, a well-maintained statement and evidence log show that you acted in good faith.

Who is required to publish one (and who isn't)

The obligation to publish a transparency statement depends on your role under the EU AI Act.

Deployers of high-risk AI systems must disclose to end-users that they are using AI and provide information about the system's purpose, performance, and limitations. This applies if you use a high-risk AI system (defined in Annex III of the AI Act) in your product or service. The disclosure must reach the people affected by the AI system.

Providers of general-purpose AI models must publish a summary of the training data used to build the model. This applies if you train and release an AI model (or fine-tune an existing model and release it as your own product).

Internal use only: If you use AI internally—for example, to automate your own content moderation or to screen job applications—you still have obligations to your employees and users, but the form and audience differ. Internal AI use is not exempt from transparency; it is subject to different disclosure channels (internal documentation, employee notification, privacy policies).

Regulatory vs. voluntary transparency

The EU AI Act imposes binding disclosure obligations on deployers and providers under Article 50. These are not optional.

Beyond the regulation, many organizations publish transparency statements as a matter of governance and user trust. A transparency statement can cover:

• AI systems that fall outside the scope of Article 50 (low-risk or non-high-risk systems).
• Internal AI use and decision-making processes.
• Performance metrics, fairness audits, and risk assessments.
• Roadmap and plans for improving AI systems. (chatbot disclosure requirements)

Voluntary transparency often goes further than the regulation requires. However, the minimum floor is set by Article 50: if you deploy high-risk AI in the EU, you must disclose it to end-users before 2 August 2026.

Understanding your role: provider vs. deployer

What makes you a provider

A provider is an organization that builds, trains, fine-tunes, or releases an AI system or model for use by others.

Examples:

• A company that trains and releases a large language model (LLM) for public or commercial use.
• A team that fine-tunes an open-source model (e.g., Llama, Mistral) and releases it under a new name or as a commercial product.
• A SaaS company that builds a proprietary AI model and sells access to it via an API.
• A company that develops a specialized AI system (e.g., a medical imaging classifier) and licenses it to hospitals.

Providers must disclose training-data summaries for general-purpose AI models. The European Commission has published a template for this purpose. Providers also have obligations around documentation, risk management, and model cards.

What makes you a deployer

A deployer is an organization that uses an AI system in a product, service, or workflow to serve end-users or make decisions that affect them.

Examples:

• A SaaS company that integrates a third-party AI model (e.g., OpenAI's GPT-4, Anthropic's Claude) into its product and exposes it to users.
• An e-commerce platform that uses an AI recommendation engine to rank products for shoppers.
• A bank that uses an AI system to assess creditworthiness or detect fraud.
• A content moderation team that uses an AI classifier to flag harmful content before human review.
• A recruiting platform that uses an AI system to screen job applications.

Deployers must disclose to end-users that a high-risk AI system is in use and provide information about its purpose, performance, and limitations. The disclosure must be accessible to the people affected by the AI system.

When you are both

Many organizations are both providers and deployers.

Example: A SaaS company builds a proprietary AI model for customer-support automation and sells it as a service to other businesses. The company is a provider because it builds and releases the model. The company is also a deployer because it uses the model in its own product to serve its own customers.

When you are both, you have both sets of obligations:

• As a provider, you must publish a training-data summary for your model.
• As a deployer, you must disclose to your end-users that you use AI and provide information about the system's purpose and limitations.

How role affects disclosure scope

Your role determines what you must disclose and to whom.

If you are unsure of your role, ask: *Does my organization build or train AI systems that others use?* (Provider) *Does my organization use AI systems in a product or service that affects end-users?* (Deployer)

What must a transparency statement include?

System purpose and use case

Start by describing what the AI system is for and what problem it solves.

A transparency statement should answer:

• What is the name or identifier of the AI system?
• What is its primary purpose? (e.g., "to rank job applications by predicted fit", "to flag content that violates community standards", "to recommend products based on browsing history")
• In what context does it operate? (e.g., "during the initial screening phase of hiring", "before human moderation review", "on the product recommendation page")
• Who built or trained it? (your organization, a third-party vendor, or a combination)

Example: *"We use an AI system called JobScreen to rank job applications by predicted fit for the role. JobScreen is trained and maintained by TalentAI Inc. It is used during the initial screening phase to help our recruiting team prioritize applications for human review."*

Data inputs and processing scope

Describe what data the AI system receives, how it processes it, and what it outputs.

A transparency statement should answer:

• What data does the system take as input? (e.g., resume text, job description, candidate demographics)
• How is that data processed? (e.g., tokenized, embedded, scored)
• What is the output? (e.g., a ranking score, a category label, a recommendation)
• Is any personal data processed? (If yes, your privacy policy should cover this in detail.)
• How long is data retained?

Example: *"JobScreen receives the candidate's resume text and the job description as input. It tokenizes the text, compares semantic similarity, and outputs a score from 0 to 100. The system does not process demographic data. Input data is deleted after 30 days."*

Decision-making scope and human review

Clarify what decisions the AI system makes and what role humans play.

A transparency statement should answer:

• Does the system make a final decision, or does it inform a human decision? (e.g., "the system ranks candidates; a human recruiter makes the final hiring decision")
• Can the system's output be overridden or challenged? (e.g., "yes, recruiters can manually adjust rankings or reject the system's recommendation")
• Is there a human review step before the decision is communicated to the user? (e.g., "yes, a hiring manager reviews the top 10 candidates before sending offer letters")
• What is the escalation path if a user disagrees with the system's output?

Example: *"JobScreen ranks candidates, but does not make hiring decisions. A human recruiter reviews the ranked list and decides which candidates to interview. Recruiters can override the ranking at any time. If a candidate believes the ranking was unfair, they can contact our recruiting team to request a manual review."*

Known limitations and safeguards

Be honest about what the system cannot do and what safeguards are in place to mitigate risks.

A transparency statement should answer:

• What are the system's known limitations? (e.g., "the system may perform less accurately for candidates with non-traditional career paths", "the system has not been tested on resumes in languages other than English")
• What biases or fairness risks have been identified? (e.g., "an audit found that the system ranked women slightly lower than men for technical roles; we have implemented a fairness adjustment to address this")
• What safeguards are in place? (e.g., "human review of all decisions", "regular audits for fairness", "opt-out option for users")
• How is the system monitored and updated?

Example: *"JobScreen may perform less accurately for candidates with non-traditional career paths or career breaks. An internal audit found a small fairness gap for women in technical roles; we have implemented a fairness adjustment. We audit the system quarterly for accuracy and bias. Users can request a manual review if they believe the ranking was unfair."*

Audience and format

Decide who needs to see the transparency statement and how to reach them.

A transparency statement can take many forms:

• A dedicated policy page on your website.
• An in-app notification or disclosure widget.
• A section of your privacy policy or terms of service.
• Machine-readable metadata (JSON-LD, HTML attributes).
• Internal documentation (for internal-use AI).

The audience determines the format:

• End-users: Use plain language, in-app disclosure, or a linked policy page. Avoid jargon.
• Deployers or business customers: Use technical documentation, API docs, or a model card.
• Regulators or auditors: Use a formal disclosure document with evidence of review and approval.

Article 50 compliance: Deployer disclosure requirements

Which AI systems trigger Article 50

Article 50 of the EU AI Act requires deployers to disclose high-risk AI systems to end-users.

A high-risk AI system is defined in Annex III of the AI Act and includes systems that:

• Assess creditworthiness or determine access to credit.
• Evaluate job applicants or determine employment eligibility.
• Assign individuals to criminal-justice categories or predict recidivism.
• Assess the risk of individuals in the criminal-justice system.
• Determine eligibility for public benefits or social services.
• Evaluate students for educational placement or assessment.
• Detect, classify, or predict emotions or psychological states.
• Perform biometric identification or categorization of individuals.
• Detect or classify individuals based on protected characteristics.

If your AI system falls into one of these categories, Article 50 applies to you as a deployer. You must disclose it to end-users.

Note: The list above is illustrative. Consult Annex III of Regulation (EU) 2024/1689 and the European Commission AI Act Service Desk for the complete and current list.

What deployers must tell end-users

Article 50 requires deployers to provide end-users with clear and accessible information about: 1. That AI is being used: The system must be identifiable as AI. 2. The purpose of the AI system: What problem does it solve? What is it designed to do? 3. The performance of the system: How accurate or reliable is it? What are its known limitations? 4. The safeguards and human oversight: What checks are in place? Can a human review or override the decision?

The information must be provided in a manner that is:

• Clear and understandable: Use plain language, not jargon.
• Accessible: Reach the people affected by the AI system (e.g., job applicants, loan applicants, content creators).
• Timely: Provide the information before or when the AI system affects the user.

How to format and deliver the disclosure

There is no single mandated format for Article 50 disclosure. Common approaches include:

Policy page: A dedicated page on your website that explains all AI systems you use. This works well if you have a small number of systems or if users can easily find and read the page.

In-app disclosure: A notification, tooltip, or disclosure widget that appears when the user interacts with the AI system. This is often the most effective because it reaches the user at the moment of use.

Terms of service or privacy policy: A section that describes AI systems and their purpose. This works if you integrate the disclosure into documents users already read.

Email or notification: A message sent to the user before the AI system affects them (e.g., "your application will be reviewed by an AI system").

Documentation or model card: Technical documentation that describes the system's architecture, training data, performance metrics, and limitations. This is useful for business customers or regulators.

Guidance on disclosure formats is available from the European Commission AI Act Service Desk.

Machine-readable marking (Optional technical approach)

Some organizations use machine-readable metadata to mark AI systems in a way that can be read by software. Common approaches include:

• HTML attributes: Adding a `data-ai` attribute to HTML elements that are generated or influenced by AI (e.g., `<div data-ai="jobscreen-ranking">`).
• JSON-LD: Embedding structured metadata in a `<script>` tag that describes the AI system, its purpose, and performance metrics.
• HTTP headers: Adding custom headers to HTTP responses that indicate the presence of AI.

Machine-readable marking can help with:

• Transparency tooling: Software that crawls websites and identifies AI systems.
• Accessibility: Tools that help users understand how content was generated.
• Compliance verification: Automated checks that confirm disclosure is present.

Important caveat: Machine-readable marking is *advisory metadata*, not a substitute for human-readable disclosure. It does not provide proof of compliance and is not a signed or certified claim. The primary obligation is to provide clear, accessible information to end-users in a format they can understand. Machine-readable marking can *supplement* this obligation, but it does not replace it.

Provider obligations: Training data and model transparency

What providers must disclose

Providers of general-purpose AI models must disclose information about the training data and the model's capabilities and limitations.

A general-purpose AI model is one that is trained on a broad range of data and can be adapted or fine-tuned for many different tasks (e.g., a large language model like GPT-4 or Llama).

Providers must disclose:

• Training data composition: What data was used to train the model? What are the sources, size, and characteristics of the training data?
• Model capabilities and limitations: What can the model do well? What are its known weaknesses or failure modes?
• Performance metrics: How accurate is the model on standard benchmarks? How does it perform across different demographic groups?
• Known risks and safeguards: What risks have been identified? What mitigations are in place?

Training data transparency requirements

The European Commission has published a template for general-purpose AI model providers to summarize their training content.

The template asks providers to describe:

• The scope and scale of training data (e.g., "the model was trained on approximately 2 trillion tokens of text from web pages, books, and academic papers").
• The sources of training data (e.g., "Common Crawl, Wikipedia, GitHub, academic repositories").
• Filtering and processing steps (e.g., "we removed duplicates, filtered for quality, and applied safety filters").
• Known biases and limitations (e.g., "the model may reflect biases in the training data, such as overrepresentation of English-language content").
• Evaluation results (e.g., "the model achieves 85% accuracy on the MMLU benchmark").

Using the Commission's template helps ensure that your disclosure is comprehensive and aligned with regulatory expectations.

Using the Commission template

To use the Commission template:

1. Download the template from the Commission's website. 2. Fill in each section with accurate information about your model's training data and capabilities. 3. Be specific: Use concrete data sources, training scales, and evaluation metrics. Avoid vague language. 4. Disclose limitations honestly: Describe what the model cannot do and what risks have been identified. 5. Publish the summary alongside your model documentation, API docs, or product page. 6. Keep it current: Update the summary if you retrain the model, add new training data, or discover new limitations.

When provider disclosure is separate from deployer disclosure

If you are both a provider and a deployer, you have two separate disclosure obligations:

• Provider disclosure (training-data summary) is published for other organizations that might use your model. It explains what the model is, how it was trained, and what it can and cannot do.
• Deployer disclosure (end-user notification) is published for the people who interact with your product. It explains that you use AI, what it does in your specific context, and what safeguards are in place.

Example: A company builds and releases a general-purpose language model (provider role) and also uses it in a customer-support chatbot (deployer role).

• Provider disclosure: The company publishes a training-data summary on its model page, explaining the training data, model capabilities, and known limitations. This is for other organizations that might use the model.
• Deployer disclosure: The company publishes a disclosure on its customer-support page, explaining that it uses an AI chatbot, what it can help with, and that humans are available to handle complex issues. This is for the customers who interact with the chatbot.

Both disclosures are required. They serve different audiences and purposes.

Building your transparency statement: Step-by-step

Step 1: Inventory your AI systems

Start by listing all AI systems your organization uses or builds.

For each system, note:

• Name and identifier: How do you refer to it internally?
• Provider: Who built or trained it? (your organization, a vendor, or a combination)
• Use case: What does it do? What problem does it solve?
• Deployment context: Where and how is it used? (e.g., in your product, in your internal workflow, in a customer-facing service)
• Risk classification: Is it high-risk under Annex III of the AI Act? Is it general-purpose?

Create a simple spreadsheet or document that lists all systems. This is your AI inventory.

Example:

Step 2: Classify by role and risk

For each system, determine: 1. Your role: Are you a provider, deployer, or both? 2. Risk level: Is it high-risk under Annex III? Is it general-purpose? 3. Disclosure obligation: What must you disclose, and to whom?

Use the decision tree below:

Are you the organization that built or trained this AI system?

• Yes → You are a provider. If it is a general-purpose model, you must publish a training-data summary.
• No → Go to the next question.

Do you use this AI system in a product or service that affects end-users?

• Yes → You are a deployer. If it is high-risk, you must disclose it to end-users.
• No → You may have internal governance obligations, but no Article 50 obligation.

Is this system high-risk under Annex III?

• Yes → Article 50 applies (if you are a deployer). You must disclose it to end-users.
• No → No Article 50 obligation, but you may choose to disclose voluntarily for transparency or governance reasons.

Step 3: Draft disclosure for each system

For each high-risk or general-purpose system, draft a disclosure statement using the template below.

For deployers (end-user disclosure):

[System Name] Disclosure

What is [System Name]? [System Name] is an artificial intelligence system that [brief description of what it does]. It is [built by us / provided by [vendor name]].

How does it work? [System Name] [describes how it processes data and makes decisions]. It receives [input data] and outputs [output/decision].

What decisions does it make? [System Name] [describes the scope of its decision-making]. [Humans / we] [describe human oversight and review].

What are its limitations? [System Name] [describes known limitations, biases, or failure modes]. [Describe safeguards or mitigations].

How can you challenge or appeal? If you believe [System Name] made an unfair decision, you can [describe escalation process].

For providers (training-data summary):

Use the European Commission template. It includes sections for training-data composition, model capabilities, performance metrics, and known limitations.

Step 4: Choose format and audience

Decide how to deliver each disclosure:

• High-risk, end-user disclosure: Use in-app notification, policy page, or email. Reach the people affected by the AI system. Use plain language.
• General-purpose model, provider disclosure: Publish on your model page, API documentation, or product page. Reach deployers and the public.
• Internal AI use: Create internal documentation. Notify employees and affected stakeholders.

For each disclosure, ask:

• Who needs to see this? (end-users, deployers, regulators, employees)
• Where will they look for it? (product page, policy page, help center, API docs)
• What format will they understand? (plain language, technical documentation, video, infographic)

Step 5: Verify and log evidence

Once you have drafted and published disclosures, verify that they are live and maintain an evidence log for audits.

Verification steps: 1. Check that the disclosure is accessible: Visit the URL or page where the disclosure should appear. Confirm that it is visible and readable. 2. Test the user journey: Simulate the user experience. Does the disclosure appear at the right time and place? 3. Confirm accuracy: Review the disclosure against your AI system's actual behavior. Is the description accurate? 4. Check for completeness: Does the disclosure answer the key questions: what, why, how, and what safeguards?

Evidence logging: Maintain a log that records:

• Date: When was the disclosure published or updated?
• System name: Which AI system does it cover?
• Disclosure content: A copy or link to the disclosure.
• Format: How is it delivered? (in-app, policy page, email, etc.)
• Audience: Who can see it?
• Verification: Who reviewed and approved it? When?
• Changes: What was updated, and why?

This log demonstrates that you have taken disclosure seriously and provides evidence for audits or regulatory inquiries.

AI Transparency Statement Checklist

Use this checklist to audit your AI systems, identify what must be disclosed, and structure a statement that covers both regulatory obligations and internal governance.

A. System Inventory

• [ ] List all AI systems your organization uses or builds.
• [ ] For each system, note the name, provider, use case, and deployment context.
• [ ] Identify whether each system is high-risk (Annex III), general-purpose, or low-risk.
• [ ] Determine your role for each system: provider, deployer, or both.

B. Role and Risk Classification

For each system, answer:

• [ ] Are we the organization that built or trained this system? (Provider: Yes / No)
• [ ] Do we use this system in a product or service that affects end-users? (Deployer: Yes / No)
• [ ] Is this system high-risk under Annex III of the AI Act? (High-risk: Yes / No)
• [ ] Is this system a general-purpose AI model? (General-purpose: Yes / No)

Determine disclosure obligation:

• [ ] If provider + general-purpose: Must publish training-data summary.
• [ ] If deployer + high-risk: Must disclose to end-users (Article 50).
• [ ] If both: Must publish both training-data summary and end-user disclosure.

C. Disclosure Content

For deployer disclosure (end-user notification):

• [ ] System name and identifier.
• [ ] Clear statement that AI is being used.
• [ ] Purpose of the AI system (what problem does it solve?).
• [ ] Data inputs: What data does the system receive?
• [ ] Decision scope: What decisions does the system make or inform?
• [ ] Human oversight: Is there human review or override capability?
• [ ] Known limitations: What are the system's weaknesses or failure modes?
• [ ] Safeguards: What mitigations are in place?
• [ ] Escalation path: How can users challenge or appeal?
• [ ] Plain language: Is the disclosure understandable to end-users?

For provider disclosure (training-data summary):

• [ ] Training data composition: Sources, size, and characteristics.
• [ ] Filtering and processing: What steps were taken to prepare the data?
• [ ] Model capabilities: What can the model do well?
• [ ] Known limitations: What are its weaknesses or failure modes?
• [ ] Performance metrics: How accurate is it on standard benchmarks?
• [ ] Bias and fairness: What biases or fairness risks have been identified?
• [ ] Safeguards: What mitigations are in place?
• [ ] Use the Commission template as a guide.

D. Format and Audience

• [ ] Identify the audience for each disclosure (end-users, deployers, regulators, employees).
• [ ] Choose a delivery format: in-app notification, policy page, email, documentation, etc.
• [ ] Ensure the format is accessible and understandable to the intended audience.
• [ ] Confirm that the disclosure reaches the people affected by the AI system.

E. Verification and Evidence Logging

• [ ] Verify that each disclosure is live and accessible.
• [ ] Test the user journey to confirm the disclosure appears at the right time.
• [ ] Review the disclosure for accuracy against the system's actual behavior.
• [ ] Confirm that the disclosure is complete and answers key questions.
• [ ] Create an evidence log that records:
• [ ] Date of publication or update.
• [ ] System name.
• [ ] Disclosure content (copy or link).
• [ ] Format (in-app, policy page, etc.).
• [ ] Audience.
• [ ] Reviewer and approval date.
• [ ] Changes and reasons.

F. Ongoing Maintenance

• [ ] Schedule quarterly reviews of all AI systems and disclosures.
• [ ] Update disclosures if the AI system changes (new training data, new use case, new safeguards).
• [ ] Monitor for new high-risk AI systems added to your product.
• [ ] Maintain the evidence log with each update.
• [ ] Document any fairness audits, performance evaluations, or risk assessments.

Common mistakes and how to avoid them

Mixing up provider and deployer obligations

The mistake: Confusing which role you play and what you must disclose.

Example: A SaaS company integrates a third-party AI model into its product. The company assumes it is a provider and publishes a training-data summary. But the company is actually a deployer—it did not build the model. The company should disclose to end-users that it uses AI, not publish a training-data summary.

How to avoid it: Ask two questions: *Did we build or train this AI system?* (Provider) *Do we use this AI system in a product or service that affects end-users?* (Deployer) You may be both, but the obligations are different.

Writing disclosures only for lawyers, not users

The mistake: Using technical jargon, legal language, or dense paragraphs that end-users cannot understand.

Example: "This system employs a transformer-based architecture with attention mechanisms to process input sequences and generate probabilistic outputs via a softmax normalization layer." End-users have no idea what this means.

How to avoid it: Write for the person affected by the AI system, not for a lawyer or engineer. Use plain language. Explain what the system does, what data it uses, and what safeguards are in place. Test the disclosure with someone outside your team. If they do not understand it, rewrite it.

Failing to update statements when AI changes

The mistake: Publishing a disclosure once and never updating it, even when the AI system changes.

Example: A company publishes a disclosure that says "our AI system ranks job candidates based on resume text." Six months later, the company adds demographic data to the system's inputs. The disclosure is now inaccurate.

How to avoid it: Treat your transparency statement as a living document. Schedule quarterly reviews of all AI systems. Update the disclosure if the system changes (new training data, new use case, new safeguards, new limitations discovered). Document each change and the date of the update.

Forgetting to log evidence for audits

The mistake: Publishing disclosures but not keeping a record of what was published, when, and who approved it.

Example: A regulator asks for evidence that the company disclosed AI use to end-users. The company has no documentation of when the disclosure was published or who reviewed it.

How to avoid it: Maintain an evidence log from day one. For each disclosure, record the date, system name, content, format, audience, and reviewer. Keep a copy of each disclosure (or a link to it). This log is your proof that you took disclosure seriously and can be critical in an audit or regulatory inquiry.

Burying disclosures where users cannot find them

The mistake: Publishing a disclosure on a policy page that is hard to find or linked only from the footer.

Example: A company publishes an AI disclosure on a page called "Technical Documentation" that is not linked from the main product page. Users have no way to discover it.

How to avoid it: Make disclosures easy to find. Link them from the product page, help center, or settings. Use clear labels like "How AI is used here" or "About our AI system". Test that users can find the disclosure in less than two clicks.

Over-claiming certainty

The mistake: Stating that the AI system is "accurate", "fair", or "unbiased" without evidence or qualification.

Example: "Our AI system is 100% accurate and has no bias." This claim is almost never true and creates liability if the system makes a mistake.

How to avoid it: Be honest about limitations. Use qualified language: "the system achieves 85% accuracy on standard benchmarks", "an audit found a small fairness gap for women in technical roles; we have implemented a fairness adjustment", "the system may perform less accurately for candidates with non-traditional career paths".

Tools and formats for transparency statements

Policy page or dedicated page

A dedicated page on your website that explains all AI systems you use is a straightforward approach.

Advantages:

• Centralized: All AI disclosures in one place.
• Searchable: Users can find information about specific systems.
• Updatable: Easy to add, remove, or update systems.
• Auditable: Clear record of what you disclose.

Disadvantages:

• Discoverability: Users may not know the page exists or where to find it.
• Timing: Users may read the page long after they interact with the AI system.
• Engagement: Users may not read a long policy page.

Best for: Organizations with a small number of AI systems or users who actively seek information about AI.

In-app or in-product disclosure

A notification, tooltip, disclosure widget, or modal that appears when the user interacts with the AI system.

Advantages:

• Timing: The disclosure appears when the user is most likely to care.
• Engagement: Users are more likely to read a brief notification than a long policy page.
• Context: The disclosure can be tailored to the specific system and use case.
• Compliance: Demonstrates that you informed the user before the AI system affected them.

Disadvantages:

• UX friction: Notifications can annoy users if overused.
• Design: Requires careful design to be noticeable without being intrusive.
• Mobile: Space constraints on mobile devices may limit disclosure length.

Best for: Consumer-facing products where users interact directly with AI systems.

Machine-readable metadata (HTML, JSON-LD)

Structured metadata that describes the AI system in a format that software can read and parse.

Advantages:

• Automation: Transparency tooling can automatically detect and extract AI disclosures.
• Accessibility: Tools can help users understand how content was generated.
• Compliance verification: Automated checks can confirm disclosure is present.
• Integration: Metadata can be embedded in web pages without affecting design.

Disadvantages:

• Not human-readable: Users cannot directly read the metadata.
• Supplementary: Must be paired with human-readable disclosure to meet Article 50 requirements.
• Tooling: Requires software to extract and display the metadata.
• Standardization: No universally agreed format yet (though JSON-LD is emerging as a standard).

Best for: Organizations that want to support transparency tooling or automated compliance verification. Use alongside human-readable disclosure.

Evidence logging and audit trails

A system for recording when disclosures are published, updated, reviewed, and approved.

Advantages:

• Auditability: Clear record of compliance efforts.
• Accountability: Shows who was responsible for each disclosure.
• Traceability: Documents changes and reasons for updates.
• Risk mitigation: Demonstrates good-faith effort in case of regulatory inquiry.

Disadvantages:

• Administrative overhead: Requires discipline to maintain.
• Storage: Logs can grow large over time.
• Complexity: May require custom tooling or spreadsheets.

Best for: Organizations that want to demonstrate compliance or prepare for audits. Essential for regulated industries.

FAQ

What is an example of an AI transparency statement?

A transparency statement for a job-ranking AI might read: "We use an AI system called JobScreen to help rank job applications. JobScreen analyzes resume text and outputs a ranking score. A human recruiter reviews the ranked list and makes the final hiring decision. JobScreen may perform less accurately for candidates with non-traditional career paths. You can request a manual review if you believe the ranking was unfair."

Do I need a transparency statement if I use AI internally but don't expose it to users?

Article 50 does not require disclosure for internal-only AI use. However, you should document AI systems for internal governance and to comply with employment law, data protection, and other regulations. Employees and affected parties should be informed about AI systems that affect them.

What is the difference between a transparency statement and a privacy policy?

A transparency statement explains what an AI system does, how it makes decisions, and what safeguards are in place. A privacy policy explains how you collect, use, and protect personal data. Both are important; a transparency statement is specific to AI, while a privacy policy covers all data handling.

How often should I update my transparency statement?

Update your statement whenever the AI system changes: new training data, new use case, new safeguards, or new limitations discovered. At minimum, conduct a quarterly review of all AI systems and disclosures to ensure accuracy.

Can I use machine-readable marking (JSON-LD, HTML attributes) instead of a human-readable statement?

No. Machine-readable marking is supplementary metadata, not a substitute for human-readable disclosure. Article 50 requires that end-users receive clear, accessible information in a format they can understand. Machine-readable marking can help with automation and tooling, but you must also provide human-readable disclosure.

What should I do if I don't know whether my AI system is high-risk?

Consult Annex III of Regulation (EU) 2024/1689 and the European Commission AI Act Service Desk for guidance. If you are still unsure, consider the use case: does the AI system make or inform a decision that significantly affects a person's rights or opportunities? If yes, it is likely high-risk. When in doubt, disclose. It is better to over-disclose than to under-disclose.