Building on general-purpose AI models under the EU AI Act

Building products on general-purpose AI models: what you must get and do

A product team or customer now asks whether a product built on a model API or an open-weight model complies with the EU AI Act. Your organization owns its controls and its obligations, and the model provider owes you information under Article 53(1)(b) so you can understand the model's capabilities and limitations and meet your own duties. The Act does not set a price or a duration for this work, so the answer comes from your own scope and your own evidence, not from a fixed fee or timetable.

The answer depends on three questions. First, is the product a high-risk AI system under Annex III or Annex I, or does it fall only into the transparency or minimal-risk tiers? Second, is your organization the provider of the system or only the deployer, which turns on whether you place the system on the market under your own name or modify it substantially? Third, which model, which version and which documentation do you rely on? A model accessed through a hosted API and an open-weight model you run yourself leave you with different information to request and different duties to meet. Write down the answer to each question before you collect any evidence.

If the product is high-risk, ask the model provider now for the information and technical access you will need, and put it in writing. Article 25(4) requires providers and suppliers to agree in writing what information, technical access and assistance is needed, and Article 99(4)(da), added in 2026, makes breaches of Article 25(2) and (4) subject to fines of up to EUR 15 million or 3% of worldwide annual turnover. The Commission's transparency chapter of the GPAI Code of Practice, with its Model Documentation Form, is a useful reference for what to request. Confirm with your counsel which supplier terms apply to your contracts and whether the free and open-source exemptions in Article 25(4) reach your components.

Written agreements for high-risk systems under Article 25(4)

If your organization builds a high-risk AI system on a model or component supplied by someone else, Article 25(4) expects you to agree in writing with that supplier on the information, technical access and assistance you need to meet your own obligations. The supplier is not your compliance program, and you cannot document what you never received. The agreement sets out what crosses the boundary before the system reaches the market.

Information scope: List the technical documentation, capability and limitation details, training data descriptions and performance data you need for your risk management, data governance and technical documentation duties.
Technical access: Specify whether you need API logs, evaluation access, test endpoints or a way to reproduce behavior, and under what confidentiality terms.
Assistance commitments: Name who answers incident questions, who supports conformity assessment, and how quickly support is expected to respond. Avoid vague wording such as "reasonable support."
Change notification: Require notice before the supplier updates, retrains or deprecates a model that your system depends on.
Liability and remedies: Agree how losses are allocated if the supplier withholds information that your compliance file later needs.

Before signing, confirm with your legal and compliance team which Article 25 obligations apply to your role, and ask the supplier which of these items it already provides in standard form.

Transparency duties for chatbots and generated content

This sequence takes a product builder from identifying every point where users meet a chatbot or receive synthetic content, through the design of disclosures and machine-readable markers, to a tested record that shows each duty under Article 50 is met. The outputs are a design record and a tested output marker for each product surface.

