ResultsMethodologyAgentsGraphControlsIntegrationsPricingBlogSecurityContact
Board-grade risk scan
Blog · AI Governance

Risk Leaders Build Article 26 Ready EU Data Act and AI Act Program

AETHER Pulse·21 September 2026·13 min read

Risk Leaders Build Article 26 Ready EU Data Act and AI Act Program

Specialist inspecting connected industrial sensor

Both the EU Data Act and the EU AI Act apply to organizations that use IoT or device-generated data with AI systems, and neither law can be handled in isolation. The two regimes create overlapping obligations around data access, documentation, and model use that most compliance functions still treat as separate projects. The single most important first step is an integrated inventory and audit-ready evidence plan that maps device data flows to AI systems and ties both to Article 26 documentation requirements, with AETHER Pulse-style metadata capture as one practical model for producing that evidence.

TL;DR:

  • Most compliance efforts are fragmented, with legal, risk, data engineering, and AI operations handling separate aspects, increasing enforcement risk.
  • Building a comprehensive evidence pack requires mapping data flows, capturing provenance, and securing explicit AI training permissions within contracts.
  • Metadata-only solutions enable organizations to produce tamper-evident audit records without invasive access to customer or production data.
  • Enforcement starts with documentation of AI system inventories and risk classifications, with phased implementation and early audits focusing on high-exposure systems.
  • Using tools like Aether Pulse can help organizations quickly develop an integrated, audit-ready evidence base aligned with both the Data Act and AI Act requirements.

Table of Contents

What the EU Data Act Means for AI-Driven Firms

The EU Data Act governs who controls data generated by connected products, from industrial sensors to consumer wearables, and it directly affects any organization feeding that data into AI models. The regulation entered into force on January 11, 2024, and applies across the EU from September 12, 2025, giving firms a narrow window to align contracts and data pipelines before enforcement begins in earnest.

The law distinguishes between "product data" (generated by the device itself) and "related service data" (generated through digital services tied to the product), and both fall inside the regulation's scope under Regulation (EU) 2023/2854. Users of connected products gain the right to access that data and to direct it to third parties, including AI vendors, which is precisely why the Data Act matters so much to firms building models on IoT telemetry.

Key elements to build into your compliance mapping include:

  • Connected product scope: physical devices that generate data through use, plus any related digital service required to operate them.
  • User access and portability rights: data holders must provide product and related service data on request, often at no cost.
  • Model contractual terms (MCT): EU-published guidance for fair, non-discriminatory data-sharing contracts between holders and recipients.
  • Exclusions that matter: inferred or derived outputs, proprietary algorithms, and IP-protected derivations generally sit outside the access obligation.

That last point trips up a lot of legal teams. Raw sensor readings are covered; the proprietary model you built on top of them typically is not.

What Does the EU AI Act Require of Training and Deployment?

The AI Act does not regulate data access. It regulates what you do with data once an AI system uses it, and it sorts every system into a risk tier that determines how much documentation and oversight you owe regulators.

  1. Risk classification comes first. Systems are grouped as prohibited, high-risk, limited-risk, or minimal-risk, and the tier assigned to your system determines every downstream obligation, from conformity assessments to human oversight requirements.
  2. Article 26 sets deployer duties. Organizations deploying high-risk AI systems must maintain technical documentation, monitor system performance, and keep records demonstrating human oversight was exercised, not just theoretically available.
  3. General-purpose AI (GPAI) gets separate treatment. Providers of foundation-style models face transparency and systemic-risk obligations distinct from the high-risk category, enforced by the AI Office created under the regulation.
  4. Applicability is phased, not immediate. The AI Act entered into force on August 1, 2024, with prohibited-practice bans, GPAI rules, and high-risk obligations landing on staggered dates rather than a single cutover.

The official regulation text, Regulation (EU) 2024/1689, is the primary source for exact obligations by risk tier, and it is worth reading directly rather than relying on secondhand summaries once you reach the high-risk classification threshold.

Where the Data Act and AI Act Actually Collide

Here is the scenario that catches most governance teams off guard: a manufacturer uses the Data Act to obtain access to industrial IoT telemetry from a partner's connected equipment, then feeds that data into a predictive maintenance model. The access itself is lawful under the Data Act. Training a model on it might not be, unless the licensing terms explicitly permit that use.

