Shadow AI: How Can Companies Protect Against Unknown Uses?

AI & Algorithms, Artificial Intelligence , , , , , , , , , , ,

Employees don’t always wait for their employers to approve new technology. This could be using a personal chatbot account to summarize a document, installing an AI browser extension, uploading information into an AI analysis tool or using an AI feature built into software without their employer knowing about it. This practice is often referred to as “shadow AI.”

Shadow AI is typically not malicious. Often, it’s the result of employees wanting to work more efficiently, or as a result of unclear AI use policies. However, shadow AI can create security and confidentiality issues. If employees send personal or company information into an AI system that has not been reviewed, the business may not have an accurate picture of where its information is going, how it’s being used, or for how long it is being stored. 

What does shadow AI look like?

Shadow AI could include any number of unapproved AI tools used for work purposes. For example, an employee may paste customer information into an LLM to create a summary, upload internal presentation information for editing or use an AI tool to analyze a spreadsheet. 

The problem is that using shadow AI can result in company information being sent to a third-party provider that the original company may not know about. By hiding in the “shadows,” employees who use AI tools in this way can create governance gaps. Without proper review of the AI tools being used by its employees, a company may not know what information is being provided, how long it will be retained for, who can access it or whether the vendor can use it for other purposes, like training its own systems. 

How can companies address employee AI usage?

Company AI policies can bring clarity to issues surrounding shadow AI. 

By addressing what kinds of technologies may be used, these policies can explain which AI tools are approved, what information employees may enter into those tools, and when a new AI tool or use requires review. In general, companies drafting these policies may want to specifically and clearly state what information may and may not be used. For example, a general policy telling employees to use AI responsibly may not provide enough guidance when someone is deciding whether to upload a confidential document or customer data into a new tool. 

These policies should also be communicated clearly. Without understanding the policies that a company has in place, employees may inadvertently engage in shadow AI use. With clarity on approved tools, uses, and inputs, an effective employee AI use policy could lower these risks. Within this policy, a company may may consider creating a process to request new AI tools. This way, relevant business teams can review any AI tools and uses before company information is provided.  

What should businesses take away?

Businesses do not necessarily need to prohibit AI use. However, companies may consider reviewing which tools employees are using and what information is being provided to them. Some steps companies may consider in this review process include, but are not limited to: 

  • Identifying AI tools employees are actually using, including personal accounts, browser extensions and AI features within existing software.
  • Explaining which tools are approved, restricted or prohibited and what information employees may enter.
  • Considering privacy, confidentiality, retention, deletion and AI-training terms with vendors.
  • Determining whether AI uses involve processing that requires a CCPA risk assessment or updates to privacy documentation.
  • Establishing rules preventing employees from providing sensitive company information to unapproved AI tools.
  • Giving employees a clear way to request new AI tools before using them for company work.

While AI in the workplace may boost efficiency, it may also create risk if the company is not aware of it. By providing employees with guidance on AI, businesses may be able to reduce the risks of shadow AI. 

AI Notetakers: Key Takeaways for Recording Calls

AI & Algorithms , , , , , , , , , , ,

Use of AI notetakers is quickly becoming routine. These tools can automatically join video calls, listen to conversations, generate transcripts, create summaries, and identify key points in a meeting. 

While these tools have an argument for efficiency, they also create legal, privacy, and confidentiality risks. 

This issue is a lot more complicated than simply asking participants of a meeting for their consent to be “recorded.”  This is because recording, transcription, and AI processing are separate activities – and each may have its own notice and consent requirements.

As a result, businesses using these tools need to understand both what is happening during the meeting and what happens to the information after the meeting has ended.

What are AI notetakers?

An AI notetaker is a tool that captures meeting content and uses artificial intelligence to create transcriptions, summaries, action items, and log other important meeting records. Most operate as a bot that joins a video conference meeting as an additional participant. 

Many AI notetakers process information from meetings through cloud-based services rather than keeping the conversation only on an employee’s local computer. Depending on the provider, the service may receive audio transcripts and other meeting information and then use an AI system to analyze and summarize the dialogue. This means meeting content may be transferred outside of the company’s own system and processed or stored by a third-party provider, which may have privacy and data-sharing implications. 

Why do recording and consent laws matter?

Recording laws differ across the United States. Some states generally follow a one-party consent approach, meaning the consent of one participant is sufficient to record a conversation.  However, other states follow an all-party consent approach, sometimes referred to as “two-party consent” which generally requires the consent of everyone involved in a conversation for recording. The specific details and exceptions vary by jurisdiction. 

What actually counts as consent?

