EU AI Act Compliance Consulting 2026

What EU AI Act compliance consulting delivers in 2026

In short

EU AI Act compliance consulting scopes an enterprise's AI estate against Regulation (EU) 2024/1689, classifies each system under Article 6, closes gaps against the seven high-risk obligations (Articles 9-15), and produces the technical documentation, conformity assessment, and post-market monitoring plan required before market placement. After the AI Omnibus political agreement of 7 May 2026, the Annex III deadline moved from 2 August 2026 to 2 December 2027, and Annex I product-embedded systems to 2 August 2028. The regulation itself has been in force since 1 August 2024.

Regulation (EU) 2024/1689 — the EU AI Act — entered into force on 1 August 2024 and is the world's first horizontal statute on artificial intelligence. Different obligations phase in on different dates, and 2026 reshuffled the calendar. The prohibited-practice ban (Article 5) has been enforceable since 2 February 2025, and general-purpose AI (GPAI) obligations for new models placed on the market applied from 2 August 2025.

The politically significant shift arrived with the AI Omnibus political agreement of 7 May 2026, which deferred the two remaining high-risk deadlines. Annex III high-risk systems — biometrics, employment, credit scoring, law enforcement, and the other domains listed in Section 4 below — now apply from 2 December 2027. Annex I product-embedded systems, which travel through existing sectoral conformity assessment, move to 2 August 2028. GPAI models already on the market before 2 August 2025 must still comply by 2 August 2027 under the original transitional rule.

Read against that calendar, a 2026 EU AI Act engagement delivers the following concrete outputs:

• An AI system inventory across the enterprise, tagged by role (provider / deployer / importer / distributor) and by prospective Article 6 classification.
• A gap analysis against the seven substantive obligations (Articles 9-15) for each system that is high-risk or likely high-risk.
• Technical documentation to Annex IV, risk management files, data governance evidence, human oversight designs, and post-market monitoring plans.
• A conformity assessment route (Annex VI internal control vs. Annex VII notified body) and a plan for EU database registration under Article 71.
• A GPAI downstream compliance file where the enterprise integrates foundation models — transparency, copyright-summary, and, where applicable, systemic- risk obligations under Articles 51-55.

Alice Labs sequences these deliverables against the deferred 2 December 2027 deadline with milestone checkpoints at Q4 2026, Q2 2027, and Q3 2027. The additional 16 months is runway to build evidence properly, not a reason to defer the work.

Who needs an EU AI Act consultant right now

In short

Any provider, deployer, importer, or distributor that places an AI system on the EU market — or whose AI output is used in the Union — is in scope under Article 2. That reaches non-EU vendors serving EU customers, EU deployers using third-party AI in Annex III use cases, and any enterprise integrating a GPAI model into an EU offering. Article 26 deployer duties apply even when the provider is outside the Union.

Scope is the question most enterprises get wrong. Article 2 is deliberately broad. The regulation applies to:

• Providers placing AI systems on the EU market or putting them into service in the Union, regardless of where the provider is established.
• Deployers — the entity using an AI system under its own authority — established in the Union.
• Providers and deployers established outside the Union when the output produced by the AI system is used in the Union.
• Importers and distributors of AI systems.
• Product manufacturers placing an AI system on the market together with their product under their own name or trademark.

The practical implication is that a US SaaS vendor selling AI-powered credit scoring to a Nordic bank is a provider under the Act, and the Nordic bank is a deployer with its own Article 26 obligations. A UK-based recruiter using an AI CV screener on candidates for EU roles is a deployer of an Annex III high-risk system. A German industrial company fine-tuning a US foundation model for predictive maintenance is a GPAI downstream integrator with duties under Articles 53 and 55.

Article 26 deployer obligations are the underweighted half of the regime. Deployers must use high-risk systems in accordance with the provider's instructions, implement human oversight, ensure input data relevance, keep automatically generated logs, monitor operation, inform the provider of serious incidents, and — for the public sector and public-service private operators — carry out a Fundamental Rights Impact Assessment (Article 27). None of that is optional because the provider sits in California or Tel Aviv.

