An AI demonstration can be convincing in an hour. A system that processes business data, serves real users, and remains operational two years later raises a different question. This is where the distinction between “build” and “buy” becomes useful, provided it is not reduced to a contest between a technical team and a vendor.
Buying a solution is sometimes the most straightforward choice. If the use case is largely standardized, if the data can remain within a controlled environment, and if the vendor provides the necessary guarantees, recreating the same function in-house does not necessarily add value. Building becomes relevant when the tool embodies business logic that is difficult to buy, relies on unique data, or must be integrated into decisions that the company cannot delegate without relinquishing control.
The wrong starting point is to choose a product before describing the work to be improved. AI used for summarization, classification, or assistance does not automatically warrant a dedicated platform. Conversely, a subscription that seems inexpensive at first can become a costly dependency if it takes root at the center of a critical process with no exit plan. An AI assessment and support engagement is intended first and foremost to clarify this scope: who uses the system, with what data, and to produce which decision or action.
Buying is an operational choice, not a surrender
A component is purchased when it meets a common need without forcing the organization to reinvent what already exists. Translation, transcription, data extraction from a stable format, office productivity assistance: rapid availability and managed maintenance may matter more than code ownership. The company must nevertheless look beyond the license. The terms governing data use, price changes, API limits, administrator access, available logs, and reversibility are all part of the product.
A serious purchase therefore requires precise requirements. Can the data and configurations be exported in a usable format? Can roles be connected to the company's directory? Does the contract state what happens to submitted content and generated outputs? Does the vendor announce changes that could alter the system's behavior? These questions are less impressive than a model comparison, but they determine the freedom to switch tools.
Data sensitivity can tip the balance. This is not a reason to declare every external solution impossible; it is a reason to define the required level of control. The CNIL's recommendations on AI systems provide a useful foundation: clear purpose, minimization, security, and governance are not formalities added after the fact. They influence the architecture, eligible vendors, and the data that a pilot can actually use.
Building means taking responsibility for what follows the prototype
Building does not necessarily mean training a proprietary model. In most projects, the value lies instead in the integration: connecting data sources, formalizing business rules, implementing access rights, evaluating responses, and integrating the tool into a workflow. These are the layers that remain when the underlying model changes.
The cost of development therefore does not end with its first version. It includes monitoring, security, fixes, documentation, testing whenever the model changes, and people capable of taking over the system. The NIST AI Risk Management Framework proposes managing, measuring, and governing risks throughout the entire life cycle. For an executive, this principle has a simple translation: a build budget without an operating budget is not a complete budget.
Building makes sense when the company also knows who will own the product after delivery. Business teams must be able to assess the responses and flag exceptions. IT must be able to update connectors and identities. Management must have established the rules of accountability. Without this division of responsibilities, a custom project may merely shift the dependency: from the software vendor to the service provider or to an employee who has become indispensable.
This is also why sovereign AI choices must be expressed in concrete terms. Hosting in a European environment, selecting reversible components, or retaining control over logs may be decisive for a sensitive use case. This removes neither the need for integration nor the need for evaluation. Sovereignty means the ability to decide and to change, not a label applied to infrastructure.
The hybrid approach makes sense when the boundary is clear
Many companies do not have to choose a single doctrine. They can buy components that have become commonplace and focus development on the workflow that differentiates them. A model accessible through an API can support a pilot; access rules, business data, and evaluation criteria remain under control. The system then gains flexibility without claiming ownership of every technical component.
This option works only if the boundary is documented. Which data remains in the internal system? Which component can be replaced? When is human intervention mandatory? Which results justify continuing or stopping the pilot? An initiative conducted with an AI partner capable of taking a project from scoping to deployment can make these decisions verifiable rather than leaving them buried in sales presentations.
Europe adds a framework that makes this discipline more urgent. The European AI regulation does not require every company to build its own model. It does, however, require the relevant actors to understand their role in the value chain and organize their responsibilities. The architecture choice can no longer be separated from this issue.
The right decision is therefore not the one that puts an assistant on display the fastest. It is the one that leaves the company able to explain why the tool exists, evolve it, and, if necessary, part with it. Before any demo, a less flattering but more useful question must be answered: which parts of our operations do we truly want to entrust to others, and which must we remain capable of operating ourselves?