The European regulation on artificial intelligence does not only concern software providers. As soon as a Procurement Department engages a freelancer, an IT services company or a SaaS provider that uses artificial intelligence to produce a deliverable or contribute to a business process, it must assess part of the risk: data confidentiality, intellectual property, regulatory classification and, in some cases, direct responsibility.
The operational question is therefore not simply: “Should we allow our providers to use AI?”
It is rather: which questions should be asked before an assignment, which requirements should be included in sourcing and contracts, and what evidence should be requested? This article proposes a procurement method for managing AI use by external providers. It is intended as operational decision-making support and not as legal advice. The proposed clauses must be reviewed and approved by your Legal Department.
What the AI Act changes for a Procurement Department
The Regulation (EU) 2024/1689, known as the AI Act, entered into force on 1 August 2024 and applies in stages. Three milestones are directly relevant to Procurement.
Since 2 February 2025, the prohibited practices set out in Article 5 have applied, as has the AI literacy obligation under Article 4. Since 2 August 2025, the obligations relating to general-purpose AI models have applied. Since 2 August 2026, the regulation has entered its general application phase, notably regarding the Article 50 transparency obligations and regulatory supervision.
The timetable for high-risk systems has since been adjusted. The rules applying to several Annex III use cases, particularly in employment and workforce management, will apply from 2 December 2027. High-risk systems integrated into regulated products covered by Annex I will be concerned from 2 August 2028, subject to the applicable transitional provisions. The European Commission presents the official timetable and latest developments.
The high-risk system timetable should be checked against the latest consolidated text and official guidance before a supplier policy or contractual template is finalised. EUR-Lex remains the reference source for the applicable version of the regulation.
The decisive point for a buyer can be summed up in one sentence: the obligation does not stop at the company’s boundary. Article 4 requires providers and deployers to take measures to ensure a sufficient level of AI literacy among their staff and other people who use AI systems on their behalf.
An external provider or freelancer operating an AI tool as part of your assignment may therefore fall within this scope. This is a matter of contract, evidence and control, not just internal awareness. The AI Act, Article 4, should be reviewed with your Legal and Compliance teams before translating this principle into a standard clause.
Important note on the timetable
The implementation timetable has evolved at European level, particularly for high-risk systems. Check the status of the applicable text on the date of your decision before finalising a supplier policy or contractual template. A procurement framework based on an outdated timetable creates a false sense of security.
Are you a deployer or a provider? The three situations that can change your role
This is the question to resolve before drafting any clause, because it determines the scope of the obligations your organisation carries.
In most procurement situations, the company using an AI system provided by a third party is a deployer. Where the system is high risk, Article 26 requires the deployer to use it in accordance with the instructions for use, assign human oversight to competent and trained people, ensure the relevance of input data to the extent of its control, monitor the system’s operation, retain logs, inform workers and their representatives before deployment in the workplace where applicable, and cooperate with the authorities.
However, you may become a provider and assume the full set of obligations attached to that role. Article 25 identifies three situations:
You place your name or trademark on a high-risk system that has already been placed on the market.
You make a substantial modification to such a system.
You change the intended purpose of a system that was not classified as high risk in a way that makes it high risk.
Procurement translation: clarify the roles before signing
A project in which a provider configures, trains or adapts a tool for a specific business use under your brand may turn your company into a provider, even if no explicit decision has been made.
The clause to draft should therefore not simply prohibit certain uses. It should clarify the roles: who is the provider, who is the deployer, who assumes which obligations, and who must notify the other party if a change could alter that classification?
The case of professional services procurement
Annex III classifies certain systems used in employment and workforce management as high risk, including systems intended for recruitment, targeted job advertising, the analysis and filtering of applications, and candidate evaluation.
Professional services procurement is therefore concerned as soon as a tool contributes to the pre-screening or scoring of profiles, including independent workers. This point must be explicitly assessed with your Legal Department before deploying a matching tool, regardless of the provider.
Another sensitive area for HR procurement and workplace environments concerns Article 5, which prohibits certain emotion-recognition systems in the workplace, except in very limited cases. A provider offering a tool that “analyses engagement” or “detects stress levels” should be screened out during sourcing, not during the pilot phase.
Three types of providers, three types of risk
The most common mistake is to treat “providers” as one single category. The risks do not have the same nature, and they do not require the same contractual response.
| Provider profile | Main risk | Priority response |
|---|---|---|
Priority response | Data leakage into an uncontrolled AI tool, reuse of submitted content and uncertainty over rights attached to the deliverable | A clear supplier AI policy, a usage declaration and data rules attached to the contract |
IT services company, agency or integrator | Allocation of roles across the value chain, subcontracting and system adaptation | A contractual responsibility matrix, documentation and mutual information requirements |
Software or online service provider | System classification, documentation, performance, limitations and transparency | Documentary requirements that are enforceable from the tender stage and verifiable throughout the contract |
A freelancer will most often use publicly available AI tools on their own account and with their own settings. The main risk is therefore contractual and informational: data leakage into an uncontrolled tool, reuse of submitted content and uncertainty about the rights attached to the deliverable. The response is a clear supplier AI policy and a usage declaration attached to the contract.
An IT services company, agency or integrator may design, configure or integrate a solution into your information system. The main risk lies in the value chain: who is the provider under Article 25, what compliance evidence is supplied and how are subsequent subcontractors managed?
A software or online service provider places an AI system on the market. The main risk concerns the system’s classification and documentation: whether it is high risk, the instructions for use, information about performance and limitations, and Article 50 transparency obligations where the system interacts with people or generates content.
This segmentation should appear in your sourcing grids. Asking the same 40 questions of a technical-writing freelancer and a candidate-scoring solution provider creates two negative effects: an incomplete questionnaire and a false impression of control.
The 12 questions to ask before starting an assignment
This questionnaire can be included in the RFI or in the provider onboarding process. It must generate written, dated answers attached to the contract. An oral answer is not evidence.
Which AI tools do you use to produce the deliverables for this assignment? Name the tool, version and subscription type. A consumer plan and an enterprise plan do not necessarily provide the same guarantees.
Are our data used to train or improve models? Require a contractual guarantee, rather than a simple reference to changeable terms and conditions.
Where are the data processed and hosted? Identify subsequent subprocessors, transfers outside the European Union and the applicable legal basis under the GDPR.
Who owns the rights to deliverables produced with AI assistance? Request an explicit assignment of rights and an indemnity covering the risk of third-party infringement claims.
What proportion of the deliverable is generated or heavily assisted by AI? Request a usage declaration for each deliverable rather than a general statement at the start of the assignment.
Does the tool fall under a prohibited practice or a use listed in Annex III? A positive answer that has not been properly addressed should be disqualifying until reviewed.
What is your declared regulatory role? Have the provider state in writing whether it acts as provider, deployer, importer or distributor.
Can you provide the technical documentation and instructions for use, together with information on performance, known limitations and intended conditions of use?
What human oversight measures do you apply, and what level of AI training do the people assigned to our project have under Article 4?
How will you inform us of a model, version or subprocessor change, an incident or a detected bias? Set a notification deadline, not just a general principle.
What evidence can you provide? Depending on criticality, request ISO/IEC 42001 certification, audit reports, robustness tests, bias assessments and security review results. ISO/IEC 42001 is an international standard for AI management systems.
What happens at the end of the assignment? Specify the return and deletion of data, the treatment of prompts, histories and vector indexes, and the portability of deliverables in an exploitable format.
A simple rule applies when using this questionnaire: an answer that cannot be verified is equivalent to no answer. Unsupported supplier declarations are one of the main blind spots in compliance programmes launched under time pressure.
Propose a six-rule supplier AI policy
A supplier AI policy does not need to be a thirty-page legal document. It is a short document that can be distributed across your supplier panel and makes your expectations predictable.
Rule 1: define a common scope and vocabulary
Specify what you mean by AI use: content generation, coding assistance, data analysis, document processing or automated agents. Without a shared definition, usage declarations cannot be compared across providers.
Rule 2: distinguish three levels of use
Separate office use without sensitive data, assistance in producing deliverables and the integration of an AI system into a business process. The third level alone justifies a full review and Legal assessment.
Rule 3: establish an explicit data rule
Specify which categories of information must never be submitted to an AI tool: personal data, client data, proprietary source code, information covered by trade secrecy and non-public financial information.
Rule 4: require usage declarations
Any generative AI use that has substantially contributed to a deliverable must be declared, together with the tool involved. This rule supports traceability and, for certain content, relates to the Article 50 transparency obligations.
Rule 5: keep full responsibility for the deliverable
Using an AI tool does not reduce the provider’s obligation to verify the work, its guarantee of conformity or its responsibility for factual errors. This should be stated explicitly because it is often the first argument raised in a dispute.
Rule 6: organise traceability and review
Appoint a single contact, require the retention of traceability information for the duration of the contract and plan at least an annual review of the policy. The regulatory framework and tools evolve faster than most contracts.
Publish this policy before imposing it contractually and allow time for adoption. A panel of freelancers confronted overnight with an unexplained AI clause may refuse to sign or sign without reading it. Neither response reduces your risk.
Integrate the requirements into sourcing and contracts
At the sourcing stage
Three additions are enough to move compliance upstream. First, add an AI section to the pre-selection questionnaire, adapted to the provider profile. Second, define a clear disqualifying criterion: a prohibited practice under Article 5, refusal to guarantee that data will not be used for training, or inability to document a system involved in a sensitive process.
Third, assign a weighting to AI literacy and governance in the scoring grid. Otherwise, the criterion will have no influence on the award decision.
The principle is the same as the one already applied by Procurement to security or GDPR requirements: formalise the need and expectations before the tender, rather than discovering gaps during delivery. This is the logic of structured sourcing, in which requirements, responses and evidence remain attached to the provider profile and traceable over time.
The article “AI-enhanced procurement: how AI is reshaping the Source-to-Pay cycle?” presents the role of AI in professional services procurement and complements this operational perspective.
At the contract stage
The following clauses should be adapted and approved by your Legal Department:
| Clause | Requirement to formalise |
|---|---|
Usage declaration and authorisation | List of authorised tools, approval process for a new tool and prohibition of undeclared use |
No training and enhanced confidentiality | Commitment not to use submitted data for training, including by subsequent subprocessors |
Intellectual property | Assignment of rights in deliverables, indemnity and coverage of the consequences of third-party rights infringement |
Regulatory classification | Declared role of each party under Articles 25 and 26, with immediate notification if the classification could change |
Documentation and evidence | Delivery of instructions for use, information on limitations, any relevant certification and an obligation to keep documentation up to date |
Incidents and changes | Notification deadline for a model, version or subprocessor change, or for a detected bias or malfunction |
Audit and verification | Right to request additional evidence and, for the most critical uses, conduct an audit |
Liability and insurance | Allocation of responsibilities, caps and proof of insurance covering the relevant activity |
Reversibility and exit | Return, deletion, portability and treatment of derived elements |
Regulatory change | Mechanism for bringing the contract into compliance without a complete renegotiation |
Do not overlook personal data
The AI Act does not replace the GDPR: the two apply in parallel. As soon as an AI tool processes personal data, the usual obligations remain applicable, including an impact assessment where required.
The CNIL publishes recommendations on the development and use of AI systems, which can help define supplier requirements. The European Data Protection Board has also issued opinions on several aspects relating to AI models.
For regulated sectors, supplier risk management must also be connected with existing operational resilience and cybersecurity frameworks, which already require contractual monitoring of critical third parties. Extending an existing framework is preferable to creating a parallel process.
The five most costly mistakes
| Mistake | Why it weakens the framework |
|---|---|
Ban AI for all service providers | A blanket ban is difficult to verify and may encourage undeclared use, resulting in a loss of traceability. |
Collect questionnaires without verifying them | The risk becomes documented but remains unaddressed, which weakens the company’s position in the event of an audit or dispute. |
Copy a clause without defining the roles | A clause that does not distinguish between the provider and the deployer becomes difficult to enforce. |
Treat the issue as a Legal matter only | The classification depends on the actual use, which is known by business teams, the IT Department and Procurement. |
Freeze the framework around a fixed timetable | Deadlines and the scope of the obligations evolve, which requires periodic review. |
Structure your relationship with external service providers
Managing AI risk does not rely on one document, but on three aligned elements: requirements defined before the tender, written and verifiable commitments in the contract and traceability retained throughout the assignment.
This is the same issue as managing the provider panel more generally: knowing who is involved, which tools they use, under which conditions, and being able to demonstrate it. A sourcing platform that centralises profiles, commitments and contractual documents facilitates this traceability, whereas tracking through email exchanges quickly makes it difficult.
Are you looking to define your AI requirements before launching a tender, or secure an assignment already under way with external experts? Contact LittleBig Connection to clarify your needs.
