Search results for: AI

Artificial intelligence has quietly become an increasingly common feature of customer communication. Across industries, companies are using AI-powered chatbots, virtual assistants, and automated customer journeys to support or replace traditional customer support. In some cases, AI is a first point of contact before more complex or sensitive matters are escalated to human agents. The business case is obvious: faster responses, round-the-clock availability, and lower operating costs.

The legal consequences are becoming increasingly obvious as well.

As generative AI moves from pilot projects, niche applications, and proof-of-concept trials into daily business operations, a growing number of disputes are emerging at the intersection of technology, consumer protection, and corporate liability.

Questions that until recently belonged to conference panels and academic papers are now finding their way into courtrooms. Consumer associations, competitors, regulators, and private claimants are starting to test the legal limits of AI-generated customer communications, particularly where inaccurate or misleading outputs affect customers and commercial decision-making.

The Aesthetify case: When the chatbot went a little too far

One of the first publicly known German cases concerning AI hallucinations in customer communications involved Aesthetify, a cosmetic medicine provider operating an AI-powered chatbot on its website. The chatbot answered patient inquiries and assisted with appointment bookings. When users asked about the qualifications of the clinic’s founders, however, the system became somewhat more creative than accurate.

According to the Higher Regional Court of Hamm (OLG Hamm), the chatbot informed prospective patients that the founders, publicly known as “Dr. Rick” and “Dr. Nick,” held specialist qualifications in aesthetic and plastic surgery that they did not possess. It even invented professional designations that do not exist under German medical regulations.

One might say Aesthetify’s chatbot attempted a cosmetic enhancement of the facts. However, this intervention did not survive judicial scrutiny.

The Consumer Association of North Rhine-Westphalia (Verbraucherzentrale NRW) challenged the statements as misleading commercial conduct under German unfair competition law. As Aesthetify declined to provide a cease-and-desist declaration, litigation followed.

In its decision of 12 May 2026 (Case No. 4 UKl 3/25), the OLG Hamm held that the chatbot’s statements were attributable to the company itself. The court rejected the argument that the AI system operated as an independent third party. Even if the chatbot had been trained exclusively on correct information, the operator remained responsible for the inaccurate output generated through its customer-facing communication channel.

The significance of the decision extends, of course, beyond customer service cases. The court effectively rejected what some organisations may have assumed would become a standard defence in future AI cases: the AI did it, not us. Where the AI functions as part of a company’s commercial communication, German courts appear willing to treat its statements as the company’s own.

AI liability without an AI liability regime

The Aesthetify decision also highlights a sometimes misunderstood aspect of European AI regulation: while the EU has adopted extensive rules governing the development and deployment of AI, it has not created a comprehensive AI-specific civil liability framework, as the proposed AI Liability Directive was ultimately withdrawn.

But this does not create a legal vacuum; quite the opposite. As is often the case with emerging technologies, existing legal frameworks must now be applied to a technology that was not necessarily foreseeable when those laws were conceived. It leaves disputes involving AI-generated harm to be resolved largely through existing national laws. Therefore, businesses deploying AI remain exposed under a wide range of established causes of action, including the following:

  • unfair competition and misleading advertising claims
  • contractual liability arising from inaccurate AI-generated information
  • product liability claims involving AI-enabled products
  • professional negligence claims
  • GDPR-related enforcement and damages claims
  • intellectual property disputes
  • claims arising from reputational harm caused by false AI-generated statements

The legal analysis in Aesthetify was conventional. The court did not engage in a broader philosophical discussion about machine autonomy, emergent behaviour, or the technical nature of hallucinations. Instead, it asked a straightforward question: were consumers presented with misleading commercial information attributable to the company operating the chatbot? The answer was yes. The fact that the information originated from an AI system did not alter the outcome.

The AI Act as a future source of disputes

The EU AI Act can be viewed primarily as a compliance framework. But it may also become a source of future disputes.

The AI Act regulates how AI systems must be designed, deployed, monitored, and governed. It imposes obligations relating to risk management, human oversight, documentation, transparency, cybersecurity, and post-market monitoring. For providers of general-purpose AI and generative AI systems, additional transparency requirements apply. These rules are intended to reduce risks before harm occurs.

What the AI Act does not do is answer the question of who ultimately bears the costs when harm nevertheless occurs. It allocates responsibility, but it does so on the regulatory plane, distinguishing providers from deployers and backing those roles with market surveillance and administrative fines, but conferring no right of action on the person who suffers the loss.

The instrument intended to close that gap no longer exists. The proposed AI Liability Directive, conceived as the civil-law counterpart to the AI Act, was withdrawn in 2025. What remains at EU level is the revised Product Liability Directive (EU) 2024/2853, which brings software, including AI systems, within the definition of a product. Member states must transpose it by 9 December 2026; in Germany, the government’s draft modernisation of product liability law has been before the Bundestag since March 2026.

Even that leaves a substantial gap. The revised regime addresses death, personal injury, property damage, and the destruction or corruption of data suffered by natural persons. It does not reach the pure economic and reputational loss a company sustains when an automated system publishes something untrue about it. Those claims continue to be governed by national tort, personality, and unfair competition law.

The AI Act therefore does not itself establish liability. What it creates is evidence. Missing transparency notices, deficient documentation, weak governance structures, or a failure to implement effective human oversight are precisely the findings a claimant will rely on to establish breach of duty, and regulatory records will increasingly supply them.

Beyond chatbots: The next wave of AI disputes

The Aesthetify case is unlikely to remain an isolated incident.

Across Europe, disputes involving AI-generated misinformation are already emerging. In Germany, the District Court Munich I recently addressed a case involving AI-generated search summaries that falsely reported a company to be insolvent (Case no. 26 O 869/26). Injunctive relief followed, providing another indication that courts are willing to intervene where AI-generated misinformation causes tangible harm.

Nevertheless, the contours of liability for AI-generated content are still taking shape. For example, only a few days later, the District Court Berlin II took a different approach. It rejected the argument that AI-generated search summaries should be attributed to the search engine operator as its own communication in proceedings concerning trademark and unfair competition claims (Case No. 52 O 62/26 eV). However, the case can be distinguished on the facts. The AI did – according to the Court – not form part of the company’s own commercial communications; rather, it functioned as a tool that aggregated and summarized information from third-party websites.

Looking ahead, several categories of disputes appear particularly likely:

  • AI systems communicating incorrect pricing or product information
  • customer-service agents inadvertently concluding contracts or making binding commitments
  • discriminatory algorithmic decision-making
  • inaccurate medical, insurance, or financial recommendations
  • copyright and training-data disputes
  • deepfakes and synthetic content
  • AI-generated defamation
  • cybersecurity incidents involving manipulated or compromised AI systems

Particularly interesting are the growing concerns surrounding unintended cyberattacks by the latest and most powerful AI models.

Litigation is catching up with innovation

The broader lesson from Aesthetify is not simply that companies may be liable for chatbot hallucinations.

The lesson is that AI disputes have entered a new phase. The first generation of AI related dispute risk discussions was largely hypothetical. The next generation will likely be fought through cease-and-desist letters, regulatory investigations, injunction proceedings, and finally through damages claims.

For businesses deploying AI, the era of treating AI disputes risk as an afterthought is rapidly coming to an end. AI may be capable of generating answers automatically. Responsibility, however, remains decidedly human.

Contractual safeguards: Vendor agreements as a line of defence

Beyond questions of statutory liability, the Aesthetify case also illustrates the importance of the contractual layer surrounding AI deployments. Chatbots and other AI-powered customer service tools are frequently developed, trained, or hosted by external providers rather than built entirely in-house. The agreements governing these relationships – covering development, licensing, hosting and ongoing support – play a central role in allocating responsibility when an AI system produces inaccurate or misleading output. This has always been a key consideration in IT contracts involving external developers and service providers, and it continues to apply with undiminished importance in the AI context.

