AI glossary for executives and finance departments: forty key notions

In most executive committees, the term "artificial intelligence" has been coming up for some time now, often without everyone meaning the same thing by it. For an executive, a chief financial officer (CFO), a partner in an investment fund or a chartered accountant, this vagueness has very concrete consequences: budgets are approved on the strength of presentations whose vocabulary is not fully understood, documents are entrusted to providers without anyone knowing precisely what becomes of them, and promises are accepted whose credibility cannot be judged. The problem, then, is not merely a lack of familiarity with a few terms. It lies in being unable to ask the right questions at the right time, that is, before deciding rather than after.

This glossary meets that need. It brings together the notions most commonly used in AI projects, from the words that describe the technology to those that frame its use, such as personal data, traceability and human oversight. Each notion is defined in plain language, linked to what it concretely changes for an executive, illustrated by a generic example that refers to no real organisation, and then tied to a decision question: what needs to be checked, who must validate, and which risk must be monitored over time. The aim is not to turn an executive into an engineer. It is to help them ask for the right evidence and to tell a solid answer from a merely cosmetic one.

This text is also intended as a working tool. The entries are self-contained: you can read them in order to build a shared vocabulary within your team, or consult just one when the subject comes up for discussion. The final section offers a printable checklist, a summary glossary and answers to the questions most frequently raised in committee.

How to read each entry#

Each notion follows the same structure, so that you can find it quickly and compare it with the others.

• The definition. It describes the notion in everyday language, without any mathematical formulae. Where confusion is common, it also states what the notion is not, since many misunderstandings arise from the same word being used for different realities.
• Why it matters to executives. It explains why the notion counts for an investment, steering or control decision, rather than for technical execution. An executive does not need to know how a system was trained, but must know whether that training was documented.
• The generic example. It illustrates the notion in an ordinary situation, deliberately far removed from any real company. It helps you picture the mechanism before discussing it with a provider.
• The decision question. It is always broken down in the same way: what to check, the function that must validate, and the risk to watch over time.

A few points of method complete this reading guide. The examples are generic: they name no client, fund, person or tool. No figures are given, because thresholds depend on each context: where a measurement is needed, the entry describes the method or the type of indicator to track. Finally, legal matters are presented as principles. They do not replace the advice of a lawyer, and any regulatory obligation must be checked with one before it is applied.

Models#

This part presents the technical building blocks. You do not have to build them, but you do need to understand them in order to assess what a provider is offering you, explain why a result varies from one request to the next, and spot the costs that do not appear in an initial presentation. The notions follow on from one another: the first describes the general principle, and the following ones address increasingly concrete objects.

Machine learning#

Machine learning refers to the methods by which a program learns rules from examples, instead of having them written out one by one by a developer. It is shown cases that have already been labelled, for example invoices whose accounting allocation is known, and it adjusts its parameters to reproduce those answers on new cases. The result of this training is called a model, that is, a statistical function whose quality depends directly on the examples used. Almost all current applications of AI rely on this principle.

Why it matters to executives. The performance of a machine learning solution reflects above all the quality of its examples, far more than the code that runs it. It is therefore the data that must be questioned, and not the technology alone.

Generic example. A company wants to classify its expense claims automatically. It supplies the system with claims already classified by its staff, then lets it apply that classification to new claims.

Decision question. Has the system learnt from examples that are representative of our business?

• What to check: where the examples come from, how old they are, how well they cover rare cases, and the instructions given to those who labelled them.
• Who validates: the CFO or the head of internal control, together with the people who established the reference classification.
• Risk to watch: good performance on common cases that masks fragility on unusual cases, which are often the most costly.

Language model#

A language model (large language model, often abbreviated to LLM) is a machine learning model trained on very large volumes of text to predict the most likely continuation of a sequence of words or word fragments. This simple capability, repeated on a very large scale, enables it to summarise, translate, rephrase or answer a question. It does not consult a base of verified facts: it produces what seems plausible in the light of its training and of the request it receives. That is why its answer can be both fluent and wrong.

Why it matters to executives. The language model is the engine behind most recent text tools. The question is not only what it can do, but where it runs, which data it is connected to and who owns the exchanges.

Generic example. A member of staff asks a tool to draft a letter to a client from internal notes. The resulting text is polite and well structured, but it must be reviewed, because nothing proves that it reflects the notes exactly.

Decision question. Which text-based use do we entrust to a language model, and with what level of review?

• What to check: the list of authorised uses, the types of information that may be entered, and the existence of a human review before anything is sent outside the organisation.
• Who validates: the chief information security officer and the lawyer, as soon as confidential data is involved.
• Risk to watch: leakage of sensitive information through the entry of unauthorised documents, and the circulation of a false text that appears reliable.

Generative AI#

Generative AI refers to systems capable of producing new content (text, images, sound, code, tables) from a request, drawing on patterns learnt during their training. Language models are its most widespread form in businesses. As a general rule, the content produced is not a copy taken from a document base: it takes the form of what the system has seen, without being an exact reproduction of it. This flexibility explains both its appeal and the risks it poses to reliability.

Why it matters to executives. What sets generative AI apart from traditional analysis is that it produces content which the company will then have to use, sign or distribute. Governance therefore changes in nature: it is no longer enough to check a calculation; the output itself and its status must be checked.

Generic example. A team asks for a summary of several sets of meeting minutes. The system produces a note of a few paragraphs, which the person in charge compares against the minutes before circulating it.

Decision question. Is the generated content treated as a draft subject to validation, or as a final document?

• What to check: that each type of output has a defined status (draft, validated, distributed) and that the person who signs it off has reviewed the sources.
• Who validates: the relevant business owner, and the legal department for any content that commits the company.
• Risk to watch: the distribution of unverified content, when responsibility for what is published remains with the company.

Token#

A token is the unit of text that a language model reads and produces. It does not correspond exactly to a word: a common word may count as a single token, while a long, technical or rare word may count as several, and punctuation counts too. Text is split into tokens before it is processed, and the model then reasons over that sequence. Language model services often charge for usage in tokens, which makes comparing several offers less straightforward than it seems.

Why it matters to executives. The token is the unit of account for many services. An executive comparing offers needs to know that the volume consumed depends on the length of the requests, of the responses and of the history passed along, and not only on the number of users.

Generic example. A text rich in technical terms, proper names or tables may represent a far greater volume than an ordinary email of similar appearance. A tool that analyses a long file will therefore consume considerably more than a simple exchange of messages.

Decision question. How is usage measured, and on what volume assumptions does our budget rest?

• What to check: the billing unit, how the conversation history is counted, and the difference between input text and output text.
• Who validates: the CFO, with the team that knows the actual uses.
• Risk to watch: a budget built on overly simple tests, which deteriorates as soon as requests become long or numerous.

