Buying a compliant AI model doesn't settle an organisation's EU AI Act responsibilities

Buying a compliant AI model doesn't settle an organisation's EU AI Act responsibilities. The more consequential question is what the organisation builds around that model, what decisions the resulting system supports, and whether changes to its purpose move the organisation into the provider role. EU AI Act requirements attach to particular systems, uses and operator roles, not to the model purchased. A defensible compliance programme therefore starts with classification and responsibility, then maps documentation, oversight, transparency and assessment duties to each deployment. Professional users also need change control: a workflow approved for document assistance may require a different assessment when repurposed for recruitment, eligibility or another consequential decision. Verification can support an evidence trail, but it doesn't determine legal classification or replace conformity assessment. Where official implementation materials give conflicting dates, the responsible approach is to record the uncertainty and verify the applicable legal text before approving a deployment calendar.

Which EU AI Act Requirements Apply to Each Risk Tier?

The EU AI Act is commonly explained through four risk tiers, with stronger controls for higher-risk uses, although transparency duties and model-provider obligations don't fit neatly into a single ladder.

EU AI Act risk tiers and the main requirement for each

• Unacceptable risk, prohibited — Typical examples: Social scoring by public authorities; manipulation that exploits vulnerabilities, where the statutory conditions are met; Main requirement: Prohibited practices cannot be deployed
• High-risk, Annex III — Typical examples: Recruitment screening; creditworthiness assessment; access to essential services; education assessment; law enforcement; migration; Main requirement: Risk management, data governance, technical documentation, logging, human oversight, accuracy, robustness and cybersecurity
• High-risk, Annex I — Typical examples: AI as a safety component of machinery or medical devices, where the relevant product-assessment conditions apply; Main requirement: Core high-risk requirements integrated with sectoral product legislation
• Limited risk, transparency — Typical examples: Chatbots interacting with people; synthetic audio, image, video or text; deepfakes; Main requirement: User disclosure and machine-readable marking where applicable
• Minimal risk — Typical examples: Spam filters; AI in video games; Main requirement: No high-risk conformity regime solely because AI is used; AI-literacy measures remain relevant, with voluntary codes available

The EU AI Act's legal text establishes the prohibited practices, high-risk classification routes and specific transparency obligations reflected in this comparison. These labels are useful shorthand, not a substitute for checking the legal conditions and exceptions.

Prohibited and high-risk uses

Unacceptable risk concerns practices the legislation prohibits, rather than systems that can proceed after extra documentation. The scope matters: not every persuasive interface constitutes prohibited manipulation, and the prohibition on social scoring isn't confined to public authorities.

High-risk classification has distinct routes. A system may fall within a listed use case, or qualify through regulated-product legislation. Not every application used in a hospital is a high-risk medical device, and not every administrative tool used by an employer performs a high-risk employment function.

Transparency and lower-risk uses

The limited-risk label can obscure an important distinction: transparency is a trigger-based obligation, not necessarily an exclusive category. A high-risk system may also interact directly with people or generate synthetic content.

Likewise, minimal risk doesn't mean absence of governance. AI literacy and other applicable laws can remain relevant even when the high-risk requirements don't apply.

For decision-makers, the practical starting questions are concrete:

• Purpose: What task or decision does the system perform?
• Context: In which sector, and with what consequences, is it used?
• Product relationship: Is it a regulated product or a safety component within one?

The underlying technology alone doesn't answer those questions. The same model can support materially different regulatory outcomes.

When Do the EU AI Act Requirements Start to Apply?

The Act applies in phases, so an organisation needs an obligation-by-obligation calendar, not a single compliance deadline.

The Commission's AI Act implementation timeline identifies the entry-into-force, literacy, governance and standard high-risk milestones below. A separate Commission regulatory-framework page gives later transition dates for certain high-risk systems, The Commission's AI Act implementation materials identify the entry-into-force, literacy, governance, transparency and high-risk milestones below. Current Commission materials state that Annex III high-risk rules apply from 2 December 2027 and Annex I product-embedded high-risk rules from 2 August 2028.

EU AI Act application milestones and verification status

