AI Data Breach: Real Cases, Causes, and How to Prevent One
Updated: July 2026
An AI data breach rarely looks like a hacker cracking a firewall. It looks like an engineer pasting confidential code into a chatbot, a vendor leaving a database open on the internet with no password, or a bug that quietly exposes other users’ conversations for a few hours before anyone notices. The cases below happened to OpenAI, Samsung, DeepSeek, and Clearview AI, and each one shows a different way personal or confidential data ends up exposed through AI systems.
Wichtigste Erkenntnisse
• A bug in ChatGPT exposed other users’ chat titles and, for some subscribers, payment details for roughly nine hours in March 2023, leading Italy’s data protection authority to temporarily halt OpenAI’s processing of Italian users’ data.
• Samsung engineers pasted confidential source code and meeting notes into ChatGPT three separate times within 20 days in 2023, prompting the company to ban generative AI tools for staff.
• In January 2025, security researchers found an unsecured DeepSeek database sitting open on the internet with no authentication, exposing over a million lines of chat logs and internal API keys.
• Under GDPR, the organisation that decides why an AI system processes personal data is the controller and carries primary liability for a breach, even when a vendor’s system is where the failure actually happened.
What Is an AI Data Breach?
An AI data breach is any incident where personal or confidential data is exposed, stolen, or accessed without authorisation through an AI system, whether the AI itself is the point of failure or simply the route the data travelled through. That covers several distinct scenarios: a vendor’s AI infrastructure left insecure, as with DeepSeek’s exposed database; an AI model’s own behaviour leaking data it was never supposed to reveal, as in OpenAI’s March 2023 bug; or an employee voluntarily feeding sensitive data into a public AI tool that was never built to keep it confidential, as Samsung’s engineers did.
The distinction from a conventional data breach is where the failure sits. A traditional breach usually involves someone getting into a database they shouldn’t have access to. An AI-related breach can happen through the model’s output, through infrastructure supporting the model, or through an employee’s own use of a tool the organisation never approved in the first place.
What Happened When a ChatGPT Bug Exposed User Data?
On 20 March 2023, a bug in an open-source library ChatGPT relied on caused some users to briefly see other users’ chat titles and, for a subset of ChatGPT Plus subscribers, payment-related details including partial card numbers and names, during a roughly nine-hour window. Italy’s data protection authority, the Garante, ordered OpenAI to stop processing Italian users’ data on 30 March 2023, citing the breach itself, OpenAI’s failure to report it under GDPR’s Article 33 notification rules, the lack of a clear lawful basis for training the model on personal data, and the absence of age verification. OpenAI restored access to Italian users about a month later, after adding a privacy notice, an opt-out for having conversations used in training, and age verification controls.
The story did not end there. In December 2024, Italy’s Garante fined OpenAI €15 million over the same underlying issues: processing personal data to train ChatGPT without an adequate legal basis, and failing to notify the March 2023 breach on time. The regulator also ordered OpenAI to run a six-month public awareness campaign in Italy about how ChatGPT collects and uses personal data.
What Happened When Samsung Engineers Leaked Source Code to ChatGPT?
In April 2023, within 20 days of Samsung’s semiconductor division allowing staff to use ChatGPT, engineers pasted sensitive internal material into the chatbot on three separate occasions. One engineer entered confidential source code while troubleshooting a bug, a second uploaded a transcript of an internal meeting to generate notes, and a third used the tool to optimise code for identifying defective chips. None of that data was Samsung’s to share. Once entered into a public chatbot, it became part of a system Samsung did not control and could not retrieve.
Samsung banned employee use of ChatGPT and other generative AI tools on company devices in May 2023 and opened internal investigations into the three staff involved. The case became one of the most cited examples of what security teams now call shadow AI: employees using AI tools the organisation never vetted, outside any data governance process, often because the tool is genuinely useful and no approved alternative exists yet.
What Happened When DeepSeek Left a Database Exposed?
On 29 January 2025, security researchers at Wiz Research discovered a ClickHouse database belonging to Chinese AI company DeepSeek sitting open on the public internet with no authentication required. The database held more than a million log entries, including plaintext user chat history, backend API keys and secrets, and internal operational details, all queryable by anyone who found the address. Wiz reported the exposure to DeepSeek, which secured the database shortly afterwards.
The DeepSeek case is a reminder that an AI data breach does not need a skilled attacker. It needs an unsecured service left reachable from the internet, the kind of basic infrastructure mistake that would be just as damaging with any other type of database.
What Happened When Clearview AI’s Client List Was Stolen?
In February 2020, facial recognition company Clearview AI disclosed that an intruder had gained unauthorised access to its full client list, including which organisations were customers, how many user accounts each had set up, and how many searches they had run. Clearview said its core systems and the underlying database of billions of scraped photos were not compromised, and that the intruder did not obtain any law enforcement agency’s search history.
The breach mattered less for its technical scope and more for what it revealed: the client list itself was sensitive, since it identified which police forces and companies were using a facial recognition tool built on billions of images scraped without consent. Even data that seems administrative, like a customer list, can carry real risk when the underlying business is processing personal data at that scale.
Who Is Liable When an AI System Causes a Data Breach?
Under GDPR, liability starts with the controller: whichever organisation decides why the data is being processed. If your business collects customer data and feeds it into a third-party AI tool, your business is very likely the controller, and that responsibility does not transfer to the AI vendor just because the vendor’s infrastructure is where the breach happened. Article 28 GDPR requires a Data Processing Agreement wherever a vendor processes personal data on your behalf, and that agreement needs to cover the vendor’s security obligations specifically, not just general confidentiality.
Where an AI vendor’s own negligence causes the breach, such as DeepSeek leaving a database open, the vendor can face its own liability, and Article 82’s joint and several liability rules mean an affected individual can pursue whichever party in the chain is best positioned to pay. Contracts with AI vendors should specify security responsibilities, breach notification timelines, and audit rights before that vendor ever touches production data, not after an incident forces the question.
What Does GDPR Require After an AI-Related Data Breach?
The same rules apply regardless of whether AI was involved. Article 33 requires notifying the relevant supervisory authority within 72 hours of becoming aware of a breach likely to risk individuals’ rights and freedoms. Where the risk is high, Article 34 adds a requirement to notify the affected individuals directly. OpenAI’s Italian case shows what happens when that notification does not happen on time: the missed Article 33 deadline was one of the specific violations the Garante cited, separate from the breach itself.
Our guide to what counts as a personal data breach covers how to assess whether a given incident, AI-related or not, crosses the threshold that triggers these obligations.
How Can You Prevent an AI Data Breach?
Most of the incidents above trace back to a small number of preventable gaps, not exotic new attack techniques. A practical prevention programme covers several areas at once.
• Set a clear, written policy on which AI tools staff can use and what data they can enter into them, and give employees an approved alternative before banning the unapproved one. Samsung’s case shows what happens when useful tools spread faster than governance does.
• Run a Data Protection Impact Assessment before deploying any AI system that processes personal data, covering how data flows through the system, where it is stored, and what happens if a vendor’s infrastructure is compromised.
• Treat AI vendor contracts like any other processor relationship: require a signed Data Processing Agreement, ask for evidence of security certifications, and build in the right to audit.
• Apply basic infrastructure security, authentication on every database, encryption at rest and in transit, and regular access reviews, to AI systems with the same rigour as any other production system. Nobody had to break into DeepSeek’s database; it simply had no password.
• Train staff specifically on what not to paste into public AI tools, since policy alone does not stop someone from pasting code into a chatbot to solve a problem quickly, as Samsung’s engineers did.
What Should a DPIA for an AI System Cover?
A Data Protection Impact Assessment for an AI system needs to go beyond the standard questions asked of any new processing activity. It should identify what personal data the system has access to and whether that access is broader than the task actually requires, assess whether the AI vendor’s own infrastructure has been independently reviewed for basic security failures, document what happens to data submitted to the system, including whether it can be used for further training, and set out a plan for what the organisation would do if the vendor experienced a breach.
Reviewing the assessment whenever the system changes, not just once before launch, catches the kind of gap that let DeepSeek’s database sit exposed for as long as it did.
Schlussfolgerung
The cases here span a regulator halting a chatbot over a nine-hour bug, engineers pasting code into a tool with no way to get it back, a database left open with no password, and a client list stolen from a company built on scraped photos. None of them required a novel attack method. They came from missing notification processes, missing governance over which tools staff could use, and missing basic security controls on AI infrastructure. Preventing the next one means treating AI systems as exactly what they are: processors of personal data, subject to the same GDPR obligations as any other system, with a few extra risks specific to how these tools actually work.
Frequently Asked Questions
What makes an AI data breach different from a traditional data breach?
The failure point is different. A traditional breach usually involves unauthorised access to a database. An AI-related breach can happen through the model’s own output, through the vendor’s supporting infrastructure, or through an employee entering sensitive data into a public AI tool the organisation never approved.
Is a company liable if an employee causes a breach by using an unapproved AI tool?
Generally, yes. The organisation is the data controller for the information its employees handle, and GDPR does not distinguish between a breach caused by external attackers and one caused by an employee using an unapproved tool. This is why a written, enforced policy on approved AI tools matters as much as technical security controls.
Do AI vendors need to sign a Data Processing Agreement like any other vendor?
Yes, wherever the vendor processes personal data on your organisation’s behalf. Article 28 GDPR requires this regardless of whether the vendor is a payroll provider, a CRM platform, or an AI tool, and the agreement needs to cover the vendor’s specific security obligations and breach notification commitments.
Disclaimer: This blog post is intended solely for informational purposes. It does not offer legal advice or opinions. This article is not a guide for resolving legal issues or managing litigation on your own. It should not be considered a replacement for professional legal counsel and does not provide legal advice for any specific situation or employer.
About the Author
Ana Mishova
Sales and Business Development Consultant — GDPRLocal
Ana focuses on helping organisations understand their compliance obligations and find the right data protection solutions. At GDPRLocal she works closely with businesses of all sizes, making GDPR and privacy compliance clear, practical, and accessible.
About the Author
Sales & Business Development Consultant
Ana Mishova is a Sales & Business Development Consultant at GDPRLocal, the UK’s fastest-growing B2B compliance partner. With four years at the company, she has experience across operations, from creating processes and shaping compliance services to driving growth through sales, marketing, and strategic partnerships.
Her prior experience includes working closely with current and prospective clients and coordinating with stakeholders to design and plan compliance products. She has led internal change initiatives, driven sales, and guided organisations in selecting the most appropriate compliance strategies.
She holds a degree in psychology, which enhances her ability to connect with people and understand their needs. At GDPRLocal, she works with colleagues to strengthen the sales function and plays an active role in developing the sales strategy.