Context window#

The context window is the maximum amount of text a language model can take into account at once, measured in tokens. It covers the instruction, the documents supplied, the history of the exchange and the response being written. Beyond this limit, the excess information is not read and therefore cannot influence the response. A wider window makes it possible to process longer files, but it does not guarantee that the model will make proper use of every passage.

Why it matters to executives. The context window determines what a tool can analyse in a single pass. It is often the invisible cause of incomplete answers: the system has not forgotten part of the file; it never received it.

Generic example. A tool is asked to compare the clauses of several contracts. If the whole set exceeds its reading capacity, the last documents are not taken into account, and yet the comparison appears complete.

Decision question. Does the file fit within the reading window, and does the output clearly state what was analysed?

• What to check: the typical size of the files processed, any splitting method used, and explicit mention of unread documents in each output.
• Who validates: the business project lead, who knows the level of completeness expected.
• Risk to watch: a conclusion presented as exhaustive when it rests on only part of the file.

Fine-tuning#

Fine-tuning consists of continuing the training of an existing model on a set of examples specific to a domain, a vocabulary or a response format. The model retains its general capabilities and acquires new ones, for example a consistent way of structuring a note. This operation requires carefully prepared data and rigorous evaluation afterwards. It is not used to teach the model recent facts, for which other methods are generally better suited.

Why it matters to executives. Fine-tuning is often presented as the way to adapt AI to the company. Yet it is a heavy investment in data, skills and maintenance, which must be justified against lighter alternatives, notably retrieval-augmented generation, described further on.

Generic example. An asset management firm wants its summary notes always to follow the same structure and the same vocabulary. Fine-tuning on validated notes can stabilise this format, but it does not make the model accurate on current market data.

Decision question. Does the need justify modifying the model itself, rather than providing better context to an existing model?

• What to check: the alternatives actually tested, the quality and representativeness of the adaptation examples, and the plan for redoing the work when the base model changes.
• Who validates: the IT department, with the business function responsible for validating the examples.
• Risk to watch: a costly dependence on a specific version of the model, and adaptation examples that contain confidential information.

API#

An API (application programming interface) is a standardised entry point through which one piece of software can call another. In the field of AI, it allows your system to send a request to a model hosted elsewhere and then receive the response, without hosting the model yourself. Exchanges follow documented rules, which specify formats, access rights and usage limits. The API is therefore the technical link through which company data leaves for a provider, which makes it a major control point.

Why it matters to executives. An API is not an integration detail. It is the door through which data passes, and it is also where dependence on the provider is determined, since changing supplier often requires part of the connections to be rebuilt.

Generic example. Expense management software sends each receipt to a model through an interface, receives a suggested category and displays it to the employee for validation.

Decision question. Which data passes through this interface, where is it processed, and what happens to the contract if we change provider?

• What to check: the list of fields transmitted, where processing takes place, the retention rules applied by the provider and the reversibility conditions, that is, the terms for exiting the service.
• Who validates: the chief information officer (CIO) and the data protection officer (DPO).
• Risk to watch: a transmission of personal data more extensive than necessary, and a technical dependence that is hard to unwind.

Data#

Data is the raw material of every AI project, and the primary source of legal and operational risk. The notions in this part help distinguish what is used to build a system, what is supplied to it while it is in use, and what must be protected, anonymised or excluded.

Training data#

Training data is the set of examples used to build a machine learning model. It may be produced by the company, bought from a third party, collected online or supplied by a provider. Its content determines what the system can do, what it misses and the distortions it may reproduce. A model cannot be better than the representation of reality contained in its training data.

Why it matters to executives. Training data is at once a question of ownership, of law and of quality. You need to know whether you have the right to use it, whether it is representative and whether its origin is documented.

Generic example. A firm wants a tool that spots anomalies in filings. If the training examples contain only ordinary files, the tool will have a poor grasp of unusual situations, which are precisely the ones it is meant to detect.

Decision question. Do we know where the data used to build the system comes from, and is it suited to our business?

• What to check: the origin of each dataset, the associated usage rights, the possible presence of personal data and the representation of rare cases.
• Who validates: the lawyer or the DPO for rights, the business for representativeness.
• Risk to watch: a system that reproduces the blind spots of its data, or that was trained on data whose use was not permitted.

Synthetic data#

Synthetic data is artificially generated data designed to mimic the statistical properties of real data, without directly reproducing the original records. It is used to test or train a system when real data is scarce, sensitive or difficult to use. Its quality depends entirely on the fidelity of the generator: a poorly calibrated generator produces data that is plausible but misleading. It does not remove the need for control; it shifts it elsewhere.

Why it matters to executives. Synthetic data can allow testing without exposing real data. That does not, however, settle the compliance question: you need to know whether it was derived from personal data and whether it could still lead back to an individual.

Generic example. A team wants to test a file-processing tool without handling real client files. It generates fictitious files that follow the same types of amounts, dates and structures, then checks that the same errors appear.

Decision question. Is the test data genuinely anonymous, and does it represent the situations we need to master?

• What to check: the generation method, the risk of real individuals being reconstructed and the coverage of difficult cases.
• Who validates: the DPO for the absence of re-identification, the business owner for representativeness.
• Risk to watch: a false sense of security, with tests validated on data too smooth to reveal real failures.

Personal data#

Personal data is any information relating to an identified or identifiable natural person, directly (a name, an address) or indirectly (a combination of elements that makes it possible to recognise them). The GDPR regulates it strictly: its collection, use and retention must, depending on the case, rest on a legal basis to be confirmed by a lawyer, a specific purpose and appropriate security measures. A text, an image, a recording or a row in a table may contain it, sometimes without anyone realising.

Why it matters to executives. As soon as an AI project handles information about clients, employees or contacts, it may fall within the scope of the GDPR, which should be confirmed with a lawyer. The executive therefore needs to know where this data is entered, who can see it and whether it is used to train a third-party tool.

Generic example. An employee pastes a client's email into a drafting tool to obtain a reply. The message contains a name, an address and personal context: this is personal data, transmitted to a service that may be located outside the company.

Decision question. Which personal data enters the system, and on what basis do we process it?

• What to check: the fields collected, the declared purpose, access, the location of processing and whether a data protection impact assessment is needed where the risk is high.
• Who validates: the DPO, with the business function that owns the purpose.
• Risk to watch: spontaneous entry of personal data by teams, outside any validated framework.

Anonymisation#