Sometimes consent can be more complicated than just simply displaying a recording symbol. Video-conference platforms may use different methods to alert participants when recording a meeting begins: a pop-up requiring participants to acknowledge the recording, an audible announcement, a banner or an icon that’s displayed during the meeting, some hosts may also require verbal consent.

But notice and consent are not always the same thing and what constitutes legally sufficient consent can depend on the applicable law and the circumstances at hand.

What happens to meeting information after the call?

Once an AI notetaker has captured a meeting, businesses should understand what rights the provider has over that information. Vendor terms can address data ownership, licensing, data retention, and whether information may be used to develop or improve the provider’s service. 

This becomes especially important as ordinary workplace conversations frequently include information that employees may not intentionally send to a third party: customer information, personnel issues, financial projections, internal strategy, product development and many other confidential materials may all be discussed while the AI notetaker captures the conversation. 

The transcription or summary can also create additional security concerns once the meeting ends. For example, automatically generated notes may be distributed via email, downloaded, forwarded and stored in employee accounts long after an original conversation has occurred. Meeting summaries create additional opportunities for sensitive information to spread or remain stored indefinitely. 

Businesses should therefore review not only what the tool captures but also who receives the resulting transcript, where it is stored, how long it is retained and who has the ability to delete it.

What about attorney-client privilege?

Adding an AI notetaker to a legal discussion can create questions about whether confidentiality has been maintained, and depending on the circumstances, whether privilege could be challenged or waived. You can read more updates from Federal District Courts on the issue here. 

This does not mean that all use of technology during a legal meeting automatically destroys attorney-client privilege. Whether privilege is affected may depend on the circumstances such as how the AI provider handles information and why the tool is being used. Therefore, businesses should be more cautious about allowing AI notetakers into meetings that involve legal advice or other professionally protected information. 

The same concern applies to trade secrets and other confidential business information. Meetings involving sensitive product plans or internal strategies and other proprietary information may not be appropriate for AI transcription unless the tool and its data practices have been reviewed carefully. 

What should businesses take away?

AI notetakers can be useful workplace tools, but businesses should have clear policies in place before employees begin using them regularly. Below are some high-level tips that businesses may want to consider when onboarding a new AI notetaker: 

  • Approve specific tools: Employees should know which AI notetakers are permitted and how those tools record, transcribe, store and process meeting information.
  • Create clear notice and consent procedures: Businesses may consider the laws that may apply to meeting participants and make sure notices accurately reflect how AI is being used.
  • Limit use in sensitive meetings: Legal, HR, disciplinary investigation and other confidential discussions may require additional approval or no AI notetaker at all.
  • Review vendor data practices: Companies should understand how meeting information is used, stored, retained and deleted, including whether it may be used to train or improve AI systems.
  • Set rules for transcripts and summaries: Businesses may want to determine who can access or share AI-generated notes, how long they are kept and whether they are treated as official company records.

Healthcare AI data breaches: Why companies need to protect more than patient records

AI & Algorithms, Artificial Intelligence , , , , , , , , , , ,

Healthcare and life science companies are not only protecting traditional patient records – things like names, diagnoses, treatment notes, lab results, and insurance information. They may also be protecting clinical trial data, research data, vendor systems, proprietary models, and other information used to support patients and drug development. When these companies and systems are involved in data breaches, the legal risks can become broader than a standard data breach. 

A useful example is the recent Novo Nordisk incident. Novo Nordisk is the pharmaceutical company that makes drugs such as Ozempic and Wegovy and recently disclosed a cyber incident involving patient data from clinical trials. It has also been reported that a hacking group claimed to have stolen over a terabyte of data and attempted to extort the company, though Novo Nordisk has not confirmed the entire scope of those claims. 

The Novo Nordisk incident shows that healthcare breaches can involve more than names and medical records. Companies also need to consider whether a cyber incident involves clinical trial information, healthcare provider data, research files, AI model information, or other confidential business materials. When this type of data is involved, companies may need to take precautions to protect the data, document their response, and comply with applicable privacy and cybersecurity obligations.

Recent health-related breaches also highlight how these incidents create major legal and business consequences. The Change Healthcare cyberattack that occurred in 2024 shows the scale of healthcare cybersecurity risks with reports that 197.2 million individuals were impacted by this breach. For scale, 197.2 million people would be more than half of Americans. The 23andMe breach also highlights the litigation risks tied to sensitive genetic information, with a bankruptcy judge approving a $46.75 million settlement for victims in the breach. While the facts of these examples differ, they all highlight why companies handling health-related data need to treat cybersecurity, AI governance and breach response as connected compliance and a priority in business practices. 