Service descriptions deserve close attention. Where the scope of services, permissible use cases, quality standards, monitoring obligations and escalation procedures are defined clearly, the parties are better placed to determine which of them is responsible if the AI system operates outside its intended parameters. Vaguely drafted service descriptions, by contrast, tend to shift disputes back into the grey area which the Aesthetify decision has shown courts are increasingly unwilling to leave unresolved.

DLA Piper’s AI disputes and advisory teams can support you on AI governance, regulation and litigation. We cover the full AI lifecycle, from AI readiness assessments and compliance programs to regulatory investigations, consumer protection disputes, unfair competition claims, AI-generated misinformation, and litigation.

In October we wrote a piece discussing the difficulties in bringing a criminal case for submarine cable damage, looking at the Eagle S case in Finland. Our colleague Pia Bräysy from our Helsinki office has informed us of the following update:

On 27 August 2026, the Court of Appeal overturned the District Court’s decision on lack of jurisdiction and remitted the case back to the District Court for trial.

The Court of Appeal held that the matter did not constitute an “incident of navigation” within the meaning of Article 97 of the UNCLOS, as it was not comparable to a collision or other maritime accident. The Court acknowledged that the dropping of the anchor could initially be regarded as an incident; however, taking into account that the crew continued to drag the anchor for several hours after the authorities had contacted the vessel and requested that it verify its anchor position — and that the crew had misrepresented the anchors as being secured — the conduct could not be characterised as an incident within the meaning of the Convention. As Article 97 therefore does not apply, the courts of Finland have jurisdiction on the basis that the effects of the criminal conduct manifested in Finland.

For more details do contact Mike Conradi or Pia Bräysy directly.

On 15 July 2026, Ofcom published a statement setting out its decision to introduce a new Condition C9 into the General Conditions of Entitlement which sets out how Ofcom will require mobile operators and business messaging aggregators to protect mobile users from scam mobile messages (“New General Condition“) and a new guidance document “Scam mobile messages: guidance on protecting people and businesses” (“New Guidance“) to assist operators with understanding how to comply with these new regulatory obligations.

The New General Condition will come into effect from 2027; the requirements applicable to person-to-person (P2P) messaging will come into effect on 18 January 2027, and those that apply to application-to-person (A2P) messaging will come into effect on 15 July 2027.

It is important to note that the New General Condition will apply to messaging services that are regulated under the Communications Act 2003 (Communications Act), which encompasses “number-based” interpersonal communications services, covering SMS and MMS messaging carried over UK telecommunications networks. The New General Condition will not apply to “over the top” messaging services such as WhatsApp and other online mobile messaging services which are not regulated under the Communications Act. This means that different regulatory frameworks will be applied to “number-based” communications services and “over the top” messaging services respectively.

In this article, we set out the background to the New General Condition and New Guidance, and provide an overview of the changes proposed by Ofcom.

UK efforts to protect mobile users from scams and fraud

The introduction of the New General Condition follows a long line of broader efforts by the UK government and Ofcom over the last several years to protect users from scams and fraud.

  • The UK government in 2025 imposed a ban on the possession and supply of SIM farms. Additionally, mobile operators have made commitments under the Fraud Sector Charter to secure trust in mobile messaging and prevent fraud.
  • Ofcom has issued guidance setting out measures it expects operators to take to comply with its rules, which make it harder for scammers to use UK telecom facilities, this includes:
    • Guidance to help operators identify and block numbers that are associated with trusted organisations, such as banks and public bodies, which are never intended to make outbound calls;
    • A good practice guide to help prevent misuse of sub-allocated and assigned numbers, which contains due diligence that UK operators should carry out when suballocating numbers to other providers;
    • Guidance on the provision of Calling Line Identification (CLI) facilities and other related services; and
    • Setting out the steps that operators are expected to take to identify calls from abroad that spoof UK landline Network Numbers and block them (where scammers ‘spoof’ their telephone number to disguise the origin of the call, or to make their call appear to be from a trusted person or organisation).

Background to the New General Condition and New Guidance

Ofcom published a call for input in 2024 to understand the effectiveness of industry developed methods to stop scam mobile messages, and to understand whether regulatory intervention would be necessary.

Ofcom subsequently consulted in 2025 on proposed new rules and guidance to combat mobile messaging scams.

Ofcom has now implemented rules as the New General Condition.

New General Condition

Ofcom notes that the New General Condition applies to two different mobile messaging channels:

  • Person-to-person (P2P) messages – which would be traditional messages sent between end users of mobile services, between two SIMs and between mobile networks.
  • Application-to-person (A2P) messages – which Ofcom regard as messages sent by A2P providers on behalf of other businesses. For example, appointment reminders, service updates or promotional messages.

Obligations applicable to P2P messaging providers

In relation to P2P messaging, the New General Condition will require mobile operators to:

  • Set volume limits for pay-as-you-go (PAYG) SIMs.
  • Block numbers that have been detected as being responsible for scams.
  • Have processes, policies and systems in place to receive scam reports from customers and third parties in relation to telephone numbers and web links (URLs) that are being used for scams.
  • Block scam messages in transit on their networks by identifying scam URLs and telephone numbers, taking into account the relevant scam reports they have received.

Obligations applicable to A2P messaging providers

In relation to A2P messaging, the New General Condition will require mobile operators and aggregators to:

  • Conduct due diligence and effective Know Your Customer (KYC) checks.
  • Prevent the use of fake alphanumeric sender IDs, including by verifying Sender IDs against information gathered through KYC checks and maintaining a policy on restricting the use of protected sender IDs.
  • Conduct ongoing Know Your Traffic (KYT) checks, including checking for indicators of scam activity and monitoring and reviewing data on volume patterns.
  • Apply incident management processes where scam activity is identified, to prevent scammers from sending messages and address any non-compliance by other providers.
  • Block scam messages in transit on their networks by detecting scam URLs and telephone numbers.
  • Have processes, policies and systems in place to receive scam reports from customers and third parties in relation to telephone numbers and URLs that have been used for scams (as required for P2P messaging).
  • Implement and maintain clear and unambiguous terms for the party from which they receive the A2P messages to either undertake the KYC, alphanumeric Sender ID and KYT checks or ensure these checks have been conducted.

Safeguard requirements applicable to P2P and A2P messaging providers

The New General Condition also imposes requirements on mobile operators and aggregators to ensure that the above requirements are effective and to minimise the risk that messages which are not scams are blocked, including requiring mobile operators and aggregators to:

  • Implement polices, systems and processes for mobile users to challenge a decision to block a number or message and ensure these are well publicised and readily available for mobile users to access;
  • Implement polices, systems and processes to identify, monitor and take appropriate action where messages have been wrongly blocked, where the provider had previously incorrectly believed, a message was intended to scam the relevant recipient;
  • Regularly review policies, systems and processes implemented to ensure their effectiveness and that they are operating as intended;
  • Train the appropriate staff on the relevant policies, systems and processes;
  • Implement and maintain appropriate record keeping policies, systems and processes; and
  • Ensure compliance with relevant data protection legislation in their activities in complying with the New General Condition.

Summary and next steps

  1. Coming into force: The New General Condition will come into effect from 2027; the requirements applicable to P2P messaging providers will come into effect on 18 January 2027, and those that apply to A2P messaging providers will come into effect on 15 July 2027.

    Many of the new General Conditions will require proactive compliance activity to be taken and technical processes to be put into place, to enable compliance. As such, mobile operators and A2P aggregators should assess Ofcom’s New General Condition closely, to ensure they are able to comply once the various requirements come into effect.
  2. Application: It is important to note that the obligations summarised above generally applies to Communications Providers who terminate/transfer P2P and A2P messages, with certain exceptions, including:
    • Certain obligations applicable to A2P messaging providers exclude lower tier aggregators (i.e aggregators who do not contract directly with a mobile service provider that directly terminates A2P messages to recipients).
    • Certain obligations in respect of P2P messaging providers, only apply to those who have assigned mobile numbers.

