On December 19, 2025, New York Governor Kathy Hochul signed the Responsible Artificial Intelligence Safety and Education (RAISE) Act into law. Governor Hochul signed the RAISE Act (Signed Act) subject to an agreement with the New York State Legislature to adopt chapter amendments clarifying several of its core requirements. Those amendments would substantially align the RAISE Act with California’s Transparency in Frontier Artificial Intelligence Act (TFAIA). If, as anticipated, the amendments are enacted, two of the largest states in the U.S. will have largely converged on a regulatory framework for frontier developers and models.

In light of the announced amendments, this article analyzes the RAISE Act’s obligations as reflected in the negotiated framework described in the governor’s approval memorandum and in new legislation introduced into the state Assembly (Assembly Bill A9449) and the state Senate (Senate Bill S8828) (collectively, Amended Act), rather than the Signed Act’s unamended text.

With insights from experts at Davis Wright Tremaine, DLA Piper, Eversheds Sutherland, Gibson Dunn and Morrison Foerster, this article discusses the principal features of the RAISE Act, as set forth in the proposed amendment, and some distinctions from the TFAIA. It also offers compliance measures for covered companies to consider.

See our two-part series on California’s landmark AI transparency law: “Covered Entities, Reporting Requirements and Penalties” (Oct. 29, 2025), and “Compliance Considerations” (Nov. 5, 2025).

Principal Features of the Amended Act

The RAISE Act is intended to address public concerns about the potential for catastrophic risk posed by AI, Marian Waldmann Agarwal, a partner at Morrison Foerster, told the Cybersecurity Law Report. The statute aims at promoting transparency around safety as well as practices that prevent the release of harmful AI products. Overall, the statute does a “pretty good job” of balancing innovation and consumer protection, she said.

With the passage of the RAISE Act, for the first time there are “bicoastal pillars for what may become a de facto federal standard for AI” frontier models, DLA Piper partner Danny Tobey told the Cybersecurity Law Report. It could be the “bones of a consensus approach” that may eventually be reflected in federal legislation, he added.

Covered Entities

The Amended Act applies to developers of “frontier models” that are “developed, deployed, or operating in whole or in part” in New York State. “Frontier models” are foundation AI models trained using greater than 10^26 integer or floating-point operations. The law distinguishes between “frontier developers” and “large frontier developers” that have more than $500 million in annual gross revenues, with greater reporting obligations imposed on the latter.

Focus on Catastrophic Risk

The Amended Act is directed at “catastrophic risk.” As in the TFAIA, “catastrophic risk” is defined as a “foreseeable and material” risk that a developer’s “development, storage, use, or deployment” of a frontier model will “materially” contribute to the death, or serious injury to, more than 50 people. It is also a catastrophic risk if a frontier model could materially contribute to more than $1 billion in property damage in a single incident resulting from the model:

1. providing “expert-level assistance” in creating or releasing a chemical, biological, radiological or nuclear weapon;
2. engaging in conduct with no “meaningful human oversight, intervention or supervision” that is a cyberattack or would be the crime murder, assault, extortion or theft if committed by a human; or
3. evading user control.

The terms “foreseeable” and “material” give companies flexibility and the “ability to eliminate risks” they can plausibly deem immaterial or unforeseeable, emphasized Michael Borgia, a partner at Davis Wright Tremaine. Companies would not have to “catastrophize” about AI scenarios but instead could focus on realistic outcomes based on the facts before them, he stated.

Transparency Requirements for Developers of Frontier Models

Section 1421 of the Amended Act would impose various transparency obligations on developers of frontier models, and the AG would have recourse to sue for violations of those obligations.

Notably, the Signed Act contains obligations beyond reporting, requiring frontier developers to implement safeguards to prevent the unreasonable risk of critical harm and not to deploy any frontier models prior to implementing such safeguards, Michael Atleson, of counsel at DLA Piper, pointed out. Those obligations are “fundamentally different” than transparency requirements that simply entail describing the risks, he explained.

Transparency Report

Under the Amended Act, all frontier developers are required – prior to the time of deployment of a frontier model – to prepare and publish on their website a “transparency report” providing:

• the model’s release date;
• the languages and modalities supported by the model;
• its intended uses, including any restrictions or conditions on such uses; and
• a method to contact the developer.

For large frontier developers, the transparency report would also have to include the results of any assessments of “catastrophic risks” conducted under the developer’s frontier AI framework, discussed below, and the extent of any involvement by third parties in such assessments. These requirements track the TFAIA.

Frontier AI Framework

As under the TFAIA, under the Amended Act, a large frontier developer would have to describe “in detail” in the frontier AI framework how it:

• incorporates national and international standards and industry best practices into the framework;
• evaluates the frontier model’s potential for catastrophic risk, including defining and assessing thresholds for determining such risk;
• mitigates catastrophic risk;
• reviews its assessments and the adequacy of its mitigations;
• uses third parties to conduct assessments;
• determines when modifications to the frontier model require an updating of the frontier AI framework;
• applies cybersecurity to prevent the unauthorized transfer or modification of model weights;
• identifies and responds to safety incidents; and
• institutes internal governance practices.

The developer would have to review the framework at least annually, and any “material” modifications, along with the justification for such modifications, would have to be published in an updated frontier AI framework within 30 days.

Whereas the transparency report is more geared toward the public, the frontier AI framework is more geared toward risk assessments and cybersecurity, and is likely to be more heavily redacted, Agarwal commented.

Instead of the frontier AI framework and the transparency report, the Signed Act requires large frontier developers to implement and publish a “safety and security protocol” (SSP) that contains overlapping, but not identical, requirements with the frontier AI framework. “Conceptually, there are a lot of similarities between the frontier AI framework and the SSP,” Borgia said. However, the former places a greater emphasis on risk assessment and mitigation, he stated.

Disclosure Statement

The Amended Act requires large frontier developers, prior to the development, deployment or operation of a frontier model in New York, to file a disclosure statement with the New York Department of Financial Services (DFS). The disclosure statement should list the identity and contact information of the company, as well as information about ownership in the event the company is privately or closely held. In addition, to defray DFS’ cost of administering the disclosure obligations, large frontier developers will pay a pro rata assessment.

Reporting of Safety Incidents

The Amended Act requires a frontier developer to report a “critical safety incident” to the DFS within 72 hours of determining that an incident has occurred, or the developer learns sufficient facts to establish a “reasonable belief” that an incident has occurred. A “critical safety incident” is defined as:

• any death or bodily injury resulting from “unauthorized access to, modification of, or exfiltration of, the model weights of a frontier model”;
• any harm resulting from the materialization of a catastrophic risk;
• any death or injury resulting from the loss of control of the frontier model; or
• any incident where a frontier model uses “deceptive techniques” to subvert the frontier developer’s monitoring or controls in a manner that demonstrates “materially increased catastrophic risk.”

