ediverse

Type to search across standards, messages, tools and glossary.

ediverse Explore the platform

Spotlight PEPPOL BIS Billing 3.0 The EU e-invoicing mandate is here — France Sept 2026, Belgium Jan 2026, Germany 2025.

— 01

Foundations

— 02

Standards

— 03

Flagship messages

— 04

Tools

Compliance by design: bake GDPR/AI Act/NIS2 in early

"Compliance by design" is not a slogan. It is an explicit regulatory obligation (GDPR article 25), structuring for EDI architectures touching personal data, AI models, or critical supply chains.

Why by design?

Integrating compliance after design typically costs 5-10x more than upstream, because it requires replacing structuring choices: storage, flow architecture, environment separation, logging. European regulators (CNIL, EDPB, ENISA, AI Office) have aligned their doctrines on the principle that obligations are assessed "at the time of determining the means of processing" and not when a possible inspection occurs.

In 2026, three texts structure European obligations for modern EDI architectures: GDPR (May 2018), AI Act (Regulation 2024/1689, August 2024), NIS2 (Directive 2022/2555, January 2023). None is EDI-specific, but all three apply as soon as personal data is processed, AI components are used, or operations are in an essential sector.

GDPR article 25: data protection by design and by default

GDPR article 25 requires the controller to implement appropriate technical and organisational measures at the time of determining the means of processing and at the time of processing itself. The principles: data minimisation, pseudonymisation, security measures, default configuration limiting access.

For an EDI hub processing partner INVOIC: minimal storage of personal data (archive only what is legally required — DGI: 10 years for accounting invoices in France; other data can be purged earlier), pseudonymisation of data in non-production environments (sandbox, staging), restrict access by default (an operator reads only data strictly necessary to their role), immutable logging of accesses. EDPB Guidelines 4/2019 detail these obligations.

AI Act: risk-based classification

The AI Act (EU Regulation 2024/1689) classifies AI systems in four risk levels: unacceptable (banned), high (strict obligations), limited (transparency), minimal (free). "High risk" classification triggers heavy obligations: risk management system, training data governance, technical documentation, human oversight, robustness and cybersecurity, event logs.

For EDI, typical AI cases are: LLM-based mapping assistant, anomaly detection, automatic error code suggestion, RAG over partner documentation. None of these is "high risk" under Annex III as such — but if AI automatically decides to accept/reject invoices, it could fall under "creditworthiness evaluation or credit scoring" (Annex III §5(b)) which is high risk. To check case by case with a classification analysis published by the AI Office.

The application timeline is progressive: prohibitions effective 2 February 2025, GPAI model obligations 2 August 2025, high-risk obligations 2 August 2026 and 2 August 2027 depending on categories.

NIS2: cybersecurity for essential operators

The NIS2 directive (2022/2555, national transposition due 17 October 2024) imposes reinforced cybersecurity obligations on essential entities (energy, transport, banking, health, drinking water, digital infrastructure) and important entities (waste management, food, manufacturing, digital providers). Threshold criterion: medium and large companies (≥ 50 employees or ≥ 10M€ revenue) operating in covered sectors.

Key obligations: documented cyber risk management, incident management (ENISA notification within 24h for significant incidents), business continuity, supply chain security (including IT and SaaS providers), authentication and encryption policies, training. For an EDI hub serving multiple NIS2 entities, the hub itself becomes a critical provider assessed by its regulated clients.

Four operational principles

  • Data minimisation — each stored field must have a business or legal justification. Test question: if we remove this field, what breaks? If nothing, we are not entitled to store it.
  • Defence in depth — combine transport encryption (TLS), payload encryption (CMS, AS2), at-rest encryption (disk encryption, KMS-backed), dynamic access control (OPA, Zero Trust). No layer is sufficient alone.
  • Immutable auditability — every significant action (payload read, config change, AI execution) must be logged in an append-only store (compacted Kafka topic, S3 object lock). Without this, impossible to prove compliance to a controller.
  • Privacy enhancing technologies — pseudonymisation, anonymisation, synthetic data for test sets, differentially private aggregation for KPIs. Investing early in these tools avoids late refusals.

EDI implications: five architectural decisions

  • Environment separation: never prod data in sandbox/dev. If necessary, systematic pseudonymisation (Synthetic Data Vault or Faker libraries allow generating realistic datasets).
  • Per-flow retention policy: each message type has its own retention duration (10 years accounting invoice, 5 years fiscal ACK audit, 90 days operational logs). Implement with S3 lifecycle policies + Airflow purge jobs.
  • Track every data access: log SQL queries on payloads (Postgres pgaudit), file downloads, admin API calls. Essential to respond to a GDPR Data Subject Access Request or a NIS2 audit.
  • SaaS and AI vendor assessment: each vendor enters the supply chain scope of your regulated NIS2 clients. Prepare a GDPR DPA, an AI Act FRIA if applicable, an SOC 2 Type II attestation or ISO 27001.
  • Incident response plan: NIS2 imposes ENISA notification within 24h for significant incidents. Prepare an escalation runbook, up-to-date contacts, regulatory notification templates.

Further reading

Last updated: May 18, 2026