How to prepare for AI:OK certification, section by section.

This guide follows the Quick Check form, the Core Certification form and the Extended Framework. It says what each section asks, what evidence to prepare and where applicants most often fall short. It is general guidance for every applicant. It does not guarantee an outcome, and AI:OK assessors do not write or coach individual answers.

How the framework relates to other frameworks is on the Framework page. You apply through the online forms. Downloadable versions help you prepare. When you submit the online form you make the declaration of accuracy and accept the Terms of Service and Privacy Policy.

1. Before you start

Who should apply

Apply if you run an AI music system, license a catalogue for AI use, or operate a platform that offers AI music tools. AI:OK certifies systems, catalogues and the practices behind them. It does not certify individual tracks.

What to have ready

• A plain description of what the system does, and who uses it.

• A list of the models you use, with providers and versions.

• A list of every dataset and source used to train, refine or evaluate the system.

• The licences, supplier agreements and rights records behind each one.

• The terms of any third-party model provider you rely on.

• The markets where you deploy or plan to deploy.

• The person in your organisation who can answer for each part.

Choose your scope

The scope is the boundary of what the certificate covers. The Core form asks you to select one and describe it.

• Company. Every generative or assistive AI system the company makes available. You need evidence for every system, including anything in beta.

• Product or service. One named product or service, including any third-party models inside it. This is the easiest scope to evidence and to explain.

• Individual model. One named model at a named version. You must publicly state which of your models are and are not certified.

• Catalogue. A defined body of works licensed for AI training or output. You provide the catalogue manifest, per-work rights status and the agreement under which it is licensed.

Start with the statement you want to be able to make. “Our product is certified” is a product scope. “Our company is certified” needs evidence for every system.

2. Quick Check

Quick Check is free. A human AI:OK assessor reviews it within five working days. You do not need full documents yet, but your answers must describe the system as it really operates. If you cannot answer a section clearly, you are unlikely to qualify in your current form.

System definition

The form asks for the name of the product, system or service, what it mainly does (search or recommendation, analysis, prediction, transformation, generation, or a mix), where it sits between non-generative and fully generative, its intended commercial use and its stage.

Prepare a product description, a short technical overview and a summary of the commercial use. Be specific about the stage. Pilot and commercially live systems are treated differently.

Model structure

The form asks whether you built your own model, fine-tuned an existing one, use a third-party API, use an open-source model you host, or a mix. It asks you to name the provider and model family and say whether you control training or rely on external providers.

Prepare a model inventory, the provider terms and a short architecture note. If you rely on a provider, say so directly. That is acceptable. Vagueness is not.

Dataset awareness

The form asks whether you can identify the actual datasets used to train, refine, evaluate or improve the system, to list the main ones, to classify the source types, and to say whether you can tell rights in a dataset list from rights in the content inside it.

Prepare a source register, vendor statements and an internal data inventory. Name the actual data, not just the category or the catalogue. A dataset can carry a free licence and still contain third-party copyright material, so a stated licence does not settle the rights position.

Rights and permissions

The form asks whether you hold explicit rights, from the relevant rights holders or authorised licensors, to use all third-party data for commercial AI training and deployment. It includes a short declaration with Yes, No or Partial. It also asks whether your third-party model provider’s terms allow your commercial use, and whether any part of the system depends on non-commercial, research-only, evaluation-only, territorial, attribution, royalty or revocable permissions.

Prepare licence agreements, provider terms and a short rights summary. Answer Partial honestly and describe the gap. A provider’s permission for your use does not show that its own training was lawful, and the form says so.

Deployment context

The form asks where and to whom you deploy, whether customers use the system in production or it is internal or experimental, and whether you know of any issue that could affect certification, deployment or trustmark use.

Prepare a deployment summary, a customer use case note and a summary of contractual restrictions.

Outcomes

• Proceed to Core. No immediate barrier is visible. You can join the waiting list.

• Requires Clarification. The system may be eligible, but the answers do not yet give enough clarity. Clarify the points raised and resubmit.

• Not Currently Eligible. The answers suggest the system is unlikely to meet the minimum threshold in its current form. You receive reasons. You may reapply with more evidence or appeal.

3. Waiting list