Anonymisation consists of transforming personal data in such a way that it is no longer possible, by reasonable means, to link a piece of information to an individual. Genuinely anonymous data may, depending on the case, fall outside the scope of the GDPR, a point to be confirmed by a lawyer. The subject is more delicate than it appears, since data that seems anonymous can be re-identified by cross-referencing it with other sources. Anonymisation is therefore a result to be demonstrated, not a box to be ticked.

Why it matters to executives. Anonymisation is often put forward as the argument that allows data to be used without multiplying authorisations. It is useful only if it withstands realistic cross-referencing, and the burden of demonstrating this lies with the organisation that claims it.

Generic example. A study analyses the payment habits of a company's clients. Removing names is not enough if the exact dates, the location and the nature of a service make it possible to find a specific person within a small group.

Decision question. Can we demonstrate that this data no longer allows anyone to be identified, even when cross-referenced with what is accessible?

• What to check: the fields removed and those made less precise, the size of the remaining groups, and the cross-referencing test carried out before any use.
• Who validates: the DPO, ideally with an independent expert for sensitive datasets.
• Risk to watch: re-identification through cross-referencing, and reuse of the data beyond the intended purpose.

Pseudonymisation#

Pseudonymisation replaces direct identifiers (name, file number, address) with substitute codes, while the correspondence table is kept separately and protected. Unlike anonymisation, it does not remove the personal nature of the data: whoever holds the correspondence can always trace back to the individual. The GDPR presents it as a useful security measure that limits exposure, although its legal effect remains to be confirmed with a lawyer.

Why it matters to executives. Pseudonymisation is a risk-reduction tool, whose legal effect must be confirmed by a lawyer. It allows teams to work on less sensitive data while retaining the ability to retrieve a file when necessary, for example for an audit.

Generic example. An administration team replaces employees' names with internal identifiers before sending working-time data to an analytics tool. Only the person responsible for the link can trace back to the name.

Decision question. Who holds the correspondence between the codes and the individuals, and is this separation genuinely effective?

• What to check: where the correspondence table is stored, the access rights, how easily the codes could be reconstructed and the logging of look-ups.
• Who validates: the security officer, with the DPO.
• Risk to watch: a code that is easy to reconstruct, or a key stored in the same place as the data, which cancels out the protection.

Knowledge base#

A knowledge base is an organised set of documents and information (procedures, notes, frequently asked questions, standard contracts, case histories) that the company makes searchable in a structured way. In an AI project, it serves as a reference source: the system relies on it to answer, instead of depending solely on what it learnt during training. The quality of a knowledge base depends less on its size than on how up to date and accurate it is, and on how clearly its owners are identified.

Why it matters to executives. The knowledge base is often an organisation's real information asset, and it is often the most neglected point. You need to know who updates the content, who decides what is published and which version prevails when two documents contradict each other.

Generic example. A firm gathers its internal notes on frequently encountered tax regimes. A tool relies on these notes to answer staff questions, indicating which note it used.

Decision question. Who is responsible for the accuracy of each reference document, and how do we know it is up to date?

• What to check: the date of the last review, the named owner of each piece of content, and the procedure for withdrawing obsolete documents.
• Who validates: the business owner for each domain, with a cross-functional role that checks the consistency of the whole.
• Risk to watch: a fluent answer based on an outdated procedure, without the user knowing that it is outdated.

OCR (optical character recognition)#

OCR (optical character recognition) is a technique that turns an image containing text, such as a scan or a photo of a document, into text that software can use. It identifies letters and numerals, then reconstructs the layout where possible. Recent systems combine OCR with comprehension models, which makes it possible to go beyond simple reading. A misrecognised character can, however, alter an amount or a name without anything flagging it.

Why it matters to executives. For a finance department, OCR determines the reliability of the entire chain that follows: data entry, reconciliation, control. You therefore need to measure what the system does with degraded, handwritten or poorly scanned documents, and not rely on a demonstration carried out on clean documents.

Generic example. A department scans expense receipts. On a crumpled receipt, one character is mistaken for another, and the amount extracted is wrong. Without a check, the error flows into the accounts.

Decision question. How do we check the data extracted from a document before it feeds a calculation or an accounting entry?

• What to check: the measured accuracy of extraction on representative documents, including the most degraded cases, and the presence of consistency checks (totals, format, reconciliation).
• Who validates: the head of accounting, on a sample of real documents.
• Risk to watch: a silent error in an amount, a name or a date, which then spreads into the financial statements.

Use#

This part describes the ways in which AI concretely enters day-to-day work. The notions are presented from the simplest to the most autonomous: an instruction given to a model, an assistant that supports a person, a system that acts on its own on certain steps of a process. The more the system acts alone, the more precise oversight must be.

Prompt#

A prompt is the instruction or request addressed to a language model. It may contain instructions, context, examples and documents, and the order in which these elements are presented influences the result. Companies often use standardised prompts, written and tested by a team, so that responses remain consistent from one user to the next. A prompt is therefore a process component, and not just a question put to a machine.

Why it matters to executives. A well-written prompt is a form of written procedure. You need to know whether validated prompts exist for sensitive uses, who wrote them and how you know they produce a compliant result.

Generic example. To analyse contracts, a team writes a prompt asking for the commitment period, the notice period and the termination clauses to be extracted, with the words "not found" where the information is absent. This prompt is then tested on a set of contracts that have already been analysed.

Decision question. Do our critical uses rely on written, tested and versioned instructions, or on the skill of each user?

• What to check: the existence of a library of validated prompts, their change history and the non-regression tests run after each change.
• Who validates: the business owner and the head of internal control.
• Risk to watch: a silent variation in results depending on the wording, and instructions that circumvent confidentiality rules.

Retrieval-augmented generation (RAG)#

Retrieval-augmented generation (RAG) consists of first searching a document base for the relevant passages, then passing them to the model along with the question. The model answers on the basis of these extracts, which makes it possible to anchor the answer in identifiable and recent sources without modifying the model itself. The system can also cite its sources, which makes verification easier. Its quality depends on two links in the chain: the search must find the right passages, and the model must read them correctly.

Why it matters to executives. Retrieval-augmented generation is often the most suitable approach when the company wants to query its own documents without building them into a model. It shifts the reliability question towards the quality of the document base and of the search, which lends itself better to control.

Generic example. An employee queries the internal procedures on expense claims. The system retrieves the applicable procedure, displays the passage used and answers. If no procedure matches, it must say so instead of inventing a rule.

Decision question. When the answer is wrong, can we tell whether the search failed or whether the model misinterpreted the passage?

• What to check: the relevance of the passages returned on a set of questions whose answer is known, the presence of citations that can be consulted, and how the system behaves when faced with a question that has no answer in the base.
• Who validates: the knowledge base owner, with the business function concerned.
• Risk to watch: answers based on an old or poorly chosen source, presented with an air of authority.

