According to the Standish Group, only 17% of IT projects meet both planned budgets and deadlines. When a provider uses AI to generate code, train models or automate processes, contractual gray areas multiply. Who owns intellectual property in partly AI-generated code? Can your business data train a model reused for a competitor? What compliance guarantees must your provider offer under the European AI Act?
The French software and digital services market is worth €62.4 billion in 2025, with 78% of companies now developing custom solutions (Syntec Numérique, 2025). Every development contract commits strategic assets: source code, data, algorithms and trained models. Yet most standard contracts contain no AI-specific clauses.
This article details essential clauses for software development contracts in the AI era, from intellectual property and delivery guarantees to training data confidentiality and regulatory compliance.
TL;DR: A software development contract incorporating AI must cover five critical areas: explicit assignment of intellectual property rights, including AI-generated code; confidentiality and nonreuse of training data; delivery and functional conformity guarantees; GDPR and AI Act compliance; and exit and transfer provisions. Without these protections, you risk losing control of digital assets.
Why Traditional Software Development Contracts Are No Longer Enough
AI-Generated Code Creates an Unprecedented Legal Gap
French copyright rests on a fundamental principle: only a natural person can author an intellectual work (Article L111-1 of the Intellectual Property Code). When a developer uses GitHub Copilot, ChatGPT or another generative AI tool for part of the code, ownership becomes an acute question.
No French court has yet ruled on copyright protection for entirely AI-generated code. The legal gap is real, and ambiguity systematically favors whoever drafted the contract, usually the provider.
A development contract signed in 2024 or 2025 without AI-specific clauses exposes the client to three concrete risks: inability to prove ownership of delivered code, potential reuse of shared AI components across clients and no traceability of code origins.
The AI Act Creates New Contractual Obligations
The European AI Act, which entered into force on August 1, 2024, introduces a progressive obligation schedule directly affecting client–provider relationships.
Since February 2, 2025, AI practices presenting “unacceptable risk” have been prohibited. Since August 2, 2025, general-purpose AI model providers must meet transparency and copyright compliance obligations (Article 53). From August 2, 2026, high-risk systems must meet strict requirements: technical documentation, risk management, human oversight and traceability.
Contracts must therefore clearly divide compliance obligations. Who classifies AI risk? Who produces required technical documentation? Who manages CE marking if the system is high-risk?
IT Disputes Are Expensive and Lengthy
IT contract litigation usually pits an IT services firm or software vendor against its client over recurring issues: nonconformity with specifications, functional instability (bugs, anomalies), delays or data loss during installation.
According to the Standish Group, 52.7% of IT projects exceed forecast budgets by an average of 189%. These overruns often originate in imprecise contracts where result obligations, acceptance criteria and delay penalties remain unclear. Adding AI multiplies potential disputes.
Intellectual Property: Clauses That Actually Protect Assets
Assignment of Rights Under Article L131-3 of the Intellectual Property Code
The French Intellectual Property Code is clear: a services contract does not automatically transfer copyright to the client. Article L131-3 requires every assignment to state explicitly:
- Each assigned right individually (reproduction, adaptation, distribution, communication to the public)
- Scope and intended purpose of the assignment
- Territory covered
- Duration of the assignment
Without these particulars, the assignment is legally void. The provider retains source code ownership, leaving the client dependent on software it does not own and cannot modify or entrust to another provider.
This formal requirement gains another dimension with AI components. The assignment must cover both human-written code and elements produced or assisted by generative AI tools.
What a Complete Intellectual Property Clause Must Cover in 2026
| Element | Required contractual detail | Risk if missing |
|---|---|---|
| Human-written source code | Assignment compliant with Article L131-3: listed rights, scope, duration, territory | Provider retains code ownership |
| AI-generated code | Assignment extended to outputs of AI tools used during development | Legal gray area the provider can exploit |
| Trained models | Ownership transfer or exclusive license for fine-tuned models | Provider can reuse the model for a competitor |
| Training data | Nonreuse and dataset return clause | Business data feeds other projects |
| Technical documentation | Rights assignment for specifications, architecture, API documentation | Maintenance dependence on provider |
| Open-source components | Inventory of third-party licenses (GPL, MIT, Apache) | Undetected viral license contamination (GPL) |
Models Fine-Tuned on Your Data
When a provider trains or fine-tunes AI on business data, the contract must distinguish three elements:
The foundation model: this generally belongs to a third-party vendor such as OpenAI, Anthropic, Mistral or Meta. The contract must specify the license under which the model is used and the restrictions applying to your commercial use.
Fine-tuned model weights: these constitute company-specific added value. Without explicit transfer, the provider could reuse them for another client, building competitive advantage on your data.
Training pipeline: fine-tuning scripts, configurations and methodologies. Their transfer ensures autonomy for future iterations.
A robust intellectual property clause covers all three layers and provides a verification mechanism—a technical audit—to confirm that the delivered elements match what the contract describes.
Training Data Confidentiality: The New Contractual Battleground
Why Business Data Is at Risk
An IT services firm developing AI software may handle three sensitive data types: business data (transactions, customers, processes), training or fine-tuning data and production-generated data.
In 2025, the European Commission published updated model contractual clauses for AI systems in public procurement, in accordance with Article 25.4 of the AI Act. These model contracts illustrate a fundamental principle: making data protection a contractual requirement has become essential, rather than optional.
The main risk is unauthorized reuse. Without restrictions, a provider serving multiple clients in one industry may use insights from your data to improve its general offering, or worse, feed an AI model reused for a direct competitor.
Five Confidentiality Clauses to Require
1. No Data Reuse for Training
The contract must explicitly prohibit any reuse of your data to train, fine-tune or evaluate AI models intended for other clients or for improving the provider's internal products, unless you have given prior written agreement. This clause goes beyond traditional confidentiality: it specifically addresses use as training data.
2. Exclusive Data Ownership
State unequivocally that the client remains sole owner of its data. The provider receives only usage rights strictly limited to contract performance, with verifiable deletion required at the end.

