Innovation Law Insights

Artificial Intelligence

AI Act investigations: How to handle the first information requests

AI Act investigations have begun, with the European Commission using its enforcement powers for the first time to order leading AI developers to detail their practices on cybersecurity, safety and copyright through information requests.

The issue isn’t only for developers as investigations on whichever company uses AI systems will start soon. The way a company answers that first letter is about to become the decisive moment of its AI compliance, because the reply isn’t a documentation exercise but the opening move of a defence.

Enforcement has stopped being theoretical, since the AI Act provisions that make it possible became operational on 2 August 2026.

Why AI Act investigations reach companies that only use AI

The most persistent misunderstanding I encounter is that the AI Act regulates developers and that everybody else can wait for the deferred deadlines to arrive.

The AI Act doesn’t only regulate developers, because it places its own set of obligations on deployers, meaning any company using AI systems in its operations, and those obligations haven’t been postponed. What was deferred concerns parts of the high-risk regime and not the framework as a whole, and certainly not the enforcement powers that started to operate at the beginning of August 2026.

The transparency duties reach a very wide population of organisations, and the position of a company that customises, retrains or rebrands a system is even less comfortable, since that activity can requalify a deployer as a provider with the heavier set of duties that follows. Treating the deployer role as a shield doesn’t work because the duty follows the system all the way to the user.

The reply is already part of the exposure

There’s a feature of the AI Act enforcement framework that most organisations haven’t internalised, and it changes the nature of the exercise entirely, because liability doesn’t begin with the substance of what a company did with the system. Refusing to respond to an information request, answering it badly or obstructing a review is sanctionable in itself, which means that a letter which looks like a request for documents is in fact the opening of a file, and everything produced in response becomes part of it.

This is why answering an information request isn’t a question of merely providing technical specifications to be handled by the IT team. The reply has to be drafted with the reasons behind the request in mind and within a defensive strategy agreed from the outset, because the authority isn’t collecting documents for their own sake, it’s testing a potential challenge, and a response that ignores the potential challenge tends to confirm it.

In my experience this is the moment where the final outcome of a dispute is decided, since everything that follows is built on what you said the first time, and no later clarification ever fully repairs an answer given too quickly.

What privacy investigations already taught us

None of this is unprecedented, because data protection authorities have been running this playbook for years, and companies that have been through a privacy inspection recognise the mechanics immediately. I wrote about how to prepare for privacy dawn raids under the GDPR some time ago, and three of the lessons from that experience transfer directly to AI Act investigations.

The first concerns accountability, since under a regime built on that principle the investigated party has to prove that it did what it was meant to do, which broadens the scope of any investigation well beyond the specific question asked and turns the absence of documentation into evidence in itself rather than into a neutral fact.

The second concerns privilege, because in jurisdictions like Italy legal privilege isn’t a substantial limit to investigations, and internal exchanges between departments, or in some circumstances even with external counsel, can be used to challenge a company’s position, which means that how an organisation writes about its own AI systems internally matters long before anybody asks to see it.

The third, and the one that causes most of the damage in practice, concerns human error, since the recurring source of problems in these files is employees who provide inaccurate information for no better reason than the wish to be helpful and to feel important for a day, and an answer given informally by somebody who doesn’t have the full picture creates a problem that no subsequent legal review can undo.

The procedure that should exist before the letter arrives

The preparation that works is the kind that cannot be improvised once a deadline is running, and it looks very much like the internal procedure that mature organisations already have for data protection inspections, adapted to a different regulator and a different subject matter.

It starts with knowing who the primary contacts are, not only the person responsible for AI governance but also external counsel and a named contact in each office, together with instructions for the people who would physically receive a communication, and with an escalation path that ensures the general counsel and management are informed immediately rather than after somebody has already replied.

It continues with knowing who is entitled to answer on behalf of the company, because an information request that reaches a technical team and gets answered by simply supplying technical details is the single most common way these files go wrong, and the people best placed to explain how a system works are rarely the people best placed to decide what the company should say about it.

It requires knowing which AI systems are actually in operation, including the ones embedded in third-party human resources, customer relationship, security and procurement software that nobody classified as AI when it was purchased, and including the generative tools that individual teams adopted on their own initiative, because an inventory assembled after a request arrives is both incomplete and inconsistent with whatever the company says next.

It requires knowing what you would be able to show today, since the value of documentation is decided by whether it exists at the moment of the request and not by whether it could be reconstructed afterwards.

And it requires training, which is the part that gets skipped, because a procedure that nobody has rehearsed is a document rather than a defence, and the people who will be interviewed need to understand that they should answer questions whose answer they actually know, refer to the internal policies and procedures where they exist, and refrain from offering personal opinions on matters that will later be read as the company’s position.

What comes next

The developers that received the first requests will handle them with counsel in the room from the first hour, and their outcome will turn on questions of substance they have been preparing for years.

The organisations that should be paying attention are the ones that concluded the AI Act was somebody else’s problem, because the enforcement model that begins with a letter is the model every digital regulator uses, and it always starts long before anybody talks about a fine. Waiting was a defensible position while enforcement remained theoretical, and it stopped being one when the first letters went out.

Understanding where an organisation stands usually begins with mapping the AI systems in use, the role the company holds in relation to each of them and the documentation that exists around them, which is a defined exercise and considerably less expensive than assembling the same information inside the deadline of a request.

To ease the understanding of the issue, below are the answers to some FAQ.

What are AI Act investigations?

They’re the enforcement proceedings through which the European Commission, the AI Office and the national authorities verify compliance with the AI Act, and they typically begin with information requests asking operators to detail their practices, produce documentation and explain how their systems work.

Can a company be sanctioned for how it answers an information request?

Yes, because refusing to respond, answering badly or obstructing a review is sanctionable in itself, independently of whether the underlying conduct concerning the AI system turns out to breach the regulation.

Do AI Act investigations concern companies that only use AI systems?

Yes. The AI Act places obligations on deployers, meaning the organisations that use AI systems, and those obligations weren’t postponed, while a company that customises, retrains or rebrands a system may also be requalified as a provider with the heavier duties that follow.

What was actually postponed?

The postponements concern parts of the high-risk regime rather than the general application of the regulation, which took effect on 2 August 2026 together with the enforcement powers of the Commission and of the national authorities.

Is legal privilege a protection during these investigations?

Not to the extent that many companies assume, since in jurisdictions such as Italy privilege isn’t a substantial limit to investigations, and internal communications about the company’s own systems can end up being used to challenge its position.

Who should answer an information request within a company?

The reply should be coordinated by whoever is responsible for the company’s legal position, with technical input rather than technical drafting, because the response is evidence and it has to be consistent with the defensive strategy adopted from the outset.

How should a company prepare for AI Act investigations?

By mapping the AI systems in operation including those embedded in third-party software, identifying the role the company holds for each of them, establishing the internal contacts and the escalation path, verifying that the documentation that would be requested already exists, and training the people who would be involved.

Author: Giulio Coraggio

 

AI criminal liability in Italy: What boards have to know now

AI criminal liability is no longer a question of how much a fine would cost, it’s a question of who signs off on a system and what happens to that person, and to the company, if the system causes harm.

Italy has now answered that question, and the answer travels beyond its borders. On 4 August 2026 the Council of Ministers gave final approval to the two legislative decrees adapting Italian law to the AI Act, completing the delegation contained in Law No. 132/2025. What deserves separate treatment is the part that reaches individuals and companies directly, because it changes both how a deployment decision should be taken and who carries the consequences of taking it.

Two things happened at the same time. A new offence entered the Criminal Code, Article 437-bis, punishing the omission of safety measures in high-risk AI systems, and that offence simultaneously became a trigger for corporate criminal liability, entering the catalogue of predicate offences under Legislative Decree 231/2001 through a dedicated new article devoted to crimes committed with the use of AI systems.

If your organisation operates in Italy, sells into Italy or has an Italian subsidiary, this concerns you, because the exposure follows the conduct and the place where the offence is committed rather than the nationality of the parent company, and Italian corporate criminal proceedings routinely reach entities whose decision makers sit somewhere else entirely.

Why AI criminal liability changes the decision

Administrative fines under the AI Act are serious and they are budgeted for, because a fine is ultimately a cost that the company absorbs, whereas AI criminal liability is faced by a person and no budget line covers it.

That difference reaches the approval stage of every AI project. When the downside was monetary, governance could be weighed against expected benefits and it usually lost the comparison, while now that the downside includes personal exposure for the people who approved the deployment, the question is no longer how much this could cost but whether the person who authorised the system can show what they did before authorising it.

In the incidents I handle, that evidence either exists or it doesn’t, and it’s never created afterwards.

What Article 437-bis punishes

The offence covers whoever omits the technical safety measures required to prevent malfunctions or alterations, or omits human oversight measures, across the design, training, production, placing on the market or professional use of high-risk AI systems.

Liability isn’t triggered by the omission alone, because the provision requires what Italian criminal law calls concrete danger, meaning a real and demonstrable risk to a protected interest in the specific circumstances rather than an abstract possibility that harm might occur.

The penalties then follow the interest at stake, running from one to five years of imprisonment where life or individual safety is exposed and from two to eight years where the danger reaches public safety or the security of the state, while a second limb of the provision deals with outside interference, punishing whoever, remaining external to the system lifecycle, alters its functioning, with two to six years in the base case and three to ten years in the aggravated ones.

Where the omissive conduct is committed with gross negligence the penalty is reduced by between one-third and one-sixth, on the model of Article 590-sexies of the Criminal Code, which governs negligent liability for death or personal injury in healthcare, the intention being to confine criminal relevance to macroscopic departures from diligence in a field that’s changing very quickly and to leave ordinary technical error outside the perimeter.

The placement in the Code says more than the text does, because Article 437-bis sits next to Article 437, which for decades has policed the failure to install equipment designed to prevent workplace accidents, so Italian law has effectively decided that failing to secure an AI system belongs to the same family as failing to install a safety guard on a machine, and anyone who has lived through a workplace safety investigation will know what that comparison implies about how these files tend to be built.

How corporate criminal liability works in Italy

For readers outside Italy, this is where the analysis stops resembling most other European systems, so the mechanics are worth setting out.

Legislative Decree 231/2001 established a regime under which a company is sanctioned directly when a specified offence is committed by its senior managers or its employees in the interest or to the advantage of the company, and only offences included in a defined statutory list, known as predicate offences, can trigger it, which is why adding an offence to that list is a significant legislative act and why what has just happened to AI matters.