The Amended Act also requires a frontier developer that discovers a critical safety incident posing an “imminent risk of death or serious physical injury” to disclose the incident within 24 hours to an “authority,” including “any law enforcement agency or public safety agency with jurisdiction, that is appropriate based on the nature of that incident and as required by law.” The TFAIA has a similar 24-hour requirement.

The language in the Amended Act provides “a bit more certainty” about what incidents are reportable, Borgia, said. The Signed Act, on the other hand, requires the reporting of any incident that provides “demonstrable evidence of an increased risk of critical harm,” and it does not qualify what constitutes an “increase,” he noted. “One could read the [Signed Act] to say that any increase in the risk of significant harm, even if it’s a very small increase, is enough,” which makes reporting more difficult, he said.

No False or Materially Misleading Statements

Like the TFAIA, the Amended Act prohibits large developers from making any “materially false or misleading statement” about catastrophic risk from its frontier models, including its management of such risk, and implementation or compliance with its frontier AI framework. Statements made in “good faith” and that are “reasonable under the circumstances” would be exempted.

Regulation by DFS

The Amended Act cloaks a new office within DFS with rulemaking authority. The Signed Act, on the other hand, had the Division of Homeland Security and Emergency Services as the overseeing government agency.

Enforcement oversight by the DFS is “extremely significant” and could make a “big difference” in the level of enforcement activity, Borgia commented. The DFS is “one of the most ambitious and aggressive technology regulators in the country,” he said. It has “broad enforcement tools” and is “willing to engage in a lot of rulemaking and enforcement activity to accomplish its goals,” he elaborated.

The DFS is “traditionally a fairly powerful regulator,” and the transfer to DFS creates a “supervisory mindset” much closer to that of a banking regulator, according to Vivek Mohan, a partner at Gibson Dunn. It is likely to vigorously enforce “black letter” disclosure statement filing and fee requirements, he added. However, it is unclear what enforcement will look like on less clear standards, such as what qualifies as a reportable critical safety incident, he remarked.

Effective Date

As set forth in the Amended Act, the RAISE Act will take effect January 1, 2027. The Signed Act is scheduled to take effect 90 days after becoming law (March 19, 2026), “but I do not think that anybody in New York State government is treating that date as real. The signed version of the law is instead being treated as an interstitial placeholder until [the Amended Act,] the truly agreed-upon version, is approved and signed,” Atleson said.

As of the time of publication, the Amended Act is in committee, moving through the Legislature.

Some Differences Between the Amended Act and the TFAIA

While the Amended Act and the TFAIA mostly align, there are some notable differences. Those differences, however, generally do not create more compliance challenges, Atleson said.

Shorter Reporting Period

The Amended and Signed Acts prescribe a 72‑hour reporting period for critical safety incidents. This is a significantly shorter time period than the analogous 15‑day period under the TFAIA.

“Practically speaking, it may be difficult for companies to comply with the 72‑hour time frame,” Agarwal predicted. “Usually when something goes wrong, there is lots of chaos trying to figure out why and how” the incident happened, she noted. The 30‑day period for updates could similarly be “challenging” for companies, she added.

Disclosure Statement

The Amended Act requires large frontier developers, prior to the development, deployment or operation of a frontier model in New York, to file a disclosure statement with the DFS. The TFAIA does not require the filing of a disclosure statement.

Increased Penalties

The Amended Act imposes penalties on large frontier developers for violations of disclosure and reporting requirements and the failure to comply with the frontier AI framework. The AG could recover up to $1 million for first violations and $3 million for subsequent violations. This is down from $10 million and $30 million under the Signed Act, but higher than the maximum $1‑million penalty available under the TFAIA.

Furthermore, developers that fail to file or submit false information in their disclosure statements or fail to pay required fees would be subject to civil fines starting at $1,000 per day.

No Whistleblower Provision

A big distinction between the TFAIA and the Amended Act is that the latter lacks a whistleblower provision, Agarwal remarked. “Whistleblower protections are a good thing for employees and the public, especially where companies might not be forthcoming with their reporting obligations and [such protections are not] provided for in other labor laws,” she said.

No Preemption

While the TFAIA preempts local laws, there is no such provision in the Amended or Signed Act. The exclusion may be in recognition of the fact that local legislative bodies may act in related ways in the future, whereas California is focused more on a statewide standard, Mohan said.

AI Framework Detail

One difference between the Amended Act and the TFAIA that may have little significance is that only the former would require that a frontier developer describe the AI framework “in detail.”

“I think that may not matter,” Atleson opined. “I think that the frontier AI framework may not look any different if those two words were not there,” he stated.

Compliance Considerations

Given the similarities between the TFAIA and the Amended Act, frontier developers that are compliant with the former should be “most of the way there” in complying with the latter, Atleson said. Nonetheless, covered developers that have not fully addressed compliance with these laws should be taking compliance steps now.

Establish and Maintain Basic Reporting Channels

Regardless of which law applies, a “day one” obligation for frontier developers should be to implement appropriate internal escalation pathways for incidents and harms that could trigger reporting obligations, Mohan advised. These pathways should reach the appropriate level of management to allow for timely reporting, he stated. Companies should also proactively “keep their ear to the ground” regarding what level of disclosure is appropriate and acceptable to regulators, he added.

See our two-part series on the practicalities of AI governance: “AI Governance Gets Real: Tips From a Chat Platform on Building a Program” (Feb. 1, 2023), and “AI Governance Gets Real: Core Compliance Strategies” (Feb. 8, 2023).

Do Not Wait to Develop a Frontier AI Framework

Probably the most imposing obligation in both the TFAIA and Amended Act, and something that covered entities should not wait on, is the establishment of a frontier AI framework. A large frontier developer cannot “wait until a week before it is due and just mash something together,” Atleson cautioned. Creating the framework “requires a lot of advanced planning and thinking, he emphasized. The developer must have tested and developed its products sufficiently not just to report information, but to tell a good story about that information, he instructed.

The National Institute of Standards and Technology Risk Management Framework is one helpful source of information for companies developing AI governance, Atleson continued, but many enterprise teams and experts, including lawyers, should be involved in the process. Ideally, companies can establish AI governance frameworks that apply across jurisdictions or that can be adapted, to the extent necessary, for different jurisdictions by “layering on” specific controls, he suggested.

Frontier developers also should document how and why they create the framework. A frontier developer should always maintain an “objectively reasonable narrative” for both regulators and the public demonstrating that it is approaching an issue in a reasonable way, Mohan advised.

