AI Regulation for French Companies: A Practical Compliance Guide

Artificial intelligence is becoming part of ordinary French business operations. A manufacturer uses computer vision to inspect parts, a sales team drafts account messages, a bank reviews documents, a logistics company predicts delays, a support team summarizes calls, and an HR department ranks applications. The pressing question is not whether your company uses AI. It is whether you know where it is used, what information it receives, which people it affects, what decisions it influences, and what evidence you can produce when a customer, employee, works council, regulator, board member, or supplier asks.

This guide is for French B2B companies, including groups with operations in several EU Member States and companies that sell AI enabled products into Europe. It describes the legal and regulatory position as checked against official sources through September 2026. It is practical operating guidance, not legal advice. Scope depends on your role, product, data, sector, customers, geography, and implementation date. Ask qualified French and EU counsel to confirm a high impact use before launch.

The French position in plain English

France does not have a separate general AI act that replaces the European Union AI Act. The EU AI Act is a directly applicable EU regulation, and France is responsible for national implementation and supervision within the framework it creates. The central text is Regulation (EU) 2024/1689, the Artificial Intelligence Act. It applies according to the roles and activities defined in the regulation, including some providers outside the EU whose systems or outputs are used in the EU.

The AI Act is only one layer. GDPR remains binding when personal data is processed. The French Data Protection Act, or Loi Informatique et Libertés, supplements GDPR and gives the CNIL important powers and guidance. French employment law, consumer law, civil liability, intellectual property, cybersecurity requirements, product safety rules, and sector regulations can apply to the same system. A model does not make the underlying activity legally neutral.

Keep a legal register with distinct labels. Binding law includes EU regulations, French statutes and regulations, valid regulator decisions, court orders, and contractual commitments. CNIL recommendations, European Commission guidance, standards, and codes of conduct can be valuable interpretive or operational guidance, but they are not automatically statutes. A draft delegated act, consultation, strategy, proposal, press announcement, or future measure is not a current obligation. Voluntary controls can be adopted internally, but record that choice honestly.

EU AI Act timing and roles

The AI Act uses a risk based structure. It prohibits certain unacceptable practices, imposes transparency duties on particular systems, places requirements on high risk systems, and creates obligations for providers of general purpose AI models. It also sets duties for deployers, importers, distributors, authorised representatives, and other participants. The correct classification depends on what the system does, who places it on the market, who deploys it, the intended purpose, and the applicable annexes. Do not classify a product only by the marketing label attached to a model.

The main dates matter. The prohibitions and AI literacy requirement started applying on 2 February 2025. Governance rules and obligations for general purpose AI models started applying on 2 August 2025. Most remaining provisions, including the main high risk and transparency framework, apply from 2 August 2026. High risk AI systems embedded in regulated products have a later date of 2 August 2027. Check the European Commission AI Act page and the regulation itself for amendments, implementation acts, exceptions, and the current timetable.

These dates do not mean a company can ignore preparation until the last date. Contracts, GDPR, product safety, employment duties, and consumer protection may apply already. A provider also needs design documentation, data governance, instructions, monitoring, and conformity work before a system can be placed on the market. A deployer needs operating procedures, competent oversight, records, and notices appropriate to the system. Treat the date as a legal milestone, not as the start of governance.

Prohibited practices and high risk use cases

The AI Act prohibits specified practices, subject to the exact wording and exceptions in Article 5. Examples include certain manipulative or deceptive techniques, exploitative uses of vulnerabilities, social scoring, some biometric categorisation, and certain biometric identification practices. The practical lesson is to review purpose and effect, not merely model capability. A system can create a prohibited practice through its configuration, data, interface, or business process even if the underlying model is sold as general purpose.

High risk systems include systems listed in Annex III and AI that is a safety component of, or itself a product covered by, specified EU harmonisation legislation. Annex III areas include biometrics, critical infrastructure, education, employment, worker management, access to essential private and public services, law enforcement, migration, justice, and democratic processes. An internal lead scoring tool is not automatically high risk. An employment system that evaluates candidates or workers may be. Document the classification reasoning and obtain specialist review when the boundary is uncertain.

For a high risk system, requirements can include risk management, data and data governance, technical documentation, automatic logging, transparency and instructions, human oversight, accuracy, robustness, cybersecurity, quality management, conformity assessment, registration, post market monitoring, and incident reporting. Providers and deployers have different duties. A French company that buys a system does not automatically inherit every provider duty, but it cannot assume that procurement ends its responsibilities.