AI agent#

An AI agent is a system that does not merely respond: it plans a sequence of actions, uses tools (searching a database, sending a request, reading a file), observes the results and adjusts what comes next. Its autonomy may be real or limited to supervised steps. The more write access it has to systems, the more concrete the effects an error can have. The notion therefore covers a wide range of levels of autonomy, and the level in question must always be specified.

Why it matters to executives. An agent shifts the question from content to action. The real question is not "what does it say?" but "what can it do, with what rights, and who can stop an action in progress?".

Generic example. An agent is tasked with preparing the bank reconciliations for the period. It reads the statements, proposes matches and prepares the entries. It does not validate the entries: a person does so after reviewing the discrepancies.

Decision question. Which actions is the agent authorised to carry out on its own, and which points require human validation before execution?

• What to check: the explicit list of accessible tools, the write permissions granted, the action logs and the stop mechanism.
• Who validates: the IT department and the head of internal control, before any go-live.
• Risk to watch: a chain of actions that runs on without any control, or an authorisation granted beyond the actual need.

Co-pilot#

A co-pilot is an assistant built into a work tool, which supports the person without replacing them. It suggests, rephrases, completes or explains, but the decision and the action remain with the user. The term has become common for describing the drafting, search or analysis assistants available within business software. Its value lies less in its power than in its place in the process and in the clarity of the limits it observes.

Why it matters to executives. The co-pilot is often the first use to be deployed, because it seems low-risk. Yet it raises real questions: what data can it see, who configured it, and do users know that a suggestion is not a validated truth?

Generic example. In consolidation software, a co-pilot proposes an explanation of the variances between two periods. The analyst can accept, amend or reject the proposal, and only the analyst's final wording is recorded.

Decision question. Does the co-pilot genuinely improve the team's work, and do users know when to be wary of its suggestions?

• What to check: the data it can access, the use cases for which it is recommended, and training on the tool's limits.
• Who validates: the business owner, with the quality or control function.
• Risk to watch: excessive trust that leads people to accept without reviewing, especially on subjects where errors are subtle.

Automation#

Automation consists of entrusting a system with the repeated execution of a task according to defined rules. It may be conventional, based on explicit rules (if a given condition is met, then a given treatment is applied), or rely on AI to handle varied inputs such as emails or documents. Automating does not mean removing control: control shifts to the design of the rules, the monitoring of exceptions and the traceability of executions.

Why it matters to executives. Automation is as much an organisational choice as a technical one. It must be decided on the basis of the process itself: what is repetitive, what is stable and what must remain subject to human decision.

Generic example. A firm automates the sorting of incoming emails by type of request. Ambiguous messages are sent to a manual processing queue, rather than being forced into a category.

Decision question. Which processing is automated, which exceptions are detected, and who takes over when the system cannot cope?

• What to check: the list of automated cases, the doubt criterion beyond which a file is switched to human handling, and the execution history.
• Who validates: the business process owner, with internal control.
• Risk to watch: an error repeated on a large scale, since automation multiplies good results and bad ones alike.

Robotic process automation (RPA)#

Robotic process automation (RPA) refers to software that reproduces a user's actions on an interface: clicking, copying a field, entering a value, downloading a file. It is particularly useful when legacy applications do not offer a programming interface. It becomes fragile when the screen changes, and it can be combined with AI to read documents or make simple decisions.

Why it matters to executives. RPA is often presented as a simple solution, but it creates a dependence on existing screens and procedures. You need to know who maintains the robots, what happens when an application is updated and which access credentials they use.

Generic example. A robot retrieves each statement available on a portal and enters it into a tracking tool. When the portal changes its layout, the robot stops, and an alert must notify the team.

Decision question. Who maintains these robots, how are they monitored, and what happens when an application changes?

• What to check: the credentials used (dedicated, controlled accounts), the logging of actions and the recovery procedure in the event of a stoppage.
• Who validates: the IT department and internal control.
• Risk to watch: excessively broad access granted to a robot, and a dependence that remains invisible until it breaks down.

Use case#

A use case is a specific application of AI to an identified business problem, described with its context, its users, its data, its expected results and its limits. It is the relevant unit of decision: one does not decide to "adopt AI"; one decides to use a system for a given task. A good use case can be stated in a single sentence that a non-specialist can understand, and it includes a way of checking that it has worked.

Why it matters to executives. The use case is the executive's prioritisation tool. It makes it possible to compare projects against common criteria: the importance of the problem, the quality of the data, the level of risk and the ability to measure the result.

Generic example. Several proposals reach the committee: classifying supplier invoices, drafting standard replies, anticipating late payments. Each is reframed as a use case with its user, its data and its success criterion, then compared with the others.

Decision question. Is this use case described precisely enough for someone to say whether it has succeeded?

• What to check: the problem statement, the population concerned, the success criterion, the data required and what the system must never do.
• Who validates: the business sponsor, with the CFO or executive management depending on what is at stake.
• Risk to watch: a project launched on a vague ambition, with no criterion for saying that it has failed.

Information extraction#

Information extraction consists of locating and isolating specific elements in a text or document: a due date, an amount, the name of a party, a clause, an identifier. It turns an unstructured document into fields that can be used in a table or in a tool. An AI system achieves this by reading the text and applying rules that are either learnt or explicitly described. The result must be accompanied by the place in the document from which each piece of information comes, so that it can be checked.

Why it matters to executives. Extraction is one of the most concrete uses for finance functions, because it feeds existing processes. The executive should focus above all on how errors are detected before they enter the accounts or the analyses.

Generic example. From a set of lease contracts, the system records the end date, the monthly amount and the indexation clause, then places them in a table in which each row refers back to the relevant page of the contract.

Decision question. Is each piece of extracted information linked to its source and subject to a check proportionate to its importance?

• What to check: the presence of a source reference for each field, the control rules (consistency, format, reconciliation), and the cases in which the system indicates that it does not know.
• Who validates: the head of the function that consumes the data.
• Risk to watch: information that is false but plausible, extracted from the wrong version of the document.

Classification#

Classification consists of assigning a category to an item from a set of predefined categories: an invoice to an account, an email to a type of request, a transaction to a risk level. It often relies on machine learning, or on generative AI guided by instructions. The quality of a classification is judged by its consistency with reference human decisions, and by the way it handles cases that fit no category.

Why it matters to executives. A classification system reproduces an interpretive grid, and therefore a view of the business. The executive must ensure that this grid is validated by those who use it, and that the categories remain stable over time.

Generic example. A services company classifies its clients' requests into several categories. A request that matches no category is sent to a qualification queue, rather than being forced into the least unsuitable category.

