EU AI Act Deadlines: Every Date and What Deployers Must Do
EU AI Act deadlines after the Digital Omnibus: Annex III high-risk rules start Dec 2, 2027, Article 50 applies now. Deployer duties, logs to keep, fines.
Luka Abramovic23 min read
The EU AI Act deadlines moved in July 2026 for high-risk AI, and mostly stayed put for everything else. Regulation (EU) 2026/1744, the "Digital Omnibus on AI", in force since July 27, 2026, pushed the obligations for Annex III high-risk systems, such as CV screening and credit scoring, from August 2, 2026 to December 2, 2027. Article 50's disclosure duties did not move: since August 2, 2026, a customer-facing chatbot has had to tell people they are dealing with AI, and a line in your terms and conditions does not count. Scoring job candidates' emotions from video interviews has been banned since February 2, 2025.
This list covers every application date and what each requires of a business that uses AI in its operations rather than building models. The last column of the main tables is ours: what your system has to log, show or keep. The Act follows the output (Art. 2(1)(c)), so it also covers businesses in the US, Canada, the UK, Australia, Saudi Arabia, the UAE, Qatar and Bahrain whose AI output is used in the EU. Checked in September 2026 against the Official Journal text. This is a practical summary, not legal advice; the authoritative version is the consolidated text on EUR-Lex.
EU AI Act deadlines and their status as of September 2026
The dates come from Article 113 of the AI Act as amended by Regulation (EU) 2026/1744. Nothing in this table is still a proposal. The Commission proposed the Omnibus on November 19, 2025, the Council gave its final approval on June 29, 2026, and it was published in the Official Journal on July 24, 2026. The Commission keeps its own timeline on the AI Act Service Desk.
| Date | What starts to apply | Status | What a deployer needs in place |
|---|---|---|---|
| Aug 1, 2024 | Regulation (EU) 2024/1689 enters into force | Law | Nothing yet. The clock starts. |
| Feb 2, 2025 | Definitions, AI literacy (Art. 4) and the eight original prohibited practices (Art. 5) | Law, applying | No banned practice in use. A record of AI literacy measures. |
| Aug 2, 2025 | General-purpose AI model obligations, governance, national authorities, the penalty framework | Law, applying | Mostly for model providers. Your national authorities and penalty rules now exist. |
| Aug 2, 2026 | General application date: Art. 50 transparency, national supervision of Art. 4, the Commission's power to fine general-purpose model providers (Art. 101) | Law, applying. Not delayed by the Omnibus | Chatbot and agent disclosures, deep fake and public-interest text labels, emotion recognition notices. |
| Dec 2, 2026 | Two new bans: AI generating non-consensual intimate images and child sexual abuse material (Art. 5(1)(ba) and (bb)). End of the machine-readable marking grace period for generative systems on the market before Aug 2, 2026 (Art. 111(4)) | Law, added by the Omnibus | Confirm your generative tools' vendors mark their output. |
| Aug 2, 2027 | Deadline for general-purpose AI models placed on the market before Aug 2, 2025 (Art. 111(3)) | Law | A vendor question only. This was also the original date for product-embedded high-risk AI, now moved. |
| Dec 2, 2027 | Chapter III, Sections 1 to 3, for Annex III high-risk systems: classification, requirements, and provider and deployer obligations, including Arts. 26 and 27 | Law. Was Aug 2, 2026 | Everything in the deployer obligations table. |
| Aug 2, 2028 | Chapter III, Sections 1 to 3, for Annex I high-risk systems: AI that is a safety component of a product under EU product laws, such as medical devices or toys | Law. Was Aug 2, 2027 | For manufacturers and users of those products. |
| Aug 2, 2030 | High-risk systems intended for public authorities that were already in service must comply (Art. 111(2)) | Law | Public bodies and their suppliers. |
What the Omnibus changed for deployers, and what it left alone
- Changed: the high-risk start dates; Article 4 on AI literacy (see below); Article 27(4), so a fundamental rights impact assessment can cross-reference your GDPR data protection impact assessment (DPIA) instead of repeating it; and the transition rule for systems already in service, which now follows the new dates (Art. 111(2)).
- New: Article 4a lets deployers process special-category data, such as ethnicity or health, to detect and correct bias, under strict conditions.
- New: the fine relief for small and medium-sized enterprises (SMEs) extends to small mid-cap enterprises (SMCs), except for prohibited practices (see penalties).
- Kept: a provider that decides an Annex III system is not high-risk must still document that and register the system in the EU database. The Omnibus only shortened what the registration contains.
- Unchanged: the Article 26 deployer obligations, the substance of Article 50, and the fine ceilings.
What is still not final is guidance. The Commission's guidelines with practical examples of high-risk and non-high-risk systems were due under Article 6(5) by February 2, 2026. They appeared as a draft for consultation instead, the consultation closed on July 23, 2026, and the Commission says the final version will be adopted by the end of 2026.
This week: put December 2, 2027 in the plan for any Annex III system, and treat Articles 5 and 50 as live today.
Deployer or provider: the test that decides which duties are yours
A deployer is anyone using an AI system under its authority in a professional capacity (Art. 3(4)). A provider develops an AI system, or has one developed, and places it on the market or puts it into service under its own name (Art. 3(3)). "Putting into service" includes supplying a system "for own use" (Art. 3(11)). So a company that has a developer build an AI system and runs it internally under its own name is that system's provider, not only its deployer. The Commission's Article 50 guidelines add that employees and contractors operating a system on the company's behalf are not separate deployers. The company is.
Article 25(1) makes you the provider of a high-risk system in three further ways: you put your name or trademark on it, you make a substantial modification to it, or you change the intended purpose of a system that was not high-risk, including a general-purpose AI system, so that it becomes high-risk.
| Setup | Your role | What changes |
|---|---|---|
| An HR suite ranks applicants, and you use it as the vendor intends | Deployer of a high-risk system | Article 26 duties from December 2, 2027. The vendor carries the provider duties: risk management, technical documentation, conformity assessment, registration. |
| A developer builds you a CV-ranking tool that you run under your company name | Provider and deployer | Provider duties under Article 16 as well as Article 26, from December 2, 2027. Article 25(4) requires a written agreement with each supplier of models, tools and components setting out the information and access you need, and the Omnibus put breaches of it in the €15 million or 3% fine tier. |
| Staff paste applications into a general-purpose chatbot and ask it to shortlist | In our reading of Article 25(1)(c), provider, because you changed the system's purpose to a high-risk one | Every provider duty for a system you never designed. The practical fix is a written rule that the tool is not used for this, and a check that it isn't. |
| You put a chatbot built on a model API on your website | Provider of that chatbot | The Article 50(1) disclosure is yours to design, not the model vendor's. |
| A company outside the EU, such as a US or UAE firm, screens candidates for its Dublin office | Deployer or provider under Article 2(1)(c), because the output is used in the EU | The same duties as an EU company. |
This week: for each AI tool, write down whether you bought it, had it built or repurposed it. The second and third answers are where provider duties hide.
Already in force: banned practices and AI literacy
Article 5: where the bans fall for ordinary business tools
Eight practices have been banned since February 2, 2025. For most businesses the one that matters is Article 5(1)(f): AI that infers the emotions of people at work or in education, except for medical or safety reasons. The Commission's guidelines on prohibited practices draw the lines.
| Tool | Status | Why |
|---|---|---|
| Video-interview software that scores candidates' emotions from face or voice | Banned since February 2, 2025 | The guidelines list emotion recognition during recruitment and during a probation period as workplace uses. |
| Call-center analytics that flags agents' anger or stress from their voices | Banned | Employees' emotions, inferred from biometric data, at the workplace. |
| The same analytics applied only to callers, to help agents cope | Not banned, provided no employees are tracked. Needs an Article 50(3) notice now and is high-risk (Annex III point 1(c)) from December 2, 2027 | Customers are not in a workplace relationship with you. |
| Sentiment scoring of customer emails, chats or survey answers | Outside the emotion recognition rules | Emotion recognition requires biometric data (Art. 3(39)). Written text is not biometric. |
| "Wellbeing" tools that detect burnout or stress from webcam, voice or keystroke patterns | Banned at work | The medical exception means CE-marked medical devices, not wellbeing monitoring. The safety exception covers stress only where it creates a specific danger, such as operating dangerous machinery, and that data cannot then be used to assess performance. Keystroke analysis counts as biometric. |
| Fatigue detection for drivers or machine operators | Not emotion recognition | Fatigue and pain are physical states, not emotions. |
From December 2, 2026, AI that generates non-consensual intimate images, video or audio of identifiable people, or child sexual abuse material, is also banned. For a deployer, that ban applies when the system is used for that purpose (Art. 5(1a)).
This week: search your software's feature lists for "emotion", "sentiment", "tone", "mood", "engagement" and "attention". For each hit, ask the vendor whether it uses face, voice or keystroke data. If it does, switch it off for staff and candidates.
Article 4: AI literacy, as rewritten in July 2026
The Omnibus replaced Article 4. Providers and deployers must now "take measures to support the development of AI literacy" of their staff and anyone operating AI on their behalf, and the text adds that this does not require them "to guarantee any specific level of AI literacy of any individual". National market surveillance authorities supervise it from August 2, 2026, with penalties set by national law (Commission AI literacy Q&A). Article 4 is not among the obligations listed in the EU's €15 million or 3% fine tier.
Our default evidence is one short record per AI system: who uses it, what they were told about its limits and typical failures (for example, "it misreads scanned tables"), when, and how new starters get the same briefing. For high-risk systems, Article 26(2) sets a separate, stricter bar for the people doing oversight.
Article 50: what people must be told, since August 2, 2026
The Commission's Article 50 guidelines (C(2026) 5054, July 20, 2026) are not binding, but they are the Commission's official reading of the article. The only Omnibus relief is for providers of generative systems already on the market before August 2, 2026, whose deadline for adding machine-readable marking is December 2, 2026. A voluntary Code of Practice on Transparency of AI-generated Content, published in June 2026, is what the guidelines treat as the recognized route to showing compliance with the marking and labeling duties.
| Situation | Who owes it | What your system must show or keep |
|---|---|---|
| Customer chatbot or voice assistant (Art. 50(1)) | The provider, which is you if you built it or had it built | A clear statement at or before the first turn, such as a greeting plus a label near the input box; for voice, a spoken statement at the start. Not enough alone: a clause in the terms and conditions, a site-wide "we use AI" notice, or calling it an "assistant". It must say it is AI when asked. Our default: log which disclosure version each session saw. |
| AI agent that emails, books or negotiates with people outside the company | Provider | Disclose that it is AI and on whose behalf it acts (guidelines point 31), in every exchange where a person is likely to be on the other end. |
| Staff draft replies with AI, then review and send them | Not covered by Art. 50(1): the customer is dealing with the person | A record of who sent each message. If drafts go out unreviewed, the disclosure duty comes back. |
| Internal assistant used by trained staff | Provider, but the "obvious" exception can apply | The guidelines read the exception narrowly and treat tools for trained professionals as the kind of case where it can work. Our default is to label anyway, because it costs one line of interface. |
| Emotion recognition or biometric categorization of customers or visitors (Art. 50(3)) | Deployer | A notice at first exposure, such as a pop-up before a session or a sign at each entrance. It applies to real-time and after-the-fact analysis, and to children. |
| Deep fakes: AI image, audio or video resembling real people, objects, places or events that could pass as real (Art. 50(4)) | Deployer | A visible or audible label on each output. The provider's machine-readable watermark does not count (guidelines point 117). The guidelines' examples include a synthetic avatar of a CEO addressing staff, so internal videos need a label too. |
| AI text published to inform the public on matters of public interest (Art. 50(4)) | Deployer | A label, unless someone with subject knowledge reviewed the substance (fact-checking at minimum) and a named person or company holds editorial responsibility and is easy to identify, for example in your site's legal information. An AI edit after sign-off voids the exception (point 136). In scope: AI-edited corporate reports with investor information on a listed company's website. Out of scope: intranet pages, internal email, individual client advice. |
| Text generated before August 2, 2026 but published after it | Deployer | Label it. Only text already published before that date is exempt (point 154). |
For an internal assistant, our guide to testing AI document search covers the permission tests it needs. If AI writes figures into reports investors read, the review step is the control that matters; our article on AI and numbers shows an architecture that flags figures that disagree or rest on stale data.
Disclosure wording you can adapt. The handoff line in the chat greeting is our default, not an Article 50 requirement:
Chat, first message:
"Hi, I'm Acme's AI assistant, an automated system, not a person.
I can help with orders and deliveries. Type 'person' at any time
to reach our team."
Label beside the input box:
"AI assistant: replies are generated automatically"
Voice, first sentence:
"You're speaking with Acme's automated AI assistant."
Outbound agent email, first line:
"This message was written and sent by an AI agent acting for
[name], Accounts Payable, Acme GmbH."
Published text with no editorial review:
"This article was generated with AI."This week: open every chatbot, voice line and outbound agent you run as a customer would. If the first thing it says does not make clear that it is AI, fix that first. Then ask it "Am I talking to a person?" and check that the answer is no.
High-risk deployer obligations, article by article (from December 2, 2027)
The right-hand column is what we would build into the system so that each obligation leaves evidence.
| Article | Obligation in plain language | What your system must log, show or keep |
|---|---|---|
| 26(1) | Use the system in line with the provider's instructions for use. | The instructions version in force. Production settings, such as score thresholds and permitted inputs, that match it. A dated record of changes. |
| 26(2), with 14(4) | Assign human oversight to people with the competence, training, authority and support to do it. The system must let them understand its limits, stay alert to over-relying on it ("automation bias"), override or reverse an output, and stop it. | A review queue showing each output with its inputs, an override that records who changed what and why, a named overseer with authority to reject, and a stop control. Our default: track each reviewer's override rate, because a reviewer who never overrides may not be reviewing. Our exception queue spec is a good starting record format. |
| 26(4) | Where you control the input data, make sure it is relevant and sufficiently representative for the system's purpose. | A log of the input fields sent, and checks for missing or out-of-range values before scoring. |
| 26(5) | Monitor operation. If you have reason to think the system presents a risk, inform the provider or distributor and the market surveillance authority without undue delay, and suspend use. For a serious incident, inform the provider first, immediately. | A monitoring view, a documented suspend switch, and an incident log with the time each notice was sent. Find your authority on the Commission's list of market surveillance authorities. |
| 26(6) | Keep the logs the system generates automatically, to the extent you control them, for at least six months unless other law, especially data protection law, says otherwise. | A retention setting of at least six months, and an export route. Check the vendor's default retention before you sign. |
| 26(7) | Before using a high-risk system at work, employers inform workers' representatives and the affected workers. | A dated notice. National information and consultation rules apply on top, and Article 2(11) preserves national laws and collective agreements that are more favorable to workers. |
| 26(8) | Public authorities register their use in the EU database, and do not use an unregistered system. | The registration reference. |
| 26(9) | Use the provider's Article 13 information for the GDPR data protection impact assessment. | A DPIA that cites the instructions for use. |
| 26(11) | Tell people that an Annex III system is making, or helping to make, decisions about them. | A notice in the application form or letter, and a per-person record that it was given. |
| 26(12) | Cooperate with the authorities. | Logs and documents you can export on request. |
| 27 | Fundamental rights impact assessment before first use, but only for public bodies, private entities providing public services, and deployers of credit scoring (point 5(b)) or life and health insurance risk and pricing (point 5(c)) systems. Notify the results to the market surveillance authority using the AI Office's template. Since July 2026, it may cross-reference your DPIA. | The assessment (process, period and frequency of use, affected groups, risks, oversight, complaint handling), the notification receipt, and an update when any of these changes. |
| 86 | A person affected by a decision based on an Annex III system's output, with legal or similarly significant effects, can ask the deployer for a clear and meaningful explanation of the AI's role and the main elements of the decision. | A per-decision record: the output, the inputs used, the reviewer, the final decision and the reason. In practice, our reading is that this follows the December 2, 2027 date, because it depends on Annex III classification. |
| 4a(2) | New since July 2026: deployers of high-risk systems may process special-category data to detect and correct bias, only where strictly necessary and under all the Article 4a(1) safeguards. It does not require you to run bias checks. | Proof that synthetic or anonymized data would not do, pseudonymization, access controls with an access log, no sharing with third parties, deletion once the bias is corrected, and the reasons recorded in your GDPR record of processing. |
The GDPR does not wait for 2027. In SCHUFA (C-634/21), decided December 7, 2023, the EU Court of Justice held that producing a credit score is itself an automated decision under Article 22 GDPR when the business receiving it draws strongly on it to enter into, carry out or end a contract. If a score, bought in or your own, largely decides whether you lend, rent or contract with a person, Article 22's limits on automated decisions apply today.
Annex III in plain language: which business uses are high-risk
An AI system in one of these areas is high-risk (Art. 6(2)) unless the Article 6(3) filter applies. The filter needs no significant risk of harm, and one of four conditions: the system performs a narrow procedural task, improves the result of a completed human activity, detects patterns or deviations in past decisions without replacing human review, or performs a preparatory task. It is never available when the system profiles people. A CV parser that only extracts fields can pass the filter. The same parser adding a "fit score" profiles candidates and cannot.
| Point | High-risk uses, in plain language | High-risk example | Not high-risk (or a note) |
|---|---|---|---|
| 1. Biometrics | Remote biometric identification; categorizing people by sensitive traits; emotion recognition | Emotion analytics on callers' voices | Verification that someone is who they claim to be, such as face login (excluded in the Annex text) |
| 2. Critical infrastructure | Safety components in critical digital infrastructure, road traffic, or water, gas, heating and electricity supply | An AI pressure sensor in a drinking-water network's pressure monitoring | Forecasting electricity demand where separate systems handle safety. No Art. 27 impact assessment is required for this point |
| 3. Education and training | Admission, grading, deciding the level of education, detecting cheating in tests | AI grading of exams that count toward a final evaluation | An admissions chatbot giving general information |
| 4(a). Recruitment | Targeted job ads, analyzing and filtering applications, evaluating candidates | Ranking CVs, scoring written or spoken answers in online assessments, background checks on applicants | Parsing CVs into a searchable database, scheduling interviews, acknowledgment emails, flagging biased wording in ads |
| 4(b). Managing work | Decisions on terms, promotion or termination; allocating tasks by behavior or traits; monitoring and evaluating performance | A shift scheduler ranking workers on punctuality and shift-acceptance rates | Desk booking, travel planning, polishing a manager's completed promotion report, compiling attendance reports |
| 5(a). Public benefits | Public authorities assessing eligibility for benefits and services | Scoring social housing applications | Assessing reimbursement claims from companies rather than from people |
| 5(b). Credit | Creditworthiness or credit scores of natural persons, except fraud detection | Scoring consumer loan or mortgage applicants | Customer segmentation kept separate from any credit decision, valuing collateral, monitoring credit exposure after lending |
| 5(c). Life and health insurance | Risk assessment and pricing for individuals | Underwriting life insurance applications | Health insurance claims handling |
| 5(d). Emergencies | Classifying emergency calls, dispatch, emergency patient triage | Prioritizing 112 calls | Scheduling medical appointments |
| 6 to 8 | Law enforcement; migration and borders; administration of justice, including alternative dispute resolution, and influencing elections | AI that helps an arbitration service apply the law to facts | Campaign logistics tools whose output voters never see |
Point 5(b) covers natural persons, so scoring companies is outside it, but a sole trader is a natural person. Where a vendor says its product passes the Article 6(3) filter, ask for its documented assessment and its EU database registration reference: providers must register even when they rely on the filter.
Systems already running before December 2, 2027
Article 111(2), as replaced by the Omnibus, says the Act applies to high-risk systems placed on the market or put into service before the Chapter III date only if their design changes significantly after that date. For providers, the date that counts is when the first unit of that type and model reached the EU market (recital 39). Systems intended for public authorities must comply by August 2, 2030 regardless. The rule does not cover Articles 5 or 50, which apply whenever a system went live.
A custom Annex III system put into service before December 2, 2027 and then left alone could stay outside the high-risk obligations. Our judgment is not to plan on it. Hosted models are retired on their vendors' schedules, and in our reading, swapping the model under a scoring system is likely to count as a significant change in design. Plan as if the first major update after December 2, 2027 triggers full compliance, but keep the evidence for the exemption anyway: the go-live date and a dated log of design changes. For a SaaS product, ask the vendor directly (question 7 in the email below).
Fines, and the small mid-cap trap
Member states set the penalty rules and national authorities impose fines, within the ceilings in Article 99. For most companies, the ceiling is the fixed amount or the percentage of worldwide annual turnover, whichever is higher. For SMEs it is whichever is lower.
| Tier | Ceiling | What it covers | SMEs | Small mid-caps |
|---|---|---|---|---|
| Art. 99(3) | €35 million or 7% | Prohibited practices (Art. 5) | Whichever is lower | Whichever is higher: no relief |
| Art. 99(4) | €15 million or 3% | Deployer duties (Art. 26), transparency (Art. 50), provider duties (Art. 16), value-chain agreements (Art. 25(2) and (4), added July 2026) and others | Lower | Lower |
| Art. 99(5) | €7.5 million or 1% | Incorrect, incomplete or misleading information given to authorities or notified bodies | Lower | Lower |
| National rules | Set by each member state | Everything not listed above, including AI literacy (Art. 4) and the impact assessment (Art. 27) | Must take account of SMEs | Must take account of SMCs |
The trap is in the wording. New Article 99(6a) gives SMCs the "whichever is lower" rule only for paragraphs 4 and 5, so an SMC's exposure for a prohibited practice is a large company's. An SME has fewer than 250 staff and turnover up to €50 million or a balance sheet up to €43 million. An SMC is above that, with fewer than 750 staff and turnover up to €150 million or a balance sheet up to €129 million (Commission Recommendation (EU) 2025/1099, as of September 2026).
| Company | Prohibited practice, Art. 99(3) | Deployer or transparency breach, Art. 99(4) |
|---|---|---|
| SME: 180 staff, €30 million turnover | Lower of €35m and 7% × €30m = €2.1m | Lower of €15m and 3% × €30m = €0.9m |
| SMC: 600 staff, €120 million turnover | Higher of €35m and 7% × €120m = €35m | Lower of €15m and 3% × €120m = €3.6m |
| Large: 3,000 staff, €2 billion turnover | Higher of €35m and 7% × €2bn = €140m | Higher of €15m and 3% × €2bn = €60m |
For this SMC, the prohibited-practice ceiling is the full €35 million, about 17 times the SME's, while its ceiling for a deployer breach stays proportionate to turnover. These are maximums. Article 99(7) lists what authorities weigh, including cooperation, whether you reported the problem yourself and what you did to limit the harm. To work out your own ceilings, put your size in B1 ("SME", "SMC" or "Other"), the tier in B2 ("99(3)", "99(4)" or "99(5)") and worldwide annual turnover in euros in B3:
B4 (fixed amount): =IF(B2="99(3)",35000000,IF(B2="99(4)",15000000,7500000))
B5 (percentage): =IF(B2="99(3)",0.07,IF(B2="99(4)",0.03,0.01))
B6 (ceiling): =IF(OR(B1="SME",AND(B1="SMC",B2<>"99(3)")),MIN(B4,B5*B3),MAX(B4,B5*B3))How to use this list this week
1. Fill in an AI register. One row per system, including tools staff signed up for themselves. The first example row shows a gap worth checking for: a vendor keeping logs for less than the six-month minimum.
| System and vendor | Bought, built or repurposed | Used on | Annex III point, filter, profiling | Article 50 case | In service since, last design change | Logs: who controls them, retention | Overseer, workers informed, Art. 27 |
|---|---|---|---|---|---|---|---|
| Applicant ranking in an HR suite | Bought | Job applicants | 4(a); no filter; profiles candidates | None | March 2026; none since | Vendor; 30 days (below six months) | Head of Talent; not yet; not required (private employer) |
| Website chat assistant on a model API | Built for us | Customers | None | 50(1) disclosure | May 2025; model swapped June 2026 | Us; 90 days | Support lead; not applicable; not applicable |
2. Send each vendor of an Annex III or Article 50 system this email.
Subject: EU AI Act: information we need about [product]
We use [product] for [purpose] in [countries]. To meet our obligations
as a deployer under the EU AI Act (Regulation (EU) 2024/1689, as
amended by Regulation (EU) 2026/1744), please send us by [date]:
1. Whether you classify [product], as we use it, as high-risk under
Annex III. If you rely on Article 6(3), your documented assessment
and your EU database registration reference.
2. The instructions for use under Article 13, and how you will tell
us when they change.
3. Which logs the system generates automatically, whether we control
them, how long they are kept and how we export them. We must keep
them for at least six months (Article 26(6)).
4. How a reviewer can override or reverse an output and stop the
system (Article 14(4)), and whether overrides are logged.
5. Whether any feature infers emotions from face, voice or keystroke
data, and whether it can be turned off for employees and
candidates (Article 5(1)(f)).
6. For generated text, images, audio or video: how outputs are marked
in a machine-readable way (Article 50(2)), and whether the marking
survives export from your product.
7. When this version was first placed on the EU market, and whether
you plan model or design changes after December 2, 2027 that you
would treat as significant changes in design (Article 111(2)).
8. Who we contact to report a serious incident (Article 26(5)).If you want a second pair of eyes on the system side, send us your register, half-filled is fine, together with the vendors' answers. We start with the review queue, the override record and log retention, because Article 26 turns on them and they are the hardest parts to add once a system is live. That is the work behind our internal AI systems service.