Develop a Cross-Jurisdictional Compliance Program

Large frontier developers can choose from different approaches when seeking to comply with laws in different jurisdictions.

The larger companies that make frontier models will have to spend the time and resources gearing everything toward compliance with “the most rigorous regulatory scheme, unless they make the informed decision that they will pull out of certain jurisdictions because of onerous regulatory burdens,” Bradford Newman, a partner at Eversheds Sutherland, said. Compliance also means companies must constantly play a catch-up game with respect to new regulations, he noted.

Generally, a company should try to hold itself to the “highest achievable and reasonable standard,” Mohan agreed.

Usually, we try to establish a baseline that addresses 90 percent of a company’s obligations under all laws, Agarwal said. A company can have “jurisdictional additions” for the remaining 10 percent, she continued. Or some companies choose to take a risk and try to “come as close as possible” to compliance with the 90‑percent approach, she explained.

In developing the compliance plan, companies should focus on “core processes” for the common disclosure and risk assessment and mitigation obligations that underly all the laws, Borgia advised. Regardless of whatever law wins the day, they will need to leverage those processes, he said.

See “AI Compliance Playbook: Seven Questions to Ask Before Regulators or Reporters Do” (Apr. 21, 2021).

Be Ready to Pivot When the Law Changes

One important component of a good compliance plan is having the ability to adjust quickly as laws change.

The “biggest challenge” for keeping compliant in a shifting regulatory landscape is integrating different obligations into a “pipeline of development, deployment and constant improvement,” Mohan observed. As lawmakers continually enact new laws and amend existing ones, companies and counsel need to “keep their head on a swivel,” he advised. It may be difficult in terms of time and cost, but a company must be able to acknowledge when the “world has changed” and it must pivot, he emphasized.

The alignment of the Amended Act and the TFAIA is helpful. “Given that the TFAIA, already in effect, and the Amended Act, as currently written, are already similar, as a practical matter it is relatively safe for covered developers to keep complying with the TFAIA and keep a close eye on the New York legislative process,” Atleson said. If it suddenly appears that the Amended Act law will not be passed, then frontier developers would have to start preparing to comply with the Signed Act, he stated. However, even then, aligning compliance should not be too difficult because the [Signed Act] and the TFAIA are still “not that different,” he explained.

“Most companies are not going to want to “go hard” into compliance with the Signed Act because it is likely to be amended, Borgia said.

See “Navigating Ever-Increasing State AI Laws and Regulations” (Jan. 15, 2025).

Revisit Vendor Contracts

The RAISE Act will result in renewed focus on vendor contracts, Newman said. Developers and their customers will be paying attention to representations and warranties about compliance and the safety and security of the frontier model, and how liability will be apportioned for any violations, he predicted. Insurance coverage litigation between frontier developers and their customers can also be expected, he added.

See “Key Legal and Business Issues in AI-Related Contracts” (Aug. 9, 2023).

A Coming Challenge to State Laws?

President Donald Trump’s December 11, 2025, executive order stating that the federal government will review and potentially challenge state-level AI laws, places the RAISE Act at risk of challenge.

“I think it is almost guaranteed that the RAISE Act will be challenged by the Department of Commerce as violative of the Supremacy Clause,” Newman predicted. One of the “most basic” arguments would be that the law impermissibly burdens interstate commerce and is federally preempted, he opined. Nonetheless, a company still must be ready to comply with the RAISE Act and avoid penalties while any challenge is ongoing, he cautioned.

See “Staying Compliant After Trump AI Executive Order Introduces Regulatory Uncertainty” (Jan. 14, 2026).

Federal Legislation Needed?

The TFAIA and the RAISE Act are “perfect examples of why federal preemption in the AI sphere is necessary and how state efforts to litigate at a hyper-technical detail level is counterproductive,” Newman said. “We cannot have a competitive AI landscape where there are 50 states regulating in 50 different hyper-technical ways with different penalties and different requirements,” he emphasized. A legal landscape with conflicting laws is “burdensome and vexing to innovators, and it is not the optimal way to ensure public health and safety. It is also very sensitive to local politics, and that is not how we want AI to be regulated,” he added.

Under a proposed consent order (settlement), the FTC will require Illusory Systems (Illusory), a cryptocurrency infrastructure company that operates the Nomad Token Bridge, to return money stolen by hackers in a major data breach in which hackers stole $186 million from consumers. The FTC alleged in its complaint that Illusory failed to implement adequate data security measures, which allowed hackers to exploit a vulnerability in the company’s code.

The settlement, announced in December 2025, shows that the FTC under the second Trump administration is still an active enforcer in the data security area. “What is different about this settlement is that it is about protecting the investments of those who are investing in cryptocurrency,” said Linn Freedman, a partner at Robinson+Cole. “And this administration is very bullish on cryptocurrency.” Illusory was not the first cryptocurrency company to settle with the FTC – that was Celsius Network in 2023 – but this is the first such settlement involving a data breach.

With insights from Freedman and other data breach experts from Cooley and Covington, this article analyzes the breach and proposed settlement terms, noting lessons for companies.

See “SEC Commissioners Urge Balance of Crypto Innovation and Privacy” (Jan. 21, 2026).

The Breach

Illusory designed, operated and advertised a service that allows users to transfer messages and assets, a type of platform commonly known as a “cross-chain bridge.” In 2022, it developed the Nomad Token Bridge. Users generally interacted with the Nomad Token Bridge through a web-based interface. The Nomad Token Bridge was deployed as “smart contracts,” programs that are accessible on a network and automatically run when specified conditions are met.

The FTC alleged that Illusory inadequately tested code for the smart contracts that included a significant vulnerability. In August 2022, hackers began to exploit that vulnerability, and, due to Illusory’s inadequate security and incident response measures, the company could not respond to the attack in time.

The hackers stole almost all the assets in the bridge – worth about $186 million. Even though the company recovered some of the money, Illusory users lost over $100 million.

See “Protecting Against Crypto Theft” (Aug. 10, 2022).

Why the FTC Investigated

The FTC’s motivation was to protect consumers and make a statement about a particular industry, while demonstrating that it remains an active enforcer under the second Trump administration.

Significant Impact

Data breaches, such as the one Illusory experienced, that involve a significant number of impacted individuals or a significant amount of money are always going to be targets for federal enforcement, Michael Egan, a partner at Cooley, told the Cybersecurity Law Report. There has been an “incredible rise” over the past few years in the number of malicious actors targeting companies such as Illusory not with the intention of extorting a ransom payment, but to steal its funds or its customers’ funds.

The Illusory case is different from other FTC data breach cases because it is not about the loss of data but the loss of a large amount of money, Freedman said.

Focus on Cyber in Crypto Sector