• 1 August 2024 — What starts applying: Regulation enters into force; Verification status: Confirmed across the cited Commission materials
• 2 February 2025 — What starts applying: Prohibitions and AI-literacy duty; Verification status: Confirmed across the cited Commission materials
• 2 August 2025 — What starts applying: Governance rules, penalties and obligations for general-purpose AI model providers; Verification status: Confirmed across the cited Commission materials
• 2 August 2026 — What starts applying: The majority of remaining rules, including Article 50 transparency obligations and enforcement for applicable provisions; Verification status: Confirmed. Annex III high-risk rules are scheduled for 2 December 2027. — What starts applying: Main rules; Annex III high-risk requirements on the standard timetable; Verification status: Conflicting high-risk timetable; verify against the Official Journal text
• 2 August 2027 — What starts applying: Member States should have at least one AI regulatory sandbox operational; Verification status: Confirmed in the Commission implementation timeline — What starts applying: High-risk AI embedded in Annex I regulated products; Verification status: Unverified planning date because the Commission materials conflict
• 2 December 2027 — What starts applying: Transition date for certain Annex III use cases in the second Commission account; Verification status: Conflicting; verify legal status and scope
• 2 August 2028 — What starts applying: Transition for safety components of products under product-safety legislation in the second Commission account; Verification status: Conflicting; verify legal status and scope

Treat conflicting dates as an unresolved control

The table distinguishes the general application date of 2 August 2026 from the later dates for Annex III and Annex I high-risk systems. Teams should still check the operative Official Journal text and transitional provisions for the specific system and deployment facts. It doesn't establish that a proposed or reported extension has become applicable law.

A planning team should check the operative Official Journal text, relevant amendments and transitional provisions before relying on an extension. Where a genuinely system-specific legal issue remains unresolved, mark the affected deadline unverified, identify an owner and record the next review.

Planning rule: A disputed deadline is a reason to preserve the implementation work, not a reason to suspend it.

For each system, record the obligation, operator responsible, legal source, applicable transition and internal readiness date. Classification determines which calendar entries matter; it doesn't remove the need to examine exceptions or existing-system provisions.

How Do You Classify an AI System Under the EU AI Act?

Classify the deployed function and intended purpose, then record the reasons for the result. A verification or decision-support label doesn't automatically make a consequential workflow low-risk.

The Regulation's classification and high-risk provisions support a purpose-based assessment, including examination of listed uses, operator responsibilities and relevant documentation.

1. State the intended purpose in one sentence. Identify who uses the system, the data involved and the task or decision supported. This establishes the boundary against which later changes can be assessed.

1. Screen for prohibited practices. Compare the actual function with the statutory conditions, not merely the vendor's description. If the proposed use falls within a prohibition, ordinary high-risk controls don't authorise it.

1. Compare the purpose with the listed high-risk contexts. Examine biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration and justice. Check relevant exceptions and qualifications rather than treating a sector label as conclusive.

1. Check the regulated-product route. Determine whether the system is itself a covered product or a safety component, and whether the required product-assessment conditions are satisfied.

1. Identify the organisation's role. Record provider, deployer, importer or distributor status, including whether modification or repurposing changes that position. Contract terminology alone isn't a sufficient classification method.

1. Map transparency triggers. Identify direct interaction, synthetic content, emotion recognition and biometric categorisation where relevant. These duties require a separate check even when the system isn't high-risk.

1. Keep the classification decision and supporting reasons. Include the system boundary, assumptions, exclusions, approver and review trigger. Where a listed-use system is assessed as not high-risk under the relevant exception, retain the required justification for authority review.

The following visual supports the initial inventory and classification discussion.

Test the downstream decision

Consider a tool that checks the reasoning behind benefit-eligibility recommendations. Its verification function doesn't settle the classification of the complete eligibility workflow.

A useful internal test is whether the team can produce a concise classification cover sheet supported by the underlying analysis. A short record can make a decision reviewable; brevity alone doesn't make it defensible.

Which Duties Fall on Providers, Deployers and Modifiers?

Role isn't fixed by purchase. Under Article 25 of the AI Act, a distributor, importer, deployer or other third party can become the provider of a high-risk system through rebranding, substantial modification or a change of intended purpose that makes the system high-risk.

A provider develops a system, has it developed, or places it on the market or puts it into service under its own name under the relevant conditions. A deployer uses a system under its authority. Importers and distributors occupy supply-chain roles, but those descriptions don't insulate them from a later role change.

What a role shift looks like