Alice Labs typically engages with enterprises in financial services, healthcare, industrial manufacturing, HR technology, and public sector — the sectors where Article 6 classification is non-trivial and where the deployer role is often as regulated as the provider role.

Article 6 classification: is your AI system actually high-risk

In short

Article 6 defines high-risk in two limbs. Article 6(1) captures AI systems that are safety components of, or are themselves, products covered by Annex I harmonisation law requiring third-party conformity assessment. Article 6(2) captures the eight Annex III domains directly (biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration, justice). Article 6(3) creates a narrow-task exception — voided if the system profiles natural persons.

The Article 6 test is the load-bearing decision in the entire regime. If your system is high-risk you inherit the seven substantive obligations, the conformity assessment route, the EU database registration, and the post-market monitoring duty. If it is not high-risk you inherit only transparency obligations under Article 50 (where applicable) and voluntary code adherence. The classification memo is the first deliverable of any serious engagement.

Article 6(1) — Annex I product limb. Applies where the AI system is a safety component of, or is itself, a product covered by the Union harmonisation legislation listed in Annex I (machinery, toys, radio equipment, medical devices, in vitro diagnostic medical devices, civil aviation, motor vehicles, marine equipment, rail systems, agricultural vehicles, lifts, pressure equipment, cableways, gas appliances, and so on), and the product itself is subject to third-party conformity assessment.

Article 6(2) — Annex III domain limb. Applies where the AI system is used in one of the eight listed domains. This is the limb that catches most enterprise software.

Article 6(3) — the narrow-task exception. An Annex III system is not considered high-risk if it performs a narrow procedural task, improves the result of a previously completed human activity, detects decision-making patterns without replacing or influencing the previously completed human assessment, or performs a preparatory task to an assessment. The exception is voided in one specific case: if the AI system performs profiling of natural persons, it is always high-risk.

The exception is narrower in practice than most vendors claim. A CV pre-screener that ranks candidates for a recruiter is not exempt — it influences a human assessment. An AI note-taker that summarises a call for a doctor may qualify. Because the exemption claim must be documented and made available to authorities on request under Article 6(4), guessing is expensive. Every Alice Labs Article 6 memo includes the exemption analysis in writing.

Annex III walkthrough: the eight high-risk domains

In short

Annex III lists eight high-risk domains: biometrics; critical infrastructure; education and vocational training; employment, worker management, and recruitment; access to essential private and public services (including credit scoring and insurance risk assessment); law enforcement; migration, asylum, and border control; and administration of justice and democratic processes. Any AI system used in these domains is presumptively high-risk under Article 6(2), subject to the Article 6(3) exemption.

The eight Annex III domains, with the enterprise use cases we see in Nordic and EU deployments:

• Biometric identification and categorisation. Real-time and post-remote biometric identification, biometric categorisation on sensitive attributes, and emotion recognition (outside medical and safety uses). Common deployments: workforce access control, retail loss-prevention analytics.
• Critical infrastructure management. Safety components of digital infrastructure, road traffic, water, gas, heating, and electricity supply. AI-driven SCADA, grid balancing, and pipeline monitoring fall here.
• Education and vocational training. Admission scoring, learning outcome evaluation, appropriate level assessment, and monitoring of prohibited behaviour during tests. Automated proctoring vendors are a heavy hitter.
• Employment, worker management, and recruitment. CV screening, job advertisement targeting, promotion and termination decision support, task allocation based on behaviour or personality, and worker performance monitoring. This is the domain most enterprises underestimate.
• Access to essential private and public services. Public assistance eligibility, credit scoring and creditworthiness (except fraud detection), life and health insurance risk assessment and pricing, and emergency services dispatch triage.
• Law enforcement. Risk assessment of natural persons as offenders or victims, polygraph and similar tools, evaluation of evidence reliability, profiling, and crime analytics.
• Migration, asylum, and border control. Polygraph-adjacent tools, security and health risk assessments, application examination assistance, and detection of irregular migration.
• Administration of justice and democratic processes. Judicial research and interpretation assistance, alternative dispute resolution outcomes, and AI systems intended to influence election outcomes or voting behaviour.

