The EU AI Act Was Not Delayed: Data Engineering Rules for 2026

Last updated: August 2026

A lot of people read the Digital Omnibus headlines in July, concluded the AI Act had been kicked down the road, and moved compliance to next year's budget. That reading is wrong in a way that costs money. Nine days ago, on 2 August 2026, obligations became enforceable that the deferral never touched.

What actually happened: Regulation (EU) 2026/1744, adopted 8 July 2026, published in the Official Journal on 24 July and in force since 27 July, amends the AI Act along with the Basic Aviation and Machinery Regulations. It pushed back deadlines, rewrote how the Commission supervises the largest providers, and added two new prohibitions. It did not repeal the high-risk regime, and it did not soften the technical artefacts you have to produce.

This is written for the people who will have to produce the evidence: data engineers, platform owners, and whoever has to answer "where did this training set come from" in front of an auditor.

Was the EU AI Act delayed? Look at which dates moved

The Omnibus deferred Chapter III, Sections 1, 2 and 3 - classification, risk management, data governance, technical documentation, record-keeping, human oversight, accuracy and robustness, plus the provider and deployer duties hanging off them - for two categories of high-risk system, on two different clocks.

Three rows moved, and only two of them change what a provider of a high-risk system has to build. Note the last row: the Omnibus added two prohibited practices effective 2 December 2026, and a simplification package that creates new prohibitions is not a repeal. Annex III systems in recruitment, credit scoring, education and essential services are still high-risk. That is a schedule change, not an exemption.

What actually switched on for data teams on 2 August 2026

• Article 50 transparency. Providers of systems that interact directly with people must make that fact known, and providers of generative systems must mark synthetic audio, image, video and text machine-readably. Deployers must inform people exposed to emotion recognition or biometric categorisation, and visibly label deepfakes and AI-generated text published on matters of public interest.
• The Commission's fining power over GPAI providers. Article 101 applies from 2 August 2026: up to 3% of total worldwide annual turnover or EUR 15 million, whichever is higher. The underlying obligations have applied since August 2025; what changed is that they became chargeable.
• Centralised supervision. A rewritten Article 75 gives the AI Office exclusive competence over two groups: AI systems built on a general-purpose model where the system and the model come from the same provider or the same undertaking, and systems that are, or are built into, a very large online platform or search engine designated under the DSA. A new Article 75c caps periodic penalty payments for continuing infringements at 5% of average daily income or worldwide annual turnover per day. Per day is the operative phrase.

One narrow piece of relief: the Article 50(2) marking obligation gets a four-month transition, to 2 December 2026, only for generative systems already on the market before 2 August 2026. Anything shipped since has no grace period, and the deployer labelling duties were not extended at all.

The Commission has been shipping guidance rather than waiting. It adopted the final Article 50 transparency guidelines on 20 July 2026, less than two weeks before the obligations applied. The voluntary Code of Practice on Transparency of AI-generated Content was finalised on 10 June 2026, and the Commission and the AI Board have confirmed it as an adequate tool for demonstrating compliance with Article 50(2), (4) and (5). Draft guidelines on the classification of high-risk systems came earlier, on 19 May 2026, with the final version still to come. Read the transparency guidelines before designing a marking scheme, not after.

What sixteen months of deferral actually buys you

It buys time on the assessment, not on the evidence. That distinction is the whole article. A conformity assessment in December 2027 is backward-looking: the technical documentation describes the data the system was trained, validated and tested on, and that data is being collected now. You cannot retrofit provenance onto a dataset assembled two years ago from a managed sync, three CSVs and a scrape someone ran on a laptop.

The deadline moved. Article 12 and Annex IV are untouched, and Article 10's data governance list still asks for exactly what it asked for before. Teams that treat this as sixteen months of nothing will spend December 2027 doing archaeology on their own warehouse.

A second reason not to relax: the deferral was justified by harmonised standards not being ready. prEN 18286, the CEN-CENELEC draft on a quality management system for AI Act regulatory purposes, went out for public enquiry in October 2025 and has since moved to formal vote, but no AI Act standard has yet been cited in the Official Journal - until one is, Article 40's presumption of conformity does not attach. And the co-legislators declined to drop registration: the Article 6(3) "not high-risk" route still requires a filing, now on a reduced form.

What are the EU AI Act data engineering requirements in 2026?

