US software companies built their EU privacy programs the way US counsel build most compliance stacks: once, under deadline, against a rule assumed to hold still. Cookie banners went up. Data processing agreements were repapered. Legitimate-interest assessments were drafted, filed, and rarely reopened. The European Commission's Digital Omnibus proposes to move almost every one of those foundations.1The Digital Omnibus package: two Commission proposals tabled 19 November 2025, on sharply divergent legislative tracks.
What the package has not done is enact any of them. It arrived as two separate proposals, and their fortunes diverged almost at once. The limb amending the AI Act has completed the ordinary legislative procedure. The limb carrying the data-protection reforms had not left committee as of publication, and the Union's two data-protection bodies have asked the co-legislators to reject its central provision outright. The counselling problem is therefore not what the Omnibus says. It is which parts of an existing privacy program rest on a rule that is in force, and which rest on a rule that is merely drafted.
1. When Telemetry Stops Being Personal Data, and for Whom
A US privacy counsel reads a de-identification standard as a property of the data. Satisfy the HIPAA safe harbor, or the conditions attaching to deidentified information under the California regime, and the record leaves scope, for everyone, and stays out. The GDPR has never worked that way. Art. 4(1) GDPR defines personal data by reference to identifiability, and identifiability has always been assessed against the means reasonably likely to be used.2Regulation (EU) 2016/679, the GDPR, with the pinpoints engaged by the Digital Omnibus. Whose means, the enacting terms never said; the recitals point, without distinction, to the controller or another person.
The Court of Justice answered part of that question in the Single Resolution Board appeal, holding that pseudonymized data are not personal data in all cases and for every person, and that whether they are personal data in a recipient's hands falls to be assessed by reference to the means reasonably likely to be used by that recipient. The relevant perspective, the Court added, depends on the circumstances of the processing in each individual case: for the disclosing controller's own duty to inform, identifiability is assessed at the time of collection and from that controller's point of view.3Case C-413/23 P, on when pseudonymized data are personal data, and from whose perspective that is assessed. The Digital Omnibus takes that holding and writes a relative test into the definition itself, so that information identifying an individual in one entity's hands is not necessarily personal data in another's merely because the first entity can perform the identification. It then goes further than the judgment did. A proposed Art. 41a GDPR would empower the Commission to specify, by implementing act, the means and criteria determining whether data resulting from pseudonymization has ceased to be personal data for certain entities.4Proposed Art. 41a GDPR, delegating the pseudonymization boundary to Commission implementing acts.
The EDPB and the EDPS did not receive this as a technical amendment. In their joint opinion they strongly urge the co-legislators not to adopt the change, on the ground that it goes far beyond a targeted or technical amendment of the GDPR and would significantly narrow the concept of personal data; the Supervisor's own framing was that the drafting departs from the Court's case law rather than codifying it. They object separately to settling the scope of Union data-protection law through an implementing act.5EDPB-EDPS Joint Opinion 2/2026, adopted 10 February 2026, urging rejection of the personal-data definition change.
Applied to one dataset held by one controller, a relative test reads as relief, and for a US business processing large volumes of pseudonymized telemetry the relief would be substantial. Applied to a supply chain, it behaves differently. Relativity is not a property the data carries; it is a property of a relationship between a dataset and a holder, and it is evaluated afresh at every hand-off. The same event stream may be personal data for the vendor that holds the mapping table and not for the customer that receives the export, which means the two parties to a single data processing agreement may sit on opposite sides of the statute while performing the same contract. Nor is the status stable in time. An entity that acquires a re-identification capability, whether through an enrichment vendor, an identity graph, or an acquisition, may find that data lawfully treated as non-personal on Monday is personal on Tuesday, with retention schedules, transfer assessments, and breach duties attaching retroactively to a population it never mapped.
A definition of personal data that varies with the holder does not travel with the data. It has to be re-established at every hand-off, by every recipient, on the day that recipient's capabilities change.
The exposure runs in both directions, and neither direction is cost-free. A company that re-scopes its data map in reliance on the proposed definition, and then watches the co-legislators narrow the narrowing, has de-scoped processing that never left scope. A company that ignores the proposal carries a compliance cost the Commission has said it need not carry. Whether the analysis was performed is rarely the difficulty. The difficulty is evidentiary: a relative scoping decision has to be reconstructable months later, across the contract team that negotiated the data processing agreement and the engineering team that added an enrichment step, and that is where the record tends to be thin.
2. The Legitimate-Interest Assessment Already on File
In US practice, training a model on customer data is a contract question before it is a statutory one. The service-provider restrictions of the California regime, the master agreement, and the data processing agreement between them determine what may be done. Under the GDPR it is a lawful-basis question first, and the answer for most US SaaS businesses has been Art. 6(1)(f) GDPR, supported by a legitimate-interest assessment prepared once and stored where such documents are stored.
The Digital Omnibus proposes to put that practice on an express footing. A new Art. 88c GDPR would provide that processing in the context of the development and operation of an AI system or an AI model may be pursued for legitimate interests within the meaning of Art. 6(1)(f) GDPR, where appropriate and except where other Union or national laws explicitly require consent, subject to organizational and technical measures running from data minimization at the stage of source selection and during training and testing through to what the model retains and discloses, and to an unconditional right to object. A companion derogation in Art. 9(2)(k) GDPR would permit the residual processing of special categories of data in the development and operation of such systems, under safeguards.6Proposed Art. 88c and Art. 9(2)(k) GDPR on AI development, and the response of the Board and the Supervisor.
The obvious response is that this is codification, and therefore safe to rely on. The Board and the Supervisor say something more awkward. They accept that legitimate interest may in some cases serve as a basis for developing and deploying AI models, note that the Board had already said so, and conclude that a dedicated provision is unnecessary and that the permissive drafting adds no legal clarification; they also consider that the right to object belongs in Art. 21 GDPR rather than standing alone. On the special-category derogation they are more receptive, accepting that such data cannot always be excluded from a training corpus, while recommending that the qualifiers doing the limiting work migrate from the recitals into the enacting terms, that data collected through prompts at deployment be placed outside the derogation, and that safeguards run across the model lifecycle.
That is an uncomfortable place for a planner. If the Board and the Supervisor are right that the provision changes nothing, a company that waits for it gains nothing. If they are wrong, a company that rebuilds its basis around the draft is relying on text that may not survive committee. Either way the assessment on file is unlikely to be the assessment the provision contemplates: an assessment written for product analytics is not an assessment for model training, and the conditions the proposal attaches, an operative right to object and measures reaching both what the model ingests and what it later retains or emits, appear in very few of the documents drafted before the proposal existed. The special-category point is sharper still for a multi-tenant service. Support tickets and free-text fields carry health data and, occasionally, trade-union membership, without anyone having decided to collect it. A derogation that requires such data to be avoided, then removed, and, where removal would take disproportionate effort, protected from being used to produce outputs or otherwise made available to third parties, sits awkwardly against a model that serves every tenant. Where those roles and their jurisdictional consequences are allocated across a cloud contract is a separate problem, examined in the analysis of jurisdictional complexity in cloud service contracts.
3. One Banner, Two Instruments, and the Definition That Decides Which
The nearest US analogue to what the Omnibus proposes for cookies is the browser-transmitted opt-out signal, which US counsel encounter as an obligation to honor a preference the user expressed somewhere else. The EU rule the reform would displace has a different shape. Art. 5(3) of the ePrivacy Directive governs the storing of, or access to, information on a user's terminal equipment, and because the instrument is a directive rather than a regulation, it governs through twenty-seven national transpositions that do not agree with one another. The standalone ePrivacy Regulation that was to have replaced it was formally withdrawn, with the withdrawal published in October 2025, so the Directive is what remains.7Directive 2002/58/EC, Art. 5(3) and Art. 4, and the withdrawal of the 2017 ePrivacy Regulation proposal.
The Omnibus would remove the processing of personal data on terminal equipment from Art. 5(3) of the ePrivacy Directive and route it into the GDPR, where a new Art. 88a GDPR would carry the consent requirement together with four purposes exempt from it, and would preserve alongside them storing or access based on Union or Member State law under Art. 6 GDPR to safeguard the objectives listed in Art. 23(1) GDPR. The four are transmitting a communication over a network, providing a service the data subject explicitly requested, creating aggregated information about the usage of an online service to measure its audience where the controller of that service does so solely for its own use, and maintaining or restoring the security of a service provided by the controller and requested by the data subject, or of the terminal equipment used to provide such service. Refusal would have to be available in an easy and intelligible manner, by a single-click button or equivalent, and a controller whose request is refused could not ask again for the same purpose for at least six months. A new Art. 88b GDPR would require controllers to let users give or refuse consent, and exercise the right to object under Art. 21(2) GDPR, through automated, machine-readable means, with browser providers other than small and medium enterprises obliged to supply the technical means by which users do so. Art. 4 of the ePrivacy Directive, which carries the security and breach duties of electronic-communications providers, would be repealed outright.8Proposed Art. 88a and Art. 88b GDPR: consent, the four exempt purposes, single-click refusal, the six-month rule, machine-readable signals.
Read as a whole, the reform does not consolidate the rule. It splits it. Art. 5(3) of the ePrivacy Directive survives, but only where no personal data are processed, or where the subscriber or user is not a natural person: the carve-out the proposal inserts requires both conditions before the provision is disapplied. Which instrument governs a given cookie on a natural person's device therefore turns on whether personal data are processed by it, and that is precisely the question the same proposal narrows in Art. 4(1) GDPR and hands to the Commission to refine by implementing act. The Board and the Supervisor strongly support a regulatory answer to consent fatigue, and welcome that oversight of terminal-equipment protection would pass to the supervisory authorities designated under Art. 51 GDPR, yet they identify this split across two instruments as a source of legal uncertainty, and they suggest an exemption for contextual advertising that the proposal does not contain. Nor does the banner disappear. The information duties survive the relocation, and withdrawal must remain as easy as consent, so the surface that carries them survives with them.
For a US business that harmonized its European consent stack on a single banner, the reform also moves only one leg of it. Switzerland is not an EU Member State, and the Digital Omnibus has no effect there. The Swiss terminal-equipment rule does not sit in the DSG at all; it sits in Art. 45c FMG, which permits the processing of data on another person's equipment by telecommunications transmission only for the telecommunications services and their billing, or where users have been informed of the processing and its purpose and told that they may refuse it. Neither instrument is touched by the package.9Swiss law: the DSG and Art. 45c FMG, neither amended by the Digital Omnibus. A consent architecture rebuilt around proposed Art. 88a GDPR would therefore diverge from the Swiss position it was built to satisfy in parallel, a dual-track problem examined for the data-protection regimes themselves in the analysis of GDPR and DSG in clinical data.
4. Ninety-Six Hours, and the Access Request a Controller May Refuse
A US public company already runs its incident clock against a materiality determination and a four-business-day disclosure duty. Adding the GDPR's seventy-two-hour notification duty to that calendar has been a durable source of friction, and the Omnibus proposes to relieve it: the notification threshold in Art. 33 GDPR would rise so that only breaches likely to result in a high risk to individuals require notification, and the deadline would extend from seventy-two to ninety-six hours. A single entry point for incident reporting, to be developed and operated by ENISA, which the proposal instructs it to pilot within eighteen months of entry into force, a figure the tabled text still carries in square brackets, would let one submission serve several regimes.10Proposed amendments to Art. 33 and Art. 12(5) GDPR, and the single reporting entry point. The Board and the Supervisor support both the higher threshold and the longer deadline, and say so in terms.
The relief is smaller than it appears, and the reason is arithmetical rather than legal. A company's incident response does not run on its longest clock; it runs on its shortest. An entity in scope of the NIS2 Directive owes an early warning within twenty-four hours, and a financial-sector entity under the Digital Operational Resilience Act owes its own report on its own timetable. Extending the GDPR duty by a day moves nothing on the critical path if the critical path is set by a twenty-four-hour warning, which is close to the point the Board and the Supervisor themselves make when they recommend that the deadlines be harmonized rather than merely lengthened. The single entry point, meanwhile, does not exist, and will not exist for some time after an adoption that has not happened. An incident-response process rebuilt around a portal that has not been built leaves a gap on the day an incident triggers the duties that are in force.
The proposal's treatment of access requests carries a subtler difficulty. An amended Art. 12(5) GDPR would allow a controller to refuse an access request, or charge for it, where the data subject abuses the rights conferred by the regulation for purposes other than the protection of their personal data, the controller being required to demonstrate that the request is manifestly unfounded or that there are reasonable grounds to believe it excessive. The provision would reach, without naming it, the practice every in-house team recognizes, which is the access request deployed as pre-litigation discovery in an employment dispute. What it does not change is who has to prove it. The burden already sits on the controller under Art. 12(5) GDPR as it stands, and it stays there, in the one class of case where the controller's evidence of the requester's purpose is weakest and where any refusal will be tested by a supervisory authority that has heard the argument before; the proposal's only movement on that point runs the controller's way, since reasonable grounds to believe a request excessive would suffice where the present text requires the excessive character to be demonstrated. Whether the controller's own characterization of the request survives that scrutiny depends on facts about the underlying dispute that sit outside the privacy function altogether.
5. Strategic Considerations
The questions the Omnibus forces are not the ones its simplification framing invites, and they turn less on what the text says than on which text a given decision leans on. A re-scoping of a data map, a rebuilt consent architecture, and a new lawful basis for model training all rest on provisions that had not left committee as of publication; the first two rest, in addition, on the very definition change the Union's data-protection bodies have asked the co-legislators to reject. A redesigned breach playbook rests on un-adopted text as well, though there the Board and the Supervisor support the change rather than oppose it. The default is to keep operating under the law in force, but that default carries a cost, and whether the cost is worth bearing depends on the size of the program and the length of the re-engineering cycle behind it.
Harder is the question of who bears the risk of the definition moving. A data processing agreement negotiated against the definition as it stands allocates controller and processor roles, indemnities, and audit rights on the premise that the data are personal for both parties. If the definition narrows, does the processor's obligation simply fall away, and did anyone in the negotiation intend that it should? Both parties may believe they understand where the boundary sits. Neither may have tested that understanding against a scenario in which the boundary is set, after signature, by a Commission implementing act neither of them will see in draft.
The cookie reform carries a circularity of its own. A consent architecture routed by whether personal data are processed is an architecture whose routing test is the very definition under revision, delegated in part to implementing acts. What follows for a company whose audience-measurement cookie is exempt from consent because the measurement is aggregated and carried out by the controller of that service solely for its own use, when a later implementing act, or a later reading of the relative test, moves the underlying identifiers across the personal-data line? The exemption is drafted against a category, and the category is in motion.
Least visible, and most consequential, is the feedback into US governance. A European deadline that appears to slip drops quietly off a board-level risk register, and a European relief that has not been enacted is easily over-weighted in the plan that replaces it. Whether the disclosure committee has been told that the GDPR reforms are proposals rather than law, whether the risk factors in the annual report still describe a regime the company has privately decided to stop building toward, and whether the directors' and officers' program responds to a foreign regulatory action at all, are questions that live outside the privacy function and are rarely routed to it. Underlying all of them is a timing caveat that a fast-moving file demands: the data track's content and its calendar can both still change, and a plan measured against it should be measured again as it advances. These questions require analysis tied to a company's own data flows, contracts, and product roadmap.