17 September 2026
The EU Artificial Intelligence Act has now moved beyond the stage of legislative anticipation and into operational compliance.
From 2 August 2026, a significant part of the AI Act’s transparency framework became applicable, including the obligations set out in Article 50. At the same time, the European Commission’s AI Office and national supervisory authorities entered a new phase in which companies can no longer treat AI governance as a matter of future preparation alone.
For businesses that rely on third-party AI tools, SaaS platforms, APIs, foundation models or embedded generative AI services, this has an important contractual consequence. The question is no longer simply whether the AI Act applies to a particular product or service. Companies increasingly need to understand how regulatory responsibility is distributed across the AI supply chain and whether their contracts provide enough information, cooperation and protection to support compliance in practice.
This matters because most companies using artificial intelligence do not build their own models. A startup may use one provider for a customer-facing chatbot, another for document analysis, another for recruitment screening and a further system for content generation or data analysis. In each case, the underlying model may be controlled by an external provider, while the commercial use of that model is determined by the customer.
That division of control creates legal tension.
The AI Act distinguishes between providers, deployers, importers and distributors, and the obligations that apply depend on how a system is developed, modified, marketed and used. Contractual language cannot override the regulatory classification imposed by law. A customer cannot avoid being treated as a deployer simply because the contract describes it as a “user,” and a company that substantially modifies or rebrands an AI system may, depending on the circumstances, assume additional responsibilities.
AI contracting is therefore becoming an increasingly important part of AI compliance.
The significance of 2 August 2026
One of the most visible changes concerns Article 50 of the AI Act, which introduces a number of transparency obligations for providers and deployers of certain AI systems.
Where an AI system interacts directly with individuals, providers will generally need to ensure that people are made aware that they are interacting with artificial intelligence, unless this is already obvious in the circumstances. In practical terms, this can affect customer-service chatbots, virtual assistants, support systems and other interfaces where users may not immediately realise that a machine rather than a human is responding.
The Act also introduces transparency requirements for AI-generated and manipulated content. Providers of systems capable of generating synthetic text, images, audio or video must, in the circumstances covered by Article 50, enable identification through machine-readable marking. Deployers may also face disclosure obligations where they create or manipulate deepfake content, or where AI-generated text is published for the purpose of informing the public on matters of public interest.
These requirements are not merely technical formalities. They reflect a broader regulatory direction in which companies are expected to be able to explain not only that artificial intelligence is being used, but also how the relevant outputs are identified, disclosed and governed.
The European Commission has confirmed that these Article 50 obligations apply from 2 August 2026. For certain systems already placed on the market before that date, a limited transitional period applies to the machine-readable marking requirement until **2 December 2026**.
The sanctions framework is also significant. Depending on the nature of the infringement and the relevant provisions, administrative fines can reach substantial levels, including up to **EUR 15 million or 3% of worldwide annual turnover** in the cases covered by the applicable penalty provisions.
The practical result is that AI governance is moving from policy to evidence.
Companies increasingly need to be in a position to show what systems they use, why they use them, what regulatory role they occupy, which obligations apply, and what contractual and organisational measures support their conclusions.
Why AI vendor contracts are becoming compliance documents
Traditional SaaS agreements were generally drafted around familiar commercial risks: service levels, confidentiality, data protection, cybersecurity, intellectual property and limitation of liability.
AI introduces a different layer of uncertainty because the technology itself may change over time and because regulatory responsibilities may be divided between several actors.
Imagine a company using a generative AI platform supplied by a third party. The provider controls the underlying model, its architecture and much of the technical documentation. The customer controls how the model is integrated into its business, what data is submitted, what decisions are made using the output and whether the tool is used in a regulated environment.
If the provider modifies the model, the customer’s existing risk assessment may no longer be accurate. If a regulator requests information about the system’s capabilities, limitations or transparency functionality, the customer may be unable to respond without assistance from the provider. If the system produces unlawful or misleading output, the parties may disagree over whether responsibility lies with the technology, the implementation or the business use.
A simple licence clause allowing the customer to use the AI service is therefore unlikely to be sufficient for many commercial deployments.
The contract increasingly needs to operate as a bridge between regulatory obligations and technical control.
Regulatory roles need to be understood, not merely labelled
One of the first issues that should be addressed is the intended role of each party under the AI Act.
In many transactions, the vendor will act as the provider of the AI system and the customer will act as the deployer. But that distinction is not always stable. A customer that materially modifies a system, integrates it into another product, rebrands it, or places it on the market under its own name may move closer to the position of a provider.
The agreement should therefore do more than assign generic labels. It should describe the intended use of the system, the scope of permitted modifications, the circumstances in which rebranding or white-labelling is permitted, and the parties’ respective responsibilities if the deployment changes in a way that affects the regulatory classification.
This is particularly important in startup environments, where products evolve quickly and integrations that begin as experimental features can later become central parts of a commercial offering.
The purpose of contractual role allocation is not to manipulate the legal classification. It is to make sure the parties understand the regulatory consequences of the business model they have chosen.
Transparency obligations depend on cooperation
The operation of Article 50 also illustrates why providers and deployers need to cooperate.
A deployer may be responsible for disclosing that certain content has been generated or manipulated by AI, but the technical ability to identify that content may depend on functionality controlled entirely by the provider.
The customer may need to know whether machine-readable markers are embedded in outputs, whether those markers survive export or editing, whether synthetic content can be detected reliably and whether particular features of the system trigger additional transparency obligations.
If the vendor provides no contractual commitment to assist with those questions, the deployer may be left with a regulatory duty but without access to the information needed to fulfil it.
For this reason, AI contracts should increasingly address transparency support expressly. The provider should, where relevant, commit to supplying information and functionality reasonably necessary for the customer to comply with applicable disclosure, marking and transparency obligations.
Model changes create legal risk
Another feature that distinguishes AI contracting from conventional SaaS arrangements is the speed at which the underlying technology can change.
A provider may update the model, alter its training methods, modify safety mechanisms, introduce new functionality, replace an underlying foundation model or change the way data is processed.
From a technical perspective, these changes may appear routine. From a regulatory perspective, they may be highly significant.
A company may have completed its legal assessment on the basis of a particular model version, specific documentation and defined technical characteristics. If those elements change materially, the original assessment may no longer be reliable.
For that reason, businesses using AI in commercially significant or regulated contexts should consider whether their contracts provide sufficient notice of material model changes. Depending on the risk profile, customers may also need access to updated documentation and, where a change substantially alters the regulatory position, the ability to reassess, suspend or terminate the deployment.
This is especially important for AI used in recruitment, financial services, healthcare, regulated decision-making or any environment in which changes to performance or behaviour may produce legal consequences.
Documentation is becoming part of the product
AI regulation increasingly depends on documentation.
A business using an AI system may need information about its intended purpose, known limitations, performance, testing, security measures, human oversight, data handling and regulatory classification.
The challenge is that much of this information may be held by the vendor.
The contract should therefore clarify what documentation the customer is entitled to receive, when it must be updated and how long it must remain available. In higher-risk deployments, the ability to preserve historical versions of technical documentation may also be important.
A company should not discover during an investigation or dispute that the documents on which its compliance assessment was originally based are no longer available because the vendor has updated its platform or replaced the model.
The ability to demonstrate how a compliance decision was reached may become almost as important as the decision itself.
Audit rights need to evolve with AI regulation
Traditional SaaS providers often resist broad audit rights, and in many cases that position is commercially understandable.
AI regulation does not necessarily require customers to obtain unrestricted access to source code, training data or model architecture. But it does increase the importance of some form of verification.
Depending on the system and the customer’s regulatory exposure, reasonable assurance may come through compliance certificates, independent audit reports, technical documentation, regulatory assessments, structured questionnaires or, in limited cases, more direct audit rights.
The objective is not to create unnecessary intrusion into the vendor’s proprietary technology.
It is to ensure that a company can obtain sufficient evidence to support the regulatory assurances on which its own compliance depends.
AI incidents require coordinated legal and technical responses
AI incidents can quickly become legal incidents.
A model may produce discriminatory output, disclose confidential information, hallucinate facts that cause customer harm, generate misleading synthetic content or behave unexpectedly in a regulated workflow.
Where this occurs, the immediate technical response may involve disabling functionality, reviewing logs or adjusting prompts. The legal response may involve regulatory notifications, customer communications, preservation of evidence or investigation of contractual responsibility.
For that reason, AI vendor agreements should contain a clear cooperation framework for material incidents.
The parties should know when the provider is expected to notify the customer, what information must be shared, how relevant records will be preserved and how the parties will cooperate if a competent authority becomes involved.
The same principle applies when either party receives a regulatory request relating to the system. If the customer cannot obtain timely assistance from the vendor, the customer may face enforcement risk arising from information it does not control.
Intellectual property risk remains central
AI compliance cannot be separated from intellectual-property law.
Commercial users increasingly want to know whether their prompts, uploaded documents or proprietary data may be used to train the provider’s models. They also want clarity over the use of generated outputs, the possibility of third-party IP claims and the extent to which confidential business information may be retained or reused.
Training data creates particular difficulty.
Customers may ask providers to warrant that all training data was lawfully obtained, while providers may be unwilling or unable to give an absolute assurance of that kind. The appropriate allocation of risk therefore depends heavily on the nature of the service, the provider’s level of control and the commercial significance of the output.
Nevertheless, sophisticated AI agreements should address these questions directly rather than leaving them to generic SaaS language.
For businesses using AI to produce software, designs, marketing content, legal documents or other commercially valuable outputs, the intellectual-property provisions may ultimately be just as important as the AI Act obligations themselves.
Liability should follow control
The final contractual question is often the most difficult: who bears the financial risk when the AI system creates regulatory or commercial exposure?
Many cloud agreements contain broad limitations of provider liability. That approach may become problematic where the customer’s ability to comply with regulation depends on information, functionality or documentation controlled exclusively by the vendor.
At the same time, it would be unreasonable for a deployer to expect the provider to assume responsibility for unlawful or reckless uses chosen entirely by the customer.
The more sustainable approach is to allocate responsibility according to control, knowledge and regulatory role.
Where a provider controls technical documentation, transparency functionality, model updates or training-data practices, it may be appropriate for the contract to allocate corresponding responsibility to the provider. Where the deployer determines the business use, makes consequential decisions based on output or disregards known limitations, responsibility may properly remain with the deployer.
Indemnities, warranties and liability provisions should therefore be tailored to the actual deployment rather than copied from a standard SaaS template.
What companies should review now
For many organisations, the most useful immediate step is not to draft a new AI policy, but to review how AI is actually being used across the business.
The first task is to identify material AI systems, including AI functionality embedded inside ordinary software products. Companies often underestimate their AI exposure because they focus only on tools explicitly purchased as “AI solutions.”
The next step is to determine the organisation’s role in relation to each system and to identify the regulatory obligations that may arise under the AI Act and other relevant frameworks, including GDPR, intellectual-property law, consumer protection, cybersecurity and sector-specific rules.
The contractual position should then be tested against that regulatory analysis.
If the business depends on a third-party provider to satisfy transparency obligations, provide technical documentation, explain model changes or respond to incidents, those dependencies should be reflected in the contract.
Finally, the organisation should maintain an evidence file documenting how it reached its compliance conclusions.
From AI regulation to AI contracting
The AI Act is gradually changing the structure of technology transactions.
AI compliance can no longer be treated solely as a regulatory exercise carried out by the legal or compliance team after a technology purchase has already been made.
The relevant obligations increasingly need to flow through procurement, product design, vendor management, cybersecurity and contractual negotiations.
For businesses using third-party AI, this means legal and technical teams should work together before deployment rather than after problems arise.
For AI providers, the same development also creates a commercial opportunity.
A vendor that can provide clear documentation, meaningful compliance commitments and practical regulatory cooperation may become more attractive than a technically similar competitor offering opaque terms and limited support.
In this environment, good AI contracts are becoming part of good AI governance.
How AryaTech can assist
AryaTech advises startups, technology companies and internationally operating businesses on emerging-technology regulation, AI governance and technology-related disputes.
Our “AI Act Deployment & Contract Compliance Review” is designed to assess the relationship between a company’s regulatory obligations, its actual use of AI and the contractual terms governing its technology providers.
Depending on the business model, the review can cover AI Act role and scope analysis, Article 50 transparency obligations, AI vendor and SaaS agreements, tailored AI contractual clauses, documentation and governance requirements, GDPR and data-governance interfaces, and the allocation of dispute and liability risk.
The objective is not simply to produce another AI policy.
It is to ensure that the organisation’s technology, contracts and compliance architecture operate as one coherent system.
Official and Practical References
1. Regulation (EU) 2024/1689 — Artificial Intelligence Act
The official text of the AI Act, including Article 50 on transparency obligations for providers and deployers of certain AI systems.
EUR-Lex, European Union:
https://eur-lex.europa.eu/eli/reg/2024/1689/2026-07-27/eng
2. European Commission — Transparency obligations under Article 50 of the AI Act**
European Commission guidance explaining the scope of Article 50, the application date of **2 August 2026**, the limited transition period for certain pre-existing systems and the related enforcement framework.
European Commission, Shaping Europe’s Digital Future:
https://digital-strategy.ec.europa.eu/en/faqs/transparency-obligations-under-article-50-ai-act
3. European Commission — Code of Practice on Transparency of AI-Generated Content**
A practical compliance framework addressing machine-readable marking, detection and disclosure of AI-generated content and deepfakes.
European Commission, Shaping Europe’s Digital Future:
https://digital-strategy.ec.europa.eu/en/policies/code-practice-ai-generated-content
Additional official update**
European Commission, “Commission starts enforcing AI Act rules and new transparency requirements on 2 August”, 31 July 2026:
https://digital-strategy.ec.europa.eu/en/news/commission-starts-enforcing-ai-act-rules-and-new-transparency-requirements-2-august
*This article provides general information and does not constitute legal advice.*