Strip out the legal language and Article 10 is a data governance specification. Each sub-paragraph maps to something you can build in a warehouse.

• 10(2)(b) - origin of data, and for personal data the original purpose of collection. A dataset registry with source lineage per column and a recorded lawful basis. This is the one nobody has and the one you cannot reconstruct later.
• 10(2)(c) - preparation operations. Annotation, labelling, cleaning, enrichment and aggregation, documented. If your transforms live in version-controlled dbt models or Talend jobs you have most of this already. If they live in ad-hoc notebooks, you do not.
• 10(2)(d)-(e) - assumptions and availability. Write down what each field is supposed to measure. The gap between a column's name and what it represents is where most model failures start.
• 10(2)(f)-(g) - bias examination and mitigation. This requires holding the attributes you need to test for bias, which is exactly the data most privacy programmes delete. The Omnibus consolidated the legal basis for that processing into a new Article 4a, which keeps what Article 10(5) allowed providers of high-risk systems and extends it, under the same strict-necessity conditions and safeguards, to other AI systems and to deployers. Read it before your DPO says it is impossible.
• 10(2)(h) - data gaps and shortcomings. A known-issues register attached to the dataset version, not a Jira board that gets archived.
• 10(3) - relevant, sufficiently representative, and to the best extent possible free of errors and complete. That is a data quality framework with thresholds and evidence, not an aspiration.

None of it is exotic. The difference is that from December 2027 it has to stand up in someone else's hands.

Build the dataset manifest before you build the model

The highest-value thing a data team can do this quarter is record, per dataset version, where every source object came from and under what basis. An afternoon to stand up, unrecoverable if skipped.

CREATE SCHEMA IF NOT EXISTS governance.ai;

CREATE TABLE IF NOT EXISTS governance.ai.dataset_manifest (
    dataset_id              STRING        NOT NULL,
    dataset_version         STRING        NOT NULL,
    source_database         STRING        NOT NULL,
    source_schema           STRING        NOT NULL,
    source_object           STRING        NOT NULL,
    snapshot_at             TIMESTAMP_NTZ NOT NULL,
    row_count               NUMBER,
    original_purpose        STRING,        -- Art. 10(2)(b)
    lawful_basis            STRING,        -- recorded at collection, not inferred later
    contains_personal_data  BOOLEAN,
    special_category        BOOLEAN,       -- Art. 4a conditions apply if TRUE
    licence_or_contract     STRING,
    preparation_steps       VARIANT,       -- Art. 10(2)(c)
    stated_assumptions      VARIANT,       -- Art. 10(2)(d)
    known_gaps              VARIANT,       -- Art. 10(2)(h)
    registered_by           STRING        NOT NULL,      -- set explicitly by the registering job
    registered_at           TIMESTAMP_LTZ DEFAULT CURRENT_TIMESTAMP(),
    CONSTRAINT pk_manifest PRIMARY KEY (dataset_id, dataset_version, source_object)
);

CREATE TABLE IF NOT EXISTS governance.ai.dataset_fingerprint (
    dataset_id       STRING,
    dataset_version  STRING,
    frozen_object    STRING,
    row_count        NUMBER,
    content_hash     NUMBER,
    captured_at      TIMESTAMP_LTZ
);

Two fields carry the weight. original_purpose and lawful_basis decide, two years from now, whether a training set is usable or has to be thrown away, and they are the only fields here you cannot derive from the warehouse. Row counts and transformation steps are recoverable from metadata. Purpose and basis live in a contract, a consent record, or someone's memory.

Record-keeping: can you reconstruct what the model was trained on?

Article 12 requires high-risk systems to technically allow automatic recording of events over their lifetime, sufficient to identify risk situations and support post-market monitoring. Article 19 requires providers to keep those logs at least six months. That is the floor: a system in service for five years needs evidence spanning five years.

"Reconstruct" means two things: freeze the exact rows, and prove the frozen copy is the one you used. Cloning does the first, a content hash the second.

-- Freeze the exact rows the model saw. No data movement at creation.
CREATE TABLE ml.features.claims_training_v3_snap_20260811
  CLONE ml.features.claims_training_v3;

