Beyond Standard SaaS: Navigating the High-Stakes Clauses in Enterprise AI Contracts
Enterprise AI contracts are not typical standard SaaS agreements. This article identifies three critical red flags, including training data loopholes, IP indemnity gaps, and privacy compliance, providing a tactical framework for safe AI adoption.
At some point in the last year, a conversation like this has happened in a glass‑walled conference room overlooking Victoria Harbour.
“We are about to sign an enterprise contract with an AI platform,” someone says, “and honestly… I am uneasy.”
The documents on the table look familiar: master service agreement, data‑processing addendum, security schedule. They read like the cloud and CRM contracts you have signed for years. There are references to uptime, support tickets, and encryption at rest. Procurement is relieved. The C‑suite is impatient. The message is clear: everyone else is moving; why aren’t we?
That familiarity is where the risk hides.
Treating GenAI as "just another SaaS tool" is like treating a student who remembers everything you say as just another notebook. Traditional SaaS processes your data and hands it back. Generative AI has the potential to absorb it, i.e. to change its behavior because of what you feed it. For General Counsel and Heads of Procurement in Hong Kong, here are three red flags that tell you you are no longer in ordinary SaaS territory.
Red Flag #1: The "Training Data" Loophole
In a standard SaaS contract, your data remains yours, securely siloed and encrypted. In the AI world, buried in service descriptions and privacy notices are phrases about using your “inputs and outputs” to “improve the service” or “train and refine models.” Inputs, in this context, are not just CSV files. They are prompts, uploaded documents, chat logs, and sometimes even the outputs themselves as they get fed back into the system.
Imagine a Hong Kong-based wealth management firm using an enterprise LLM to draft personalized investment strategies for high-net-worth clients. Over months, the prompts start to reveal patterns: how the firm frames risk, which structures it prefers, how it handles certain jurisdictions. If the contract gives the vendor broad rights to reuse “service data” for training, those patterns—refined, abstracted, anonymized—can become part of a general‑purpose model the vendor offers to everyone.
One day, a competitor’s analyst types a similar question into the same platform. What comes back may not be your words, but it could echo your logic.
The obvious response is to ask for a “Zero‑Retention” or “No‑Training” clause. In practice, most vendors will still need to retain some data for a short time for security monitoring, abuse detection, and legal compliance. The key is not to eliminate every byte, but to draw a firm line around what that data can and cannot be used for.
In contracts we review, we look for language that:
Explicitly excludes corporate data, prompts, and outputs from any use in training or improving shared foundation models.
Limits retention to clearly defined, time‑bound purposes such as fraud detection and legal archiving, with a commitment to deletion once those purposes are exhausted.
The rule of thumb is simple: if a vendor wants to learn from your business, they need a separate conversation and a different deal.
Red Flag #2: Ambiguous AI IP Ownership
A marketing team feeds an LLM with briefs and brand guidelines and gets back a campaign that sings. An engineering team uses an AI assistant to refactor legacy code. A product team experiments with AI‑generated interfaces for a new app.
Who owns what comes out of the model?
Most AI contracts now contain a reassuring sentence: “As between the parties, the customer owns all output.” It sounds definitive. But underneath that line are two complications.
First, in many jurisdictions, copyright law was built around human creators. Courts and regulators are still working out how to treat works produced with heavy machine assistance. If there is not enough human input, protection may be limited or uncertain. The risk is not that you have no rights, but that those rights may be harder to enforce in the way you are used to.
Second, when things go wrong, ownership is only half the story. If the model generates content that infringes a third party’s rights—code that mirrors an open‑source library under a restrictive licence, copy that echoes a well‑known tagline—who stands in front of the claim? Traditional SaaS indemnities usually cover infringement by the software itself, not by everything users create with it.
In other words, you may own the output, and still be alone in court.
A more robust approach has two parts:
Clear allocation of rights: the contract should give you the broadest possible rights in the outputs—use, modify, sublicense—“to the extent permitted by law,” and recognize the human contribution your teams make in directing and editing those outputs.
A targeted IP indemnity: the vendor should stand behind their models to the extent the infringement arises from how the service works, not from the specific data you supplied or the instructions you gave. That means covering claims where the problem lies in the model’s training set or architecture, not in your decision to paste in someone else’s confidential document.
No indemnity is limitless. Caps, exclusions, and control of the defence still matter. But if an AI platform wants to be embedded deep in your creative or engineering stack, it should share the risk that comes with that role.
Red Flag #3: Global Privacy Boilderplate, Local Rules
Most large AI providers now come with data‑processing addenda built around GDPR or the California Consumer Privacy Act. These frameworks are rigorous. They talk about controllers and processors, data subject rights, and international transfers. But they are not tailored to Hong Kong’s Personal Data (Privacy) Ordinance or to the way local regulators have started to think about AI.
In Hong Kong, the key concept is the “data user”—the party who decides the purposes and means of processing. In many AI deployments, that is your organization, even if the model runs on someone else’s infrastructure. Recently, the Privacy Commissioner has set out high‑level expectations for how AI should handle personal data: fairness, transparency, accountability, and safeguards around automated decision‑making.
Now consider two common scenarios:
HR uses an AI tool to screen résumés and rank candidates.
A bank uses a model to assist in credit or risk assessments.
If your contract simply imports a global privacy template without addressing local concepts — who is the data user, how individuals are notified, how they can challenge decisions — you may find that what looks “GDPR‑compliant” on paper does not match PDPO expectations in practice.
The contract should therefore:
Spell out the roles clearly: in most enterprise use cases, you are the data user, and the vendor is a processor or sub‑processor.
Address how data subject requests under PDPO—access, correction, deletion—will be honoured when AI systems and logs are involved.
Clarify cross‑border transfers: where personal data and inferences are processed, and which safeguards apply when data leaves Hong Kong.
The question is no longer just “Is this platform compliant somewhere?” but “Can we defend this specific implementation under Hong Kong rules?”
Turning Anxiety into a Scorecard
At this point, it is tempting for legal and procurement teams to default to the oldest defensive move in the book: say no.
But in boardrooms across the city, the mandate is shifting. Legal is not being asked to block AI. It is being asked to navigate it.
One way to do that is to replace one‑off arguments with a repeatable AI Vendor Risk Scorecard—a tool that turns abstract worries into concrete questions.
A good scorecard should asks, at minumum:
Data Isolation: Is our environment single‑tenant or multi‑tenant? How are our prompts, files, and logs segregated from other customers?
Training & Opt-Out Mechanics: Is our data excluded from model training by default, or do we have to find an obscure checkbox to opt out? What does “improvement of services” actually cover?
IP Protection: Do we have both clear rights to use outputs and a meaningful indemnity for infringement tied to the way the model works? How do the liability caps align with the value at risk?
Privacy & Transfer: Are PDPO roles and obligations explicitly addressed? Where does the processing actually happen, and what safeguards apply if data leaves Hong Kong?
Security Audits: Do the provider’s SOC 2 or ISO 27001 reports actually cover the AI components we are using, or just the underlying cloud?
Used consistently across vendors, this kind of scorecard changes the tone of internal debate. It shifts the question from “Should we block this?” to “What would it take for this to be safe enough for our use case?”
Don't Sign in the Dark
The pressure to keep up with AI is real. So is the responsibility to protect client data, intellectual property, and regulatory standing.
Enterprise AI contracts are not ordinary SaaS agreements wearing new branding. They sit at the point where your institutional memory, your creative output, and your risk profile meet someone else’s technology.
If you feel uneasy when you look at those clauses, you are not overreacting. You are noticing a gap between yesterday’s paperwork and today’s tools.
Closing that gap does not require you to become a machine‑learning expert. It requires the right questions, the right red lines, and, often, a partner who lives in the intersection of law, technology, and risk.
Whether you need a line‑by‑line review of a pending contract or help designing an AI Vendor Risk Scorecard that your teams can use across all new deals, our role is straightforward: we help you see the red flags early, close the loopholes, and adopt AI on terms that match the stakes.
Because in this new landscape, signing “in the dark” is no longer just a bad habit. It is a risk you can measure.