If 2023 to 2025 were the years where organisations were trying to understand and experiment with the use cases of artificial intelligence (“AI”), then 2026, and moving into 2027 are certainly the years where organisations are moving forward in understanding what it actually takes to implement and integrate AI into actual business operations and at scale.
Essentially, it is a change of phase from AI experimentation to actual enterprise AI deployment and integration, where it is no longer just some curious employees toying around with publicly available generative AI tools to draft simple emails, summarise documents, conduct research, generate images or prepare presentation slides. Moving forward, the next phase that we are actively seeing amongst companies in recent months, whether within Malaysia or globally, is companies directly adopting, deploying and integrating AI into actual business operations at scale, such as credit assessment, fraud detection, customer service, recruitment and many other operational processes.
And with that, it is a very different kind of AI usage because, more than merely using generative AI for chatbot-like purposes in generating answers to prompts, the deployment and integration of AI is now increasingly a top-down approach where an organisation is directly deploying AI within the company’s systems, where the AI may have access to the company’s data. As organisations move towards agentic AI and more autonomous AI systems, this may go even further, where they can then retrieve and process data, analyse data, make inferences, make recommendations, make predictions, initiate workflows, and even autonomously take further actions such as communicating with customers, making decisions and taking certain actions on behalf of the organisation with minimal or almost no human intervention or assistance.
This is pretty much a new-new phase that the world is heading into, one that is also definitely unprecedented and unseen before. Yet, if you are reading this article, there is a reasonable chance that conversations of this nature are already taking place within your organisation. Trust that if you are within the legal team, during such AI deployment and integration within business operations, you will also realise that as the technology and the business move forward, the legal framework supporting that technology must move forward as well because suddenly, all the standard MSAs, SaaS agreements and other software licensing agreements for typical technology contracts that most in-house counsels have been using for the past many years are no longer necessarily sufficient for this new phase of AI deployment and integration within the business operations of an organization – and it is totally understandable because, while both concern technology, the fundamental difference is that traditional enterprise software is mainly designed to perform defined functions, and the key contractual risks of traditional enterprise software have always largely revolved around matters such as uptime and availability.
AI, however, introduces a very different dimension that all in-house counsels would need to consider, especially on issues such as data protection, cybersecurity and intellectual property. This is because an AI system, more than simply performing a defined function, can process, generate, predict, recommend and decide pretty much autonomously, with little to almost no human intervention, on behalf of the company. The standard uptime requirement is therefore no longer sufficient for an AI system because, even if the AI system is operating at the gold standard of “five nines”, which is 99.999% availability, it still means very little if the AI system hallucinates and generates inaccurate information or makes the wrong decision autonomously, where it may even potentially infringe intellectual property rights, breach personal data obligations, or make the wrong recommendations or take the wrong actions altogether. Suddenly, the most crucial aspect of “availability” is no longer the complete measure of performance, as the system can technically be working perfectly while substantively producing the wrong answer, and that distinction pretty much goes to the heart of enterprise AI contracting.
This is why AI deployment fundamentally changes how typical technology contractual risk allocation works. As in-house counsel, you will definitely recognise that this is also why an in-house legal team cannot simply use an existing SaaS or MSA template agreement and just slap “AI” into the clauses or the schedule. The technological fundamentals, the contractual risk allocation, and what works and what does not work are fundamentally different when it comes to AI deployment.
Therefore, in this article, we aim to set out the top 5 most crucial contractual considerations that in-house legal counsels and legal teams should pay particular attention to before deploying third-party AI within their organisations, an area where we are certainly seeing more and more activity and a significant uptick in the market this year.
Key Takeaway 1: A Standard Uptime SLA Is Not an AI Performance Standard
The first key takeaway is probably the most obvious one that a standard uptime SLA is not an AI performance standard.
As explained above, typical SaaS agreements usually measure performance through availability, and typically, the more “nines” there are, the higher the standard becomes, with the gold standard being “five nines”, or a 99.999% uptime commitment. However, when it comes to AI, while there is of course no doubt that uptime is still important, it does not tell us the whole story as to whether the AI is actually performing properly as intended or designed.
Even with 100% uptime, an AI system that is always perfectly available but consistently produces poor-quality outputs or unreliable decision-making is certainly not acceptable either. This is why when it comes to AI deployment, the first shift is to understand that AI-specific performance standards must go beyond ordinary uptime. Depending on the nature of the AI system, this may then include different measurements such as testing procedures, benchmark datasets, accuracy thresholds, false-positive or false-negative tolerances, response quality standards, latency requirements, or other measurable indicators relevant to the particular use case.
Of course, one crucial aspect is the balancing act between what is technically reasonable and practical, and what is commercially and legally expected. While the commercial and legal expectation may be for the AI not to make errors, it would also be commercially and technically unrealistic for an AI vendor to warrant that the AI system will be absolutely accurate and will never make an error. Hence, what is advisable, without necessarily making this a deal breaker, is to establish the expected performance envelope and determine what happens if the AI repeatedly performs outside that envelope.
For example, where AI is used to extract information and autonomously generate and issue invoices, it may be perfectly possible to test the system against a representative dataset and agree on an acceptable extraction accuracy level. Similarly, where AI is used for fraud detection, the relevant performance criteria may include acceptable false-positive and false-negative rates. A system that identifies almost every transaction as potentially fraudulent may technically detect most fraudulent transactions, but it may simultaneously produce such a high false-positive rate that it becomes commercially impractical. Conversely, a system with an unusually low false-positive rate may appear efficient while failing to detect an unacceptable proportion of actual fraudulent activity.
Hence, instead of just relying on uptime availability, the performance obligations in an AI deployment agreement should be designed around the actual function, expected outcome and acceptable performance boundaries of the AI system, taking into account what is legally appropriate, technically achievable and commercially workable for the particular deployment.
Key Takeaway 2: Pay Close Attention to the Data Used During AI Deployment
The second key takeaway is the data that is used during the deployment of AI.
When it comes to deploying AI, what is slightly more concerning is that, depending on the architecture of the AI system, the way in which the AI accesses and processes the organisation’s data may be very different from what companies have traditionally been accustomed to.
For example, with more passive AI prompting, employees are typically the ones providing and feeding information into the AI system, such as personal data, confidential business information, customer records, financial information and other internal information. To a certain extent, this remains within the control of the company and the individual employees because they are the ones deciding what information is being provided to the AI system.
However, when it comes to agentic AI, it is definitely very different because the AI system will frequently be allowed to connect directly to, and have access to, the company’s systems and internal databases. Instead of the company selectively choosing what information should be uploaded to the cloud or provided to the AI system, the question now becomes which internal systems, databases and datasets the agentic AI should be permitted to access directly.
This is where the definition of “Company Data” really needs to be properly drafted and defined because unlike in the past, where “Company Data” would typically consist of information provided or uploaded by the company itself, the definition may now need to be redrafted so that it captures not only information expressly provided or uploaded by the company, but also all other databases, datasets and information that the AI may have access to, whether directly or indirectly, through any permissioned access granted by the organisation.
Through that, one of the most crucial issues is to understand whether any of this information may then be used by the AI vendor to train, fine-tune, improve or develop the vendor’s AI model. There is actually a slight but very important distinction here, as it is one thing for the data to be used as operational telemetry, or otherwise to monitor system performance, troubleshoot issues, fine-tune the deployment or improve the performance of the AI system specifically for the company. However, it is quite another for that same dataset to be used to train or improve a broader AI model that is subsequently made available to thousands of other customers.
The distinction is extremely important because, chances are, once the AI system is connected to the company’s databases, it will have access to a very significant amount of information. Companies should therefore understand whether the vendor is using that information merely to improve the service and performance being provided to that particular company, or whether the information is also being used to improve the vendor’s underlying AI model, which may subsequently benefit the vendor and all of its other customers. As the former benefits the company itself, the latter benefits the AI vendor and the rest of its customer base.
Hence, before giving an AI system access to the organisation’s data, companies should understand precisely where that data is going, how it is being processed, and what the vendor is contractually entitled to do with it. There is certainly a fine line between what “model improvement” and “service improvement”, and similar concepts actually mean in practice, and this is one small but important technical nuance that must be carefully defined and reviewed, otherwise, the organisation’s own data may inadvertently become a free source of training material for the AI vendor to improve its wider model.
Key Takeaway 3: Ownership of AI Inputs and Outputs
The third key takeaway is the ownership of AI inputs and outputs.
When it comes to AI, the position is slightly different from traditional technology agreements, where the distinction between the vendor’s technology and the customer’s data has, by now, become relatively well established. However, with AI, the position becomes more complicated because there is now another layer to consider, which is the output generated by the AI system itself.
There is no doubt that, through AI, companies may increasingly rely on AI systems to produce songs, reports, software code, product designs, or even inventions and other commercially valuable work. However, depending on the jurisdiction, the issue of intellectual property ownership in AI-generated content and works is certainly not settled or in any way straightforward, as it may also depend on the degree of human involvement and the particular circumstances in which the relevant material, invention or work was created.
More than just clearly establishing that the company retains ownership of its pre-existing materials and intellectual property provided to the AI system, which is something already typically addressed in most standard technology agreements, moving forward, another layer to consider is how the AI-generated work itself can be protected from an intellectual property perspective.
For certain forms of intellectual property, the extent of human authorship, creativity, contribution or inventorship may remain highly relevant, therefore, while an organisation may receive broad contractual rights to use an AI-generated output while still facing uncertainty as to whether it can obtain or enforce exclusive intellectual property rights over that output against third parties.
This is increasingly important as we are also seeing AI providers introduce technical measures, including watermarking and other mechanisms, to identify AI-generated content and, in certain cases, to prevent other AI models from distilling or using their outputs. At the same time, the vendor’s contractual terms may even impose their own conditions on how AI-generated outputs may be used, reproduced or commercialised.
Hence, this is another key aspect that companies should clearly consider when deploying AI, because even if the company is able to contractually establish its rights to use or own AI-generated outputs as between itself and the AI vendor, that does not necessarily resolve the separate question of whether the output is capable of attracting intellectual property protection under the applicable law. With that, it is no longer sufficient to ask who owns the data that goes into the AI. Companies increasingly also need to ask who owns the output that comes out of it, whether that output can actually be protected by intellectual property rights, and what level of human involvement may be necessary to preserve that protection.
Key Takeaway 4: Liability and Risk Allocation
The fourth key takeaway is liability and risk allocation.
When it comes to liability and risk allocation, this is probably one of the most complicated and challenging parts because AI vendors will understandably seek to protect themselves from potentially unlimited exposure arising from a company’s reliance on the use of AI, and on the other hand, companies should also be extremely cautious about accepting provisions that simply transfer all AI-related risks back to them.
Typically, when it comes to liability architecture, most standard technology agreements will use a familiar formula under which the vendor’s total liability is capped at the fees paid during the preceding 12 months. While such a structure may be understandable and very much reasonable for low-risk and ordinary software services, it may be totally disconnected from the actual exposure created by AI deployment. For example, a company may simply be using an AI tool to help employees draft internal emails, however, in another situation, an AI agent may be directly connected to the company’s fulfilment and procurement systems, with autonomous access and authority to initiate and approve fulfilment and procurement processes and transactions on behalf of the company. One can immediately see that the risk exposure of using AI to assist with internal emails is very different from using agentic AI within a company’s fulfilment and procurement systems.
Therefore, liability should be calibrated to the actual risk profile of the AI deployment and the level of control exercised by each party, with the overall risk allocation being proportionate to the actual consequences of failure.
One useful fundamental principle in approaching this is that liability should follow control. The vendor should certainly be responsible for matters within its control, including the operation of its technology, compliance with contractual restrictions relating to data, implementation of agreed safeguards, compliance with security obligations, authorised use of customer data, and the representations and warranties it gives in relation to the services it provides. However, this should not be unfettered, as the customer should generally remain responsible for the manner in which it chooses to deploy the AI, the instructions given to the system, its employees’ use of the technology, and situations where it ignores clearly documented restrictions or uses the AI outside the agreed parameters.
Once the respective areas of control are properly understood, it may then become easier for companies to structure the liability provisions by determining whether separate or higher liability caps are appropriate for particular categories of risk. These may include breach of confidentiality, personal data breaches, cybersecurity incidents, intellectual property infringement, unauthorised use of customer data, or losses arising from an AI agent acting outside the expressly agreed scope of authority because of a defect in the vendor’s service.
Therefore, when it comes to liability and risk allocation, as much as an in-house legal team may understandably prefer to push as much liability as possible towards the vendor, one should also appreciate that the objective should not be to make one party responsible for everything. We trust that the better contractual approach is to properly allocate each material risk to the party that is best able to control, prevent or insure against that risk, while ensuring that the liability framework still leaves a meaningful remedy if a serious contractual failure occurs. Ultimately, risk allocation should be proportionate to the actual consequences of failure.
Key Takeaway 5: Exit Must Be Planned from the Beginning
The fifth and final key takeaway is exit planning.
This is probably the “sunset clause” that appears towards the last few pages of the agreement and, quite often, receives the least attention. Yet, like it or not, every agreement must eventually deal with exit.
When it comes to AI, this can be very different from standard plug-and-play software, especially so for agentic AI, which may be fully integrated and embedded into the company’s workflows and systems, with direct access to the company’s databases, applications and internal processes. Because of the amount of access that the AI system may have, the exit provisions should be extremely tight and carefully drafted.
The agreement should therefore address matters such as data export, return and deletion, continued access during the transition period, migration support, treatment of configurations and customised workflows, retention of audit records, revocation of system credentials, and the secure decommissioning of AI integrations.
This is also where the technical difficulty comes in. Where the AI has been given credentials, API access or authority to perform actions within the company’s systems, termination should not simply mean switching off the subscription. There should also be an effective decommissioning process to ensure that all such permissions and access rights are properly revoked, and that any data retained or stored by the AI vendor is properly returned, deleted or migrated in accordance with the agreed requirements. These are all technical and operational processes that should ideally be dealt with early on rather than only when the relationship is already coming to an end.
As with every technology arrangement, and particularly for AI deployment contracts, there is no doubt that the best time to negotiate the exit is before the relationship begins. If the exit plan is properly structured from the outset, the company will be in a much better position to unwind the AI deployment in an orderly and commercially practical manner if and when the relationship eventually comes to an end.
Closing Thoughts
AI deployment is unquestionably going to become one of the most significant enterprise technology developments over the coming years. With ordinary software, we typically focus on whether the system performs the function that it has been programmed to perform. However, with AI, companies increasingly need to consider not only whether the system works, but what it generates, what it learns from, what information it can access, whether its behaviour can change, what decisions it can influence and, with agentic AI, what actions it may ultimately be authorised to take.
Ultimately, the deeper an AI system becomes integrated into an organisation’s operations, the more difficult it becomes to separate technology risk from legal risk, commercial risk and operational risk.
If you have any questions on AI deployment, AI-related contractual documentation, AI governance, vendor and third-party AI arrangements, data protection, cybersecurity or the broader legal and regulatory considerations surrounding enterprise AI adoption, please feel free to reach out to the partners in our Technology Practice Group, Ong Johnson and Lo Khai Yi, for a consultation. We have extensive experience advising on technology law, AI, data protection, cybersecurity, digital platforms and complex technology arrangements, and would be pleased to assist businesses, boards and in-house teams in structuring and negotiating the appropriate contractual, legal and risk-allocation framework for the responsible deployment and integration of AI within their organisations.
The Technology Practice Group of Halim Hong & Quek continues to be recognised by leading legal directories and industry benchmarks. Recent accolades include FinTech Law Firm of the Year at the ALB Malaysia Law Awards (2024, 2025 and 2026), Law Firm of the Year for Technology, Media and Telecommunications by the In-House Community, FinTech Law Firm of the Year by the Asia Business Law Journal, a Band 2 ranking for FinTech by Chambers and Partners, and a Tier 3 ranking by Legal 500. The strength of the practice is further reflected in the individual recognition of its partners, including a Band 1 ranking for FinTech by Chambers and Partners within the Technology Practice Group.
About the authors
Ong Johnson
Partner
Head of Technology Practice Group
Fintech, Data Protection,
Technology, Media & Telecommunications (“TMT”),
IP and Competition Law
johnson.ong@hhq.com.my
◦
Lo Khai Yi
Partner
Co-Head of Technology Practice Group
Technology, Media & Telecommunications (“TMT”), Technology
Acquisition and Outsourcing, Telecommunication Licensing and
Acquisition, Cybersecurity
ky.lo@hhq.com.my.
More of our Tech articles that you should read:
- • Consumer Credit Act 2025: 10 Key Takeaways on Malaysia’s New Authorisation Regime
- • Exit and Step-In Rights in Artificial Intelligence-as-a-Service
- •Telecommunication Towers M&A: Unpacking the Transaction