-- Fingerprint it, so the technical file can name the bytes that were used.
INSERT INTO governance.ai.dataset_fingerprint
SELECT
    'claims_underwriting'                            AS dataset_id,
    'v3'                                             AS dataset_version,
    'ML.FEATURES.CLAIMS_TRAINING_V3_SNAP_20260811'   AS frozen_object,
    COUNT(*)                                         AS row_count,
    HASH_AGG(*)                                      AS content_hash,
    CURRENT_TIMESTAMP()                              AS captured_at
FROM ml.features.claims_training_v3_snap_20260811;

HASH_AGG(*) is order-independent, so a restored copy matches only if the contents do. That one number turns "we think this is the training set" into "this is the training set."

The gotcha: a clone is not a backup and Time Travel is not an archive. A clone shares micro-partitions with its source and accrues storage as the two diverge, so a 2 TB snapshot that costs nothing in August can cost a full 2 TB by spring.

Column-level lineage is the audit artefact

When an auditor asks where a feature came from, a pipeline diagram is not an answer. Column-level lineage is, because it comes from what the platform executed rather than what someone documented. In Snowflake that means SNOWFLAKE.ACCOUNT_USAGE.ACCESS_HISTORY, specifically OBJECTS_MODIFIED, which records each written column and its direct sources.

SELECT
    ah.query_start_time,
    ah.user_name,
    om.value:objectName::STRING   AS target_object,
    col.value:columnName::STRING  AS target_column,
    src.value:objectName::STRING  AS source_object,
    src.value:columnName::STRING  AS source_column
FROM snowflake.account_usage.access_history ah,
     LATERAL FLATTEN(input => ah.objects_modified)     om,
     LATERAL FLATTEN(input => om.value:columns)        col,
     LATERAL FLATTEN(input => col.value:directSources) src
WHERE om.value:objectName::STRING = 'ML.FEATURES.CLAIMS_TRAINING_V3'
  AND ah.query_start_time >= DATEADD('day', -90, CURRENT_TIMESTAMP())
ORDER BY ah.query_start_time DESC;

Four things will bite you, in the order they usually do:

• Edition. ACCESS_HISTORY requires Enterprise Edition or higher. On Standard this query returns nothing, and you find out during the audit.
• Retention. The ACCOUNT_USAGE views retain roughly a year. A system in service for five years needs lineage older than the view keeps it, so you archive it yourself.
• Latency. ACCESS_HISTORY is not real-time; expect a lag of hours. Any archival job needs an overlapping window.
• Coverage. It records what Snowflake executed. Transformations done in Spark, a Python notebook or a Talend job before the data landed are invisible to it - and that is usually exactly where the interesting decisions were made.

The fix for retention is boring and takes ten minutes:

CREATE TABLE IF NOT EXISTS governance.ai.lineage_archive (
    captured_at       TIMESTAMP_LTZ,
    query_id          STRING,
    query_start_time  TIMESTAMP_LTZ,
    target_object     STRING,
    target_column     STRING,
    source_object     STRING,
    source_column     STRING
);

CREATE OR REPLACE TASK governance.ai.t_archive_lineage
  WAREHOUSE = gov_wh
  SCHEDULE  = 'USING CRON 0 3 * * * UTC'
AS
INSERT INTO governance.ai.lineage_archive
SELECT
    CURRENT_TIMESTAMP(),
    ah.query_id,
    ah.query_start_time,
    om.value:objectName::STRING,
    col.value:columnName::STRING,
    src.value:objectName::STRING,
    src.value:columnName::STRING
FROM snowflake.account_usage.access_history ah,
     LATERAL FLATTEN(input => ah.objects_modified)     om,
     LATERAL FLATTEN(input => om.value:columns)        col,
     LATERAL FLATTEN(input => col.value:directSources) src
WHERE ah.query_start_time >= DATEADD('day', -2, CURRENT_TIMESTAMP())
  AND om.value:objectName::STRING LIKE 'ML.%';

ALTER TASK governance.ai.t_archive_lineage RESUME;

The two-day lookback absorbs the latency. The task's owning role needs IMPORTED PRIVILEGES on the SNOWFLAKE database - the other thing that quietly returns zero rows. Deduplicate on query_id.

Human oversight has to be a pipeline stage, not a PDF

Article 14 requires high-risk systems to be designed so people can effectively oversee them: understand the output, interpret it, decide not to use it, intervene or stop the system. The word doing the work is designed. A policy saying "a human reviews all decisions" is not a design and produces no evidence. The engineering translation is a state machine in a table, with downstream consumption blocked on it.

