Key takeaways

  • Panasonic Operational Excellence, which runs shared back-office functions for Japan's Panasonic Group, said on October 23, 2026 that a member of an HR system project had uploaded personal data to an external generative AI service the company had banned.
  • About 334,000 people are affected: roughly 75,000 current employees and 178,000 former employees going back to 1978, with employee numbers, addresses, phone numbers and emails, and 81,000 family members registered as emergency contacts, with names as well.
  • It was not an attack. Panasonic says the AI provider told it the training setting was off and the data was not used to answer anyone else, but that deleted data is kept for 30 days; that period ended on October 25.
  • Panasonic reported the incident to the privacy regulator on September 29 and published its notice almost four weeks later, as a substitute for notifying each person. It has not named the AI service.
  • In our view, it is a clear case of shadow AI: a written ban that nothing technical enforced, in a project that had a large extract of personal data to hand. Blocking every unapproved AI service is hard to run; detecting personal data and blocking bulk uploads is the more realistic control. Even with approved AI, deciding what client information may go in is too hard to leave to each employee. It is time to look at technical controls, starting with a fresh look at DLP, since AI services are only one of many places data can go.

What happened#

Panasonic Operational Excellence (PEX) is running a project with its subsidiary Panasonic Digital to introduce a new HR information system for Panasonic Group companies in Japan. During that project, a project member uploaded data from the existing HR system, as it stood in April 2026, to an external generative AI service. PEX prohibits the use of that service.

Panasonic calls it a rule violation by the project member, not an outside attack. After it was discovered, the member deleted the chat history and the data on their work PC. Panasonic has not said when the upload happened, how it was found, why the data was uploaded, or which AI service was used.

Date (2026) Event
April The HR data involved is a snapshot from this month
Not disclosed Data uploaded to the banned AI service; discovered; chat history and local copies deleted
Sep 29 Reported to the Personal Information Protection Commission
Oct 23 Public notice
Oct 25 The AI provider's 30-day retention of deleted data ends

Whose data#

Who People Data
Current employees about 75,000 Employee number, address, phone, email (no names)
Former employees, who left from 1978 to this year about 178,000 Same as above
Employees' family members registered as emergency contacts about 55,000 Name, address, phone, email
Former employees' family members, for those who left since 2016 about 26,000 Same as above

Former employees include people who moved to companies that bought Panasonic businesses. The family data covers only people an employee had registered in the system as an emergency contact.

What the AI provider said#

Panasonic asked the operator of the AI service what had happened to the data. According to Panasonic, the provider said:

  • The setting that lets the provider use input data to train its AI was turned off when the data was uploaded, so the data would not appear in answers to other users.
  • When a user deletes data, the provider still keeps it for 30 days for security and legal compliance, under strict access control, and accesses it only for audits and similar requests.
  • The data deleted right after discovery would therefore be gone from the provider's systems from October 25.

On that basis, Panasonic says the data will not be used further, and that it has found no sign of publication or misuse. It tells the people affected that they do not need to do anything.

How the law treats it#

Employee data is personal data. Japan's Act on the Protection of Personal Information (APPI) makes no distinction between customers and staff. The details a company holds on its employees, former employees and their emergency contacts are personal information, and in an HR system they are personal data, covered by the same duties as customer data: security measures, supervision of contractors, and the rules on reporting breaches.

Legally, the AI is incidental. What matters is that personal data was sent to an outside service the company had not approved. That is handled the same way as an email sent to the wrong address or a file copied to someone's personal cloud storage: the data has left the company's control, which makes it a breach (漏えい等). Panasonic's notice does not describe the upload as using data outside its purpose of use or as providing it to a third party. It followed the breach rules: it reported to the Personal Information Protection Commission (PPC) and published a notice that, it says, serves in place of notifying each person individually. Those rules apply to any breach of more than 1,000 people, as we explain in our guide to the notification rules, and this one involves about 334,000.

