EU AI Act Compliance: Every Obligation, in the Order You Discharge It

A customer sends a security questionnaire and one line reads: "Confirm your EU AI Act compliance status." There is no box to tick and no certificate to attach. The honest answer depends on four facts about your company, and until you have them, anything you write in that box is a guess.

The four facts: what role you play for each AI system (provider under Article 16, deployer under Article 26, importer under Article 23, distributor under Article 24); what risk class each falls into under Article 5 and Article 6; whether it is already on the EU market or still in development; and which duties are live today rather than dated to 2027.

So the verdict, plainly: EU AI Act compliance is not a certificate. It is a stack of dated deliverables — a classification record, a technical file, a signed declaration, a database entry, a monitoring plan — each depending on the one before it. You cannot run an Article 43 conformity assessment before an Article 17 quality management system exists, or register under Article 49 before signing a declaration under Article 47. That order is the dependency chain the Regulation builds in, and getting it wrong costs months.

This page walks that stack from the top.

---

What EU AI Act Compliance Actually Requires

EU AI Act compliance means discharging the specific duties Regulation (EU) 2024/1689 assigns to your role — provider, deployer, importer or distributor — for each AI system you place on or use in the EU market, and holding dated evidence that you did.

Duties attach per system and per role, not per company. The same business can be a provider of one system, a deployer of three more, and out of scope for a fourth. There is no organisation-wide compliance state to achieve — there is a register of systems, each with its own verdict.

Nine steps, in order:

1. Inventory every AI system you build or use
2. Fix your role for each system
3. Classify each system against Articles 5 and 6
4. Discharge the duties already in force
5. Build the Article 9–15 requirement set
6. Wrap it in an Article 17 quality management system
7. Pick your Article 43 conformity-assessment route
8. Declare, mark and register under Articles 47, 48 and 49
9. Run post-market monitoring under Articles 72 and 73

Four variables set how much of that stack you owe. Your role decides whether you build evidence or consume it. Your risk class decides whether steps 5 to 9 exist for you at all. Annex III decides which conformity route applies. And whether the system is already on the market decides whether you are retrofitting or designing.

On dates, two matter for the heavy stack. High-risk obligations apply from 2 December 2027 (Annex III stand-alone) and 2 August 2028 (Annex I product-embedded), as amended by Regulation (EU) 2026/1744 (in force 27 July 2026). Everything else has already arrived: Article 4 AI literacy, the Article 5 prohibitions and Article 50 transparency all apply today. For the instrument itself, read Regulation (EU) 2024/1689 explained or the practical guide for smaller companies.

---

Step 1 — Inventory Every AI System You Build or Use

Nothing downstream works without a complete list. You cannot classify a system you have not catalogued, and classification run against a partial inventory produces a file that is confidently wrong.

A usable row is not a name and an owner. It carries: the system and its version; its intended purpose under Article 3(12), in the words the vendor or your product team actually use; your role for it; the supplier and whether it is established in the EU; what data goes in and what decision comes out; whether a natural person is affected; and a named owner who can answer questions without escalating.

The usual gap is unsanctioned tooling. A recruiter running CVs through a browser extension, a support lead piping tickets into a summariser, a finance analyst scoring suppliers in a spreadsheet plug-in — none appear in procurement records, and all can carry obligations. Start from expense data and browser telemetry, not the IT asset register, which shows only what was bought centrally.

The inventory is maintained, not produced once, which needs a named person with authority to demand answers — see who owns this inside a company and the governance operating model that staffs this work. For the register itself, see building an AI system inventory.

---

Step 2 — Fix Your Role Before You Read Another Article

Get this one wrong and every page you read afterwards is the wrong page. Every obligation hangs off a role, and companies that skip the question work through provider requirements they do not owe, or — far more expensively — miss that they became a provider.

Article 3(3) defines a provider as the party that develops an AI system, or has one developed, and places it on the market or puts it into service under its own name or trademark. A deployer uses one under its own authority in a professional capacity; importers and distributors move someone else's system into and through the EU market.

The Article 25 flip that catches resellers

Article 25 turns a comfortable deployer into a provider carrying the entire stack. Three triggers do it, and any one is enough.

