Framing AI in your business processes: where to start

The essentials in brief

Useful AI doesn't start with choosing a tool: it starts with framing your processes. Before automating anything, you need to map what already exists, identify use cases with genuine value, and assess the risks — including regulatory ones. Since 02/02/2025, the AI Act has required every AI deployer to ensure the AI literacy of its teams (art. 4). The five-step method detailed in this article gives you an operational starting point.

Why "buying an AI tool" so often fails

Most corporate AI projects don't stumble on the technology. They stumble on a lack of preparation: a generic tool deployed onto a poorly mapped process, without team ownership, without data governance — and whose outputs no one really understands.

This pattern is widespread. Unframed AI usage spreads through organisations, driven by individual initiatives (what is known as "shadow AI"): staff use consumer tools for sensitive tasks, sometimes with confidential data, without management being aware of it. The risk lies not in AI itself — it lies in the absence of a framework.

The other trap is the generic tool sold as a universal answer. Generative AI can draft an email or summarise a document. It doesn't replace an application designed for your business rules, your data flows and your regulatory constraints. The difference between the two becomes visible at the first edge case — and is often costly to correct.

AI literacy, now an obligation (AI Act, article 4)

What the AI Act says, and for whom

The European regulation on artificial intelligence (EU 2024/1689, known as the "AI Act") distinguishes two categories of actor: providers (those who develop AI systems) and deployers (those who use these systems in their activities). Companies and public bodies that integrate AI tools into their processes — even third-party tools — are deployers and fall directly within the scope of article 4.

That article requires every deployer to take "appropriate measures to ensure that staff who use or oversee AI systems have a sufficient level of AI literacy". In practice: your teams must understand what they are using, its limits, and the point at which human oversight is needed.

This is not a standardised obligation of result — the expected literacy is proportionate to the type of system deployed and the associated level of risk. But ignoring article 4 exposes the organisation to penalties, and the absence of framing makes any compliance very difficult to demonstrate. For questions of legal interpretation, we refer you to the competent authorities (CNIL, DGE, AMF depending on the sector).

The timeline to know

Source: EU Regulation 2024/1689; entreprises.gouv.fr / Direction générale des Entreprises (DGE).

The literacy obligation (art. 4) is therefore already in force. Penalties, however, become fully operational from August 2026 — which leaves a window for action, but not an indefinite one.

The five steps to frame AI in your processes

1. Map your processes and actual usage (including shadow AI)

Before deciding what to automate, you need to know what already exists. This involves two levels: formal process mapping (those that are documented and managed) and the detection of informal usage — the AI tools your teams are already using, sometimes without your knowledge. This inventory is often revealing: it shows where AI is already present, what kind of data it touches, and what latent risks have built up.

2. Identify use cases with genuine value (and set aside the gimmicks)

Not every process benefits from AI assistance. A relevant use case meets at least one of these criteria: it involves large volumes of data that humans process slowly, it includes repetitive tasks with a high cognitive load, or it requires the rapid synthesis of heterogeneous information. Conversely, a process that calls for fine contextual judgement, a direct relationship of trust or a very specific business rule is not necessarily a good candidate — or it calls for a bespoke approach rather than a generic tool.

3. Assess risks, data and compliance (GDPR, AI Act risk level)

Each identified use case must be assessed along three axes: the AI Act risk level (Annex III of the regulation lists high-risk cases: HR, credit, justice, education, critical infrastructure, etc.), GDPR compliance (data quality, legal basis for processing, individuals' rights), and data sovereignty (where is the data processed and stored?). The CNIL publishes specific recommendations on AI and personal data — they are a practical reference for this step.

4. Build AI understanding among decision-makers using your real cases

The AI literacy the AI Act expects isn't acquired through a generic module. What builds operational understanding is a shared reading of the use cases you are genuinely considering: how the system works, what it cannot do, how to control its outputs. This understanding should target decision-makers and managers first — those who will approve the deployments and take responsibility for them.

That is what we do during our consulting and audit engagements: we start from your context, not from pre-written content.

5. Decide: build the bespoke business tool, or not

Once the framing is done, the decision is much clearer. Two main scenarios: either an existing tool (generic or sector-specific) covers the need satisfactorily, with configuration adjustments — in which case we say so; or the use case is specific, strategic or tied to sensitive data enough to justify a bespoke business application, augmented by AI, designed for your rules and your flows. That is where bespoke development comes into its own.

Generic AI or business-specific AI?

A generative AI assistant answers questions, rephrases text, summarises documents. That is useful — and it is limited. Its logic is that of a universal tool: it doesn't know your sector, your business rules, your historical data or your regulatory constraints. It produces plausible results, not necessarily reliable ones for critical professional use.

A bespoke business application augmented by AI works differently: the AI is embedded within a controlled process, on data you control, with validation and oversight rules that you have defined. It can automate a complex document-processing task, enrich a decision using your historical data, or detect an anomaly in a business flow — reliably and traceably.

The distinction between the two is not theoretical: it determines whether your AI project will be a lasting productivity gain or a prototype that is hard to maintain. Our article on the limits of vibe coding and the AI prototype explores this point in detail.

For AI automation systems embedded in your processes, see also our Automation & AI service.

The particular case of public bodies

Local and regional authorities are AI deployers like any other under the AI Act — sometimes more exposed, because they handle people's data in high-stakes contexts (social services, education, town planning, security). The AI literacy obligation (art. 4) applies to them as soon as they use AI systems, whether developed in-house or integrated through service providers.

According to the Observatoire Data Publica (November 2024), around 36% of public bodies are already experimenting with AI and ~15% plan to do so. This adoption often progresses through pilot projects — which makes framing all the more necessary: experimenting without governance means creating precedents that are hard to control afterwards.

Public bodies face specific constraints: public procurement, reinforced GDPR requirements on citizens' data, digital sovereignty questions, and requirements to trace decisions. Our article The AI Act and public bodies details these issues and the steps towards compliance.