The employment and essential-services rows are where private-sector enterprises concentrate. A bank running AI-assisted mortgage decisioning, an insurer using ML for underwriting, and a Nordic retailer with an AI-powered internal-mobility platform are all inside Annex III whether they realise it or not.

The seven substantive obligations for high-risk systems

In short

Articles 9-15 impose seven substantive obligations on every high-risk AI system before market placement: (1) a risk management system (Art. 9); (2) data and data governance (Art. 10); (3) technical documentation to Annex IV (Art. 11); (4) record-keeping and logging (Art. 12); (5) transparency and information to deployers (Art. 13); (6) human oversight (Art. 14); and (7) accuracy, robustness, and cybersecurity (Art. 15). Each obligation is evidence-based — a claim without documentation fails.

Chapter III Section 2 of the AI Act is the operational core. Read it as an evidence checklist that must exist in the technical file before a system may be placed on the market and CE-marked.

• Article 9 — Risk management system. A continuous iterative process running across the AI system lifecycle. Identify and analyse known and foreseeable risks to health, safety, and fundamental rights; estimate and evaluate risks emerging from use and from foreseeable misuse; adopt risk mitigation and control measures. Not a one-off assessment.
• Article 10 — Data and data governance. Training, validation, and testing datasets must be relevant, representative, free of errors, and complete to the extent possible; examined for possible biases; managed under a documented data governance regime. This is where most Nordic engagements find the deepest gaps.
• Article 11 — Technical documentation. The Annex IV package: general description of the system; detailed description of elements and development process; detailed information on monitoring, functioning, and control; risk management records; changes over lifecycle; harmonised standards applied; EU declaration of conformity; and post-market monitoring plan. Roughly 60-120 pages for a typical enterprise system.
• Article 12 — Record-keeping. Automatic logging of events over the lifetime of the system, enabling traceability of functioning to the extent appropriate to the intended purpose. For remote biometric identification the log content is prescribed in Article 12(2).
• Article 13 — Transparency and information to deployers. Instructions for use, characteristics, capabilities and limitations, human oversight measures, expected lifetime and maintenance measures, and any pre-determined changes.
• Article 14 — Human oversight. Interface tools that enable natural persons to understand the system's capacities and limitations, remain aware of automation bias, correctly interpret outputs, decide not to use the output, and intervene or interrupt operation. Designed into the system, not bolted on.
• Article 15 — Accuracy, robustness, and cybersecurity. Appropriate levels declared in instructions, resilience to errors, faults, and inconsistencies, and resilience to attempts by unauthorised third parties to alter use or performance through exploiting vulnerabilities.

Alice Labs delivers each of the seven as a discrete artefact with named owners inside the client organisation. The technical file is version-controlled, cross-referenced, and mapped to the harmonised standards being drafted by CEN-CENELEC JTC 21.

GPAI and foundation-model duties for downstream integrators

In short

Articles 51-55 govern general-purpose AI (GPAI) models. Providers of new GPAI models placed on the market from 2 August 2025 must comply immediately; models on the market before that date have until 2 August 2027. Systemic-risk models — trained above 10^25 FLOP — trigger additional evaluation, adversarial testing, and incident-reporting duties under Article 55. Downstream deployers integrating GPT, Claude, Gemini, Mistral, or Llama inherit transparency and copyright-summary obligations.