Two features deserve attention from anyone used to a different system. The sanction is imposed on the entity itself, in its own proceedings, alongside any case brought against the individuals involved, and the company has a genuine defence rather than mere mitigation where it can show that it had adopted and effectively implemented an organisational, management and control model designed to prevent offences of that kind, overseen by an independent supervisory body. The practical implication is direct, because a model that doesn’t address AI risk cannot function as a defence against an AI predicate offence.

On sanctions, the new provision applies a monetary penalty of between 600 and 1,000 units for Article 437-bis and between 200 and 700 units for the deepfake offence under Article 612-quater introduced by Law 132/2025, and since Italian corporate sanctions are expressed in units rather than in euro, with the court setting the monetary value of each unit within a statutory range according to the financial condition of the entity, the same number of units produces very different amounts for a small supplier and for a multinational, reaching well above EUR1 million at the upper end.

Where the legislator positioned the offence tells you more than the numbers do, because the explanatory report accompanying the decree places it in the high band of the catalogue and adopts as its express benchmark the predicate offence covering manslaughter and personal injury caused by breaches of workplace safety rules. This means AI safety failures have been ranked, quite deliberately, alongside industrial safety failures.

Interdictive sanctions also apply and in practice they hurt considerably more than the money, since they include the suspension or revocation of authorisations, the prohibition on contracting with the public administration, the exclusion from grants and financing and the prohibition on advertising goods or services. Interdiction from carrying on the business activity was left out on proportionality grounds, which is the one piece of good news in the package.

Why deployers are inside the perimeter, not outside it

This is the point that most companies get wrong when they read the headline.

The conduct covered by Article 437-bis runs across design, training, production, placing on the market and professional use, and that list isn’t accidental because it tracks the value chain of the EU AI Act from provider through to deployer and distributor, with the consequence that AI criminal liability, and the corporate exposure that follows from it, reaches every company that professionally uses high-risk AI systems developed by somebody else.

Most organisations I speak to assume that criminal exposure for AI belongs to whoever built the model, which is not the case, because if you deploy a high-risk system in your operations the duty to maintain safety measures and human oversight is yours and remains yours for as long as the system runs, and buying that system from a reputable vendor moves nothing at all.

One consequence deserves attention on the procurement side, since if your exposure depends on measures that only the provider can implement and on information that only the provider holds, then your contracts need to secure both, and most AI supply agreements signed in the last two years do neither.

What changes when the system acts on its own

A recommendation engine proposes, whereas an agent books, negotiates, executes and decides, increasingly without a human approving each step.

Read Article 437-bis with that shift in mind and the exposure becomes clearer, because the offence is built around two elements that agents complicate, the first being the adequacy of the technical measures preventing malfunction and the second being human oversight, which the provision treats as an autonomous duty whose omission is punishable in itself, so that an agent operating with wide autonomy and no meaningful oversight point is, in the terms of this provision, the paradigm case.

The investigative consequence follows naturally, because the chain between a management decision and a harmful outcome becomes longer and more autonomous, and the question of who authorised what stops being an organisational detail and becomes the centre of the case. If an agent takes an action creating concrete danger, the first requests will concern who decided to deploy it, what testing was performed on its impact, what limits constrained what it could do, and who was monitoring it when the situation deteriorated.

I advise a growing number of organisations that are introducing agents into their operations and in many of them none of those four questions has a documented answer, because systems reach production without prior impact testing, without guardrails and without any governance model capable of monitoring how they behave over time, which under a regime of administrative fines was a commercial risk and under a regime of AI criminal liability is a different order of decision, usually one that nobody in the organisation has consciously taken.

The interest or advantage test, and where it points

Corporate liability requires that the offence was committed in the interest or to the advantage of the company, and that connecting factor, which prosecutors have to establish, is what links an individual’s conduct to the entity.

On this particular offence the advantage is easy to identify and that’s precisely the problem, because it consists of saving on safety measures, meaning the controls not implemented, the testing not performed, the oversight function not staffed and the monitoring never built.

The structure is uncomfortable, because the same organisational failure risks being counted twice, once in the conduct itself and once again in the organisational fault that founds corporate liability, and Italian commentators have flagged the point alongside a textual overlap in the first paragraph where public safety appears in both the base and the aggravated bands, neither of which was resolved at the parliamentary stage and both of which will be argued.

For a board the practical reading is simpler, since any decision to defer AI safety spending now produces a documentary trail pointing directly at the advantage element of a corporate criminal case.

One complication worth keeping in mind

The offence attaches to high-risk AI systems and the European framework for high-risk systems has just moved, because the Digital Omnibus, Regulation (EU) 2026/1744 of 8 July 2026 published on 24 July, postpones the application of the high-risk provisions while leaving the rest of the AI Act in place.

The tempting conclusion is that there is time, but the safer reading is that the classification exercise cannot wait, because a company that hasn’t established which of its systems are high-risk cannot know which of them sit inside Article 437-bis and won’t be able to show, later on, that it ever looked.

What to put in place

None of the protective measures are exotic and most of them make the AI project work better in any event.

Map the AI systems in use and classify them, since inventories are usually the missing piece, particularly for AI embedded in third-party HR, CRM, security and procurement software and for generative tools that staff adopted on their own initiative.

Test the impact before the system goes live and keep the assessment, covering what the system can do, what can go wrong and who could be harmed, because the value of that document lies not in the analysis itself but in the proof that the analysis happened.

Build the human oversight function and give it both a name and the authority to stop the system, since the provision treats missing oversight as punishable conduct in its own right, which makes this the single measure with the clearest link to the offence.

Set the boundary between autonomy and authorisation in writing, defining what an agent may do alone and what requires a human decision, because systems inherit the limits that somebody defined for them and where nobody defined any, the limits are whatever the model happens to produce.

Fix the supply chain contracts on security measures, oversight support, incident information, audit rights and cooperation in a proceeding, because your exposure depends on things that your provider controls.

Update the compliance model that operates as a defence, which for groups with Italian operations means revisiting the local organisational model rather than the global policy suite, since the defence depends on the Italian document and on evidence that it was actually implemented and supervised.

Organisations that want to understand where they stand on AI criminal liability usually start with an assessment of the AI systems in use and of the governance around them, which is a defined exercise with a defined scope and costs a fraction of what it costs to reconstruct the same information under pressure.

Author: Giulio Coraggio

 

Data Protection and Cybersecurity

Data Act access by design: What changes for connected products from 12 September 2026

The Data Act access by design obligation becomes applicable on 12 September 2026 to connected products and related services placed on the market after that date.

It requires manufacturers to build their products so that users can reach the data by default rather than on request, which raises questions of product architecture, of coordination with the GDPR where the data concerns people other than the user, and of how far trade secrets can legitimately limit access.

The shift is easier to grasp if you compare it with what applied until now, because the question that decides whether a connected product complies is no longer whether the manufacturer can extract the data when somebody asks for it, but whether the user can reach that data without having to ask at all. The AI Act Regulation itself, EU Regulation 2023/2854, has been applicable since 12 September 2025 so what changes now is not the existence of the obligation but the set of products that have to be built around it.

What Data Act access by design actually requires

Article 3(1) requires connected products and related services to be designed and manufactured so that product data and related service data, together with the metadata necessary to interpret and use them, are by default easily, securely and free of charge accessible to the user, in a comprehensive, structured, commonly used and machine-readable format and, where relevant and technically feasible, directly accessible.

Because every element of Data Act access by design carries a design consequence, accessibility has to be the default state rather than something activated on request as it was until now. The format has to be machine-readable rather than a report a human can look at, and the metadata that makes the data intelligible travels with the data, since a stream of values that nobody can interpret satisfies nothing.

The perimeter is broad and reaches sectors that don’t usually think of themselves as data businesses, covering vehicles, industrial and agricultural machinery, IoT devices, monitoring equipment and smart home systems, a scope that the European Commission had already outlined in its guidance on connected devices. What falls inside is the raw and pre-processed data readily available on the product, and not, as a general rule, information that has been further processed or inferred through operations producing significantly enriched data, which is where a good part of the manufacturers’ commercial value tends to sit.

Why this is an engineering problem before it’s a legal one

For the products already on the market before September 2025, being able to extract data following a request was enough. For the new ones it is not, because accessibility has to be built into the architecture of the product or the service, through interfaces, applications, portals, export functions or APIs.

Data Act access by design is a different order of requirement. A compliance function can write a procedure for handling access requests in a matter of weeks, whereas building an access mechanism into a product means touching the design phase, the firmware, the connectivity architecture and often the supplier contracts governing the components that generate the data in the first place. This change is crucial. Companies that treated the Data Act as a legal project rather than a product project will discover the difference at the moment the first user asks for something the product was never built to give.

The point where the Data Act meets the GDPR, and where it stops

This is the part that generates most of the questions I receive, and where getting the analysis wrong creates exposure on both sides.

Data generated by connected products frequently includes personal data. Where the user and the data subject are the same person, the Data Act and the GDPR operate in a complementary way and the analysis is relatively straightforward. The difficulty arises when the data concerns individuals other than the user, which happens constantly in practice, as in the case of the employee driving a company vehicle, or of several people using the same device in a household.

In those situations the Data Act does not in itself provide a legal basis for disclosing personal data to the user. A legal basis under Article 6 GDPR has to be identified, and where special categories of data are involved, one of the derogations under Article 9 has to apply before the disclosure takes place rather than after it, a tension between connected devices and data protection and that the Data Act has made considerably more concrete.

The consequence is that Data Act access by design and data protection by design and by default have to be engineered together, because making data technically accessible isn’t the same as making it indiscriminately available. Systems have to be able to identify and authenticate the user, to delimit the data that user may legitimately reach, and to protect the data referable to third parties, which in a shared vehicle or a shared device means separating streams that were never designed to be separated.

Trade secrets are a defence, but not a general one

A similar balancing exercise applies to cybersecurity and trade secrets, and here I see the opposite error, namely the assumption that commercial sensitivity is a way out.

The Data Act doesn’t allow a manufacturer to invoke its knowhow in general terms to avoid sharing, and a defence built on that assumption tends to collapse under scrutiny. What the Regulation does provide is a set of specific safeguards and, in defined circumstances, the possibility of limiting or refusing access. The distinction matters enormously in practice, because the first approach produces a dispute the manufacturer is likely to lose, while the second produces a documented position that can be defended.

Where Data Act access by design will produce disputes