You put your own name or trademark on a high-risk system already on the market. You make a substantial modification to it — Article 3(23): a change not foreseen in the provider's initial conformity assessment that affects compliance or alters the intended purpose. Or you change a system's intended purpose so that it becomes high-risk when it was not.

White-labelling is the common trap. A SaaS company licenses a scoring engine, wraps it in its own interface, sells it under its own brand and tells itself it is reselling. Under Article 25 it is the provider, and the vendor's technical file does not transfer: the Annex IV file, the Article 43 assessment and the Article 47 declaration land on the company whose name is on the product.

Fine-tuning sits in the same territory: adapting a third-party model on your own data, for a purpose the original provider never assessed, is the change Article 3(23) contemplates.

Decide this per system, not per company — most businesses wear two hats. See how obligations move along the AI value chain, the full provider obligation checklist under Article 16 if you ship anything, what Article 26 requires of deployers if you mostly buy, and, if you sell software, whether a SaaS company is provider, deployer, or both plus the Article 16 duties for a SaaS provider.

---

Step 3 — Classify Each System and See What It Triggers

Run each inventory row through the same test, in order. An earlier answer ends it.

Article 5 first. If the system does what Article 5 prohibits — social scoring under 5(1)(c), subliminal manipulation under 5(1)(a), emotion recognition in the workplace or in education under 5(1)(f), real-time remote biometric identification in public spaces for law enforcement under 5(1)(h) — you stop. No compliance path, prohibited since 2 February 2025, heaviest penalty tier. Note the workplace point: emotion recognition on employees is prohibited, not high-risk. A sentiment-analysis tool filed as "high-risk, we'll handle it in 2027" is filed wrong.

Article 6(2) next, against Annex III: biometrics; critical infrastructure; education; employment and worker management; access to essential private and public services (creditworthiness and credit scoring in, fraud detection out, life and health insurance risk and pricing in); law enforcement; migration, asylum and border control; justice and democratic processes. An intended purpose that lands in one of those is presumptively high-risk — see the eight Annex III high-risk areas.

Article 6(1) is the other high-risk route: a system that is a safety component of a product covered by EU harmonisation law listed in Annex I, or is itself such a product, where that product needs third-party conformity assessment. Medical devices and in-vitro diagnostics are the common cases — later clock, 2 August 2028, through sectoral law.

Then Article 50: chatbots, synthetic content, emotion-recognition and biometric-categorisation systems and deepfakes carry transparency duties whatever else they are. Finally, minimal risk — no mandatory obligations, where most business software lands.

The Article 6(3) filter, honestly stated

Article 6(3) lets an Annex III system out of the high-risk category if it poses no significant risk of harm to health, safety or fundamental rights. Four conditions carry it, drafted narrowly. The system performs a narrow procedural task. It improves the result of a previously completed human activity. It is intended to detect decision-making patterns or deviations from prior decision-making patterns and is not meant to replace or influence the previously completed human assessment, without proper human review. Or it performs preparatory work for an assessment.

Read the third one twice. The qualifiers are load-bearing: it is drafted against an assessment that has already happened, so a tool scoring an application while a human is still deciding is influencing a live decision, not detecting a prior pattern.

Only one condition need be met, which makes the filter useful and under-used. But it has a hard stop: any system that profiles natural persons is always high-risk, whichever condition you think you meet.

Article 6(4) carries what survives. You must document the assessment before placing the system on the market or putting it into service, you are subject to the registration obligation in Article 49(2), and you must hand the documentation to a national competent authority on request. An undocumented exemption is indistinguishable from an unclassified system when an authority asks. For the full test, see the four risk tiers.

Where general-purpose models sit

General-purpose AI models are a separate category under Chapter V, not a fifth risk tier. Build on a third-party model from a provider such as OpenAI, Mistral, Google or Meta and you are not the model provider — those Chapter V duties stay with them. Your obligations attach to the system you build and the purpose you build it for: an LLM is not high-risk in itself, a CV-screening system built on one is. See obligations attached to general-purpose AI models and the two open-source carve-outs.

---

Step 4 — Discharge What Is Already in Force

Three sets of duties bind you today, and a 2027 deadline on the high-risk stack postpones none of them. A national authority can act on these now.

Article 4 requires providers and deployers to take measures to support the development of AI literacy among staff and others operating AI systems on their behalf, taking into account their technical knowledge, experience and the context of use. It applies to all AI systems — minimal risk included — since 2 February 2025. No small-company exemption, no threshold below which it switches off.