Applicants cleared to proceed to Core join the waiting list while places are limited. Places are offered in order of Quick Check clearance date. A place is not guaranteed. If your system or rights position changes while you wait, tell AI:OK. You may be asked to complete a new Quick Check.

4. Core Certification

Core is the substantive review and the stage where the trustmark is granted or withheld. Complete every mandatory section in full, and submit supporting documents with the form. Mark commercially sensitive answers and files [Confidential]. They are handled under the Confidentiality Protocol, and unmarked material is also treated as confidential.

Core 1. System disclosure

The form asks for the product, system or service under review, what it mainly does, where it sits between non-generative and fully generative, the intended commercial use, the stage, the scope you select and the model name and version.

Generative and partly generative systems receive extra scrutiny in the rights and deployment sections. Evidence is tied to a named model version, so give the exact version you use.

Core 2. Dataset and Source Register

This section is mandatory. List every dataset, source and training input, one row per item. For each row give the dataset name, provider or supplier, licensor or rights holder, asset type, role in the system, licence type and an evidence reference. Attach the register file and the documents it refers to.

The register must refer to the actual assets used. A metadata index, catalogue or list of assets is not enough. If you obtained a dataset list or manifest, rights to that list are separate from rights to the content, and you must address both.

If you cannot identify the datasets used for training, Core certification cannot proceed. If you rely entirely on a third-party model provider, complete the register as far as you can and explain the rest in Core 3.

Typical evidence: a source register or data inventory, vendor statements or data supply agreements, internal dataset documentation, licence agreements or terms of use from dataset providers, and provenance records.

Core 3. Training data provenance

For each dataset in the register, the form asks what was used, how it was obtained (purchased or licensed from the rights holder, supplied by a vendor or intermediary, open or public with stated licence terms, non-commercial or research-restricted, scraped from public web sources, internally generated, or through a third-party model provider), who supplied it, who holds the underlying rights, whether you separate rights in a list from rights in the content, and whether you relied on non-commercial, research-only, evaluation-only, territorial, attribution, royalty or revocable permissions.

Where you used an open or public source, confirm whether you assessed the rights status of the underlying content, not only the dataset’s stated licence.

Typical evidence: data supply agreements or purchase records, licence agreements and terms of use, provenance documentation, rights holder identification records, and vendor or intermediary statements.

Core 4. Rights and licensing

This section is the core of the Core review. Certification cannot be granted unless explicit rights exist for each use.

The form asks whether you hold explicit written rights from the relevant rights holders or authorised licensors for commercial AI training, for fine-tuning and improvement, and for commercial deployment. It then asks for the rights declaration: Yes, confirmed for all datasets; No; or Partial. If the answer is No or Partial, identify each gap and what you are doing about it. It asks whether your third-party model provider’s terms allow your use during training and model development, and whether any territorial, attribution, royalty or revocation terms affect deployment.

Rights obtained from a supplier, uploader, platform user, intermediary or dataset provider may not be enough if that party does not itself hold the underlying rights. Distinguish clearly between the party that supplied the content and the party that owns the rights in it.

Typical evidence: licence agreements for all training datasets, provider terms of service, rights clearance records or legal opinions, data processing agreements, and written confirmation from rights holders or licensors.

Core 5. Transparency obligations

The form asks which training data transparency obligations apply to you under law, such as EU AI Act Article 53 for general-purpose AI models or the EU copyright framework, whether you can disclose your training datasets on request, whether you keep records that show provenance to a regulator or rights holder, and whether you go beyond the legal minimum.

Typical evidence: a regulatory compliance assessment or legal opinion, a training data disclosure policy or summary, records of transparency-related communications, and EU AI Act documentation where it applies.

Core 6. Commercial deployment permissions

The form asks where, to whom and in which sectors you deploy, whether any legal, regulatory or contractual issue could affect deployment, whether rights in outputs are clearly established, and whether your third-party model provider’s terms permit your deployment and ongoing commercial use in your target markets. That last question is separate from the training-stage permissions in Core 4.

Typical evidence: a deployment summary or use case description, provider terms relevant to deployment, a legal review or counsel opinion on the target markets, and a summary of contractual restrictions.

Core 7. Synthetic data

The Core form asks about synthetic data. If you used any, be ready to say what it was generated from, which model generated it, and what rights you hold in the source material. Synthetic data does not remove the need to trace rights back to the source.

