Automating with AI without losing control

AI adoption is accelerating in French companies. According to the France Num 2026 Barometer, based on 9,655 very small, small and medium-sized businesses:

These figures reveal an important distinction: using AI does not necessarily mean having built it into your business processes.

Asking an assistant to draft an email or summarise a document is occasional use. Connecting an AI to a CRM, a management system or a database to run a sequence of actions is a change of scale.

In the second case, AI is no longer just an individual productivity tool. It becomes a component of how the company runs day to day. That is precisely the point where questions of control, security and accountability really start to matter.

The right question is no longer just: « How much time will we save? »

It becomes: « How do we check that the system works properly, and what happens when it gets something wrong? »

A company can lose control of how it uses AI before it has even officially launched an automation project.

This is the phenomenon of shadow AI: the use of artificial intelligence tools outside the framework defined by the organisation.

The Greenworking x Ipsos bva Observatory, published in September 2026 and based on 1,100 private-sector employees, highlights this gap:

In other words, individual practices are moving faster than the frameworks meant to govern them.

An employee might, for example, paste sales information into an external assistant, use an AI service to process a confidential document, or connect an extension to an internal tool without assessing the permissions granted.

These practices do not necessarily reflect bad intent. They often meet a concrete need: getting things done faster with the tools at hand. The risk comes from the lack of a shared framework.

Without visibility on the tools being used, the data being shared and the decisions being delegated, management can hardly assess the risks involved or guarantee business continuity.

Reliable automation does not depend only on the quality of the AI model being used.

It depends above all on its architecture, the permissions granted, the validation mechanisms and the company's ability to supervise how it runs. Five principles help build that framework.

Before connecting an AI to your company's tools, you need to understand how the existing process works.

Who triggers the operation? What data is used? What decisions are made? Who validates the result? And what happens when a situation falls outside the usual frame?

Take a company that wants to automate the handling of its sales enquiries. The process can include several steps: receiving the form, qualifying the lead, creating a record in the CRM, preparing a reply and assigning it to a salesperson.

Not all of these steps carry the same level of risk. Drafting a reply can easily be automated. Granting an exceptional discount or committing to contractual terms, on the other hand, may require validation.

Mapping the process lets you separate the operations that can run automatically from those that must stay supervised. It also helps surface the automations already being used informally inside the company.

A poorly defined process does not become more reliable because you add artificial intelligence to it.

The security of an automated system depends largely on what it is allowed to do.

An AI in charge of classifying customer requests does not necessarily need to be able to delete CRM records, change prices or access all of the company's financial documents.

This is the principle of least privilege: each component only has the access it needs for its job. In a well-designed architecture, that means in particular:

Depending on the project's constraints, the choice between an external AI service, an open-source model hosted on infrastructure you control, or a hybrid architecture can also become decisive.

The goal is not necessarily to host everything in-house. It is to choose an architecture that fits your requirements for confidentiality, performance and independence.

Not every operation needs systematic human approval. If every step has to be validated manually, automation quickly loses much of its value. Conversely, letting a system act freely on sensitive operations can introduce disproportionate risks.

Control therefore has to sit in the right place.

A system can, for example, analyse an incoming request, extract the information it needs, prepare a reply and suggest an action in a business application. Human intervention becomes necessary when the result crosses a defined threshold: an unusual amount, inconsistent information, an ambiguous situation or a decision that commits the company.

This logic relies on a clear separation between three levels:

The level of autonomy should depend on the possible consequences of an error, not only on the technical capabilities of the model.

Human validation is only worth something if the person has the information and the authority needed to understand, challenge or change the result.

An automation that runs without producing usable information quickly becomes hard to manage. To stay in control of a system, you need to be able to understand what it did, when, and with what result.

That means, among other things, appropriate logging of operations: actions triggered, errors encountered, validations performed and human interventions.

Metrics should also be defined before deployment. Depending on the process, they can include:

These measurements let you compare how things run before and after automation.

An AI can give the impression of speeding up work while creating new verification tasks. The 2026 Ipsos-Greenworking study notes that 57% of users surveyed say they have to spend more time checking the results produced by AI.