As such, mobile operators and A2P aggregators should review the New General Condition carefully to see which new obligations apply to their specific activities.


Hallmarks and hallmark moments

A piece of “family silver” often reveals its most important details on the underside. Tucked away on the back, there is often a row of small stamped symbols: a walking lion, a leopard’s head, or an anchor, a single letter in a particular typeface, and perhaps a maker’s initials – all of which appear to be decorative. To those who know the code, it is a complete provenance record – the metal is sterling, it was assayed in a particular location, it was tested in a particular year, and this is the person who made it.

Hallmarking is one of the oldest consumer-protection schemes. The English system has been running, in one form or another, for the better part of seven centuries. As a piece of the design, it is subtle. The mark is standardized, so that the same symbol means the same thing regardless of who struck it. It is difficult to forge, because striking it is controlled by an independent assay office. It survives ordinary handling and wear and tear. Notably, it is readable: not by everyone, but by anyone who cares to learn the code, and by every dealer, valuer, and assay office. A mark that survives but cannot be read is useless; as is a mark that can be read but rubs off the first time someone gives it a clean.

Although hallmarking is medieval, the problem it solves is modern: it closely parallels the challenges the European Union is seeking to address for artificial intelligence (AI).

The EU’s Code of Practice on Transparency of AI-Generated Content (Code) reflects a hallmarking scheme for synthetic content. The Code seeks to make the output of generative AI capable of being identified and understood – to give machines and people a reliable way to tell what was minted by a model and what was not, and to do so in a way that fosters trust in an increasingly complex information ecosystem.

The silver analogy applies: there is the assay office that strikes the mark (the provider of the AI system), the silversmith who sells the finished piece to the public (the deployer), and the shopper looking at the underside of the spoon (the end user trying to understand what they are looking at).

The Code is a substantial document, but its architecture reflects the hallmarking parallel. In this alert, we use that parallel to unpack the Code and its implications for businesses.

You can read the full article at What the EU’s new Code of Practice means for AI-generated content transparency | DLA Piper exploring:
– What is the Code?
– Timings and publication of the code?
– Key considerations for providers
– Detection, durability and interoperability
– What deployers must disclose
– From mark to chain of custody
– Foreseeability, and liability
– Next Steps

Artificial intelligence has quietly reshaped recruitment. From sourcing, screening to selection of candidates, AI tools promise speed and scale in an ever-globalised workforce landscape following the boom of remote work infrastructure. However, a recent intervention by a UK regulator has surfaced regulatory pressure on the vendors building these systems.

The Information Commissioner’s Office (ICO) has audited certain providers of AI-driven recruitment tools in the UK and, published a thorough report effectively setting out a rulebook for the sector: AI in Recruitment Outcomes Report. The audits are a reminder that, even before the EU AI Act enters into force, UK data protection law is already imposing rigorous standards on how these systems are designed and deployed.

There has largely been an illusion of “upstream neutrality” where vendors offering HR tools have long assumed they have a safe regulatory distance from hiring decisions. The ICO’s findings make clear that this assumption is increasingly untenable, particularly where AI models are trained, calibrated, and deployed centrally across multiple clients.

The first point to note is the clarity in the ICO’s statement that where a provider develops a central AI model used across clients, it is likely to be acting as a controller, with full responsibility for how personal data is used in training and development. The audits found repeated attempts by providers to classify themselves as processors and push obligations downstream, often through vague or incomplete contracts.

This controller status triggers the requirement to conduct a Data Protection Impact Assessment (DPIA) early in development and update it as processing changes. The ICO expects DPIAs to contain a substantive analysis of the trade-offs between privacy and competing interests, including: accuracy versus explainability (more data points improve output accuracy but make it harder to explain how the AI works); data minimisation versus statistical validity (more personal information improves accuracy but conflicts with the minimisation principle); and transparency versus understandability (granular technical detail may seem more transparent but impacts comprehension). The ICO also found many DPIAs lacked a detailed map of data flows through the AI system and did not consider alternative approaches that might use less personal information to achieve the same outcomes.

Controller status also brings obligations around individual rights. Providers must document and implement processes to handle individual rights requests, including how each right will be managed within the AI tool. The ICO further expects controllers to maintain records of processing activities (RoPA) based on regular data flow mapping, recording purpose, lawful basis, additional conditions for special category data, and data sharing arrangements.

Controller status matters. It triggers the full weight of UK GDPR obligations: lawful basis, transparency and fairness. It also materially increases exposure in the event of regulatory scrutiny or private claims. Where responsibility for model design, training, and outputs sits with the vendor, liability is less easily displaced through contractual drafting alone. For many providers, this is a significant structural issue if an operating model and compliance programme rests on assumptions that no longer hold true in the UK regulatory landscape.

I will draw out some of the key themes from the ICO’s report in part 1 of this series spotlight.

AI Bias: the problem providers thought they had solved

There is extensive discussion in the recruitment industry on “debiasing” AI, but the ICO’s findings show some of this work is not yet fully effective.

A key concern is the widespread use of inferred demographic data, for example, predicting ethnicity or gender from names. The regulator found such data is not accurate enough to monitor bias and may be unlawful where used without a valid basis and without informing candidates.

Moreover, the regulator observed bias monitoring was often narrow in scope, limited to gender, ethnicity and age. Many providers were unable to assess other protected characteristics under the Equality Act as they could not be reliably inferred. The ICO also found that not all providers had used sampling techniques to ensure datasets were diverse and representative of the relevant population, highlighting the need to maintain clean datasets free of demographic proxies that could introduce bias.

The result is a compliance paradox: systems may be failing to detect the bias they introduce. Worse still, the ICO found that some tools included features allowing recruiters to filter candidates in or out of suggested lists based on inferred demographics, a functionality unlikely to be fair or have an appropriate lawful basis.

A failure to ensure potential bias in AI is properly detected and addressed may result in potential discrimination claims arising under the Equality Act. Candidates may assert that their particular protected characteristic was a reason for a role not being offered to them. If bias in the AI system is subsequently discovered which meant candidates with particular protected characteristics were not being progressed through the recruitment process, this could potentially create a liability for such a claim. It also may shift the burden of explanation onto the organisation deploying the tool.

The ICO outlines an alternative in collecting demographic data directly from candidates, for example via optional surveys. This may be more accurate, but it requires a clear lawful basis and purpose limitation analysis, particularly where data is repurposed for bias monitoring.

AI Accuracy is not a sliding scale

A striking regulatory comment in the report concerns accuracy. Some providers had adopted a pragmatic threshold: if an AI tool was “better than random”, it was deemed good enough. The ICO rejects this outright. Where AI materially influences recruitment decisions, “better than random” is unlikely to comply with the law. Systems must be tested rigorously and must reach defined accuracy thresholds before processing personal data. From a risk perspective, organisations should also consider how those thresholds are evidenced and documented, particularly where outputs may later need to be defended in the context of a complaint, audit or claim.

Critically, the ICO also recommended that providers keep training and testing data separate. Where AI is trained with information and then tested with the same data, accuracy or bias issues may remain undetected until after launch. The regulator further suggests engaging cognitive behavioural and psychometric experts to regularly test and review AI logic, scoring, and outputs for potential accuracy or bias issues.

Transparency: privacy notices criticised

The ICO found many providers relying on generic, multi-purpose privacy policies, often covering multiple jurisdictions and processing activities. These were held to be insufficient.