Approved AI is a different matter. Companies can put personal data into generative AI services they have approved and set up properly, and many already do. The conditions are the same as for any outside service that handles personal data:

  • The use has to fall within the purpose for which the data was collected. Using HR data for HR work usually does.
  • The provider relationship has to be settled, typically as outsourcing under contract, which needs no consent but makes the company responsible for supervising the provider. The provider must not use the data for its own purposes, such as training. The PPC's June 2023 caution on generative AI centered on exactly this point.
  • The company has to control who can access the service, how long data is kept, and how it is deleted.
  • If the provider handles the data abroad, Japan's rules on transfers to other countries come into play, and how they apply depends on the arrangement.
  • Only the data actually needed should go in. Masked data is often enough.

In our view, the difference between Panasonic's incident and routine use of an enterprise AI tool is not the technology but whether the use sits inside the company's controls: a contract, settings the company manages, and supervision. The same AI service, used through a personal account with unknown settings, would raise exactly the same problem. It is why Panasonic had to ask the provider, after the fact, how long the data would be kept.

Our analysis#

Shadow AI, in numbers#

Most of Japan's breaches this autumn have been attacks: attackers exploiting vulnerabilities and APIs, often with AI tools of their own, as our analysis of the year's largest breaches shows. This one is different. It is an insider, most likely trying to get work done faster, pasting a large data extract into a tool the company had told staff not to use. Security teams call it shadow AI, and it is rarely disclosed at this scale.

The detail that matters is that the service was already banned. A written rule did not stop the upload.

The cleanest way to enforce a ban is to make the service unreachable from the corporate environment. In practice, that is hard to run. New AI services appear every week, AI features are built into SaaS tools the company already approves, and staff work from home and on devices the network does not fully see. A block list is always behind, and blocking too broadly gets in the way of legitimate work and pushes people to personal devices, where the company sees nothing at all.

In our view, the more realistic control targets the data rather than the destination: detect personal data in what is being sent out, and block or hold bulk uploads of it, to AI services or anywhere else. An HR extract with tens of thousands of addresses and phone numbers is exactly the kind of upload such a control is good at catching, whatever tool it is headed for. It will not stop someone pasting a few records into a chat, and it is much weaker for confidential business information, which has no fixed pattern to detect. But it targets the incidents that matter most for personal data: the ones measured in hundreds of thousands of people. Combined with an approved AI tool good enough that people do not need the banned one, it narrows the gap a written rule leaves open.

Approved is not the end of the question#

Even with an approved, well-configured AI tool, deciding what may go into it is hard in practice. In our experience of security consulting, it is one of the questions organizations struggle with most, and it does not get easier when the tool is approved.

Personal data is, if anything, the easier case. The privacy law at least provides a framework: purpose of use, outsourcing, supervision. But much of what a client entrusts to a company is not personal data at all: system designs and network diagrams, configuration files, source code, findings from security assessments, product plans, contract terms, figures that have not been published. None of it falls under the privacy law. It is governed by contracts, confidentiality agreements and, for some of it, the rules on trade secrets, which say far less about where the line is. A list of a client's unpatched vulnerabilities contains no personal data, yet in the wrong hands it is a map for attackers.

The difficulty is that the answer depends less on the tool than on the data. A document can carry personal data from several sources collected for different purposes. Customer or client data often comes with contracts that limit who may process it and where, and an NDA signed years ago did not anticipate AI. A client's own policy may forbid what your company allows. Data that looks harmless alone can identify people when combined. And staff have to make the call in seconds, in the middle of a task.

Rules are still needed. A small number of clear data categories with a rule for each, such as public, internal, client-confidential and personal data, defaults that keep the most sensitive categories out unless a contract or the client explicitly allows it, and a quick route to ask someone when in doubt, give staff something to work from.

But in our view, rules alone ask too much of employees. They are being asked to make judgments that even security and legal specialists find hard, quickly and repeatedly, in the middle of other work. It is time for organizations to look seriously at technical controls that take some of those decisions out of individual hands.