Inventory every user-facing output surface
List each product feature where a person interacts with the system directly or receives generated audio, image, video or text, including chat widgets, voice interfaces, drafting tools, summaries, and exports. Assign an owner to each surface, usually the product lead for that feature with input from engineering. Include outputs produced by a general-purpose model you integrate, not only the features you build yourself. The step closes when the list is signed off and every surface is tagged as interactive, generative, or both.
Determine where AI interaction is obvious
For each interactive surface, decide whether a reasonably well-informed, observant and circumspect person would already recognize that they are talking to an AI system. Article 50(1) allows that exception, but it is a judgment about context, so record the reasoning rather than assuming it. Legal or compliance review should confirm borderline cases. The step closes with a written determination per surface, stating either that disclosure is required or why the interaction is obvious in that context.
Design the chatbot disclosure
Where disclosure is required, write the notice and specify when and where it appears, such as before the first message, in the interface header, or in the first response. Ensure the wording is clear to end users and is not buried in terms of service. Product design and legal review approve the wording. The output is a design record containing the disclosure text, placement, screen mock-ups, and the approver's name and date, which an assessor can compare against the live product.
Map which outputs need machine-readable marking
For each generative surface, confirm whether the output is synthetic audio, image, video or text that Article 50(2) covers, and whether it is produced through a general-purpose AI system that you provide or integrate. Note that the duty sits with the provider of the system generating the content, so a product builder on a model API must confirm what its upstream provider already marks and what it must add. The output is a marking map linking each output type to a marking method and an owner.
Check the 2026 marking code and guidelines
Review the Code of Practice on marking and labelling of AI-generated content published by the Commission on 10 June 2026, and the Commission's transparency guidelines dated 20 July 2026. Also review the Commission's opinion on the Code of Practice on Transparency of AI-generated Content dated 9 July 2026. Compare each marking method in your marking map against the practices these documents describe, and decide whether to sign or adopt the code. The step closes with a gap list noting where your design departs from the guidance and the reason for each departure.
Implement and test the output marker
Engineering adds the chosen marking to generated outputs, such as embedded metadata, watermarking, or both, and confirms the marker survives the export paths users rely on, including download, copy, and API responses. Test with generated samples across each output type and each model version in use. Quality assurance records the detection results. The step closes with a test report showing that marked outputs are detectable by the intended method and that unmarked paths have been removed or justified.
Verify disclosures in the live product
Test the chatbot disclosure in each release environment and on each client type, confirming it appears where the design record says it should and that it cannot be dismissed in a way that defeats its purpose. Repeat this check after any change to the model, prompt templates, or interface. Keep dated screenshots or recordings with the design record. The step closes when the test evidence matches the approved design for every interactive surface.
Retain evidence and review on change
Store the inventory, determinations, design records, marking map, gap list, and test reports in a version-controlled location with named owners. Set a trigger to revisit the record when the upstream model provider changes its marking, when a new output type is added, or when the Commission updates its guidance. Confirm with the independent auditor or regulator which evidence they expect, since DeployOpen prepares these records but does not issue any assessment. The step closes when the evidence set is complete and a review owner is named.

When the AI Office, not a national authority, supervises your product

The AI Office is the supervisor for some products built on general-purpose AI, and national authorities are the supervisors for the rest. Under Article 75(1) as amended by Regulation (EU) 2026/1744, the Commission's AI Office is exclusively competent for an AI system built on a general-purpose AI model by the same provider or undertaking that also places the model on the market. The same article gives the AI Office exclusive competence over AI in very large online platforms and search engines. The amendment keeps exceptions, including certain Annex I products, which remain with the sector authorities that already supervise them. Whether your product falls inside the AI Office's competence depends on whether the model and the system come from the same provider or undertaking, so the question is about your corporate structure as much as your technology.

If the model and the system come from different undertakings, such as a product built on a model API from a third party, the system is generally supervised by the national market surveillance authority in the Member States where it is placed on the market or used. Those authorities are named by each Member State, so you need to know which one applies to each market you serve. Several questions decide the answer: whether your group entities count as one undertaking, whether an affiliate trains or fine-tunes the model you deploy, and whether any Annex I exception applies. Ask counsel to map each product line against these questions in writing, and keep that analysis with your AI system inventory so the supervising authority is recorded before you engage with one.

Confirm three things before you plan your engagement with a regulator. First, the supervising authority determines where you file, which authority requests documentation, and who you contact after an incident. Second, the classification can change if your corporate group reorganizes, changes which entity provides the model, or adds an affiliate that modifies it, so review it at each material change. Third, the enforcement timeline and fine structure follow the same article framework for both routes, so the practical difference is the counterparty you deal with. Your counsel and your national authority contacts should confirm the current position for your products.

What to have in place before you ship

Six items decide whether a product built on a general-purpose model can be shipped and defended under the AI Act. Each one is a record you can hold, a decision you can point to, or a contract you can produce on request. Check them before launch, then keep them current as the model changes.

Model inventory with provider and version

List every general-purpose model in each product, with the provider, the exact model name and version, whether the model is accessed through an API or run as open weights, and which product features depend on it. Confirm that the inventory also covers models reached indirectly through a vendor's platform or a third-party component. Without this record you cannot tell which provider documentation applies to which product, or which provider to contact when a model changes.

File of received model documentation

Collect the information each model provider has supplied to you, and store it with the version it describes. Under Article 53(1)(b), providers integrating a model into downstream systems must receive information that lets them understand capabilities and limitations and meet their own duties. Ask each provider whether it follows the transparency chapter of the GPAI Code of Practice and its Model Documentation Form, and check that the file is dated and linked to the inventory entry.

Signed Article 25(4) terms for high-risk use

If the product may become a high-risk system, agree in writing with each model supplier the information, technical access and assistance you will need. Article 25(4) requires this agreement, and it does not apply to free and open-source tools other than general-purpose models. Ask whether the AI Office's voluntary model contract terms are the basis for the agreement, and confirm who signs, who holds the copy, and when the terms are reviewed.