• Give every scored record a review state. PENDING, ACCEPTED, OVERRIDDEN, ESCALATED, with reviewer identity, timestamp and a free-text reason. The override reason is the most useful field you will collect.
• Make the gate real. If the serving view filters on review state, oversight cannot be skipped under deadline pressure. If it does not, it will be.
• Show the reviewer enough to disagree. Confidence, top contributing features, base rate for the segment. A score and an Approve button is automation bias with extra steps.
• Log the non-events. A month where nobody overrode anything is itself a finding. Rubber-stamping shows up as an override rate of zero.

Build it now, even with the Annex III date in December 2027: retrofitting a blocking review gate into a live scoring pipeline means renegotiating SLAs with everyone downstream, and that conversation is far easier before the pipeline exists.

Article 50 in a pipeline: carry provenance on every generated row

This one is live today, and most platforms fail it for a dull reason: generated content lands in the same table as human-authored content with nothing distinguishing the two. After that merge, you cannot mark what you cannot identify.

The provider duty under Article 50(2) is machine-readable marking of synthetic output. The deployer duties under 50(4) are different and constantly confused with it: a visible, human-perceptible disclosure for deepfakes and for AI-generated text published on matters of public interest. A hidden watermark does not discharge that. If you both generate and publish, you owe both.

• Never let synthetic rows land unflagged. A generated_by column defaulting to 'human', set explicitly on every model-written path, costs nothing and cannot be added retroactively.
• Record model identity and version. When a marking scheme turns out to be strippable, the only way to scope the blast radius is knowing which model wrote which rows.
• Record the marking method and its version. Marking technology will change; your obligation to show what you did at the time will not.
• Keep the human-review flag separate from the generation flag. The 50(4) carve-out for content under human editorial control is a different fact from whether a model wrote the draft.

ISO/IEC 42001 and NIST AI RMF: the de facto operating model

Nobody builds an AI Act programme from the regulation text alone. The market has converged on two documents doing different jobs. ISO/IEC 42001 is the management system: who is accountable, what is in scope, which controls apply. The NIST AI Risk Management Framework is the risk process you run inside that shell.

The combination works because 42001 is deliberately thin on how to assess risk - it says have a process, not what the process is. Govern sets accountability, Map establishes context and identifies risks per system, Measure defines metrics and testing, Manage handles response. Map and Measure are where the data team lives: representativeness testing, bias metrics, drift monitoring, documented data limitations.

One caution, because vendors blur it: neither gives you a presumption of conformity. Under Article 40 that comes only from harmonised standards cited in the Official Journal, and the AI Act-specific CEN-CENELEC work is not there yet. A 42001 certificate is strong evidence of a systematic approach and a useful internal forcing function; it is not a conformity assessment. NIST also treats the RMF as a living document and keeps adding profiles and companion resources around it, so map your controls to the four functions rather than to subcategory numbers.

The cost trap, and what to do before December 2027

Compliance evidence is a storage line item, and it is the one that surprises finance. Three traps, roughly in order of cost.

• Blanket Time Travel extension. Setting DATA_RETENTION_TIME_IN_DAYS = 90 at account level is the reflex answer to "we need to reconstruct things." On a high-churn raw zone it multiplies storage on every table, and Fail-safe adds seven more days you pay for and cannot query. Set it per object, on the tables in an AI system's lineage. Nothing else.
• Snapshot drift. Clones are free at creation and stop being free as the source changes. Five years of quarterly training snapshots on a large feature table quietly becomes real, full-price storage. Unload older ones to external stage as Parquet or Iceberg, hash alongside.
• Lineage archive growth. The flattened archive produces one row per target column per source column per query - millions of rows a week on a busy transformation layer. Cluster on target object and roll old detail up to a distinct edge list.

If you do nothing else this quarter, do four things in order. Work out honestly whether anything you run touches Annex III - recruitment, credit, education, essential services, worker management. Stand up the dataset manifest and populate purpose and lawful basis on new collection from today. Turn on lineage archival so a twelve-month window stops being your evidence horizon. And if you generate content, add the provenance columns before the next merge makes synthetic and human rows indistinguishable.

That is a quarter of unglamorous work, not a two-year programme, and it turns December 2027 from a scramble into a formality. A team that cannot say where its training data came from has a model problem long before it has a regulatory one.