Chapter V of the AI Act carves out a distinct regime for general-purpose AI. A GPAI model is defined in Article 3(63) as an AI model trained on a large amount of data using self-supervision at scale, displaying significant generality and competence to perform a wide range of distinct tasks. Foundation models — GPT, Claude, Gemini, Mistral, Llama, and the Nordic-specific models emerging from Silo AI and AI Sweden — all sit inside this definition.

The core obligations for providers of GPAI models (Article 53):

• Maintain up-to-date technical documentation of the model, including training and testing process and evaluation results, to be provided to the AI Office and national competent authorities on request.
• Provide downstream providers integrating the model with sufficient information to understand its capabilities and limitations and to comply with their own obligations.
• Put in place a policy to comply with Union copyright law, including through state-of-the-art technologies to identify and comply with rightsholder opt-outs under Article 4(3) of the DSM Directive.
• Publish a sufficiently detailed summary of the content used for training the model, according to a template provided by the AI Office.

Systemic-risk GPAI models — those with training compute at or above 10^25 FLOP per Article 51(2) and Annex XIII — carry the Article 55 duties on top: model evaluation with state-of-the-art protocols, adversarial testing, documentation and reporting of serious incidents, cybersecurity protections, and reporting on energy consumption.

Downstream integrators — the enterprise fine-tuning or wrapping a GPAI model — are usually acting as a provider of a distinct AI system, with the seven substantive obligations flowing through. In some deployments they may become the provider of a new GPAI model themselves if the modification is substantial (Article 25). Alice Labs runs this analysis on every downstream integration in scope.

Conformity assessment and CE marking pathway

In short

Under Article 43 and Annexes VI and VII, most Annex III high-risk systems undergo an internal control conformity assessment (Annex VI) — the provider produces the technical file, applies the harmonised standards, and self-declares conformity. Remote biometric identification systems (Annex III point 1(a)) require notified body involvement under Annex VII. All high-risk systems require an EU declaration of conformity, CE marking, and registration in the EU database under Article 71 before market placement.

The conformity assessment route is prescribed by Article 43 and depends on the system type:

• Annex VI internal control. Default route for Annex III high-risk systems. The provider verifies compliance with the seven obligations against harmonised standards, prepares the Annex IV technical documentation, and self-issues the EU declaration of conformity. No notified body involvement is required. This is the pathway for employment scoring, credit scoring, insurance risk, education admission, and the majority of enterprise use cases.
• Annex VII third-party assessment by notified body. Mandatory for real-time and post-remote biometric identification systems under Annex III point 1(a). A notified body designated under Article 31 audits the quality management system and the technical documentation.
• Annex I products. Where the AI system is a safety component of an Annex I regulated product (medical device, machinery, in vitro diagnostic), the existing sectoral conformity assessment absorbs the AI Act requirements — the notified body assesses both.

After a positive conformity assessment the provider must:

• Draw up an EU declaration of conformity under Article 47.
• Affix the CE marking to the AI system (or, where not possible, to packaging or accompanying documentation) under Article 48.
• Register the system in the EU database for high-risk AI systems under Article 71, before market placement.

Substantial modification of a system (Article 43(4)) triggers a fresh conformity assessment. That is a live issue for enterprises running continuous training pipelines — model drift and periodic retraining can amount to substantial modification and reset the clock.

Post-market monitoring, incident reporting, and serious-incident duties

In short

Article 72 requires providers of high-risk systems to establish and document a post-market monitoring system proportionate to the nature of the AI technology and risks. Article 73 mandates serious-incident reporting to national market surveillance authorities within 15 days of the provider becoming aware, and immediately (no later than 2 days) for incidents involving death or widespread infringement of fundamental rights. Deployers must notify providers under Article 26.

Compliance does not end at market placement. Chapter IX of the AI Act imposes lifecycle duties that most consultancies underweight in gap analyses.

Article 72 post-market monitoring requires providers to:

• Establish and document a post-market monitoring system proportionate to the nature of the AI technology and risks.
• Actively and systematically collect, document, and analyse relevant data on performance throughout the lifetime.
• Enable the provider to evaluate continuous compliance with the seven substantive obligations.
• Feed monitoring outputs back into the risk management system under Article 9.

Article 73 serious-incident reporting is the sharpest lifecycle duty. A serious incident is defined in Article 3(49) as an incident or malfunctioning leading to death, serious harm to health, serious and irreversible disruption of critical infrastructure management, infringement of Union fundamental-rights obligations, or serious harm to property or environment.

• Report to national market surveillance authorities within 15 days of the provider becoming aware.
• For incidents involving death of a natural person, report immediately and no later than 10 days.
• For widespread infringement of fundamental rights or serious critical infrastructure disruption, report within 2 days.
• Provide the authority with subsequent information and analysis as it emerges.

Deployers must notify providers of serious incidents under Article 26(5). Post-market monitoring and incident reporting are inseparable — one produces the data that feeds the other. Alice Labs treats them as a single Phase 4 workstream with dashboards, runbooks, and drill exercises before go-live.

Fundamental Rights Impact Assessment (FRIA) for deployers

In short

Article 27 requires public-sector bodies and private operators providing public services (education, healthcare, employment services, housing, essential public infrastructure) to complete a Fundamental Rights Impact Assessment before deploying an Annex III high-risk AI system. Private-sector deployers of credit scoring and life/health insurance risk assessment systems also fall in scope. The FRIA covers affected persons, frequency, categories of harm, human oversight measures, and remediation.

The Fundamental Rights Impact Assessment sits under Article 27 and applies to a subset of deployers, not to providers. The regulatory logic is that only the deployer knows the specific context of use — the population affected, the frequency of decisions, the actual human oversight in place — and only the deployer can assess fundamental-rights impact against that context.

Who must run a FRIA:

• Bodies governed by public law, or private operators providing public services, deploying any Annex III high-risk system.
• Deployers of the Annex III credit scoring point 5(b) and life/health insurance risk assessment point 5(c) systems, regardless of public or private status.

What the FRIA must cover (Article 27(1)):

• A description of the deployer's processes in which the high-risk AI system will be used consistent with its intended purpose.
• A description of the period of time and frequency in which the AI system is intended to be used.
• The categories of natural persons and groups likely to be affected in the specific context.
• The specific risks of harm likely to impact the categories of natural persons or groups.
• A description of the implementation of human oversight measures according to the instructions for use.
• The measures to be taken in the case of the materialisation of those risks, including internal governance and complaint mechanisms.

The FRIA output must be notified to the market surveillance authority via the template provided by the AI Office. For enterprises already running Data Protection Impact Assessments under GDPR Article 35, the FRIA extends and complements — but does not replace — the DPIA. Alice Labs runs FRIA and DPIA as an integrated workstream on every in-scope engagement.

Penalties and enforcement in 2026

In short

Article 99 sets three penalty tiers: up to EUR 35M or 7% of global annual turnover for prohibited practice breaches; up to EUR 15M or 3% for breaches of provider obligations for high-risk systems and GPAI duties; up to EUR 7.5M or 1% for supplying incorrect, incomplete, or misleading information to notified bodies and market surveillance authorities. National market surveillance authorities were required to be designated by 2 August 2025 and are now active across all 27 Member States.

The fine ceilings under Article 99 are the highest of any horizontal EU regulation. For reference, GDPR's top tier is 4% of global turnover or EUR 20M; the AI Act tops out at 7% or EUR 35M. Whichever is higher applies. For a mid-sized European enterprise with EUR 500M in revenue, that is EUR 35M in fine exposure per prohibited-practice event.

The three penalty tiers under Article 99:

• Up to EUR 35M or 7% of global annual turnover, whichever is higher — non-compliance with the prohibition of AI practices under Article 5 (subliminal manipulation, social scoring, real-time biometric identification in public spaces outside listed exceptions, and other listed practices).
• Up to EUR 15M or 3% of global annual turnover — non-compliance with obligations for providers of high-risk AI systems (Articles 16 and 22-29), obligations for deployers (Article 26), obligations for notified bodies, GPAI obligations (Chapter V), and transparency obligations under Article 50.
• Up to EUR 7.5M or 1% of global annual turnover — supply of incorrect, incomplete, or misleading information to notified bodies and national competent authorities in reply to a request.

Small and medium-sized enterprises are subject to the same percentages but capped at the lower of the two numbers, not the higher (Article 99(6)) — that is the only meaningful SME concession in the fine schedule.

Enforcement infrastructure. Each Member State designated at least one notifying authority and one market surveillance authority under Article 70, with the 2 August 2025 designation deadline. Sweden's designated market surveillance authority is IMY (the data protection authority) for most high-risk categories, complemented by the Swedish Post and Telecom Authority (PTS) and other sectoral regulators. Denmark, Finland, and Norway (via EEA incorporation) are in similar postures. The AI Office within the European Commission coordinates enforcement across GPAI.

How Alice Labs runs an EU AI Act engagement

In short

Alice Labs runs EU AI Act engagements as a 12-week programme by default: Weeks 1-2 AI system inventory and Article 6 triage; Weeks 3-4 Annex III gap analysis against the seven Article 9-15 obligations; Weeks 5-8 technical documentation build to Annex IV, FRIA where applicable, human oversight design; Weeks 9-12 conformity assessment, EU database registration, post-market monitoring plan. Senior consultants only. Transparent fixed-scope pricing.

The engagement pattern below is what Alice Labs runs on a typical mid-sized enterprise with 5-15 AI systems in scope. Larger estates run as parallel tracks over a shared Phase 2 platform layer.

• Weeks 1-2 — Inventory and Article 6 triage. Workshops with product owners, procurement, and data teams. Every AI system in the estate is catalogued with role (provider / deployer), intended purpose, data sources, and target user. Each system gets an Article 6 memo — Annex I product limb, Annex III domain limb, or out-of-scope — with the exemption analysis documented.
• Weeks 3-4 — Annex III gap analysis. For each high-risk system, a gap matrix mapped to Articles 9-15. Existing controls are credited; missing controls are turned into a Phase 5-8 workplan. Deployer obligations under Article 26 are analysed separately from provider obligations.
• Weeks 5-8 — Technical documentation build. Annex IV package drafted, risk management file populated, data governance regime documented, human oversight designs specified. FRIA where the deployer sits in scope of Article 27. AI literacy programme designed under Article 4.
• Weeks 9-12 — Conformity, registration, monitoring. Route decision between Annex VI internal control and Annex VII notified body. EU declaration of conformity drafted. EU database registration under Article 71. Post-market monitoring plan (Article 72) and serious-incident runbook (Article 73). CE marking application prepared.

Every deliverable is signed off by a senior Alice Labs consultant with named ownership in the SOW. There is no offshore build wall, no undisclosed subcontracting, and no juniors billed at senior rates. The pricing model is fixed-scope with transparent day rates — no back-loaded scope creep.

For enterprises with a shorter runway or narrower scope, Alice Labs runs a 2-week readiness diagnostic as a scoped entry point: inventory, Article 6 triage on the top 3-5 systems, and a written recommendation whether to proceed to a full 12-week programme, defer, or route the work in-house. Roughly one in eight diagnostic engagements ends there — sometimes the answer is that the estate is simpler than the client feared.

Interaction with GDPR, DSA, DORA, and NIS2

In short

The AI Act layers on existing EU regulation, it does not replace it. GDPR Article 22 automated-decision-making overlaps with Annex III credit scoring and employment use cases. DORA operational resilience testing applies to financial-sector AI systems. NIS2 supply-chain security obligations cover AI vendors serving essential entities. DSA risk assessments for VLOPs intersect with recommender-system transparency. Alice Labs runs integrated compliance workstreams across all four regimes on financial-services and public-sector engagements.

