On stage, an agent handles a request, consults documents and triggers an action in seconds. In a business, the same sequence must contend with access permissions, legacy software and a bill. The RAISE Summit, a Paris event dedicated to artificial intelligence, offers a useful starting point for exploring this gap between promise and operation. Looking ahead to September 2026, the question is no longer simply what a model can produce, but under what conditions it can be entrusted with work. This analysis draws on developments documented before that date; projections for September 2026 are forward-looking, not a report on forthcoming announcements.
Is the most powerful model the right one?
The race to develop models has established a reflex: compare scores, then choose the top-ranked contender. Yet a business is not buying a place on a podium. It wants, for example, to extract contractual clauses or answer questions about a catalogue accurately. These tasks call on different capabilities. High average performance on public tests guarantees neither a command of industry-specific terminology nor robustness when dealing with poorly structured documents.
The first question to ask behind a demonstration is: what evaluation dataset was used to validate the system? It needs representative cases, known errors, recent documents and situations where the correct response is to abstain. For a support assistant, measuring apparent satisfaction alone can conceal convincing but false answers. Actual resolutions and human corrections must also be tracked.
The Llama, Mistral and Qwen families have made open-weight models a credible option in many scenarios. That does not automatically mean free software, no restrictions or cost-free operation. Conversely, a proprietary API can speed up the initial rollout while creating dependence on the provider’s pricing, versions and terms. The right trade-off concerns the entire system, not just the availability of model weights.
RAG, adaptation, agents: ask why
Retrieval-augmented generation, or RAG, involves supplying the model with information retrieved from a document repository. It can keep answers up to date without retraining the model. But it shifts part of the problem elsewhere: are documents properly chunked, indexed and filtered according to permissions? If the retrieval engine returns an outdated procedure, even the best generator can produce a wrong answer with flawless confidence.
Adapting a model through additional training addresses other needs, such as making an output format consistent or specialising its behaviour. It does not necessarily replace an up-to-date source of documents. Agents, meanwhile, can chain together calls to tools, adding new points of failure. A reading error can turn into an incorrect change in business software.
The useful question becomes: why this architecture rather than a simpler solution? A conventional search engine, explicit rules or a small specialised model may be enough. When an agent is necessary, its permissions must be limited, its actions traceable and sensitive operations subject to approval. Autonomy is not an absolute virtue: it is a level of risk that must be justified.
Inference: the bill after the applause
Training attracts attention, but inference — running the model each time it is used — shapes the service’s day-to-day economics. A demonstration involving a few queries says almost nothing about the cost when thousands of users arrive at once. With an API, pricing often depends on the volumes of text processed and generated. With self-hosting, accelerators, memory, operations and reserved capacity must all be paid for, even when some of that capacity sits idle.
The relevant cost is therefore not just the price per million tokens. It is the cost per successfully completed task. A cheaper model that requires repeated attempts may end up costing more. An agent that runs several searches and checks turns a request into a chain of calls. Approaches that devote more computing power to reasoning sharpen this trade-off: a potentially better answer also comes at a cost in time and resources.
- How many calls and tokens does it take to complete a real task?
- What latency is observed at peak times, particularly for users experiencing the worst performance?
- What proportion of results requires human rework?
- What happens to costs when usage doubles or documents get longer?
Caching, batching requests and routing simple tasks to small models can reduce spending. Quantisation, which reduces the numerical precision of parameters, can lower memory requirements. But every optimisation requires a fresh evaluation: a technical saving has value only if it preserves the quality the business needs.
Infrastructure is about more than GPUs
Accelerators have become the symbol of competition in AI. Yet having GPUs is not enough. Available memory, communication between machines, storage and the ability to feed data into the model all affect throughput. Long contexts and simultaneous conversations also consume memory during execution. Infrastructure suited to an isolated test may become saturated under an interactive workload.
It is essential to ask where there is headroom: actual available capacity, expansion lead times, power supply, cooling and service continuity. For a hosted project, these constraints remain, even if they are transferred to the provider. Rate limits, availability commitments and failover options become part of the product.
Sovereignty also deserves a precise definition. A data centre located in France does not, on its own, resolve questions of jurisdiction, administrative access or software dependency. Where are requests routed? Who retains the logs? Who controls the encryption keys? Is it possible to migrate to another provider without rebuilding the entire application? These answers are worth more than a “sovereign” label.
Reliability is built after the demonstration
An AI service evolves: data changes, users find unexpected applications, and a new model version alters responses. Continuous monitoring, regression testing and rollback capabilities must therefore be planned for. Retrieved documents can also contain malicious instructions: prompt injection becomes particularly concerning when the system has tools or sensitive access permissions.
In the European context, the AI Act adopted in 2024 adds a framework being implemented in stages. Obligations depend in particular on the organisation’s role and the use case involved. Without conflating legal compliance and technical safety, documenting limitations, data and oversight helps with both. Providers should be asked for evidence of this work, not just a declaration of compliance.
What next? By September 2026, a plausible extension of these trends would be a more pragmatic approach to selecting projects: several models rather than just one, graduated autonomy and budgets calculated per useful outcome. This is not a foregone conclusion. The RAISE Summit can serve as a meeting point between ambition and reality, provided every demonstration is followed by three simple requests: show the errors, break down the full cost and explain how the system works as load increases. That is where production-scale deployment begins.
