EU AI Act High-Risk: Swedish Prep for December 2027

Updated 27 September 2026 to reflect the revised timeline under Regulation (EU) 2026/1744, the Digital Omnibus on AI. The original version of this post was written for a 2 August 2026 high-risk deadline that no longer exists.

What Moved and What Did Not

Regulation (EU) 2026/1744 was adopted on 8 July 2026, published in the Official Journal on 24 July, and entered into force on 27 July, six days before the AI Act's largest applicability milestone. It amends the AI Act, the civil aviation regulation and the machinery regulation. The popular summary, that the AI Act got delayed, is wrong in a way that costs money: only the conformity-assessment layer moved.

The recitals are candid about why. Harmonised standards from CEN-CENELEC were not ready, the Commission's own guidance was late, and many member states had not finished designating competent authorities. None of that makes the obligations lighter. The full Chapter III requirement set arrives on schedule in December 2027, against standards that are expected to exist by then and regulators who will have had sixteen extra months to staff up. We covered the mechanics of the deferral itself in the AI Act's high-risk deadline moved to December 2027.

The Two Obligations That Are Already Live

Start here, because these are the ones with an enforcement date in the past or the near future. Everything in the high-risk section below is build work. This section is remediation.

Article 50 transparency, in force since 2 August 2026

Article 50 was untouched by the Omnibus. It applies to every risk class, which means a customer-service chatbot that is nowhere near Annex III still owes duties today. Three concrete requirements:

• Disclosure of AI interaction. A person interacting with an AI system must be told, unless it is obvious from the context to a reasonably well-informed person. Voice bots and embedded assistants are the usual gaps, because the disclosure often lives in a help page rather than in the interaction.
• Machine-readable marking of synthetic content. Providers of systems that generate synthetic audio, image, video or text must mark the output in a machine-readable format detectable as artificially generated. This is a provider duty, so if you fine-tune and ship under your own brand, it is yours.
• Deepfake and emotion-recognition notice. Deployers of systems producing deepfake content must disclose it, and deployers of emotion-recognition or biometric-categorisation systems must inform the people exposed to them.

The one piece of relief: providers whose generative systems were already on the market before 2 August 2026 have until 2 December 2026 to meet the Article 50(2) machine-readable marking requirement. That is a four-month engineering window for a task that is fiddlier than it sounds, because marking has to happen on every generation pathway and survive ordinary transformations like re-encoding and cropping. For Azure OpenAI specifically we wrote up the implementation detail in Article 50 compliance for Azure OpenAI apps.

Two new prohibitions, 2 December 2026

The Omnibus added prohibitions rather than removing any. From 2 December 2026, Article 5 also bans AI systems that generate or manipulate realistic non-consensual intimate imagery of identifiable persons, and systems that generate or manipulate child sexual abuse material. The scope is wider than "nudifier apps built on purpose". It reaches systems where such output is a reasonably foreseeable and reproducible outcome in the absence of reasonable, proportionate and effective safeguards.

Read that phrase twice if you run an image or video generation feature. It converts safety filtering from a brand-risk decision into a compliance control sitting in the penalty tier that caps at 35 million euros or 7 percent of global turnover. The evidence you want on file by 1 December 2026: what safeguards are in place, what red-team testing showed, what the bypass rate was, and who signed off.

Classification: Is Your System Actually High-Risk?

Annex III defines the high-risk categories by use case, not by technology. A hiring recommendation system is high-risk regardless of whether it runs a small gradient-boosted classifier or a frontier model. A chatbot answering product questions is not high-risk, even if it is powered by the same frontier model. Classification is per system and per purpose, never per vendor.

The Article 6(3) filter survived the Omnibus unchanged, and it does real work. A system that touches an Annex III domain is not high-risk if it poses no significant risk of harm and only performs a narrow procedural task, improves the result of a previously completed human activity, detects decision patterns without replacing or influencing the human assessment, or performs preparatory work for an assessment. Profiling of natural persons is always high-risk, with no filter available. Two rules follow: document the reasoning whichever way you land, and note that a system you filter out under Article 6(3) still carries a registration duty.

Run the role check next, because it determines the size of the obligation set. You are a provider if you develop the system, or have it developed, and place it on the market under your own name or trademark. You are a deployer if you use someone else's system under your own authority in a professional capacity. The traps are substantial modification, change of intended purpose, and white-labelling: a fine-tuned model shipped under your brand makes you the provider, with the full Annex IV dossier and conformity assessment attached. Most Swedish enterprises are deployers of Azure-hosted or SaaS-embedded AI, which is a lighter set of duties but not an empty one.