What satisfies it is proportionate, not elaborate: role-differentiated training, a record of who received what and when, refreshers when systems or roles change. An all-hands slide deck with no attendance record is not evidence. See the Article 4 AI literacy duty.

The Article 5 prohibitions are live from the same date. Run the check against your inventory, document the result, re-run it when a purpose changes.

Article 50 transparency applies now — 2 August 2026 has passed, and general application arrived with it. Four sub-paragraphs, and the split between roles is what most explainers get backwards: paragraphs 1 and 2 bind the provider, paragraphs 3 and 4 the deployer.

• 50(1) — a provider must design and develop AI systems intended to interact directly with natural persons so that those persons are informed they are interacting with an AI system, unless that is obvious to a reasonably well-informed, observant and circumspect person. If you built the support chatbot you ship or run, this is your duty; if you bought it, it is your vendor's.
• 50(2) — a provider of a system generating synthetic audio, image, video or text must mark outputs as artificially generated, in a machine-readable format. Providers of such systems placed on the market before 2 August 2026 have until 2 December 2026 to meet the marking duty.
• 50(3) — deployers of emotion-recognition or biometric-categorisation systems must inform the people exposed to them.
• 50(4) — deployers must disclose deepfake content, and AI-generated text published to inform the public on matters of public interest.

A separate measure shares that December date, and it is not an Article 50 duty. Regulation (EU) 2026/1744 adds new Article 5 prohibitions on AI systems generating child sexual abuse material and on "nudifier" applications producing non-consensual intimate imagery, applying from 2 December 2026. That is a prohibition in the €35,000,000 or 7% tier, not a transparency duty — do not file it under Article 50.

Article 50 breaches themselves sit in the €15,000,000 or 3% tier. A chatbot with no disclosure line is cheap to fix this month and expensive to explain next year.

---

Step 5 — Build the Article 9–15 Requirement Set

High-risk verdict at Step 3? Then seven articles land at once, and this is where the nine to twelve months go. Treat each as an artefact you hand an auditor with a name and a date on it, not a principle to endorse.

Article 9 — a risk file that keeps moving

Article 9 requires a continuous, iterative risk management system across the lifecycle: identify foreseeable risks to health, safety and fundamental rights, estimate risks from intended use and reasonably foreseeable misuse, evaluate risks from post-market data, adopt targeted measures. Article 8 is the chapeau introducing the requirement set, not the risk management article. The deliverable is a living file with dated revisions. See building an Article 9 risk management system.

Data governance means datasets, not staff training (Article 10)

Article 10 governs the training, validation and testing datasets: relevance, representativeness, error levels, statistical properties, examination for possible biases, and the collection processes and provenance behind them. Data governance in the dataset sense — not staff training, and not your data-protection programme, though the two overlap. The deliverable is a provenance and bias record per dataset. See Article 10 data governance in practice.

The Annex IV technical file, and why it starts here (Article 11)

Article 11 requires technical documentation drawn up before the system is placed on the market and kept current, with content specified across the nine areas of Annex IV — system description, development process, monitoring and control, risk management, changes, standards applied, the declaration and the post-market plan. It is the largest artefact and the one everything else feeds. Start it here, not at Step 7. See assembling the Article 11 and Annex IV technical file.

Article 12 — logging designed in, not bolted on

Article 12 requires high-risk systems to technically allow automatic recording of events over their lifetime, enabling traceability appropriate to the intended purpose. The deliverable is a logging design: what is recorded, at what granularity, how it is protected, how long it is kept. The retention floor sits in Article 19 — at least six months, subject to other applicable law. See logging and record-keeping under Article 12.

Instructions a deployer can act on (Article 13)

Article 13 requires the system to be transparent enough for deployers to interpret its output and use it appropriately, with instructions for use stating the provider's identity, the system's characteristics, capabilities and limitations, its accuracy, foreseeable circumstances that may pose risk, the oversight measures and the expected lifetime and maintenance. Write these for the deployer's actual job: if your customers owe a fundamental rights impact assessment under Article 27, your instructions supply its input. See the Article 13 instructions-for-use duty.

Article 14 — oversight someone can actually exercise

