Trade secret law has always been practical law. It protects the confidential business information that gives a company an advantage because competitors do not know it and cannot readily obtain it by proper means. In older business settings, that often meant formulas, manufacturing methods, customer lists, internal financial data, vendor terms, or sales playbooks. In modern companies, the same legal principles now apply to assets that may not look like traditional “secrets” at first glance: exported CRM files, pricing algorithms, prompt libraries, retrieval-augmented generation materials, fine-tuned model files, evaluation datasets, and internal AI workflows. These assets may live in cloud platforms, sales tools, source-code repositories, chat interfaces, vector databases, or model registries rather than in a locked file cabinet. But the legal question remains familiar. The business must be able to show that the information is valuable because it is not generally known that competitors could gain value from it, and that the company took reasonable steps to keep it secret. ¹
That last requirement is often where companies stumble. Many businesses have handbooks, confidentiality policies, and nondisclosure agreements, but trade secret protection depends on more than the existence of paperwork. Courts and counterparties look at conduct. A company that labels information confidential but allows unrestricted exports, uncontrolled personal-device downloads, shared passwords, unsecured AI tool uploads, or broad internal access may have a difficult time proving that it treated the information as a trade secret. The handbook may be helpful evidence, but it is rarely enough by itself. Trade secret protection is built through daily operational discipline. It requires aligning employment policies, technical controls, vendor contracts, data governance, onboarding, offboarding, incident response, and litigation readiness around the specific categories of information the business actually needs to protect. ¹
The shift from paper policies to digital operations has expanded both the value and the vulnerability of trade secrets. A salesperson no longer needs a banker’s box of files to take a customer list. A departing employee may export years of CRM records in minutes. A developer may clone a repository containing source code, model weights, configuration files, and deployment scripts before giving notice. A marketing team may paste internal prompts, customer personas, or competitive pricing assumptions into a third-party AI platform without appreciating that the material could be retained, reviewed, or used in ways inconsistent with the company’s confidentiality obligations. The speed and portability of digital information do not weaken trade secret law, but they raise the standard for practical protection. A company must be prepared to explain who could access the information, why they needed access, what restrictions applied, what monitoring existed, and what happened when the access was no longer needed.⁵
CRM exports are a useful place to begin because they sit at the intersection of ordinary business records and high-value competitive intelligence. A customer’s name may not be secret in isolation. A public website, LinkedIn profile, trade-show attendee list, or secretary of state database may reveal that a company exists and that it buys certain products or services. But a properly maintained CRM often contains much more than names. It may include decision-maker identities, renewal dates, buying cycles, pricing history, discount tolerances, objections raised during negotiations, product pain points, implementation notes, support history, contract terms, churn risk, and relationship intelligence gathered over years. The value of that compilation is not simply that it identifies customers; it reflects how the company sells, what it has learned from prior interactions, and where the next commercial opportunity may exist. Under trade secret principles, a compilation can be protectable even when some individual data points are publicly knowable, if the assembled information has independent economic value and is not readily ascertainable in that useful form. ¹
The problem with CRM data is that businesses often treat it as both mission-critical and casually portable. Sales teams are encouraged to move quickly, and CRM platforms are frequently connected to email tools, forecasting dashboards, customer success systems, marketing automation platforms, and spreadsheet exports. Those integrations can be commercially necessary, but each one creates a pathway for disclosure. A company that wants to treat CRM exports as trade secrets should define the protected categories clearly and then back that definition with access controls. It is not enough to say that “customer information” is confidential if every employee can export the entire customer database without approval. A stronger approach treats export rights as a privileged function, logs bulk downloads, limits access by territory or account responsibility, restricts personal email forwarding, disables unnecessary third-party syncs, and requires business justification for large reports. Those measures do not have to be perfect, but they should show that the company made reasonable efforts proportional to the value and sensitivity of the information. ¹
Pricing algorithms raise a different but related issue. In many businesses, price is not a single number. It is the output of a system. That system may account for costs, demand elasticity, competitor behavior, customer segment, inventory levels, region, contract length, lifetime value, risk, seasonality, channel strategy, and negotiated exceptions. A competitor who obtains the logic behind that system may not merely learn what the company charged yesterday; it may learn how the company thinks about market opportunities tomorrow. For that reason, a pricing engine, spreadsheet model, quoting tool, rate database, or algorithmic decision tree may qualify as a trade secret when it is not generally known, provides competitive value, and is protected by reasonable secrecy measures. The Eleventh Circuit’s Compulife litigation is often cited in discussions of software, data, and automated quote systems because the dispute involved proprietary life-insurance quote software, a rate database, and allegations that competitors used scraping and copied code to build competing tools. ³
Pricing systems also show why trade secret protection must focus on both the algorithm and the surrounding data. The formula may be valuable, but so may the training data, weights, assumptions, exception tables, historical quote outcomes, customer segmentation logic, and user-interface features that allow sales personnel to apply the pricing strategy consistently. A business may lose practical protection if it allows pricing logic to spread through uncontrolled spreadsheets, offline copies, informal Slack messages, or local downloads. The law does not require a company to eliminate every operational convenience, but it does require the company to act like the information matters. That means version control, permissioned access, audit logs, confidentiality legends where appropriate, vendor restrictions, and disciplined review before sharing pricing models with consultants, brokers, distributors, investors, or prospective acquirers. ¹
Prompt libraries are a newer category, and they are easy to underestimate. At first glance, prompts can look like ordinary text instructions. A prompt may not resemble source code, a formula, or a customer database. But in practice, a well-developed prompt library may represent substantial trial and error. It may encode a company’s preferred tone, legal risk tolerances, sales methodology, customer classification framework, objection-handling language, internal review standards, drafting conventions, escalation rules, data fields, and proprietary workflows. A prompt library may also include examples of successful outputs, negative examples, structured templates, compliance constraints, and instructions for using internal knowledge bases. When prompts are paired with confidential context, retrieval systems, custom tools, or evaluation results, they may become part of a broader operational method rather than mere text. That method may have economic value precisely because competitors do not know how the company has refined it.⁵
The trade secret question for prompt libraries is not whether every prompt is secret. Many prompts are generic, publicly available, or easily recreated. A simple instruction to “write a professional email” is unlikely to deserve much attention. But a curated system of prompts developed for a particular industry, product, client base, legal environment, or operational workflow may be different. The value may lie in the sequence, the constraints, the embedded examples, the connection to internal taxonomies, and the testing history that shows which prompts produce reliable results. Businesses should avoid overstating the secrecy of ordinary AI usage, but they should also avoid giving away internally developed prompt engineering playbooks simply because they do not resemble traditional software. If the prompt library saves time, improves quality, reduces risk, or produces commercially superior outputs, the company should decide whether it wants to treat that library as protectable confidential information and then manage it accordingly. ¹
AI model files create even more complicated issues because they can contain or reflect many different protected assets. A model file may include model weights, fine-tuning results, architecture choices, hyperparameters, tokenizer files, embeddings, adapters, evaluation sets, system prompts, retrieval configurations, safety filters, deployment scripts, and monitoring rules. Some of these materials may be open source or derived from third-party tools. Others may be the company’s own confidential work. The fact that a model uses open-source components does not automatically mean the company’s fine-tuned version, training process, evaluation data, or deployment configuration lacks trade secret value. Conversely, calling a model “proprietary” does not make every component a trade secret. The company must identify what is actually secret, what value it provides, and how it has been protected.⁵
Model files also present a special risk because they can be copied, transferred, or deployed in ways that are difficult to detect after the fact. A former employee downloads a model checkpoint, vector index, or fine-tuned adapter may take something far more valuable than a document. They may take a portable representation of months or years of training, evaluation, and domain-specific refinement. The Waymo litigation remains a prominent reminder that trade secret disputes in technology often turn on large-scale downloads of confidential technical files, the circumstances of employee departure, and whether later competitive development benefited from improperly acquired information.⁴ The specific facts of any AI dispute will differ, but the lesson is broader. Companies should treat model artifacts as high-value technical assets, not as ordinary files sitting somewhere inside a developer environment.
Protecting AI model files requires coordination between legal, engineering, security, and business teams. Legal agreements should define confidential AI materials with enough specificity to include model weights, fine-tuning data, prompts, embeddings, evaluation datasets, configuration files, and deployment documentation where appropriate. Engineering controls should limit repository access, restrict downloads, separate production models from experimental workspaces, and monitor unusual activity. Security teams should maintain logs that can answer basic forensic questions: who accessed the model, when, from what device, for what purpose, and whether files were copied or transferred externally. Business leaders should understand that the asset is not only the model output shown to users; it is the accumulated system that produces the output reliably, efficiently, and in the company’s preferred manner.⁵
The rise of generative AI also complicates the company’s own use of third-party tools. Employees may upload confidential materials to external AI platforms to summarize documents, generate code, rewrite sales scripts, analyze pricing, or create customer communications. That behavior may be efficient, but it can create trade secret and contractual problems if the platform terms, retention settings, training settings, or access controls are not appropriate. A company that prohibits public disclosure but silently permits employees to paste sensitive materials into uncontrolled tools may have difficulty demonstrating consistent reasonable measures. The better approach is not to ban all AI use reflexively, but to classify tools and data. Employees should know which AI systems are approved, which categories of information may be entered, which materials are prohibited, and what review is required before using confidential data in prompts or uploads.⁵
This is where the “beyond the handbook” concept becomes most important. A handbook can state that employees may not disclose trade secrets, but it often does not tell a salesperson whether they may export a CRM report to a personal spreadsheet, tell a developer whether a model checkpoint may be saved locally, or tell a marketing employee whether a prompt containing customer segmentation logic may be entered into a public chatbot. Modern trade secret governance must translate general confidentiality language into operational rules that match the tools people actually use. The policy should speak in the vocabulary of the business: CRM exports, quote sheets, pricing tools, prompt libraries, repositories, model files, customer recordings, support transcripts, embeddings, vector stores, APIs, dashboards, and vendor workspaces. Employees protect what they can recognize. Vague warnings about “confidential information” are less effective than concrete rules tied to everyday systems.
The same point applies to onboarding. Companies often present confidentiality obligations during the first week of employment, when employees are absorbing benefits information, HR forms, security training, and job expectations all at once. For trade secret purposes, onboarding should do more than collect signatures. It should identify the company’s most important categories of confidential information and explain why it matters. A salesperson should understand that the CRM reflects relationship intelligence developed through company investment. A data scientist should understand that training sets, evaluation scripts, and model artifacts may be protected even if they are stored in ordinary development tools. A product manager should understand that roadmaps, pricing assumptions, and customer feedback compilations can reveal competitive strategy. A lawyer, HR leader, or executive should understand that privilege, confidentiality, privacy, and trade secret concepts may overlap but are not identical.
Offboarding deserves even more attention because trade secret disputes often arise when an employee leaves for a competitor, starts a competing venture, or joins a customer or vendor. A strong offboarding process should begin before the employee’s last day whenever possible. Access should be reviewed and reduced promptly. Company devices should be returned and preserved if there are concerns. Recent downloads, exports, repository clones, file transfers, email forwarding, cloud syncs, and external sharing should be reviewed based on risk. Departing employees should receive a reminder of their continuing confidentiality obligations, but that reminder should be tailored to their actual role and access. A generic exit letter is less useful than one that specifically references CRM data, pricing tools, source code, model files, prompt libraries, customer proposals, or other assets the employee used. The goal is not to threaten every departing worker. It is to preserve the company’s legitimate rights while creating a clear record that the company treated its information seriously.
Vendor and contractor relationships are another common weak point. Businesses often rely on outside developers, AI consultants, marketing agencies, sales operations vendors, pricing consultants, managed service providers, and data-labeling teams. These third parties may need access to sensitive systems, but trade secret protection can be weakened if contracts and controls do not match the access granted. A vendor agreement should not merely include a standard confidentiality clause. It should address permitted use, data segregation, subcontractors, security standards, return or destruction of materials, audit rights, incident notice, ownership of derivative works, restrictions on model training, and post-termination obligations. If a consultant helps develop a prompt library, fine-tune a model, or improve a pricing algorithm, the agreement should make clear who owns the resulting work and whether the consultant may reuse methods, templates, or artifacts for other clients.
The distinction between employee skill and company trade secrets is also critical. Trade secret law does not prevent employees from using general knowledge, experience, memory, and professional skill. It does not give a company ownership over a person’s career. A former employee may know the industry better because of prior work, and that knowledge may be lawful to use. The line is crossed when the employee takes, discloses, or uses protected confidential information acquired under circumstances giving rise to a duty of secrecy. The distinction matters because overbroad claims can backfire. Companies should avoid treating every former employee as a suspected thief or every competitive move as misappropriation. Instead, they should focus on specific information, specific access, specific secrecy measures, and specific evidence of improper acquisition, disclosure, or use. ¹
That discipline is especially important in the AI context because outputs may resemble prior work without proving that a trade secret was used. A competitor’s chatbot may produce similar sales language because both companies rely on common industry terminology. A pricing recommendation may look similar because both companies face the same market conditions. A prompt structure may resemble another because best practices circulate widely. The stronger case is built not on suspicion, but on evidence: unusual downloads, repository access before departure, copied file names, metadata, identical errors, matching internal labels, possession of nonpublic datasets, or communications showing improper transfer. Companies that maintain logs, access records, and version histories will be better positioned to distinguish legitimate competition from misappropriation.
Reasonable secrecy measures should be risk-based. The law does not require the same controls for every piece of information. A company does not need to protect a routine meeting agenda as if it were a model-weight file or pricing algorithm. But the more valuable, portable, and competitively sensitive the asset, the stronger the expected controls. For CRM exports, that may mean role-based access, export restrictions, monitoring, and territory-based segmentation. For pricing algorithms, it may mean repository controls, approval workflows, limited model documentation, and restrictions on sharing with channel partners. For prompt libraries, it may mean access-limited workspaces, internal-only labels, controlled examples, and AI tool rules. For model files, it may mean secure model registries, download restrictions, encryption, environment isolation, and forensic logging. The legal standard is flexible, but flexibility is not the same as informality. ¹
Companies should also consider how trade secret protection interacts with other legal regimes. Customer data may implicate privacy laws, contractual confidentiality obligations, industry regulations, and cybersecurity requirements. Pricing algorithms may raise antitrust, consumer protection, or discrimination concerns depending on how they are designed and used. AI models may involve copyright, open-source licenses, data rights, biometric laws, employment laws, and sector-specific rules. Trade secret status does not excuse unlawful conduct, and secrecy should not be used to avoid required transparency. A responsible governance program recognizes that some information should be protected from competitors while still being documented, audited, and disclosed to regulators, courts, or counterparties when the law requires. The DTSA also includes whistleblower immunity provisions that employers should address in agreements governing trade secrets or confidential information. ¹
Documentation is often the difference between having trade secrets and proving trade secrets. When litigation begins, a company may be required to identify its alleged trade secrets with reasonable particularity. Broad descriptions such as “all customer information,” “our AI system,” or “pricing strategy” may not be enough. A company should be able to describe the protected compilation, method, model artifact, dataset, or workflow without disclosing the secret itself. This requires internal inventories. The inventory does not have to be elaborate at the beginning, but it should identify major categories, owners, storage locations, access groups, business value, and control measures. For AI systems, the inventory should distinguish between third-party base models, open-source components, proprietary fine-tuning data, internal prompts, retrieval materials, model outputs, and deployment configurations.⁵
Incident response should likewise be designed before a crisis. If a CRM export, model file, or prompt library is suspected to have been taken, the company should preserve evidence quickly and lawfully. That may include suspending automatic deletion, preserving devices, collecting access logs, reviewing cloud-sharing records, and documenting the timeline. Internal investigation should be coordinated with counsel to avoid unnecessary waiver or spoliation issues. Communications should be careful, factual, and limited to those who need to know. The company should evaluate whether the issue is a trade secret matter, a privacy incident, a contractual breach, a computer access issue, or some combination. Acting too slowly can allow the information to spread. Acting too aggressively without evidence can create employment, defamation, or business-interference risks.
The most effective trade secret programs are not built around fear. They are built around clarity. Employees should not have to guess whether a prompt library is confidential, whether a pricing model may be downloaded, or whether a CRM export may be used after leaving the company. Vendors should not have to infer whether they may reuse templates developed during an engagement. Managers should not learn for the first time during litigation that their team had no export controls or that model files were stored in personal cloud folders. Clarity reduces disputes because it tells people what the company values and how that value must be handled.
Trade secrets will continue to evolve as business tools evolve. The assets that matter most to a company may no longer fit neatly into the examples used in older handbooks. A modern business may derive its advantage from the way it organizes customer intelligence, prices dynamically, instructs AI systems, tunes models, evaluates outputs, and integrates proprietary knowledge into automated workflows. Those assets can be protected, but not by labels alone. They require a living system of legal agreements, technical safeguards, training, monitoring, vendor management, and evidence preservation. Trade secret law remains broad enough to protect modern digital assets, but it rewards companies that can show they acted deliberately.
The practical lesson is straightforward. Do not wait until a key employee leaves, a competitor launches a suspiciously similar tool, or a model file appears outside the company to decide what your trade secrets are. Identify the assets now. Classify them in business language. Limit access based on need. Control exports and downloads. Regulate AI tool use. Update contracts. Train employees with examples they recognize. Monitor the systems where sensitive information lives. Preserve evidence when something goes wrong. A handbook can introduce those duties, but the real protection comes from how the business operates every day. In the world of CRM exports, pricing algorithms, prompt libraries, and AI model files, trade secret protection belongs not only in the handbook, but in the architecture of the company itself.
Contact Tishkoff
Tishkoff PLC specializes in business law and litigation. For inquiries, contact us at www.tish.law/contact/. & check out Tishkoff PLC’s Website (www.Tish.Law/), eBooks (www.Tish.Law/e-books), Blogs (www.Tish.Law/blog) and References (www.Tish.Law/resources).
Footnoted Sources:
1- Defend Trade Secrets Act of 2016, 18 U.S.C. §§ 1833, 1836, 1839. https://www.congress.gov/114/plaws/publ153/PLAW-114publ153.pdf
2- Uniform Trade Secrets Act § 1(4), as amended in 1985, Uniform Law Commission. https://www.uniformlaws.org/viewdocument/final-act-128?CommunityKey=3a2538fb-e030-4e2d-a9e2-90373dc05792&tab=librarydocuments
3- Compulife Software Inc. v. Newman, 959 F.3d 1288 (11th Cir. 2020). https://media.ca11.uscourts.gov/opinions/pub/files/202114071.pdf
4- Waymo LLC v. Uber Technologies, Inc., No. 17-2235, 2017 WL 3912607 (Fed. Cir. Sept. 13, 2017). https://law.justia.com/cases/federal/appellate-courts/cafc/17-2235/17-2235-2017-09-13.html
5- World Intellectual Property Organization, WIPO Guide to Trade Secrets and Innovation, Part VII: Trade Secrets and Digital Objects. https://www.wipo.int/web-publications/wipo-guide-to-trade-secrets-and-innovation/en/index.html