Legal commentary on this exact issue notes that IoT data made available under the Data Act can be used to train third-party AI models, but only when data recipients secure proper licensing and separately observe GDPR and AI Act obligations. Access rights and training permissions are two different legal questions, and firms that conflate them build compliance gaps into their pipelines from day one.

The friction points worth flagging to your legal and data teams:

  • Access does not equal permission to train. MCT-based contracts need explicit language covering AI training use, not just data transfer.
  • Metadata and derived data get murky fast. Once telemetry is transformed into features or embeddings, tracking provenance back to the original consent or license becomes harder, and regulators will ask for that trace anyway.
  • Personal data triggers GDPR regardless of Data Act access rights. If the IoT stream includes identifiable information, you still need a lawful basis and, in most cases, a data protection impact assessment (DPIA).
  • Predictive maintenance is the clearest real-world example. A model trained on industrial sensor data touches Data Act access rules, AI Act risk classification (maintenance failures can carry safety implications), and potentially GDPR if operator identifiers are embedded in the telemetry.

Pro Tip: Before any IoT dataset enters a training pipeline, run a two-question test: does the contract explicitly permit AI training use, and does the dataset contain any field that could re-identify a person? Failing either question should stop the pipeline, not just flag it.

Turning Obligations Into Owned Controls

Compliance obligations only become manageable once they are assigned to a specific team with a specific deliverable. Spread across legal, risk, data engineering, and AI operations, the core duties look like this:

  • Data provenance and metadata capture: log where every training and validation dataset originated, including the connected product or service that generated it.
  • Contract review and MCT adoption: audit existing data-sharing agreements against the Data Act's model contractual terms and flag any that lack AI-training language.
  • Risk classification and mitigation plans: assign each AI system a risk tier under the AI Act and document the mitigation controls tied to that tier.
  • Documentation, monitoring, and human oversight: maintain the technical files and oversight logs Article 26 expects, updated on a defined cadence rather than reconstructed at audit time.
  • GDPR-specific tasks: confirm a lawful basis for any personal data in the pipeline, honor subject access and erasure rights, and apply data minimization before, not after, model training begins.

Ownership matters as much as the task list. Legal typically owns contract review and MCT language, data engineering owns provenance capture, risk owns classification and mitigation plans, and AI operations owns the day-to-day monitoring and oversight records. Ambiguous ownership is where most of these programs stall before they produce a single usable evidence pack.

What Should Compliance Teams Do This Quarter?

Turning the obligations above into a working program does not require a multi-year roadmap. A focused first quarter looks like this:

  1. Map device-to-AI data flows and tag data types. Identify every AI system that ingests IoT or connected-product data and classify each input as product data, related service data, or personal data.
  2. Run a contract and license triage against MCT guidance. Flag every data-sharing agreement missing explicit AI-training permissions.
  3. Perform DPIAs and risk assessments for systems likely to qualify as high-risk. Prioritize the systems where a maintenance failure, credit decision, or safety outcome is on the line.
  4. Implement metadata capture and provenance logging before training expands. Retrofitting provenance after a model is in production is far harder than building it in from the start.
  5. Assign named owners across Legal, Risk, Data Engineering, and AI Ops. Each task above needs a person, not a department, accountable for delivery.

Pro Tip: Start the pilot on your highest-exposure system, not your easiest one. A lightweight evidence pack on your riskiest AI deployment tells regulators more about your governance maturity than a polished pack on a low-stakes system.

How Do You Build Audit-Ready Evidence Without Invasive Access?

Regulators reviewing AI Act compliance are not primarily looking for a compliance memo. They want provenance records, dataset versioning, and tamper-evident logs of model changes, and documentation of demonstrable provenance is expected to sit at the center of AI Act supervision.

Illustration of AI evidence governance structure

The friction most firms hit is that producing this evidence typically means giving governance tools deep access to production systems, which creates its own risk and slows deployment. A metadata-only approach avoids that trade-off: it captures the inventory, provenance trail, and cryptographic evidence regulators expect without touching the underlying customer data itself.

