AI Governance: A Complete Audit and Compliance Guide for French Mid-Market Companies

Executive summary. The progressive entry into force of the European AI Act (2024-2028), combined with the strengthening of French sector frameworks (ACPR, ANSSI, CNIL, HAS, RGS), creates an unprecedented regulatory environment for companies deploying artificial intelligence. This guide offers an in-depth analysis of the obligations in force and to come, a structured audit methodology, and ready-to-use operational templates for DPOs, CISOs, leadership committees and technical teams. AI governance doesn't replace existing compliance setups: it integrates with them, aggregating the requirements of the GDPR, the AI Act, sector frameworks and international standards such as ISO/IEC 42001.

Chapter 1. The European Regulatory Framework: the AI Act

1.1 Origins and structure of the regulation

The European regulation on artificial intelligence, known as the AI Act, came into force on 1 August 2024. It is the first regulatory framework in the world aimed at protecting citizens from the risks linked to AI while fostering a European single market for trustworthy AI. Its core logic rests on a classification of AI systems by their potential risk level to people's safety, health and fundamental rights. This proportionate approach means the regulatory obligations vary in intensity according to the system's perceived dangerousness: unacceptable-risk practices are purely and simply prohibited, while high-risk systems are subject to strict oversight covering documentation, traceability and human oversight.

The structure of the text revolves around four risk categories — unacceptable, high, limited and minimal — to which are added specific obligations for general-purpose AI models (GPAI) such as large language models (LLMs). This tiered architecture targets requirements where they're most needed, without imposing a disproportionate burden on low-impact uses. For French companies, and particularly the mid-market companies that make up the country's main economic fabric, a fine understanding of this classification is the indispensable step before any production deployment.

1.2 Classification of systems by risk level

The AI Act classification is the heart of the framework. Every company must be able to place its AI systems in one of the following four categories, because it's this classification that determines all the applicable obligations.

High risk is the category densest in obligations and the one that directly concerns mid-market companies in regulated sectors. Annex III of the regulation lists the domains concerned: biometrics, critical infrastructure, education, employment, access to essential services, law enforcement, migration and the administration of justice. For the financial sector specifically, two categories of systems are explicitly classified as high-risk by Article 6(2): AI systems intended to assess the creditworthiness of natural persons or establish their credit score, and those used to assess risks and pricing in life and health insurance.

1.3 Updated application timeline (Digital Omnibus)

The application of the AI Act is progressive, but the pace has accelerated considerably since the end of 2024. The Digital Omnibus, a political agreement reached on 7 May 2026 between the European Parliament, the Council of the EU and the European Commission, amended several key deadlines. These adjustments aim to allow the harmonised technical standards to be finalised before the heaviest obligations apply.

The confirmation of these postponements by the Digital Omnibus offers companies apparent breathing room, but must not mask the operational urgency. High-risk systems require 12 to 18 months of preparation to reach full compliance. Companies that wait until the last minute will risk not having the technical and organisational resources needed to meet the deadlines. Moreover, some earlier obligations remain unchanged: prohibited practices have effectively been illegal since February 2025, and financial penalties have applied since August 2025.

1.4 Detailed obligations by risk level

1.4.1 Unacceptable-risk systems (prohibited)

Since 2 February 2025, the following practices are strictly prohibited across the European Union:

• The social scoring of individuals by public authorities or profiling systems assessing individuals based on their online behaviour
• Subliminal cognitive or behavioural manipulation, such as the artificial production of content intended to influence or deceive individuals without their knowledge
• The exploitation of vulnerabilities of people (age, disability, social or economic situation) to alter their behaviour in a harmful way
• Real-time biometric surveillance systems in public spaces, save for very strictly framed exceptions (search for kidnapping victims, prevention of terrorist acts)
• Emotion recognition in professional or educational contexts

Failure to comply with these prohibitions exposes you to maximum penalties of €35 million or 7% of total worldwide annual turnover.

1.4.2 High-risk systems (strict oversight)

High-risk systems, which make up the densest perimeter of the AI Act, must comply with a set of requirements structured around nine pillars before being placed on the market or put into service.