The regulator’s expectation is clear:

  • Have a processing-specific candidate privacy notices
  • Include a clear explanation of AI logic, outputs and training uses
  • Disclose the lawful basis and retention periods
  • Supplement text-based privacy information with informative pop-up messages, bite-sized information at the point of processing, or visual aids such as data flow maps

Of particular note is the ICO’s stance on Article 14(5)(b), the “disproportionate effort” exemption. Several providers relied on this exemption when scraping data from public sources such as job platforms. The ICO was not persuaded, signalling a materially narrower interpretation of the exemption in practice. This has direct implications for large-scale data sourcing strategies which rely on passive transparency and may now carry increased regulatory risk if not revisited.

Where providers held names and contact details, they could not justify why notifying individuals would be disproportionate. Simply publishing a website privacy policy was not enough. Individuals must be actively informed, typically within one month of collection. This is a significant tightening of practice and large-scale sourcing models built on passive transparency should be reviewed.

Human oversight: present, but not always meaningful

AI vendors routinely emphasise “human-in-the-loop” safeguards. The ICO’s findings suggest these controls are often superficial in practice.

Most tools were designed to support, rather than replace, human decision-making. Yet:

  • human review processes were not always formalised and reviewers were not consistently trained
  • feedback loops were weak or undocumented i.e. in some cases, providers relied on recruiters to flag errors but without clear mechanisms to do so, or evidence that issues were addressed.

The result is a familiar compliance gap: human oversight exists in theory, but often operates as a control of form rather than substance, providing limited mitigation in practice. Such a gap in a recruitment process may have several unintended consequences and therefore risks. For example, there may be a failure to identify and support candidates with disabilities who require certain adjustments to be made in order to remove any disadvantage they may be experiencing in the recruitment process.

Data hunger and purpose creep

AI systems require large volumes of data. In parallel, data protection law constrains that with data minimisation a core UK GDPR principle.

The ICO found extensive use of scraped data from public profiles, often combined at scale and reused for training and product development. In many cases, providers could not demonstrate that these secondary uses were compatible with the original purpose of collection. The regulator was particularly critical where providers had no contracts with source sites confirming information was collected lawfully, and could not show the new use was compatible with the original purpose.

Retention practices were equally problematic. Some providers maintained candidate databases indefinitely “just in case”, or reset retention periods with each update effectively creating permanent records.  

Against this, the ICO emphasises a more restrictive model:

  • define a minimum data set (often limited to core CV data)
  • use pseudonymisation or aggregated data where possible
  • adopt techniques such as k-fold cross-validation to reduce data volume without sacrificing accuracy
  • limit collection to defined parameters, for example up to 10 years of job experience, and collect demographic information optionally and exclusively for bias monitoring purposes

If a provider’s growth strategy is built on accumulating ever-larger datasets, this challenge should be noted.

Providers should also note that where they rely on legitimate interests as a lawful basis, a legitimate interests assessment (LIA) must be conducted and documented which will consider some of these issues.

A related and emerging issue is the downstream impact of AI-assisted working practices within organisations themselves. In enforcement and contentious contexts, we are increasingly seeing internal use of generative AI tools giving rise to large volumes of additional personal data, including inferred or speculative content, which must then be captured and reviewed in response to data subject access requests. This creates both operational strain and a heightened risk profile, particularly where the content reflects inappropriate or unverified assumptions about individuals. Organisations should ensure that internal AI usage policies and training are aligned with their data protection obligations in this regard.

Security: complex AI systems, expanding risks

While the audits found generally strong technical controls, encryption, monitoring and segregated environments, the report also highlights the increasing complexity of AI systems. These tools involve multiple integrations, cloud infrastructures and third-party processors, creating a broader attack surface and more complex data flows.

At the same time, weaknesses persisted: (a) inconsistent access management, (b) insufficient review of audit logs; and (c) unclear processes for internal role changes. The lesson is that AI security risks are not wholly “novel”, but they are materially amplified by scale, integration, and data sensitivity, increasing both the likelihood and impact of failures across interconnected systems. In particular, reliance on third-party integrations and evolving model architectures can make root cause analysis and incident containment more complex in practice and therefore more prone to error. This should be explored in detail in the DPIA.

The coming convergence

Overall, the ICO’s audit reads like preparatory enforcement if the expectations are not met. The message for providers is that compliance cannot be bolted on. It must be designed into AI systems from the outset, spanning data sourcing, model training, governance and user interaction. Some organisations are taking a “wait and see” approach to high-risk AI systems in the recruitment space caught by the EU AI Act in light of the Omnibus proposals. However, the UK intervention report is grounded in current data protection principles which already apply.

For providers, the ICO’s findings translate into a set  of immediate, actionable priorities: review controller/processor classification with legal counsel; conduct or update DPIAs with documented trade-off analysis and detailed data flow mapping; separate training and testing datasets; engage external experts (psychometric, cognitive behavioural) for ongoing validation; revise privacy notices to be UK-specific and candidate-focused with layered transparency mechanisms; conduct LIAs where relying on legitimate interests; implement processes for handling individual rights requests and maintain a comprehensive RoPA; review data scraping practices and purpose compatibility; implement defined retention limits; and test breach response processes through periodic desktop simulations.

Part two will examine how the EU AI Act sharpens these obligations, and what it means for providers operating across both regimes – in addition to what employers/deployers should consider when using this tools from a contractual and compliance perspective.

On 12 May, Ofcom launched a consultation on proposed updates to its General statement of policy under section 105Y of the Communications Act 2003 (the “Statement of Policy”) in respect of how it will assess compliance by public telecommunications operators with their security obligations under the UK telecommunications security regulatory regime (see Background below for further details). The consultation closes on 4 August 2026, with a final statement expected later this year.

In parallel, the UK government has published proposed revisions to the Telecommunications Security Code of Practice 2022 following consultation with the industry, Ofcom and other stakeholders (“Revised Code“).

This article provides a summary of the proposed changes to Ofcom’s Statement of Policy and the key updates to the Revised Code.

Background of telecommunications security

In 2021, the UK government made major changes to the regulation of the security of public telecommunications networks and services. As part of the changes, regulation shifted from an operator-led approach, where operators would determine “appropriate and proportionate” measures to secure their networks and services, to a regime where such measures are set out on a prescriptive basis under regulation and codes of practice.

These changes were brought into effect through the Telecommunications (Security) Act 2021 (which amended the Communications Act 2003), the Electronic Communications (Security Measures) Regulations 2022, and the Telecommunications Security Code of Practice 2022 (together, the “Security Instruments“).

Ofcom Statement of Policy

Under this new regime, Ofcom plays a role in supervising, and enforcing, compliance by operators with their security duties under the Security Instruments.

Section 105Y of the Communications Act 2003 requires Ofcom to publish a statement explaining how it will exercise such supervisory and enforcement functions in relation to telecoms security duties. We previously wrote about Ofcom’s Statement of Policy here.

The Statement of Policy is procedural rather than substantive: it does not impose new obligations on providers but sets out:

  • how Ofcom monitors compliance;
  • how it exercises enforcement powers; and
  • what types of “security compromises” must be reported, and how.

Telecommunications Security Code of Practice

Under the Security Instruments, the Telecommunications Security Code of Practice 2022 provides detailed guidance from the UK government as to how it expects telecom operators to comply with the broader obligations in the Telecommunications (Security) Act 2021 and the Electronic Communications (Security Measures) Regulations 2022.

What is changing?

Ofcom Statement of Policy

The proposed updates reflect Ofcom’s evolving approach to its supervisory and enforcement role, more than three years since the introduction of the Security Instruments, and are primarily aimed at improving the consistency, clarity and usefulness of incident reporting, while refining its supervisory approach.