The governance layer can be built on a metadata-only model that connects through OAuth metadata and generates tamper-evident, cryptographically signed evidence packs, alongside an inventory and identity graph of AI agents. For Article 26 and Data Act audits, the artifacts worth having on hand include:

  • A current inventory of AI systems and the data sources feeding each one.
  • Provenance logs tracing training and validation datasets back to their originating contracts or licenses.
  • Version-controlled records of model changes over time.
  • Signed evidence packs that auditors and regulators can verify independently, without needing system access.

When Do These Rules Actually Take Effect?

The Data Act's application date is September 12, 2025, with model contractual terms guidance meant to precede that deadline so firms can renegotiate contracts in advance. The AI Act's provisions phase in on a rolling schedule following its August 2024 entry into force, with the AI Office holding enforcement authority over GPAI providers and high-risk system obligations as each phase activates. Expect early enforcement to focus on documentation requests and corrective measures before fines become common, though both regulations carry meaningful penalty structures for firms that cannot produce evidence on demand.

Where to Go Deeper on Data Act and AI Act Obligations

Start with the primary texts: the European Commission's Data Act page and EUR-Lex Regulation 2023/2854 for data access rules, and the Commission's AI Act overview alongside EUR-Lex Regulation 2024/1689 for risk-tier obligations. From there, run a gap assessment, pilot an evidence-capture exercise on one system, and triage your highest-risk data contracts. Aetherpulse's guide on EU AI Act obligations for regulated firms covers the governance mechanics in more depth.

The Compliance Gap Nobody Budgets For

The Compliance Gap Nobody Budgets For — overview diagram

Most governance programs still treat data rights and AI obligations as separate workstreams, run by separate teams, on separate timelines. That gap is where enforcement risk concentrates, because a regulator does not care which department owns which regulation.

The realistic starting point is not a comprehensive program. It is one high-impact AI system, one lightweight evidence pilot, and proof that oversight can be demonstrated without shutting down operations to get it. Non-invasive methods earn their place here precisely because they let firms show control without becoming the risk they are trying to manage.

— Eleye

Where AETHER Pulse Fits Into Your Compliance Program

Building the evidence artifacts described above from scratch, provenance logs, signed evidence packs, agent inventories, takes most teams months of internal tooling work before a single audit request arrives. Certain solutions offer metadata-only integration that requires no access to production data, tamper-evident evidence packs, and an inventory and identity graph of AI agents operating across an organization.

Aetherpulse

Each capability maps directly onto the checklist from earlier in this article. Metadata capture satisfies your provenance logging requirement. Signed evidence packs satisfy the tamper-evident record regulators expect under Article 26. Agent inventory and identity graphing satisfy the "map your AI systems" starting point every compliance program needs. If you want a structured path into that first pilot, Aetherpulse's Article 26 readiness audit is built specifically for that starting point, and current plans, including Free, Pro, and Enterprise tiers, are listed on the Aetherpulse platform page. Book a walkthrough to see what an evidence pack looks like against your own AI inventory.

Sources

FAQ

What Is the EU Data Act?

The EU Data Act is a regulation governing access to and use of data generated by connected products and related digital services, granting users rights to obtain and share that data with third parties. It applies across the EU from September 12, 2025, following its entry into force on January 11, 2024.

Has the EU AI Act Passed?

Yes. The AI Act entered into force on August 1, 2024, and its obligations are phasing in on a rolling schedule rather than a single date, with prohibited practices, GPAI rules, and high-risk system requirements activating at different points.

What Are the Main Points of the EU AI Act?

The AI Act sorts systems into risk tiers, from minimal to high-risk, and assigns documentation, transparency, and human oversight duties based on that tier. Article 26 sets specific deployer obligations for high-risk systems, while general-purpose AI providers face separate transparency rules enforced by the AI Office.

Does the EU AI Act Apply to US Firms?

The AI Act applies based on where an AI system is placed on the market or used, not where the provider is headquartered, so US firms deploying or selling AI systems in the EU fall within scope for those systems. A firm with no EU market presence for a given system generally sits outside that system's obligations, though GDPR and Data Act exposure follow separate scope rules.

What Does Aetherpulse Cost?

Aetherpulse offers Free, Pro, and Enterprise plans, with current details available on the Aetherpulse site. Design Partner and Production tiers, along with the Article 26 readiness audit, are listed on the pricing page.

Recommended

Working on Article 26 readiness, deployer-side governance evidence, or AI agent risk at a regulated firm? We'd value 15 minutes of your perspective.

Start a conversation