For companies that deploy these systems ("deployers" in the regulation's terminology), additional obligations apply: putting human oversight in place on site, monitoring the system's operation, retaining logs, and notifying serious incidents.

1.4.3 Limited-risk systems (transparency)

Limited-risk systems, which include chatbots and content-generation tools, are subject to one main obligation: clearly informing the user that they're interacting with an AI or that the content they're viewing was generated by an AI. This transparency obligation, provided in Article 50 of the regulation, applies from 2 August 2026. The Digital Omnibus postponed to 2 December 2026 the specific obligations for digital marking (watermarking) of AI-generated content.

The Digital Omnibus also introduced a new prohibition: the ban on AI systems generating non-consensual intimate images and child sexual abuse material, applicable from December 2026.

1.5 Penalties

The AI Act's penalty regime is graduated according to the gravity of the breaches and the risk level of the systems concerned. It aims to ensure consistent application of the regulatory framework and to deter non-compliant behaviour.

Beyond financial penalties, the national surveillance authorities can order the withdrawal from the market of a non-compliant AI system and impose injunctions, including provisional ones, in case of serious and immediate danger. The AI Act also provides for reduced penalties for SMEs and start-ups so as not to hinder innovation, while maintaining a minimum compliance requirement.

Chapter 2. The French Sector Framework: Supervisors and Standards

For French companies, the AI Act is only one layer of the regulatory framework. Regulated sectors — banking, insurance, healthcare, public sector — must align these new requirements with already demanding pre-existing standards: ACPR, ANSSI, CNIL, HAS, HDS, RGS, NIS2, DORA. This stacking of frameworks creates a compliance complexity that requires an integrated approach.

2.1 Financial sector: ACPR, DORA and AMF

2.1.1 The ACPR, market-surveillance authority for the AI Act

The Autorité de Contrôle Prudentiel et de Résolution (ACPR) is expected to be designated market-surveillance authority for the banking and insurance sectors under the AI Act. This mission, expected to be effective since 2 August 2025 (the deadline for designating competent national authorities), gives the ACPR the power to oversee the proper application of the European AI regulation in the French financial sector.

The ACPR has set up an internal task force bringing together all its functions, working on five main axes:

The ACPR intends to carry out these missions in the spirit of reconciling innovation and security that is the regulation's, by adopting a proportionate risk-based approach and using every possible synergy with its usual checks. On 2 April 2025, the ACPR held a working meeting with around twenty institutions (banks, insurers, fintechs) to assess their readiness and co-build its thinking on AI audit.

2.1.2 DORA: digital operational resilience

The Digital Operational Resilience Act (DORA), which came into force on 17 January 2025, is a complementary framework particularly relevant to AI systems deployed in the financial sector. DORA imposes new obligations on financial institutions for managing risks linked to information and communication technologies (ICT). Its four pillars apply directly to AI infrastructure:

DORA strengthens the oversight of risks linked to cloud providers and AI service providers, requiring financial institutions to assess their resilience. The EU sovereign cloud, backed by the EUCS framework, aims to guarantee the security and confidentiality of European data, aligning with DORA's objectives.

2.1.3 High-risk systems in the financial sector

In the financial sector, two categories of AI systems are explicitly classified as high-risk by Article 6(2) of the AI Act:

• Creditworthiness-assessment systems: tools for evaluating the credit of natural persons, excluding financial-fraud-detection systems
• Insurance risk-assessment and pricing systems: tools used to assess risks and set premiums in life and health insurance

These systems will have to comply with all the requirements for high-risk systems (technical documentation, human oversight, traceability, CE marking) from 2 December 2027. The ACPR will be the competent authority to verify their compliance.

2.2 Healthcare sector: HAS, HDS and ANSM

2.2.1 The HAS and medical artificial intelligence

The Haute Autorité de Santé (HAS) has integrated artificial intelligence into its certification framework for healthcare establishments. The 2025 version of the framework introduces three specific AI-related criteria:

These criteria require healthcare establishments to actively govern AI tools, whether they have a medical purpose (diagnosis, clinical decision support) or an organisational one (planning, resource management). The HAS v2 certification, applicable since 2025, also strengthens the criteria on cybersecurity and digitalisation.

2.2.2 HDS: hosting of health data

The HDS (Health Data Hosting) certification is a mandatory framework for any actor hosting or processing personal health data in France. Established by Article L.1111-8 of the Public Health Code, it guarantees that medical information is stored and processed under strict conditions of security, confidentiality and availability. The HDS v2 framework, published in 2025, introduces several notable changes.

For AI systems deployed in the healthcare sector, HDS compliance is an indispensable prerequisite. The data used to train or feed an AI model (via RAG, for example) must be hosted on HDS-certified infrastructure as soon as it contains personal health data. This constraint also applies to the subprocessors and cloud-service providers used by medical AI-solution vendors.

2.3 Public sector: RGS and NIS2

2.3.1 The General Security Framework (RGS)

The RGS is a set of rules laid down by ANSSI that applies to the information systems of French administrative authorities. It defines the security requirements for online services, messaging and authentication in electronic exchanges. The RGS applies mandatorily to State administrations, local authorities, public establishments and their digital providers.

Any administration carrying out electronic exchanges must obtain a security accreditation through a three-step process: identifying threats, analysing risks according to the criticality of the data, and implementing an action plan compliant with the RGS requirements. For AI systems deployed in the public sector, this accreditation must integrate the specific risks linked to AI (algorithmic bias, hallucinations, data leakage via the models).

2.3.2 NIS2: cybersecurity and AI

The NIS2 directive, which must be transposed into French law, strengthens the cybersecurity of companies in the EU by broadening its scope and imposing stricter obligations. In France, between 15,000 and 18,000 companies will be concerned, classified as essential entities (EE) or important entities (EI). The companies concerned will have three years to comply from the publication of the implementing decrees.

ANSSI has defined 20 strategic objectives to frame this transposition. The interaction between NIS2 and AI systems is particularly important: attacks specifically targeting AI (poisoning, evasion, extraction) must be integrated into the cyber-risk analyses of the entities concerned.

2.4 Cybersecurity: ANSSI's 35 recommendations

The Agence nationale de la sécurité des systèmes d'information (ANSSI) published in April 2024 a guide of 35 security recommendations for a generative-AI system. Updated in 2025, this document is the French reference for securing AI architectures. It addresses securing a generative-AI system architecture from the design phase to deployment.

The recommendations are organised around three main categories of attack identified:

Among the 35 recommendations, several are directly applicable to the governance of enterprise RAG systems and chatbots:

ANSSI also published in February 2025 an international report, in partnership with 16 organisations, on building trust in AI through a cyber-risk-based approach. This document underlines that the security of AI systems is never guaranteed and that their use can increase their users' vulnerability to cyberattacks. The agency is also a stakeholder in the Institut national de l'évaluation de la sécurité de l'intelligence artificielle (INESIA), launched in 2025, which develops certification schemes for products and systems integrating AI.

Chapter 3. GDPR and Artificial Intelligence: the CNIL's Recommendations

Applying the GDPR to artificial-intelligence systems is a major challenge of AI governance. The CNIL has published a series of practical sheets detailing the conditions for AI systems' compliance with the European data-protection regulation. These recommendations are part of the AI action plan launched by the CNIL in 2023 and complement the existing compliance rules.

3.1 The pillars of GDPR compliance for AI

The CNIL stresses the need to integrate data protection by design (privacy by design) and by default (privacy by default) into AI systems. The controller must be able to demonstrate compliance at all times with the GDPR principles, which implies rigorous documentation and the mobilisation of the Data Protection Officer (DPO).

The CNIL recalls that these principles apply to all phases of the lifecycle of an AI system: constituting the datasets, training the model, deployment in production, and use by end users.

3.2 Training data: constitution and management

The CNIL's practical sheets insist on documenting the constitution of training datasets. For each dataset, the controller must be able to justify several key elements:

• The provenance of the data (direct collection, open databases, web scraping, purchase)
• The legal basis applicable to each source
• The categories of data included and excluded
• The minimisation measures applied (removal of identifying fields, pseudonymisation)
• The retention period of the training data after the model is completed

The question of retaining training data receives particular attention. The CNIL considers that retention "just in case", with no specific purpose, contravenes the storage-limitation principle. If the data is necessary to retrain or improve the model, its retention may be justified, but this justification must be documented.

3.3 Anonymisation, pseudonymisation and synthetic data

The CNIL considers that anonymisation and pseudonymisation are strong safeguards that don't preclude the use of personal data for AI training, provided these measures are necessary for the processing. In its summary of the contributions on the AI sheets, the CNIL provides several important clarifications:

The CNIL has developed a decision tree to guide actors in determining a model's status under the GDPR. This methodology goes through assessing the likelihood of re-identifying people from the model, by conducting attack tests on the system. If the analysis concludes that the likelihood of re-identification is insignificant, the use of the system may be presumed to fall outside the GDPR's scope.

3.4 The right to be forgotten and vector stores: the major technical challenge

The right to erasure, often called the "right to be forgotten", is enshrined in Article 17 of the GDPR. It allows individuals to request the deletion of their personal data held by an organisation. In 2025, this right was chosen as the theme of the coordinated action of the European Data Protection Board (EDPB), with the participation of 32 European authorities. For the CNIL alone in 2024, the right to erasure represented 37% of the complaints received.

Applying the right to be forgotten to AI systems raises major technical challenges, particularly for RAG (Retrieval-Augmented Generation) architectures that rely on vector stores.

The CNIL launched the partnership project PANAME (Privacy AuditiNg of Ai ModEls) with ANSSI, the iPoP program and PEReN, aiming to develop a software library to assess whether a model processes personal data or not. This tool, expected in the coming months, will offer concrete technical solutions to developers and users of AI models.

3.5 Responsibilities of the value-chain actors

The CNIL announced the publication, in the second half of 2025, of new recommendations to clarify for the actors in the chain of creating an AI system their responsibilities under the GDPR. These recommendations will cover, in particular:

• Clarifying the consequences of applying the GDPR to models that aren't anonymous
• Studying the case of open source, an essential practice for the development of AI technologies
• The technical tools to facilitate the concrete implementation of the recommendations

Chapter 4. Security of Enterprise RAG Systems and Chatbots

Deploying chatbots and RAG (Retrieval-Augmented Generation) systems in the enterprise carries a specific risk: the circumvention of existing access rules. A poorly scoped chatbot can expose the leadership team's salaries to a production operator. A misconfigured RAG can reveal the legal committee's confidential notes to a salesperson. Document-access security cannot be a layer bolted on afterwards: it must be an integral part of the architecture.

4.1 The principle: inheriting existing permissions

Enterprise chatbots and RAGs must build on the authorization systems already in place: Active Directory, IAM (Identity and Access Management), or a business RBAC model. The production operator querying an agent must only retrieve documents they could already access in the existing applications. No AI channel should circumvent the established access rules.

This approach relies on several complementary mechanisms:

4.2 Row-level security and metadata filtering

Row-level security (RLS) is the state of the art for securing enterprise RAG systems. This technique consists of applying permission filters before the vector search, guaranteeing that only authorized documents are taken into account in the similarity calculation.

The process unfolds in three critical phases:

Phase 1: Ingestion and ACL tagging. When documents are ingested into the vector store, each chunk is enriched with security metadata: owner_id, tenant_id, department, access_level, classification (public, internal, confidential, secret). This metadata comes directly from the source document-management system (SharePoint, Google Drive, Confluence) where the ACLs are already defined.

Phase 2: Query-time filtering. When a user submits a query, the system first retrieves their permissions from the Identity Provider (Active Directory, Okta, etc.), then builds a dynamic filter that is applied to the vector search. For example: WHERE department IN ('Finance') AND access_level <= user_access_level.

Phase 3: Post-query validation. Before sending the retrieved chunks to the LLM, the system performs a final validation to ensure no out-of-scope document has been included. This "fail close" step guarantees that if the user context is missing or corrupted, the query is rejected.

4.3 Authorization models for RAG

Several authorization models can be implemented in a RAG system, depending on the complexity of the organisation's needs:

The ReBAC model is particularly well suited to RAG applications because it focuses on the relationships between users and resources rather than on endpoint management. This makes it ideal for post-query filtering, where the system must determine which documents a user can access based on their relationships with the document categories.

4.4 Multi-tenant isolation and vector-store security

In SaaS or multi-department architectures, data isolation between tenants is fundamental. Three isolation patterns are commonly used:

Modern vector databases (Pinecone, Weaviate, Qdrant, pgvector) all support metadata filtering, which efficiently implements tenant-filter isolation. The security recommendation is to apply the tenant filters before the similarity search, not after, to avoid other tenants' embeddings being loaded into memory and leaking via prompt manipulations.

4.5 Defences against attacks on RAG systems

RAG systems are exposed to specific attacks that can circumvent access controls or extract sensitive information:

The concept of RAG 2.0 is emerging to address these challenges by introducing a security-centred control flow: session-based policy evaluation, metadata filtering before injection into the prompt, permission branching mid-flow, and explainable provenance tracking.

Chapter 5. Organisational Governance of AI

5.1 The AI steering committee: a cross-cutting decision-making body

The first reflex of companies is often to entrust AI governance to IT or the Chief Data Officer. That's a mistake. The AI steering committee must be a cross-cutting decision-making body, co-chaired by a member of the executive committee and the data/AI lead. Its typical composition includes: the CEO or deputy CEO, the CIO, the main business director, the HR director (for the employment impact), the CISO (for data security), and an ethics lead.

The effectiveness of an AI governance committee rests on the diversity of the expertise represented. An exclusively technical or legal view would be insufficient to grasp the multidimensional nature of AI challenges.

The frequency of meetings depends on the number of AI systems deployed: quarterly for two or three systems, monthly beyond five. The committee's role is to validate new deployments, arbitrate changes, and review incidents. Once at least two AI systems are deployed in production, a dedicated steering committee becomes indispensable.

5.2 A three-tier organisational architecture

Effective AI governance is organised into three levels of intervention, from the strategic to the operational:

Strategic level, AI governance committee. Chaired by a member of the executive committee (CEO or COO), this body defines the organisation's AI vision, strategy and investment priorities. It ensures alignment between AI initiatives and business objectives, arbitrates conflicting priorities and validates major investments. Its missions include: defining the corporate AI strategy, validating investments beyond a defined threshold, approving governance policies, and overseeing major AI risks.

Operational level, AI steering committee. Led by the Chief Data Officer or Chief AI Officer, this committee translates the strategy into concrete action plans and steers the execution of the initiatives. It ensures coordination between projects, resource allocation and performance monitoring. Its responsibilities cover: prioritising projects by strategic criteria, allocating technical and budgetary resources, monitoring performance and ROI, and escalating issues to the strategic committee.

Technical level, AI Center of Excellence. This structure centralises the technical and methodological expertise, develops the standards and best practices, and supports the business in their projects. It typically comprises: a data-science and ML-engineering team, AI ethics and explainability experts, data-governance specialists, and internal consultants to support the business.

5.3 The five pillars of AI governance in a mid-market company

Experience with dozens of mid-market companies makes it possible to formalise the fundamentals of AI governance that works:

5.4 ISO/IEC 42001: the international AI-governance standard

ISO/IEC 42001:2023 is the first certifiable international standard dedicated to artificial-intelligence management systems (AIMS). Published in December 2023, it's quickly becoming the reference standard for governing AI responsibly. In December 2025, more than 2,400 organisations were certified worldwide, with growth of +350% compared with 2024.

One of ISO 42001's major strengths is its strong convergence with the AI Act's requirements. The standard already covers 80 to 85% of the European regulation's obligations, which makes it a particularly effective operational foundation for reaching compliance.

Only a few areas remain specific to the AI Act and aren't covered by ISO 42001: registration in the European database, evaluations by notified bodies for certain products, CE marking, and the EU declaration of conformity. These elements represent between 15 and 20% of the AI Act's requirements and must be handled in addition to ISO 42001 certification.

Chapter 6. AI Audit Methodology and Compliance Deliverables

6.1 Phases of the AI governance audit

A structured AI governance audit unfolds in five successive phases, with a total duration of two to three weeks for an existing system:

The cost of an initial audit for an AI system in production with no compliance documentation ranges from €12,000 to €25,000 depending on complexity. The compliance work itself ranges from €15,000 for a simple documentation clean-up to €80,000 if the access architecture needs to be redesigned. On the French market in 2026, the day rates of specialised consultants range from €600 to €3,000 per day depending on the level of expertise.

6.2 AI governance maturity-assessment grid

The following grid assesses an organisation's AI governance maturity on a scale of 1 (initial) to 5 (optimised):

6.3 The eight production deliverables

Every production rollout of an AI system must produce eight documents that make up the compliance file:

6.4 AI Act compliance checklist by risk level

Checklist, Limited-risk systems (chatbots, content generation)

Checklist, High-risk systems (recruitment, scoring, diagnosis)

Chapter 7. Regulatory Integration: Aligning the AI Act, GDPR and Sector Frameworks

7.1 Framework-alignment matrix

Companies in regulated sectors must navigate a complex ecosystem of partly overlapping frameworks. The following matrix summarises the main alignments:

7.2 An integrated approach to compliance

The approach recommended for mid-market companies is to not treat each framework in isolation, but to build an AI governance setup that aggregates the common requirements and identifies the sector specifics. AI governance builds on the existing data governance: the data catalog references the datasets used by the AI systems, the classification policies determine which documents an AI system can ingest, and the existing access-validation processes extend to the new AI channels.

7.3 Mapping the supervisory actors in France

Chapter 8. Operational Templates

8.1 Template, AI-systems registry (AI Act–compliant)

8.2 Template, Technical sheet for a high-risk AI system

8.3 Template, AI-incident response plan

Conclusion, The 10 commandments of AI governance for mid-market companies

Faced with the complexity of the regulatory and technical landscape, here are the ten guiding principles we recommend to any mid-market company deploying or considering deploying artificial-intelligence systems:

Compliance isn't a destination but a continuous process. Companies that invest now in structured AI governance — with operational committees, up-to-date registries, robust access controls and complete documentation — will turn this regulatory constraint into a competitive advantage. ISO 42001 certification, demonstrated risk mastery and the ability to respond effectively to audits will become differentiators in a market where trust in AI keeps eroding.

Document written in May 2026. The regulatory dates cited incorporate the changes made by the Digital Omnibus (political agreement of 7 May 2026). This guide does not constitute legal advice and must be supplemented by a case-by-case analysis of each organisation's situation.