It is possible that the FTC wanted to pursue Illusory to indicate to the broader cryptocurrency sector and others what security controls the enforcer wants to emphasize as particularly important for reasonable security practices, posited Caleb Skeath, a partner at Covington & Burling.

Regulators across the world, including the FTC, are paying attention to the cybersecurity risks and challenges facing cryptocurrency companies, Egan observed. The FTC and other regulators have worked very hard to acquire sophisticated knowledge of this technology sufficient to enable them to do “technical deep dives on these issues.”

Continued Focus on Addressing Vulnerabilities

The FTC’s concern about Illusory’s issues in addressing reports of vulnerabilities is one that the regulator has talked about and pursued enforcement on in the past, Skeath said. This is a continuing focus of the FTC, he added.

See “FTC and State Enforcers Reveal What’s Next and What to Do About It” (Oct. 2, 2024).

Illusory’s Security Failures and Misrepresentations

In its complaint, the FTC alleged that Illusory employees and third parties raised concerns about security flaws that were not addressed and that might have played a role in the breach occurring, said Skeath. It appears from the allegations that the company knew of the issues with its security, but it did not resolve those issues and “just ignored” them, Freedman said.

Failure to Implement Adequate Data Security Practices

The FTC alleged that since at least January 2022, despite knowing smart contract exploits can result in the catastrophic loss of all funds and that cross-chain bridges are often a target of sophisticated adversaries, Illusory failed to engage in reasonable and appropriate security practices.

According to the FTC, months before the attack, an engineer warned Illusory’s CEO about weak code testing and quality assurance, noting that the company had previously shipped code with a significant vulnerability because it wasn’t properly tested.

Specifically, the FTC alleged that Illusory failed to:

• implement well-known secure coding practices, such as writing and conducting adequate unit tests prior to pushing code into production;
• have a clear process for receiving and addressing security vulnerability reports, thereby delaying its opportunity to correct discovered vulnerabilities or respond to reported incidents;
• have a written information security plan and adequate process for incident response;
• have adequate staff to address security;
• have sufficient measures, such as automated systems, to detect unusual transactions and patterns of transactions;
• hire adequate staff to address security; and
• take reasonable measures to implement widely known technologies that would mitigate critical loss of user funds.

Illusory’s failure to have a clear process for receiving and addressing security vulnerability reports delayed its opportunity to correct discovered vulnerabilities or respond to reported incidents, the FTC alleged. “If [Illusory] was not patching vulnerabilities that are critical in an appropriate amount of time, that is something that [the FTC] would deem unreasonable,” Freedman said.

See “Understanding Cyberattacks on Digital Asset Platforms” (May 17, 2023).

Misrepresentations on Security

The FTC alleged that Illusory misrepresented the security of its software development practices and how it was protecting consumers’ financial assets, Freedman noted, adding that this allegation is very consistent with other FTC enforcement actions. “The FTC watches very closely what companies are telling consumers in their privacy policies about their data security measures,” she warned.

At different points, the company advertised its smart contract solution as “high security,” a “security first” solution that “prioritizes the safety and security of the funds/cross chain messages” and something that would “keep the entire system (and your funds/messages) safe.”

Illusory’s security misrepresentations were likely not written by a CISO or a technical expert, Egan posited. “These are more marketing-flavored statements.” Since the SolarWinds case, the FTC has been saying that companies need to stand behind any representations they make to the public, he said, cautioning that misrepresentations are also of interest to other regulators, such as the SEC.

“It’s important that companies live up to their security promises to consumers,” said Christopher Mufarrige, Director of the FTC’s Bureau of Consumer Protection, in a press release.

Key Provisions of Settlement

Pursuant to the settlement terms, Illusory must implement a comprehensive information security program designed to protect against theft and other unauthorized access and address the specific security concerns identified in the FTC’s complaint. The company is also required to undergo independent, biennial assessments of its information security program and to cooperate with the third-party assessor.

Over the years, the FTC has been increasingly detailed in terms of the specificity of the requirements laid out in the required information security programs included in its settlement orders, Skeath noted.

The settlement was published in the Federal Register on December 19, 2025, for a 30‑day public comment period that ended on January 20, 2026.

Repayment of Stolen Funds to Customers

The settlement requires Illusory to return to consumers the $37.5 million in assets recovered after the security breach, to the extent it was not already returned. “That is probably something that the company was already considering doing,” Freedman said. “That’s interesting to me that they are reiterating, ‘Hey, you’ve got to pay this back to the consumers.’”

Even if Illusory is intending to repay the stolen funds to customers, the FTC might be anticipating the risk of a repayment issue and using this provision as a legally enforceable backstop in that event, Skeath suggested.

Ability to Pause or Limit System Functionality

As one of the minimum steps Illusory must take to satisfy the information security program requirement, the settlement requires Illusory to introduce as a safeguard a way to quickly pause or limit the functioning of a system that allows irrevocable actions such as the unrecoverable transfer of funds if it exhibits unexpected behavior, such as the exploitation of a security vulnerability. This requirement is “interesting,” highly tailored to the issues alleged in this case and something not seen in prior FTC actions or statements, Skeath pointed out.

10‑Year Term

The monitoring term of the Illusory settlement – like that of the Illuminate Education settlement, also announced in December 2025 – is for 10 years, unlike the 20‑year terms previously issued before then. This is a “positive thing because 20 years is a really long time and, for both a regulator and a company, super onerous,” Freedman said. “Ten years is plenty of time to monitor a company to make sure they’re doing the right thing.”

In today’s fast-moving digital ecosystem, 20 years is an eternity, with so many startups getting acquired, going public or failing, Egan pointed out. Likely, “the change reflects the background negotiations that took place.” There has always been pushback against the 20‑year consent decree, which has been considered too aggressive, he added.

After the Illusory and Illuminate settlements, “I would expect to see going forward 10 years of monitoring” in future settlements, as the FTC is very consistent, Freedman said. “Attorneys representing companies are going to negotiate 10 years since now it is kind of a precedent.”

This is a potentially significant shift in how the FTC operates, Skeath and Egan both agreed. Egan expressed uncertainty as to whether the 10‑year term in the Illusory and Illuminate Education settlements is “the beginning of a trend or two unique circumstances.” The FTC is an evolving organization that changes with administrations, he noted.

A 10‑year term is still burdensome for companies, Skeath said, noting the typical information security program and third-party assessor requirements, and adding that “a lot can happen and evolve in security practices and industry practices over 10 years.”

See “Illuminate Settlements Signal Regulator Focus on Children’s Data” (Dec. 17, 2025).

Absence of Fine or Penalty