The sectors that will feel this first are the ones where somebody else already wants the data and has the commercial incentive to fight for it.

Automotive is the clearest case, since vehicles generate more data than any other consumer connected product, and there’s an established chain of parties that want access to that data, from insurers to independent repairers to fleet operators. Access to vehicle data has until now been controlled by manufacturers in a way that protected their aftermarket, and that control is precisely what the Data Act unsettles, a dynamic.

Industrial and agricultural machinery follows closely, and it’s the field where the tension between access and trade secrets is sharpest, because operating and maintenance data is commercially valuable to the manufacturer and equally valuable to the operator. It’s also, and this is worth noting for anyone planning the next 12 months, the same population of companies that the Cyber Resilience Act reaches which means two sets of design obligations landing on the same engineering department in the same period.

Where the connected product embeds an AI system, a further layer applies, since the obligations of the AI Act and, in Italy sit alongside the access duties considered here.

Healthcare and medical devices raise the GDPR question in its most acute form, since almost every data point is a special category of data and the Article 9 analysis is the rule rather than the exception.

And then there’s the category of companies that will be caught without knowing it, which is the consumer electronics and smart home sector, where a large number of manufacturers don’t perceive themselves as producers of connected products at all.

What to do now

The exercise that cannot be postponed is classification, meaning establishing which products and related services fall within the perimeter, which of them will be placed on the market after 12 September 2026, and which data they generate that qualifies as readily available raw or pre-processed data.

Alongside it, the access architecture has to be defined rather than assumed, which means deciding through which interface the user will reach the data, in which format, with which authentication mechanism and with which filtering of third-party data, and then verifying that the answer is technically achievable within the product roadmap rather than aspirationally described in a policy.

The third piece concerns contracts, because the data covered by the obligation is frequently generated by components supplied by third parties, and a manufacturer whose access obligation depends on a supplier who hasn’t undertaken to support it is a manufacturer with an exposure it hasn’t priced.

Companies that want to understand where they stand on Data Act access by design usually start by mapping products, data and access mechanisms together, which is a limited exercise with a defined scope and considerably cheaper than discovering the gap when a user, a competitor or an authority points at it.

Below are some FAQ that might help to better understand the obligations under the Data Act.

What is Data Act access by design?

It’s the obligation under Article 3(1) of the Data Act to design and manufacture connected products and related services so that product and related service data, together with the metadata needed to interpret them, are by default easily, securely and free of charge accessible to the user in a structured, commonly used and machine-readable format, and directly accessible where relevant and technically feasible.

When does it apply?

The Data Act has been applicable since 12 September 2025, and the access by design obligation applies to connected products and related services placed on the market after 12 September 2026.

Which products are covered?

The obligation reaches a broad range of connected products, including vehicles, industrial and agricultural machinery, IoT devices, monitoring equipment and smart home systems, along with the services related to them.

Which data is covered?

Readily available raw and pre-processed data generated by the product or the related service, along with the metadata necessary to interpret and use them. Information that has been further processed or inferred through operations producing significantly enriched data generally falls outside the obligation.

Does the Data Act allow a manufacturer to disclose personal data of people other than the user?

No. Where the data concerns individuals other than the user, the Data Act does not in itself constitute a legal basis for the disclosure, and a legal basis under Article 6 GDPR has to be identified, with the derogations under Article 9 applying where special categories of data are involved.

Can a manufacturer refuse access on the basis of trade secrets?

Not on a general invocation of knowhow. The Regulation provides specific safeguards and, in defined circumstances, the possibility of limiting or refusing access, which requires a documented and specific position rather than a generic objection.

What should a manufacturer do first?

Classify the products and services within the perimeter, identify which data they generate that falls within the obligation, define the access architecture together with authentication and filtering of third-party data, and verify that supply contracts support the obligations that depend on components provided by others.

Author: Giulio Coraggio

 

Cyber Resilience Act guidance: Which products, which obligations, from when

On 27 July 2026, the European Commission approved the content of its guidance on the Cyber Resilience Act, which is the most detailed interpretive document published to date on Regulation (EU) 2024/2847. It’s formally non-binding, although it sets out the interpretation that market surveillance authorities, notifying authorities and notified bodies are expected to apply across the EU.

Two documents merit consultation, the Communication C(2026) 5252 and the Annex containing the guidance itself, both available on the Commission’s announcement page.

The outline below follows the scope, the obligations and the timing of the CRA as the guidance addresses them.

1) Which products does the CRA apply to?

Under Article 2(1), the Regulation applies to a product with digital elements whose intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network.

Two clarifications introduced by the guidance have immediate practical relevance:

• A data connection presupposes the transmission of digitally encoded information, deliberately generated by a sender according to a defined scheme and capable of being decoded as information at the destination. The mere switching of an output on and off doesn’t constitute a data connection.
• Placing on the market presupposes supply in the course of a commercial activity, a notion that the guidance develops at length in relation to open-source software.

Software and the place of execution

The distinction carries particular weight for the gaming and gambling sectors, since a downloadable game client constitutes a product with digital elements, whereas a title played exclusively through a browser doesn’t fall within the scope of the Regulation on that basis alone.

A further rule governs the moment of placing on the market for standalone software. Once a given version is first supplied for distribution or use on the EU market, all copies of that version are considered placed on the market at that same moment, irrespective of the date on which each individual user subsequently downloads it. A version supplied on 1 January is placed on the market on that date both for the customer who acquires it immediately and for the customer who acquires it several weeks later.

Variants of the same software that differ in included components, configurations or enabled functionalities, such as builds for different operating systems or bundles with differing feature sets, are treated instead as distinct products.

Hardware and software may constitute a single product

The channel through which software is delivered to the user isn’t decisive. Where software is necessary to operate, configure, control or use hardware in accordance with its intended purpose, the two elements together constitute a single product with digital elements, even where the software is obtained separately through an application store or a download link after the hardware has been placed on the market. Both elements are consequently placed on the market at the same point in time.

The guidance illustrates the principle through a network printer that cannot fulfil its intended purpose without its drivers, and through a fitness wearable whose measurements can be displayed and configured only by means of the manufacturer’s companion application. The same reasoning governs console peripherals, virtual reality headsets and connected devices supplied with dedicated configuration utilities.

Cloud services: When remote processing forms part of the product

Remote data processing solutions fall within the perimeter of the product with digital elements. Their identification rests on three cumulative questions:

• Does the data processing take place at a distance, whether on public cloud infrastructure, on a private cloud or on servers located on the manufacturer’s own premises?
• Would the absence of that data processing prevent the product from performing one of its functions, this notion being broader than the core functionality and the intended purpose?
• Has the software been designed and developed by the manufacturer, or under its responsibility, meaning that it has been built solely by or on behalf of the manufacturer on the basis of designs and specifications provided by it?

Where all three questions are answered affirmatively, the remote component forms part of the product and must be addressed in the risk assessment, in the technical documentation and in the conformity assessment. Software deployed by the manufacturer on third-party Infrastructure as a Service or Platform as a Service offerings will ordinarily satisfy the third condition. A third-party Software as a Service application integrated into the product will not, and will be treated as a third-party component subject to due diligence and to product-level mitigation measures.

Two boundaries limit that perimeter:

• Only the software modules responsible for the functionality of the product, together with the interfaces those modules use with external services, qualify as remote data processing solutions. Back-end systems with which the product does not directly interact remain external dependencies to be assessed and mitigated at product level, without forming components of the product itself.
• Communication infrastructure, meaning cellular networks, routers, ethernet cabling and wireless signals, constitutes an enabler of connectivity and not remote data processing, and no due diligence obligation arises towards the network provider.

Free and open-source software: Two questions in sequence

Software qualifies as free and open-source software only where two conditions are satisfied cumulatively:

• The software is made available under a licence granting the full set of rights referred to in Article 3(48).
• Its source code is openly and publicly shared.

Software distributed under an open-source licence whose source code is disclosed only to paying customers or to a restricted group of users does not qualify as FOSS for the purposes of the Regulation.

The assessment then proceeds in two stages:

Stage one: Is the software under the responsibility of a given person?

Responsibility rests with the natural or legal persons who publish the software and exercise primary control over its development, releases and distribution decisions, generally described as maintainers. Persons who contribute source code without controlling releases, roadmaps or governance are contributors and remain outside the scope of the Regulation. The existence of technical permissions such as commit access isn’t sufficient to establish responsibility.

Stage two: Is the software monetised?

The guidance addresses the principal scenarios as follows.

The Commission expressly neutralises two circumstances that are frequently misunderstood:

• The manner in which development has been financed has no bearing on the commercial character of the supply, so that grants, sponsorships and paid feature development don’t convert a project into a product placed on the market.
• A nonprofit entity established in such a way that all earnings after costs are used to achieve nonprofit objectives does not place its FOSS on the market, even where the software is directly monetised.

Where FOSS is published without being placed on the market, the legal person publishing it may qualify as an open-source software steward under Article 3(14) and become subject to the more limited set of obligations laid down in Article 24. A single entity may hold both roles simultaneously in respect of different projects, and an entity publishing both a free community edition and a paid enterprise edition of the same software will be the steward of the former and the manufacturer of the latter. The reporting obligations of stewards are calibrated to the support actually provided, in accordance with Article 24(3).

Categories falling outside the scope of the Regulation

Three categories deserve attention:

1. Spare parts intended to replace identical components and manufactured to the same specifications are exempt under Article 2(6). Identity is assessed by reference to the functional role of the component and to those characteristics that are relevant to cybersecurity, such as cryptographic mechanisms, protocols and access control features.
2. Automotive components designed and constructed exclusively for integration into vehicles covered by Regulation (EU) 2019/2144 or Regulation (EU) No 168/2013 fall outside the scope, provided that the exclusivity of their destination is objectively verifiable.
3. Products governed by the other instruments listed in Article 2(2) are likewise excluded.

The exemption for spare parts carries an evidentiary condition that manufacturers should anticipate. The maintenance or repair purpose must be apparent from the context of the supply, whether through identification of the product or product family in the order or commercial offer, or through supply via after-sales or service channels, and supporting evidence must be kept available for market surveillance authorities. The same item offered through general retail or through online channels open to the public will not benefit from the exemption.

2) What are the obligations under the CRA guidance?

The obligations can be organised into six blocks, all of which apply cumulatively.

2.1 Cybersecurity risk assessment

