EU Data Act (2023/2854): B2B Data Sharing, Smart Contracts, and AI Training Data — Developer Guide

The EU Data Act — Regulation (EU) 2023/2854 — became applicable on 12 September 2025. If you read about the Data Act before that date, you probably heard about cloud switching rights (Chapter VI, Articles 23–31). That part gets the coverage because it directly affects developers running workloads on AWS, Azure, or GCP.

But the Data Act is much broader. Chapter II–IV creates binding B2B data sharing obligations for IoT and connected product manufacturers. Chapter V gives governments emergency access to private-sector data. Article 33 introduces mandatory safeguards for smart contracts used in automated data sharing. And the intersection of the Data Act with GDPR and the EU AI Act creates a governance regime for training data that most AI developers are not yet aware of.

This guide covers what Chapter VI does not: the B2B, B2G, Smart Contract, and AI training data provisions.

See also: EU Data Act 2025: Your Right to Switch Cloud Providers (Chapter VI Guide) for the cloud switching provisions.

What the EU Data Act Actually Covers

Regulation (EU) 2023/2854 spans seven substantive chapters:

The cloud switching rights (Chapter VI) and the data access rights for connected products (Chapters II–III) apply from 12 September 2025. The FRAND-terms provisions for B2B contracts have phased application. Article 33 (smart contracts) applies from the same September 2025 date.

Chapter II–III: B2B Data Sharing for Connected Products (Art.4–8)

What Counts as a "Connected Product"?

Article 2(5) defines a "product with a network connection" broadly: any physical product that can connect to the internet or to other devices, collects or generates data about its use or environment, and transmits that data. This includes:

• Industrial IoT sensors (factory floors, supply chains)
• Smart building systems (HVAC, access control, energy monitors)
• Connected vehicles (OBD, telemetry, driver assistance systems)
• Wearable devices and medical monitors
• Consumer electronics that log usage data
• Agricultural IoT (soil sensors, irrigation systems)

If you manufacture, import, or place such products on the EU market — or build the firmware, OS, or cloud platform that processes their data — the Data Act applies to your data architecture.

Article 4: User Access Rights

Article 4 gives users (both consumers and business customers) the right to access data generated by the products they use, in real time and for free. The data holder (typically the manufacturer or platform operator) must:

1. Provide structured access — machine-readable format, continuous or on-demand, without unnecessary friction
2. No access fee — data holders cannot charge users to access their own usage data
3. Reasonable technical means — no requirement for users to contact support; the product or API must expose the data directly
4. Metadata included — the access right covers not just raw sensor data but metadata describing format, collection frequency, and accuracy

Practically, this means if you manufacture a smart energy meter, a connected vehicle, or an industrial sensor and sell it in the EU, your product must ship with an API or user interface that allows the customer to retrieve the full usage dataset, in real time, at no charge.

# Data Act Art.4 — Compliant data access endpoint pattern
from datetime import datetime
from typing import Any

class DataActAccessEndpoint:
    """
    Implements Art.4 data access right for connected product data.
    Users must be able to retrieve their device data in machine-readable
    format, in real time, without friction or fees.
    """

    def get_user_device_data(
        self,
        user_id: str,
        device_id: str,
        from_ts: datetime,
        to_ts: datetime,
        format: str = "json"  # json, csv, parquet — Art.4(2) machine-readable
    ) -> dict[str, Any]:

        # Verify ownership — Art.4 right belongs to the USER of the product
        if not self._verify_ownership(user_id, device_id):
            raise PermissionError("Device not associated with this user account")

        # Retrieve data — no fee, no delay requirement (Art.4(1))
        data = self._fetch_device_data(device_id, from_ts, to_ts)

        return {
            "device_id": device_id,
            "data_holder": "manufacturer_name",
            "regulation": "EU Data Act 2023/2854 Art.4",
            "data_format": format,
            "collection_frequency_seconds": data["metadata"]["frequency"],
            "accuracy_description": data["metadata"]["accuracy"],
            "records": data["records"],
            "timestamp": datetime.utcnow().isoformat(),
        }

Article 5: Obligations When Users Share Data with Third Parties

Article 5 extends the user access right into a B2B sharing mechanism: users can instruct the data holder to share their data with a third-party data recipient (a competing service provider, a repair shop, an analytics platform, a research institution). When instructed, the data holder must:

• Share directly with the recipient by default — users should not be forced to download and re-upload
• Provide the same quality and format as the data holder uses internally
• Not use contractual terms to discourage third-party sharing
• Not use technical barriers (throttled APIs, degraded formats) to disadvantage third-party recipients