Time saved is therefore not enough to measure the value created.

A successful automation must improve a measurable business outcome, not just increase the number of actions executed.

Technology lock-in is a less visible risk than an immediate error. A company can gradually hand several essential processes over to tools it does not fully control.

The problem shows up when it wants to change its architecture, switch providers, stop an automation or get its data back.

A reversible architecture has to anticipate these situations from the design stage. That means documenting processes, planning data export mechanisms, keeping control of integrations between applications and avoiding, where possible, unnecessary dependence on a single provider.

For critical functions, it may also be necessary to keep a fallback procedure so operations can continue when a service becomes unavailable.

That does not mean a migration will always be simple or free. Reversibility has to be prepared and tested.

The company must be able to evolve its tools without rebuilding the way it operates from scratch. That is a fundamental difference between adopting a technology and building a lasting system.

Picture an SME receiving several dozen sales enquiries every week.

Without automation, someone has to open each request, check the information, create a customer record, qualify the need and prepare a reply.

A workflow that includes AI could take on a large part of this work. When a form comes in, the system checks the required fields, identifies the type of request, extracts the useful information and prepares a draft reply. The lead record can then be created in the CRM according to predefined rules.

But several limits stay in place.

The AI can only access the data it needs. It can neither freely change prices nor make unauthorised commercial commitments. Ambiguous requests are passed on to a manager and every action taken is logged.

If the model malfunctions, the automated processing can be paused without making the CRM unusable.

This logic echoes that of a good automated workflow: speeding up repetitive tasks without sacrificing quality or the ability to decide.

Keeping human control is not only an organisational preference. European law already sets certain requirements for automated processing, depending on its nature and consequences.

Article 14 of the European AI regulation (AI Act) provides for human oversight mechanisms for AI systems classified as high-risk.

Depending on the risks and context of use, these systems must in particular make it possible to monitor how they operate, interpret their outputs, detect anomalies and intervene on their decisions or operation.

The obligation does not apply indiscriminately to every automation used by companies. It targets systems that fall within the relevant regulatory categories, including certain uses related to recruitment, education, critical infrastructure or access to essential services.

The application timeline was also amended in 2026:

These dates appear in the European Commission's official timeline.

In addition, Article 22 of the GDPR already governs certain decisions based solely on automated processing when they produce legal effects or significantly affect a person. Specific exceptions and safeguards exist, notably regarding human intervention. The CNIL, France's data protection authority, details these rights and how they apply.

An SME automating ordinary administrative tasks is therefore not automatically subject to every requirement that applies to high-risk AI systems. That does not exempt it from its obligations on data protection, security and accountability.

Beyond the strict legal framework, the principle still holds: a system should keep a level of oversight proportionate to the consequences of its actions.

At Movira, we stand for an approach in which technology should make teams more autonomous, not lock them into tools they no longer understand.

That starts with choosing the right problem to solve. An AI model is not always needed to improve a process. An integration between two applications, a better-structured database or an automation based on explicit rules can sometimes be a better fit.

On the Chef's Origin project, for example, we built an internal software tool that centralises production, orders and sales management, with real-time operational tracking.

It is not an example of autonomous AI, but of an essential architectural principle: centralise information and make operations visible before trying to automate further.

The same standard applies to systems that include AI agents. The goal is not to multiply tools or delegate as many decisions as possible. It is to design a coherent architecture in which automations fit into existing business practices.

Our AI & Workflows approach is built on that logic: structured workflows, controlled access, measurable results and a level of technological independence suited to each organisation's needs.

The fear of losing control with artificial intelligence is not irrational. It becomes a useful signal when it pushes a company to look at how its tools access data, make decisions and interact with its processes.

The real problem is not automation. It is the lack of visibility on what has been automated.

Mapping processes, limiting permissions, planning appropriate oversight, measuring results and preserving reversibility make it possible to build more reliable and more lasting systems.

A successful automation should not only help a company move faster. It should also give it more control over how it runs.

Want to automate a process without losing your grip on your tools, your data or your decisions? Let's talk about your workflow.