The EU Data Act: Sharing Industrial and IoT Data Compliantly

Introduction

The European Union's Data Act (Regulation (EU) 2023/2844), which entered into force on 11 January 2024 and will apply from 12 September 2025, represents a pivotal legislative instrument designed to unlock the economic and societal value of data within the EU. As a cornerstone of the European Data Strategy, the Act establishes harmonized rules on fair access to and use of data, with a particular focus on data generated by connected products (Internet of Things or IoT) and related services. For businesses operating in the B2B landscape, especially those involved in manufacturing, operating, or utilizing industrial IoT devices, this regulation mandates a fundamental shift in data governance, contractual arrangements, and technical infrastructure.

This article delves into the critical aspects of the Data Act pertinent to B2B data sharing, encompassing user rights, data holder obligations, the intricacies of fair, reasonable, and non-discriminatory (FRAND) terms, and the emergent role of smart contracts in ensuring compliance and efficiency in data exchange.

Scope and Key Definitions

The Data Act applies to manufacturers of connected products and providers of related services placed on the EU market, irrespective of their origin, and to users of these products or services. It also impacts third-party data recipients and public sector bodies requesting data under exceptional circumstances.

Key definitions under the Act include:

• Product: A tangible movable item that obtains, generates, or collects data concerning its use or environment and is able to transmit that data via an electronic communications service, physical connection, or on-device storage. This extensively covers industrial machinery, smart devices, connected vehicles, and other IoT assets.
• Related service: A service that is connected with a product in such a way that its proper functioning requires the collection of data generated by the product.
• Data holder: A legal or natural person who has the right or obligation, in accordance with applicable Union law, to use and to make available certain data. Typically, this is the manufacturer of the product or the provider of the related service.
• Data user: A legal or natural person, other than the data holder, to whom the data holder makes data available. This can be another business, a service provider, or the end-user of a product.
• Data: Any digital representation of acts, facts, or ideas, including data generated by products or related services. The Act distinguishes between personal data (covered primarily by GDPR) and non-personal data, but its provisions apply to both, with GDPR taking precedence for personal data.

Data Sharing Obligations and Rights in B2B Contexts

The core principle of the Data Act is to empower users of connected products and related services to control the data they generate through their use. This user-centric approach has profound implications for B2B relationships.

User Rights

Users, whether businesses or consumers, gain the right to access the data generated by their use of a product or related service. Furthermore, they have the right to request that the data holder make this data available directly to a third party of their choice, subject to specific conditions. This means a manufacturing company operating an industrial robot, for instance, can demand access to its operational data and instruct the robot's manufacturer (the data holder) to share that data with a predictive maintenance service provider (a third party).

Data Holder Obligations

Data holders are subject to several critical obligations when making data available to users or third parties:

1. Access on Request: Data holders must make data available to users (and, at the user's request, to third parties) without undue delay, free of charge for B2C, and under FRAND terms for B2B.
2. Ease of Access: Data must be made available in a readily available, structured, commonly used, and machine-readable format.
3. Transparency: Data holders must provide clear and comprehensive information to users about the data generated by the product, how it is collected, and how users can exercise their data access rights.
4. No Obstruction: Data holders cannot design products or services in a way that prevents users from accessing their data or requesting its sharing.

Third-Party Access Restrictions

While facilitating data sharing, the Data Act also imposes restrictions on third-party data users, particularly in B2B contexts, to prevent market distortion:

• No Competing Products: A third party receiving data at the user's request generally cannot use that data to develop a product or service that competes with the product or related service from which the data originated, unless explicitly agreed.
• No DMA Gatekeepers: Designated gatekeepers under the Digital Markets Act (DMA) cannot be chosen as third-party data recipients, except under specific circumstances (e.g., if the data is essential for an interoperable ancillary service).
• Contractual Limitations: Data sharing agreements must clearly define permitted purposes and prohibit uses that fall under these restrictions.

Fair, Reasonable, and Non-Discriminatory (FRAND) Terms

A cornerstone of B2B data sharing under the Data Act is the requirement for data holders to make data available to data users (and third parties at a user's request) under FRAND terms. This is critical for preventing exploitative practices and fostering a competitive data economy.

Criteria for FRAND Terms:

The Act provides guidance on what constitutes FRAND terms, without prescribing specific pricing models:

• Fair: Terms must be balanced, avoiding overly restrictive clauses or clauses that grant disproportionate advantages. They should not impose unnecessary costs or obligations on the data user.
• Reasonable: Compensation for data holders (in B2B) must be reasonable and reflect the costs incurred in making the data available. It should not be used to extract value from the data itself or to capture rents. This generally implies a "cost-plus" model, covering technical infrastructure, security, data preparation, and administrative overheads, but not speculative profits derived from the inherent value of the data.
• Non-Discriminatory: Data holders must offer comparable conditions for making available comparable data to similar categories of data users. This prevents preferential treatment that could stifle competition.

Dispute Resolution

In the event of a dispute over FRAND terms, the Data Act provides for a robust dispute resolution mechanism. Parties can refer disputes to certified dispute settlement bodies, ensuring an accessible and efficient means of resolving disagreements outside of lengthy court proceedings.

Data Sharing Agreements and Contractual Provisions

Formal data sharing agreements are essential for B2B data exchange under the Data Act. These contracts must meticulously reflect the Act's requirements and clarify the rights and obligations of all parties involved. Key contractual provisions should include:

• Scope of Data: Precise definition of the data to be shared.
• Permitted Purposes: Explicit enumeration of the purposes for which the data user or third party can process the data.
• Prohibited Uses: Clear stipulations against developing competing products, sharing with DMA gatekeepers, or other restricted activities.
• Data Security and Protection: Comprehensive obligations for implementing appropriate technical and organizational measures to protect the shared data, including compliance with GDPR for personal data.
• Compensation: Detailed terms regarding the reasonable compensation to be paid to the data holder, aligned with the FRAND principles.
• Liability: Allocation of liability for breaches of the agreement or data protection obligations.
• Duration and Termination: Conditions for the agreement's term and termination.
• Audit Rights: Provisions allowing the data holder to audit the data user's compliance with the agreement's terms.
• Data Portability and Deletion: Requirements for data users to return or delete data upon termination.

Smart Contracts Criteria under the Data Act

The Data Act encourages the use of smart contracts to facilitate data sharing, particularly for the automated execution of data access and compensation terms. Smart contracts offer transparency, immutability, and efficient enforcement, aligning with the Act's goals of fostering a frictionless data economy.

For smart contracts to be deemed compliant and reliable under the Data Act, they should satisfy the following criteria:

• Robustness and Reliability: The underlying technology (e.g., blockchain or distributed ledger technology) must be secure and resistant to manipulation.
• Self-Execution: The contract should automatically execute predefined actions (e.g., granting data access, releasing payment) upon the fulfillment of specified conditions.
• Interoperability: Smart contracts should be designed to interoperate with existing IT systems and data infrastructure, enabling seamless data flow.
• Immutability and Auditability: Once deployed, the terms and execution history of the smart contract should be immutable and auditable, providing a transparent record of data access events and payments.
• Legal Certainty: Crucially, the smart contract's code must accurately reflect the legal terms of the data sharing agreement, ensuring legal enforceability. This often requires careful legal and technical mapping.
• Security: Smart contracts must be designed with security by design principles to prevent vulnerabilities and cyberattacks.

While offering significant benefits in automating compliance, challenges remain, particularly in mapping complex legal nuances to code and establishing dispute resolution mechanisms for code-based contractual disagreements.

Data Holder vs. Data User Obligations and Compensation Limits

The table below summarizes the key obligations and compensation considerations for data holders and data users in a B2B context under the EU Data Act. It is important to note that the Act does not specify explicit monetary "limits" for compensation but rather mandates that compensation must be "reasonable" and based on "costs incurred," not value extraction.

| Feature/Role | Data Holder (e.g., Product Manufacturer) | Data User (e.g., Business Utilizing IoT Data) | | :------------------ | :---------------------------------------------------------------------------------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Core Obligation | To make data available to the user, or a third party at the user's request, without undue delay, in a machine-readable format, and under FRAND terms (B2B). Ensure design-by-default for data access for new products from September 12, 2026. | To request access to data generated by product use, adhere to access terms, and respect data usage limitations. | | Data Access | Provide clear information to users about data generated, facilitate easy access mechanisms (e.g., APIs), and avoid technical barriers. Implement technical solutions for data sharing by September 12, 2026, for new products. | Utilize accessed data strictly for the agreed-upon purposes. | | FRAND Terms | Must offer data access under Fair, Reasonable, and Non-Discriminatory contractual terms for B2B requests. Terms must be proportionate to costs incurred in making data available. | Must accept data access under FRAND terms. Has the right to challenge terms deemed non-compliant with the Act's principles. | | Compensation | For B2B: Entitled to reasonable compensation covering the costs directly incurred in making the data available (e.g., technical setup, secure transfer infrastructure, anonymization/pseudonymization costs, maintenance of data sharing mechanisms). Compensation should not include the commercial value of the data itself or be used as a barrier to entry. | For B2B: Obligated to pay reasonable compensation to the data holder, reflecting the costs incurred by the data holder for providing data access. This excludes compensation for the inherent value of the data. Payment terms should be clear in data sharing agreements. No specific monetary limits are defined by the Act; compensation must strictly be cost-based. | | Prohibited Use | Cannot prevent user access or exploit data in a manner that restricts competition unfairly. | Cannot use shared data to develop a product or service that competes with the data holder's product or service (unless explicitly agreed). Cannot share data with designated DMA gatekeepers (except in specific interoperability scenarios). | | Data Security | Implement appropriate technical and organizational measures to protect shared data, ensuring data integrity, confidentiality, and availability. Comply with GDPR for personal data. | Ensure robust security measures for received data. Comply with data protection regulations (e.g., GDPR) for any personal data received. Ensure data is deleted or returned upon agreement termination. | | Dispute Resolution | Engage in good faith negotiations and, if necessary, use certified dispute settlement bodies to resolve disagreements over data access terms or compensation. | Engage in good faith negotiations and, if necessary, use certified dispute settlement bodies. |

Compliance Timeline

The EU Data Act's key dates for application and compliance are:

• 11 January 2024: Date of entry into force.
• 12 September 2025: General date of application of the Data Act. From this date, most provisions of the Act become legally binding.
• 12 September 2026: Specific obligations related to the design and manufacturing of products and related services to ensure data access by design will apply to products and related services placed on the market from this date onwards. This includes obligations to make data readily and directly accessible to the user by default.

Javascript Code Sample: Data Act Compliance Verification Gate

This JavaScript snippet provides a conceptual illustration of how a smart contract or a data access gateway might programmatically verify an industrial or IoT data access request against key compliance requirements of the EU Data Act. In a production environment, this would be part of a larger, more secure system potentially leveraging blockchain or DLT for immutable records and cryptographic verification.

/**
 * @fileoverview Conceptual Smart Contract/Data Access Gate for EU Data Act Compliance Verification.
 * This JavaScript snippet illustrates how a programmatic gate could verify an industrial or IoT data access request
 * against key principles of the EU Data Act before granting data access.
 * It is a simplified representation and would require robust backend integration,
 * blockchain/DLT for true smart contract functionality, and comprehensive legal mapping in a production environment.
 */

// --- Simulated Data Act Compliance Rules and Context ---

// In a real system, these would be retrieved from a secure registry, blockchain state, or policy engine.
const euDataActCompliancePolicy = {
    // Simplified checks for prohibited third-party types (e.g., DMA Gatekeepers)
    prohibitedThirdPartyTypes: ['DMA_GATEKEEPER_STATUS'],
    // Disallowed purposes for third-party data users
    disallowedPurposesForThirdParty: ['COMPETING_PRODUCT_DEVELOPMENT', 'MARKET_MANIPULATION'],
    // Required contractual clauses to ensure FRAND terms, data security, etc.
    requiredContractualClauses: ['FRAND_TERMS_ACCEPTED', 'DATA_SECURITY_COMMITMENT', 'LIABILITY_FRAMEWORK', 'DATA_DELETION_ON_TERMINATION'],
    // Example: A compensation factor reflecting 'reasonable costs' (e.g., 120% of direct costs)
    // This is highly simplified; real FRAND assessment is complex and dynamic.
    maxCompensationFactorAgainstCost: 1.2
};

/**
 * Represents a data access request, potentially originating from a user via a secure application.
 * In a blockchain context, this could be an event or a transaction payload with cryptographic proofs.
 */
class DataAccessRequest {
    /**
     * @param {Object} params - Parameters for the data access request.
     * @param {string} params.requestId - Unique identifier for the request.
     * @param {string} params.productIdentifier - ID of the IoT device or industrial system.
     * @param {string} params.dataHolderId - ID of the data holder (manufacturer/provider).
     * @param {string} params.userId - ID of the product user.
     * @param {string|null} [params.thirdPartyId=null] - ID of the third party requesting data on behalf of the user.
     * @param {string} params.purpose - Stated purpose for data access (e.g., 'PREDICTIVE_MAINTENANCE', 'ENERGY_OPTIMIZATION').
     * @param {string} params.contractHash - Hash of the data sharing agreement/smart contract.
     * @param {string[]} params.requestedDataScope - Array of data types requested (e.g., ['SENSOR_READINGS_LAST_24H', 'USAGE_LOGS']).
     * @param {number} [params.compensationOffered=0] - Proposed compensation for data holder (B2B context).
     * @param {string} params.userConsentSignature - Digital signature from the user confirming consent.
     * @param {string[]} params.thirdPartyDeclarations - Declarations by the third party (e.g., 'NOT_DMA_GATEKEEPER').
     */
    constructor({ requestId, productIdentifier, dataHolderId, userId, thirdPartyId = null, purpose,
                  contractHash, requestedDataScope, compensationOffered = 0, userConsentSignature, thirdPartyDeclarations = [] }) {
        this.requestId = requestId;
        this.productIdentifier = productIdentifier;
        this.dataHolderId = dataHolderId;
        this.userId = userId;
        this.thirdPartyId = thirdPartyId;
        this.purpose = purpose;
        this.contractHash = contractHash;
        this.requestedDataScope = requestedDataScope;
        this.compensationOffered = compensationOffered;
        this.userConsentSignature = userConsentSignature;
        this.thirdPartyDeclarations = thirdPartyDeclarations;
    }

    /**
     * Placeholder for cryptographic user consent verification.
     * In a real system, this would involve public key cryptography.
     * @returns {boolean} True if user consent is valid.
     */
    verifyUserConsent() {
        console.log(`  [Crypto] Verifying user consent signature for request ${this.requestId}...`);
        // Simulate successful verification
        return this.userConsentSignature && this.userConsentSignature.startsWith('SIG_');
    }

    /**
     * Placeholder for verifying that the contract hash corresponds to a contract
     * containing all required clauses as per EU Data Act and policy.
     * @param {string[]} expectedClauses - An array of clause identifiers that must be present.
     * @returns {boolean} True if all required clauses are found within the contract (represented by its hash).
     */
    verifyContractualTerms(expectedClauses) {
        console.log(`  [Contract] Verifying contract hash '${this.contractHash}' for required clauses...`);
        // In reality, this would involve retrieving the contract content (e.g., from IPFS or a secure ledger)
        // and performing a more robust parsing and validation.
        const containsAllClauses = expectedClauses.every(clause => this.contractHash.includes(clause));
        return containsAllClauses;
    }
}

/**
 * Calculates a hypothetical cost for providing the requested data.
 * In a real-world scenario, this would interface with detailed cost accounting systems
 * of the data holder, considering infrastructure, bandwidth, processing, security, etc.
 * @param {string[]} dataScope - The scope of data requested.
 * @returns {number} Estimated cost in EUR.
 */
function calculateDataProvisionCosts(dataScope) {
    const baseCostPerScopeItem = 5.00; // e.g., €5 per type of data requested
    const securityAndInfrastructureOverhead = 15.00; // Fixed overhead
    return (dataScope.length * baseCostPerScopeItem) + securityAndInfrastructureOverhead;
}

/**
 * Simulates a Data Access Gate function that verifies a request against EU Data Act compliance rules.
 * This function would be invoked by a data holder's API gateway, a blockchain smart contract, or a policy engine.
 * @param {DataAccessRequest} request - The data access request object.
 * @returns {Object} An object indicating success or failure with reasons.
 */
function verifyEuDataActCompliance(request) {
    console.log(`\n--- Initiating EU Data Act Compliance Verification for Request ID: ${request.requestId} ---`);

    const results = {
        isCompliant: true,
        reasons: []
    };

    // 1. Verify User Consent (Fundamental Right under Data Act)
    if (!request.verifyUserConsent()) {
        results.isCompliant = false;
        results.reasons.push('USER_CONSENT_INVALID');
    } else {
        console.log('✔ User consent verified.');
    }

    // 2. Check Third-Party Eligibility and Purpose (if applicable)
    if (request.thirdPartyId) {
        console.log(`  [ThirdParty] Checking eligibility for third party: ${request.thirdPartyId}`);

        // Check against prohibited third-party types (e.g., DMA Gatekeepers)
        const isGatekeeper = euDataActCompliancePolicy.prohibitedThirdPartyTypes
                             .some(type => request.thirdPartyDeclarations.includes(type));
        if (isGatekeeper) {
            results.isCompliant = false;
            results.reasons.push('THIRD_PARTY_IS_DMA_GATEKEEPER_OR_PROHIBITED_TYPE');
        } else {
            console.log('✔ Third party is not a designated DMA gatekeeper (based on declaration).');
        }

        // Check against disallowed purposes (e.g., developing competing products)
        const purposeIsDisallowed = euDataActCompliancePolicy.disallowedPurposesForThirdParty
                                    .includes(request.purpose.toUpperCase());
        if (purposeIsDisallowed) {
            results.isCompliant = false;
            results.reasons.push('DISALLOWED_PURPOSE_FOR_THIRD_PARTY');
        } else {
            console.log(`✔ Third party purpose '${request.purpose}' is permitted.`);
        }

        // 3. Verify Contractual Terms (FRAND, Security, Liability, etc.)
        if (!request.verifyContractualTerms(euDataActCompliancePolicy.requiredContractualClauses)) {
            results.isCompliant = false;
            results.reasons.push('CONTRACT_MISSING_REQUIRED_CLAUSES_OR_NOT_FRAND');
        } else {
            console.log('✔ Contractual terms verified (e.g., FRAND, security clauses present).');
        }

        // 4. Check Compensation (B2B Context: FRAND pricing principle)
        const actualCostsForDataProvision = calculateDataProvisionCosts(request.requestedDataScope);
        const maxReasonableCompensation = actualCostsForDataProvision * euDataActCompliancePolicy.maxCompensationFactorAgainstCost;

        console.log(`  [Compensation] Estimated costs for data provision: €${actualCostsForDataProvision.toFixed(2)}`);
        console.log(`  [Compensation] Max reasonable compensation (FRAND guidance): €${maxReasonableCompensation.toFixed(2)}`);

        // Check if offered compensation is within the "reasonable" FRAND range (cost-plus model)
        // A more sophisticated system might allow for negotiation or arbitration if outside.
        if (request.compensationOffered < actualCostsForDataProvision || request.compensationOffered > maxReasonableCompensation) {
            results.isCompliant = false;
            results.reasons.push('COMPENSATION_OFFERED_OUTSIDE_FRAND_RANGE');
            console.warn(`  ⚠ Compensation offered (€${request.compensationOffered.toFixed(2)}) is outside the acceptable FRAND range.`);
        } else {
            console.log(`✔ Compensation offered (€${request.compensationOffered.toFixed(2)}) is within FRAND range.`);
        }
    } else {
        console.log('  [ThirdParty] No third-party involved in this request (direct user access).');
        // For direct B2C user access, compensation would generally not be applicable.
        // For direct B2B user access, FRAND compensation might still apply depending on data holder's costs.
    }

    if (results.isCompliant) {
        console.log(`--- EU Data Act Compliance: SUCCESS for Request ID ${request.requestId} ---`);
    } else {
        console.warn(`--- EU Data Act Compliance: FAILED for Request ID ${request.requestId} ---`);
        console.warn('Reasons for failure:', results.reasons.join('; '));
    }

    return results;
}

// --- Example Usage Scenarios ---

// Scenario 1: Compliant B2B Data Access Request to a Third Party
const compliantRequest = new DataAccessRequest({
    requestId: 'REQ_001_B2B_TP',
    productIdentifier: 'INDUSTRIAL_ROBOT_XYZ_789',
    dataHolderId: 'ROBOTICS_CORP',
    userId: 'MANUFACTURING_LTD',
    thirdPartyId: 'PREDICTIVE_MAINTENANCE_LLC',
    purpose: 'PREDICTIVE_MAINTENANCE',
    contractHash: 'FRAND_TERMS_ACCEPTED_DATA_SECURITY_COMMITMENT_LIABILITY_FRAMEWORK_DATA_DELETION_ON_TERMINATION_VER_1.2',
    requestedDataScope: ['MOTOR_TEMPERATURE', 'VIBRATION_SENSOR_DATA'],
    compensationOffered: 28.00, // Costs for 2 items (10) + security (15) = 25. Max FRAND = 25 * 1.2 = 30. 28 is within range.
    userConsentSignature: 'SIG_USER_XYZ_VALID',
    thirdPartyDeclarations: ['NOT_DMA_GATEKEEPER', 'NO_COMPETING_PRODUCT_DEVELOPMENT']
});
verifyEuDataActCompliance(compliantRequest);

// Scenario 2: Non-Compliant Request - Third party is a gatekeeper
const gatekeeperRequest = new DataAccessRequest({
    requestId: 'REQ_002_GATEKEEPER',
    productIdentifier: 'SMART_HOME_HUB_001',
    dataHolderId: 'IOT_PRODUCER_INC',
    userId: 'RESIDENTIAL_USER_456',
    thirdPartyId: 'GLOBAL_TECH_GIANT_A', // Designated DMA Gatekeeper
    purpose: 'SMART_HOME_ANALYTICS',
    contractHash: 'FRAND_TERMS_ACCEPTED_DATA_SECURITY_COMMITMENT_LIABILITY_FRAMEWORK_DATA_DELETION_ON_TERMINATION_VER_1.0',
    requestedDataScope: ['ENERGY_CONSUMPTION', 'DEVICE_USAGE_STATS'],
    compensationOffered: 35.00,
    userConsentSignature: 'SIG_USER_ABC_VALID',
    thirdPartyDeclarations: ['DMA_GATEKEEPER_STATUS', 'NO_COMPETING_PRODUCT_DEVELOPMENT'] // Simulating declaration
});
verifyEuDataActCompliance(gatekeeperRequest);

// Scenario 3: Non-Compliant Request - Disallowed purpose (developing competing product)
const competingProductRequest = new DataAccessRequest({
    requestId: 'REQ_003_COMPETING_PRODUCT',
    productIdentifier: 'MEDICAL_DIAGNOSTIC_DEVICE_ALPHA',
    dataHolderId: 'MEDTECH_SOLUTIONS_AG',
    userId: 'HOSPITAL_GROUP_Z',
    thirdPartyId: 'NEW_MEDTECH_STARTUP',
    purpose: 'COMPETING_PRODUCT_DEVELOPMENT', // Explicitly disallowed purpose
    contractHash: 'FRAND_TERMS_ACCEPTED_DATA_SECURITY_COMMITMENT_LIABILITY_FRAMEWORK_DATA_DELETION_ON_TERMINATION_VER_1.1',
    requestedDataScope: ['DIAGNOSTIC_OUTPUTS', 'DEVICE_CALIBRATION_DATA'],
    compensationOffered: 40.00,
    userConsentSignature: 'SIG_HOSPITAL_XYZ_VALID',
    thirdPartyDeclarations: ['NOT_DMA_GATEKEEPER', 'ATTEMPTING_COMPETING_PRODUCT_DEVELOPMENT_PURPOSE'] // Simulated
});
verifyEuDataActCompliance(competingProductRequest);

// Scenario 4: Non-Compliant Request - Compensation outside FRAND range (too high)
const expensiveRequest = new DataAccessRequest({
    requestId: 'REQ_004_EXPENSIVE_COMPENSATION',
    productIdentifier: 'INDUSTRIAL_SENSOR_HUB_005',
    dataHolderId: 'SENSOR_TECH_INC',
    userId: 'FACTORY_AUTOMATION_GRP',
    thirdPartyId: 'OPTIMIZATION_SOLUTIONS_LTD',
    purpose: 'PROCESS_OPTIMIZATION',
    contractHash: 'FRAND_TERMS_ACCEPTED_DATA_SECURITY_COMMITMENT_LIABILITY_FRAMEWORK_DATA_DELETION_ON_TERMINATION_VER_1.3',
    requestedDataScope: ['MACHINE_RPM', 'TEMPERATURE_READINGS', 'PRESSURE_DATA'],
    compensationOffered: 100.00, // Costs for 3 items (15) + security (15) = 30. Max FRAND = 30 * 1.2 = 36. 100 is too high.
    userConsentSignature: 'SIG_FACTORY_ABC_VALID',
    thirdPartyDeclarations: ['NOT_DMA_GATEKEEPER']
});
verifyEuDataActCompliance(expensiveRequest);

Implementation Guide for B2B Stakeholders

Proactive compliance with the EU Data Act requires a multi-faceted strategy for B2B entities:

1. Data Inventory and Audit: Identify all connected products and related services that generate data. Catalogue the types of data collected (personal, non-personal, raw, processed) and map data flows.
2. Review of Existing Contracts: Assess current B2B data sharing agreements and licensing terms for alignment with FRAND principles and user rights under the Act. Revise or re-negotiate contracts as necessary.
3. Develop FRAND Terms Policy: Establish an internal policy for determining "reasonable compensation" and setting non-discriminatory access conditions. This should be transparent and cost-based, focusing on actual expenses for making data available.
4. Technical Solutions for Data Access: Invest in or develop robust technical interfaces (e.g., APIs, standardized data formats) to enable seamless, secure, and machine-readable data access for users and authorized third parties. Ensure compliance by design for new products placed on the market from September 12, 2026.
5. Smart Contract Feasibility Study: Evaluate the potential for integrating smart contracts into data sharing workflows, particularly for automating access, usage monitoring, and compensation mechanisms. Develop a strategy for ensuring legal certainty and interoperability.
6. Data Governance and Security Framework: Enhance internal data governance frameworks to ensure compliance with Data Act and GDPR requirements, including robust security measures, access controls, and incident response protocols.
7. Internal Training and Awareness: Educate legal, product development, sales, and IT teams on the implications of the Data Act and the new compliance obligations.
8. Dispute Resolution Preparedness: Familiarize with certified dispute settlement bodies and establish internal procedures for handling data access or compensation disputes.

Conclusion

The EU Data Act is a transformative piece of legislation that will fundamentally reshape how industrial and IoT data is shared and utilized within the European single market. For B2B stakeholders, it presents both significant compliance challenges and considerable opportunities to foster innovation, enhance data-driven services, and unlock new value streams. By proactively addressing data access rights, adhering to FRAND principles, and exploring advanced solutions like smart contracts, businesses can navigate the complexities of this new regulatory landscape, maintain a competitive edge, and contribute to a more open and fair data economy. Compliance is not merely a legal obligation but a strategic imperative for future-proofing B2B operations in the data era.