The data holder may claim a trade secret exception if sharing would disclose proprietary technical details not generated by the user's activity. The burden of proof is on the data holder; the exception is narrow.

Article 6: Third-Party B2B Data Sharing (FRAND Terms)

Article 6 is the most commercially significant B2B provision. It requires data holders to make product-generated data available to third-party data recipients at FRAND (Fair, Reasonable, and Non-Discriminatory) terms.

FRAND is a concept from patent licensing, applied here to data sharing contracts:

Article 6(5) explicitly prohibits data holders from using their market position to impose terms that would be considered unfair or abusive under competition law. The European Commission is developing non-binding model contractual clauses to operationalize FRAND requirements — this guidance is expected to reduce compliance ambiguity.

What this means for developers: If you build a platform that aggregates IoT data from multiple manufacturers (energy management, fleet telematics, building automation), you now have a legal right to access device data under FRAND terms. Data holders who refuse or impose discriminatory fees are in violation of the Data Act, enforceable by national supervisory authorities.

Chapter V: B2G Data Access — Government Emergency Powers (Art.9–15)

Articles 9–15 give public sector bodies (government agencies, EU institutions) the right to request access to privately-held data in exceptional circumstances. This is the B2G (Business-to-Government) data access mechanism.

When Can Governments Request Your Data?

Article 9(1) lists three grounds:

1. Public emergency — natural disasters, major accidents, pandemics, terrorist incidents
2. Prevention of public emergency — when there is evidence of an imminent threat
3. Recovery from public emergency — post-crisis data needed for rebuilding or assessment

The government body must issue a formal request specifying:

• The legal basis
• The nature and scope of data requested
• The purpose (limited to the stated emergency)
• The retention period (data must be deleted when no longer needed)

Article 11: Safeguards for Data Holders

Data holders who receive B2G requests are not without protection:

• Confidentiality obligation: the requesting body cannot publicly disclose trade secrets
• Data minimization: the request must be limited to data strictly necessary for the stated purpose
• Compensation right (Article 9(4)): for SMEs, the data holder may request reasonable compensation for technical compliance costs
• Challenge mechanism: data holders can challenge the legal basis of a request before an independent authority

Article 14: Data Retention and Deletion

Data provided under B2G mechanisms must be deleted by the government body once the emergency purpose has been fulfilled. The data holder must receive written confirmation of deletion. Article 14 prohibits governments from retaining or further processing the data for other purposes — a principle analogous to purpose limitation under GDPR Article 5(1)(b).

# Data Act Art.9-14 — B2G data sharing compliance tracker

from dataclasses import dataclass, field
from datetime import datetime, date
from enum import Enum

class B2GRequestStatus(Enum):
    RECEIVED = "received"
    UNDER_REVIEW = "under_review"
    APPROVED = "approved"
    REJECTED = "rejected"
    DATA_PROVIDED = "data_provided"
    DELETION_CONFIRMED = "deletion_confirmed"

@dataclass
class B2GDataSharingRecord:
    """
    Art.9-14 compliance tracking for B2G data access requests.
    Immutable audit trail for each government data access.
    """
    request_id: str
    requesting_body: str
    legal_basis: str                     # Art.9(1)(a/b/c) — emergency type
    data_scope: str                      # Description of data requested
    requested_purpose: str               # Limited to stated emergency
    request_date: date
    status: B2GRequestStatus
    data_categories: list[str] = field(default_factory=list)
    retention_period_days: int = 0       # As specified in request
    deletion_confirmed_date: date | None = None
    trade_secret_exemptions_claimed: list[str] = field(default_factory=list)
    compensation_claimed: bool = False   # Art.9(4) SME compensation right

    def can_respond(self) -> bool:
        """Art.11: Verify request has required fields before providing data."""
        return all([
            self.legal_basis,
            self.requested_purpose,
            self.data_scope,
            self.retention_period_days > 0
        ])

    def mark_deletion_confirmed(self, confirmed_date: date) -> None:
        """Art.14: Record government's deletion confirmation."""
        if self.status != B2GRequestStatus.DATA_PROVIDED:
            raise ValueError("Cannot confirm deletion before data was provided")
        self.deletion_confirmed_date = confirmed_date
        self.status = B2GRequestStatus.DELETION_CONFIRMED

Article 33: Smart Contracts for Automated Data Sharing

Article 33 is unique in EU regulation: it directly addresses blockchain-based smart contracts as a mechanism for automated data sharing under the Data Act. If you deploy a smart contract that automates B2B data sharing obligations imposed by the Data Act, Article 33 applies.

