As ChatGPT, Claude and enterprise AI tools enter everyday management, a new legal risk is emerging. When directors or non-lawyer executives use generative AI to analyse contracts, employment relationships, regulatory investigations, M&A disputes or potential litigation, could those conversations later be subject to discovery? And if the records are obtained, how will a court decide who actually entered the prompts and how much evidential weight the records deserve?
This is no longer simply a question of data privacy or acceptable AI use. It sits at the intersection of document production, legal professional privilege, authentication of electronic evidence, litigation holds and corporate governance.
AI chats may be discoverable, but discovery is not the verdict
Any discussion of the litigation risk in AI conversations must begin by separating three distinct questions.
The first is document discovery or production. If an AI conversation relates to disputed facts, management’s motives, contract interpretation or later conduct—and remains in the possession or control of the company or a relevant person—it may fall within the scope of documents that must be produced in litigation.
The second is legal professional privilege. Even if a record is relevant, a company may try to resist production by asserting legal advice privilege or litigation privilege. But a non-lawyer executive who asks an AI system for legal advice will usually struggle to obtain legal advice privilege merely because the subject is legal. An AI system is not a qualified lawyer, and the exchange does not create a conventional lawyer–client relationship. Adding “Privileged and Confidential” to a prompt does not create privilege either.
The third is admissibility and probative weight. A chat that has been produced is not automatically admissible, and a court will not necessarily accept its contents at face value. The court may still ask whether the record is authentic, whether it was altered, who entered the prompt, whether the relevant person read or adopted the output, and whether the conversation is corroborated by other evidence.
Why AI conversations are especially dangerous in litigation
Directors and executives usually choose their words carefully in formal emails, board papers and communications with counsel. In an AI chat, however, users are often more direct—and more likely to put their real objective into the prompt.
A manager may never write “How can we avoid paying the earnout under the acquisition agreement?” in a formal document, yet ask an AI system exactly that. The manager might ask whether an executive can be removed first and facts supporting a for-cause termination found later, or how to take control of a subsidiary while reducing the risk of being found in breach.
In that setting, whether the AI’s answer is legally correct may not be the most important point. The more probative material may be the question the user chose to ask. A prompt can reveal what management knew, what it feared and what outcome it was actually trying to achieve.
If a company later says that an executive was terminated purely for poor performance, while its CEO had previously asked AI how a termination could avoid a large earnout, opposing counsel may use the chat to challenge the company’s explanation and argue that the performance rationale was a pretext developed after the event.
Krafton: how AI records entered the court’s fact-finding
Fortis Advisors, LLC v. Krafton, Inc. is one of the most closely watched examples. It was a commercial contract case in the Delaware Court of Chancery, not a criminal prosecution. It is therefore inaccurate to describe the AI chats as “evidence of conviction.” More precisely, the records became important adverse evidence as the court assessed the company’s true motive, whether its stated grounds for termination were pretextual, and whether it had breached the acquisition agreement.
Krafton’s acquisition of Unknown Worlds involved a fixed purchase price and a contingent earnout of up to approximately US$250 million. The former management retained significant operational control for a defined period, and key employees could generally be terminated only if contractual “Cause” existed.
As the target company’s game approached release, Krafton’s internal projections indicated that a large earnout might become payable. Management then began exploring how it could take control of the target, and whether changing the management team, altering the release date or reinterpreting the agreement could reduce the payment obligation.
The court record showed that Krafton’s CEO used ChatGPT to discuss whether removing management could cancel the earnout and, if renegotiation failed, how to create leverage, control game-publishing rights, prepare legal defences and shape the public narrative. Some of the AI-generated strategies were subsequently shared with other executives.
The company then took several steps that closely tracked the AI plan: it took control of Steam publishing rights, prepared contractual and legal-defence materials, applied pressure to the former management, and ultimately removed key executives and assumed operational control.
The court did not decide the case because “ChatGPT said so,” nor did it treat the AI system as a legal expert or fact witness. The significance of the chats was that they helped the court understand management’s thinking at the relevant time and connect internal financial projections, Slack messages, executive testimony, circulation of the AI plan and the company’s subsequent conduct into a coherent evidential chain.
Another important feature of Krafton was that the CEO admitted using ChatGPT, acknowledged sharing the relevant strategy, and admitted deleting some relevant chat logs. The case therefore did not present a serious dispute over whether somebody else might have used his account.
An account in someone’s name does not prove who entered the prompt
In other cases, attribution of the AI record to a particular user may become a genuinely difficult forensic issue.
A chat found in an account bearing the name of a director or CEO establishes, at most, an initial link to an account associated with or controlled by that person. It does not automatically prove that every prompt was personally entered by the account holder.
Passwords may be shared; assistants may operate the account; browsers may remain signed in; company devices may have several users; credentials may synchronise across devices; and accounts may be compromised. Authenticity of an electronic record and identity of the person who used the account are therefore separate questions.
An official platform export may show that a particular account generated a conversation at a particular time. It may not establish who was sitting at the keyboard, or whether the account holder ever read or adopted the AI’s response.
Courts will usually assess a combination of evidence: account login data, enterprise SSO, MFA, IP addresses, device information, browser history, local caches, chat exports, screenshots and later forwarding records.
The content of the chat may provide further clues. A prompt containing a non-public acquisition price, an internal project code, details of a board discussion or a financial forecast known only to a small group may support an inference about who the real user was.
What happened after the conversation is often more powerful. Suppose an AI system recommends locking a publishing platform and the CEO gives the same instruction to IT the next day. Or suppose AI produces a “no-deal response strategy” that the CEO then forwards to the head of strategy. The evidence is no longer limited to a chat sitting in an account. It becomes a continuous sequence from AI inquiry to internal circulation, management direction and implementation.
In civil litigation, a court generally applies the preponderance or balance-of-probabilities standard. A party need not prove that nobody else in the world could possibly have accessed the account. Merely suggesting that “anyone who knew the password could have typed it” will often be too abstract to displace a complete circumstantial chain. A meaningful denial usually requires specific evidence: that the account was in fact shared, that the relevant login came from an assistant’s device, or that the executive did not have access to the device at the time.
Using an API or an open model does not make the records disappear
Some companies assume that avoiding the ChatGPT website—by calling a model through an API or deploying an open-source model on local servers—will prevent discoverable chat records from being created. That assumption is unreliable.
“Open source” describes the model’s code, weights or licence. It says nothing about whether usage records exist. The decisive questions are where the model is deployed, which systems carry the request, whether logging is enabled, how long data is retained, and who controls the relevant servers, databases and devices.
In an enterprise API architecture, a single request may pass through an internal AI front end, an API gateway, an identity provider, logging systems, databases, a model provider and backup systems. Each layer can retain a different part of the record.
The internal application may store the user’s input, conversation history, system prompt, uploaded files, RAG context, API request, model output, request ID, identity, timestamp and tool calls. The gateway may retain source IPs, service accounts, endpoints, token usage and error logs. The identity platform may hold SSO and MFA records. Even when a chat is deleted from the primary database, it may remain in snapshots, disaster-recovery copies, virtual-machine images or log archives.
Forensic analysis must also recognise that the prompt visible on screen may not be the full request received by the model. The actual payload can include system instructions, earlier messages, hidden enterprise policies, internal knowledge-base results and outputs returned by external tools. A request for production may therefore reach beyond the visible question and answer to the complete payload, every message, retrieval context and tool-call record.
Local models can leave extensive electronic traces
If a model runs on company servers, the external model provider may have no copy of the conversation. The company’s own environment, however, can still contain extensive evidence.
Records may reside in a front-end SQLite or PostgreSQL database, inference-server logs, web-server access logs, enterprise SSO, browser local storage, Jupyter notebooks, Python scripts, terminal history, Docker or Kubernetes logs, virtual-machine snapshots, database backups, exported Markdown or PDF files, and AI outputs later sent through email, Slack or corporate reports.
Where the company uses RAG, a vector database and retrieval logs may also reveal which internal documents the model consulted. Even if the original chat no longer exists, subsequent documents and system records may reconstruct part of what happened.
At the extreme—an entirely local model, no chat interface, no application logging and no saved or forwarded output—the original prompt and answer may genuinely be unavailable. Even then, there may be indirect traces in shell history, notebook cells, temporary files, swap space, clipboards, screenshots, residual disk data, GPU activity records or witness testimony.
Rerunning the model cannot reliably reconstruct the original answer
If the original record is gone, can the company recover it by submitting the same prompt again? Usually not.
Generative-AI output may depend on the model version, temperature, seed, system prompt, conversation history, uploaded files, RAG results and tool outputs. The same visible question may produce a different answer.
A rerun can show that the model might produce similar content. It cannot prove what the model actually produced at the relevant time.
If an enterprise wants high-risk AI activity to remain auditable or reproducible, it needs the original request and response together with the model name and version, local model-file hash, system prompt, parameters, conversation history, RAG sources, tool calls, request ID and timestamp.
Having no logs is not a way around discovery
A company may legitimately design a system not to retain full prompts, or to keep technical logs only briefly, for reasons of data minimisation, privacy or information security. If no litigation was pending or reasonably anticipated and data was deleted automatically under an established policy, there may later be no conversation record to produce.
The position changes once a dispute exists or litigation is reasonably foreseeable. Deleting an AI chat database, disabling logs, clearing terminal history, overwriting backups, destroying devices or instructing staff to clean their personal AI accounts may then become a preservation issue.
In a serious case, a court may discount a witness’s credibility, draw an adverse inference that deleted material would have harmed the deleting party, or impose procedural sanctions or costs.
A no-logs architecture can be a prospective data-governance policy that is consistently applied. It cannot properly be used as a selective clean-up mechanism after a dispute has arisen.
How Singapore law may treat AI conversations
As of publication, Singapore’s reported decisions have not developed a complete body of rules specifically addressing legal discussions between non-lawyer executives and generative AI. Existing principles nevertheless point in a reasonably clear direction.
Legal advice privilege in Singapore remains centred on confidential communications between a client and a qualified legal adviser for the purpose of seeking or giving legal advice. A direct legal inquiry from an executive to an AI system would not ordinarily fall within that relationship. Enterprise deployment and strict access controls can improve confidentiality, but they do not turn AI into legal counsel.
Litigation privilege can, in appropriate circumstances, cover communications involving third parties. It will usually be necessary to show that litigation was reasonably contemplated and that the dominant purpose for creating the material was preparation for that litigation. A mixed AI conversation about commercial negotiations, avoiding a payment, product timing, public relations, personnel decisions and legal risk may make that dominant purpose difficult to establish.
Singapore courts dealing with electronic evidence will also distinguish between whether a system generated a record, whether its contents are authentic, and who actually operated the system. A platform export may help prove that an account generated a conversation; whether the account holder was the user still depends on the combined login, device, content and conduct evidence.
If an AI record relates to the dispute and is adverse to the producing party, describing it as internal, personal-account material or commercially confidential will not by itself remove it from document-production obligations. The key questions remain relevance, possession or control, and whether a valid privilege or other legal ground applies.
How companies should design AI governance
AI logging creates a genuine governance tension. More complete records make it easier to investigate misuse, attribute responsibility and establish who used the system—but may also enlarge the pool of sensitive material that must be produced in litigation. Fewer records may reduce the impact of a data breach, while making it harder to reconstruct events during an incident, investigation or lawsuit.
The sensible answer is not “retain everything” or “retain nothing,” but tiered retention based on risk.
Companies should prohibit shared AI accounts and use individual enterprise identities, SSO and MFA to establish basic attribution. Matters involving actual or potential litigation, major contract disputes, termination of key personnel, post-acquisition control, regulatory investigations, whistleblowing, director liability or significant tax disputes should first be assessed by the legal team, including whether AI should be used and in what environment.
For ordinary low-risk use, the system might retain only identity, timestamp, request ID, model version, device and whether a file was uploaded. For higher-risk legal, M&A, financial, regulatory and employment uses, it may be appropriate to preserve the complete prompt and response, system prompt, RAG sources, tool calls, edits and forwarding records—subject to strict access controls and retention periods.
Once litigation begins or becomes reasonably foreseeable, the legal hold should extend beyond email and conventional corporate documents to SaaS AI chats, API logs, local-model records, RAG retrievals, company-related material in personal accounts, browser caches, screenshots, database backups and virtual-machine snapshots.
Companies should also separate ordinary commercial analysis from litigation preparation conducted under a lawyer’s direction. A mixed AI conversation combining negotiations, public relations, personnel arrangements and legal defences will generally present a more difficult privilege claim than litigation analysis created in a controlled workspace under explicit legal guidance.
Conclusion
An AI conversation does not fall outside litigation merely because it looks like a private draft. Copies may exist simultaneously on the AI platform, in company databases, API logs, employee devices, Slack, email, screenshots and backup systems.
At the same time, a court will not automatically decide that every prompt came from a CEO simply because the conversation sits in an account bearing the CEO’s name. What matters is the complete evidential chain: account and authentication data, device forensics, internal information contained in the chat, circulation of the AI output, admissions by the individual, and the company’s subsequent conduct.
The central lesson of Krafton is not that a ChatGPT record can decide a case by itself. It is that when an AI conversation is corroborated by contemporaneous internal documents, executive testimony and later implementation, it can become powerful evidence of a company’s real purpose and decision-making process.