EU AI Act Compliance: An Engineering Evidence Checklist

Direct Answer

EU AI Act engineering starts with an accountable applicability decision, then turns each applicable duty into versioned evidence. Code can prove that a release includes an approved role analysis, risk record, test report, instructions, logs, human-oversight design, and post-market plan. Code cannot decide that the legal analysis is correct or issue a declaration of conformity.

The 2026 AI Omnibus changed the implementation timeline and several obligations. A checklist that still assumes one August 2026 deadline, fixed training hours, automatic high-risk classification, or a universal third-party assessment route is no longer safe to use.

This article is an engineering framework, not legal advice.

Key Takeaways

• Record the exact legal text or official timeline used for every release decision.
• Separate operator role, intended purpose, prohibited-practice review, high-risk classification, transparency duties, and GPAI obligations.
• The amended timeline sets 2 December 2027 for Annex III high-risk systems and 2 August 2028 for Annex I product-embedded systems.
• Article 50 transparency requirements apply from 2 August 2026, with a transition to 2 December 2026 for specified pre-existing systems under Article 50(2).
• Engineering automation should validate evidence identity and completeness, not decide legal scope.
• Logs, fairness tests, human review, kill switches, model cards, and CE labels are not interchangeable controls.
• FRIA, GDPR DPIA, conformity assessment, registration, and post-market monitoring each have their own trigger and owner.
• Preserve the previous release and an operational stop path; documentation without executable control is weak evidence.

Current Implementation Timeline

The official EU AI Act Service Desk publishes this post-Omnibus planning sequence:

The AI Omnibus entered into force on 27 July 2026. It also simplified parts of AI literacy and EU database registration, extended some SME measures to small mid-cap companies, expanded sandbox support, introduced another prohibited practice, and changed parts of governance and conformity procedure.

Do not copy this table into a release ticket and call the analysis finished. Amendments, guidance, standards, national enforcement, product legislation, and the system's actual role still determine what applies.

Build an Applicability Record

Start with facts, not a risk label:

assessment_id: eu-ai-2026-104
legal_text:
  regulation: "Regulation (EU) 2024/1689"
  amendment: "Regulation (EU) 2026/1744"
  reviewed_at: "record actual review date"
operator:
  legal_entity: "entity ID"
  roles:
    - "provider or deployer, pending counsel review"
market:
  placed_on_union_market: "unknown"
  put_into_service_in_union: "unknown"
  output_used_in_union: "unknown"
system:
  intended_purpose: "versioned purpose statement"
  prohibited_uses: ["versioned list"]
  model_release: "model bundle ID"
  software_release: "commit and artifact digest"
decisions:
  article_5: "pending"
  article_6_annex_i: "pending"
  article_6_annex_iii: "pending"
  article_50: "pending"
  gpai_role: "pending"
owners:
  legal: "role"
  product: "role"
  engineering: "role"
  security: "role"

Unknown is a valid state before review. Automatically converting a keyword such as “recruitment” or “credit” into a final legal classification hides the facts and exceptions that an accountable reviewer must examine.

Separate Operator Roles

One organization can hold more than one role, and a role can change after integration or substantial modification.

Do not infer responsibility from who pays the model API bill. The role analysis follows the legal definitions and actual product chain.

Classify Duties, Not Just “Risk”

The Commission explains the Act using four risk levels, but implementation needs the exact legal route:

A system can avoid Annex III classification and still have Article 50 transparency duties, GDPR duties, sector rules, contract obligations, or product-safety requirements. An upstream GPAI provider and a downstream AI-system provider can also have different duties for the same product chain.

Create an Obligation Matrix

Translate the reviewed legal route into owned controls:

Article 50 Is Use-Specific

Article 50 does not mean every AI-produced byte receives the same label. Review the exact use:

• systems designed for direct interaction may need to inform people they are interacting with AI, subject to the provision's conditions;
• providers of systems generating synthetic audio, image, video, or text may need machine-readable marking under Article 50(2);
• deployers of emotion-recognition or biometric-categorization systems have specific information duties;
• deepfakes and certain public-interest text have disclosure duties with stated exceptions and presentation requirements.

Record the content type, role, interface, exception analysis, marking method, transformation survival, accessibility, and evidence. Test screenshots, exports, API output, and downstream transformations rather than checking only the first rendering.

High-Risk Evidence Must Be Versioned

For a system on an approved high-risk route, create a release bundle:

release/
  applicability.json
  intended-purpose.md
  operator-roles.json
  risk-register.json
  data-lineage.json
  evaluation-report.json
  cybersecurity-report.json
  instructions-for-use.md
  human-oversight.md
  logging-contract.json
  technical-documentation/
  conformity-route.json
  registrations.json
  post-market-plan.json
  approvals.json
  manifest.sha256

Every file should identify the system release, model and data revisions, policy version, owner, approver, creation time, supersession state, and applicable legal route. A current document linked to an old model is not valid release evidence.

Use Code as an Evidence Gate

The legal route must be approved outside this program. The Go gate only verifies that the approved route has the evidence it declares:

package main

import (
	"errors"
	"fmt"
	"sort"
)

type Route struct {
	ID       string
	Required []string
}

type Bundle struct {
	ReleaseID string
	RouteID   string
	Artifacts map[string]string
	Approved  bool
}

func validate(route Route, bundle Bundle) error {
	if bundle.ReleaseID == "" {
		return errors.New("release ID is required")
	}
	if bundle.RouteID != route.ID {
		return errors.New("bundle does not match the approved legal route")
	}
	if !bundle.Approved {
		return errors.New("accountable approval is missing")
	}

	missing := make([]string, 0)
	for _, name := range route.Required {
		if bundle.Artifacts[name] == "" {
			missing = append(missing, name)
		}
	}
	if len(missing) > 0 {
		sort.Strings(missing)
		return fmt.Errorf("missing evidence: %v", missing)
	}
	return nil
}