One of the most interesting parts of the settlement is the lack of fine or penalty, Freedman opined. Usually, a company that is the subject of an FTC investigation and enters a consent order has to pay a fine or penalty. Very similar allegations against other companies would lead to a fine or penalty, she said, quipping, “Maybe their lawyer was really good at negotiating.”

Practical Compliance Takeaways

Ensure the Security Program Is Reasonable

There are several different security frameworks that are helpful for companies to assess whether their security program is reasonable, Freedman noted. First, there are state and federal laws with specific requirements for security programs in different industries. For example, there is HIPAA for the healthcare sector, as well as the Gramm-Leach-Bliley Act and the New York Department of Financial Services cybersecurity regulations for financial services. There are dozens of state laws that, among other things, require companies to have a written data security program, she explained. Small companies do not necessarily need to implement the same security measures as large ones, but should have an appropriate security program for the size, scope and complexity of the organization, she suggested.

The National Institute of Standards and Technology provides a Cybersecurity Framework and a Privacy Framework, which provide worthwhile advice that many companies follow, Freedman offered. ISO 27001 also is a particularly useful framework, as is SOC 2, Egan said. Being aligned with such frameworks is evidence that a company has reasonable security, he added.

Companies also should always pay close attention to FTC settlements and guidance statements, Skeath advised.

It is also advisable to audit a company’s data security policies and procedures, Egan recommended, asking questions such as:

• Have the policies and procedures been updated?
• Have they been practiced through penetration testing and red teaming?
• Are there secure development lifecycle policies?
• Is there a written information security program?

Have an Appropriate Process for Receiving and Addressing Vulnerability Reports

A company currently unable to appropriately receive and address vulnerability reports needs to hire someone to watch for notifications and patch them promptly, Freedman urged.

In many cases, a good vulnerability response system involves having either a publicly accessible communication mechanism or a communication mechanism available to designated security researchers, so there is an established pathway for those issues to be reported, Skeath said. At the end of the system, there should be appropriate personnel from the IT or information security team monitoring what is received, so that issues reported through the system can be appropriately evaluated and, if needed, escalated.

Take Steps to Avoid Misrepresentations

Companies should be transparent with consumers about how they use security measures that are reasonable for their size, scope and complexity, Freedman suggested. They should also ensure that there is good communication and collaboration between the technical/security people and the sales/marketing staff, to discourage the latter from “puffing what the data security measures are.” Collaboration between these two groups can be complemented with input from legal personnel, or by providing legal a chance to review statements resulting from the collaboration on hot button issues such as security representations before public release, Skeath recommended.

Additionally, companies should investigate what their members are saying publicly about security, Egan advised. Perfect security does not exist. Thus, he elaborated, it would be problematic if a company states, “We have industry-leading cybersecurity,” or “We guarantee the security of your data or your currencies or our systems.”

It is critical for companies to ensure that marketing communications do not get ahead of their technical capabilities. Companies should establish a system in which the sales/marketing people show copies of all statements about data security to the security teams before they are publicly released, Egan recommended. “This is certainly something, post SolarWinds, that we have been talking to clients about as being incredibly important,” he shared.

Strengthen Incident Response

Companies should have a written incident response plan and an incident response team ready to respond to any security situation that occurs, Freedman advised. The team also should include delegates of key members in the event that someone is in transport, on vacation, sick or otherwise unavailable.

The Illusory complaint suggests that the company’s response to the breach was slowed by the fact that an engineer who played a key role in the response was on a plane at the time and thus unable to effectively participate in the response. An effective incident response plan has enough flexibility to deal with those types of situations and those that may be unanticipated, Skeath observed. However, small companies with limited personnel or technical expertise may struggle with finding delegates competent to take over if a key person in the plan is unavailable, Egan noted.

An effective incident response plan supports quick escalation of potential problems, whether they come to the company’s attention through customer complaints, suspicious access, detection of the loss or excessive movement of data, or some other way, Egan stressed. Many of these red flags can be identified by automated mechanisms, which will provide an alert that should be monitored in a way that leads to a prompt response. However, he cautioned, raising too many alerts can lead to staff developing alert fatigue, like the story of the boy who cried wolf. It is critical for the right alert to be raised at the right time to the right people for cybersecurity issues to properly be identified, stopped and remediated, he said.

Conduct Tabletop Exercises

Incident response teams, including delegates, should be involved in data security tabletop exercises or war games more than once a year, Freedman advised. “I do a lot of tabletop exercises; I love doing tabletop exercises because I think that it is one of the best ways to help a company prepare for a security incident.”

A good tabletop exercise is one in which the entire incident response team gets together, and no one knows the scenario beforehand, so there is no preparation. When conducting these exercises, Freedman provides the team with a real-life scenario that she has been through many times. She tests the incident response team on their response, knowing their roles, communication and how they work together. She also advises testing the responses of the IT, communications and executive leadership team in what should feel like a real-life scenario. “Every tabletop exercise that I have ever been involved with has had the [participants] come out of it energized, with more knowledge and experience,” she observed. “The companies that do tabletop exercises more than once a year always do better in a security incident than those that do not.”

Skeath agreed. Companies that go through a tabletop exercise or some other sort of evaluation of their incident response process before an incident have “muscle memory” about what to do. “They have more familiarity with what each person needs to do and are able to execute more easily if and when an incident occurs, as opposed to those who do not have a plan or have a plan and have not rehearsed it prior to an incident,” he said.

Implement Secure Coding Practices

The FTC, as illustrated by the Illusory settlement, expects companies to embed security into coding and development from the start and at every stage, rather than treating it as a single step bolted on before deployment, Skeath observed. The process may take IT or development additional time, but it can reduce security and legal risk. “The FTC has been talking about this in terms of not only ‘secure coding,’ but ‘secure by design’ and similar concepts for a number of years,” he noted.

The goal of secure coding practices is to ensure that code works as intended, with testing before the software goes into production, Egan said. An important part of secure coding practices is ensuring that this work follows an appropriate written policy, he added. 

Be Able to Pause or Limit System Functionality

Companies involved in fintech and the blockchain ecosystem should pay attention to the settlement provision requiring Illusory to ensure a system that allows irrevocable actions such as the unrecoverable transfer of funds can quickly pause or limit functionality, Skeath advised. “This is something that the FTC thinks is a good idea, and it might be something that it looks for in future investigations or inquiries.”

Choose an Appropriate Third-Party Assessor

If a company finds itself negotiating toward a settlement that will include a third-party assessor requirement, it should pay close attention to selecting the assessor, Skeath recommended. The company gets to present an assessor to the FTC for approval, so it should choose an assessor who will likely be accepted by the FTC and would tend to be fair and reasonable toward the company if there are any gray areas or subjects of differing opinion that arise during the assessment, he said.