One definitional change is worth checking if you build for industry. The Omnibus narrowed the Article 3(14) definition of a safety component, so a function counts only where it has the intended purpose of preventing or mitigating a risk to health or safety. Systems that exist purely for user assistance, performance optimisation or convenience fall outside, while systems whose failure endangers health or safety remain inside. If you classified an embedded system as Annex I high-risk in 2025, the answer may have changed.

The Artifacts Still Due, Now by 2 December 2027

This list is unchanged by the Omnibus. Only the date on it changed.

1. System classification register. A documented assessment of which systems are high-risk under Annex III and why, including the Article 6(3) reasoning and the provider-versus-deployer determination per system. Board-reviewed.
2. Technical documentation (Annex IV). A full dossier per high-risk system: description, intended purpose, design choices, data sources, training methodology, performance metrics, risk management, human oversight and post-market monitoring plan. SMEs and the new small mid-cap category can use a simplified template.
3. Risk management system (Article 9). An ongoing process, not a static document. Identifies, estimates and evaluates risks across the system lifecycle, and records the mitigations chosen.
4. Data and data governance documentation (Article 10). Training, validation and test data descriptions covering relevance, representativeness, error examination, bias detection and known gaps. This is the artifact that takes longest to retrofit, so it is the one to start on first.
5. Logging (Article 12). Automatic event recording across the system lifetime, with scope, retention and access documented. Schema below.
6. Instructions for use (Article 13). Documentation that lets a deployer interpret outputs and operate the system within its intended purpose.
7. Human oversight design (Article 14). Measures that let named natural persons understand, monitor and intervene. A dashboard nobody watches does not qualify.
8. Accuracy, robustness and cybersecurity evidence (Article 15). Documented performance levels, resilience testing and security measures, with repeatable evaluation runs.
9. Conformity assessment. Internal control for most Annex III categories, notified body for some. Biometrics is the category most likely to need a third party.
10. CE marking, declaration of conformity and EU database registration. Provider duties. Deployers have related but separate obligations, including fundamental-rights impact assessments where they apply.

The Logging Schema That Satisfies Article 12

Logging is the artifact most worth building early, for a practical reason: you cannot retrofit history. Every month you run without it is a month of evidence you will not have in December 2027. Keep references and hashes in the log rather than payloads, so the log itself does not become a personal-data liability under GDPR.

// Annex-IV-aligned event log for a high-risk system
interface AIActLogEvent {
  eventId: string;                 // ULID or UUID
  systemVersion: string;           // semver or build hash
  modelRef: string;                // deployment name + model version
  timestamp: string;               // ISO 8601 UTC
  inputRef: string;                // hash reference; no PII in log
  outputRef: string;               // hash reference
  decision: string;                // high-level outcome
  confidence?: number;
  humanInLoopStage?: 'none' | 'advised' | 'approved' | 'overridden';
  humanOverride?: {
    reason: string;
    userId: string;
    timestamp: string;
  };
  riskFlags?: string[];            // safety filter / guardrail hits
  evalRunRef?: string;             // links output to the eval that qualified this version
  retentionClass: 'short' | 'medium' | 'long';
}

Two fields in that schema exist for audit rather than debugging. modelRef lets you answer "which model version produced this decision" eighteen months later, which matters because a silent model upgrade behind a stable API endpoint is invisible in a log that only records the deployment name. evalRunRef ties a production decision back to the accuracy and robustness testing that qualified that version, which is the chain an assessor will ask you to walk. On Azure, diagnostic settings on the Azure OpenAI resource plus Log Analytics retention policies cover the plumbing; the schema discipline is yours.

Using the Extra Fifteen Months

The failure mode is obvious and common: treat December 2027 as permission to stop, then restart cold in mid-2027 against standards nobody on the team has read. Sequence it instead, with the live obligations first and the slowest artifacts second.

Now to December 2026: close the live gaps

• Audit every user-facing AI touchpoint for Article 50 disclosure. Chat frontends, Copilot Studio agents, Teams bots, voice channels, embedded website assistants.
• Ship machine-readable marking on every generation pathway before 2 December 2026 if any generative system was on the market before 2 August 2026.
• Document the safeguards against non-consensual intimate imagery and CSAM generation, with red-team evidence, before the prohibitions apply on 2 December 2026.
• Build the system inventory: every AI system in production or procurement, its vendor, its Azure footprint, its purpose, the personal data it touches, and your role under the Act.

Q1 to Q3 2027: the slow artifacts