func main() {
	route := Route{
		ID: "annex-iii-provider-v3",
		Required: []string{
			"applicability",
			"risk-register",
			"data-lineage",
			"evaluation-report",
			"human-oversight",
			"logging-contract",
			"post-market-plan",
		},
	}
	bundle := Bundle{
		ReleaseID: "release-2026-10-05",
		RouteID:   route.ID,
		Approved:  true,
		Artifacts: map[string]string{
			"applicability":      "sha256:a1",
			"risk-register":      "sha256:b2",
			"data-lineage":       "sha256:c3",
			"evaluation-report":  "sha256:d4",
			"human-oversight":    "sha256:e5",
			"logging-contract":   "sha256:f6",
			"post-market-plan":   "sha256:g7",
		},
	}
	if err := validate(route, bundle); err != nil {
		panic(err)
	}
	fmt.Println("evidence bundle accepted")
}

Expected output:

evidence bundle accepted

This program cannot decide whether the route is correct, whether an artifact is truthful, whether a standard is harmonized, or whether a regulator or notified body will accept it. Those remain review responsibilities.

Logging Must Be Purpose-Bounded

Article 12 logging is not permission to collect unlimited personal data or hidden model reasoning. Define:

• event purpose and legal basis;
• stable system, model, data, policy, and operation identity;
• timestamps and clock assumptions;
• input and output references rather than unnecessary raw content;
• policy, human intervention, state transition, and outcome;
• integrity controls and access separation;
• retention, legal hold, deletion, and export;
• exporter failure and telemetry-loss detection.

Hashing a small identifier space does not anonymize it. A hash chain can make some changes detectable but does not provide access control, lawful retention, or complete immutability.

Evaluation Must Match the Intended Purpose

There is no universal fairness metric or statutory 0.8 threshold. Build a test plan from:

• affected groups and rights;
• decision and error costs;
• representative operating data;
• missing and uncertain labels;
• intersectional slices where sample size permits;
• accuracy, calibration, robustness, cybersecurity, and accessibility;
• human disagreement and appeal outcomes;
• model, data, threshold, and policy revisions.

Report sample counts and uncertainty. An aggregate metric can hide a severe subgroup failure, while a tiny subgroup estimate can be too uncertain to support a conclusion.

Metric names must match the question being audited. Predictive Parity compares positive predictive value among cases receiving a positive decision; it is not full score calibration and is undefined for a group with no positive predictions. A claim about the same person's prediction under a changed protected attribute instead invokes Counterfactual Fairness, which requires an explicit structural causal model and recomputation of causal descendants rather than a one-column data edit.

Human Oversight Must Control the Effect

An oversight mechanism is effective only if the person:

1. receives understandable evidence and system limitations;
2. has time and authority to intervene;
3. can stop, override, or escalate before a protected effect;
4. is not evaluated in a way that rewards automatic approval;
5. can identify automation bias and unusual operating conditions;
6. sees whether the action already occurred before retrying;
7. leaves an auditable decision linked to the release and object revision.

A confidence threshold alone is not human oversight. Model confidence may be uncalibrated, and a high-confidence output can still violate policy or use stale evidence.

Keep FRIA, DPIA, and Conformity Separate

These artifacts can share evidence but answer different questions:

Do not mark FRIA complete for every product by default, and do not assume a DPIA automatically satisfies FRIA.

Post-Market Monitoring Closes the Loop

The release gate is only the beginning. Link production evidence back to the same release identity:

• operating distribution and drift;
• accuracy and error slices;
• policy denials and human overrides;
• complaints, appeals, and accessibility failures;
• security events and attempted misuse;
• serious incident triage and reporting decision;
• supplier or model changes;
• corrective action, rollback, and field notices.

Define who can suspend the system and which conditions trigger reassessment. A model alias, new data source, changed intended purpose, expanded geography, altered human role, or material UI change can invalidate earlier evidence.

Common Failure Modes

Frequently Asked Questions

Does the EU AI Act apply to companies outside the EU?

Potentially. Record provider and deployer roles, market placement, deployment, and specified output use, then review Article 2 under the current text. Hosting location and user count alone are insufficient.

What dates should an engineering roadmap use?

Use the official Service Desk timeline and bind each date to a provision. The amended high-risk milestones are 2 December 2027 for Annex III and 2 August 2028 for Annex I systems; Article 50 and other rules have earlier dates.

Can an AI vendor's documentation satisfy downstream obligations?

It can supply evidence, but the downstream organization still needs its own role, intended purpose, integration, data, evaluation, instructions, oversight, monitoring, and change records where applicable.

Must every AI release receive a CE mark?

No. CE marking follows the applicable high-risk and product-law route. Determine scope and conformity procedure before building release automation around it.

How should engineering handle legal uncertainty?

Represent it explicitly as pending, block the affected release or capability, record the owner and question, and preserve the evidence needed for review. Do not convert uncertainty into a default approval.

Conclusion

EU AI Act readiness is an evidence system, not a collection of compliance-themed components. Start from the current amended law, record the operator and intended-purpose facts, obtain an accountable obligation matrix, and bind each control to immutable release evidence. Use automation to detect missing or mismatched evidence while keeping legal classification, conformity, and residual-risk decisions with authorized reviewers.

For deeper implementation patterns, see the EU AI Act high-risk systems guide, AI compliance engineering guide, and LLM guardrails guide.

Primary Sources

• Regulation (EU) 2024/1689
• Regulation (EU) 2026/1744, AI Omnibus
• European Commission: AI Omnibus enters into force
• EU AI Act implementation timeline
• European Commission AI Act overview
• EU AI Act Service Desk FAQs