Adding an artificial intelligence feature to a product is now an afternoon’s work: an API key, a handful of calls, and the assistant is answering inside the application. The legal side is considerably less immediate, and tends to surface months later, when a corporate client sends its compliance questionnaire or when someone asks who is answerable for what the assistant said.
The most widespread misconception is that, because you are using a third party’s model, the obligations under Regulation (EU) 2024/1689 — the AI Act — belong to that third party. It does not work that way. The model provider answers for its model. You answer for what you put on the market.
First question: which role do you occupy?
The Regulation allocates obligations according to the role each operator performs, not according to who wrote the code.
Whoever trains and makes available the general-purpose model is the model provider. It carries the obligations attaching to general-purpose AI models: technical documentation, information to downstream integrators, a copyright policy and, where the model presents systemic risk, a reinforced regime. Those obligations neither transfer to you nor disappear.
However, when you integrate that model into your product and market it under your own brand, you are placing on the market an AI system distinct from the model. And of that system, under the Regulation’s general definition, you are the provider — not because you trained anything, but because you place it on the market under your own trade name.
The distinction matters because it determines who must inform the end user, who documents the system, who answers to the client and who appears on the file if an inspection ever comes.
One nuance is worth adding: if, beyond integrating the model, you substantially adjust it — meaningful fine-tuning, not a system prompt — it becomes arguable that you have also become the provider of the resulting model, with the obligations that entails. It is a question of degree to be assessed case by case, and it is worth raising before investing in the adjustment rather than after.
What binds you from today
Three blocks already apply, whatever your product is for.
Transparency (Article 50)
If your SaaS interacts with people, they must know they are dealing with an AI system, unless that is obvious from the context. If it generates or manipulates synthetic content — text, image, audio, video — that content must be marked as artificially generated in machine-readable form. And if it produces deepfakes or text intended to inform the public on matters of general interest, specific labelling duties apply.
These obligations have applied since 2 August 2026 and the Digital Omnibus on AI has not deferred them. A limited four-month grace period does apply to certain machine-readable marking requirements, and it runs out at the beginning of December. Anyone waiting until December to implement marking is cutting it fine.
AI literacy (Article 4)
Applicable since February 2025. Your workforce — not only the technical team, but also sales, support and management — must have a sufficient level of competence regarding the AI systems they handle. It is an obligation of means, with no standalone penalty, but non-compliance weighs as an aggravating factor when any other is assessed.
Documentation and instructions for use
If you are the provider of the system, your clients need to know what it does, what it is designed for, its known limitations and what they must not use it for. In practice this means a system datasheet and terms of use that delimit the intended purpose. It is also your best defence the day a client uses it for something it was never meant for.
When your use case becomes high-risk
This is where many projects are caught out. It is not the model that determines the risk: it is what it is used for.
If your SaaS uses AI to screen CVs, assess candidates or take decisions on promotion or dismissal; to evaluate the creditworthiness of natural persons; to allocate places or grade in education; or to manage access to essential services, the system falls within Annex III and becomes high-risk. With that come risk management, data governance, event logging, human oversight, conformity assessment and CE marking.
The Digital Omnibus on AI, published in the Official Journal on 24 July 2026 and in force since 27 July, has deferred the application of this regime: stand-alone high-risk systems under Annex III move from 2 August 2026 to 2 December 2027, and those embedded as safety components of regulated products to 2 August 2028.
This is a deferral, not a repeal. The difference matters for anyone building now: if your product is going to fall within Annex III, the extension is not a reprieve but the preparation time you did not have. Redesigning the data governance and traceability of a system already in production is far more expensive than designing it properly from the outset.
The other front: data protection
The AI Act does not displace the GDPR; it adds to it. And in the integration of a model API three points fail with some regularity.
— The processor chain. If your users’ prompts contain personal data — and they almost always do — the API provider acts as a processor or sub-processor. That requires an Article 28 contract, documented instructions and, importantly, that your own client contracts contemplate that sub-processing.
— International transfers. Most leading model providers are established outside the EEA. The transfer basis must be identified and it must be verified where requests are actually processed: some providers offer processing in a European region, and whether or not that is enabled changes the analysis entirely.
— Retention and training. It is worth verifying, and placing on record, that the provider does not use data submitted through the API to train its models, and what the actual retention period for requests is. This is usually found in the enterprise product documentation, not in the general terms accepted when the account is created.
Where the processing is likely to result in a high risk, an Article 35 impact assessment is added to all of the above.
And one point that is not regulatory but costs clients
If your SaaS serves law firms, professional advisers, healthcare or any sector under reinforced confidentiality duties, their compliance officers will ask what happens to the information their users enter into the assistant. Having that answer in writing, backed by the model provider’s contract, is today as much a commercial requirement as a legal one.
Minimum checklist before going to production
— Determine and document which role you occupy: provider of the AI system, deployer, or both depending on the module.
— Implement the AI interaction notice and the marking of synthetic content, without waiting for the grace period to expire.
— Check whether the use case appears in Annex III and, if so, plan compliance against the December 2027 horizon.
— Formalise the processing agreement with the API provider, review international transfers and disable the use of data for training.
— Draft the system datasheet and terms of use delimiting the intended purpose.
— Evidence the AI training of the teams that handle it.
— Review that your client contracts reflect the sub-processing and the allocation of responsibilities.
Conclusion
Integrating a third party’s model does not outsource compliance: it distributes it. The model provider answers for the model; you answer for the product you sell under your brand. The good news is that almost everything required today — transparency, documentation, contracts and training — is a matter of weeks rather than quarters, provided it is addressed before the product is in clients’ hands.
At Ferrer-Bonsoms Abogados we advise technology companies on classifying their AI systems, the documentation required and the negotiation of contracts with model providers. If you are integrating AI into your product and want to know where you stand, get in touch.