Article 14 requires the system to be designed so natural persons can effectively oversee it in use — understanding its capacities and limits, staying alert to automation bias, interpreting output correctly, deciding not to use it, intervening or stopping it. The deliverable is a design record plus evidence that the assigned people hold the competence, training and authority the article requires. A named overseer with no power to halt the system does not satisfy it. See designing Article 14 human oversight that works.

Accuracy, robustness and cybersecurity, evidenced (Article 15)

Article 15 requires an appropriate level of accuracy, robustness and cybersecurity, consistent performance across the lifecycle, resilience to errors and faults, and resistance to attempts to alter use or performance by exploiting vulnerabilities, including data poisoning and adversarial examples. Declared accuracy metrics go into the instructions for use, linking back to Article 13. The deliverable is test evidence with methodology, thresholds and results. See Article 15 accuracy, robustness and cybersecurity evidence.

Skip one and the gap surfaces at Step 7, when you cannot assess conformity against a requirement set with a hole in it.

---

Step 6 — Wrap It in a Quality Management System (Article 17)

The quality management system comes after the requirement set for a practical reason. Article 17 asks you to show the Article 9–15 work is repeatable — that the next release, dataset version and incident will be handled the same way. You cannot document a process you have not run.

Article 17 requires providers of high-risk systems to put a quality management system in place, documented in written policies, procedures and instructions, covering a set list: a regulatory compliance strategy including conformity assessment and change management; design and design-control procedures; development, quality control and verification; testing and validation; technical specifications and standards applied; data management; the Article 9 risk management system; post-market monitoring under Article 72; incident reporting under Article 73; communication with authorities and notified bodies; record-keeping; resource management, including security-of-supply measures; and an accountability framework setting out the responsibilities of management and staff.

That list reads like it needs a quality department. It does not. For a company of roughly 100 people, a proportionate Article 17 system is a document set with owners and review dates — perhaps fifteen to twenty-five procedures, most two pages, many formalising what your engineers do already. Article 17(2) requires proportionality to the size of the provider's organisation, so an ISO-scale management system quoted for a two-product company sells beyond the requirement. If you already run ISO/IEC 42001 or align to the NIST AI RMF, much of the structure carries over.

Two retention rules belong here. Article 18 requires the technical documentation, the QMS documentation, notified-body decisions where applicable and the EU declaration of conformity to be kept at the disposal of national authorities for ten years after the system is placed on the market or put into service. Article 19 sets a six-month floor on automatically generated logs. Different clocks on different artefacts: a system retired in 2030 still carries files into 2040.

See the Article 17 quality management system.

---

Step 7 — Pick Your Conformity-Assessment Route (Article 43)

Most readers arrive at Article 43 expecting an external auditor and a bill. For Annex III points 2 to 8 they get neither, and that finding usually rewrites the budget.

Annex III point 1 — biometrics. Article 43(1) gives you a choice, but only if you have earned it. Where you have applied the harmonised standards under Article 40 or the common specifications under Article 41, you may elect either Annex VI internal control or Annex VII assessment by a notified body. Where those standards do not exist, you did not apply them, or you applied them only in part, Annex VII is mandatory. AI Act harmonised standards are still thin in 2026, so plan for a notified body and treat internal control as the upside. One carve-out: where the system is used by law enforcement, immigration or asylum authorities, or by an EU institution, the market surveillance authority acts as the notified body.

Annex III points 2 to 8. The route is Annex VI — internal control. You assess conformity yourself, against your own quality management system and technical documentation. No notified body, no external audit, no fee. Employment, credit scoring, education, essential services: all self-assessed. The most over-feared step in the stack.

Annex I product-embedded systems. Conformity runs through the sectoral regime that already governs the product — the Medical Devices Regulation and IVDR are the clearest cases — with the AI Act requirements folded into the existing assessment, not bolted alongside it. Clock: 2 August 2028.

Two points to hold onto. Article 43 requires a fresh assessment when a system is substantially modified, so the route you pick is not a one-time cost. And Article 62(2) requires the specific interests and needs of SME and start-up providers to be taken into account when Article 43 conformity assessment fees are set, and those fees to be reduced proportionately to the provider's size, the market size and other relevant indicators.

See choosing your Article 43 conformity-assessment route.

---