CNIL guidance and authority

CNIL is France’s independent data protection authority. Under GDPR and the French Data Protection Act, it can investigate, issue warnings and orders, restrict processing, impose administrative fines within the applicable limits, and publish decisions. It is not the sole authority for every AI Act category, but it remains central whenever personal data, individual rights, profiling, or data protection governance is involved. Other French authorities may have roles under the AI Act and sector laws, so identify the competent authority rather than assuming every issue belongs to CNIL.

CNIL’s AI hub and its practical guidance on AI provide useful material on legal bases, purpose limitation, data minimisation, data subject rights, security, impact assessments, and the relationship between AI development and GDPR. CNIL guidance is not a new act of Parliament. It is authoritative regulatory guidance that helps explain expectations and enforcement risk. Separate what GDPR requires from what CNIL recommends as a prudent implementation method, and record the source and date of each conclusion.

CNIL also has a role in the French AI ecosystem through consultation, innovation support, investigations, and enforcement. Its advice does not provide a blanket approval for a product. An informal exchange, sandbox discussion, or guidance page cannot replace a documented legal basis, data protection impact assessment, security review, or decision by the accountable business owner. Keep evidence that your team considered relevant CNIL material and explain any justified departure.

GDPR still governs personal data

The GDPR applies when an AI workflow processes personal data. That includes obvious identifiers, but also free text, voice, images, device data, employment records, customer history, location, inferred attributes, embeddings, prompts, outputs, and logs that relate to an identifiable person. Pseudonymisation reduces risk but does not automatically make information anonymous. A model provider’s statement that it does not train on prompts does not answer every GDPR question.

For every use case, identify the controller and processor roles, purpose, legal basis, categories of people and data, recipients, transfers, retention, security, rights process, and whether a special category is involved. A contract with a vendor should describe processing instructions, confidentiality, security, assistance, deletion or return, subprocessors, audits, and breach support as appropriate under Article 28. If the supplier uses inputs for its own purpose, it may not be only a processor. Have the roles assessed from the facts rather than copied from a template.

Legitimate interest, contract, legal obligation, consent, and other GDPR bases each have conditions. Do not use consent as a universal cure for excessive collection, an incompatible purpose, an imbalance between employer and employee, or a decision that lacks fairness. Special category data requires an additional Article 9 condition. Criminal data has its own restrictions. Document necessity, proportionality, alternatives, balancing where relevant, and the information given to people.

Automated decisions and profiling

Article 22 GDPR addresses decisions based solely on automated processing, including profiling, that produce legal effects or similarly significantly affect a person. The rule has defined exceptions and safeguards, including the right in relevant cases to obtain human intervention, express a point of view, and contest the decision. The analysis is fact specific. Calling a model output a recommendation does not resolve the issue if staff routinely accept it without meaningful review.

Map the full chain. A model may rank a candidate, prioritise a support case, flag a customer, set an offer, assess creditworthiness, recommend a dismissal review, or decide whether a supplier passes a gate. Ask what happens after the output, who can change it, how often people override it, and whether the affected person has a practical route to challenge the result. A human reviewer needs authority, time, relevant context, training, and a genuine ability to disagree.

Provide a useful explanation. Tell the person that automation or profiling is involved where required or materially relevant, describe the purpose and main factors in understandable language, identify the responsible organisation, and explain how to request review or correction. Do not promise a technical explanation the system cannot provide. Preserve the input or record needed to reconstruct the result, the model version, the reviewer’s reasoning, and the outcome, subject to minimisation and applicable confidentiality.

French data and employment law

The French Data Protection Act supplements GDPR and remains relevant to national procedures, specific processing rules, and CNIL powers. The official Legifrance text should be checked with the current GDPR text and implementing provisions. French companies should also consider secrecy, confidentiality, intellectual property, trade secrets, and records rules when prompts or outputs contain business information. A privacy review is not a substitute for an employment, commercial, or security review.

The French Labour Code limits how employers introduce technology into work. Under Article L1222-3, information collected by a device or technique used to control employee activity must be relevant to the purpose pursued. Employees must be informed in advance of methods and techniques used to collect personal information. The official Labour Code text should be reviewed for the current provisions, related consultation duties, collective agreements, and the specific work process.