• Law-firm deployment: A firm uses a model to summarise documents, then configures a workflow for eligibility triage. The new purpose warrants a fresh assessment; routine document assistance and consequential eligibility assessment aren't interchangeable.
• Clinical modification: A clinic repurposes a triage tool for a different patient group. The relevant questions concern the approved purpose, original assessment and effect of the change, rather than whether staff call it configuration.
• Public-sector integration: A public body fine-tunes a model and integrates it into benefit decisions. Its responsibilities require examination at system level, including the workflow it puts into service.
• Supply-chain rebranding: A distributor markets a high-risk system under its own name. Commercial presentation can therefore affect regulatory responsibility.

Not every retrieval-augmented prompt, workflow integration or controlled edit constitutes a substantial modification. The answer depends on the legal test, the original assessment and the facts; competent-authority interpretation may also affect implementation.

Literacy belongs in the operating model

The Commission's AI-literacy guidance addresses measures by providers and deployers for staff and others operating AI on their behalf. That isn't the same as imposing an identical training obligation on every supply-chain actor.

A defensible programme connects role-based training to permitted uses, verification steps, confidentiality, uncertainty and escalation. A course certificate alone doesn't demonstrate that those controls work.

In our analysis, the strongest safeguard against an unnoticed role shift is a change-control record kept alongside the classification file.

That record should capture the original purpose, each modification, validation results, human controls and the decision to approve or escalate the change.

What Must High-Risk Systems Document and Keep?

High-risk documentation should connect each legal requirement to evidence that a named person can produce and explain.

High-risk requirements and the records to keep

• Risk management system — Article: Article 9; What to keep on file: Risk identification, mitigation measures and residual-risk decisions across the lifecycle
• Data governance — Article: Article 10; What to keep on file: Data origin, preparation, suitability, examination for bias and identified limitations
• Technical documentation — Article: Article 11 and Annex IV; What to keep on file: System description, design choices, intended purpose and performance metrics
• Record-keeping and logs — Article: Article 12; What to keep on file: Automatic logs supporting traceability and monitoring
• Transparency to deployers — Article: Article 13; What to keep on file: Instructions for use, accuracy information and known limitations
• Human oversight — Article: Article 14; What to keep on file: Measures enabling people to understand, override or stop the system
• Accuracy, robustness and cybersecurity — Article: Article 15; What to keep on file: Test results, performance limits and resilience measures
• Quality management system — Article: Article 17; What to keep on file: Written policies, procedures and accountability assignments
• Retention of documentation and logs — Article: Articles 18 and 19; What to keep on file: Required documentation and conformity records; provider-controlled logs under the applicable retention rules

The AI Act's documentation and retention provisions require providers to retain specified documentation, including technical documentation and the EU declaration of conformity, for 10 years after placement on the market or putting into service, and provider-controlled automatic logs for an appropriate period of at least six months, unless applicable law provides otherwise.

Build records that connect

Assign each control a named owner, version and date. For risk management, link a hazard to its mitigation and validation result; for oversight, connect the written procedure to an available intervention mechanism and evidence of its use.

Data-governance records should explain relevant preparation choices and limitations, rather than merely listing datasets. Technical documentation should let a reviewer understand the system without reconstructing its design from scattered messages.

For consequential runs, a practical evidence trail can include immutable run identifiers, model-version and prompt metadata, retrieved sources, reviewer outputs, corrections, disagreements, access logs and incident records. Apply access and retention controls to the trail itself, since logs may contain confidential material.

The operational considerations for high-risk AI handling confidential documents are particularly relevant where evidential completeness and restricted access need to coexist.

Maintain contract and agent registers

Our evidence line for AI contracts is a contract register listing each AI contract, its owner, the rights exchanged, available logs and access, gaps, and a remediation deadline.

Our evidence line for AI agents is an agent register listing each agent's identity, owner, permitted scope, approver, and the location of its logs.

These are working governance structures, not substitutes for the required technical documentation. They help expose a practical problem: an organisation may promise traceability while lacking contractual access to the records needed to demonstrate it.

The decisive test is whether the file shows controls operating as designed, including failures, interventions and corrections, rather than merely showing that policies were approved.

Which Conformity Assessment Route Applies to Your System?

The assessment route follows the system's legal category and product context, not the organisation's preferred certification process.