Step 8 — Declare, Mark, Register (Articles 47, 48, 49)

Three acts make a high-risk system legally placeable; two real dependencies order them.

First, declare. Under Article 47, the provider draws up a written, machine-readable, physically or electronically signed EU declaration of conformity for each high-risk system, keeps it at the disposal of national authorities for ten years, and supplies a copy on request. Annex V fixes the content: the system's name and identification, the provider's details, a statement that the declaration is issued under the provider's sole responsibility, the standards or specifications applied, and any notified body's details. Signing it is an act of legal responsibility, not a formality.

Then mark. Article 48 governs the CE marking, affixed visibly, legibly and indelibly, or — for digitally provided systems — through a digital CE marking that is easy to access. Where a notified body was involved, its identification number accompanies the marking.

And register. Article 49 requires the provider to register itself and the system in the EU database before placing an Annex III high-risk system on the market or putting it into service. The data to be entered sits in Annex VIII; the database itself is established by Article 71. Registration also applies where you concluded under Article 6(3) that your Annex III system is not high-risk. Public-authority deployers of Annex III systems register too.

The dependencies run one way, and there are two. The declaration must exist before you affix the marking, because the marking asserts the declaration. And it must exist before you register, because Annex VIII requires a copy of the Article 47 declaration in the registration entry itself. Marking and registration do not depend on each other — but all three must be done before the system is placed on the market. Any team that books a "CE marking workstream" before the technical file is closed has bought a date it cannot meet.

See applying CE marking under Article 48 and registering in the EU database under Article 49.

---

Step 9 — Run It After Launch (Articles 72, 73, 20, 21)

Compliance does not end at the CE marking; four articles govern the running system.

Article 72 requires the provider to establish and document a post-market monitoring system proportionate to the system and its risks, based on a plan forming part of the Annex IV technical documentation. You collect and analyse performance data across the system's lifetime and feed it back into the Article 9 risk file. This is the provider's own duty — not market surveillance, the authority's function under Article 74 and following. See your Article 72 post-market monitoring plan.

Article 73 requires providers to report serious incidents to the market surveillance authority of the Member State where the incident occurred, immediately after establishing a causal link, and in any event no later than 15 days after becoming aware of the incident. Two shorter clocks cut across that. Article 73(3): a widespread infringement, or a serious and irreversible disruption of critical infrastructure under Article 3(49)(b), must be reported immediately and no later than 2 days. Article 73(4): where a person has died, report immediately on establishing or suspecting a causal link, and no later than 10 days.

Article 3(49) defines a serious incident: death or serious harm to health, serious and irreversible disruption of critical infrastructure, breach of fundamental-rights obligations, serious harm to property or the environment. Two days is a weekend. Decide now who makes that call at 9pm on a Friday, and write the name into the quality management system. See reporting serious incidents under Article 73.

Article 20 requires corrective action where a system you placed on the market no longer conforms: bring it into conformity, withdraw, disable or recall it, and inform distributors, deployers, the authorised representative and importers. Article 21 requires you to give authorities, on a reasoned request, the information and documentation needed to demonstrate conformity, in a language they readily understand. See cooperating with authorities under Article 21.

---

If You Are a Deployer, Your Stack Is Much Shorter

Most companies reading this are deployers on most of their systems, and that stack is a fraction of the provider's.

Article 26 collects the duties. Use the system in accordance with the instructions for use. Assign human oversight to natural persons with the necessary competence, training and authority, and support them — the Article 14 design only works if the operator can actually stop the system. Ensure input data is relevant and sufficiently representative for the intended purpose, so far as you control it. Monitor operation, inform the provider and the authority where you identify a risk or serious incident, and suspend use where appropriate. Keep the automatically generated logs you control for at least six months. Where you deploy a high-risk system at the workplace, inform affected workers and their representatives first. And where an Annex III high-risk system makes or assists decisions about natural persons, inform those persons that they are subject to its use.

Article 27 — the fundamental rights impact assessment — binds a narrower set than most vendor content implies: deployers that are bodies governed by public law or private entities providing public services, and deployers of creditworthiness systems under Annex III point 5(b) and life and health insurance risk-and-pricing systems under point 5(c). A private employer deploying a CV-screening tool owes no FRIA — it may still owe a data protection impact assessment under GDPR Article 35, a different instrument with different content. Article 27(4) lets a FRIA build on an existing DPIA rather than duplicate it. See when a FRIA is required and how it differs from a DPIA.