Before deploying AI for hiring, scheduling, performance, productivity, monitoring, promotion, discipline, or termination, involve HR, legal, the DPO, worker representatives, and occupational stakeholders as appropriate. Define job relevance, accessible accommodation, source data correction, review criteria, bias testing, notice, retention, and appeal. Do not conceal an AI tool in a vendor feature or treat an employee’s continued work as meaningful consent. If a works council consultation is required, schedule it before an irreversible rollout.

Consumer transparency and B2B boundaries

A B2B company can still serve individuals, employees of business customers, sole traders, or consumers. The French Consumer Code and EU consumer protection rules can apply to the offer, interface, marketing, pricing, recommendations, and customer service. The official Consumer Code is the starting point. Avoid claims that an AI feature is accurate, autonomous, unbiased, secure, or compliant unless the claim is supported by evidence and qualified by material limitations.

Tell a person when they are interacting with an AI system when the context requires it, including the AI Act transparency duties that apply from their relevant date. Make generated or manipulated content appropriately identifiable when the regulation requires disclosure. Give customers a human route for complaints, account changes, contractual questions, and consequential outcomes. A disclaimer buried in standard terms does not fix a misleading interface or an inaccessible escalation path.

Public sector and private sector distinctions

A private company does not become a public authority merely because it uses AI. Public bodies, however, may face additional duties under the AI Act, French administrative law, public procurement rules, transparency obligations, sector security requirements, and their own internal policies. A supplier working for a ministry, municipality, hospital, or public operator must map the customer’s obligations into the contract and delivery design. Public sector use can involve stricter documentation, accessibility, audit, hosting, reversibility, and human decision requirements.

The distinction also matters for prohibited practices and high risk classification. AI used by or on behalf of public authorities can trigger provisions that do not apply in exactly the same way to a private internal workflow. A public customer’s tender documents may require standards, sovereign hosting, security accreditation, source access, impact analysis, or audit rights even when a private customer would not. Treat those requirements as contract and procurement obligations, and do not market public sector alignment as a universal legal certification.

AI literacy is an operating duty

The AI Act requires providers and deployers to take measures to achieve a sufficient level of AI literacy for staff and other people operating systems on their behalf, taking account of technical knowledge, experience, education, training, context of use, and affected people. This is binding law within the scope and timing of Article 4. It does not prescribe one universal course, test, or certificate. Keep a role based training record that shows why the content and frequency fit the use.

A salesperson needs safe data handling, claim verification, and disclosure skills. An operations reviewer needs escalation, override, and error correction skills. An engineer needs access control, prompt injection, evaluation, logging, and rollback skills. A manager needs to recognise automation bias and understand accountability. Training should include realistic scenarios, a route to report incidents, and refreshers when a model, purpose, connected action, or risk changes. A policy acknowledgement alone is weak evidence of literacy.

Sector rules can change the answer

The AI Act does not replace sector regulation. Financial services firms should consider EBA and ACPR expectations, outsourcing, model risk, anti money laundering, credit, fraud, customer information, and operational resilience. Insurers should review underwriting, claims, pricing, fairness, and explanation. Health companies should consider medical device rules, clinical safety, health data, professional duties, and patient communication. A model that helps a clinician is not automatically the same as a regulated medical device, and a model embedded in a product may change the analysis.

Manufacturers should connect AI governance to product safety, machinery rules, quality management, industrial cybersecurity, maintenance, and worker safety. Transport, energy, defence, telecoms, and critical infrastructure companies need specialist assessment. Law firms and regulated professionals should address privilege and professional secrecy. Accountants and auditors should preserve independence and evidence. Ask the sector owner to approve each high impact use. General privacy approval cannot substitute for an engineering, clinical, financial, employment, or safety review.

Procurement and vendor controls

Buying an AI feature does not transfer all accountability to the vendor. The supplier controls parts of the model and infrastructure. Your company controls purpose, users, prompts, connected data, configuration, customer promises, and downstream decisions. Classify the service before accepting standard terms. A private drafting assistant and an agent that changes a customer account or ranks workers need different due diligence and approval authority.