On March 13, 2024, the European Parliament adopted the European Regulation on Artificial Intelligence, known as the E.U. AI Act (Act). The Act entered into force on August 1, 2024. “I think it’s fair to say 2025 was really when the rubber hit the road for the AI Act,” said Bird & Bird partner Toby Bond during a program on implementation of the Act.

Bond, along with Bird & Bird partners Miriam Ballhausen and Izabela Kowalczuk‑Pakula, and associate Puck van den Bosch, discussed significant developments under the Act, including the obligations that came into force in 2025, those taking effect in 2026 and strategies for meeting those obligations. They also examined existing and anticipated guidance, transparency obligations and a pending proposal to amend the Act, which could extend certain compliance deadlines and ease some requirements. This article distills the key takeaways from the program.

See our three-part series answering top questions about the E.U. AI Act: “Reach and Unique Requirements” (Apr. 24, 2024), “Risk Tiers and Big-Player Transparency” (May 1, 2024), and “Practical Steps and What’s Next” (May 8, 2024).

Significant Developments Under the Act in 2025

Article 4 Literacy Obligation and Article 5 Prohibited Practices Took Effect

On February 2, 2025, the prohibited AI practices under Article 5 and the AI literacy obligation under Article 4 came into force, noted Bond. However, the absence of guidelines left many open questions about the permissibility of certain practices, especially employee monitoring.

Although provisions for fines did not take effect until August 2, 2025, there were some private claims for alleged breaches of Article 5 before then, Bond pointed out. The Act does not specify fines for breach of Article 4. It is up to Member States to adopt them, none of which had done so as of the date of the program. Private enforcement of Article 4 may also be available under Member States’ laws.

Guidelines Were Issued

In 2025, Bond explained, the European Commission (EC) issued the following guidelines and other materials:

• February 4: guidelines on prohibited practices;
• February 6: guidelines on the definition of “AI system”;
• July 10: the General Purpose AI (GPAI) Code of Practice, which addresses transparency, copyright, safety and security;
• July 18: guidelines on the scope of obligations for providers of GPAIs; and
• July 24: a training data disclosure template for use with Article 53(1)(d).

GPAI Model Provider Obligations Took Effect

On August 2, 2025, the GPAI model provider obligations under Articles 51‑55 took effect for models placed into service after that date, with enforcement powers commencing August 2, 2026, said Bond. For models already in service, such obligations take effect on August 2, 2027. The Act does not clearly define what constitutes a GPAI model, though the GPAI guidance now provides indicative criteria and examples. It also distinguishes between the fine-tuning of models by original providers and downstream users, and what requirements apply to each.

The GPAI Code of Practice constitutes “an adequate voluntary tool for providers of general purpose models to demonstrate their compliance with the Act,” Bond explained. The guidelines on prohibited practices address the extent to which a GPAI provider must take steps to ensure it is not used for improper purposes.

The EC took a bifurcated approach with its guidance. For some types of systems, the provider must incorporate certain technical safeguards. For others, the provider may be able to rely on terms of use and instructions, possibly in conjunction with reactive monitoring. Additional guidelines are expected regarding the obligations of providers of high-risk systems.

AI and Copyright Consultation Launched

On December 1, 2025, the EC launched a stakeholder consultation under the Act to support the implementation of the Act’s obligation for providers of GPAI models to identify and comply with reservation of rights expressed by rightsholders. The EC’s consultation closed in January 2026, noted van den Bosch. The consultation was intended to support the Act’s obligation for providers of GPAI models to put in place a policy to comply with E.U. law, including to identify and comply with reservations of rights against text and data mining.

See “A Baker’s Dozen AI Governance Resolutions for 2026” (Jan. 7, 2026).

Draft Code of Practice for Article 50 Transparency Requirements Were Published

In December 2025, the EC published a draft code of practice for Article 50 transparency requirements for labeling AI-generated content and disclosing deepfakes and AI-generated text, explained van den Bosch. An organization that does not subscribe to the code of practice will have to demonstrate how it complies in a different way.

Content-Labeling by Providers

The code, according to van den Bosch, includes the following labeling commitments for providers of AI-generated content:

• marking content and ensuring it cannot easily be removed;
• ensuring marking can be detected;
• ensuring marking techniques are effective and robust; and
• testing, verifying and monitoring the chosen marking techniques.

See our two-part series on managing legal issues arising from use of ChatGPT and Generative AI: “E.U. and U.S. Privacy Law Considerations” (Mar. 15, 2023), and “Industry Considerations and Practical Compliance Measures” (Mar. 22, 2023).

Deployer Disclosure of Deepfakes and AI-Generated Content

The code also requires all deployers of AI-generated content to:

• disclose the origin of the content based on a deployer-developed common taxonomy;
• distinguish between fully and partially AI-generated content and identify such content with an “AI” icon;
• ensure compliance through training and monitoring; and
• conform to specified human accessibility standards.

It also includes specific measures for deepfakes, added van den Bosch. For example, an auditory deepfake must include a clear, but non-intrusive, auditory alert.

See “How to Create a Program to Combat Deepfakes” (Oct. 22, 2025).

August 2, 2026, Deadlines

Several significant obligations under the Act take effect on August 2, 2026, explained van den Bosch. They include obligations for high-risk systems and AI systems with transparency risk.

High-Risk Systems

High-risk systems are listed in Annex III of the Act, and include applications like biometric categorization, recruitment and HR decisions, explained van den Bosch. The obligations take effect for (1) high-risk systems placed on the market after August 2, 2026, and (2) those already in service that have been substantially modified. Most such obligations fall on system providers.

Deployers, importers and distributors of high-risk systems also have obligations under Articles 23 to 26, primarily Article 26, according to van den Bosch. Article 25 sets forth value chain obligations for suppliers of components, tools or services to providers of high-risk AI. Such suppliers will need contracts with providers to deliver information needed by providers to comply with the Act.

See “Pain Points and New Demands in AI Contracts” (Jun. 18, 2025).

Systems With Transparency Risk

Systems with transparency risk mainly include chatbots and generative AI systems, said van den Bosch. Providers of systems intended to interact with humans must ensure that:

• users know they are interacting with an AI system; and
• content is labeled as being AI-generated.

Additionally, deployers of such systems must disclose use of:

• emotion recognition or biometric categorization systems;
• “deepfakes,” which are defined broadly under the Act; and
• AI-generated text, when such text is used to inform the public on public matters.

See our two-part series on California’s landmark AI transparency law: “Covered Entities, Reporting Requirements and Penalties” (Oct. 29, 2025), and “Compliance Considerations” (Nov. 5, 2025).

Anticipated Guidance and Ongoing Initiatives