Mandatory Smart Contract Safeguards

Article 33 requires that smart contracts used for Data Act compliance meet six technical requirements:

The "Kill Switch" Requirement

The most technically demanding requirement is the safe termination mechanism — informally called the "kill switch." Article 33(f) requires that the contract can be interrupted or stopped in cases where:

• A court order invalidates the underlying data sharing agreement
• The data holder exercises a trade secret exemption
• The B2G emergency purpose has been fulfilled and data must no longer flow
• The FRAND conditions are modified by mutual agreement

For Ethereum-based contracts, this typically means implementing a pausable pattern or a role-based access control that allows the data holder (or a regulatory authority) to halt execution:

// Data Act Art.33 — Compliant smart contract pattern (Solidity)
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "@openzeppelin/contracts/access/AccessControl.sol";
import "@openzeppelin/contracts/security/Pausable.sol";

contract DataActDataSharingContract is AccessControl, Pausable {
    bytes32 public constant DATA_HOLDER_ROLE = keccak256("DATA_HOLDER_ROLE");
    bytes32 public constant REGULATOR_ROLE = keccak256("REGULATOR_ROLE");

    // Art.33 — data archiving: all exchanges logged immutably
    event DataExchangeExecuted(
        address indexed recipient,
        bytes32 dataHash,
        uint256 timestamp,
        string frandTermsRef
    );

    // Art.33 — safe termination: regulatory override
    event ContractTerminated(address indexed terminatedBy, string reason);

    constructor(address dataHolder, address regulatoryAuthority) {
        _grantRole(DATA_HOLDER_ROLE, dataHolder);
        _grantRole(REGULATOR_ROLE, regulatoryAuthority);
    }

    function executeDataShare(
        address recipient,
        bytes32 dataHash,
        string calldata frandTermsRef
    ) external onlyRole(DATA_HOLDER_ROLE) whenNotPaused {
        // Art.33 — access control: only data holder triggers sharing
        emit DataExchangeExecuted(recipient, dataHash, block.timestamp, frandTermsRef);
    }

    // Art.33(f) kill switch — callable by data holder OR regulator
    function terminateDataSharing(string calldata reason)
        external
    {
        require(
            hasRole(DATA_HOLDER_ROLE, msg.sender) ||
            hasRole(REGULATOR_ROLE, msg.sender),
            "Not authorized to terminate"
        );
        _pause();
        emit ContractTerminated(msg.sender, reason);
    }
}

Jurisdiction Problem for Smart Contracts

Article 33's requirements apply to contracts used to execute Data Act obligations. But on most public blockchains, the executing node infrastructure is geographically distributed — including nodes in the United States. This creates a CLOUD Act exposure analogous to the cloud hosting problem: US-based blockchain nodes can be subject to DOJ warrants for data accessible to the contract.

EU-native blockchain infrastructure (private or consortium chains running on EU-jurisdiction nodes) avoids this exposure. For Data Act smart contracts, the jurisdiction of the execution environment matters — not just the jurisdiction of the contract authors.

Data Act × GDPR: The Personal vs Non-Personal Data Problem

The EU Data Act was designed for non-personal data — machine-generated data that does not identify individuals. But in practice, most IoT data is mixed: a smart meter reading combined with an account identifier is personal data under GDPR. A vehicle telemetry dataset combined with a VIN and owner record is personal.

The Mixed Dataset Problem

Article 2(13) of the Data Act defines a "mixed dataset" as data that contains both personal and non-personal data. The regulation's handling of mixed datasets is complex:

For mixed datasets, GDPR does not cease to apply simply because the data also falls within Data Act scope. This means:

• Art.4 Data Act access rights do not override GDPR Article 6 lawfulness requirements
• A user requesting access to their connected device data under Art.4 Data Act is also exercising a GDPR Article 15 subject access right — both obligations apply
• Third-party recipients under Art.5/6 Data Act must have a GDPR lawful basis for receiving personal data — FRAND terms alone are not a lawful basis

Practical GDPR × Data Act Checklist for Developers

# Data Act + GDPR intersection — mixed dataset classification

from dataclasses import dataclass
from enum import Enum

class DataClassification(Enum):
    PERSONAL_ONLY = "gdpr_only"
    NON_PERSONAL_ONLY = "data_act_only"
    MIXED = "both_apply"