Below, we provide a summary of some of the key changes proposed by Ofcom.

1. Standardisation of incident reporting thresholds

One of the key proposed changes is the introduction of standard thresholds for incident reporting.

In particular:

  • A move away from bespoke thresholds per MNO to a standard threshold for all MNOs: Ofcom proposes to remove operator-specific thresholds, and replace them with a universal standard threshold for all MNOs.

The Ofcom proposal is that for all MNOs, a security compromise that affects  ≥100,000 customers for any duration, and compromises affecting ≥10,000 or ≥25% of customers where the duration is for ≥8 hours, must be reported.

  • Introduction of infrastructure-based thresholds for MNOs: due to the difficulty of assessing mobile customers affected by a security compromise, Ofcom proposes to introduce a threshold based on the number of cell sites affected, and for there to be a specific threshold for rural areas.

This includes reporting of security compromises affecting ≥25 cell sites for ≥2 hours; ≥150 cell sites for any duration of time; or ≥1 rural cell site for ≥8 hours.

2. Clarification on what to report

Ofcom is proposing to clarify that incidents having a significant effect on the operation of a network or service in scope will remain reportable even if they do not meet the Ofcom criteria or thresholds. This means operators cannot rely solely on Ofcom’s reporting criteria and must still consider this catch-all reporting obligation when assessing security compromises.

3. Evolution to Ofcom’s approach to compliance monitoring

Beyond reporting, the consultation signals a shift in how Ofcom intends to exercise its broader powers. In particular, Ofcom suggests that it will begin to use assessment notices on a more standard basis as part of its compliance monitoring activities.

Originally, Ofcom would primarily use information notices which simply request information from an operator. Assessment notices were to act as the next escalation step in the enforcement process, and to permit Ofcom to direct operators to take specific action or perform specific tests. 

The change is intended to reduce the burden on operators, and provide for greater efficiency, as this permits Ofcom more directly to assess non-compliance, rather than proceed through a two-step process of seeking general information through an information notice, and then more specific information and action through an assessment notice to verify matters identified through facts gathered through an information notice.

Telecommunications Security Code of Practice

Why is the 2022 Code changing?

Since the original 2022 Code, different threats have emerged and new technologies have developed, which were not addressed in the 2022 Code.

The UK government is revising the 2022 Code following security advice from the National Cyber Security Centre (NCSC), and to reflect the need for the 2022 Code to remain up to date to achieve its purpose of establishing measures for how operators can comply with their obligations under the Security Instruments.

Key changes to the 2022 Code

The Revised Code introduces additional guidance and targeted updates in key areas, including:

  • network automation, aligning with National Cyber Security Centre (NCSC) guidance, including secure principles for machine learning;
  • signalling, which is noted to address continued targeting of signalling systems by cyber threat actors and reflect industry feedback;
  • privileged access workstations, including updates to align with European Telecommunications Standards Institute (ETSI) standards;
  • application programming interfaces (APIs), reflecting their increased use and associated security risks, including data loss; and
  • patching and updates, to mitigate risks associated with threats such as non-persistent malware.

Key takeaways for communications providers

Public telecommunication operators who are caught under the Security Instruments will need to carefully review the updates proposed by Ofcom and the new requirements in the Revised Code. This is because these instruments require proactive action by operators in their day-to-day management of the security of their telecommunications networks and the structuring of compliance functions.

In particular:

  1. Ofcom’s proposed updates will change criteria and triggers for reporting security compromises, as well as replace existing reporting templates. Operators should review any internal processes established to comply with the original Ofcom Statement of Policy, and update these accordingly once Ofcom has published its final decision to ensure ongoing compliance.
  • The UK government’s Revised Code presents updated expectations for how telecommunications networks will be secured in respect of updated threats and technologies. Operators should assess whether these updates apply to their networks and the way they are deployed, and assess if they can become/are compliant with the revised procedural guidance.

As these documents form part of the broader regulation under the Security Instruments, telecommunications operators should consider both documents together and assess the combined impact on their operational and compliance frameworks, including incident reporting processes, technical controls, and internal governance arrangements. Early engagement may help identify implementation challenges and inform any response to Ofcom.

Next Steps

Stakeholders have until 4 August 2026 to respond to the Ofcom consultation.

The Revised Code has already been subject to a consultation process, and the UK government has now indicated that the Revised Code will be finalised and laid before Parliament.

On 10 June 2026, the Italian Council of Ministers approved, at a preliminary stage, two draft legislative decrees on artificial intelligence.

The first draft concerns the powers of national authorities, supervision, sanctions, testing environments and training, and also contains provisions relating to employment.

The second draft regulates the use of artificial intelligence systems in policing and introduces provisions on civil and criminal liability.

It should be made clear from the outset that these are not yet final texts. The drafts have been approved at a preliminary stage and must complete the required procedure, with possible amendments before final approval and publication in the Official Gazette.

This initiative falls within the framework of Law No. 132 of 23 September 2025, which sets out provisions and delegates powers to the Government regarding artificial intelligence, and of EU Regulation 2024/1689, namely the AI Act. The rationale is to align the national legal system with the European framework, not to create a parallel or alternative Italian regime.

Executive summary

The package approved by the Government confirms that Italian AI regulation is entering a more operational phase.

The most significant areas are:

  • national governance of the AI Act, with a central role for AgID and ACN;
  • supervision, inspection powers and sanctions;
  • sandboxes and regulatory experimentation;
  • AI in work processes and in decisions affecting workers;
  • training and AI literacy;
  • use of AI by the police, with specific regulations for biometrics and facial recognition;
  • civil liability, access to evidence and presumption of causation;
  • criminal liability and potential impact on 231 models; and
  • protection of data, algorithms and training methods as trade secrets, where the conditions apply.

AI is not treated as an isolated technology, but as an organisational and decision-making infrastructure requiring governance, documentation, controls, internal accountability and appropriate contracts.

1. National governance: AgID, ACN and sectoral authorities

According to the first draft decree, the national authorities for artificial intelligence are AgID and ACN.

AgID acts as the national notification authority, with powers relating to notification procedures and conformity assessment bodies. ACN, on the other hand, plays a central role in market surveillance for AI systems and is designated as the single point of contact.

The role of sectoral authorities remains unchanged, particularly in the banking, financial and insurance sectors. The draft decree identifies the Bank of Italy, CONSOB and IVASS as the competent authorities in their respective fields, in addition to the Data Protection Authority within the limits of its relevant remit.

For regulated firms, this is a key point. AI compliance will not be merely an internal policy matter, nor solely a privacy issue. Depending on the circumstances, it may involve ACN, AgID, the Data Protection Authority, the Bank of Italy, IVASS, CONSOB and other competent authorities.

2. Sanctions: alignment with the AI Act, but with a national framework

The first draft decree provides for a structured system of sanctions, coordinated with the AI Act.

For the most serious violations, relating to practices prohibited by Article 5 of the AI Act, the penalty may reach up to €35 million or, if higher, up to 7% of the total annual global turnover of the previous financial year. Lower thresholds are also provided for other categories of obligations, including those of providers, deployers, notified bodies, transparency and reporting to the authorities.

The penalty figure is significant, but it is not the most important aspect. The real issue for businesses will be the ability to demonstrate an effective control system: classification of AI systems, AI Act roles, technical documentation, logging, human oversight, risk management, incident management, post-deployment monitoring and change control.

Looking ahead, organisations will need to be able to demonstrate not only that they have ‘an AI policy’, but that they have verifiable processes for acquiring, developing, using, modifying and decommissioning AI systems.

3. Work: an end to exclusively automated decisions

One of the most significant aspects concerns employment.