The risk assessment required by Article 13(2) constitutes the foundation of the entire compliance architecture, since it determines which of the essential requirements set out in Part I of Annex I apply to the product and how those requirements are to be implemented.

Three principles govern its outcome:

1. The internal risk tolerance of the manufacturer, its commercial strategy and considerations of cost carry no weight in determining whether identified risks have been sufficiently addressed.
2. The Regulation doesn’t permit the transfer of cybersecurity risk or responsibility to users or third parties to compensate for shortcomings in product design.
3. Where the assessment identifies risks that cannot be adequately treated, compliance may require changes to the design, to the functionality or to the intended purpose of the product.

Residual risk is recognised as an inherent outcome of any risk treatment process, since cybersecurity risks cannot be entirely eliminated. It cannot, however, be accepted at the discretion of the manufacturer, and a product may be placed on the market only where residual risks have been sufficiently addressed through the implementation of the essential requirements.

2.2 Essential requirements, due diligence and technical constraints

Part I of Annex I governs product security and Part II governs vulnerability handling. Components sourced from third parties attract the due diligence obligation laid down in Article 13(5), which requires the manufacturer to:

• determine what the product needs from each component to meet its cybersecurity objectives; and
• verify, in a risk-based manner, that the component satisfies those needs, whether through technical specifications, security documentation, conformity or assurance documentation, or testing.

External elements outside the manufacturer’s control must be addressed through product-level measures. The guidance refers to:

• cryptographic authentication of remote commands;
• verification of the integrity of configuration changes;
• generation of security-relevant logs;
• assurance that the unavailability of an external service doesn’t cause the product to enter an insecure state.

Complex systems receive proportionate treatment, which doesn’t amount to an exemption. Where an essential requirement cannot be fulfilled because the intended purpose of the product requires interoperability with existing dependencies or compliance with mandated interoperability requirements, the manufacturer is expected to identify and document the constraint, to assess the associated risks and to implement alternative or compensatory mitigation measures. Where the product is technically capable of supporting both a secure protocol and a legacy protocol, the secure protocol is to be implemented and enabled by default. The constraint must be reassessed periodically, and the product updated once the constraint can be lifted or reduced.

2.3 Conformity assessment and the notion of core functionality

To determine the applicable conformity assessment regime, a product may have only one core functionality, corresponding to its main features and technical capabilities, without which the product wouldn’t be able to meet its intended purpose.

Functions ancillary to the core functionality leave the classification unaffected, so that a smartphone integrating an operating system doesn’t acquire the core functionality of an operating system, and security orchestration, automation and response software whose capabilities substantially exceed those of a security information and event management system is generally not classified as such a system. The guidance states expressly that a manufacturer cannot misrepresent the core functionality of its product to escape a more stringent regime, and identifies inconsistencies between promotional materials, instructions for use and technical documentation as the indicator that authorities will examine.

Three further points are relevant:

1. The application of a harmonised standard covering the core functionality permits recourse to the internal control procedure, although the presumption of conformity extends only to the risks actually covered by that standard. Ancillary functionalities falling outside its scope benefit from no presumption, and the additional measures adopted in respect of them require separate documentation.
2. Modules also made available on the market separately, whether through separate purchase, licensing or subscription, constitute standalone products classified on the basis of their own respective core functionalities.
3. Where variants of a product share the same architecture, security-relevant design and intended purpose, and face the same cybersecurity risks, a single risk assessment, a single set of technical documentation, a single conformity assessment and a single EU declaration of conformity may cover the entire family, provided that the declaration clearly identifies the variants concerned.

2.4 Support period

The minimum period of five years operates as a safeguard and not as a default, since Article 13(8) requires the support period to reflect the period during which the product is expected to be in use. Products reasonably expected to remain in use for longer than five years should accordingly be given correspondingly longer support periods. The end date of the support period must be indicated to the purchaser at the time of purchase, specifying at least the month and the year.

Article 13(10) introduces a measure of flexibility for iteratively developed software, permitting the manufacturer to address and remediate vulnerabilities only in the version last placed on the market, provided that users of earlier versions can upgrade free of charge and without incurring additional costs. The guidance interprets the notion of additional costs restrictively. Personnel time, routine testing, configuration adjustments and upgrades of underlying dependencies constitute reasonable operational effort inherent in software maintenance. Mandatory purchases of new hardware, infrastructure replacement and fundamental changes to the operating environment fall within the notion and preclude reliance on the provision.

2.5 Vulnerability handling and upstream obligations

The obligations under Part II of Annex I comprise policies and procedures for handling vulnerabilities reported from internal or external sources, the provision of security updates, a coordinated vulnerability disclosure policy and the application of effective and regular tests and reviews throughout the support period. The requirement of regularity doesn’t entail the mechanical repetition of an unchanged test campaign at fixed intervals. It requires the periodic review of whether newly identified threats or newly discovered vulnerabilities call for the existing tests to be updated, followed by the execution of the tests so identified.

Products must be made available on the market without known exploitable vulnerabilities. A vulnerability is to be regarded as known where it’s listed in the European vulnerability database or in other prominent vulnerability databases, where it has been disclosed to the manufacturer through coordinated disclosure by a security researcher, where it has emerged from the manufacturer’s own internal testing and analysis, or where it has been publicly and prominently reported by reliable media outlets. A vulnerability is exploitable where it has the potential to be effectively used by an adversary under practical operational conditions, as opposed to theoretical or laboratory conditions.

Reporting a vulnerability does not amount to its confirmation. The manufacturer is required to investigate the report, to verify its veracity and its applicability to the specific product, and thereafter to determine, on the basis of the cybersecurity risk assessment, whether the product may be securely placed on the market or whether the vulnerability must first be remediated. The guidance accepts that postponing a release carries its own risks, particularly where the release also remediates other exploitable vulnerabilities or is necessary for the continued operation of critical systems.

Vulnerabilities identified in integrated components must be reported to the person or entity manufacturing or maintaining the component, in respect of the version integrated and in accordance with any established disclosure channels. Any security fix developed by the manufacturer must be shared upstream in a machine-readable and verifiable format compatible with the licence of the component. Manufacturers are encouraged to consult publicly accessible vulnerability databases, project-specific advisories and issue trackers before reporting, to avoid duplicate submissions, and are relieved of the obligation where the maintainer is already aware of the vulnerability or where the component no longer has a maintainer.

2.6 Reporting to ENISA and the CSIRT

Actively exploited vulnerabilities and severe incidents having an impact on the security of the product must be notified simultaneously to ENISA and to the CSIRT designated as coordinator, in accordance with the following sequence.

A vulnerability affecting an integrated third-party component is subject to mandatory notification only where it is actually being exploited in the manufacturer’s product. Where the vulnerable code isn’t reachable, or where the vulnerability hasn’t been exploited in that product, the mandatory reporting obligation doesn’t arise, although voluntary reporting under Article 15 remains available and the vulnerability handling obligations continue to apply in full.

The moment from which the deadlines run is defined by reference to awareness. The manufacturer is regarded as having become aware when, following an initial assessment conducted promptly upon detection of a suspicious event or upon receiving a report from a third party, it holds a reasonable degree of certainty that a vulnerability contained in its product is being actively exploited or that a severe incident has compromised the security of that product. Affected users must also be informed under Article 14(8), on a risk-based and proportionate basis. The guidance confirms that disclosure may be limited to the users or customers concerned where the product is deployed in sensitive or essential environments and where public disclosure of technical details could itself facilitate further exploitation.

3) When do the obligations apply?

Four points relating to the temporal application of the Regulation deserve attention.

The reporting obligation does not operate retroactively. Active exploitation of which the manufacturer had already become aware before 11 September 2026 falls outside the obligation. Where the manufacturer was aware of a vulnerability before that date without being aware of any active exploitation, and exploitation subsequently occurs or comes to its attention after that date, the vulnerability becomes subject to the reporting obligation. The obligation covers products placed on the market before 11 December 2027 and continues to apply after the expiry of the support period.

Products designed before the date of application do not require redesign. Units manufactured in accordance with a type or model designed before December 2027 may be placed on the market, provided that a current cybersecurity risk assessment demonstrates that the existing security measures address the identified risks. The manufacturer isn’t required to recreate historical design or test documentation, since doing so wouldn’t contribute to the security of the product, but remains subject to the conformity assessment procedure, the drawing up of the EU declaration of conformity, the affixing of the CE marking and the vulnerability handling obligations.

A substantial modification results in a new placing on the market. A modification qualifies as substantial where it alters the level of cybersecurity risk in a manner that the manufacturer had not considered in its risk assessment, or where it modifies the intended purpose for which the product has been assessed. The scale of the change is not determinative, since the introduction of a persistent login feature storing authentication tokens locally has been identified as a substantial modification, whereas the activation of functionalities already foreseen and assessed in the original design has not. Security updates generally fall outside the notion, since their purpose is to reduce risk, unless they alter the intended purpose or introduce new dependencies, as occurs where local encryption functionality is replaced by a remote encryption service operated by the manufacturer.

The assessment may usefully be structured around four questions drawn from the guidance:

1. Does the update introduce new threat vectors?
2. Does it enable new attack scenarios?
3. Does it change the likelihood of previously identified attack scenarios?
4. Does it change their potential impact?

A negative answer to all four indicates that the modification is unlikely to be substantial, provided that the assumptions and mitigation measures relied upon in the risk assessment remain valid.

The consequences depend on the identity of the person carrying out the modification. An importer, a distributor or any other natural or legal person who substantially modifies a product already placed on the market and makes it available becomes its manufacturer, in respect of the modified part alone where the modification doesn’t affect the cybersecurity of the product as a whole, and in respect of the entire product where it does. The assembly of components into a new product does not constitute a modification at all, since the integrator places a new product on the market and is its manufacturer for all purposes. Where the original manufacturer carries out the modification, documentation and test results relating to unaffected parts may be reused, and any third-party assessment focuses on the parts actually modified.

One further consequence is frequently assumed to operate otherwise. A substantial modification does not automatically reset or extend the support period. The relevant question is whether the modification affects the factors that originally determined the expected use time of the product. A software update adding new operating modes to a robot vacuum cleaner leaves the physical durability of the hardware untouched, so that the original support period continues to run. The replacement of the embedded computing platform of a programmable logic controller with components designed for a significantly longer operational lifetime does affect those factors and requires the support period to be recalculated.