Still Waiting for Harmonized Standards

As with all E.U. product safety legislation, “harmonized standards are going to be key compliance tools for high-risk obligations under the Act,” said Bond. Although such standards could be issued as early as the summer of 2026, “there is real concern that the harmonized standards won’t be ready sufficiently in advance of the high-risk deadline for Annex III systems of August [2026]. Without those compliance tools, it’s going to be really challenging for many organizations to implement their compliance program,” he observed.

Soft Law

Codes of practice under the Act, including the GPAI code, are creating “soft law” requirements, according to Bond. Organizations that do not follow them will have to be able to demonstrate how they meet the Act’s relevant requirements in other ways. The European AI Office (AI Office), which was established within the EC to support the development and use of trustworthy AI and enforce portions of the Act, still has a significant amount of work to do on such codes. It has indicated its desire to “take a collaborative, staged and proportionate approach to enforcing GPAI requirements,” he said.

Areas of Anticipated Guidance

Guidance is needed to address the many remaining gaps under the Act, noted Bond. Organizations should continue to engage in the Act’s implementation processes. Participation in consultations has resulted in improved guidelines. The EC is expected to issue a considerable amount of additional guidance and guidelines, according to van den Bosch, including:

• templates for:
  • reporting serious incidents involving high-risk systems;
  • fundamental rights impact assessments; and
  • post-market monitoring of high-risk systems;
• practical application of and/or guidance on:
  • high-risk classification, requirements and obligations for providers and deployers of high-risk systems;
  • Article 50 transparency requirements;
  • AI value chain responsibilities;
  • what is a “substantial modification” of an existing model; and
  • clarification of the research exception;
• elements of quality management systems for small and medium-sized enterprises (SMEs) and small mid-cap companies (SMCs); and
• interplay of the Act with other E.U. laws.

Whistleblower Tool

The AI Office has launched an AI whistleblower tool. Individuals who report breaches of the Act to the AI Office will be protected from retaliation under the E.U. Whistleblower Directive.

Practical Considerations for Implementing High-Risk Systems

According to Ballhausen, high-risk use cases may include, for example:

• HR, such as resume screening, candidate ranking, performance monitoring and evaluation, and promotion and termination decisions;
• certain customer support functions;
• fraud detection and anti-money laundering screening; and
• workplace communications monitoring.

Most organizations are likely to have high-risk systems, given the Act’s focus on HR and recruitment, said Ballhausen.

There are different obligations for “providers” – those that develop an AI system and put it on the market or those that put it into service under the person’s own name — and “deployers” – those that use an AI system, or the output from an AI system, in the E.U., explained Ballhausen.

See “Guide to AI Risk Assessments” (Jun. 18, 2025).

Deployer Obligations

The Act specifies eight obligations for deployers of high-risk systems, not all of which are relevant to every deployer, noted Ballhausen. They include:

• ensuring the system is used in accordance with instructions;
• ensuring input data is relevant and sufficiently representative;
• ensuring oversight by sufficiently AI-literate humans;
• logging certain events and retaining log records;
• conducting quality monitoring and notifying providers of serious incidents;
• for employers, notifying employees that they are subject to a high-risk system;
• carrying out data protection impact assessments in certain instances; and
• for public bodies, conducting a fundamental rights impact assessment for certain applications.

In certain situations, cautioned Ballhausen, a deployer of a high-risk system may be deemed a provider, including:

• by adding a name or trademark to a high-risk system;
• making a substantial modification to a high-risk system; and
• modifying an AI system in a way that makes it a high-risk system.

Provider Obligations

Article 16 of the Act sets forth the obligations of providers of high-risk systems, cross-referencing many other provisions of the Act, noted Ballhausen. She provided a list of the relevant obligations and, where applicable, the relevant articles, including:

• ensuring compliance with requirements specified in:
  • Art. 9 – risk management systems;
  • Art. 10 – data governance and management;
  • Art. 11 – technical documentation;
  • Art. 12 – recordkeeping;
  • Art. 13 – transparency and instructions for deployers;
  • Art. 14 – human oversight; and
  • Art. 15 – accuracy, robustness and cybersecurity;
• Art. 17 – quality management systems;
• Art. 18 – documentation;
• Art. 19 – logging;
• Art. 20 – corrective actions;
• Art. 21 – regulatory cooperation;
• Art. 22 – authorized representatives;
• Art. 43 – pre-marketing conformity assessment;
• Art. 47 – E.U. declaration of conformity;
• Art. 48 – “CE” marking;
• Art. 49 – registration;
• E.U. accessibility requirements;
• supplying provider information on packaging; and
• transparency.

To facilitate compliance, Ballhausen recommended grouping those requirements into buckets, from highest to lowest relative urgency, as follows:

1) AI System Design

This is the most important area of focus, according to Ballhausen. Without knowing what a system includes, it will be difficult to, for example, draft documentation or conduct a conformity assessment. Thus, the most urgent tasks include:

• Art. 12 – recordkeeping;
• Art. 13 – transparency and instructions for deployers;
• Art. 14 – human oversight;
• Art. 15 – accuracy, robustness and cybersecurity; and
• compliance with accessibility requirements.

2) Policies and Procedures

System design will feed development of policies and procedures, noted Ballhausen. There will also be interplay with existing procedures. This step includes:

• Art. 9 – risk management systems;
• Art. 10 – data governance and management;
• Art. 17 – quality management systems; and
• Art. 72 – post-market monitoring and tracking.

3) Documentation

Relevant provisions include:

• Art. 11 – technical documentation;
• Art. 18 – documentation; and
• Art. 19 – logging.

4) Conformity Assessment and Providing Information

The following are not necessarily lower priority, cautioned Ballhausen. However, sufficient guidance is not yet available for conducting full conformity assessments. If and when guidance becomes available, she noted, the following tasks “will very likely become more urgent”:

• Art. 43 – pre-marketing conformity assessment;
• Art. 47 – E.U. declaration of conformity;
• Art. 48 – “CE” marking;
• Art. 49 – registration; and
• supplying provider information on packaging.

5) Accompanying Tasks

The remaining elements of compliance include:

• Art. 20 – corrective actions;
• Art. 21 – regulatory cooperation;
• Art. 22 – authorized representatives; and
• Art. 73 – reporting serious incidents.

See our AI Compliance Playbook series: “Traditional Risk Controls for Cutting-Edge Algorithms” (Apr. 14, 2021), “Seven Questions to Ask Before Regulators or Reporters Do” (Apr. 21, 2021), “Understanding Algorithm Audits” (Apr. 28, 2021), and “Adapting the Three Lines Framework for AI Innovations” (Jun. 2, 2021).

Digital Omnibus Package

