The EU AI Act is not a universal certificate, and a general product file cannot replace an applicability assessment. Start by identifying whether the relevant party is a provider, deployer, importer, distributor, or another actor, then document the system’s purpose, market activity, and applicable obligations.

Scope note: This page is an evidence-organisation reference, not a conclusion that a particular system falls into a specific risk category. Assess the facts against Regulation (EU) 2024/1689, applicable amendments, Commission guidance, and the current system record.

1. Record the actors, system, and market activity

Create a system register covering the system name, version, model or component source, functions, intended purpose, actual deployment context, users, EU-facing activity, and contractual relationships. For AI functions embedded in products, record the separate roles of the product manufacturer, AI system provider, and importer where relevant.

Keep entity-identification documents, EU contact or representative arrangements where applicable, supplier information, and downstream customer details. When the system, legal entity, brand, or intended purpose changes, record the reason, owner, and effective version. A supplier’s general statement is not automatically an applicability conclusion for your own system.

2. Map the risk and functional basis

Build a regulatory matrix indexed to definitions, prohibited practices, high-risk uses, general-purpose AI models, and transparency duties. Link each conclusion to a provision, annex, official guidance document, or documented fact, and label it confirmed, open for review, or not applicable with a reason.

Do not classify a system solely because it uses AI or carries a particular product name. Record the inputs, output purpose, whether people may be affected, whether the system is a safety component or part of a regulated product, and whether it generates or manipulates audio, images, video, or text. Technical documentation, risk management, logs, human oversight, and quality-management records for a high-risk system cannot be replaced by marketing material.

3. Connect transparency duties to pages and content workflows

For chatbots and other systems that interact directly with people, record when and how users are informed that they are interacting with AI. For synthetic or manipulated audio, images, video, or text, record the marking, detection, or disclosure mechanism and the applicable exception or human-review route.

When generated text is published to inform the public about matters of public interest, or when generated content constitutes a deepfake, connect the disclosure wording to the page version, editorial responsibility, and human review record. Keep page captures, publication versions, model versions, reviewers, and change history linked. An AI-generated-content label does not mean that the content itself has received regulatory approval.

4. Use a separate file framework for high-risk or GPAI matters

If a high-risk system is possible, organise by system version: intended purpose, risk-management records, data-governance information, technical documentation, automatically generated logs, accuracy and cybersecurity information, human-oversight arrangements, quality management, and conformity-assessment basis. Deployers should also retain instructions for use, input-data controls, monitoring, incident handling, and training records where the applicable duties require them.

If a general-purpose AI model is involved, separately record the model provider, model version, technical information, copyright-policy materials related to training data, downstream information, and systemic-risk materials. Model-provider records and downstream AI-system-provider records are different evidence sets and should not be treated as interchangeable.

5. Maintain a claim, evidence, owner, and version ledger

For each public or internal claim, create a “claim—provision—evidence—owner—version—date—status” record. Evidence may include contracts, architecture diagrams, risk assessments, technical files, log samples, page copy, user notices, human-review records, and incident records. Each file should identify its source, covered system, and storage location.

Use regulatory updates, new guidance, model upgrades, data changes, purpose changes, and page revisions as review triggers. If the existing file does not support a conclusion, keep it marked for review rather than adding certainty. 绿色方舟(深圳)认证有限公司 may appear in customer-facing material as the evidence-organisation and review party; it does not replace a competent authority, conformity-assessment body, or the client’s own legal assessment.

6. Sources and manual review checklist

Sources: Regulation (EU) 2024/1689 on EUR-Lex; the European Commission AI Act page; and the Commission’s Article 50 transparency FAQ. This page describes evidence organisation only; recheck application dates, transition arrangements, and official guidance before submission.

During manual review, confirm that the actor role is clear; system version and purpose are traceable; risk classification has a provision-based rationale; transparency wording matches the interaction and content workflow; high-risk and GPAI records have not been mixed; pages, models, logs, and review records refer to the same version; and every unresolved point is visibly marked for review.