• Article 10 data governance first, because dataset lineage, representativeness analysis and bias examination cannot be produced in a sprint. On Azure this is where Purview cataloguing and documented dataset versioning in AI Foundry earn their cost.
• Turn on Article 12 logging in production now rather than later, so you accumulate a year of records before the deadline.
• Stand up the Article 9 risk management process inside your existing ISO 27001 machinery instead of beside it. The overlap is large and the duplication is expensive.
• Put AI Act deliverables into vendor contracts at this renewal cycle, while the deadline is still far enough away that you have leverage.
• Track the harmonised standards as they publish. Writing Annex IV documentation against a standard is far cheaper than writing it against the bare statute, and the standards gap was the stated reason for the deferral.

Q4 2027: conformity and rehearsal

• Run conformity assessment, draw up the declaration of conformity, affix CE marking where you are the provider, and register in the EU database.
• Engage a notified body considerably earlier than this if your category needs one. Capacity, not your readiness, will be the constraint.
• Activate post-market monitoring with a serious-incident runbook, and rehearse the audit by having someone outside the programme walk one system's evidence chain end to end.

Two More Omnibus Changes Worth Knowing

Bias testing got a legal basis. Article 10(5) was extended to permit processing special categories of personal data for detecting and correcting bias, across AI models and systems, subject to strict necessity and mandatory safeguards including pseudonymisation, access controls and timely deletion. This resolves a genuine deadlock: Article 10 asks for bias examination, GDPR Article 9 restricts the data you need to do it. If your legal team blocked a fairness audit on that basis in 2025, the blocker has changed.

Small mid-caps joined the relief tier. Simplified technical documentation and proportionate quality-management expectations, previously for SMEs and start-ups, now also cover enterprises under 750 employees with turnover at or below 150 million euros (or a balance sheet at or below 129 million euros), with priority sandbox access and adjusted penalty caps. That threshold captures a large share of the Swedish mid-market that assumed it faced the full enterprise burden.

The Swedish Angle

• PTS, not IMY, is the hub. The Swedish inquiry report SOU 2025:101, Anpassningar till AI-förordningen, delivered on 6 October 2025, proposes Post- och telestyrelsen as the coordinating market surveillance authority and Sweden's single point of contact, inside a system of eleven market surveillance authorities and two notifying authorities. Earlier guidance, including an earlier version of this post, assumed Integritetsskyddsmyndigheten would lead. IMY remains central for personal-data and biometric questions, and Finansinspektionen for credit scoring, but the coordinating role sits with PTS.
• Notifying authorities. Swedac and Läkemedelsverket are the two proposed notifying authorities, which is where conformity-assessment questions land.
• The supplementary law is not yet enacted. Sweden has proposed its implementing measures but has not finalised the legislation. That does not soften anything: the AI Act is a regulation and applies without national transposition. What is still forming is the national supervision and sanction machinery. Our fuller map is in who enforces the AI Act in Sweden.
• Sandbox by 2 August 2027. Every member state must have at least one AI regulatory sandbox operational by then, and SOU 2025:101 tasks PTS with establishing Sweden's. For a borderline Annex III use case on a 2027 roadmap, a sandbox slot is real de-risking, and documented participation is evidence that shortens later conformity discussions. The queue will not be empty.
• Procurement language is already updating. Swedish public-sector buyers were writing AI Act clauses into upphandling requirements ahead of August 2026. Expect tenders to ask for a commitment to the December 2027 date, evidence of current Article 50 compliance, and the documentation a deployer needs. If you sell, a phased programme is a competitive answer. If you buy, put the phase gates in the contract.
• Swedish-language instructions for use. Not universally a legal requirement, but a standing procurement expectation where deployers are Swedish. Budget the translation into the Annex IV work rather than discovering it at tender stage.

Where the Real Risk Sits Now

The deferral shifted the near-term risk from high-risk conformity to transparency. A Swedish company with no Annex III system at all can still be in breach today over an undisclosed chatbot or unmarked generated content, and that risk is live while the high-risk one is not. The penalty structure reflects the hierarchy: up to 35 million euros or 7 percent of global turnover for prohibited practices, up to 15 million euros or 3 percent for most other infringements. Our Azure deployer enforcement checklist covers the immediate items.

For high-risk work, the planning assumption to hold is that December 2027 will be enforced by better-prepared supervisors than August 2026 would have been, measuring against harmonised standards that should exist by then. Fifteen months is enough to do this calmly. Four was not, which is why the date moved. Spend the runway on Article 10 data governance and Article 12 logging first. Both accumulate evidence over time, and neither can be produced retroactively in the final quarter.