@dataclass
class IoTDatasetClassification:
    """Classify IoT datasets for GDPR × Data Act compliance."""

    dataset_id: str
    contains_personal_identifiers: bool   # Name, email, device-linked VIN, IP
    contains_machine_generated: bool      # Sensor readings, telemetry, logs
    can_be_separated: bool               # Can personal be stripped without loss of value?

    @property
    def classification(self) -> DataClassification:
        if self.contains_personal_identifiers and self.contains_machine_generated:
            return DataClassification.MIXED
        elif self.contains_personal_identifiers:
            return DataClassification.PERSONAL_ONLY
        else:
            return DataClassification.NON_PERSONAL_ONLY

    def compliance_requirements(self) -> list[str]:
        c = self.classification
        reqs = []
        if c in (DataClassification.PERSONAL_ONLY, DataClassification.MIXED):
            reqs += [
                "GDPR Art.6 — lawful basis required for all processing",
                "GDPR Art.13/14 — transparency notice at collection",
                "GDPR Art.15 — subject access right response within 30 days",
                "GDPR Art.17 — right to erasure applies to personal elements",
                "GDPR Chapter V — transfer restrictions apply to personal elements",
            ]
        if c in (DataClassification.NON_PERSONAL_ONLY, DataClassification.MIXED):
            reqs += [
                "Data Act Art.4 — user access right to machine-generated data",
                "Data Act Art.5/6 — B2B sharing under FRAND terms",
                "Data Act Art.32 — international transfer restrictions for non-personal",
            ]
        if c == DataClassification.MIXED and self.can_be_separated:
            reqs.append(
                "Data Act Rec.27 — where feasible, separate personal and "
                "non-personal components for independent regulatory treatment"
            )
        return reqs

Data Act × AI Act: Training Data Governance

This is the intersection that catches most AI developers off guard. If you train an AI model using data obtained under the Data Act (either through Art.4 user access rights, Art.5 third-party sharing, or Art.6 B2B FRAND agreements), both the Data Act and the EU AI Act apply to the training dataset.

Dual Obligations on AI Training Data

The critical intersection: Data Act Art.6 FRAND terms define the permitted use of B2B data. If a data sharing agreement specifies the data may be used for operational analytics but not for AI model training, using that data to train a model is a Data Act violation — even if the AI Act would otherwise permit it.

The Training Data Provenance Problem

EU AI Act Article 10(3) requires high-risk AI systems to use training datasets that are "relevant, representative, free of errors and complete." This requires documentation of where training data came from, how it was collected, and what rights the developer holds.

If your training data includes IoT datasets obtained under Data Act provisions, you need to document:

1. The legal basis — was the data accessed under Art.4 (user right), Art.5 (user instruction to share), or Art.6 (FRAND B2B agreement)?
2. The permitted use scope — do the FRAND terms permit training use?
3. The personal data status — was GDPR consent obtained for any personal elements used in training?
4. The geographic origin — data obtained from EU-jurisdiction IoT deployments but processed on US cloud infrastructure triggers CLOUD Act exposure

# AI Act Art.10 + Data Act — training data provenance record

from dataclasses import dataclass, field
from datetime import date

@dataclass
class TrainingDataProvenanceRecord:
    """
    Combined AI Act Art.10(2) + Data Act compliance record
    for training datasets that include IoT/B2B data.
    """
    dataset_id: str
    model_id: str
    collection_period_start: date
    collection_period_end: date

    # Data Act fields
    data_act_legal_basis: str          # Art.4 / Art.5 / Art.6 / Art.9 / none
    frand_agreement_ref: str | None    # Contract ref if Art.6 applies
    frand_permitted_uses: list[str] = field(default_factory=list)
    training_use_explicitly_permitted: bool = False

    # GDPR fields (for personal elements)
    contains_personal_data: bool = False
    gdpr_lawful_basis: str | None = None     # e.g., "consent Art.6(1)(a)"
    pseudonymized: bool = False

    # AI Act Art.10 fields
    ai_act_high_risk_system: bool = False
    known_biases_documented: bool = False
    data_quality_assessment_date: date | None = None
    training_data_specification_version: str = "1.0"

    # Infrastructure jurisdiction
    storage_jurisdiction: str = "EU"         # EU / US / other
    cloud_act_exposure: bool = False         # True if US cloud storage used

    def compliance_gaps(self) -> list[str]:
        gaps = []
        if self.data_act_legal_basis == "Art.6" and not self.training_use_explicitly_permitted:
            gaps.append(
                "DATA ACT: FRAND agreement does not explicitly permit training use — "
                "verify contract terms before training"
            )
        if self.contains_personal_data and not self.gdpr_lawful_basis:
            gaps.append(
                "GDPR: Personal data in training set lacks documented lawful basis"
            )
        if self.ai_act_high_risk_system and not self.known_biases_documented:
            gaps.append(
                "AI ACT Art.10(3): High-risk AI training data — "
                "known biases must be documented"
            )
        if self.cloud_act_exposure and self.storage_jurisdiction != "EU":
            gaps.append(
                "DATA ACT Art.32 + CLOUD ACT: Training data on US cloud = "
                "parallel US government access risk to EU IoT data"
            )
        return gaps