Existing certificates provide a transitional benefit of limited scope. An EU-type examination certificate issued under the delegated act supplementing the Radio Equipment Directive or under the Machinery Regulation dispenses the manufacturer from reassessing or re-demonstrating compliance, although only in respect of the cybersecurity risks actually covered by that certificate and only until 11 June 2028, even where the validity of the certificate extends beyond that date under the legislation on the basis of which it was issued. Risks identified through the CRA risk assessment beyond that perimeter, including those relating to vulnerability handling processes, data minimisation and reduction of the attack surface, are the responsibility of the manufacturer.

Author: Giulio Coraggio

 

Fintech and Digital Assets

EDPB Guidelines 02/2025 on blockchain and GDPR: version 2.0 confirms a strict privacy approach

On 7 July 2026, the European Data Protection Board (EDPB) adopted the final version (version 2.0) of the Guidelines 02/2025 on the processing of personal data through blockchain technologies (the Guidelines), following the public consultation that closed on 9 June 2025.

The first version – adopted on 8 April 2025 and already the subject of a previous contribution of ours – addressed the complex relationship between the structural features of distributed ledger technology (DLT) (decentralisation, immutability of records, global distribution of nodes) and the GDPR principles, first and foremost data minimisation, storage limitation and the effective exercise of data subjects’ rights.

The overall message emerging from a comparison of the two versions is clear. Despite the strong criticism raised by players in the decentralised industry during the consultation, the EDPB has substantially confirmed its original framework, confining itself to terminological clarifications and targeted additions.

A framework substantially confirmed

A comparative reading of the two texts shows that none of the passages that had raised the greatest concerns among operators has been amended in substance.

In particular:

• The preference for permissioned blockchains remains in place (that is, blockchains in which an authority – a single entity or a group of entities – determines who may read, write or create blocks): organisations should favour permissioned architectures, which offer a clearer allocation of responsibilities, and should explore different governance alternatives only where there are justified and documented reasons, in which case they should question the very appropriateness of resorting to blockchain technology.
• The analysis of the roles of nodes is confirmed in full: while nodes with limited decision-making power may not qualify as controllers, the nodes of public permissionless blockchains (open to participation by anyone on an equal footing, such as bitcoin and ethereum) may qualify as controllers or joint controllers where they exercise decisive influence over the determination of the purposes and essential means of the processing of personal data, together with the related invitation – likewise unchanged – to set up consortia or other legal entities among the nodes.
• The preliminary assessment framework required of controllers (necessity of the blockchain, type of architecture, technical and organisational measures, on-chain or off-chain placement of the data), the central role of the data protection impact assessment (DPIA) under Article 35 GDPR and the 16 recommendations in Annex A, which have been subject only to drafting refinements, all remain unchanged.
• The position that is perhaps the most debated in the entire document survives the consultation: where erasure of the data has not been provided for from the design stage (by design), compliance with the storage limitation principle may require the erasure of the entire blockchain, which is substantially incompatible with the nature of permissionless blockchains that, by their very structure, cannot be forced to delete the distributed ledger.

The Guidelines themselves point, alongside this last statement of principle, to a more realistic way out. Where the combination of on-chain and off-chain data has been designed by design with compliance in mind, storage limitation can be satisfied by preventing the future identifiability of the data subject by erasing the off-chain elements alone (keys, salt, witness), so that the residual transaction on the chain – by then devoid of any semantic value – survives for the sole purpose of preserving the integrity of the ledger. In other words, at the end of the retention period the data must be either erased or anonymised: and it’s precisely anonymisation that represents the concretely viable route for operators. This point must be read together with Guidelines 02/2026 on anonymisation, adopted by the EDPB at the same plenary of 7 July 2026 (and open to public consultation until 30 October 2026), which update WP29 Opinion 05/2014 in light of the most recent case law of the Court of Justice (Breyer, C-582/14; EDPS v SRB, C-413/23 P).

Taking up the relative and contextual approach affirmed by the court, the new guidelines clarify that data may be regarded as anonymous where the likelihood of identifying the data subject, by means reasonably likely to be used by the relevant entities, is insignificant, and they articulate the test around the three criteria of no record isolation, no linkage and no inference. This yields a practical indication for those designing processing operations on permissionless blockchains: to structure the on-chain/off-chain architecture from the outset so that, once the retention period has elapsed, erasing the off-chain elements renders the data remaining on the chain effectively anonymous under the new framework, with the result that it falls outside the scope of the GDPR and the erasure obligations themselves cease to apply – thereby averting the scenario, as paradoxical as it is potentially unworkable, of deleting the entire chain.

The passages on the qualification of identifiers as personal data – public keys attributable to natural persons identifiable by means reasonably likely to be used – and the warning that technical impossibility cannot be invoked to justify non-compliance with the GDPR likewise remain unchanged. As we shall see, on this front the final version does not retreat but in fact strengthens the board’s position.

The clarifications introduced

The amendments actually incorporated into version 2.0 are limited in number, but some of them are of no small practical significance.

• On-chain metadata as personal data. The principle that on-chain data is not confined to the payload (the content) of transactions but also covers the other data structures recorded on the chain was already present in the first version. The final version, however, makes it operational through a new footnote that expressly lists the categories of on-chain metadata capable of constituting personal data where they allow the direct or indirect identification of a natural person: transaction identifiers, wallet addresses (the alphanumeric addresses identifying the participants in transactions), event logs, receipts, state transitions, smart contract storage and related traces. This is a clarification that runs counter to the industry’s requests to exclude such identifiers from the notion of personal data and that calls for a more granular mapping of the personal data processed.
• The (conditional) recognition of PETs. The final version supplements the passage on measures to protect on-chain data (encryption, hashing with salt or a secret key, cryptographic commitment) with an express reference to emerging Privacy Enhancing Technologies (PETs), such as zero-knowledge proofs (protocols that allow the truth of a statement to be demonstrated without revealing its content) and other advanced cryptographic protocols, on a par with cryptographic obligations, which are recognised as techniques capable of reducing the risks to data subjects. That recognition is, however, accompanied by a twofold caveat, also new: such technologies must be carefully tested and validated and, in any event, are not self-sufficient, since they must always be coupled with further technical and organisational measures suitable to ensure compliance with the GDPR and the exercise of data subjects’ rights.
• The interface with MiCAR and the AMLR on data retention. Of particular interest to crypto-sector operators is the new footnote inserted in the section on retention periods, which expressly recalls the retention obligations laid down by Regulation (EU) 2023/1114 (MiCAR) – (Articles 68(9) and 76(15)) and by Anti-Money Laundering Regulation (EU) 2024/1624 (AMLR) (Article 77), which require identification and transaction data to be retained for at least five years from the end of the business relationship; the footnote also specifies that the AMLR will apply from 10 July 2027 and that, in the meantime, Article 40 of Directive (EU) 2015/849 remains applicable. For crypto-asset service providers (CASPs) authorised under MiCAR, the reference finally provides an explicit anchor, within the Guidelines, for building retention policies, confirming that the storage periods established by EU or member state law must be taken into account when determining retention periods.
• Restrictions on data subjects’ rights under Article 23 GDPR. From a systematic standpoint, the reformulation of the passage on restrictions of data subjects’ rights also deserves attention: the final version clarifies that the relevant examples – including anti-money laundering cases and inventories of certain assets – presuppose that it is EU or member state law that mandates recourse to blockchain solutions. It remains the case that restrictions must be proportionate, strictly defined by law and consistent with the requirement of necessity in a democratic society.
• The expanded glossary. Version 2.0 significantly enriches Annex B with four new definitions:
  • the definition of “consensus,” which specifies that consensus mechanisms among nodes may be probabilistic or eventual and that competing versions of the chain (forks) may arise;
  • the definition of “publicity,” understood as the degree of visibility and accessibility of the data processed in connection with a blockchain, a notion that is central to the framework of the Guidelines but was left undefined in the first version;
  • a broad definition of “smart contract,” which catalogues the various types (token contracts, governance contracts, multisignature or escrow contracts, bridges, proxies, factories, oracle-related contracts) and describes their cascading executions;
  • and, above all, the definition of “wallet address/account/public key,” which crystallises its qualification as personal data under Article 4 GDPR whenever the identifier can be associated with an identified or identifiable natural person.
• The picture is completed by the supplementing of the definition of ledger – specifying that in most implementations the ledger data is materialised at node level by means of key-value databases – and by the consistent replacement, throughout the text, of the reference to the “identities” of the parties with a reference to their “identifiers.”

The remaining changes are of a drafting nature: correction of typos, resolution of ambiguous wording and terminological realignments that don’t affect the substance of the guidance.

What changes in practice for operators

With the adoption of the final version, the Guidelines cease to be a document in fieri and become the interpretative benchmark for European supervisory authorities. For organisations processing personal data by means of blockchain, the operational implications are at least threefold.

• First, the consultation has not shifted the regulatory axis: anyone hoping for a softening of the positions on erasure, the privacy roles of nodes or the preference for permissioned architectures will have to acknowledge that the approach is now settled. The design of any blockchain-based processing will have to start from the preliminary assessment required by the EDPB, duly documented and, in most cases, feeding into a DPIA that addresses the specific aspects indicated in the Guidelines.
• Second, the new footnote on on-chain metadata and the definition of wallet address require the compliance analysis to be extended beyond the content of transactions: event logs, smart contract storage, receipts and state transitions fall squarely within the perimeter of personal data mapping, with direct consequences for records of processing activities, privacy notices and impact assessments.
• Finally, for CASPs and other supervised entities, the express reference to MiCAR and the AMLR confirms the need for an integrated approach, in which retention policies and data protection by design measures are built by holding together anti-money laundering obligations, prudential requirements and GDPR principles.

The regulatory crossroads we wrote about in the immediate aftermath of the first version has been resolved: the EDPB has (predictably) chosen the path of interpretative continuity, and the European decentralised ecosystem will have to draw the consequences in terms of compliance.

On a similar topic, you may find this article of interest” “EDPB Guidelines 02/2025: navigating GDPR compliance with blockchain technology.”

Authors: Andrea Pantaleo, Giulio Napolitano

 

Technology Media and Telecommunications

Smartphones and radio frequencies: Supreme Court holds manufacturers to enhanced information duties even in the absence of scientific certainty

The Italian Supreme Court (Corte di Cassazione) has once again addressed the relationship between the precautionary principle, product safety obligations, and consumers’ right to comprehensive information in connection with the risks, albeit still scientifically uncertain, associated with prolonged exposure to radio frequencies emitted by mobile phones.