Article 50 design checks

Review each user-facing interface against the transparency duties. If people interact directly with the system, they must be told it is an AI system unless that is obvious to a reasonably well-informed person in context. If the product generates synthetic text, images, audio or video, outputs must be marked in a machine-readable format. Record the test cases, screenshots and marking method used, and check them against the current Commission transparency guidelines before release.

Intended use and limitations record

Write down the purposes the product is built for, the uses it is not designed for, the user groups it serves, and the known failure modes of the underlying model. Link each limitation to a mitigation, such as a restricted feature, a human review step or a warning in the interface. Confirm that the record matches the product documentation and the information your model provider supplied, because a gap between them is the first thing an assessor will test.

Owner for provider model updates

Name one person who receives and reviews every update, deprecation and change notice from each model provider. A new model version can change outputs, limitations and documentation, so the owner decides whether the change needs re-testing, a new documentation request or a change to the Article 25(4) terms. Check that the owner has a route to the product team, a fixed review date for each model in the inventory, and a record of each decision.

Questions builders ask about model providers and the AI Act

Does calling a model through an API make us a provider under the AI Act?

Calling a hosted model through an API does not, on its own, make you the provider of that model. It can make you the provider of the AI system you build on it. The Act generally treats a company that develops an AI system, or has one developed, and places it on the market or puts it into service under its own name as the provider. A company that uses a system under its own authority is a deployer. If your customers receive a product under your brand, you are likely its provider, and the model vendor is the upstream provider of the model. Internal use of a vendor model is usually a deployer role. Confirm the role for each product with counsel, because the answer depends on who places the system on the market, under whose name, and whether you substantially modify it.

What must a general-purpose model provider send us when we build on its model?

The model provider must give you the information and documentation you need to understand the model's capabilities and limitations and to meet your own obligations. Under Article 53(1)(b), this includes at least the elements listed in Annex XII, and the provider may protect its intellectual property and trade secrets while doing so. The Commission says the transparency chapter of the GPAI Code of Practice, with its Model Documentation Form, offers providers a way to meet these duties. Ask for the current form, its version and date, the intended-use and limitation statements, known risks, and a named technical contact. Keep what you receive, with dates and versions, in your own technical file, because an assessor may ask how you learned the model's limits.

Do open-weight models change our duties under the AI Act?

Open-weight models change some duties, but they do not remove the ones that matter most to a product builder. The Act's free and open-source provisions relieve certain obligations for qualifying models, but they do not relieve every duty, and some do not extend to models with systemic risk. Article 25(4) does not apply to free and open-source tools other than general-purpose AI models, so a model's licence does not settle how you contract for a commercial integration. Whether an exemption applies depends on the licence, the commercial terms, and the model's risk classification. Check the Commission's scope guidelines and the model provider's documentation before you assume an exemption. Your own transparency and high-risk duties apply regardless of the model's licence.

What must a written agreement with a model or system supplier cover?

Article 25(4) requires providers and third parties that supply AI systems, models, tools, services, components or processes to agree in writing the information, technical access and assistance needed for compliance. In practice, the agreement should name the documentation you will receive and how it is updated, the technical access you need, such as logs, test endpoints or version history, and the assistance available when something goes wrong. It should also cover notice of model changes, data handling, incident contacts and liability. The AI Office may develop and recommend voluntary model contract terms between providers of high-risk systems and their suppliers, published free of charge, which is a useful starting point for negotiation. Have counsel review the final text against your high-risk use cases.

Do AI Act fines apply to us if we only build on someone else's model?

Yes, if your role under the Act brings you within the obligations. Article 99(4)(da), added in 2026, makes breaches of Article 25(2) and (4) subject to fines of up to EUR 15 million or 3% of worldwide annual turnover, whichever is higher. Most operator obligations carry the same maximum, while prohibited practices carry up to EUR 35 million or 7% of worldwide annual turnover, and misleading information given to authorities carries up to EUR 7.5 million or 1%. Who enforces the rules also varies: national market surveillance authorities handle AI systems, and the AI Office handles general-purpose model rules and, as amended in 2026, AI systems built on a provider's own model. Map each product to a role first, then to its obligations and enforcing authority.

When do the AI Act's obligations for our products apply, and what drives the effort?