The relief, plainly: as a deployer you owe no CE marking, no conformity assessment and no Annex IV technical file — and no Article 49 registration unless you are a public authority, a Union institution, body, office or agency, or someone acting on their behalf, who must register the use under Article 49(3), or unless the Article 25 flip has made you a provider. What you do owe, on every system including minimal-risk ones, is Article 4 literacy.

Your moment to act is procurement, before signature: demand the instructions for use, the declaration of conformity and the classification the vendor applied. See assessing an AI vendor before you deploy, what Article 26 requires of deployers and, for an unusually dense deployer stack, the checklist for healthcare deployers.

---

The Duties Outside the Product: Representative, Importer, Distributor

Three roles complete the chain, easy to miss because they sit outside product work.

A provider established outside the EU must, under Article 22, appoint an authorised representative established in the Union by written mandate before making a high-risk system available on the EU market. The representative verifies the declaration and technical documentation and keeps them available to authorities for ten years. It also must terminate the mandate if it considers, or has reason to consider, that the provider is acting contrary to its obligations — informing the market surveillance authority immediately, and the notified body where applicable, of the termination and its reasons. That duty makes the representative a control rather than a mailbox. See appointing an authorised representative under Article 22.

An importer under Article 23 must verify, before placing the system on the market, that conformity assessment was carried out, the technical documentation exists, the CE marking and declaration are in place, and an authorised representative was appointed where needed. A distributor under Article 24 runs a lighter check on onward supply: CE marking affixed, declaration and instructions accompanying the system, provider and importer duties met — and must not supply one it has reason to consider non-conforming. See importer duties before an AI system enters the EU and what distributors must verify under Article 24.

---

What It Costs and How Long It Takes

Anchor the plan on this: a first technical file plus conformity assessment on one high-risk system is nine to twelve months of structured work. Not of effort — of elapsed time, because dataset documentation, testing evidence and oversight design depend on release cycles you do not control.

Four things drive the number. How many high-risk systems you have — the second costs perhaps 40% of the first, because the Article 17 system and the templates already exist. Whether a notified body is in play, which adds scheduling risk more than fee risk. Your evidence maturity: teams with existing test records and dataset documentation start halfway up. And the headcount assigned, which in companies under 250 people is usually one part-time owner, not a team.

Those figures are our judgment from the shape of the work, not numbers the Regulation states. 2 December 2027 reads as distant in September 2026; it is roughly five quarters away, and the work has to start before the last two. See a full implementation roadmap from zero, what EU AI Act compliance actually costs, and free documentation starting points if you would rather not draft the first version of each artefact from a blank page.

---

Penalties: Three Tiers, and the SME Cap

Article 99 sets exactly three maximums.

Two details change the arithmetic for smaller companies. Under Article 99(6), for small and medium enterprises including start-ups, each fine is capped at the lower of the percentage and the fixed sum — not the higher, the default for larger undertakings. And fines on providers of general-purpose AI models are imposed by the Commission under Article 101, a separate regime from the Article 99 tiers.

The third tier deserves a second look: getting the paperwork wrong in front of an authority is its own offence, whatever the underlying system's status.

---

Worked Example: Bancred Systems BV

Bancred Systems BV, Utrecht, roughly 110 employees and about €21 million annual turnover, sells a creditworthiness-scoring module to Dutch and Belgian lenders under its own brand. Three systems sit on its inventory.

System 1 — the scoring module. Sold under Bancred's own name, so Bancred is the provider under Article 16. Its intended purpose is evaluating the creditworthiness of natural persons: Annex III point 5(b). The compliance lead tries the Article 6(3) filter and closes it in one line — the module profiles natural persons and influences the lending decision rather than detecting a prior decision pattern. High-risk, no exemption, deadline 2 December 2027. Route: point 5(b) is not point 1, so Annex VI internal control, self-assessed, no notified body. That is the finding that changes the budget.