Decision question. Who defines the categories, and how do we check that the classification remains faithful to human decisions?

• What to check: the category framework, the method of comparison with a reference classification, and the handling of cases that fall outside the categories.
• Who validates: the business owner, and management control for accounting categories.
• Risk to watch: a silent drift in the categories, or a classification that favours a default category.

Automatic summarisation#

Automatic summarisation produces a shorter version of a document while retaining its main ideas. It may be extractive, selecting existing sentences, or generative, rephrasing the content. The second type is more flexible, but it may omit a nuance or introduce wording that changes the meaning. A summary is therefore an interpretation of the document, and not the document itself.

Why it matters to executives. A summary improves readability, but it hands part of the judgement over to the tool. The question is what has been left out, and whether decisions are taken on the basis of the summary or of the source.

Generic example. A committee receives the summary of a long audit report. A recommendation that depends on a reservation set out in an appendix may disappear from the summary, even though it changes the scope of the conclusion.

Decision question. Does the summary refer back to the source passages, and are decisions always based on the original document?

• What to check: the presence of references to the passages, a comparison between summary and source on sensitive points, and a statement of the elements excluded.
• Who validates: the author of the source document and the person presenting the decision.
• Risk to watch: the omission of reservations, exceptions or conditions, which changes the meaning without anyone noticing.

Quality and risk#

An AI system can be useful and flawed at the same time. This part brings together the notions that make it possible to describe failures, to make them visible and to decide who is accountable for them. It is not only about technical error: it also covers bias, the traceability of decisions and a person's ability to take back control.

Hallucination#

A hallucination is a response produced by a model that is false, invented or not grounded in its sources, yet presented with apparent confidence. It is not an isolated bug: it stems from the very nature of language models, which produce what is plausible rather than what is verified. A hallucination may take the form of a non-existent reference, an incorrect figure, a fictitious court ruling or a summary that adds information absent from the source. The risk increases when the question concerns a poorly documented field or when the user is unable to check.

Why it matters to executives. Hallucination is the central risk of text generation, because it makes error convincing. The question is not whether the system makes mistakes, but in which cases it makes them and how the error is detected before it has any effect.

Generic example. A drafting tool cites a legal provision that does not exist, with a plausible title. A reviewer who knows the field spots the error, but a reviewer in a hurry could let it through.

Decision question. How do we detect a false answer before it is used, and which types of output are prohibited without verification?

• What to check: the presence of sources for each factual statement, testing of the system on questions whose answer is known, and its behaviour when faced with a question that has no answer in the documents.
• Who validates: the business owner, and an independent reviewer for content that commits the company.
• Risk to watch: an invented citation, an inaccurate figure or a legal conclusion presented as established.

Bias#

A bias is a systematic distortion in a system that leads it to treat certain situations, certain groups or certain types of case unequally. It may stem from the training data, from the way the problem was framed, from measurement choices or from the use made of the result. A bias is not always intentional, and it does not necessarily show up in an overall average: it often emerges when sub-populations are examined. Detecting it therefore requires breaking the results down by the relevant categories.

Why it matters to executives. In a finance department, biases can produce credit, recruitment or control decisions that are less favourable to certain profiles, with legal and reputational consequences. The executive must insist on being shown the broken-down results, and not just an overall score.

Generic example. A tool that prioritises files for review displays a satisfactory overall score. By breaking the results down by type of file, the team discovers that files of an infrequent type are systematically handled less well.

Decision question. Have the results been analysed by sub-population, and what is done about the gaps observed?

• What to check: the list of relevant breakdowns, the gap observed between groups, and the existence of a documented decision in response to that gap.
• Who validates: the head of compliance and a representative of the business function concerned.
• Risk to watch: indirect discrimination, invisible in averages but identifiable by the people affected or during an inspection.

Explainability#

Explainability is the ability to explain, in an understandable way, why a system produced a given result. It ranges from simple justification (the criteria that carried weight) to technical analysis of the internal workings, which remains difficult for highly complex models. A distinction must be drawn between the explanation offered to the user, the one intended for the auditor and the one used to correct the system. A plausible explanation is not necessarily accurate: it must also be tested.

Why it matters to executives. An executive must be able to justify a decision to a client, an employee, an auditor or a regulator. If a system cannot explain what it has done, the decision remains difficult to defend, even if it is statistically sound.

Generic example. A tool recommends reviewing an expense claim. The interface shows the factors behind the recommendation: an unusual amount for the category, an incomplete receipt. The user can check each of these factors.

Decision question. Can we explain a decision to the person concerned, using factors that genuinely correspond to the calculation performed?

• What to check: the level of explanation provided to each audience, the consistency of that explanation with how the system actually works, and the documentation of the system's limits.
• Who validates: the DPO for automated decisions concerning individuals, and the lawyer for the reasons to be communicated.
• Risk to watch: a cosmetic justification, constructed after the fact, that does not match the mechanism actually used.

Traceability#

Traceability is the ability to reconstruct the history of a result: which data was used, which version of the model or of the instruction produced the response, who validated it and when. It relies on reliably retained logs, identified versions of components and clear retention rules. Without traceability, it is impossible to answer a simple question after the fact: why was this decided?

Why it matters to executives. Traceability is what makes it possible to control a system over time. It makes an opaque use auditable, and it helps the company establish responsibility for a decision when necessary.

Generic example. A department uses a model to propose accounting allocations. For each proposal, the log records the model version, the instruction used, the input data and the person who accepted or corrected the proposal.

Decision question. Can we reconstruct, for a given decision, the entire chain that led to it?

• What to check: the logs retained, the separation between input data and outputs, the identified versions and the retention rules set by internal policy.
• Who validates: the head of internal control, with the statutory auditors during a review, and the DPO for logs that contain personal data.
• Risk to watch: incomplete logs, or logs that themselves contain sensitive data and become a leakage risk.

Human oversight#

Human oversight refers to the arrangement by which a competent person retains the ability to understand, control and, if necessary, stop or correct the operation of a system. It does not consist of reviewing every output, which would often be unrealistic, but of defining control points, alert thresholds and powers of intervention. This principle features in the European legislation on AI for systems that present risks, a point to be confirmed by a lawyer.

Why it matters to executives. Human oversight is the concrete answer to the question "who decides?". It must be assigned to named individuals and given the time, information and authority it needs. A review in principle only, with neither resources nor the power to stop the system, is not oversight.

Generic example. A system proposes the automatic approval of small expenses. Any proposal above an amount set by internal policy, or showing an anomaly, is routed to a person who can reject it without having to justify their disagreement to the tool.

Decision question. Who can stop the system, who corrects it, and with what level of information?