3. Technical Environment Isolation
Beyond contractual promises, require technical guarantees: data processed in an isolated environment, without pooling with other clients' data. This is especially critical on shared cloud platforms.
4. Access and Processing Traceability
The CNIL recommends AI systems with operational transparency, including event recording. Require access logs available on request identifying who accessed what, when and for what purpose.
5. No Transfers Outside the EEA Without Safeguards
Transfers outside the European Economic Area require appropriate safeguards (standard contractual clauses or equivalent mechanisms). This GDPR obligation becomes especially important when providers use AI APIs hosted in the US or Asia.
GDPR Compliance: AI-Specific Obligations
AI software development raises specific GDPR questions contracts must anticipate. The CNIL has published explicit recommendations for AI system development.
The central principle is that data collected for one purpose cannot be reused for a radically different one. Training an AI model constitutes a new purpose requiring a distinct legal basis. The contract must document that legal basis and provide mechanisms for data subjects to exercise their rights of access, rectification, objection and erasure.
An often-neglected issue is the “right to be forgotten” applied to AI models. If a user requests deletion of data used in training, deleting the database entry is insufficient: learned patterns remain. Specify a technical procedure for this situation (retraining, machine unlearning or documented justification of technical impossibility).
Delivery Guarantees: Turn Promises into Contractual Obligations
Obligations of Means vs. Obligations of Result: Make the Distinction Explicit
This distinction remains the main friction in French IT litigation. An obligation of means commits the provider to deploying necessary resources without guaranteeing results. An obligation of result commits it to delivery conforming to defined specifications.
AI development contracts should combine both:
| Project phase | Obligation type | Rationale |
|---|---|---|
| Analysis and design | Enhanced obligation of means | Technical exploration needs an uncertainty margin |
| Deterministic feature development | Obligation of result | Traditional code must meet specifications |
| AI component development | Obligation of means with performance thresholds | AI performance depends on data quality |
| Integration and acceptance | Obligation of result | Final delivery must pass defined tests |
| Corrective maintenance | Obligation of result | Identified bugs must be fixed |
This granular approach avoids two pitfalls: a contract consisting entirely of obligations of result, which would deter serious providers because AI involves some experimentation; and a contract consisting entirely of obligations of means, which would leave you without recourse if the delivered software did not work.
Define Measurable Acceptance Criteria for AI Components
AI components cannot be accepted like deterministic code. A classifier may reach 95% accuracy on a test set and 78% in production. Anticipate this gap through objective criteria.
Contract metrics by component type:
Classification model: accuracy, recall and F1 score, with minimum thresholds on a jointly validated representative test set.
Text generation model: maximum acceptable hallucination rate, human-panel relevance score and brand guideline compliance.
Recommendation system: minimum click-through rate (CTR), recommendation diversity and absence of measurable discriminatory bias.
Chatbot or conversational agent: first-contact resolution, response time and human escalation rate.
The contract must specify the evaluation methodology—which dataset, how often testing occurs and who validates the results—and provide a period of validation under real conditions through A/B testing or shadow mode before final acceptance.
Penalties, Milestones and Exit Mechanisms
A robust AI software contract structures verifiable milestones with clear progression conditions:
Delivery milestones: each milestone corresponds to a defined deliverable: approved mockups, a functional MVP, a beta version or a production version. The contract associates each milestone with a deadline, a precise deliverable and acceptance criteria.
Delay penalties: these must be proportional and progressive. A common standard is 0.5–1% of the milestone amount per day of delay, capped at 10–15% of the total amount. Penalties that are too low provide no incentive to meet deadlines; penalties that are too high encourage the provider to rush out a poor-quality product to avoid sanctions.
Early termination: if cumulative delay exceeds a defined threshold, for example 30 days, the client can terminate and recover produced deliverables, source code, models and documentation without client penalties.
Operational warranty: a postdelivery period of 3–12 months depending on complexity, during which blocking and major defects are corrected free.
Exit and Continuity: Prepare the Handover at Signing
The Technical Dependency Trap
Reversibility is the ability to regain control of software internally or through another provider when the relationship ends. Without an exit and transfer clause, vendor lock-in can make changing providers prohibitively expensive.
AI amplifies this risk. A model trained on specific infrastructure with proprietary dependencies may be technically impossible to migrate if portability was not anticipated contractually.
Assets to Recover at Contract End
Explicitly list what the provider must transfer:
- Complete source code, including version history (Git repository)
- Trained AI models in standard portable formats (ONNX, SavedModel, etc.)
- Training and test datasets used
- Complete technical documentation (architecture, APIs, deployment procedures)
- Infrastructure configurations (IaC scripts, Docker files, CI/CD pipelines)
- Secrets and credentials (API keys, certificates, access tokens)
- Third-party licenses needed for operation
The transfer must be accompanied by a transition period, typically 1–3 months, during which the outgoing provider supports the handover. Its assistance obligation must be documented and billed at a predefined rate.
Source Code Escrow: Additional Protection
Depositing source code with a trusted third party protects against provider failure (judicial liquidation, cessation of business). Code is released to the client when a contractually defined trigger occurs.
For AI projects, escrow must include trained models and data pipelines as well as code. Quarterly deposits or deposits at each major version are good practice.
Regulatory Compliance: Incorporate the AI Act
Allocate Compliance Responsibilities
The AI Act distinguishes provider, deployer and user roles, each with specific obligations. Clarify each party's role.