Why are AI-related healthcare breaches unique?

A standard healthcare breach analysis often focuses on whether names, medical records, insurance information, or other identifiable patient information was exposed. These concerns are highly important and sensitive. But as artificial intelligence becomes more integrated into healthcare, it creates additional risks because AI tools rely on large volumes of sensitive data that may also be tied to valuable research and business information.

For example, an AI model used in drug development may involve clinical trial data, molecular research, imaging data, prompts, outputs and other model training information. If these systems are accessed by an unauthorized actor, the incident may raise privacy concerns and may also create IP and competitive risks. 

This means healthcare AI security should not only focus on protecting patient records. Companies should also consider whether their AI models, training datasets, research systems, and vendor environments are adequately secured.

Why does de-identification matter?

De-identification can be key when healthcare data is used with AI. In simple terms, de-identification means removing information that could identify a person up to a certain legal standard. This matters because companies may want to use patient data or clinical data to train, test or improve their models. 

If health data is properly de-identified before being used with AI, the company may reduce privacy risks. However, if the data is not properly de-identified, several questions remain. The company may need to ask whether its privacy notices clearly explained that health data could be used for AI training or analysis. State privacy laws may also require clear disclosures about how personal information is collected and used. For example, California’s CCPA requires covered businesses to provide notice about the categories of personal information collected and the purposes for which that information is collected or used. This is especially important when health-related data is later used in a way that patients or consumers may not have expected. 

The company may also need to consider whether protected health information was shared with an outside AI vendor, whether a business associate agreement was required, and whether patient authorization was needed.

What happens if PHI may have been compromised? 

Breach response is also an important issue. If a healthcare company experiences a ransomware attack or an unauthorized access incident, they may need to assess whether protected health information (PHI) was compromised, This may include reviewing what information was involved, whether it could identify an individual, who accessed it, whether it was viewed or acquired and if the risk was mitigated or not.

The Novo Nordisk incident highlights why this analysis matters. Novo Nordisk stated that the clinical trial information involved was not directly linked to patient names or other direct identifiers. However, the incident still raised questions about patient-related data, de-identification, and whether any protected health information may have been compromised. This is why companies should be able to document how health-related data was stored, protected, and separated from information that could identify individuals.

What should companies take away? 

For healthcare and life science-related companies, the key takeaway is that AI governance should include privacy and cybersecurity from the start. Before using health-related data with AI, companies should ask:

  • What data goes into the AI system?
  • Is the data identifiable or properly de-identified?
  • Who can access the data, prompts, outputs, or model?
  • Are outside vendors involved?
  • Can the vendor use the data to train or improve its own models?
  • What security controls apply if the system is breached?

Companies should also treat AI models, training datasets, prompts, outputs, and research tools as sensitive assets as well since they can carry PHI and may lead to inadvertent disclosures. Vendor contracts should address confidentiality, data retention, security controls and model training. 

AI may help healthcare and life science companies innovate and operate faster, but innovation cannot replace privacy and regulatory accountability. Companies using AI with health-related data need to confirm de-identification practices, strengthen vendor contracts, and properly prepare for responses before incidents occur.

0
Chicago Grand Central Looking Up

DOJ Issues Final Rule on US Bulk Sensitive Data

Data Brokers, Data Transfers, United States , , , ,
The International Emergency Economic Powers Act (IEEPA) vests the President with authority to deal with extraordinary threats to national security and foreign policy that have their source in part or in whole outside of the United States. Acting pursuant to the IEEPA, President Biden issued Executive Order 14117, “Preventing Access to Americans’ Bulk Sensitive Personal Data and United States Government-Related Data By Countries of Concern” (the EO). The EO directed the Department of Justice (DOJ or Department) to establish and implement regulations addressing threats from certain countries of concern attempting to access and exploit bulk amounts of US sensitive data, including personal and government data. On December 27, 2024, the DOJ issued the Final Rule, which went into effect on April 8, 2025. Additional compliance provisions for certain transactions take effect on October 6, 2025. The Final Rule prohibits or restricts a range of transactions involving categories of bulk sensitive personal data or government-related data between the US and countries of concern or covered persons. In assisting businesses to adapt to this comprehensive update, the DOJ provided a Fact Sheet, a Compliance Guide, and over 100 FAQs on the Final Rule, along with an Implementation and Enforcement Policy. Below are five main takeaways that US entities may want to consider in light of these regulations.
  1. Enforcement May Be More Lenient Until July 8, 2025 