• What to check: the named control points, the thresholds that trigger escalation, the training of supervisors and the real ability to deactivate the system.
• Who validates: executive management or the committee that owns the risk, with the head of internal control.
• Risk to watch: oversight that becomes a mere rubber stamp, where the human approves without examining, for lack of time or information.

Technical debt#

Technical debt is the future cost created by hasty or incomplete choices: poorly documented code, fragile connections, badly named data, an absence of tests, dependence on a single provider. Like financial debt, it is not a problem in itself, but it becomes costly if it is never repaid and keeps accumulating. In AI projects, it grows quickly, because models, prompts and data evolve constantly and must be maintained together.

Why it matters to executives. A proof of concept that works can mask significant debt. The executive must ask what will be needed to put the system into lasting operation, who will maintain it and what the cost of bringing it up to standard will be.

Generic example. A tool is developed in a hurry for a team. It works, but the processing rules sit in code known to a single person, without documentation. When that person changes role, maintenance turns into a rebuilding exercise.

Decision question. What will maintaining this system cost over time, and who knows how to keep it running?

• What to check: the documentation, the automated tests, the quality of the connections and the existence of an identified team or provider for updates.
• Who validates: the CIO and the head of operations.
• Risk to watch: dependence on one person or one provider, and the silent accumulation of temporary fixes that become permanent.

Governance#

Governance answers a simple question: who decides what, on what basis, and who is accountable if something goes wrong. The notions in this part set out the European legal framework, the data that must be managed as an asset and the hosting choices that determine control. These are not subjects reserved for lawyers: they involve the board, the audit committee and every process owner.

Data governance#

Data governance is the set of rules, roles and processes that define who is responsible for which data, how it is defined, who can access it, how it is corrected and how it is deleted. It specifies the data owners (the person accountable for its accuracy and its use), those who guarantee its quality and the sharing rules. Without it, an AI project takes in contradictory data and reproduces its inconsistencies on a large scale.

Why it matters to executives. An organisation without data governance cannot say what its system really knows. Nor can it secure the project, since responsibilities remain blurred as soon as an incident occurs.

Generic example. A sales department and a finance department use different definitions of the same client. The AI tool is fed by both, and its analyses do not match the usual dashboards. Governance settles the reference definition and appoints an owner.

Decision question. For each piece of data used by the system, do we know who is accountable for it and according to which definition?

• What to check: the data register, the named owners, the shared definitions and the access rules.
• Who validates: the data governance committee, with the CFO for financial data.
• Risk to watch: data used by the AI without an owner, which drifts without anyone noticing.

The following table summarises the usual allocation of validations in an AI project. It must be adapted to the size and organisation of each company.

GDPR#

The GDPR (General Data Protection Regulation) is the European regulation governing the processing of personal data. It rests on principles such as lawfulness, purpose limitation, data minimisation, storage limitation, security and transparency towards data subjects. It grants data subjects rights, notably the rights of access, rectification and objection, and requires processing to be documented. Its requirements apply in full to AI projects as soon as they process data about individuals.

Why it matters to executives. The GDPR does not prohibit AI, but it requires you to know what is done with personal data and why. For an executive, this is a matter of legal liability, of client trust and of the ability to respond to a request from a data subject.

Generic example. A firm wishes to use its clients' emails to train a response tool. Before any collection, it must define the purpose, check that it is compatible with the purpose for which the emails were received, and inform the data subjects.

Decision question. Is every processing operation involving personal data documented, justified and known to the data subjects?

• What to check: the record of processing activities, the legal basis and the purpose, the processors involved and the data subjects' rights that can be exercised for this processing.
• Who validates: the DPO, with the lawyer for interpretation (obligations must be checked with a lawyer).
• Risk to watch: misuse of data collected for another purpose, or a provider that retains data beyond what the contract provides for.

EU AI Act#

The EU AI Act is the European regulation on artificial intelligence. It organises obligations according to a risk-based approach: certain practices are prohibited, high-risk systems must meet stricter requirements, and others are subject to transparency obligations. It emphasises principles such as human oversight, traceability, data quality and the provision of information to users. It is being applied in stages, and its precise obligations must be checked with a lawyer for each case.

Why it matters to executives. The EU AI Act is an interpretive framework. It helps classify projects by their level of risk before asking how to put them into operation. It also requires the company to know which of the systems it uses are supplied by third parties, and what obligations then fall on it as a user.

Generic example. A company uses an application-screening tool supplied by a software vendor. Even though it did not develop this tool, it may have obligations as a user, particularly regarding oversight and informing the individuals concerned.

Decision question. Do we know, for each system, its risk category under the EU AI Act, and who bears the related obligations?

• What to check: the inventory of systems used or developed, the risk category assigned to each, the company's role (provider or user) and the associated obligations, checked with a lawyer.
• Who validates: the legal department, with the DPO and the head of information systems.
• Risk to watch: a classification carried out too lightly, which underestimates a sensitive use, or a third-party system whose obligations have been overlooked.

High-risk system#

A high-risk system, within the meaning of the EU AI Act, is an AI system whose use may cause significant harm to safety, to fundamental rights or to access to certain services, for example in recruitment, creditworthiness assessment or certain administrative decisions. The legislation lays down stricter requirements for these systems: risk management, data quality, technical documentation, traceability, human oversight and robustness. The precise list of cases concerned and the applicable obligations must be checked with a lawyer.

Why it matters to executives. High-risk status changes the expected level of preparation, the design time and internal responsibilities. An executive must be able to spot uses that could fall into this category, even when they seem innocuous at first.

Generic example. A department uses a system to prioritise loan applications. Even if the tool does not decide on its own, its ranking influences the human decision. A legal analysis is needed to determine whether this type of use falls within the high-risk category.

Decision question. Could any of our uses affect a person's access to a service, to a job or to an important decision, and who has examined it?

• What to check: the system's purposes, its actual influence on the decision, the data used and the existence of a compliance file.
• Who validates: the lawyer and the executive committee, on the basis of a documented opinion.
• Risk to watch: a use presented as a mere aid that in practice becomes the decision, without the stricter requirements having been examined.

Sovereign hosting#

Sovereign hosting refers to an arrangement of infrastructure and data that allows the company to retain control over where they are located, who accesses them and which laws they are subject to. It may involve hosting in a given territory, contractual clauses governing access, or models that can be run within the infrastructure of the company or of a trusted partner. The notion is not limited to geographical location: it also concerns dependence on a provider and the ability to take back control.

Why it matters to executives. The hosting choice affects confidentiality, compliance and the ability to change supplier. It is a trade-off between control, performance and cost, which should be settled explicitly rather than simply endured.