System 2 — a third-party recruitment-screening tool used internally. Bancred is a deployer under Article 26: follow the instructions for use, assign a competent overseer in HR with authority to stop it, keep logs, inform staff and their representatives before it goes live, and tell affected candidates they are subject to an Annex III system. No FRIA under Article 27 — Bancred is neither a public body nor an Annex III 5(b) or 5(c) deployer — though a GDPR Article 35 DPIA is likely.

System 3 — a customer-facing chatbot Bancred built on a third-party general-purpose model. Bancred developed it and put it into service under its own name, so Bancred is the provider of that system and owes the Article 50(1) disclosure by design, now. It is not the model provider and owes nothing under Chapter V.

The value-chain twist is the judgment worth copying. Bancred's lender customers are deployers of an Annex III 5(b) system, so they owe the Article 27 FRIA. Bancred does not — but its Article 13 instructions must give those lenders the accuracy metrics, limitations and oversight design their FRIA depends on. Ship thin instructions and you lose renewals to a customer who cannot close their file.

The dated verdict. This quarter, two things: the Article 50(1) chatbot disclosure and the Article 4 literacy programme with attendance records, both already due. Then, across five quarters: Article 9–15 evidence on System 1, an Article 17 system around it, Annex VI self-assessment, an Article 47 declaration, Article 48 CE marking and Article 49 registration before 2 December 2027 — then the Article 72 plan that keeps running afterwards.

---

How Confir Helps

Confir registers every AI system you build or deploy, derives the role for each, and runs the classification and requirement checks through plain-English intake — then generates the Annex IV technical documentation pack, the Article 47 declaration and the Article 27 FRIA where it is owed. The engine is deterministic and rule-based: same intake, same finding, every rule that fires human-readable, the audit log immutable. That is what makes a file defensible two years after the person who filled it in has left.

---

Frequently Asked Questions

Is there an official EU AI Act certificate we can obtain?

No. The Regulation creates no certification scheme for companies. What exists is a per-system evidence set: a documented classification, the Article 9–15 file, a conformity assessment under Article 43, a signed declaration under Article 47, CE marking and a database registration. When a customer asks whether you are compliant, the answer is a list of systems with their classifications and dates, not a badge.

We only use ChatGPT and a CRM with some AI features. What do we actually owe?

Probably three things. Article 4 AI literacy, which applies to all AI and is already in force. An inventory entry for each tool with its classification recorded, so you can answer it next time in a minute. And a check that any customer-facing chatbot actually carries its AI disclosure — that disclosure is the provider's duty under Article 50(1), so make it a procurement question, not a build task. No technical file, no CE marking, no registration — you are a deployer.

Which comes first, the technical file or the conformity assessment?

The technical file. Article 43 assesses the system against your Article 17 quality management system and your Annex IV documentation, so both must exist before the assessment starts. Teams that schedule conformity work first end up assessing an incomplete file and repeating it. The order is requirement set, then QMS, then assessment, then declaration, then marking and registration.

Our vendor's system carries CE marking. Does that cover us?

It covers their conformity, not your deployment. As a deployer you still owe Article 26: use the system per the instructions, assign competent human oversight with authority to intervene, keep logs, inform affected workers and affected individuals. And check Article 25 — if you rebrand the system, change its intended purpose or substantially modify it, the vendor's marking stops covering the product you are now selling.

We are based outside the EU. Does this reach us?

Yes, if you place an AI system on the EU market, put one into service in the EU, or the output produced by the system is used in the Union. Non-EU providers of high-risk systems must also appoint an authorised representative established in the Union under Article 22, by written mandate, before the system is made available. Where your servers sit does not decide it.

Will we need a notified body?

Most likely not. Annex III point 1, biometrics, is the only area where a notified body can be required — and under Article 43(1) even there you may elect Annex VI internal control if you have applied the harmonised standards in full. Annex III points 2 to 8 — employment, credit scoring, education, essential services — run through Annex VI, which you carry out yourself. Annex I product-embedded systems use their existing sectoral assessment. Article 62(2) also requires reduced fees for smaller providers.

---

Related guides

• How obligations move along the AI value chain
• The full provider obligation checklist under Article 16
• What Article 26 requires of deployers
• Assembling the Article 11 and Annex IV technical file
• Choosing your Article 43 conformity-assessment route
• Registering in the EU database under Article 49
• Your Article 72 post-market monitoring plan
• Reporting serious incidents under Article 73
• A full implementation roadmap from zero