The starting point is more basic than a new AI product. AI services are only the newest place data can go; it can just as easily leave by email, file sharing, personal cloud storage, chat tools, other SaaS or a USB stick. In our view, the right response is to revisit data loss prevention (DLP) as a whole, built around the data rather than any one destination:

  • Know and label the data: sensitivity labels on documents and data sets, including client-confidential material, so that controls have something to act on
  • Cover every outbound channel: endpoints, email, web and cloud uploads, and SaaS, with AI services treated as one more destination rather than a separate problem
  • Act on bulk and on labels: block or hold large volumes of personal data and anything labelled restricted, wherever it is headed, and mask data automatically where the work allows
  • Log and review: so that mistakes are found in days, not weeks

Purpose-built AI gateways, which inspect and mask what goes into approved AI tools, can sit on top of this, as can separate environments for each client's work. But without the basic layer underneath, they only guard one door. None of these controls is perfect, and confidential business information remains harder to detect than personal data. What they do is move the decision from a person under time pressure to a control that applies the same rule every time. The Panasonic case is the extreme end of the problem: a full HR extract, an unapproved tool, and nothing in between to stop it.

System migrations are high-risk moments#

The upload happened during an HR system implementation. Projects like this routinely produce full extracts of production data for mapping, cleansing and testing, and that is exactly the kind of task people now hand to AI tools. In our view, organizations should treat migrations as a distinct risk: use masked or synthetic data wherever possible, limit who handles real extracts, and give project teams an approved AI environment that is cleared for the data they actually work with.

Why was 1978 still there?#

Former employees going back to 1978 were in the HR system, and so were the family contacts of people who left as far back as 2016. Some records must be kept for years under employment and pension rules. But emergency contacts for people who left years ago, and contact details for employees who retired almost half a century ago, are hard to justify. It is the same lesson as the license images Times Car kept for seven years: data that is no longer needed cannot be uploaded, leaked or stolen. A system migration is also the natural moment to decide what not to carry over.

Trusting the provider's word#

Panasonic's assurance that the data will not be reused rests on what the AI provider told it: training was off, and deleted data is kept for 30 days and then removed. That is plausible for a major provider, and the 30-day period is typical. But it is an assurance Panasonic cannot verify, about a service it had not approved and has not named. For enterprise AI contracts, retention periods, training settings and audit rights are negotiated up front. With a banned service, the company learns the terms after the fact.

Quiet but not fast#

Panasonic reported to the regulator on September 29 and published on October 23, almost four weeks later, using its notice as a substitute for telling each person. Given the low risk of misuse, the decision not to ask people to do anything is reasonable. But former employees and family members, who may not follow Panasonic news, learned of it only if they found the notice. In our view, a notice addressed to them through the channels the company still has, such as pension and alumni contacts, would have been worth the effort.

What this means for readers#

  • If you worked for a Panasonic Group company in Japan, or are registered as a family emergency contact, your contact details may have been involved. Panasonic says no action is needed; be wary of any message that refers to this incident and asks for information or payment.
  • If you run security or privacy for an organization, check whether your AI policy is enforced or only written. Blocking every unapproved AI service is hard to sustain; detecting personal data in outbound traffic and blocking bulk uploads is more workable. Pair it with an approved AI tool with clear data terms.
  • If you already have an approved AI tool, do not leave each employee to decide what goes into it. Define a few data categories with clear rules that cover confidential business information, not only personal data, and revisit your DLP across every outbound channel, with AI services as one more destination, so the hardest calls are not made by individuals under time pressure.
  • If you are planning a system migration, decide what data you will not migrate, use masked data for testing, and give the project team explicit rules and tools for AI use.
  • If you use an AI service under contract, know its retention period, training setting and audit rights before an incident, not after.

Japanese terms at a glance#

Japanese Reading Meaning
生成AI seisei AI Generative AI
外部生成AIサービス gaibu seisei AI sābisu External generative AI service
アップロード appurōdo Upload
ルール違反 rūru ihan Rule violation
人事情報システム jinji jōhō shisutemu HR information system
本人通知の代替措置 honnin tsūchi no daitai sochi Substitute for individual notice
緊急連絡先 kinkyū renrakusaki Emergency contact