In most custom development projects, the contractor is the AI system provider and the client the deployer. This implies:
Contractor obligations (provider):
- Assess and classify system risk
- Produce required AI Act technical documentation
- Establish risk management
- Guarantee training data quality
- Conduct predeployment conformity tests
Client obligations (deployer):
- Use according to provider instructions
- Provide human oversight in production
- Report incidents and malfunctions
- Inform people affected by AI processing
Include an adaptation clause: if classification changes, such as limited risk becoming high risk after modification, obligations adjust and compliance costs are divided under a predefined formula.
Technical Documentation as a Contractual Deliverable
From August 2, 2026, high-risk AI systems must be accompanied by complete technical documentation. This documentation is not an optional extra: it is a legal obligation.
Include it among mandatory deliverables, with AI Act-compliant detail:
- General system description and purpose
- Training, validation and test data information
- Performance metrics and known limitations
- Cybersecurity and robustness measures
- Deployer instructions
- Human oversight procedures
Checklist: 20 Clauses to Verify Before Signing
Use this checklist before approving any AI software development contract:
Intellectual property
- Rights assignment compliant with Article L131-3 (listed rights, scope, duration, territory)
- Explicit extension to AI-generated code
- Ownership transfer of AI models fine-tuned on your data
- Open-source component and license inventory
- Noninfringement warranty (provider guarantees no third-party rights violations)
Confidentiality and data
- Prohibition on data reuse to train third-party models
- Exclusive client data ownership
- Technical isolation of processing environments
- Data access traceability (accessible logs)
- Controls on transfers outside the EEA
Delivery guarantees
- Explicit obligation type (means/result) per phase
- Measurable AI acceptance criteria (metrics, thresholds)
- Delivery milestones with dates and acceptance criteria
- Proportional, progressive delay penalties
- Postdelivery operational warranty (duration, scope)
Exit and transfer
- Exhaustive end-of-contract transfer list
- Transition period with mandatory provider assistance
- AI model delivery format (ONNX or portable equivalent)
- Source code and model escrow
Regulatory compliance
- AI Act responsibility allocation (provider/deployer) and adaptation clause
FAQ
Can a Provider Refuse to Transfer Source Code Ownership?
Yes. Under French law, the software author (the provider) retains ownership without written assignment. No legal obligation compels transfer; it is negotiated. If refused, negotiate at least an exclusive, perpetual, irrevocable license covering every use needed for operations.
Is Code Generated by GitHub Copilot or ChatGPT Copyright-Protected?
French courts have not yet decided. Copyright requires an “imprint of the author's personality,” presupposing a human author. Entirely AI-generated code may be unprotectable. Anticipate uncertainty through broad assignment explicitly covering AI outputs regardless of future legal classification.
What Penalties Does the AI Act Provide for Noncompliance?
Fines can reach €35 million or 7% of worldwide annual revenue for prohibited practices, €15 million or 3% for high-risk-system violations, and €7.5 million or 1% for providing incorrect information. Specify which party bears financial responsibility according to the violation.
How Can I Verify My Provider Does Not Use My Data to Train Other Models?
Require technical audit rights exercisable by an independent third party, timestamped access logs, certified destruction at contract end and documented environment isolation. Add deterrent contractual penalties for proven breaches.
Should You Require an Obligation of Result for AI Components?
Not systematically. Performance depends heavily on client-provided data quality and volume. An enhanced obligation of means with contractual thresholds (minimum accuracy, maximum error rate) is generally the most balanced and defensible approach in litigation.
What Happens if the Provider Goes Bankrupt Mid-Project?
Without exit provisions and escrow, you may lose access to code, models and documentation. Trusted-third-party escrow with automatic release in insolvency proceedings is the best protection. Also require regular interim deliveries to limit exposure.
AI Coder Squad: Clear Contracts for Controlled AI Projects
Every AI Coder Squad project comes with a transparent contractual framework: complete IP assignment, source code delivered at each milestone and technical documentation included. Code ownership, data confidentiality and exit provisions are addressed from the commercial proposal.
AI Coder Squad designs custom applications and AI agents for companies that want to move fast without sacrificing quality, with senior developers and an AI-powered approach.
→ Start your project and discover how AI Coder Squad can accelerate your next delivery.