Buying a compliant AI model doesn't settle responsibilities

You cannot discharge your EU AI Act obligations by purchasing a compliant model. Your legal duties attach to the specific system you deploy, the decisions it supports, and the role you occupy in its supply chain. A defensible compliance programme begins with classification and responsibility, then maps documentation, oversight, transparency and assessment duties to each deployment.

An analysis of 4 November 2026 of buying a compliant AI model and settling an organisation's EU AI Act responsibilities argues that the Act's requirements attach to particular systems, uses and operator roles, not to the model purchased. The analysis uses a tool that checks reasoning behind benefit-eligibility recommendations to illustrate how a verification function does not settle the classification of the complete eligibility workflow. In our assessment, the distinction matters because a workflow approved for document assistance may require a different assessment when repurposed for recruitment or another consequential decision, and an organisation may shift from deployer into provider role through substantial modification or a change of intended purpose.

Which risk tier applies to your system?

The EU AI Act establishes four risk categories, though transparency duties and model-provider obligations do not fit neatly into a single ladder. Unacceptable-risk practices are prohibited outright; the scope matters because not every persuasive interface constitutes prohibited manipulation, and the prohibition on social scoring is not 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, but not every application used in a hospital is a high-risk medical device. Limited-risk classification can obscure an important distinction—transparency is a trigger-based obligation, not necessarily an exclusive category. Minimal-risk classification does not mean absence of governance; AI literacy and other applicable laws can remain relevant even when high-risk requirements do not apply.

The underlying technology alone does not answer the classification question. The same model can support materially different regulatory outcomes depending on its intended purpose and the decisions it supports.

What does your compliance calendar actually require?

The Act applies in phases, so you need an obligation-by-obligation calendar, not a single compliance deadline. The general application date is 2 August 2026. Annex III high-risk rules apply from 2 December 2027. Annex I product-embedded high-risk rules apply from 2 August 2028. Where Commission materials state conflicting dates, the responsible approach is to record the uncertainty, check the operative Official Journal text and transitional provisions, and mark the affected deadline unverified with a named owner and next review date. 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 does not remove the need to examine exceptions or existing-system provisions.

How do you classify a system and stay classified?

Classify the deployed function and intended purpose, then record the reasons for the result. A verification or decision-support label does not automatically make a consequential workflow low-risk. A useful internal test is whether your team can produce a concise classification cover sheet supported by the underlying analysis. Brevity alone does not make it defensible.

Role is not fixed by purchase. Under the 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. 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. 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.

Failure modes and risk categories requiring documented controls:

• Misclassification — treating a high-risk system as lower-risk because of its technical category rather than its intended purpose.
• Unnoticed role shift — moving from deployer into provider through modification or purpose change without reassessing obligations.
• Incomplete upstream documentation — integrating a third-party model without securing the provider records needed to demonstrate conformity.
• Purpose drift — repurposing a workflow approved for one use into a different consequential decision without reassessment.
• Ineffective oversight — approving controls in policy without evidence that they operate as designed, including failures and interventions.
• Unresolved legal uncertainty — proceeding with a deployment when applicable dates or standards remain genuinely disputed.

What records must you keep and who owns them?

High-risk documentation should connect each legal requirement to evidence that a named person can produce and explain. 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 decisive test is whether the file shows controls operating as designed, including failures, interventions and corrections, rather than merely showing that policies were approved.

The Act requires providers to retain specified documentation, including technical documentation and the EU declaration of conformity, for ten 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.

Concrete controls you must be able to demonstrate:

1. Maintain a system register — document each deployed AI system, its classification, intended purpose, operator role, applicable legal requirements and responsible owner.
2. Record classification reasoning — produce a concise cover sheet for each system supported by underlying analysis that explains why it falls into its assigned risk tier.
3. Operate change control — capture the original purpose, each modification, validation results, human controls and the decision to approve or escalate every change to purpose, model or material workflow.
4. Document upstream provider obligations — secure and retain technical documentation, training-content summaries and conformity evidence from each model provider, with access and retention controls applied to the records themselves.
5. Maintain evidence of control operation — show that oversight procedures, risk mitigations and quality management function as designed, including documented failures, interventions and corrections.
6. Establish a release gate — run a documented checklist before go-live and whenever purpose, model or material workflow changes, with sign-off from a named approver.

What conformity assessment route applies?

The assessment route follows the system's legal category and product context, not your preferred certification process. For most standalone high-risk use cases, the provider's route centres on documented assessment. That still requires a coherent technical file, functioning quality management and evidence that applicable requirements have been met. An internal approval meeting is not 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.

Biometric systems require particular care. Remote biometric identification can require notified-body involvement where relevant harmonised standards or common specifications are not applied or are not fully applied; a generic internal-control assumption is therefore unsafe. 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 does not, by itself, establish conformity with the Act's system-specific requirements.

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.

System transparency and upstream model obligations are separate responsibilities. Connecting a third-party model to your workflow does not transfer all responsibility to the model provider. The Act distinguishes informing people that they are 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 should not be assumed to replace the other.

For procurement and integration, a defensible documentation package includes the model provider's technical documentation, training-content summary, copyright policy, downstream information obligations and, where applicable, evaluation and risk-assessment records for systemic-risk models. External model routing may involve recipients outside the European Economic Area, so your provider and customer arrangements need an applicable transfer mechanism where GDPR Chapter V applies. For a deployment assessment, document what each recipient receives, rather than assuming that transformed context removes every privacy question.

Comparing outputs from independent models can support professional review. Multi-model agreement is not a conformity assessment, does not supply missing provider documentation and does not establish that an answer is correct. The procurement question is therefore specific: what has each upstream provider documented, what can you verify, and what remains unknown?

What are the enforcement consequences?

Breaches of the prohibited-practices rules can attract fines of EUR 35 million or 7 per cent of total worldwide annual turnover for the preceding financial year, whichever is higher. Other breaches can attract EUR 15 million or 3 per cent of turnover. Breaches of obligations by providers of general-purpose AI models can attract EUR 10 million or 2.5 per cent of turnover. These are maximum ceilings, not automatic penalties. The applicable calculation also reflects the Act's treatment of small and medium-sized enterprises, including start-ups; the higher-of formulation should not be applied indiscriminately to them. 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 and should not all be described as attracting the headline maximum.

National competent authorities form part of the enforcement framework, whilst the Commission's AI Office has responsibilities concerning general-purpose AI models. 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.

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 is not a general statement that your organisation uses compliant AI. It is a system register supported by reasoned decisions and accessible evidence. 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 has not purchased a new model.

Verification does not 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. The tooling available to support compliance—model registries, change-control systems, documentation repositories—can carry the administrative burden. What remains your own professional judgement is whether the system's intended purpose, the controls you have designed and the evidence you have gathered actually satisfy the legal test for your deployment.