The general-purpose model rules have applied since 2 August 2025. Under Article 113, as amended by Regulation (EU) 2026/1744, which was published on 24 July 2026 and entered into force on 27 July 2026, the high-risk rules for Annex III systems apply from 2 December 2027 and for Annex I product systems from 2 August 2028, instead of the earlier dates of 2 August 2026 and 2 August 2027. Confirm these dates against the consolidated text before you set a plan. No preparation duration is fixed by the Act. Effort depends on how many products you ship, how many fall into high-risk uses, how much documentation your model vendor supplies, whether you modify models, and how far your logging and evidence systems already reach. Ask any partner for a plan based on a written scope.

Can our own team prepare for the AI Act, or do we need outside help?

Your team can prepare for the AI Act, and the organization owns its controls and the decisions behind them. Many Annex III high-risk systems use internal control for conformity assessment under Annex VI, so the provider performs the assessment itself. Notified bodies are involved for some biometric systems and Annex I products under Article 43. Outside help usually covers specific gaps, such as preparing systems, logs, technical documentation and evidence, or testing AI systems and agents. DeployOpen plans, implements, integrates and documents self-hosted open-source platforms in your own environment and can prepare systems and evidence for an assessment. It does not issue reports, attestations or certificates, which only independent assessors or certification bodies can do. Agree the scope in writing before work starts.

Dates that set the timeline for product teams

For a product team, the first date to plan around is 2 February 2025, when the Act's definitions, AI literacy duty and prohibited practices began to apply. The general-purpose AI rules, which govern the model provider you build on, have applied since 2 August 2025. The bulk of the Act, including the operator obligations that reach a product built on a model, applies from 2 August 2026 under Article 113. Those dates are already past or fixed, so the practical question for a product team is which of your features fall under them today, and which rules your model provider's obligations will pass down to you through contract terms.

The 2026 amendment, Regulation (EU) 2026/1744, moved the high-risk rules in Chapter III Sections 1 to 3. Annex III high-risk systems now apply from 2 December 2027 instead of 2 August 2026, and Annex I product systems from 2 August 2028 instead of 2 August 2027. Read the amended text on EUR-Lex before you set milestones, because a product that moves into an Annex III category will need its design, documentation and logging ready well before those later dates. Confirm with your legal team which Annex III category, if any, your use case falls into, since that determines whether the 2027 date applies to you at all.

The effort to prepare depends on scope, not on a date. Scope is set by the number of AI features in the product, whether any of them is high-risk, whether you fine-tune or otherwise modify the model, and how many contracts with model providers need written information and assistance terms. Ask your team to list each AI feature against the dates above and to name an owner for each one. A written scope with those inputs is the basis for any internal plan or external quote, and it tells you which milestones fall inside the current release cycle.

How DeployOpen prepares your systems and evidence

DeployOpen plans, builds and documents the self-hosted open-source platforms behind AI products inside your own cloud accounts, data centers or air-gapped networks. For general-purpose AI, we prepare the systems, records and written supplier arrangements that your team and an independent assessor can review.

How we scope

Engagements are fixed-scope, with the systems, deliverables and timelines agreed in writing before work starts.
The written scope lists which model APIs or open-weight models are in use, and which products built on them are covered.
We record which information your model provider has supplied, and which technical details still need to be requested.

How we build

We deploy and harden the self-hosted model serving, logging and access controls within your own infrastructure.
We configure transparency features such as user notices for chatbots and machine-readable marking of generated outputs where the product needs them.
We test the product against the scoped requirements and document the results for your compliance and security teams.

How we hand over

You receive technical documentation, configuration records and test evidence organized against the agreed scope.
We provide draft supplier terms covering information, technical access and assistance for your review with counsel, not as legal advice.
Your team owns the controls and the final decisions, and an independent auditor or certification body issues any report or certificate.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
A retainer can cover updates when a model provider changes its documentation, model version or terms.
Ask for a written quote built from your scope, including which items you would keep in house and which you would outsource.

Building products on general-purpose AI models

Building products on general-purpose AI models: what you must get and do

Written agreements for high-risk systems under Article 25(4)

Transparency duties for chatbots and generated content

Inventory every user-facing output surface

Determine where AI interaction is obvious

Design the chatbot disclosure

Map which outputs need machine-readable marking

Check the 2026 marking code and guidelines

Implement and test the output marker

Verify disclosures in the live product

Retain evidence and review on change