The court overturned and remanded the decision of the Bologna Court of Appeal, holding that the lack of definitive scientific proof of a causal link between exposure to electromagnetic waves and the onset of cancer is not sufficient to exclude manufacturers’ information obligations, nor the damage arising from the violation of a consumer’s right to make informed decisions.

Background of the decision

The case originated from an action brought by a consumer who purchased a smartphone from a well-known manufacturer in 2016 and used it extensively, including in low-signal conditions and in close proximity to her minor daughters. In 2018, she became aware that the International Agency for Research on Cancer (IARC) had classified radio frequencies as potentially associated with an increased risk of certain cancers.

The claimant alleged that the packaging and user documentation lacked clear and visible warnings regarding radio-frequency risks and precautionary measures capable of reducing exposure. She argued that her right to self-determination had been infringed, asserting that, had she been properly informed, she would have changed her usage habits by avoiding keeping the device in contact with her body or near her bed and by using earphones or speakerphone functions more frequently. Both the trial court and the Bologna Court of Appeal dismissed the claim, emphasizing the product’s compliance with technical standards (CE marking and SAR values) and the absence of conclusive scientific evidence.

Technical compliance and product safety

The Supreme Court reaffirmed that the concept of a “safe product” is not exhausted by compliance with regulatory standards or the presence of CE marking. It also encompasses informational defects when a product lacks the instructions and warnings necessary to prevent risks that aren’t readily apparent to consumers.

In other words, compliance with technical parameters does not relieve manufacturers of the obligation to adopt additional precautions whenever necessary to protect users’ health.

Precautionary principle and professional diligence

The court rejected the lower court’s approach, which had confined the precautionary principle (Article 191 TFEU) to the public-law sphere. According to the Supreme Court, the link between that principle and private-law relationships is ensured through the duty of professional diligence under Article 1176 of the Italian Civil Code.

A professional operator has to not only to comply with minimum technical requirements but also adopt all precautionary and informational measures that, based on an ex ante assessment, are necessary or even merely advisable to prevent harm to users’ health.

In this context, the court referred to the “as low as reasonably achievable” as a framework for managing risks arising from exposure to potentially harmful factors even where their dangerousness has not been fully established scientifically. Scientific uncertainty, the court clarified, does not exempt manufacturers from their duty to inform; rather, it’s precisely the circumstance that triggers a preventive obligation designed to safeguard product safety.

Moreover, information cannot be limited to generic warnings. It must be sufficiently clear and meaningful to enable consumers to properly assess risks and benefits and adopt appropriate precautionary measures.

Compensable damage

With regard to damages, the court also criticized the lower court for limiting its analysis to the claimant’s subjective fear. Compensable harm may consist in the infringement of the right to self-determination, namely the inability to make an informed choice as to whether and how to use a product because of inadequate information.

Nevertheless, the consumer still bears the burden of proving, including through presumptions, that adequate information would have led to different choices. Mere abstract fear, by itself, is not compensable.

Particularly noteworthy is the court’s openness to remedies in specific performance. On remand, the lower court must assess not only potential monetary compensation but also the adoption of concrete measures by the manufacturer, such as supplementing warnings provided to users and, where appropriate, supplying accessories, for example earphones, capable of reducing exposure to electromagnetic emissions, even where the risk remains merely potential.

Conclusions

This decision is likely to have a significant impact on consumer litigation in the coming years. It provides an important reference point for assessing information obligations in contexts characterized by scientific uncertainty, requiring businesses to manage risk communication in a manner that doesn’t shift the burden of uncertainty onto consumers.

Author: Gabriele Cattaneo

 

Intellectual Property

‘ROSE’ trademark rejected by the EU General Court: When a colour describes the product

Pink is one of the most widely used colours in fashion, from baby onesies to the trendiest teen looks. And it’s precisely this ubiquity that makes “ROSE” unregistrable as a trademark for clothing. So ruled the General Court of the European Union in its judgment of 22 April 2026 (Case T-56/25), upholding the refusal issued by the EUIPO.

Background of the case

Rose Bikes GmbH, a German company based in Bocholt known for its bicycles, applied to the EUIPO on 7 February 2024 to register the word mark “ROSE” also for clothing, footwear and headgear (Class 25), as well as for the related retail services (Class 35).

The problem surfaced immediately. For English or French speakers – and therefore for a large share of the European public – “rose” is not a fanciful term but simply denotes the colour pink. The EUIPO examiner refused the application for Class 25, finding the sign descriptive and devoid of distinctive character under Article 7(1)(b) and (c) EUTMR. For the Class 35 retail services, however, registration was allowed to proceed.

Rose Bikes’ defence: The vita precedent

Rose Bikes appealed the decision on 19 July 2024, relying on an apparently favourable precedent: the vita case (T-423/18).

In that ruling, the EU General Court had allowed registration of “vita” (which means “white” in Swedish) for kitchen utensils, on the grounds that white was just one of many possible colours for those products – an accidental feature, not inherent to their nature.

The company’s reasoning was straightforward: if “white” doesn’t intrinsically describe a blender, then “pink” shouldn’t intrinsically describe a t-shirt. Pink, Rose Bikes argued, is merely one of countless possible colours for clothing.

The Board of Appeal: Pink in clothing is not white in the kitchen

The Second Board of Appeal of the EUIPO, in its decision of 28 November 2024 (Case R 1461/2024-2), was not persuaded.

It acknowledged that no general rule can be drawn from vita to the effect that a colour name is never descriptive: it depends on the product. And in clothing, colour is not a secondary detail. It’s a decisive purchasing criterion for consumers, a way of expressing personal identity, an element that can make or break a purchase decision – which is precisely why major online retailers such as Zalando and Momoxfashion use colour as a central search filter.

There is more: the board pointed to a fact familiar to anyone who has set foot in a children’s clothing shop. Baby clothes are typically sold in pink or pale blue. Among teenagers, too, pink is a widely popular colour. For these sub-categories, pink isn’t an incidental feature but a trait strongly associated with the product.

The sign was also found to lack distinctive character: an English- or French-speaking consumer, seeing “ROSE” on a garment, would think of the product’s colour, not of the company that makes it.

The EU General Court confirms: Pink is intrinsic to baby clothing

Rose Bikes brought the matter before the General Court of the European Union, alleging infringement of Article 7(1)(c) and (b) EUTMR.

The court addressed the core issue with a distinction worth noting. As a matter of principle, echoing vita and OFF-WHITE (T-133/19), it acknowledged that the mere fact a product is available in a given colour doesn’t automatically make that colour a “characteristic” of the product. Colour can be a purely incidental, contingent feature.

But – and this is the decisive step – pink is not just any colour when it comes to baby clothing. The court noted that it’s well known that baby clothes are typically marketed in pink or pale blue, and that pink is also particularly significant for teenagers' clothing. For these sub-categories, pink is an intrinsic characteristic inherent to the nature of the product, not an accidental detail.

The trap of an overly broad specification

The court then applied a well-established principle, already affirmed in case law going back to Postkantoor (C-363/99): if a sign is descriptive even for just one sub-category of goods – here, baby clothing – the refusal extends to the entire broader category, unless the applicant has expressly limited the application to exclude the problematic sub-category.

Rose Bikes had listed “clothing, footwear and headgear” generically, without any limitation. The refusal therefore extended to the whole of Class 25. As for the lack of distinctive character, the court didn’t even find it necessary to examine that ground separately: a single absolute ground for refusal is enough to bar registration.

The appeal was dismissed in its entirety, with costs to be borne by each party.

Comparing vita and OFF-WHITE: A case-by-case test

The ROSE judgment offers a good opportunity for a systematic comparison with the two precedents invoked by the applicant, and shows how the court is building an increasingly refined analytical framework for assessing the descriptiveness of colour names.

In vita (T-423/18), the sign corresponded to the plural of the Swedish word “vit” (white), filed for kitchen utensils and household appliances. The court concluded that white was just one of many possible colour variations for those products: a purely accidental, contingent feature, with no direct and immediate link to their nature. Nobody buys a blender because it is white.

In OFF-WHITE (T-133/19), the court similarly rejected descriptiveness for watches and sunglasses: off-white was found to be a contingent feature that could apply to only a fraction of those products, without constituting an intrinsic or inherent characteristic.

The ROSE ruling marks a turning point relative to these precedents — though it doesn’t overturn them. The court expressly cites them as the correct starting point, but introduces a decisive distinction: when a colour is notoriously and typically associated with a specific sub-category of products, that colour ceases to be an accidental detail and becomes an intrinsic characteristic of the product. Pink for baby clothing – traditionally marketed in pink or pale blue – falls squarely within this scenario. The same holds for teenage clothing.

The test that emerges from reading the three cases together is this: the descriptiveness of a colour name doesn’t depend on whether the products in question can come in that colour (true of almost any product), but on whether that colour is typically and intrinsically associated with a specific category or sub-category of products, to the point of being inherent to its commercial nature.

Put differently: white for a blender is one thing; pink for a baby onesie is another.

What the ROSE case teaches trademark practitioners

Pay close attention to how the goods list is drafted. The “sub-category trap” is a real risk: if a sign is descriptive even for just a niche of goods included in the application, the entire relevant class can be refused. A targeted limitation – for example, expressly excluding baby clothing – could have changed the outcome.

Never underestimate the multilingual test. “ROSE” is the name of a German company, and in German it doesn’t denote a colour (the German word for “pink” is “rosa”). But an EU trademark is assessed against all the linguistic areas of the EU, and for English- and French-speaking audiences the meaning is immediately descriptive. Anyone filing an EU trademark should check the sign’s meaning in all relevant languages before even submitting the application.

The test is always case-by-case. There is no general rule as to whether colour names are, or are not, descriptive. What matters is the specific relationship between that colour and that category (or sub-category) of goods: if the link is well known and typical, the colour becomes an intrinsic characteristic rather than an accidental detail.

Author: Maria Rita Cormaci

 

WIPO publishes the World Intangible Investment Highlights 2026: Intangible investment over USD10 trillion

The World Intellectual Property Organization (WIPO) and the Luiss Business School have published the third edition of their annual report on intangible investment, titled “World Intangible Investment Highlights 2026 – Better data for better business and policy,” based on the Global INTAN-Invest Database (World Intangible Investment Highlights 2026 – Better data for better business and policy).

The report provides annual and quarterly statistics on investment in intangible assets – including knowhow, R&D, software, data, trademarks, design and other intellectual property rights – across 29 economies.