Generic example. A finance department wishes to process payroll data with an AI tool. It compares a solution hosted within the company's infrastructure, more controlled but more demanding to maintain, with an external solution whose contractual clauses and exposure to foreign legislation it checks.

Decision question. Where is our data stored and processed, who can access it, and how could we change supplier without rebuilding everything?

• What to check: the location of the data and of the processing, access by the provider's staff, the reversibility clauses and exposure to non-European legislation.
• Who validates: the CIO, the DPO and the legal department.
• Risk to watch: a technical and legal dependence on a single player, and access to sensitive data by unidentified third parties.

Measurement#

An AI project is judged by what it measures. Without an evaluation method, convincing demonstrations and deployment decisions rest on impressions. The notions in this part describe how to establish a baseline, how to compare results over time and how to move from testing to real use, without ever setting numerical thresholds, which would depend on each context.

Evaluation#

Evaluation is the process of measuring a system's quality against criteria defined in advance: accuracy, completeness, consistency, response time, compliance with rules, user satisfaction. It compares the system's results with a reference, which may be a validated human decision or a specialist's answer. A serious evaluation specifies the measurement method, the population tested and what counts as success. It must be repeated, because quality changes with the data, the models and the uses.

Why it matters to executives. Evaluation makes it possible to base a decision on measurements rather than on a favourable impression. A written protocol should be required before the results are seen, to prevent them from being interpreted after the fact.

Generic example. A team evaluates an invoice classification tool by comparing it with a classification already validated by accountants. It measures the errors on routine invoices and on unusual cases separately, then decides what action to take for each type of error.

Decision question. What method, what reference and what criteria did we set before looking at the results?

• What to check: the definition of the criteria, the comparison reference, the representativeness of the population tested and the separation between tuning data and test data.
• Who validates: the business owner for the definition of success, and an independent function for the method.
• Risk to watch: criteria chosen after the fact, which favour the system being evaluated.

Test set#

A test set is a collection of representative cases whose correct answer is known, reserved for measuring a system's quality. It must be distinct from the data used to train or tune the system, otherwise the result is artificially favourable. A good test set covers common cases, rare cases, ambiguous situations and errors already observed. It must itself be maintained, because an old set no longer reflects actual activity.

Why it matters to executives. The test set is an asset. It makes it possible to compare versions, to spot any regression after an update and to demonstrate what has been tested. An executive should know who builds it and whether it is accessible to the team developing the system.

Generic example. A team builds a set of contract cases whose correct answer has been established by a lawyer. Each new version of the system is run against this set before being deployed, and failures are added to the set.

Decision question. Is the test set independent of development, up to date and demanding enough to reveal real failures?

• What to check: separation from the training data, coverage of difficult cases, the date of the last update and the traceability of each correct answer.
• Who validates: the business owner, who knows the correct answers, with internal control.
• Risk to watch: a test set that is too easy or too close to the training data, which makes the system look better than it is.

Drift#

Drift refers to the gradual change in a system's behaviour, or in the quality of its results, because the data or the context changes. A distinction is often drawn between data drift (the inputs no longer resemble the original ones), concept drift (the relationship between inputs and correct answers changes) and performance drift (the results deteriorate). Drift can be slow and invisible if nobody measures the results over time.

Why it matters to executives. A system validated at a given moment does not remain validated indefinitely. You need to know who monitors quality after go-live, how often and against which indicators, because drift is precisely what does not show up in a demonstration.

Generic example. A tool worked well on the usual files. A change in the business brings new types of transactions. Quality declines quietly, until a manual check reveals recurring errors.

Decision question. Which indicators do we monitor continuously, and who reacts when they deviate from the baseline?

• What to check: the quality indicators tracked, regular comparison against the test set, the alerts configured and the retraining or withdrawal plan.
• Who validates: the system owner, with internal control.
• Risk to watch: silent degradation, all the more dangerous because it seems normal to users.

Latency#

Latency is the time elapsed between a request and the response it produces. For an AI system, it depends on the size of the model, the length of the inputs and outputs, the load on the service and the geographical distance of the processing. High latency is not a flaw in itself. It becomes a problem when it prevents the intended use, for example when a user is waiting for an answer in the middle of an exchange, or when an automated process falls behind.

Why it matters to executives. Latency influences the actual adoption of a tool. The speed observed in a demonstration does not predict the speed in production, which depends on load, integration and the volumes actually processed.

Generic example. An internal question-answering tool is fast during testing. In production, at peak times, users abandon their requests because the wait interrupts their work. The team then decides to use the tool only for tasks where a wait is acceptable.

Decision question. Is the response time measured under real conditions compatible with the moment when the user needs the answer?

• What to check: measurement of the response time under representative loads, the distinction between time to first response and time to complete response, and the system's behaviour during a peak.
• Who validates: the head of IT operations, with the business function that uses the tool.
• Risk to watch: a degraded user experience that pushes people to bypass the tool, and therefore to step outside the validated framework.

Proof of concept#

A proof of concept (often abbreviated to PoC) is a limited test designed to verify that a use case is technically feasible and that it produces a usable result within a narrow scope. It answers the question "is it feasible?", not the question "is it robust and cost-effective?". A well-run proof of concept defines its success criteria and its limits in advance. Without this, it becomes an impressive demonstration that proves nothing.

Why it matters to executives. The proof of concept is the executive's natural tool before investing on a large scale. It must be sized to answer a specific decision, not to produce a showcase. The risk is to mistake it for a project that is ready to be deployed.

Generic example. A team tests the classification of incoming requests within a narrow scope. The proof establishes that the system understands most requests, but reveals that requests written in another language are not handled correctly, which shapes the next stage of the project.

Decision question. Does the proof of concept answer a decision question, with written criteria, and does it set out what will happen next?

• What to check: the question asked, the success and failure criteria, the data used and its legal legitimacy, and the follow-up plan in the event of success or failure.
• Who validates: the business sponsor and the committee that arbitrates investments.
• Risk to watch: a proof of concept that expands without a formal decision, or whose results are presented as a given for deployment.

Scaling up#

Scaling up is the extension of a validated system to a wider scope: more users, data, processes, sites or types of request. It does not consist of multiplying licences. It requires adapting the architecture, the oversight, the training, the access rights, the maintenance and the control of usage costs. Many projects succeed in their demonstration and then struggle at this stage, for want of having anticipated these requirements.

Why it matters to executives. Scaling up is the phase in which the project becomes an organisational dependency. You need to decide who owns it, how teams are trained and which control framework applies as use becomes widespread.

Generic example. A summarisation tool validated in one team is to be rolled out across several departments. Each has different documents, its own rules and its own confidentiality requirements. Scaling up calls for an inventory of uses and for controls adapted to each one.

