AI is already in production across French finance

When Denis Beau, first deputy governor of the Banque de France, spoke about AI on September 9, 2026, he started from a point most compliance officers in Paris will recognize from their own institutions. An ACPR survey in 2025 found that almost all banks and insurers have AI use cases in production. Production, not pilots.

That moves the supervisory conversation on. Supervisors now take AI use for granted and want to see how it is controlled. Beau's speech and three other documents published this summer describe what that proof will look like. We read them as a company that builds compliance software for regulated French institutions, and this piece is our attempt to turn them into things a team can actually build over the next year.

December 2027: the ACPR takes on high-risk AI

From December 2027, Beau said, the ACPR will supervise high-risk AI systems in finance, with credit granting and insurance pricing as the obvious examples. The date matches the EU AI Act as amended by the Digital Omnibus, under which Annex III high-risk obligations, including creditworthiness assessment, start on December 2, 2027.

None of this should surprise anyone who follows the ACPR. Its 2026 work program, published on January 19, lists preparing for AI supervision among its five priorities, alongside DORA implementation, according to a summary from Deloitte Société d'Avocats.

Thirteen months is less time than it sounds. A credit-scoring or pricing model that goes live in 2027 is being designed, trained and validated over the coming quarters. If the documentation standard is only settled in late 2027, those models will be documented retroactively. Retroactive evidence is expensive to produce and rarely convincing, and an experienced inspector can usually tell which files were written after the fact.

Algorithmic fairness: why removing sensitive variables no longer works

The most technically interesting text of the summer is the ACPR's discussion paper on algorithmic fairness (a document de réflexion on équité), which was open for public consultation from July 1 to September 30, 2026. Its central argument is that "fairness through ignorance", the practice of removing sensitive variables from a model's inputs, is largely outdated, because models can reconstruct that information from the variables that remain.

Anyone who has built a credit model knows why. Postcode, employment sector, spending categories, even the device used to apply can correlate with protected characteristics. Drop the sensitive column and a gradient-boosted model will find a proxy within a few splits. The bias is still there. It has simply left the feature list, where a reviewer would have seen it.

For risk and compliance teams, the consequence is that the control has to move from the inputs to the outcomes:

  • Measure outcomes across groups (approval rates, prices, error rates) on a schedule. That requires a lawful way to hold or estimate sensitive attributes for testing, which is a GDPR question to settle with your DPO early.
  • Test for proxies explicitly by asking how well the sensitive attribute can be predicted from the model's inputs.
  • Record which fairness metric you chose and why. There are several, they can conflict with each other, and a supervisor will want your reasoning as much as the result.
  • Re-run the tests when the model, the training data or the customer base changes, not only at initial validation.

The consultation has closed. Whatever the final text says, the direction is clear enough to start building the testing capability now.

Frontier AI, cyber risk and DORA

The second theme is operational resilience. Beau described DORA as a strong framework that is nonetheless "probably not sufficient" for the most advanced models. On July 31 the three European supervisory authorities, the EBA, EIOPA and ESMA, issued a joint statement calling for a "cross-sectoral, risk-based and consistent supervisory approach" to the ICT risks of frontier AI models, and updating DORA's oversight of critical ICT third-party providers to cover that risk.

Two practical consequences follow for French institutions.

First, if an AI feature calls a model provider's API, that provider is an ICT third party. The register of information, exit strategy and concentration analysis apply to it like any other supplier. It is easy to register the cloud provider and forget the model API sitting behind an internal assistant.

Second, frontier models change underneath you. A provider can ship a new model version, and controls validated on the previous version no longer describe what is running. Pin model versions where the provider allows it, and treat a version change as a change event with its own tests and sign-off.

Client data belongs in the same discussion. When prompts contain customer information, the model provider ends up holding a copy of it. For Logikol we built a privacy vault that tokenizes personal data before it leaves the customer's system, so the provider sees tokens instead of names and account numbers. That reduces both the GDPR exposure and the damage if a third party has an incident.

Turning supervisory expectations into controls and evidence

Supervisors do not inspect intentions. They inspect files. Our view, from building Azia for regulated French institutions, is that AI governance should live inside the existing compliance program instead of a separate spreadsheet owned by the data science team.

Azia is a multi-tenant platform that runs a firm's compliance program from the yearly plan de contrôle to regulator-ready reports. It has a control-plan execution engine, a risk-mapping module covering all the AMF-required categories, an automated recommendation engine and a reporting engine that produces branded PDFs without leaving the tool. That structure accommodates AI risk without much stretching. Each AI system becomes an entry in the cartographie des risques. Each fairness test or model-version review becomes a scheduled control with an owner and a deadline. Findings flow into the same reports the compliance function already sends.

Evidence is the heavier part of the work. A fairness test produces outputs, a model validation produces a report, a DORA third-party review produces contracts and assessments. For SecureLabs we built AI assistants that evaluate uploaded evidence (PDFs, Word documents, images) against specific controls. Using AI to review AI evidence sounds circular, but the assistant does not decide whether the firm is compliant. It spares a reviewer from reading a long validation report only to discover that the one table they needed is missing, and a person still signs off.

A 12-month roadmap for compliance teams

Here is how we would sequence the work between now and December 2027.

Q4 2026: inventory. List every AI system with its owner, purpose, model provider and version, and whether it falls under Annex III. Add model APIs to the DORA register of information.

Q1 2027: classify and prioritize. Credit and insurance-pricing models go first. For each one, write down the fairness metrics you will use and how you will lawfully obtain the data to compute them.

Q2 2027: first testing cycle. Run outcome testing and proxy analysis on the priority models. Expect findings, and document the remediation.

Q3 2027: make it routine. Write the AI controls into the next plan de contrôle with owners and deadlines. Rehearse a supervisory request: could you assemble the complete file for one model within a week?

Q4 2027: close the gaps before December 2, and move from project mode to recurring controls.

None of this depends on final texts. The ACPR, the three ESAs and the AI Act point in the same direction, and an institution that starts this quarter will have a year of evidence on file when the first questions arrive. If you are scoping the tooling for this, we would be glad to compare notes.

Sources