The first draft decree stipulates that, in decision-making processes concerning the employment relationship, employers using AI systems must ensure that decisions relating to the establishment, modification or termination of the relationship, including disciplinary measures, are not taken solely on the basis of automated processing.

The final decision must be reserved for a natural person exercising effective and independent authority.

The employee would also be entitled, upon request and through human intervention, to receive a comprehensible explanation of the decision, including an indication of any impact the AI system had on the decision-making process and the main parameters considered. The draft also provides for the nullity of any dismissal issued in breach of the prohibition on exclusively automated decisions.

This may affect recruitment systems, candidate screening, workforce management, performance management, internal scoring, automated scheduling, people analytics, disciplinary systems and tools for monitoring or assessing productivity.

The issue will not be merely formal. It will not suffice to state that ‘the final decision is human’ if, in practice, the system’s output substantially determines or influences the decision. Companies will have to document the role of human intervention, the possibility of challenging the decision, the main decision-making logic, anti-discrimination safeguards and information obligations.

4. Health and safety at work

The first draft decree also introduces an explicit link between AI and health and safety in the workplace.

The use of AI systems that affect the organisation of work, production rates, the manner in which work is performed, or decision-making processes relevant to safety should be assessed as part of the risk assessment under Legislative Decree 81/2008.

Employers should also ensure that information and training are provided on the specific risks associated with the use of AI systems and on the prevention and protection measures adopted.

This profile may be particularly relevant for logistics, manufacturing, retail, digital platforms, healthcare, financial services, contact centres and organisations that use AI tools to optimise shifts, workloads, operational priorities or performance monitoring.

5. Training, AI literacy, universities, professions and the public administration

The first draft decree devotes a significant section to training. Measures are envisaged for schools, teacher training, adult literacy, professional retraining, public administration, universities, research bodies, AFAM, ITS Academy, the administration of justice, professions and healthcare.

These provisions reflect Article 4 of the AI Act, which require providers and deployers to take measures to ensure a sufficient level of AI literacy among staff and other persons operating or using AI systems on their behalf.

Training should therefore not be treated as a generic course on AI. It will need to be tailored to specific roles: board and management, legal, compliance, privacy, risk, procurement, HR, IT, cybersecurity, data science, business owners and end users.

The content must vary depending on the type of AI system used, the level of risk, the business process involved and the people affected by the outputs.

6. Police, biometrics and facial recognition

The second draft decree governs the use of AI by the police.

The approach is to permit the use of AI systems as support tools, with qualified human oversight, traceability and respect for fundamental rights. For high-risk systems, human oversight must be effective and compliant with the AI Act.

The most sensitive provision concerns real-time remote biometric identification in public places or places open to the public. The decree permits this only for limited purposes, such as preventing specific threats or searching for missing persons or victims of certain crimes.

Biometric matching must be carried out against appropriate reference databases, and the decree prohibits the use of biometric databases populated, in whole or in part, through non-targeted scraping or created in breach of data protection legislation.

Procedural, temporal and territorial limits are provided for. Authorisation must relate to a specific event or the time strictly necessary, in any case not exceeding fifteen days, with possible justified extensions.

In the event of non-compliance with the conditions, use must be discontinued, the data and outputs must be deleted, and the results may not be used.

In criminal proceedings, the framework provides for the involvement of the public prosecutor and the judge for preliminary investigations. The public prosecutor requests authorisation from the judge for preliminary investigations, who issues a reasoned decree; emergency procedures with subsequent validation are provided for.

For technology providers, this is not merely a public sector issue. Those who develop or supply biometric solutions, video analytics, identity verification, cybersecurity, law enforcement technology or data analytics platforms must carefully assess the intended purpose, context of use, contractual limitations, audits, logging, accountability and prohibited use clauses.

7. Criminal liability and 231 models

The second draft decree introduces a new criminal offence relating to the failure to adopt security measures in AI systems and the unlawful alteration of systems.

The offence concerns, in particular, high-risk AI systems and conduct such as design, training, production, placing on the market or professional use in the absence of appropriate technical measures to prevent malfunctions or alterations, or in the absence of human supervision, where this results in a concrete danger to life, personal safety, public safety or national security.

The draft also provides for the inclusion in Legislative Decree 231/2001 of offences related to the use of AI systems, including the new Article 437-bis of the Criminal Code; the draft also refers to Article 612-quater of the Criminal Code, which will be assessed separately in the final text.

This is a point of great significance for businesses. If confirmed in the final text, AI governance could also become a 231 issue, at least for organisations that develop, train, place on the market or professionally use high-risk AI systems.

Organisational models should therefore include safeguards regarding security, human oversight, change control, testing, logging, incident management and the traceability of technical decisions.

8. Civil liability: access to evidence and presumption of causation

In civil matters, the second draft decree does not appear to introduce a generalised strict liability regime for AI.

The approach taken is different: strengthening the injured party’s means of proof, access to relevant documentation, and a relative presumption of causation in the event of a breach of obligations under the AI Act.

In particular, the court may order the production of evidence relating to the operation of the AI system, including logs, risk management system documentation, technical documentation and information regarding parameters and methods of human supervision.

The framework also provides safeguards for trade secrets and confidential information.

There is also a presumption of a causal link where the harm results from a breach of one or more obligations under the AI Act, subject to proof to the contrary. The AI system’s compliance with the obligations of the AI Act, even if certified, does not in itself exclude the defendant’s liability.

For businesses, this reinforces the importance of documentation. The practical question becomes: in the event of a dispute, are we able to produce logs, risk assessments, technical documentation, user instructions, evidence of human oversight, tests, change logs and governance decisions?

9. Insurance and direct action

The second draft decree also contains provisions on direct action against an insurance company.

Anyone intending to bring a claim for compensation could ask the party deemed liable whether there is insurance cover for civil liability relating to the damage. If cover exists, the injured party would have a direct claim against the insurer up to the limit of the policy.

This aspect is relevant not only for litigation but also for the structuring of insurance programmes. Companies should verify whether and how AI risks are covered by cyber, professional indemnity, product liability, D&O, E&O or other policies, and whether there are specific exclusions relating to algorithms, models, automated outputs, high-risk systems or non-compliant use.

10. Data, algorithms and training methods as trade secrets

A particularly interesting aspect for technology companies, developers, AI providers and industrial groups is the provision relating to the Industrial Property Code.

The second draft decree provides that, among the business information and technical-industrial know-how eligible for protection as trade secrets, data, algorithms and mathematical methods for training AI systems may also be included, provided the legal requirements are met.

In particular, this refers to model architectures, optimisation functions, training procedures and configurations, and other technical and computational elements instrumental to the development of AI systems.

If confirmed, this provision could have significant implications for AI development contracts, licensing, technology outsourcing, research partnerships, joint development, data sharing, procurement and M&A due diligence.

Protection will not be automatic: the standard requirements for trade secrets will still apply, including confidentiality, the economic value derived from confidentiality, and the adoption of reasonable measures to maintain it.

11. Operational implications for businesses

Even before final approval, businesses should start working on certain priority areas.

The first is mapping AI systems. Many organisations do not yet have a reliable inventory of the AI systems in use, including tools embedded in third-party software, HR platforms, CRM, cybersecurity, analytics, procurement, document automation, customer service and generative tools used by employees.

The second is the classification of systems. A distinction must be made between prohibited practices, high-risk systems, systems subject to transparency obligations, general-purpose AI and tools with lower risk. This classification must be documented and updated over time.

The third is technology procurement. AI contracts should not be treated as standard software or SaaS contracts. Clauses are required covering the role of the AI Act, intended purpose, technical documentation, user instructions, data, output, IP, logging, audits, cybersecurity, incident management, system modification, retraining, fine-tuning, subcontractors, cooperation with authorities and allocation of liability.