Conformity assessment routes compared

• Internal control under Annex VI — Typically applies to: Most standalone Annex III high-risk systems, subject to the applicable category-specific rules; Who assesses: Provider using its quality management system and technical documentation; Result: EU declaration of conformity and CE marking
• Notified-body assessment under Annex VII — Typically applies to: Relevant biometric systems where applicable standards or specifications aren't used, aren't fully applied, or the legal conditions otherwise require it; Who assesses: Designated third-party notified body; Result: Certificate, followed by the applicable declaration and CE marking
• Sectoral product route under Annex I — Typically applies to: Qualifying high-risk AI within regulated products, such as machinery or medical devices; Who assesses: Assessment participants required by the product legislation; Result: Product-regime assessment integrating AI Act requirements
• Non-high-risk systems — Typically applies to: Systems outside the high-risk classification; Who assesses: No high-risk AI Act conformity assessment; Result: Applicable transparency and other duties remain

Internal control isn't an absence of assessment

For most standalone high-risk use cases, the provider's route centres on its own documented assessment. That still requires a coherent technical file, functioning quality management and evidence that the applicable requirements have been met.

An internal approval meeting isn't equivalent to conformity assessment. The responsible signatory needs a basis for the declaration, including unresolved limitations and the relationship between tests, controls and intended use.

The biometric route needs particular care. Remote biometric identification can require notified-body involvement where the relevant harmonised standards or common specifications aren't applied or aren't fully applied; a generic internal-control assumption is therefore unsafe.

Check standards and designation

Harmonised standards published in the Official Journal can support a presumption of conformity only for the requirements they cover. Teams should map each claimed standard to specific requirements and verify its applicable status.

ISO/IEC 42001 is a management-system standard. Certification against it doesn't, by itself, establish conformity with the AI Act's system-specific requirements.

Assessment question: What evidence authorises the declaration for this system, this version and this intended purpose?

Before approving the route, establish who signs the declaration, whether a notified body is needed and which standards remain unresolved. For regulated products, coordinate that decision with the product-conformity team rather than creating a separate, disconnected AI approval.

What Transparency and GPAI Duties Apply to Third-Party Models?

System transparency and upstream model obligations are separate responsibilities. Connecting a third-party model to an organisation's workflow doesn't transfer all responsibility to the model provider.

Policy review should examine both the interface people encounter and the upstream documentation available to the organisation.

The Act distinguishes informing people that they're interacting with AI, machine-readable marking of synthetic outputs, and deployer disclosures for specified generated or manipulated content. An on-screen label and technical output marking perform different functions; one shouldn't be assumed to replace the other.

Obtain the upstream evidence

General-purpose AI model-provider duties address technical documentation, downstream information, copyright policy and a public training-content summary. Models with systemic risk attract additional evaluation, risk-assessment, mitigation and cybersecurity duties.

For procurement and integration, a defensible documentation package includes:

• Model identity: Provider, model version and changes relevant to the deployment.
• Permitted use: Usage restrictions and information needed for downstream implementation.
• Operational cooperation: Incident-notification commitments and available security or evaluation evidence.
• Known gaps: Missing documents, inaccessible test information and contractual limits on assistance.

External model routing may involve recipients outside the European Economic Area, so our provider and customer arrangements need an applicable transfer mechanism where Chapter V GDPR applies.

For a deployment assessment, document what each recipient receives, rather than assuming that transformed context removes every privacy question. The discussion of AI Act transparency and Digital Omnibus developments also requires careful separation of enacted requirements from unresolved changes.

The accompanying video can be considered alongside the written policy review.

Don't confuse agreement with conformity

Comparing outputs from independent models can support professional review. Multi-model agreement isn't a conformity assessment, doesn't supply missing provider documentation and doesn't establish that an answer is correct.

The procurement question is therefore specific: what has each upstream provider documented, what can the organisation verify, and what remains unknown?

What Are the Fines for Breaching the EU AI Act?

For undertakings, breaches of the prohibited-practices rules can attract fines of EUR 35 million or 7% of total worldwide annual turnover for the preceding financial year, whichever is higher, under the AI Act's penalty provisions.

The same provisions establish other ceilings:

• EUR 15 million or 3%: Maximum exposure for specified other infringements.
• EUR 7.5 million or 1%: Maximum exposure for supplying incorrect, incomplete or misleading information to authorities or notified bodies.