The document is structured around eight stylized trends, offering both a long-term view of how intangible investment has evolved and an assessment of more recent dynamics driven by economic and technological factors, including the impact of AI.

According to the data analysed, intangible investment reached an all-time high of over USD10 trillion in 2025, having grown at a compound annual rate of 3.5% since 2008 – roughly 3.6 times faster than investment in tangible assets. Between 2015 and 2025, the gap widened further, with intangible investment expanding at 4.4% annually against 1.8% for tangibles.

The US leads in absolute terms, with nearly USD5 trillion invested in 2025, followed by Japan and Germany; Sweden remains the most intangible-intensive economy relative to GDP, ahead of the US and France. India, Japan and the Philippines stand out among the fastest-growing economies.

Among the various strategic assets, trademarks play a role of primary importance: brand investment exceeded USD1.4 trillion for the first time in 2025, with the US leading in absolute value and Luxembourg in growth intensity.

The report also examines the relationship between AI and intangible investment, distinguishing an initial wave concentrated on physical infrastructure (data centres, semiconductors) from a slower, second wave in which firms reorganise data, skills and processes around AI, with effects across all categories of intangible assets, from organisational capital to R&D.

A finding of particular relevance for IP practitioners is that around 62% of intangible investment still goes unrecorded in official statistics, since assets such as organisational capital, design and brands aren’t treated as investment under national accounts. The report confirms that accurately measuring intangibles is still an open challenge, one that’s critical both for business decisions and for shaping innovation and IP policy.

Author: Massimiliano Tiberio

 

Gaming and Gambling

The Cyber Resilience Act for gambling operators and suppliers: What falls in scope and what has to be done

The Cyber Resilience Act reaches the gambling sector more widely than most operators assume. Downloadable casino and sportsbook clients, mobile applications, gaming cabinets, self-service betting terminals, kiosks and the software supplied with them all qualify as products with digital elements, and the guidance approved by the European Commission on 27 July 2026 removes much of the uncertainty as to where the perimeter runs.

The general reading of that guidance, covering scope, obligations and deadlines across all sectors, is set out in the previous article on this blog. The analysis below applies the same framework to online and land-based gambling operators and to their suppliers.

Three dates govern the planning:

• The reporting obligations under Article 14 apply from 11 September 2026, including in respect of products already on the market.
• The CRA Regulation applies in its entirety from 11 December 2027.
• EU type-examination certificates issued under other EU legislation may be relied upon until 11 June 2028.

1) Which gambling products fall within the scope of the CRA?

The test under Article 2(1) covers any product with digital elements whose intended purpose or reasonably foreseeable use includes a direct or indirect data connection to a device or network. Applied to the gambling sector, the outcome is the following.

An operator whose product is played exclusively through a browser does not, on that basis alone, place a product with digital elements on the market, while the same operator distributing a native mobile application does.

2) The cabinet and its software constitute one product

The channel through which software reaches the user is not decisive. Where software is necessary to operate, configure, control or use hardware according to its intended purpose, the two elements together constitute a single product with digital elements, and both are placed on the market at the same moment.

As a consequence, a cabinet, its firmware, the game software installed on it and the configuration utility supplied by the manufacturer form one product for the purposes of the Regulation, even where the game software is delivered later through a download or an update channel. The same conclusion applies to a betting terminal supplied with a separate management application, and to a mobile application that a player must install to use a connected loyalty card or a cashless wallet.

For standalone software, once a version is first supplied for distribution, every copy of that version is placed on the market at that same moment, whatever date each player downloads it. Builds that differ in included components or enabled functionalities, such as separate builds for different operating systems or market-specific bundles, are treated as distinct products and require their own assessment.

3) Remote game servers, player account platforms and SaaS: Three different treatments

Remote data processing solutions form part of the product and must be covered by the risk assessment, the technical documentation and the conformity assessment. Their identification rests on three cumulative questions, namely whether the processing takes place at a distance, whether the absence of that processing would prevent the product from performing one of its functions, and whether the software was designed and developed by the manufacturer or under its responsibility.

Applied to a typical online gambling architecture, the classification runs as follows.

A remote game server operated by a gambling supplier and reached by the operator through an interface will normally fall in the third above, since the operator neither designed nor developed it. The operator still has to identify the risks arising from the integration and mitigate them within its own product, through authentication of the interface, verification of the integrity of the data received and controls that prevent the product from entering an insecure state when the service becomes unavailable.

4) Who is the manufacturer, the supplier or the operator?

The allocation of roles follows the same logic that the gambling sector has become familiar with under the AI Act, and it produces comparable surprises.

• A supplier that builds a cabinet, a platform or a client and places it on the market under its own name is the manufacturer and carries the full set of obligations.
• An operator that distributes an application under its own brand and gambling license is the manufacturer of that application, whatever development arrangement sits behind it.
• An operator or integrator that assembles components into a new product places a new product on the market and is its manufacturer for all purposes.
• A person who substantially modifies a product already placed on the market and makes it available becomes its manufacturer, in respect of the modified part alone where the cybersecurity of the product as a whole is unaffected, and in respect of the entire product where it is not.

The last point carries real consequences for operators that take a supplier’s platform and customise it heavily, which is common practice in this market. Customisation that alters the level of cybersecurity risk in a way the original risk assessment did not consider transfers the obligations, and the operator that believed itself to be a customer becomes the manufacturer of the modified product.

5) Conformity assessment: Gaming certification doesn’t replace CE marking

A product may have only one core functionality for the purposes of the applicable conformity assessment regime, and functions ancillary to it leave the classification unaffected.

For most gambling products the outcome is the default regime, which permits internal control based on module A. A gaming cabinet doesn’t acquire the core functionality of an operating system merely because it integrates one, nor that of a firewall because it contains one. Attention is nonetheless required where a product’s core functionality corresponds to a category listed in Annex III or Annex IV, which may occur with access control units, biometric readers and certain payment or card-reading devices, and where third-party assessment then becomes mandatory or conditional.

Two consequences deserve to be recorded.

• Certification obtained under gaming technical standards, whether from a testing laboratory or under the technical rules of a national regulator, does not discharge the obligations under the CRA. The two regimes pursue different objectives, and the CE marking, the EU declaration of conformity and the technical documentation remain due in addition to any gaming approval.
• Where a harmonised standard covering the core functionality is applied, the presumption of conformity extends only to the risks that the standard actually covers. Ancillary functionalities outside its scope carry no presumption and the measures adopted in respect of them require separate documentation.

Where variants of a cabinet or of a client share the same architecture, security-relevant design and intended purpose, a single risk assessment, a single technical file and a single declaration of conformity may cover the whole family, provided that the declaration identifies the variants concerned.

6) Support periods and the length of a cabinet’s life

The minimum of five years for support periods operates as a safeguard and not as a default, since the support period must reflect the period during which the product is expected to be in use. Gaming cabinets, terminals and kiosks routinely remain in operation for seven to ten years, and a support period declared at five years will be difficult to defend for equipment of that kind. The end date must be communicated to the purchaser at the time of purchase, specifying at least the month and the year.

For iteratively developed software, Article 13(10) allows remediation to be limited to the version last placed on the market, provided that users of earlier versions can upgrade free of charge and without additional costs. Personnel time, routine testing and configuration adjustments count as ordinary maintenance effort. Mandatory purchases of new hardware and fundamental changes to the operating environment do not, which matters for operators running estates of older cabinets that cannot accept the latest build.

A substantial modification does not automatically reset the support period. The question is whether the change affects the factors that originally determined the expected use time. A software update adding new game modes leaves the durability of the cabinet untouched and the original period continues to run, whereas the replacement of the embedded computing platform with longer-lived components requires the period to be recalculated.

7) Legacy protocols in land-based estates

Casino management systems and machine communication protocols in widespread use were designed decades ago and offer limited security by modern standards. The guidance addresses this situation without granting an exemption.

Where an essential requirement cannot be met because the intended purpose of the product requires interoperability with existing infrastructure, the manufacturer is expected to document the constraint, to assess the associated risks and to implement compensatory measures. Where the product can technically support both a secure protocol and a legacy one, the secure protocol is to be implemented and enabled by default, with the legacy protocol available only where interoperability requires it. The constraint must be reassessed periodically and the product updated once it can be lifted.

8) Spare parts across an installed estate

Spare parts intended to replace identical components and manufactured to the same specifications are exempt under Article 2(6). Identity is assessed by reference to the functional role of the component and to characteristics relevant to cybersecurity, such as cryptographic mechanisms, protocols and access control features. A replacement bill validator, printer or display that performs the same function with the same security characteristics remains exempt, whereas a newer board with a different cryptographic implementation does not and constitutes a product with digital elements in its own right.

The exemption carries an evidentiary condition. The repair purpose must be apparent from the context of supply, through identification of the product or product family in the order or through supply via after-sales channels, and the evidence must remain available to market surveillance authorities. The same component offered through general retail channels loses the benefit.

9) Reporting from 11 September 2026, alongside every other notification duty

Actively exploited vulnerabilities and severe incidents affecting the security of the product must be notified simultaneously to ENISA and to the CSIRT designated as coordinator.

Awareness arises when, after an initial assessment conducted promptly, the manufacturer holds a reasonable degree of certainty that a vulnerability in its product is being actively exploited or that a severe incident has compromised the security of that product.

The practical difficulty for gambling companies lies in the accumulation of parallel duties. A single incident affecting a player-facing application may trigger the CRA notification to ENISA and the coordinating CSIRT, a personal data breach notification under the GDPR, an incident report to the gambling regulator under national licence conditions, and, for entities within their scope, obligations under NIS2 or DORA. The deadlines differ, the recipients differ and the thresholds differ. A single incident response procedure mapping all of them against one timeline is the only workable answer, and building it after the first incident is considerably more expensive.

10) What should be done now

• Inventory every product with digital elements placed on the market, distinguishing downloadable clients, mobile applications, cabinets, terminals, kiosks and licensed software.
• Determine, for each of them, whether the company acts as manufacturer, importer, distributor or integrator, paying particular attention to customised platforms.
• Classify the remote components as remote data processing solutions, third-party components or external dependencies, and record the reasoning.
• Verify whether any product has a core functionality falling within Annex III or Annex IV, since the conformity assessment route changes accordingly.
• Review declared support periods against the realistic operating life of the equipment.
• Document legacy protocol constraints together with the compensatory measures adopted.
• Establish the reporting procedure before 11 September 2026 and align it with the gambling, data protection and financial notification duties already applicable.