The DOJ’s Implementation and Enforcement Policy, states that the Department will “target its enforcement efforts during the first 90 days to allow US persons (e.g., individuals and companies) additional time to continue implementing the necessary changes to comply with the [Final Rule].” The Department’s civil enforcement actions for violations of the Final Rule will not be a priority “so long as the person is engaging in good faith efforts to comply with or come into compliance with the [Final Rule] during that time.” However, the Department makes clear that it will “pursue penalties and other enforcement actions as appropriate for egregious, willful violations” during the delayed enforcement period.
  1. DOJ Will Consider Good Faith Efforts to Comply
While the Implementation and Enforcement Policy reflects that civil actions for violations of the Final Rule will not be a priority, this depends on the entity’s good faith effort to comply. According to this Policy, examples of evidence of good faith efforts may include, but are not limited to:
  • Conducting internal reviews of access to sensitive data.
  • Conducting internal reviews to determine whether transactions involving access to such data flows constitute data brokerage.
  • Reviewing internal datasets and datatypes to determine if they are subject to the Final Rule.
  • Conducting due diligence on potential new vendors.
  • Renegotiating vendor agreements or negotiating contracts with or transferring products or services to new vendors.
  • Adjusting employee work locations, roles or responsibilities.
  • Evaluating investments from countries of concern or covered persons.
  • Implementing the CISA Security Requirements.
  1. “Good Faith” May Include Satisfying CISA Security Requirements 
A good-faith effort to comply may be demonstrated, in part, by implementing the CISA Security Requirements, which were developed concurrently with the Final Rule pursuant to the EO. The security requirements are intended to address threats that arise when conducting restricted transactions, as detailed below. These security requirements are divided into two sections: i) organizational- and covered system-level requirements; and ii) data-level requirements.
  1. Before October 6, 2025, Determine if Your Company is Conducting Restricted Transactions
US entities engaged in restricted transactions under the Final Rule have affirmative data compliance program and audit obligations, among other obligations. In addition, the Final Rule provides that data brokerage transactions are prohibited with any foreign entity unless the US person contractually binds the foreign entity from subsequent transactions of that data with a country of concern or covered person. They must also report any known or suspected violation of this requirement.
  1. An Iterative Review Plan May be Needed for Covered Transactions 
With the Final Rule coming into effect and enforcement nearing, US companies that engage in certain data transactions or share information with third parties that may be covered persons or countries of concern should evaluate their transactions and data practices. After a thorough review of the types of information collected, who that information is shared with, and who is involved in the processing of that data, it may be helpful to adopt a compliance policy to ensure transactions are being handled appropriately in light of the Final Rule.
0

The Do’s and Don’ts of DSARs: A Practical Guide for Responding to Data Subject Access Requests

DSAR, EU, GDPR, State Privacy Laws, United States , , , , , ,
Handling data subject access requests (DSARs) isn’t as easy as ticking a compliance checkbox. It can be a test of an entity’s data organization, internal communication, and understanding of legal requirements. Between navigating jurisdictional nuances and meeting strict deadlines, the DSAR response process can quickly unravel without a clear plan. In this guide, we suggest best practices for handling and responding to DSARs, along with tips and common pitfalls to avoid when planning effective responses.

1.    Understand the Individual’s Ask

Under international data privacy laws, including those in the US and EU, individuals may have rights over the personal data collected about them by covered entities. The way individuals generally actualize those rights are through DSARs submitted to the relevant entities. These rights can include, but are not limited to:
  • Accessing Data: Individuals may request access to all or specific categories of their personal data.
  • Ceasing Data Processing: Individuals may request the entity stop processing their personal data.
  • Data Correction or Deletion: Individuals may request rectification of inaccurate or outdated personal data or even request the deletion of their personal data.
  • Processing Information: Individuals may request what their personal data is used for and why.
  • Portability: Individuals may request to receive a copy of their personal data in a portable format.
When an individual makes a request to exercise one of these rights, the entity must then respond to the request within a set time frame determined by the applicable law. These time frames differ between applicable laws, so the first step is ensuring you know the appropriate time frame to apply. Who can submit a DSAR? DSARs may be submitted by individuals whose data is processed by entities under the scope of laws like the GDPR and US state privacy laws. Depending on the jurisdiction, DSARs may also be submitted by employees of the covered entity or by agents appointed by the individual and authorized to submit DSARs on the individual’s behalf. Why are DSARs important? DSARs allow individuals to determine what information a covered entity holds about them, how it’s being used, and why it is being processed. In short, they empower individuals to understand and exert some control over their personal data. Additionally, DSARs serve as a tool to confirm that covered entities are upholding their promises: by using these requests, individuals can check whether entities are adhering to both privacy laws and customer privacy notices. This allows individuals to better hold entities accountable for lawful data processing.