The fourth is internal governance. Legal, compliance, privacy, cyber, procurement, HR, risk, IT and business owners must have clearly defined roles. AI governance cannot be left solely to IT or the innovation function.

The fifth is the workplace. Tools affecting recruitment, assessment, performance, disciplinary measures, dismissal, work organisation or safety must be subject to a specific review.

The sixth is evidential documentation. Future AI risk management will also depend on the ability to produce evidence: logs, risk assessments, tests, validations, human oversight, instructions, data checks, change logs, incident reports and governance decisions.

The seventh is training. AI literacy must be practical, tailored to specific roles and linked to the systems actually used by the organisation.

Conclusion

The Government has launched the national implementation phase of the AI Act. The decrees are not yet final, but they clearly indicate the direction of Italian regulation: AI must be governed through an integrated system of compliance, cybersecurity, data protection, supplier oversight, internal accountability, training, documentation and traceability.

For businesses, the issue is not merely ‘being compliant’ when the decrees come into force. The issue is being prepared, including knowing where AI is used, by whom, with which suppliers, in which processes, with what data, with what impact on people, with what human supervision, with what documentary evidence and with what contractual allocation of responsibilities.

For more information on AI and its effects across the globe, you can view our new campaign Algorithm to Advantage – making AI clarity your competitive advantage.

Quantum computing is poised to profoundly reshape the cybersecurity landscape, with significant legal and regulatory implications. By introducing fundamentally different computational methods, enabling the simultaneous processing of multiple possibilities, quantum computing has the potential to undermine and ultimately render many traditional encryption techniques ineffective. The result is a significant systemic risk across critical infrastructures, including financial systems, communications networks, and digital identity frameworks. The risk is not theoretical: threat actors are already “harvesting” encrypted data with a view to decrypting it once quantum capabilities mature.

Regulators are signalling that organisations cannot afford to wait. With expectations shifting toward quantum‑resilient security, businesses that fail to assess and plan for the transition could face significant enforcement, reputational damage, and litigation risk. As quantum computing converges with AI to accelerate cyber threats, the message is clear: quantum readiness is no longer a future concern—it is a present-day priority. Key steps include identifying and prioritising cryptographic assets, building quantum resistant measures into technology environments, embedding quantum risk into governance and risk assessments, and planning for a structured transition to quantum‑resistant standards. Early action will be critical to maintaining compliance and resilience as the threat landscape evolves.

Our full article – a review of the legal implications of quantum computing and its ability to overcome current cryptography methods – is available on our Algorithm to Advantage insights page.

The KRITIS Umbrella Act (Dachgesetz zur Stärkung der physischen Resilienz kritischer Anlagen – KRITISDachG) has been in effect since March 17, 2026. For operators of critical infrastructure in Germany, this means: new obligations, tight deadlines, and hefty fines require swift action. For the first time, the law establishes a cross-sector legal framework to strengthen physical resilience and applies to operators of critical facilities across ten sectors – ranging from telecommunications, energy, and transportation to healthcare and space. In this article, you’ll learn who is affected, what obligations exist, how regulatory responsibilities are distributed, and what penalties apply for violations.

  1. The five most important takeaways for your company
  • The registration requirement takes effect on July 17, 2026 – affected operators must register with the Federal Office of Civil Protection and Disaster Assistance (Bundesamt für Bevölkerungsschutz und Katastrophenhilfe – BBK)/Federal Office for Information Security (Bundesamt für Sicherheit in der Informationstechnik – BSI) within three months of being identified as a critical infrastructure. Attention: Immediate action required – those who fail to act now risk fines.
  • Broad scope of application: The law addresses operators of critical infrastructure in ten sectors.
  • Comprehensive operator obligations: The list of obligations follows a comprehensive all-hazards approach.
  • Significant risk of fines: Violations of key operator obligations may result in fines of up to EUR 1,000,000.
  • Personal responsibility of management: Management is personally responsible for approving and monitoring resilience measures (Sec. 20 KRITISDachG).
  • Background and Objectives of the KRITISDachG

The KRITISDachG serves to implement the CER Directive on the resilience of critical entities (Directive (EU) 2022/2557). The objective is to ensure the maintenance of key economic and societal functions in the event of natural disasters, technical failures, sabotage, or other hybrid threats, specifically through cross-sectoral minimum standards for the physical protection of critical infrastructure. It thus supplements existing regulations on IT security – particularly the amended national BSI Act (BSIG) as the central implementing instrument of the NIS2 Directive (Directive (EU) 2022/2555) – with a physical component.

  • Sectors Affected

The law applies to operators of critical facilities, i.e., natural or legal persons as well as other organizational units that have a decisive influence on facilities that are essential for the provision of critical services (see Sec. 2 nos. 1 – 4 KRITISDachG).

The law defines ten sectors in Sec. 4 (1) KRITISDachG: information technology and telecommunications, energy, transport and traffic, finance, social security services and basic income support for job seekers, healthcare, water, food, space, and municipal waste management.

Which services are to be classified as critical within the individual sectors and the criteria according to which facilities are considered significant for the provision of critical services will be determined separately by a statutory ordinance issued by the Federal Ministry of the Interior (Bundesministerium des Innern – BMI) (Sec. 4 (3) and 5 (1) KRITISDachG). Facilities that meet these criteria are considered critical facilities.

“Criticality” is therefore presumed to exist if a facility is necessary to provide a critical service and exceeds a threshold value specified in the statutory ordinance (Sec. 5 (1) sentence 1 no. 2 KRITISDachG). The threshold is determined based on the population to be served, with a population of 500,000 generally serving as the basis (Sec. 5 (2) sentence 2 KRITISDachG).

A state-level exemption clause allows the federal states to classify regionally significant facilities below the threshold as critical (Sec. 5 (7) KRITISDachG) – such as a hospital indispensable to the region or a water supply system.

Affected companies typically include energy suppliers, telecommunications providers, network operators, municipal utilities, airports, ports, and railway hubs, hospitals and pharmaceutical companies, water suppliers, data centers, and large food producers and logistics providers.

Federal government agencies that perform exclusively national security, defense, or law enforcement functions are largely exempt (Sec. 7 (1) no. 2 and (2) sentence 2 KRITISDachG).

  • Key Obligations and Sector Exemptions

A defining feature of the new legal framework is a multi-tiered resilience system that links government risk analyses with comprehensive operator obligations. In doing so, the law adopts a so-called all-hazards approach: every risk – from natural disasters to sabotage and terrorist attacks to human error – must be included in the risk analysis.  

An overview of the core provisions:

  • Cross-sectoral risk analyses by federal and state ministries for critical services (Sec. 11 KRITISDachG),
  • Registration with the BBK/BSI within three months of identification as a critical facility, no earlier than July 17, 2026 (Sec. 8 (1) KRITISDachG),
  • Risk analysis (Sec. 12 KRITISDachG) for the first time no later than nine months after registration (Sec. 8 (7) KRITISDachG), thereafter as needed, but at least every four years,
  • Resilience measures and resilience plan (Sec. 13 KRITISDachG) for the first time no later than ten months after registration (Sec. 8 (7) KRITISDachG), including emergency response teams, physical security, access controls, emergency power supply, and staff training,  
  • Reporting obligations: Upon request, evidence of compliance with these obligations must be provided (Sec. 16 KRITISDachG), and incidents must be reported immediately, no later than 24 hours after becoming known (Sec. 18 (1) KRITISDachG),
  • Personal responsibility of management for approving and monitoring resilience measures (Sec. 20 KRITISDachG).