On November 19, 2025, the EC issued a proposal for a Digital Omnibus on AI (Proposal), setting out proposed amendments to the E.U.’s digital regulatory framework as part of a broader simplification and competitiveness initiative. The Proposal is meant to ease regulatory burdens while maintaining high standards, explained Kowalczuk‑Pakula. It reflects the EC’s recognition that Member States have been slow to designate national competent authorities and that harmonization standards for high-risk requirements are not ready. If the EC follows customary timelines, it could finalize the Proposal by early 2027. However, it could decide to fast-track adoption using its “urgent procedure.”

Extending Future Deadlines

Annex III High-Risk System Obligations

According to Kowalczuk‑Pakula, the Proposal would extend the current August 2, 2026, deadline for Annex III high-risk systems to the earlier of:

• six months after the EC issues a decision confirming the existence of adequate measures; and
• December 2, 2027.

Annex I High-Risk System Obligations

Similarly, it would extend the August 2, 2027, deadline for Annex I high-risk systems to the earlier of:

• 12 months after the EC issues a decision confirming the existence of adequate measures; and
• December 2, 2028.

Marking

Article 50 requires video or text generated by AI systems to be “marked in a machine readable format and are detectable as artificially generated or manipulated,” explained Kowalczuk-Pakula. The Proposal would extend the marking compliance date for systems placed on the market before August 2, 2026, to February 2, 2027. Systems placed on the market after August 2, 2026, would have to comply immediately.

Near-Term Deadlines Likely to Stand

It is unlikely that that the Proposal will be finalized before the deadline for high-risk systems, cautioned van den Bosch. Organizations should be as ready as possible to implement all standards as they become available, said Bond.

Moreover, even if the Proposal is adopted, organizations will have just six months from the EC’s determination that standards are acceptable to comply. They will still have a lot of work to do. Consequently, it is advisable to start now to identify systems and documentation, gather relevant information, develop processes and organize the relevant stakeholders, Bond advised.

Eliminating Registration Requirement for Non-High-Risk Annex III Systems

If a provider determines that an Annex III system is not high-risk, Article 49 requires the provider to register the system with the E.U. high-risk database, explained Kowalczuk‑Pakula. To streamline compliance and reduce costs, the Proposal would eliminate this registration requirement.

Thus, a provider relying on an exception under Article 6(3) would not have to register. It would only have to document how it determined the exception applied. Notably, however, many authorities, including those in Poland, the Netherlands and Germany, have already indicated that they will not support this element of the Proposal.

Shifting AI Literacy Requirements

The Act requires providers and deployers to ensure the AI literacy of their workforces, continued Kowalczuk‑Pakula. The Proposal would eliminate that requirement and, instead, require the EC and Member States to encourage providers and deployers to ensure appropriate AI literacy. “Member States do not like new obligations,” so there is likely to be extensive debate over this aspect of the Proposal, she remarked.

Processing Special Categories of Personal Data

To facilitate compliance with data protection laws, the Proposal would allow providers and deployers to process, with appropriate safeguards, special categories of personal data to ensure bias detection and correction. Currently, Article 10 only permits such processing when “strictly necessary” with respect to high-risk systems. The Proposal would eliminate that provision and replace it with a one permitting such processing when “necessary” with respect to high-risk and other systems and models, explained Kowalczuk‑Pakula.

See our two-part series “AI Meets GDPR”: EDPB Weighs In on AI Models (Feb. 5, 2025), and Mitigating Risks and Scaling Compliance in the Development and Deployment of AI Models (Feb. 19, 2025).

Other Elements of the Proposal

Other elements of the Proposal, as Kowalczuk‑Pakula outlined, include:

• broadening use of AI regulatory sandboxes and testing, including strengthening cross-border cooperation and extending testing opportunities to hybrid systems under Annex I;
• simplifying documentation quality management systems for SMEs and SMCs;
• centralizing oversight of various AI systems in the AI Office;
• additional guidance;
• more flexibility in post-deployment monitoring; and
• additional clarification of the interplay between the Act and other E.U. legislation.

Kelley Drye has announced the addition of two lawyers to the firm’s privacy and information security practice group. Kate Black joins as a partner in San Francisco and is associated with the firm’s Los Angeles office, and Mason Fitch joins as special counsel in Houston. Both attorneys arrive from Hintze Law, where Black served as a partner and chair of the health and biotech group, and Fitch was of counsel.

Black focuses on legal issues related to privacy, AI, health technology and cutting-edge innovation. She advises companies on managing legal risk associated with highly sensitive personal data, including health, genetic, biometric and consumer information. Her clients span biotechnology, life sciences, digital health, mobile medical applications, consumer health and wellness products, e-commerce, data analytics and technology platforms that handle sensitive information. Prior to private practice, Black served as the first head of privacy and data protection at 23andMe, where she led the company’s privacy, data governance and law enforcement response function. She also held roles at the U.S. Department of Health and Human Services and advised the California Office of Health Information Integrity.

Fitch focuses on privacy and AI matters, particularly as they relate to healthcare, emerging technology and sensitive personal data, providing advice that enables strategic, high-stakes data uses. He has represented clients in state, federal and international regulatory investigations. In addition to his private practice experience, he has also held in-house roles, including privacy counsel at Hims & Hers and manager of the privacy program at Facebook.

For insights from Kelley Drye, see “CPPA’s Tractor Supply Decision Offers Lessons As Enforcement Focus Moves From Education to Deterrence” (Oct. 22, 2025); and “Healthline’s Record-Setting CCPA Settlement Offers Lessons on Transparency and Opt-Outs” (Aug. 6, 2025).

Cipriani & Werner has welcomed Cristina Di Maria as a partner in its cybersecurity group in Philadelphia. She arrives from the Beckage Firm.

Di Maria focuses on data security and privacy and complex cyber risk challenges. She helps clients of all sizes navigate the complexities of cyber threats and mitigate their exposure to data privacy and security risks. Her practice is centered around incident response, proactive risk management – including data privacy and information security training – and ensuring compliance with evolving data privacy regulations. 

Di Maria has successfully led a wide range of incident response services across industries, including digital forensics investigations, network restoration efforts, ransom negotiations and strategic guidance on communications. She also works with clients to assess and fulfill consumer and regulatory notification obligations, and liaises with law enforcement. An experienced litigator, she has managed numerous cases for healthcare providers and facilities, particularly in matters involving HIPAA and the HITECH Act.

In her prior role as partner at the Beckage Firm, Di Maria specialized in tech, data security and privacy law. She also previously served as managing counsel for global privacy and security at Fiserv, where she was responsible for advising stakeholders on a broad spectrum of data privacy, cybersecurity and AI laws.