Generative AI in the enterprise: where to start, from Dakar.

Generative AI has a rare merit: it has put executive leadership, the IT department and field teams in front of the same screen. Everyone has tested it, everyone has been surprised, everyone has seen the tool get things wrong with aplomb. The wrong reflex would be to conclude that you need “an AI strategy” before having run anything at all. The right reflex is to choose a modest first case, put it in the hands of a few people, and measure what it changes in their day.

What generative AI really changes

These models produce text from an instruction and a context. That capability, simple as it seems, touches five everyday actions in the enterprise.

• Writing. A reply letter, a briefing note, minutes, the first draft of a specification. The model does not replace the author; it spares them the blank page and gives them back the time to proofread.
• Summarising. Summarising a credit file, a contract, a mission report, an e-mail thread several weeks long. The value is immediate for anyone who has to decide quickly on long documents.
• Searching documents. Asking a question in plain language and getting an answer backed by internal documentation, with the source cited. The most underestimated case, because it does not shine in demonstrations and changes everything in daily work.
• Business assistants. An assistant that knows the procedures, the prices, the rules of a cash desk or an after-sales department, and answers in the context of the person asking.
• Code. Generating, reviewing, explaining existing programs, including the custom developments of an ERP that nobody can read any more. A real gain, provided review and testing are kept.

What it does not change

A generative model knows nothing about your company until it is given your documents, your data and your rules. It does not reason from a truth, it produces the most plausible text. It can therefore assert a clause that does not exist or an outdated price, in the same tone as when it is right. It replaces neither the customer master, nor the chart of accounts, nor the approval workflow. It does not clean data that is not clean. And it does not decide in place of someone who has to answer for the decision. These are not growing pains: they are the nature of the tool.

The right first cases

A good first case is frequent, easy to verify, and keeps a person in the loop. We see four come up almost everywhere, from the public sector to banking to distribution.

The assistant on internal documentation

Procedures, memos, ERP manuals, product terms. These documents exist, scattered between a file server, a mailbox and a few heads. An assistant that answers by citing the exact passage saves time for newcomers, for branches far from head office and for support functions. It also reveals, without mercy, contradictory or outdated documents. An ideal first case: a wrong answer is quickly spotted and does not commit the company towards the outside world.

Handling letters and complaints

Reading an incoming letter, identifying what it is about, extracting the useful elements, proposing a draft reply and routing it to the right department. The volume is there, the action is repetitive, and the person who approves keeps control over what goes out. For a government body, an insurance company or a customer service department, this is often the most profitable case in time given back to the teams.

Customer service support in the languages of the field

Customers write and speak in French, in Wolof, in other national languages, sometimes mixing all three in a single voice message. A well-chosen model understands these messages, summarises them for the adviser and helps them reply in the customer’s language. This case is specific to our context and is hard to design remotely: it has to be tested with real messages, real accents, and you have to accept that some languages are still less well served than others.

Document extraction

Invoices, delivery notes, identity documents, bills of lading, forms filled in by hand. Generative AI complements classic extraction techniques, especially on documents whose layout varies. The result enters the ERP or the CRM after verification, and the gap between what was read and what was corrected gives an honest measure of quality. We discuss it in our reading of the AI use cases that really create value.

The wrong first cases

The most frequent, and the most dangerous, consists in automating a decision without control: granting or refusing a loan, closing a complaint, replying to a customer in the company’s name without review. The model will do it with confidence, including when it is wrong, and nobody will be able to explain why. As soon as the decision touches a person, it also falls under Law No. 2008-12 and the scrutiny of the CDP: declared purpose, information of the persons concerned, possibility to contest. Another bad start is the “general-purpose” assistant open to the whole company, with no scope and no reference documents. It amuses for two weeks then fades away, because it knows nothing precise.

The first use case is not chosen to impress a committee. It is chosen to give time back to a specific team, on an action it performs every day.

The non-negotiable conditions

Clean data and documents

A documentation assistant is worth what its documents are worth. If three versions of a procedure coexist, it will cite one at random. The first workstream is therefore often a sort: which documents are authoritative, who keeps them up to date, where they live. The same logic applies to ERP and CRM data, the subject of our Data & Analytics offering.

The choice of model and hosting

This is the most structuring decision, and it is rarely taken at the right level. Where does the data go: a model called at a foreign provider receives your documents, and if they contain personal data, that transfer falls under Law No. 2008-12 and the formalities with the CDP. What sovereignty: some cases justify an open model hosted in your cloud or on your servers, others can live with an online service. What cost in foreign currency: a service billed per use, in dollars or euros, is paid on every request and follows the variations of the CFA franc against those currencies, which argues for smaller, well-targeted models when they suffice. There is no good general answer; there is one answer per use case, written down. Our Cloud and IT security & risk offerings handle these trade-offs together.

Human supervision

Someone reviews, corrects, and their corrections improve the system. This is not a temporary safety net to be removed once the tool is “mature”. It is the normal operating mode of generative AI in the enterprise. The useful question is not “can we remove the human?” but “at which point in the process is their eye worth the most?”.

Measurement

Time saved per letter handled, share of answers judged useful, correction rate on extractions, response time to the customer. These indicators are defined before starting, with the team concerned, and read every week during the pilot. Without them, the project lives on enthusiasm and dies with it.

The advantage of designing in Dakar

Our conviction, forged on our projects: a generative AI use case is designed next to its users, not thousands of kilometres away. The teams who will handle the letters or query the documentation are in Dakar, in Thiès, in Saint-Louis, in branches where the connection is not the head office’s. Testing with them every week, in their language and on their documents, changes the quality of the result. The skills exist here: profiles who know the models, enterprise data and the field at the same time. Design costs make it possible to iterate more often, and therefore to learn faster. And a case designed from Dakar takes into account from the outset connectivity, languages, the CDP framework and cost in foreign currency, instead of discovering them in production. That is the point of our data & AI teams in Dakar and of our AI & automation offering.

And the major platforms?

SAP embeds generative AI in its products, with Joule and SAP Business AI; Salesforce does the same with Einstein and Agentforce. These capabilities live where the data and processes already are, with the platform’s security and access rights. They also have their conditions, starting with the location of the services and the billing model, to be examined with the same care as for any other model. Our position is simple: when the use case lives in SAP or in Salesforce, we look first at what the platform offers; when it lives between systems or on documents that are not in them, we build with the appropriate tools. Two platforms, one team.

Where to start, in practice

1. Choose a team and an action. A volunteer team, a frequent action, one person who answers for the result. Not a committee, not a program.
2. Gather and sort the documents for that action. What the assistant is allowed to read, what is authoritative, what is personal and must be protected.
3. Decide on the model and hosting for this case. Personal data, sovereignty, cost in foreign currency, users’ connectivity. Write down the decision and its reasons.
4. Build a pilot in a few weeks, with the users. Put it in their hands early, improve it from their corrections.
5. Measure, then decide. Extend, correct or stop, on the indicators defined at the start. A pilot stopped in time is a success of method.
6. Set governance before the second case. Who authorises a new case, who checks compliance, how people are informed, how drift is monitored over time.

Generative AI does not require a revolution to get started. It requires a well-chosen first case, clean documents, hosting decided with full knowledge of the facts, and people who review. That is what we know how to do from Dakar, for the sub-region.