The core of these requirements consists of resilience obligations under Sec. 13 KRITISDachG. To specify these obligations, the BMI may establish cross-sectoral minimum requirements (Sec. 14 (1) KRITISDachG). In addition, operators or their industry associations have the option of proposing industry-specific resilience standards (Sec. 14 (2) KRITISDachG). Sector-specific requirements issued by federal ministries or state governments are only permissible on a subsidiary basis and in agreement with the BMI (Sec. 14 (3) and (4) KRITISDachG). The provisions on sector-specific requirements will not take effect until January 1, 2030, in order to give priority to the development of industry-specific standards (see Sec. 14 (2) KRITISDachG).

Furthermore, the law provides for sector-specific exemptions to avoid double regulation (Sec. 4 (2) nos. 1 – 3 KRITISDachG):

  • These apply to operators in the financial sector who are already subject to the Digital Operational Resilience Act (DORA) (Regulation (EU) 2022/2554), as well as operators in the IT and telecommunications sector for whom a resilience and security regime exists under the NIS2 Directive and its national implementation in the BSIG. In these areas, key operator obligations – such as risk analysis and risk assessment (Sec. 12 KRITISDachG), ensuring resilience (Sec. 13 KRITISDachG), and providing evidence (Sec. 16 KRITISDachG) – are exempted, while the registration requirement (Sec. 8 KRITISDachG) and provisions regarding national risk analyses and assessments (Sec. 11 KRITISDachG) continue to apply.
  • Similar exemptions apply to operators of critical facilities in municipal waste management and in the social security/basic income support sector, although risk analysis and assessment obligations (Sec. 12 KRITISDachG) expressly remain in effect.
  • Penalties for Violations

Violations of key operator obligations may result in fines of up to EUR 1,000,000 as well as administrative orders. The graduated fine scale depends on the nature and severity of the violation. It has been increased from a maximum of EUR 500,000 to EUR 1,000,000 compared to the government draft (as of November 2025).

If managers violate their duty to approve the specific resilience measures to be taken pursuant to Sec. 13 (1) KRITISDachG as appropriate and to continuously monitor their implementation (Sec. 20 (1) KRITISDachG), they are liable to their organization for damages caused through negligence (Sec. 20 (2) KRITISDachG); the governing body remains ultimately responsible.

  • Competencies of the Authorities

Responsibility for critical services lies with different federal (Sec. 3 (2) nos. 1 – 12 KRITISDachG) or state authorities (Sec. 3 (6) KRITISDachG), depending on the sector, such as the BMI (for critical services provided by federal administrative bodies) and the Federal Network Agency (Bundesnetzagentur – BNetzA) (e.g., for critical telecommunications services).

The central contact point for ensuring cross-border cooperation with contact points in other Member States (Art. 9 (2) CER Directive) is the BBK, Sec. 3 (1) KRITISDachG.

The BBK is the competent authority for imposing administrative fines for violations of registration requirements; in all other cases, the competent (sector-specific) authority pursuant to Sec. 3 (2) sentence 1 KRITISDachG (Sec. 24 (3) KRITISDachG) is responsible.

  • Conclusion and Outlook

With the KRITISDachG, the national legislature supplements existing resilience requirements – which until now have been primarily focused on cyber and information security – with physical security requirements. Within the framework of a risk-based “all-hazards approach,” the KRITISDachG establishes continuous and comprehensive resilience management for operators; at the same time, sector-specific exemptions consider the goal of avoiding double regulation.

Even though critical services, resilience obligations, and minimum standards are yet to be specified by statutory ordinance (upon whose entry into force the previously applicable BSI-Kritisverordnung will be repealed), it is advisable for the affected sectors to review the new legal requirements at an early stage, especially since the KRITISDachG provides for substantial fines for violations.

Organisations increasingly use AI-enabled tools throughout the recruitment process. These tools screen CVs, score suitability, run online assessments, and analyse behaviour. They can speed up hiring and may help reduce the human bias found in traditional recruitment. However, their use often clashes with data protection rules that limit decisions based only on automated processing. On 31 March 2026, the Information Commissioner’s Office (ICO) published a report and draft guidance on automated decision-making in recruitment. The report draws on evidence from more than 30 employers. It also includes public perception research reflecting views from graduates, civil society, government, trade unions, and industry bodies.

A key finding is that many employers fail to recognise that they are using automated decision-making (ADM). As a result, they do not put essential safeguards in place. These safeguards include transparency, bias monitoring, accountability, and respect for data subject rights. The ICO’s message is clear. Employers must follow the guidance. Where organisations fall short, the ICO signals that enforcement action may follow.

Summary of the ICO’s Key Findings

Most employers told the ICO that they use automated tools only for decision support. In practice, however, the evidence showed that many tools make decisions without meaningful human involvement. The ICO stresses that human involvement must be active and genuine. It cannot be a token step or a rubber-stamping exercise.

A human must be able to influence the decision before it takes effect. They must have the authority, discretion, and competence to change the outcome. If this standard is not met, the process counts as solely automated. This remains true even if a person appears in the decision chain.

The Impact of the Data (Use and Access) Act

The new Data (Use and Access) Act (DUAA) offers greater flexibility for employers using automated tools in recruitment. Under Article 22 of the UK GDPR, the law treated automated decision-making as largely prohibited, with narrow exceptions. The DUAA reframes this position. It creates a right to challenge automated decisions, supported by safeguards, rather than a general ban.

This change gives employers more scope to use automation, provided they put proper protections in place. Where special category data is involved, however, the stricter rules still apply.

Two Routes for Employers from the ICO

The ICO sets out two options for employers:

  1. Acknowledge solely automated decision-making.
    Employers can accept that the process lacks meaningful human involvement. They must then recognise that they are carrying out ADM and apply the required safeguards.
  2. Ensure meaningful human involvement.
    Employers can redesign their processes so a human plays a genuine role in each decision for each candidate.

This second option sets a high bar. For organisations handling large volumes of applications, it will often prove impractical. In reality, many employers will need to follow the first route.

The ICO’s Required Steps Where Decisions Are Solely Automated

Where employers rely on solely automated decision-making, the ICO expects them to take several steps.

First, employers must identify a lawful basis for processing. The DUAA removes the previous limitation to consent or contractual necessity in recruitment, provided no special category data is involved. Employers may now rely on legitimate interests.

Second, employers must provide clear and timely transparency. They must explain how the automated decision works and its likely effects. A brief mention hidden in a general privacy notice will not be sufficient.

Third, employers must implement safeguards. Candidates must know about the automated process. They must have the chance to make representations, request human review, and challenge the decision.

Fourth, employers should carry out fairness testing and bias reviews. This includes questioning vendors about their own bias testing during procurement. Employers should also run trials, monitor outcomes over time, and share clear information about the tools’ accuracy and performance.

Finally, employers must complete data protection impact assessments (DPIAs). The ICO found that many existing DPIAs lack the detail needed to meet legal requirements.

What This Means for Organisations

Organisations should review their use of AI in recruitment. They should assess whether processes involve solely automated decision-making. This is particularly relevant where CV filtering, suitability scoring, or behavioural assessments play a role.

DLA Piper works closely with clients to support compliant use of ADM in recruitment. This work includes developing due diligence processes to assess fairness and bias in vendor tools. It also includes drafting transparency information that meets the ICO’s expectations at each stage of recruitment and preparing detailed DPIAs and legitimate interests assessments.

DLA Piper also helps clients design processes for handling candidate objections and requests for human review. Awareness of data protection rights is growing. Candidates increasingly exercise these rights, often using AI-generated requests. This area demands careful attention. The ICO’s guidance provides limited operational detail, making practical legal support especially valuable.

For organisations operating across borders, DLA Piper uses its global network to align UK and EU approaches to automated decision-making. In the EU, organisations must consider not only the GDPR but also the AI Act. You can view our Data Protection Laws of the World to gain insight on any current or upcoming regulations that may affect you. You may also view our AI Laws of the World to understand the ever-changing landscape of AI regulation.