Core 8. Gaps and remediation

The form asks whether you know of gaps or uncertainties, whether you have a plan with a timeframe to resolve them, and whether Sound Judgement, AI:OK’s AI literacy programme, would help. Be candid. Conditional Certification is available where gaps exist but no clear infringement is established and you show credible intent and a plan. It is not available for the four gating conditions.

Sound Judgement is optional and is included with certification through the member portal at no extra charge.

Declaration

When you submit the online form you confirm that your answers and documents are accurate and complete, that you are authorised to submit for your organisation, and that you accept the Terms of Service. Material misrepresentation is a gating condition and can lead to refusal or revocation.

5. After Core

Outcomes

• Certified. All mandatory requirements are met and the rights, provenance and deployment basis are credible. You receive the certificate, a public registry entry, the trustmark licence and member portal access. Annual review is required.

• Conditional Certification. Gaps exist but no clear infringement is established, and you show intent to resolve them. You receive a remediation plan with milestones and a re-review date.

• Not Certified. Mandatory requirements are not met. You receive reasons. You may reapply with evidence or appeal.

Every outcome comes in writing with reasons.

The four gating conditions

Certification cannot proceed, and Conditional Certification is not available, where:

1. datasets used for training cannot be identified;

2. explicit rights for commercial training or deployment are absent or clearly not held;

3. restricted, non-commercial or research-only data has been used commercially without appropriate rights; or

4. material misrepresentation is identified in the application.

Appeals

You may appeal a decision within 20 working days of notice. A person or panel not involved in the original decision decides the appeal.

6. Extended Framework

The Extended Framework starts after Core certification. Core asks whether a system can be legitimately built and deployed. Extended asks how it is run day to day. A human assessor reviews your answers in a structured exchange. It supports dialogue and evidence gathering, and it is refreshed each year.

Answers are mostly short descriptions and selections. Prepare evidence you already keep: policies, procedures, test records and screenshots.

Extended 1 and 2. Initial disclosure and your organisation

The form asks about contentious AI tools you have used, any further training or refinement on additional datasets, your business size, phase and location, and any other certifications such as Fairly Trained, ISO or IEEE, with your reasoning.

Extended 3. Data governance

Covers GDPR compliance and certification, third-party sharing of user data, high-level source types in your training data, how you inform users about data use, information security policy and audit frequency, and retention, deletion, cleaning and preprocessing.

Typical evidence: GDPR documentation, ISO/IEC 27701 or privacy documentation, a privacy policy, retention and breach response policies, a DPO appointment letter, third-party sharing disclosures, and subprocessor lists and data processing agreements.

Extended 4. The user

Covers whether you explain how the system works, whether users can opt out of training on their data or of features, profiles and recommendation explanations, reporting of problematic content, accessibility, transparency for API users and for people in your database, and wellbeing measures such as moderation, anthropomorphisation, addictive design and echo chambers.

Typical evidence: user guides or FAQ pages, screenshots showing consent and controls, accessibility reports, transparency reports, datasheets on model functionality and limits, community guidelines, and assistive technology test reports.

Extended 5. System design and operation

Covers quality testing, risk assessment and emergency plans, documentation policies, third-party software and AI models in the system, large language model use, business model and human oversight, and bias and diversity.

Typical evidence: a risk assessment plan, a quality assurance policy, documentation policies, a list of integrated third-party software, a list of AI models and how they are integrated, AI use disclosures and provider contracts, and technical documentation.

Extended 6. Cultural and sector impact

Covers attribution, licensing, copyright and royalty practices, effects on artist compensation, gaming and manipulation of your system, adaptation to different music markets, and long-term cultural impact.

Extended 7. Governance and ecosystem

Covers regulatory tracking, internal accountability and ethics, whistleblower protections, sustainability, third-party developer guidelines, external collaboration, supply chain ethics, child safety and responsible marketing.

Typical evidence: regulatory tracking logs, internal policies for ethical AI use, organisation charts and review team charters, policies for reporting concerns, environmental impact analysis, developer access guidelines, and marketing materials.

Extended 8. AI literacy