• Identify the provider, deployer, importer, distributor, model family, versions, intended purpose, hosting locations, subprocessors, support access, and change process.
• Specify whether inputs, outputs, feedback, telemetry, files, and logs are used for training, evaluation, product improvement, or another secondary purpose.
• Require security, privacy, retention, deletion, access, transfer, incident, vulnerability, regulatory cooperation, and business continuity commitments appropriate to the use.
• Require advance notice and review rights for material model, data use, hosting, subprocessor, capability, safety, or contractual changes.
• Define service limits, human escalation, rollback, export, audit evidence, service levels, accessibility, language support, and termination assistance.
• Prohibit unapproved high impact decisions and require disclosure of limitations, evaluation results, known incidents, and material dependencies.

Ask for evidence rather than a badge. A vendor’s statement that a system is AI Act compliant is not a classification decision, conformity assessment, GDPR role analysis, or proof that the configured service is appropriate. Review technical documentation, instructions, data use settings, security evidence, evaluation results, audit reports, incident history, and change controls. For critical uses, test the exit plan and confirm that the company can safely operate if the vendor is unavailable or changes the model.

Create an inventory before a policy

Start with visibility. Ask every function to list purchased software, embedded AI, APIs, experiments, browser tools, open source models, spreadsheet add ons, agents, and uses created without procurement approval. Reconcile answers against software assets, cloud bills, identity groups, expenses, data processing records, product roadmaps, vendor questionnaires, and security logs. Shadow AI is a governance finding. Omitting it makes the risk picture less accurate.

• System and feature, model or provider, version, owner, users, business purpose, lifecycle stage, and connected actions.
• Input data, output recipients, personal and special category data, confidential information, children’s data, retention, and transfer locations.
• Affected people, geography, language, sector, decision impact, autonomy, human review, override authority, and ability to stop.
• Vendor, contract, hosting, subprocessors, training settings, security controls, incident contact, regulatory role, and exit plan.
• Known limitations, evaluation results, fairness and accuracy concerns, legal classification, open questions, and next review date.

Risk classification that helps decisions

Use two labels. First record the legal classification under the AI Act and other applicable law. Then use an internal operational tier for approval and control. A low internal tier might cover drafting with no personal or confidential input and no decision effect. A medium tier might cover customer interaction, retrieval, or workflow recommendations that require verification. A high tier might cover employment, credit, health, eligibility, safety, biometrics, essential services, regulated products, or autonomous action. A prohibited tier stops uses that law forbids or that cannot be controlled with available evidence.

Reassess when the model, data source, user group, geography, language, connected action, customer, or business purpose changes. A low risk summarizer can become high risk when it receives HR files or sends final notices. Record why the use received its classification, who approved it, required controls, residual risk, and the event that triggers another review. Never describe an internal tier as an official EU or French legal category.

Human oversight that is real

Human oversight is more than placing a person at the end of a workflow. The reviewer needs relevant context, understandable instructions, competence, independence from throughput pressure, enough time, access to source records, authority to override, and a way to stop the system. Design the interface to surface uncertainty, missing data, conflicts, and reasons for escalation. Prohibit automatic execution when the use case requires a decision that the reviewer cannot safely assess.

Measure whether oversight works. Sample recommendations and final outcomes, compare reviewer decisions, investigate rubber stamping, track overrides and corrections, and test difficult cases in French and relevant customer languages. Keep a human escalation route for customers and workers. If the system takes an external action, use least privilege, approval thresholds, transaction limits, confirmation steps, and a reversible design. Make the accountable person visible in the operating record.

A practical implementation roadmap

In days 1 to 30, establish visibility and stop avoidable exposure. Appoint an executive sponsor, DPO or privacy lead, security contact, legal owner, procurement lead, and system owners. Issue an interim rule for sensitive data, unapproved tools, prohibited practices, and high impact decisions. Inventory use cases across business, IT, HR, product, security, procurement, and suppliers. Screen each use for AI Act role and classification, GDPR, CNIL guidance, French employment and consumer effects, sector rules, vendor data use, and autonomous action.

In days 31 to 60, turn findings into controls. Approve internal tiers and decision records. Publish the acceptable use standard and role based AI literacy plan. Create an approved tool catalogue. Update procurement questionnaires and priority contracts. Complete DPIAs and expanded AI impact reviews for high exposure uses. Configure access, redaction, retention, logging, notices, human escalation, incident intake, and French language testing. Create a legal register that labels binding law, guidance, standard, contract, proposal, and future effective date.

