Panel: The Future of Market Data Infrastructure
Industry experts debate the evolution of market data ecosystems. Topics include cloud-native architectures, AI-driven insights, next-generation data distribution models, and the democratization of market data access.
Moderator & Panelists
Summary
Panel Discussion: AI, Market Data & the Future of Investment
Moderator: Fayssal El Mofatiche, Founder & CEO, Finteda / Flowistic Date: March 12, 2026 Event: Paris — Market Data x AI (Finteda / FactSet)
Panelists
- Caio Natividade — Head of Quantitative Investment Solutions Research, Deutsche Bank - Francois Arnaud — Lead of AI Innovation & Transformation, Amundi - Jan Decken — Director, Head of App Dev Sales EMEA & APAC, FactSet - Boris Toledano — COO & Co-Founder, Linkup — web indexing and search platform rebuilt for LLMs and agents - Eric Benhamou — Head of Machine Learning, Ai For Alpha — FinTech using AI to decode public information and track institutional/CTA flows
Topic 1: Where Does AI Actually Deliver Value in Investment?
Eric (Ai For Alpha)
There's a paradox: everyone has high expectations for AI, but in the investment community — asset managers, hedge funds, investment banks — it's mainly good for automation, data search, working with tables, databases, and code. In investment research specifically, it's still far from delivering.
Key challenge: AI is non-deterministic, which is problematic for finance. It opens doors but is also overwhelming — there's so much to explore. Machine learning wants lots of data, but too much data introduces noise. You don't want selection bias either.
Ai For Alpha specialized in "decoding" — using AI to track what financial institutions and CTAs are doing (flows, positions) rather than trying to predict prices. This works well. Prediction remains a major challenge: the signal-to-noise ratio in finance is low. Progress is encouraging but the battle is ongoing.
Topic 2: AI Adoption in a Large Institution — Deutsche Bank
Caio (Deutsche Bank)
Deutsche Bank is "an elephant, not a cheetah." Adopting external AI solutions requires convincing technology departments, compliance, legal, and corporate management that it won't put the bank at risk. Decision-makers think in terms of tail risks — not probability but magnitude of potential losses.
Onboarding timeline: 5-6 months of due diligence (employee count, client base, revenue, model vintages) — in a world where 5-6 months is an eternity.
Current usage: Mostly efficiency gains — addressing large research questions via chatbots, and more recently, coding assistance.
Critical insight: To reach the stage where most R&D processes can be automated, the infrastructure groundwork needed to start 6 years ago. What was presented (the Research SDK, DataStore, etc.) was a 6-year journey from scattered spreadsheets and CSVs to a unified platform.
Topic 3: AI Use Cases at Scale — Amundi's 300+ Use Cases
Francois (Amundi)
Amundi followed a similar 5-year journey to build a unified data platform (security, logging, Chinese walls, data domains). Once you have clean, urbanized data, you can build bottom-up with building blocks, rather than top-down directives with "skyrocketing ROI" promises. This enables a citizen developer approach — serverless technologies on top of the data layer let everyone experiment in a secure environment.
Why so many use cases? More people know how to code now, especially in buy-side.
Key blockers for scaling AI:
1. Security and governance — Chinese walls, access controls 2. Organization and adoption — People testing AI know they may be automating their own jobs. Need to ensure unbiased testing and reassure employees about reallocation. 3. Cost estimation — Nobody can predict the cost of a deep research query: how many loops, tokens, hours. "You've spent the entire database, all the compute, and it cost $5 and 3 hours of waiting." This reshapes how we think about testing and funding.
Topic 4: How Must Data Products Evolve for AI and Agents?
Jan (FactSet)
Some things don't change: data quality and durability remain paramount regardless of whether an agent or a human consumes the data. FactSet has 10,000+ employees, two-thirds working on data collection — a massive area for AI-driven efficiency gains.
What must change:
1. Machine-readable first — Data models built before GenAI need rearchitecting for latency, scalability, and machine comprehension. Data must be correct at the backend; you can't fix it at the frontend. 2. Metadata becomes critical — For humans, showing a value was sufficient. Models always need metadata to reason correctly. 3. Auditability and traceability — The ability to trace any output back to its original source. This is the prerequisite for trust, which is itself the prerequisite for autonomous agent workflows.
On licensing and entitlements (Jan, Topic 5)
The industry is shifting from per-seat (human at a terminal) to consumption-based models. Agent-level entitlements (which agent, for which application, sees which data at which granularity) don't fully exist yet but are being built. Trust — getting clients to the point where they are genuinely willing to delegate a workflow to an agent without manual intervention — is the friction point that cannot easily be solved by design.
Topic 5: Alternative Data, On-Demand Collection, and Trust
Boris (Linkup)
Linkup is a web indexing and search platform rebuilt from scratch for LLMs and agents, because legacy search engines weren't designed for this purpose. They serve as a complement to give agents flexible access to web content.
Key challenge: Trust, on multiple levels:
1. Stabilizing non-deterministic LLM behavior — Boris echoed Eric's point that stochastic LLM outputs are painful for everyone and a key thing clients try to solve. 2. Infrastructure guarantees — latency, SLAs, guarantees that client data is not used for model training and that nothing is stored. This is especially important for banks and the financial industry.
Topic 6: Economics of Productionizing AI (POC to Production)
Francois (Amundi)
With ~300 use cases (50-80 in testing/POC, ~25 in production), Amundi's strategy reflects four known approaches: Moonshot, ROI-driven, Product Enrichment, and Divide and Conquer.
Product enrichment: Amundi builds most of its enterprise tools in-house. AI modules can be detached and exported via token exchange / MCP to enrich products directly.
The "divide and conquer" example (prospectuses): The POC — indexing and summarizing contract prospectuses — was a success within days. But the data lifecycle is complex: 35,000 prospectuses across multiple languages and jurisdictions, with master agreements, sub-documents, amendments, and annexes that must be coordinated (with information barriers managed across the lifecycle). This makes full productionization slow.
Once the first building block reaches near-zero error rate, it becomes a commodity that triggers many downstream use cases (legal, compliance, risk, portfolio managers) at negligible marginal cost. This is the medallion approach — modernize data and expose it correctly, then build on top.
The semantic layer (as discussed with dbt) is crucial for coordinating KPI definitions and managing this data lifecycle.
Topic 7: Forward-Looking Bias and Continuous Data Onboarding
Caio (Deutsche Bank)
Two dimensions:
1. Existing datasets: Primarily a question of whether data is point-in-time. Non-point-in-time data is irrelevant for backtesting. 2. Model risk with LLMs: This area is still opaque. Deutsche Bank hasn't built LLM-based trading signals yet. If they did, the approach would be: only assume data from after the model's live date (e.g., after GPT-4 went into production).
Key Takeaways
- Infrastructure first, AI second — The teams winning are those who invested 5-6 years in clean, unified data platforms - Non-determinism is the core friction — Finance requires deterministic outputs; stochastic LLM behavior is the biggest adoption barrier - Machine-readable data by default — Not as an afterthought; metadata, lineage, and auditability are non-negotiable - Cost unpredictability — Token costs for agentic workflows are hard to estimate and reshape how firms think about testing and budgeting - Licensing must evolve — Per-seat models don't work for agents; consumption-based entitlements at the agent level are being built - Trust is the bottleneck — Technical capabilities exist; the gap is organizational trust to let agents run autonomously
Review Notes (Changes Made)
The following issues were corrected from the original summary:
Fabricated content removed: - Eric section: The Jane Street / reinforcement learning anecdote, the "markets only happened once" / Go vs chess analogy, and the specific framing around "high-frequency trading and order book execution" as where deep learning "clearly works" — none of this appears in the transcript. Eric only mentioned the signal-to-noise challenge and that prediction is difficult. - Boris section: The pension fund / Reddit / Glassdoor example is not in the transcript. The "monitoring 5,000 companies instead of 50" figure is not in the transcript. The "post-retrieval processing" bullet is not in the transcript. Boris's trust discussion in the transcript covers only two points: stochastic LLM behavior and infrastructure guarantees (latency, SLAs, data not used for training).
Factual errors corrected: - Caio's description of the model risk area: the original summary described it as "masonic (opaque)" — the transcript says "assez opaque" (quite opaque). "Masonic" is not Caio's word and introduces a misleading connotation. - The GPT-4 example Caio gives for model live dates was missing from the original summary's Topic 5 section.
Structural issues corrected: - In the original summary, Caio's remarks (elephant/cheetah, compliance hurdles, onboarding timeline) were folded into Topic 1 alongside Eric. In the transcript they are a distinct Topic 2. The structure has been corrected to match the transcript. - The four strategies (Moonshot, ROI-driven, Product Enrichment, Divide and Conquer) were placed in Topic 2 (Amundi use cases) in the original summary. In the transcript they appear in the economics/POC-to-production section. Corrected accordingly. - Jan's licensing/entitlement discussion was a separate topic in the transcript (Topic 5: Friction Points). The summary merged it into Topic 4 without acknowledgment. This has been restructured to reflect the actual flow.
Full Transcript
Event: Paris — Market Data x AI (Finteda / FactSet) Date: March 12, 2026
Moderator: Fayssal El Mofatiche — Founder & CEO, Finteda / Flowistic
Panelists: Caio Natividade — Core Developer, QIS Research, Deutsche Bank Francois — AI Innovation Office, Amundi Jan Decken — Sales (France), FactSet Boris — Co-founder & COO, Linkup Eric — Co-founder, Ai For Alpha
============================================================
--- OPENING / INTRODUCTIONS ---
Caio: I suppose in order to keep the audience lively, I would like to mention an anecdote, which is that today I was ordering coffee. I was in a queue to order coffee at a very nice café nearby in the Passage. And there were five people in the queue, and each one of those five people was trying to practice their French. And the barista who was taking the orders — she would take none of that. So the first person comes in, "Bonjour, je voudrais un café." And she was like, "OK, what kind of coffee do you want?" And the person tried to continue in French. And I'm like — no, she took no shit. Then the second person spoke a bit better, a bit of an Eastern European accent — no, no. And the third person was actually French-Canadian. Bonsoir.
Fayssal: Oui, on peut aller à François.
Francois: Bonjour à tous. Je m'appelle François. Je représente Amundi et l'AI Innovation Office d'Amundi. Pas d'ingénieur, pas même de background mathématique, rien d'autre. Je vais me concentrer sur les choses fonctionnelles aujourd'hui et peut-être on verra ça plus tard.
Fayssal: Jan?
Jan: Bonjour à tous, je m'appelle Jan Decken, je travaille pour FactSet, Sales en France. J'aide les clients à construire des applications basées sur nos données et nos API, et je fais beaucoup de conversations MCP ces jours-ci.
Fayssal: Merci.
Boris: Je suis Boris, je suis le co-fondateur et COO de Linkup. Pour ceux qui ne connaissent pas, c'est une plateforme d'indexation web — une machine de recherche, appelez-la comme vous voulez. Notre travail est basiquement d'indexer l'ensemble du web. Nous parcourons le web dans une grande base de données pour le rendre accessible aux LLMs et aux agents. Nous avons réalisé que les anciens moteurs de recherche n'étaient pas faits pour ça, alors nous avons décidé de le refaire proprement — conçu comme un complément en ligne pour donner un accès plus flexible au contenu sur le web.
Fayssal: Merci. Dernier, Eric.
Eric: Bonjour à tous, bonsoir. Je m'appelle Eric, je suis l'un des fondateurs d'Ai For Alpha. Ai For Alpha est une FinTech qui essaie d'aider nos clients dans la décision d'investissement. En particulier, nous utilisons l'IA pour décoder, à partir d'information publique, ce que font les acteurs financiers institutionnels — les CTAs — et pour fournir de l'information sur les flux.
--- TOPIC 1: WHERE DOES AI ACTUALLY DELIVER VALUE IN INVESTMENT? ---
Fayssal: On a eu notre prep call et Eric était l'une des voix qui s'est prononcée pour explorer un peu plus profondément, au-delà du hype — ou de l'overhype, on peut même l'appeler. Qu'est-ce qui fonctionne et comment cela s'applique aux équipes d'investissement, dans le front office, qui essaient d'obtenir un avantage, d'extraire de la valeur de tout ça? Et il a une opinion très forte à ce sujet, et je pense que ce n'est pas seulement lui.
Mais la première question est peut-être: commençons par les bonnes choses. Où voyez-vous ce genre d'intelligence — l'intelligence artificielle au sens large, avec le deep learning, le reinforcement learning — vraiment délivrer de la valeur? Comment pensez-vous à l'augmentation de la valeur de l'IA en termes de machine learning?
Eric: Alors, pendant la préparation, j'expliquais qu'il y avait une sorte de paradoxe. Je pense que tout le monde a de très hautes attentes vis-à-vis de l'IA. Et pourtant, si vous allez dans la communauté d'investissement — que ce soient les asset managers, les hedge funds ou les banques d'investissement — c'est surtout très bon pour l'automatisation. C'est très utile pour aider les gens à chercher des données, travailler avec des tableaux, des bases de données, du code. Mais je dirais que dans l'espace de la recherche d'investissement, on est encore loin.
Je pense que l'un des défis, et je suis sûr qu'on va en parler au cours du panel, c'est que c'est un peu non-déterministe, ce qui est assez problématique. Ça ouvre des portes, mais en même temps c'est si vaste que c'est un peu déroutant. Il y a tellement de choses à explorer.
L'un des défis du machine learning, c'est que vous voulez avoir beaucoup de données, mais en même temps, trop de données tue les données — vous introduisez du bruit. Mais vous ne voulez pas non plus avoir un biais de sélection. C'est assez délicat.
Et c'est pourquoi, parce qu'on a beaucoup essayé, je pense qu'on s'est spécialisé dans des choses plus basiques, comme ce qu'on appelle le "decoding," et on a trouvé que ça marchait très bien. Mais quand il s'agit de prédiction, c'est un des grands défis. On sait que c'est le futur, donc tout le monde veut y être. Mais on a encore des difficultés, parce qu'en finance, le ratio signal/bruit est faible. C'est un défi, mais c'est tout de même très encourageant. J'ai hâte de voir l'avenir, mais en ce moment, c'est encore la bataille, pour être honnête.
--- TOPIC 2: AI ADOPTION IN A LARGE INSTITUTION — DEUTSCHE BANK ---
Fayssal: Merci. Peut-être juste sur cette même ligne — nous avons aussi Caio qui a présenté comment intégrer l'IA à un niveau infrastructurel, pas seulement au niveau recherche, mais aussi au niveau infrastructure, pour étendre et moderniser leur processus d'investissement. Tout d'abord, est-ce que vous confirmez ce qu'Eric a vécu d'un point de vue recherche? Et comment voyez-vous l'IA aujourd'hui affecter les choses?
Caio: Il y a une différence importante pour une organisation comme la nôtre, par rapport aux autres présentateurs. C'est que nous sommes un peu comme un éléphant, pas un guépard. Et en étant un éléphant, vous avez les avantages et les désavantages de cette échelle.
Pour nous, l'un des défis clés pour adopter des solutions IA externes, c'est de convaincre nos départements technologie — au pluriel — ainsi que nos départements compliance, juridique, notre management, que c'est quelque chose qui ne va pas mettre la banque à risque.
And you're often dealing with agents — human agents — who are basically non-economical, so to speak. You can't just present a business plan to them. They're not looking at the monetization angle. They're looking at high-sigma tail risks. Not the probability of these risks occurring, but the magnitude of what the bank stands to lose if they do occur. That's basically all they think about. So when you show them ideas, that's what you have to primarily consider.
And for that, we prepare — we look at the different vendors. We have to do our own due diligence, and it's significant due diligence in terms of how many employees the AI firm has, how many clients they have, what kind of revenue they have, the different model vintages, and so on. These are all very important matters, and to onboard something, it has to pass that — and often it takes 5-6 months for adoption to take place. In a world where 5-6 months is a lot of time.
La deuxième question, c'est comment utiliser l'IA? En ce moment, beaucoup de choses concernent les gains d'efficacité — s'adresser à de grandes questions de recherche en demandant aux chatbots comment ils aborderaient le même problème, et plus récemment, le code.
Un dernier point que j'aimerais faire: pour arriver finalement à un stade où nous pouvons automatiser la plupart des systèmes, la plupart du processus R&D et du workflow — nous devions commencer ce travail d'infrastructure il y a 6 ans. Ce qu'on a présenté, c'est un voyage de 6 ans. Ça a commencé avec des spreadsheets, des fichiers CSV, des données dispersées partout, et tous ces sites archéologiques de données que nous avions décidé de rassembler et de structurer.
--- TOPIC 3: AI USE CASES AT SCALE — AMUNDI'S 300+ USE CASES ---
Fayssal: Vous avez mentionné la difficulté qu'il faut résoudre afin d'embarquer des cas d'utilisation, de les faire fonctionner, d'obtenir les bonnes briques en termes de technologie, d'accès, d'infrastructure. And this is just some of the issues that big companies have to deal with.
And I think Francois has exactly this unique perspective, because he is overseeing the whole AI use cases at Amundi — and it's more than 300 such use cases. So I think he is very well placed to tell us how he sees use cases developing at this aggregated level, and what he sees from practice: what makes some use cases succeed and some use cases really stall and don't progress.
Francois: There are different layers in your question and I would like to follow up exactly on the same story. On a fait la même démarche depuis environ 5 ans. Je pense qu'on a atteint à peu près la même cible — et je parle ici aussi du talk de Databricks, mais aussi des autres. Une fois que vous avez de la donnée propre, unifiée dans une plateforme unifiée — sécurité, logging, Chinese walls, data domains, exposition — you have urbanized all the commodity and then you start thinking of building blocks, bottom-up, as opposed to top-down directives with skyrocketing ROI promises. And then you can start democratizing the innovation.
So I'm going to start from there — j'ai complètement rejoint tout ce qu'il a dit. Ça me rappelle beaucoup les difficultés du passé et mes ambitions aussi. Donc, une fois que vous avez cet asset et que vous commencez à l'exposer, à l'utiliser — nous avons parlé des data products plus tôt, et de tous les principes. Vous commencez à penser d'abord aux produits de données. L'utilisateur final est en fait celui que vous voulez embarquer. Donc, l'adoption, l'engagement — la logique est inversée, parce que vous avez déporté la complexité vers l'utilisateur final, et vous pouvez avoir ce qu'on appelle l'approche "citizen developer."
La deuxième couche, c'est toutes les technologies et les plateformes serverless que vous pouvez construire sur la couche de données. Elles peuvent clairement ouvrir tous les accès, pour que tout le monde puisse commencer à expérimenter dans un environnement sécurisé, en mélangeant les différents datasets.
Pourquoi avons-nous autant de use cases? Le point, c'est que de plus en plus de gens savent coder — ce qui n'était pas le cas il y a longtemps, en particulier dans le buy-side.
Quels sont les freins pour passer à l'échelle? Il y a quatre éléments:
Le premier, c'est la sécurité et la gouvernance — les Chinese walls, les contrôles d'accès.
Le deuxième, c'est l'organisation en termes d'adoption. L'alignement entre les personnes qui vont tester et le fait qu'elles savent très bien, après quelques jours, qu'elles sont la communauté qui sera automatisée dans quelques mois. Donc nous devons penser à une manière complètement différente de tester les choses pour s'assurer que les gens ne sont pas biaisés par le fait qu'ils vont potentiellement perdre leur travail. Et nous devons les rassurer — avec un strong ownership, ils seront sécurisés et nous allons réallouer les ressources vers d'autres activités.
Troisièmement, les coûts — et je pense que c'est l'un des points clés de ce soir — comment mesurer les coûts en termes de construction, d'industrialisation du use case, et aussi en termes de tokens. Personne ne peut estimer la durée d'une deep research query. Combien de boucles? Combien de tokens? Combien d'heures? "Oui mais vous avez dépensé toute la base, tout le compute, et ça a coûté 5 dollars et 3 heures d'attente." C'est ce genre de cas qui reshape complètement la façon dont nous pensons aux tests. Et au financement aussi.
--- TOPIC 4: HOW MUST DATA PRODUCTS EVOLVE FOR AI AND AGENTS? ---
Fayssal: Peut-être Jan, parce que c'est l'autre aspect que Caio a mentionné. Si les processus d'investissement s'adaptent et que la façon dont nous utilisons l'IA transforme nos opérations, notre réflexion, notre distribution — nous savons qu'en finance, tout ce qui est produit est une dérivation de données. Il y a une dépendance directe sur le produit de données, l'infrastructure de données et la donnée elle-même.
And we heard quite a few things about the importance of not only the data, but the metadata. How do you think, as a data provider like FactSet, a good data product is going to have to transform in order to keep up with the expectations of people using this with AI and agents?
Jan: Je pense que beaucoup des choses qui changent ont déjà été mentionnées dans les présentations précédentes. Certains aspects ne changent pas: la qualité des données, la fiabilité restent exactement les mêmes — peu importe que ce soit un agent ou une personne qui consomme les données.
FactSet possède plus de 10 000 employés et deux tiers d'entre eux travaillent dans la collecte de données. Si on regarde cette partie, vous pouvez voir les gains potentiels d'efficacité si nous automatisons encore plus — potentiellement augmenter la qualité ou ajouter des données supplémentaires à notre offre.
L'autre angle, celui du client: nos modèles de données ont tous été construits bien avant GenAI. Donc vous pouvez imaginer l'énorme effort nécessaire sous le capot — pour la latence des données, la scalabilité, la compréhension machine. On a vu cet exemple où il y a un site web conçu pour un utilisateur humain, et puis une copie carbone en description pour un agent afin qu'il puisse faire le même travail.
Cette partie, c'est de repenser les données pour qu'elles soient machine-readable first, par défaut — et ne pas les construire d'abord pour l'affichage dans un terminal, parce que c'est de là que vient notre industrie. Et cela a un impact sur la latence. On ne peut pas corriger les choses en front-end — ça doit être correct en back-end, sinon c'est faux dans l'API et dans tout autre système downstream.
Le metadata est devenu plus important. Pour un humain, montrer la valeur suffisait. Le modèle aura toujours besoin de metadata. Ce n'est pas de la science fusée, mais il faut le faire.
Et le troisième point, qui était aussi un sujet à travers toutes les présentations: l'auditabilité et la traçabilité. Que vaut un résultat si vous ne pouvez pas faire confiance à l'agent? Donc pour notre industrie, il faut pouvoir remonter à la source originale pour tout ce que nous fournissons aux clients.
--- TOPIC 5: FRICTION POINTS FOR USING MARKET DATA WITH AI AGENTS ---
Fayssal: Selon ce que vous voyez en parlant à des clients qui demandent vos données, quelle est la plus grande friction actuellement pour utiliser des données de marché avec des agents IA? Est-ce l'accès? Le metadata? La confiance? Les interfaces? Le licensing?
Jan: Le licensing — oui. Commercialement, c'est un sujet que nous et tout le monde dans notre industrie connaissons. Nous sommes habitués aux modèles par siège, parce que nous avons habituellement des humains assis devant une sorte de terminal. Et ça, évidemment, va être remplacé — ou du moins en grande partie — par un modèle agentique où il n'y a pas d'humain, mais il faut toujours établir des droits d'accès au niveau agent et s'assurer que seul cet agent, pour cette application, est autorisé à voir ces données à cette granularité.
La réalité, c'est que ces choses n'existent pas encore complètement, mais nous les construisons en ce moment. Le sujet de l'entitlement et du traçage de ce que l'agent a utilisé et quand — ces choses n'ont pas d'importance si l'utilisateur regarde la workstation, mais elles en ont beaucoup si vous voulez déléguer le workflow à un agent et, à un moment donné, le laisser fonctionner de manière autonome en étant sûr que l'output est correct.
Évidemment, il y a un impact commercial pour nous aussi, puisque nous avons des modèles basés sur des données à accès restreint. Nous devons changer vers une base de consommation — c'est principalement le modèle que tout le monde adopte.
En termes d'accès et de traçabilité, on peut les résoudre techniquement. Ce qu'on ne peut pas résoudre facilement par le design, c'est le thème de la confiance — arriver à un point où le client est vraiment prêt à confier ça à un agent et n'a plus besoin d'intervention manuelle. Parce que c'est le prérequis pour les gains d'efficacité que nos clients veulent.
--- TOPIC 6: ALTERNATIVE DATA, ON-DEMAND COLLECTION, AND TRUST ---
Fayssal: À ce point exactement, peut-être qu'on peut aller directement à Boris, parce que c'est encore un peu plus fort comme sujet. Nous savons qu'il y a déjà ces données traditionnelles — elles existent depuis des décennies. Mais maintenant, vous offrez quelque chose qui est à la volée — vous allez chercher des données à l'extérieur.
So when access and retrieval becomes democratic and on the press of a button — on the sending of a query — what happens to controls of quality and trust? A pension fund, for example, needs to care about that but doesn't necessarily have the expertise. How do you deal with that?
Boris: Le problème clé ici, c'est la confiance, bien sûr. Et ça peut être à différents niveaux. Je rejoins ce qu'Eric a dit au début: le comportement stochastique des LLMs est douloureux pour tout le monde. Tout le monde cherche à le stabiliser. Ils utilisent nous, ils utilisent FactSet, ils utilisent différentes solutions pour aider les résultats à être plus prédictibles. C'est une chose.
Ensuite, à la deuxième étape, c'est la partie infrastructure — et je sais parce que je suis de l'autre côté que ce sont des processus très douloureux au quotidien. Où est ma latence? Où sont mes SLA? Où sont les garanties? Est-ce que vous entraînez des modèles sur mes données? Est-ce que vous garantissez que vous ne stockez rien? C'est la deuxième partie, qui est surtout importante pour les banques et l'industrie financière en général.
--- TOPIC 7: ECONOMICS OF PRODUCTIONIZING AI (POC TO PRODUCTION) ---
Fayssal: Francois, you mentioned something very interesting — I'm not going to let it go — from your enterprise aggregated view, you mentioned all the challenges related to costs and keeping an eye on that. Can you tell us more concretely: how should firms, in terms of implementation, think about the economic aspects of productionizing AI — especially when going from POC to production, when you're really dependent on these things?
Francois: À 300 use cases en arrière-plan — en commençant à 50, 80 en phase de test ou POC, et à 25 en production — c'est intégré dans tous les modules. Je ne sais pas si vous êtes au courant mais Amundi Asset Management développe et édite en fait la plupart de ses outils d'entreprise en interne. C'est ça l'intégration — c'est la partie clé, et c'est pourquoi cela influence notre stratégie.
Nous savons tous qu'il y a 4 stratégies différentes: le Moonshot, le ROI-driven, le Product Enrichment, et le Divide and Conquer.
Pour répondre à votre question — pour le product enrichment, qui est vraiment notre cas: on a construit notre plateforme et ensuite on a détaché, par exemple, la plupart des assistants ou des outils en série. On peut les détacher et les exporter directement via des token exchanges, et grâce au protocole MCP, on peut brancher la plupart de notre système directement dans notre produit principal.
Pour le divide and conquer, je vais donner un exemple qui illustre la réponse à la première question aussi. Il nous a pris seulement quelques jours pour indexer et avoir un résumé complet sur les contrats — typiquement les prospectus. Le POC était un succès. Et on s'est rendu compte que la plupart de nos prospectus sont en fait traduits avec de petites variations d'un pays à l'autre — un disclaimer ici, un cycle de vie différent, trois fois par an mais pas de la même façon selon le pays. Et nous avons 35 000 prospectus à gérer, donc le temps, les versions, le nombre de langues.
Pour s'assurer d'un point de vue divide and conquer qu'on peut obtenir un ROI final, c'est d'accepter qu'à un moment donné, le premier bloc de construction soit avec zéro ou quasi-zéro erreur. Et ensuite, grâce à ça, ça devient une commodité pour le reste de l'entreprise qui déclenche de nombreux use cases dérivés, pour lesquels le coût marginal est ridicule — vraiment très petit.
L'autre point: le POC sur les prospectus était un succès rapide. Mais ensuite on a réalisé que le cycle de vie de ce genre de données est complexe — il faut pouvoir gérer et coordonner les limites de l'information. On en a parlé avec la couche sémantique — je crois que c'était dbt.
Fayssal: Oui, c'était dbt, oui.
Francois: D'accord. Vous avez le ISDA master agreement, vous avez un cycle de vie, parfois il y a des sous-documents, des amendements, des annexes — tout ça doit être correctement coordonné dans le cycle de vie, avec tous les inputs, pour s'assurer que vous avez quelque chose de fiable. C'est pourquoi c'est parfois très long de la phase POC à la production.
Et quand vous avez atteint ce point, vous voyez qu'en fait le juridique, la compliance, les risk managers, les portfolio managers — tous les clients internes ont besoin de ce genre de données. C'est clairement une approche médaillon que l'on peut développer ici, modernisant les données et les exposant correctement.
--- TOPIC 8: FORWARD-LOOKING BIAS AND CONTINUOUS DATA ONBOARDING ---
Fayssal: Caio, you mentioned this aspect of continuous data onboarding to enhance your AI capabilities. The question that comes to mind is: how do you tackle or think about things like look-ahead bias or data leakage when you are continuously bringing in richer and richer datasets to your process?
Caio: Quand il s'agit d'existants datasets, c'est juste la donnée elle-même. Pour cela, c'est principalement une question de savoir si les données sont point-in-time ou non. Les données qui ne sont pas point-in-time n'ont pas d'importance pour le backtesting.
La deuxième question, c'est le model risk. Ce domaine est toujours assez opaque. Nous n'avons pas beaucoup d'expérience avec ça parce que nous n'avons pas construit de signaux de trading basés sur des LLMs. Si nous en avions construit, j'aurais dit: il faut regarder quand le modèle est allé en production et ne prendre en compte que les données après cette date. Par exemple, quand est-ce que GPT-4 est allé en production? OK, à partir de là.
--- CLOSING ---
Fayssal: I would love to ask more questions, but I was asked explicitly to cut it. Definitely very interesting and very enriching perspectives from all of you, so I'm very thankful for that. And this actually closes the formal part of our event. There is still some food and some time to network, so thanks a lot for everyone who contributed, asked questions, or just was here.
============================================================ END OF PANEL ============================================================