Decision question. Will what worked within a narrow scope hold up when use becomes widespread, and who will bear the burden?

• What to check: the technical capacity, the usage costs projected under several scenarios, the training of new users, the access rights and the incident management procedure.
• Who validates: the IT department, the business owner and the governance committee.
• Risk to watch: a roll-out that goes beyond the validated framework, with data or uses that had not been foreseen at the outset.

How to use this glossary in committee#

A glossary is only valuable if it changes the discussion. The following points suggest a simple method for using it during a project review or a provider's presentation.

• Start with the decision, not the technology. State the decision to be taken in one sentence: invest, continue, stop or extend. The useful notions are those that shed light on this decision; the others can wait.
• Ask for evidence in a logical order. First the data (origin, rights, representativeness), then the evaluation method, then the oversight and traceability mechanisms, and finally the operating costs and the exit conditions. This order helps avoid discussing a performance whose measurement conditions are unknown.
• Name an owner for each risk. Each decision question in this glossary indicates the type of validator expected. During the meeting, assign the subject to a specific person and note the date by which validation is expected.
• Keep a decision log. Record the uses accepted, the uses refused and the conditions set. This log serves as the basis for governance and for subsequent reviews, and it limits the risk of reopening the same debates each time the team changes.
• Revisit the entries at each milestone. A notion that was not central at launch can become decisive at the scaling-up stage. Reread the relevant entries at each stage.

Finally, bear in mind that a provider can be both honest and incomplete. A clear presentation on performance does not exempt you from asking for evidence on the data, on oversight and on the exit conditions of the contract.

Glossary#

This summary lists the notions covered in the entries, with a one-line definition and the part of the text in which each one is developed. It is followed by additional terms that are frequently used in committee.

Additional terms:

• Embedding. A representation of a text as a series of numbers, which makes it possible to compare meanings. It is a common building block of search within a knowledge base.
• Tokenisation. Splitting a text into tokens before processing. The same text may be split differently depending on the model used.
• Temperature. A parameter that sets the degree of randomness in the responses. A lower value makes the responses more stable, without making them any more true.
• Controller and processor. The first determines the purposes and means of a processing of personal data; the second carries it out on the first's behalf. This role determines the obligations of each party.
• Audit log. A time-stamped record of the actions of a system or a user. It must be protected, as it may itself contain sensitive data.
• Ground truth. A correct answer established by a reliable source and used as a reference during evaluation. The quality of this reference limits that of the evaluation.
• Shadow mode. Running a system in parallel with an existing process, with no effect on decisions, in order to compare its results.
• User feedback. A user's indication that a response is correct or wrong. It is used to improve the system, provided that it is sorted and qualified.
• Integration. Connecting the system to the company's existing tools. This is often where security risks and hidden costs are concentrated.
• Cloud. Remotely rented IT infrastructure on which data and processing are hosted by a provider. Its use raises questions of location and control.
• Open model and proprietary model. The first has its workings published and can be installed by the company itself; the second is operated by a vendor that retains control over it. This choice determines sovereignty and the degree of dependence.

Printable checklist#

Print this list and tick it off at each project review. It replaces neither the advice of a lawyer nor that of a security expert.

Before launch#

• The decision to be taken is stated in one sentence, with its named owner.
• The use case has a success criterion written before any testing.
• The origin of the data used is known, and its usage rights have been checked.
• The personal data involved is listed, with its purpose and its legal basis.
• The system has been classified under the EU AI Act, with a documented legal opinion.
• The location of the data and of the processing has been chosen explicitly.

During testing#

• The test set is kept separate from the training data and covers difficult cases.
• The evaluation method was set before the results were examined.
• The results are broken down by sub-population or by type of case.
• Errors are categorised, and their severity is assessed by the business.
• Answers without a source and questions with no answer in the documents have been tested.
• The system has been confronted with degraded or unexpected data.

Before going live#

• Human oversight is assigned to a named person, with the power to stop the system and defined escalation thresholds.
• Traceability logs are active and protected.
• The explanations provided to users and to the individuals concerned have been checked.
• Access rights are limited to actual need, including for automated actions.
• The documentation enables another team to take over maintenance.
• Prohibited uses and cases never to be entrusted to the system are written down and circulated.

In operation#

• Quality indicators are tracked over time, with a defined review frequency.
• Drift is monitored, and the alert threshold is known to the system owner.
• Usage cost is tracked against actual volumes, not against the initial assumptions.
• Incidents are logged, analysed and reported to the governance committee.
• Knowledge bases and validated prompts are kept up to date and versioned.
• A procedure for withdrawing the system is documented and tested at regular intervals.

Frequently asked questions#

Do you need to be an engineer to decide on an AI project?#

No. You need to understand the notions of data, risk and control, and to know how to ask for evidence. Technical choices remain in the hands of specialists, but framing the uses and validating them falls to the business and to management.

Should a provider promising a fast and reliable result inspire confidence?#

Not on its own. A claimed result without an evaluation method, a test set or a description of limits provides no usable information. Always ask how performance is measured and under what conditions it was obtained.

What is the difference between a co-pilot and an AI agent?#

The co-pilot supports a person who retains the decision and the action. The AI agent plans and executes steps, using tools and access rights. The more the agent can act alone, the more precise the controls, the logs and the authorisation limits must be.

Does the GDPR prohibit using client data with an AI tool?#

It does not prohibit such use, but it closely governs the purpose, the legal basis, the information given to individuals and the role of processors. Processing must be documented before it begins. These rules must be checked with the DPO and a lawyer for each case.

Should we wait for regulation to stabilise before launching a project?#

It is more prudent to classify uses by their level of risk and to start with those that involve little at stake for individuals. The precise obligations must be checked with a lawyer, and an inventory of the systems in use provides a useful foundation in all cases.

Conclusion#

This glossary does not make artificial intelligence simple, nor does it claim to. Rather, it shows that the notions that matter to an executive are not always the most technical ones. The quality of the training data, the traceability of a decision, human oversight or the exit conditions of a contract often carry more weight than the sophistication of the model. Vocabulary serves to frame precise questions, to identify who must answer them and to bring risks into the discussion before they turn into incidents.

It is also worth remembering that these notions overlap. A poorly maintained knowledge base feeds wrong answers despite a good reading window, poorly pseudonymised personal data complicates compliance, and an evaluation without an independent test set says nothing about drift. Teams that proceed methodically tend to read these notions as a coherent system, and not as a list to be memorised.

Finally, this text replaces neither a lawyer, nor an auditor, nor a security expert. It does, however, enable you to talk to them in a common language, and to know what to ask them, when and in what order.