2.    Build A Response Team

Given the complexity of modern data systems, internal collaboration is essential when handling DSARs. Clear communication helps ensure DSARs are handled effectively—especially for more comprehensive requests, like deleting or accessing an individual’s data. To build your response team, start by identifying key players. Privacy officers can help oversee legal and regulatory compliance, data experts can help retrieve and process data securely, and communication teams can help draft clear responses to requests and questions. While the specific structure of each team will vary based on the covered entity’s size and complexity, every member of the team should understand the DSAR requirements and specific responsibilities, and get proper training based on their role. Do: Train Your Team       Training is critical to help every member of the team understand the importance of DSARs and their role in maintaining compliance. This isn’t about knowing the legal jargon—each team member should be able to recognize these requests (even if worded in a vague or informal way) and how to execute the steps required to meet deadlines. Since each DSAR is unique, teams should also have a clear point of contact for guidance and next steps if there is any confusion. Don’t: Delay Decisions Effective responses generally take effective planning. Because of the tight DSAR response deadlines imposed by applicable laws, covered entities should plan for these requests before they arrive. By defining clear rules, covered entities can avoid last-minute confusion and chaos when responding to DSARs.

3.    Prepare A Playbook

The regulatory landscape governing DSARs is far from uniform. Because each law may have its own requirements and response timeline, it is essential to understand jurisdiction-specific obligations. A playbook is a simple way to address these obligations in one place and guide the response team through a step-by-step process. To create a playbook, consider:
  • Legal scope: Identify applicable laws based on where the entity operates and whose personal data they process.
  • Verification requirements: Confirm the verification requirements, if any, under each law to determine what steps are needed to confirm the identity of the individual submitting the DSAR.
  • Data retrieval methods: Determine what tools and workflows are needed to locate and compile data efficiently, and how this information may be transmitted to the individual, if necessary.
  • Template responses: Draft standardized responses for anticipated outcomes, like fulfillment or denial of requests, or requests for additional information.
  • Escalation plans: Provide guidance for handling complex requests.
Playbooks should be regularly reviewed to reflect changes in regulations or operational processes. Do: Note the Nuances of Each Law Laws that provide individuals with rights over their personal data commonly include exemptions, such as data that is covered by other laws. Double-check and note these requirements for each jurisdiction and ensure that the playbook is marked in a way that users can easily understand it. Don’t: Forget to Customize Using the same strategy for every DSAR risks a misstep in responses. Privacy laws are often unique, and failing to adapt to these nuances can lead to delays, incomplete responses, or even regulatory penalties. By making your playbook specific to both your entity’s needs and the requirements of each jurisdiction, you are better preparing your team to handle DSARs.

4.    Respond Effectively

Most data privacy laws require a response within a certain time frame from when the request was received. In other words, once a DSAR is received, a clock usually starts ticking. We suggest the following steps as a starting place for a well-executed response, but your steps should be tailored to the applicable legal requirements:
  1. Acknowledge the Request: Confirm the request and provide a clear timeline for how the request will be handled.
  2. Verify the Identify (as needed): Ensure the individual’s identity is confirmed, if required by the relevant laws.
  3. Locate and Collect Data: Collaborate across departments as needed to gather the relevant information.
  4. Review Data for Exceptions: Identify data that may be exempt from disclosures or require redaction, like data that pertains to another individual.
  5. Respond Clearly: Deliver the response in a clear, accessible format with an explanation of how that response was arrived at.
  6. Record and Learn: Maintain detailed records for accountability and review the process regularly.
 Do: Build a Feedback Loop    The best way to learn is by doing. After developing your playbook, perform a trial exercise to ensure your communication is streamlined and a test request is handled as expected. Then, talk to your team to review what went well and what improvements are needed. By viewing this process as iterative, with modifications and refinements made along the way, the DSAR response team can effectively grow and shift with the volume of requests or any regulatory changes. Don’t: Overlook Redaction and Exemptions Redaction and exemptions can easily be overlooked, but neglecting these steps can lead to non-compliance, or even a breach. Always double-check any information before it is disclosed and verify that all information is accounted for and handled appropriately.   While typically seen as a compliance obligation, DSARs can also present an opportunity for entities to demonstrate data privacy and transparency. Each DSAR is a chance to refine operations, and with a capable response team and a detailed playbook, entities can approach the process with a better understanding of compliance.
1 2 3 … 5