These are maximum ceilings, not automatic penalties. The applicable calculation also reflects the Regulation's treatment of small and medium-sized enterprises, including start-ups; the higher-of formulation shouldn't be applied indiscriminately to them.

The infographic summarises the headline prohibited-practices ceiling for undertakings, subject to those statutory qualifications.

Read exposure through the actual obligation

National competent authorities form part of the enforcement framework, while the Commission's AI Office has responsibilities concerning general-purpose AI models. Penalty assessment considers factors including the nature, gravity and duration of the infringement and cooperation with authorities.

Misclassification, missing records, ineffective oversight and misleading submissions create different legal questions. They shouldn't all be described as attracting the headline maximum.

The distinction between system offences and penalties affecting GPAI model providers matters for board reporting. Leadership should identify the relevant obligation, responsible entity and potential turnover exposure, rather than attaching a single fine figure to every AI risk.

What Does a Compliance Checklist Look Like in Practice?

Run a documented release checklist before go-live and whenever the purpose, model or material workflow changes. Treat it as a recommended control framework, not a statement that every item is an identical statutory duty for every system.

1. Assign ownership. Name the accountable system owner and approving function.
2. Record the intended purpose and permitted boundaries.
3. Complete the prohibited-practice screen and relevant Annex checks.
4. Confirm operator status, including any modification-related provider shift.
5. Approve transparency triggers and the corresponding disclosure text.
6. File upstream provider documentation, model identity, restrictions and incident commitments.
7. Record risk-management and data-governance decisions with version and date.
8. Confirm technical documentation, logging design and applicable retention.
9. Define who reviews, who can override and who approves consequential outputs.
10. Require appropriate human review before reliance, filing or external transmission. Users retain professional judgment and the final decision, and should review output before relying on it, acting on it, filing it or sending it to a third party.
11. Keep role-specific AI-literacy records.
12. Maintain an incident and correction log with an escalation route.
13. Identify the conformity route and declaration owner where applicable.
14. Set a reclassification review date and change triggers.

The visual provides a compact release-gate summary.

Apply the checklist to the workflow

For customer-support deployments, SupportGPT-1's insights on building support agents can provide implementation context, but they aren't authority for EU professional or regulatory duties.

In our analysis, upstream documentation deserves an explicit release gate because the downstream team may otherwise approve a workflow without the information needed to assess it. That's a risk-based recommendation, not a measured claim about which omission occurs most frequently.

The checklist supports review. It doesn't replace legal advice on the deployment's specific facts.

Which Decision Should Your Team Take First?

The first decision is whether each system is in scope, how it is classified and who owns that conclusion. Leadership can then approve the assessment route and implementation plan against verified legal requirements.

The most useful board submission isn't a general statement that the organisation uses compliant AI. It is a system register supported by reasoned decisions and accessible evidence.

Ask for decisions that can be reviewed

• Classification approval: Which systems are high-risk candidates, who approved each conclusion and what assumptions could change it?
• Responsibility allocation: Which entity carries provider or deployer duties, and which modifications require escalation?
• Assessment approval: Which conformity route applies, who signs the declaration and what external assessment is needed?
• Readiness approval: Which documentation and oversight controls are operating, and which remain incomplete?
• Deadline confidence: What is the source for each obligation's start date, and which transitions remain unverified?
• Evidence access: Can the organisation produce upstream documentation and the evidence trail for consequential outputs?

The underlying governance insight is that classification and change control belong together. A carefully assessed system can become a different compliance proposition when its purpose changes, even if procurement hasn't purchased a new model.

It supports review and control for professionals working where accuracy, confidentiality and accountability matter, including legal teams, notaries, health services, journalists, researchers, compliance teams and security-sensitive organisations.

Verification doesn't ensure correctness, decide the legal classification or replace legal advice. Where dates or standards remain uncertain, retain the conflicting positions, name the person responsible for resolution and set the next review.

More articles on this subject are collected in the EU AI Act and compliance overview.

Sources: Risk tiers, prohibited practices, high-risk routes and transparency duties are drawn from the EU AI Act legal text on EUR-Lex; application milestones come from the Commission's AI Act implementation timeline and its regulatory-framework page, which conflict on certain high-risk dates; value-chain roles reference Article 25.