In days 61 to 90, test the operating model. Run accuracy, robustness, fairness, privacy, security, accessibility, and language tests appropriate to each use. Sample logs and human overrides. Run an incident tabletop involving a privacy disclosure, fabricated customer answer, biased employment recommendation, and unauthorized agent action. Test rollback and vendor outage procedures. Add a change gate for models, prompts, data sources, integrations, user groups, and material vendor changes. Report unresolved high risks and overdue evidence to leadership.

Evidence an auditor can understand

• AI inventory with owner, purpose, provider, version, role, data, users, affected people, geography, classification, and review date.
• Legal register identifying the AI Act article, GDPR provision, French rule, CNIL guidance, sector source, contract, proposal, and effective date.
• DPIA and AI impact review covering alternatives, necessity, proportionality, residual risk, approval conditions, and reassessment triggers.
• Data flow, legal basis, notices, rights handling, retention schedule, access review, transfer assessment, deletion process, and security design.
• Model and dataset documentation, evaluation methods, limitations, fairness checks, accessibility, French language tests, and change history.
• Human oversight instructions, escalation routes, override samples, reviewer training, correction records, and evidence that review was effective.
• Vendor diligence, contract clauses, subprocessors, technical documentation, conformity evidence where relevant, incident commitments, and exit plan.
• AI literacy records, approved tool catalogue, acceptable use acknowledgements, shadow use findings, and remediation actions.
• Incident register, preserved evidence, impact assessment, regulator or customer communications, corrective action, and restart approval.
• Executive decisions, risk acceptances, exceptions, KPIs, audit samples, and scheduled governance reviews.

KPIs that show control

Measure coverage and effectiveness together. Coverage measures include the percentage of known uses inventoried, the percentage with an owner and legal classification, completed DPIAs, approved tool adoption, AI literacy coverage by role, vendor evidence coverage, and material changes reviewed before release. Outcome measures include human review completion, meaningful override rate, error rate by relevant group and language, privacy incidents, time to contain, time to correct a record or decision, rollback test success, customer escalation time, and unresolved high risks by age.

Common failure modes

• Waiting for the AI Act date while ignoring GDPR, French employment law, consumer protection, sector duties, and contract commitments already in force.
• Calling CNIL guidance, a harmonised standard, a Commission FAQ, or a proposal binding law without checking its legal status and scope.
• Assuming the EU AI Act has one simple label for every model, or that a general purpose model makes every downstream use low risk.
• Treating a vendor’s AI compliant statement as proof of classification, conformity, GDPR compliance, security, or suitability for the configured use.
• Using consent or a disclaimer as a cure for incompatible purpose, excessive collection, unfair profiling, poor security, or an inaccessible human route.
• Calling a person human in the loop when that person cannot understand, challenge, override, or stop the output.
• Testing only average cases or English performance while ignoring French terminology, accents, accessibility, edge cases, and affected groups.
• Keeping unlimited prompts and outputs, copying sensitive material into tickets, or forgetting indexes, embeddings, telemetry, and derived profiles.
• Launching an employment system without checking worker information, consultation, accommodation, job relevance, source correction, and discrimination risk.
• Creating an inventory and policy that do not connect to identity, procurement, product release, security response, incident management, and ownership.

Build versus buy

Buy mature commodity capabilities such as identity, access management, asset discovery, training delivery, ticketing, evidence storage, vendor questionnaires, monitoring, and controlled model access. Build or configure the judgment heavy parts: your French and EU legal register, use case taxonomy, risk appetite, approval gate, DPIA workflow, human review design, evaluation thresholds, language tests, escalation rules, and executive reporting. A governance platform can organise evidence, but it cannot decide whether an employment workflow has a significant effect or whether a reviewer can genuinely correct an outcome.

What can we do for you?

Magna Products helps French B2B companies turn scattered AI experiments into controlled, useful operations. We can inventory your AI use cases, map EU AI Act roles and classifications, connect GDPR and CNIL requirements to French employment, consumer, public sector, and industry considerations, design practical DPIA and impact workflows, strengthen vendor requirements, test French language and human oversight, and connect evidence, incidents, and KPIs to the systems your teams already use. Talk with Magna Products to schedule a focused discovery workshop and leave with a prioritised 30, 60, and 90 day implementation backlog.