The work is largely documentary, and it’s the documentation that market surveillance authorities will ask to see.

Author: Giulio Coraggio

 

Italian responsible gambling campaigns: New rules open a branding window for licensed operators

Italian responsible gambling campaigns now have a rulebook and might represent an opportunity for operators to show their brands in a highly regulated market which requires a tailored approach.

After a consultation, the Italian communications authority (AGCOM) has published its supplementary guidelines on the interpretation of the Italian gambling advertising ban. The guidelines implement the regime introduced with the reform of the Italian remote gambling licensing regime that imposed on concessionaires an annual investment in responsible gambling communications equal to 0.2% of net revenues, capped at EUR1 million. Below is analysis of the contents of the supplementary guidelines.

Why the final text is good news for licensed operators

For eight years the Italian market has operated under a near-total advertising prohibition, while brand exposure kept migrating into grey areas policed by AGCOM with fines that hit affiliates and platforms as well as media owners and commissioning parties. The supplementary guidelines do something different. They build a lawful, branded and measurable communication channel inside the ban.

Three elements deserve particular attention from a commercial standpoint:

1. The logo is expressly admitted. The use of the logo or trademark is allowed, provided the gaming product isn’t shown.
2. The mandatory spend becomes visibility. The 0.2% investment is a statutory obligation in any case. Operators that build a proper multi-format plan convert a cost item into the only lawful brand impression available on Italian generalist media, and the guidelines require an adequate presence on national and local television, radio and press.
3. A safeguard clause is now written into the text. Communications compliant with the supplementary guidelines and genuinely free of incentivising content cannot be treated as promotional communications prohibited by the Italian gambling advertising ban. This is the closest thing to a safe harbour that the Italian market has seen since 2018.

The counterpart is that conformity is substantive, not declaratory. AGCOM will look at content, context, form, frequency of dissemination, use of the mark and the presence of any referral to the gaming offer.

The compliance perimeter at a glance

Logo use: The marginality test

The logo performs an identification function, and AGCOM expressly recognises its value in distinguishing the legal offer from the illegal one, particularly in less supervised social and digital contexts. That recognition is a genuine gain for licensed operators.

The mark, however, must never be the central or most emphasised component. The indices of marginality listed by the Authority are practical and easy to build into a creative brief:

• contained dimensions compared to the textual and graphic elements of the warning;
• placement in a corner or lateral area, never in the central or opening part of the format;
• no animation, progressive enlargement or other effects increasing visibility;
• in audiovisual formats, limited exposure time relative to the overall duration of the prevention message.

Anyone drafting a media plan should treat these four indices as a checklist to be documented at storyboard stage, because they’re the elements an inspector will measure after the campaign has aired.

Links and QR codes: Four cumulative conditions

The “no-link” principle survives, but with a carve-out that wasn’t obvious in the draft. Referrals to neutral informative pages are admitted, including pages hosted on sites attributable to the Italian gambling licensed operator, provided they don’t carry the operator’s brand or logo and are dedicated exclusively to player protection tools. Four conditions apply cumulatively:

1. the destination page contains no promotional element and no information on gaming products, odds, bonuses or contractual conditions, and doesn’t allow navigation towards the gaming area or the gaming account;
2. access to the page and the activation of protection tools don’t entail any profiling of the user under the GDPR, nor the development of predictive logics on gambling behaviour or risk propensity;
3. any data collected in that context, for instance the activation of a spending limit or a self-exclusion period, is processed consistently with the minimisation and purpose limitation principles of the GDPR, and is not reused for direct or indirect marketing, commercial profiling, ad targeting or behavioural profile reconstruction, nor shared with third parties for incompatible purposes;
4. the functional and IT segregation between the player protection area and the rest of the site is verifiable and documentable by the concessionaire at the Authority’s request.

Fail one of them, and the referral becomes a surreptitious form of indirect promotion in breach of the Italian gambling advertising ban. The fourth condition is the one that will require engineering work rather than legal drafting, since documenting segregation to a regulator means logs, architecture diagrams and access controls, not a paragraph in a compliance policy. Privacy and marketing teams should be involved from the outset, given the explicit prohibition on reusing self-exclusion and limit-setting data.

On social networks and video sharing platforms the Authority accepts referrals to operator-managed sections free of gambling invitations, activated where the format allows through a single responsible gambling image with a dedicated link, including a link in bio or in the comments.

Targeting, risk markers and automated messaging

Segmentation is treated as one of the most sensitive application profiles. The 18-24 age band identified receives particular attention, alongside minors in the 11-13 and 14-17 bands and people over 65. AGCOM rejected the option of excluding these groups from campaigns, on the ground that exclusion would neutralise the preventive effect. Initiatives addressed to minors are channelled exclusively through educational and institutional settings.

Pre-testing of the message on the target segment before dissemination is recommended, together with retention of the segmentation criteria and media plans adopted. Operators should keep this documentation available: it’s the natural evidence base in any subsequent proceeding.

The self-assessment grid

The most practically useful part of the document is the conformity grid, which allows Italian gambling licensed operators, commissioning parties, media owners and event organisers to verify a message before it goes out.

Necessary requirements (cumulative): clear and prevalent prevention content referring to concrete behaviours of immoderate gambling; recognisability as a prevention message; a comprehensible warning on risks; the minimum information elements required by the guidelines which are that the communication:

1. provides clearly and prominently features content aimed at preventing and combating gambling disorders, relating to specific instances of excessive gambling behaviour;
2. is clearly recognisable as a prevention and protection message;
3. includes, in an easily understandable form, a warning about the risks associated with an unbalanced approach to gambling;
4. contains
   • references to support services, such as the new single national helpline dedicated to all forms of addiction, whether substance-related or behavioural;
   • information on the option to activate self-exclusion measures and set limits on spending and time spent gambling, emphasising that these measures are designed to protect the player; and
   • any other information required by the relevant legislation.
5. is consistent with the themes identified in the Annual Policy Document of the Government Commission which still needs to be issued;
6. where it bears the licence holder’s logo or trademark, it uses it within the limits indicated above.

Blocking elements (any one is fatal): incentivising elements; direct or evocative reference to the gaming offer; call-to-action however formulated; graphic or narrative emphasis on the brand or gaming products.

Elements that don’t trigger non-conformity: the logo within the limits indicated above; neutral or merely descriptive communications on protection tools; compliant referrals to protection pages; short formats within an integrated plan; automated messaging to account holders; references to behavioural risk markers, including in messages addressed to the general public; a tone normalising the request for help.

Context, form, frequency and placement are elements of overall assessment, with trivialisation of financial loss and representation of gambling as an ordinary moment of daily pleasure singled out as the two normalisation risks.

Prior clearance: The most effective risk mitigation tool

The guidelines open the door to prior engagement with the Italian Self-Regulatory Advertising Institute (Istituto di Autodisciplina Pubblicitaria – IAP) as a potential prior approval which might limit the risk of challenges. Indeed, the IAP provides a very fast prior consultation solution that grants strong arguments to support the legitimacy of the initiative, while AGCOM never provides a formal clearance.

Submitting the communication to IAP before dissemination produces three concrete benefits:

• Predictability on borderline calls. The distinction between marginal and emphasised use of a logo, or between a neutral protection page and a surreptitious gateway is a matter of degree. A prior opinion converts that judgement into a documented position taken before the money is spent.
• Evidence of diligence in the liability chain. The liability of commissioning parties, media owners and event organisers is assessed according to objective criteria, including the possibility for the party concerned to detect the divergence of the message from the established safeguards. A positive IAP assessment is precisely the element that shows a media owner or a commissioning party acted with the required diligence, and it's worth building the clearance into contractual warranties along the production chain.
• Correction before exposure. Amending a storyboard costs a fraction of what it costs to withdraw a national campaign, and past AGCOM practice shows that sanctions in this area hit several links of the chain simultaneously rather than the operator alone.

Prior clearance doesn’t bind AGCOM and doesn’t exclude a subsequent proceeding. It does, however, make the operator’s position substantially more defensible, and it’s difficult to see why a concessionaire investing up to EUR1 million a year would leave that protection on the table.

8. Action points for Italian gambling licensed operators

Operators finalising campaigns for the coming season should focus on the following:

1. rebuild the creative brief around the criteria listed above, and record the reasoning behind each choice;
2. audit the linkable page architecture against the four cumulative conditions indicated above, with input from privacy and IT teams on segregation and profiling;
3. design the media plan as an integrated multi-format system, with short formats routing to extended content, and with the generalist media presence required by the guidelines;
4. run and document a pre-test on the target segment, retaining segmentation criteria and media plans;
5. build the grid into an internal sign-off template, with a named owner for each requirement; and
6. submit the final creative to IAP and reflect the outcome in the contracts with agencies, media owners and event organisers.

The supplementary guidelines entered into force the day after its publication on the Authority’s website, with transitional arrangements possible for campaigns already planned or contracted. Italian responsible gambling campaigns are therefore live business as of now, and the operators that treat them as a communication project rather than a compliance formality will be the ones extracting value from a budget they have to spend regardless.

Author: Giulio Coraggio

---

Innovation Law Insights is compiled by DLA Piper lawyers, coordinated by Edoardo Bardelli, Carolina Battistella, Noemi Canova, Gabriele Cattaneo, Maria Rita Cormaci, Camila Crisci, Cristina Criscuoli, Tamara D’Angeli, Chiara D’Onofrio, Federico Maria Di Vizio, Enila Elezi, Nadia Feola, Laura Gastaldi, Vincenzo Giuffré, Nicola Landolfi, Giacomo Lusardi, Josaphat Manzoni, Valentina Mazza, Lara Mastrangelo, Maria Chiara Meneghetti, Giulio Napolitano, Andrea Pantaleo, Deborah Paracchini, Maria Vittoria Pessina, Marianna Riedo, Rebecca Rossi, Roxana Smeria, Massimiliano Tiberio, Federico Toscani, Giulia Zappaterra.

Articles concerning Telecommunications are curated by Massimo D’Andrea, Flaminia Perna, Matilde Losa and Arianna Porretti.

For further information on the topics covered, please contact the partners Giulio Coraggio, Marco de Morpurgo, Gualtiero Dragotti, Alessandro Ferrari, Roberto Valenti, Elena Varese, Alessandro Boso Caretta, Ginevra Righini. 

If you no longer wish to receive Innovation Law Insights or would like to subscribe, please email Silvia Molignani.