Covers whether you know the AI literacy requirements for your region and whether you educate staff, users and API clients, and refresh that knowledge. EU AI Act Article 4 requires providers and deployers to take measures to support AI literacy. Typical evidence: internal policies, training modules, update schedules and feedback logs.

Extended 9. Finishing up

You can say where you are unsure about operational, governance or rights implications. AI:OK uses this to give general guidance and to improve the framework. It is not used to penalise.

7. Annual review and changes you must disclose

Certification lasts twelve months. You complete the annual review every year, including a refresh of the Extended Framework. The Framework page explains which version of the standard applies and what happens at the review.

Tell AI:OK promptly about material changes to training data, model structure, rights arrangements, ownership or control, third-party model dependencies or deployment markets. A material change to training data, model architecture or the rights basis will normally require re-certification, not disclosure alone. Other material changes may need an interim review. The annual review is required in every case. If you do not complete it, the certificate lapses and the registry shows Expired.

Keep your Dataset and Source Register, licence records and policies up to date through the year. Evidence prepared for the first review can be reused at the annual review where nothing has changed.

8. What good evidence looks like

Types of evidence

• Provenance evidence: registers, inventories, manifests and source records.

• Legal evidence: licence agreements, supply agreements, provider terms, rights clearance records, legal opinions and written confirmations.

• Operational evidence: policies, procedures, records, logs and screenshots.

Required and strengthening evidence

Some evidence is needed to answer a question at all. Other evidence strengthens an answer. Written confirmation from a rights holder or licensor, and a legal opinion on a deployment market, are examples of evidence that strengthens an answer.

Where evidence usually sits

• Legal and contracts: licence agreements, data supply agreements, provider terms, indemnities and data processing agreements.

• Data or engineering: the source register, the data inventory, lineage records and model inventory.

• Product: user-facing pages, consent and control screens, help articles and accessibility reports.

• Internal policies: security, retention, risk, quality, documentation, ethics and AI literacy policies.

What good evidence looks like

• It is specific to your scope and to the named model and version.

• It is dated, and a policy or procedure shows a version history or review date.

• It can be traced to a person or team responsible for it.

• It is consistent with your other answers.

• It shows what you do in practice, not only what you intend.

• It is current.

A policy can sit inside another document. For example, an AI failure plan can be part of an incident response procedure, and an acceptable use policy can be part of your terms of service. Point to the section.

Third-party model providers

Gather the provider contract or terms of service, and any commitments the provider makes on intellectual property, such as indemnities, copyright and trademark handling policies, liability coverage and documented limitations or exclusions. Add any questionnaire responses or certification documents the provider has supplied. These show what the provider promises. They do not show how it trained its model.

Data transfers

If data leaves the EU or another regulated region, prepare your data processing agreements, your transfer mechanism (such as standard contractual clauses or an adequacy decision), and a subprocessor list that shows locations and has a review date or version history.

9. Common gaps

• Catalogue rights versus content rights. Holding rights to a list is not holding rights to the works in it.

• Supplier versus rights holder. The party that sold you data may not own the rights in it.

• A free licence versus rights in the content. An open licence on a dataset does not settle the rights position of the music inside it.

• Provider permission versus lawful provider training. A provider can allow your use while its own model rests on a weak basis.

• Training rights versus deployment rights. Explicit rights to train do not automatically cover commercial deployment, or fine-tuning.

• Missing model version. Evidence must refer to the exact model and version.

• Vague registers. Rows with categories instead of named datasets, or no evidence reference.

• Synthetic data with no lineage. You cannot show where the generating model or its source material came from.

• Unclear scope. The scope you select does not match the evidence you provide.

10. Checklist

Before Quick Check:

• Description of the system and its commercial use.

• Model list with providers and versions.

• List of datasets and sources.

Before Core:

• Complete Dataset and Source Register with an evidence reference for each row.

• Licence agreements, supply agreements and provider terms.

• Written confirmation from licensors or rights holders where you have it.

• A rights summary and a list of gaps with plans.

• Deployment markets and any restrictions.

• Synthetic data source and lineage, if used.

• Scope and exact model name and version.

Before Extended: - Privacy, security and retention policies. - Risk assessment, quality and documentation policies. - List of third-party software and AI models in use. - Accessibility and user control evidence. - Governance, ethics and AI literacy records.

Questions about an application go to info@ai-ok.org.