The AI Act does not stand alone. Every serious engagement runs an interaction analysis across the four horizontal regimes most likely to overlap.

• GDPR. Article 22 (automated decision-making with legal or similarly significant effects) overlaps directly with Annex III point 5(b) credit scoring and Annex III point 4 employment scoring. The DPIA under Article 35 and the FRIA under AI Act Article 27 are complementary artefacts. Data governance evidence under AI Act Article 10 must be consistent with lawfulness-of-processing evidence under GDPR Article 6.
• DORA (Regulation (EU) 2022/2554). Financial-sector AI systems that are ICT third-party services fall inside DORA operational resilience testing, incident classification, and register-of-information duties. AI Act Article 15 robustness testing and DORA threat-led penetration testing overlap in scope for trading, credit, and payments AI.
• NIS2 (Directive (EU) 2022/2555). Essential and important entities have supply-chain security obligations under Article 21 that reach their AI vendors. A hospital deploying diagnostic AI must reflect that supply-chain in its NIS2 register; the vendor's AI Act evidence feeds the hospital's NIS2 evidence.
• DSA (Regulation (EU) 2022/2065). Very Large Online Platforms and Very Large Online Search Engines have Article 34 systemic-risk assessments that overlap with AI Act recommender-system transparency obligations. Content moderation AI carries obligations under both regimes.

For Nordic financial services engagements, Alice Labs runs a single integrated compliance workstream across AI Act, GDPR, and DORA — the artefacts share evidence, and running them as separate projects duplicates work and creates internal inconsistency. For public-sector engagements, NIS2 supply-chain obligations shape the vendor-selection criteria that then feed the AI Act deployer file.

AI literacy obligations under Article 4

In short

Article 4 requires providers and deployers to take measures to ensure sufficient AI literacy of staff and other persons dealing with AI systems on their behalf, taking into account their technical knowledge, experience, education, training, and the context of use. The obligation has been enforceable since 2 February 2025. There is no prescribed curriculum, but evidence of a role-based training programme is expected. Alice Labs runs literacy tracks for executives, product, engineering, and risk.

Article 4 is a small article that has outsized operational reach. It applies to every provider and deployer, regardless of high-risk status, and became enforceable on 2 February 2025 — the same date as the Article 5 prohibited-practice ban.

The regulation deliberately does not prescribe a curriculum. What is required is "sufficient AI literacy" proportionate to the role, technical background, and context of use. The evidence expected by market surveillance authorities is:

• A documented training programme with role-based tracks, updated as the AI estate evolves.
• Records of who has completed training and when, retained for the working duration of the AI systems in question.
• Content that covers the specific AI systems the trainee interacts with, not generic AI literacy slideware.
• Integration with human oversight duties under Article 14 — trained operators are the precondition for effective human oversight.

Alice Labs runs role-based literacy tracks on every engagement:

• Executives — regulatory landscape, risk exposure, board-level decisions, and the two questions to ask before signing off an AI deployment.
• Product and business owners — Article 6 classification, intended purpose specification, FRIA where applicable, and how to write a compliant SOW.
• Engineering — Article 9-15 obligations translated into build requirements, logging under Article 12, robustness testing under Article 15.
• Risk, legal, and compliance — post-market monitoring, serious- incident reporting, EU database registration, and interaction with GDPR / DORA / NIS2.

Nordic and cross-border considerations

In short

Sweden, Denmark, and Finland apply the AI Act in full as EU Member States. Norway and Iceland — inside the EEA but not the EU — will incorporate the AI Act into the EEA Agreement with an expected lag; the Norwegian government has confirmed intent, and preparatory work is ongoing. Alice Labs is Stockholm-headquartered and works internationally across the single market with no fake local offices. Nordic engagements typically require cross-border deployer analysis under Article 26.