Article 32: International Data Transfers for Non-Personal Data

GDPR has Chapter V (Articles 44–49) restricting transfers of personal data outside the EU/EEA. The Data Act introduces a parallel mechanism for non-personal data under Article 32.

Article 32(1) prohibits transferring non-personal data outside the EU if the transfer would conflict with EU law or the law of any EU Member State. The concern is primarily about foreign government access: a US cloud provider storing EU industrial IoT data can be compelled by US courts under the CLOUD Act to disclose that data to US authorities — regardless of where the data was generated.

What "Conflict with EU Law" Means

The European Data Protection Board's guidance on GDPR international transfers provides useful analogy: any situation where a foreign government can access EU data without a mechanism equivalent to an EU MLAT (mutual legal assistance treaty) creates a structural incompatibility.

For non-personal IoT data stored on US cloud infrastructure:

• CLOUD Act §2523: permits US government to compel cloud providers to disclose data stored on servers anywhere in the world
• No MLAT requirement: US law does not require the provider to redirect requests through EU courts
• Data Act Art.32: this creates a conflict with EU law — specifically, with EU trade secret protections and industrial data sovereignty expectations

EU-native PaaS infrastructure where the operating company, legal entity, and data storage are all under EU jurisdiction eliminates this conflict. The CLOUD Act cannot reach a provider that has no US legal nexus.

Enforcement and Fines

The Data Act does not create its own supervisory authority. Enforcement is assigned to national competent authorities (typically digital economy or competition regulators). Penalties vary by Member State, but the Regulation sets an outer bound:

The Data Act enforcement adds to an already significant regulatory stack. Combined with GDPR (€20M/4%), AI Act (€35M/7%), NIS2 (€10M/2%), and CRA (€15M/2.5%), IoT and AI developers can face multiple concurrent enforcement actions for the same dataset if it is both personal, machine-generated, used in a high-risk AI system, and stored on non-EU infrastructure.

Infrastructure Jurisdiction and the Data Act Stack

The Data Act creates a legal incentive to keep data in EU-jurisdiction infrastructure that parallels but is separate from GDPR:

For a developer building an IoT data pipeline that feeds a high-risk AI system, running on EU-native infrastructure resolves three simultaneous legal risks:

1. GDPR Chapter V — personal data components stay under EU jurisdiction
2. Data Act Art.32 — non-personal industrial data not subject to CLOUD Act
3. AI Act Art.10 — training data provenance documentation shows single-jurisdiction governance

US cloud infrastructure creates CLOUD Act exposure on all three simultaneously.

What to Do Now

If you manufacture IoT/connected products sold in the EU:

• Implement Art.4 compliant data access APIs (machine-readable, real-time, no fee)
• Audit existing B2B data sharing agreements for FRAND compliance
• Add Article 14 deletion confirmation workflows to B2G response procedures

If you use B2B IoT data from other manufacturers:

• Identify which data flows now have FRAND terms obligations on the supplier side
• Check whether data sharing contracts predate the Data Act and need updating
• Verify that Art.5/6 sharing authorizations cover your intended use (including AI training)

If you build AI systems trained on IoT data:

• Add Data Act legal basis fields to your training data provenance records
• Verify FRAND agreement terms explicitly permit training use
• Document the GDPR × Data Act classification for mixed datasets

If you use smart contracts for data sharing:

• Implement Art.33 kill switch (pause/terminate mechanism)
• Store data exchange event logs for audit access
• Ensure contract infrastructure uses EU-jurisdiction nodes if executing EU data obligations

See Also

• EU Data Act 2025: Cloud Switching Rights (Chapter VI, Art.23-31)
• EU AI Act: Training Data and High-Risk AI Conformity Assessment
• EU AI Liability Directive (AILD) + PLD 2024: Developer Guide
• GDPR Article 25: Privacy by Design for PaaS and SaaS Developers
• EU NIS2 + AI Act: Critical Infrastructure Double Compliance