The Nordic regulatory posture in mid-2026:

• Sweden, Denmark, Finland. Full application as EU Member States. Market surveillance authorities designated by 2 August 2025. Swedish designation routed largely through IMY (data protection authority) and sectoral regulators (Finansinspektionen for financial services, MPA for medical). Finnish designation through Traficom and Traficom-adjacent authorities. Danish designation through Datatilsynet and sectoral regulators.
• Norway. Inside the EEA but not the EU. The Norwegian government (Regjeringen.no) has confirmed that the AI Act will be incorporated into the EEA Agreement, though the incorporation is expected to lag behind EU application by 6-18 months per typical EEA precedent. Enterprises operating in Norway should plan against the EU calendar as a working assumption and confirm the EEA-adopted date closer to the event.
• Iceland. Same EEA path as Norway.
• United Kingdom. Outside the EU and outside the EEA. The UK has taken a principles-based, sectoral approach that diverges from the AI Act. UK enterprises selling into the EU are captured by AI Act Article 2 as third-country providers regardless of the domestic UK regime.

Alice Labs is Stockholm-headquartered and works internationally across the single market. We do not run fake local offices in Oslo, Copenhagen, or Helsinki. On cross-border Nordic engagements — a Swedish bank selling into Norway, a Finnish HR-tech vendor serving Danish employers — the deployer analysis under Article 26 is often the deciding factor in project scope, and it needs to be run per jurisdiction of use, not per jurisdiction of provider establishment.

How to choose an EU AI Act consultant

In short

Four filters separate real EU AI Act consultants from Big 4 pyramid teams and adjacent regulatory shops: (1) ask for evidence of a full Annex IV technical documentation package delivered end-to-end, not a template; (2) verify a senior-only staffing model — named engineers and consultants in the MSA, no offshore juniors; (3) confirm workflow-embedded delivery inside the client build team, not slide-deck consulting; (4) demand transparent fixed-scope pricing with published rate cards, not on-request quotes.

The EU AI Act consulting market grew fast in 2024-2026 and now contains three kinds of firms. Big 4 practices, adjacent regulatory shops from GDPR and DORA backgrounds, and AI-native boutiques that added a compliance workstream to existing build engagements. Buyer education is uneven and the fit between claim and delivered evidence is often poor.

Four filters to run against any prospective consultant:

• Ask for a shipped Annex IV package. A real EU AI Act consultant can show you (redacted) a full Annex IV technical documentation package they built for a client. Not a template. Not a table of contents. The full 60-120 page artefact with risk management records, data governance evidence, and human oversight designs. If they cannot show one, they have not delivered one.
• Verify senior-only staffing. Named individuals in the MSA with substitution requiring client approval. Ask who will be on the ground in Week 5 when the Annex IV drafting starts. If the answer requires qualification, you are buying pyramid staffing dressed as end-to-end.
• Confirm workflow-embedded delivery. The consultant sits inside the build team during technical documentation work. They observe the actual system being built, they interview the engineers, and they produce evidence that reflects the real product. Slide-deck consultants write generic content mapped to your logo.
• Demand transparent pricing. Published day rates, fixed-scope proposals per phase, no on-request quoting theatre. Compliance work has known scope and known effort — a firm that cannot publish rates is protecting margin, not serving a genuinely bespoke need.

For a full ranked comparison of the EU AI Act consulting market see our EU AI Act compliance consultants 2026 guide and the CIO-audience view at best AI governance consultants for CIOs 2026. For the operational checklist that any engagement must close see the EU AI Act compliance checklist 2026.

Alice Labs is a Stockholm-headquartered enterprise AI consultancy delivering EU AI Act readiness across 100+ production AI implementations since 2023. Senior-only staffing. Workflow-embedded delivery. Transparent fixed-scope pricing. Book a 2-week readiness diagnostic to receive a written recommendation within three weeks of kickoff.