An employee pastes a contract into a public AI assistant. A team automates refunds with an agent. A supplier discreetly adds a generative function to a software already deployed. A scoring model changes version without new validation.
These four events fall within AI governance. None will be solved by a general charter alone.
The challenge is to transform principles — fairness, security, human control, sovereignty — into verifiable decisions. Who authorizes? Who operates it? What threshold triggers a stop? What evidence can be shown to a customer, regulator or data subject?
1. Key figures: adoption is advancing faster than operational control
Eurostat estimates that 20% of EU enterprises with at least ten employees used AI technology in 2025, 6.5 points higher than in 2024. The rate was 17% for small enterprises, 30.36% for medium-sized enterprises and 55.03% for large enterprises. Governance no longer concerns a few laboratories.
In France, INSEE measured 10% of companies using AI in 2024: 9% of small, 15% of medium-sized and 33% of large enterprises. Of the users, 69% used commercially available software. This finding matters. A company may be responsible for a use without having developed the model or mastered its training.
France Num observed in 2025 that 26% of microbusinesses and SMEs used AI: 22% for generative AI, 14% for chatbots, but only 5% for task automation and 5% for data analysis. The gap between individual use and operational integration calls for two regimes: simple rules for assistants, and reinforced controls for systems that act.
Risk signals are increasing in parallel. Stanford's AI Index 2026 recorded 362 AI-related incidents in 2025, up from 233 in 2024. Its transparency index for foundation models fell from an average score of 58 out of 100 in 2024 to 40 in 2025. Companies therefore need to ask for more evidence at the very moment when capabilities are becoming more deeply integrated.
Agent security remains difficult. In an evaluation of NIST published in 2025, agent-hijacking attacks were successful in 57% of cases with a single attempt and 80% after 25 attempts according to the protocol tested. A protection that blocks nine out of ten formulations can fail when an attacker can start over.
2. The control plan: eight linked registers
Governance becomes practical when it is organised around eight registers. They can start in a simple tool. Their value comes from their consistency and updating.
2.1. The system register
It lists purchased products, models, automations, internal assistants, experiments and AI functions integrated with third-party software. Each entry has a business owner and a technical owner.
At a minimum, the registry answers these questions:
- What is the purpose of the system?
- Which people or operations does it affect?
- What data does it receive and produce?
- Which model or supplier does it use?
- In which countries are data processed?
- What actions can it trigger?
- What level of human supervision applies?
- Which evaluations and versions are active?
- What contract, what retention period and what cessation procedure?
It must cover shadow AI without trying to punish every experiment. A rapid reporting channel, accompanied by authorised solutions, obtains more visibility than a ban that cannot be enforced.
2.2. The risk register
Each system is classified according to its impact, not technological enthusiasm. A simple matrix combines the severity of an error, probability, volume, autonomy, vulnerability of people and difficulty of detection.
Logiks recommends four internal levels.
| Level | Example | Minimum control |
|---|---|---|
| Assisted | drafting an internal draft | rules of use, confidentiality, verification |
| Recommended | commercial or legal recommendation | sources, evaluation, documented human review |
| Decision making | score influencing access or priority | independent validation, recourse, bias monitoring |
| Autonomous | external or financial action | minimum permissions, confirmation, ceilings, emergency stop |
This internal classification does not replace the legal categories of the AI Act. It guides operations on a daily basis and can be more stringent when the context requires it.
2.3. The data register
Sources, purposes, legal bases, sensitive categories, durations, recipients, transfers, quality and rights are documented. The data used to evaluate the system are distinguished from those used to train or operate it.
The CNIL stresses the determination of the legal regime, the definition of a purpose, the qualification of responsibilities, the legal basis, testing and security. This work should not begin the day before deployment. A choice of architecture — logging conversations, reusing entries, hosting outside the EU — can make late correction expensive.
2.4. The register of models and suppliers
For each model, the company maintains the version, usage conditions, region, subcontractors, known limitations, internal results, change dates and replacement plan. Model cards are not enough.
Due diligence includes data used, intellectual property, security, incident notification, availability commitments, retention, audit, export and termination of contract. When information is not provided, it is noted as "unknown", not assumed to be favourable.
2.5. The register of evaluations
It links each version to a set of tests, thresholds and a decision to start production. Metrics cover quality, affected groups, robustness, safety, latency and cost.
The tests are proportionate to the use. An advertising variant generator does not require the same level of proof as a recruitment system. But every system has a definition of failure and an owner able to intervene.
2.6. The access and action register
It describes who can use the system, read what data, call what tools and validate what actions. Permissions are attached to the identity of the user and the service. They are never granted because a model requests it in its text.
An action is decomposed: propose, prepare, simulate, execute, cancel. An agent can prepare a refund without being able to send it. This granularity reduces the impact radius of an error or injection.
2.7. Incident log
Critical errors, leaks, discriminations, circumventions, rights violations and unexpected actions follow a common process: detection, containment, analysis, notification, correction and feedback.
Weak signals matter. Twenty similar manual corrections may report an incident before damage is reported. Governance therefore links user feedback to risk management.
2.8. The register of decisions
It keeps the arbitrations: why this supplier, why this threshold, why an exception, who approved it and until when. This brief avoids reopening the same debate and shows that the decision was taken with the available information.
Governance without dated decisions becomes a collection of documents. A decision without evidence becomes an opinion.
3. AI Act: status as at 13 July 2026
The European Artificial Intelligence Regulation, Regulation (EU) 2024/1689, follows a gradual application. A distinction must be made between the published text, the obligations already applicable and the amendments still being finalized.
Since 2 February 2025, the prohibitions concerning certain AI practices and the AI literacy provisions, have applied. Since 2 August 2025, the governance rules and obligations relating to general-purpose AI models have begun to apply, with the provisions provided for in the Regulation.
The initial schedule provided for the general application of the majority of the provisions on 2 August 2026, followed by certain obligations relating to high-risk systems integrated into regulated products on 2 August 2027.
However, the European Commission notes that a provisional political agreement was reached on 7 May 2026 on targeted amendments. According to its regulatory page as of the date of this guide. In particular, the agreement provides for postponing the rules on certain high-risk systems: 2 December 2027 for Annex III systems and 2 August 2028 for those integrated into regulated products. Until the legislative procedure and the corresponding publication have been completed, a prudent organisation does not treat these dates as a confirmed exemption.
There are three practical consequences.
First, the obligation to develop a sufficient level of AI literacy is already an operational subject. Annual generic training is not necessarily enough. The skills must correspond to the systems, usage contexts and individuals involved.
Second, the company must qualify its role as a supplier, deployer, importer, distributor or manufacturer of a product. A substantial integration or modification may change this legal status. The contract does not decide the qualification alone.
Thirdly, waiting for the final implementing act would be risky. Inventory, risk management, documentation, data quality, logs, human control and post-deployment monitoring take time. These capabilities are useful even when a system is ultimately not high risk.
This guide does not replace a legal analysis of the specific case. It provides the evidence system that makes this analysis possible.
4. Security: design for partial failure
Conventional applications execute a code written in advance. Generative systems interpret instructions, context and sometimes external content. This flexibility creates new attack surfaces.
4.1. Treat content as unreliable
An e-mail, web page or PDF may contain instructions to divert the agent. The recovered text must never change the rules of the system or acquire permissions. Instructions, data and tools remain technically separate.
4.2. Reduce permissions
Each agent uses its own identity and temporary rights. Read access is separated from writing. Amounts, volumes, target areas and frequencies have ceilings. Irreversible operations require confirmation outside the model-controlled channel.
4.3. Validate inputs and outputs
Files are analysed, limited formats and secrets detected. Tool calls follow a strict schema. A model output never becomes directly SQL, shell code or active HTML without validation and isolation.
4.4. Constrain execution
The generated code runs in a disposable environment, without default network, with time, memory and storage quotas. The agent does not share the secrets of the application. Unexpected behaviour remains contained.
4.5. Test adversarially
Red teams simulate injection, exfiltration, policy circumvention, tool abuse, repeat attack and collusion between content. Tests are re-executed with each model change, prompt, tool or source. A result obtained on a version does not apply to the next version.
4.6. Prepare for shutdown
A Kill Switch disables a tool, agent or supplier without stopping any business. The teams know the manual fallback mode. Restoration and revocation of secrets are exercised, not only documented.
The OWASP Top 10 for Agentic Applications, published with the input of more than 100 experts, is a useful framework for structuring these scenarios. The NIST complements this approach with its AI Risk Management Framework and its work on agent security.
5. Human oversight: a function, not a button
Adding "Valider" to an interface does not create effective human control. The person must have the time, information, competence and authority to challenge the output.
Good control meets five conditions:
- The user knows what the system has done;
- they see the relevant evidence and uncertainties;
- it may correct or refuse without undue penalty;
- its action is recorded and analysed;
- The organisation does not set a volume that makes the verification fictitious.
Automation can shift the risk to humans. If an analyst has to read 300 decisions per hour, validation becomes a ritual. The metric should therefore not be "percentage with human in the loop", but error detection rate, available time and actual effect of the intervention.
6. AI literacy: train by level of responsibility
Not all employees need the same curriculum. Logiks distinguishes four levels.
User. Understand boundaries, protect data, verify results, cite usage when necessary and report an incident.
Professor. Define purpose, critical errors, human control, thresholds and expected results.
Constructor. Controls data, assessments, security, versioning, observability and documentation.
Controller. Know how to audit evidence, challenge metrics, qualify a legal role and stop a system.
Each course ends with an exercise related to the position. On the procurement side: compare two supplier clauses. For a developer: block an indirect injection. For a manager: decide on a deployment from an evaluation report.
The training is linked to the registry. A person accesses a sensitive system after completing the corresponding module and then renews that training after a major change.
7. Sovereignty: measure the ability to decide and exit
Sovereignty is not synonymous with hosting in France. It concerns the ability to control data, operation, keys, suppliers, components and continuity.
A decision grid may cover seven axes.
Jurisdiction. Which entities contract, administer and subcontract? What rights can apply?
Location. Where are storage, backups, inference, logs and support located?
Technology. Can models, libraries, accelerators and formats be replaced?
Data. Can the company export sources, embeddings, annotations, traces and tests in a usable format?
Operations. Who has the skills to diagnose, restore and evolve?
Economy. What price or volume variation would make service unsustainable?
Release. How many days does it take to migrate, from a verified backup?
A mastery level and proof are assigned to each axis. A "sovereign cloud" promise without clause, architecture or exercise does not get a point.
The choice can be differentiated. Support for public writing may use an external service. A body of strategic research may require a dedicated environment. Critical functions have a fallback path and manual mode.
8. Supplier due diligence: twenty questions that matter
Selection should not be limited to performance. The following are the structuring questions:
- Which entity provides the service and which subcontractors are involved?
- Where are the data stored, processed and saved?
- Are inputs and outputs used to train or improve service?
- What retention period applies by default and after termination?
- Who controls encryption keys?
- Which logs are accessible to the customer?
- How are incidents detected and reported?
- Which certifications actually cover the service used?
- What version of the model is active and how are the changes announced?
- Can we freeze a version or test before migration?
- What security and bias assessments are published?
- What training data and limitations are documented?
- What property rights apply to exits and adaptations?
- How is a request for deletion propagated?
- Does the supplier accept audits or provide independent reports?
- What limitations of availability, latency and capacity are contractual?
- How are government access requests handled?
- What assets can be exported, in what formats and at what cost?
- What assistance is provided for migration?
- What is the fallback mode if the service stops tomorrow?
The answers are documented with the contract documents. An oral response may guide the discussion, but it is not a guarantee.
9. AI Committee Scoreboard
A useful committee follows a small number of indicators, but links them to decisions.
- inventory coverage and systems without owner;
- distribution by risk level and expired exceptions;
- rate of systems with recent evaluation;
- critical errors, near-incidents and correction time;
- autonomous actions, confirmations and refusals;
- rates of employees trained according to their role;
- concentration of costs per supplier;
- percentage of exportable assets and final exit test;
- measured business value and uses without demonstrated benefit.
The committee doesn't read all the cards. It arbitrates exceptions, residual risks, shared investments and stop decisions. Product owners remain responsible for daily operations.
10. Action plan in 90 days
Days 1 to 15 — Make visible. Launch inventory, open a reporting channel, identify contracts and tools, name owners. Block only obviously dangerous uses.
Days 16 to 30 — Classify. Define the four internal levels, qualify the data, identify the systems potentially affected by the AI Act and prioritise the ten most exposed uses.
Days 31 to 50 — Control. Set up access, logging, minimum assessments, retention rules and incident process. Separate reading, preparation and execution.
Days 51 to 70 — Prove. Build evidence files, test suppliers, perform an injection exercise and a controlled shutdown. Correct gaps that prevent control.
Days 71 to 90 — Embed. Form by role, install the dashboard, date exceptions and schedule a reversibility test. The Committee shall take its first decisions on continuation, restriction or shutdown.
The expected result is not "Compliance Completed". It is a recurrent ability to know, decide, demonstrate and correct.
11. A ten-minute control check
Take a system. Name its owner. Show its purpose. Open its assessment. Find its version. Identify its data. Cut a tool. Revoke access. Export its assets. Finally, explain a recent mistake.
Each response must point to current evidence, not to the memory of a meeting. If three links are missing, the organisation may have good principles but not yet a complete operational control, because governance becomes credible only when teams are able to carry out these actions quickly, during an incident or in the face of an external request.
12. Frequently Asked Questions
12.1. Is a company using an API covered by the AI Act?
Potentially yes. Its role and obligations depend on the system, use and value chain. Being a supplier's customer does not remove the deployer's responsibilities. Legal qualification on a case-by-case basis remains necessary.
12.2. Can you ban public tools and govern shadow AI?
The ban reduces certain uses, but does not create a viable alternative or visibility. An effective approach combines authorised tools, understandable rules, awareness raising, proportionate technical controls and friction-free reporting.
12.3. Is the supplier's certification sufficient?
No. We need to check its perimeter, date and correspondence with the service. A safety certification does not prove the professional quality, lack of bias or conformity of use performed by the customer.
12.4. How to govern a model that changes without warning?
Contract notifications where possible, monitor versions and perform sentinel tests. For a critical case, use a controlled version or provide for a stop if the behaviour goes beyond the thresholds.
12.5. What is the first deliverable?
A workable inventory with an owner, purpose and level of risk. Without it, policies and training remain abstract.
13. What Logiks recommends
Do not first look for the perfect policy. Make the systems visible, connect each use to an owner and proof, and then proportion the controls to impact and autonomy. Security limits the range of action. Sovereignty is demonstrated by the ability to interrupt, restore and replace. Compliance then becomes a product of operational governance, not a separate file.
14. Main sources
- European Commission, AI regulatory framework and timetable, consulted on 13 July 2026: https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai
- EUR-Lex, Regulation (EU) 2024/1689: https://eur-lex.europa.eu/eli/reg/2024/1689/oj
- CNIL, recommendations for the development of the systems: https://www.cnil.fr/fr/developpement-des-systemes-dia-les-recommandations-de-la-cnil-pour-respecter-le-rgpd
- Eurostat, use of AI in enterprises in 2025: https://ec.europa.eu/eurostat/web/products-eurostat-news/w/ddn-20251211-2
- Insee, Use of artificial intelligence by enterprises in 2024: https://www.insee.fr/fr/statistiques/8616837
- France Num, France Num Barometer 2025: https://www.francenum.gouv.fr/guides-et-conseils/strategie-numerique/comprendre-le-numerique/barometre-france-num-2025-le
- Stanford Institute for Human-Centered AI, AI Index Report 2026, Responsible AI: https://hai.stanford.edu/ai-index/2026-ai-index-report/responsible-ai
- NIST, Strengthening AI Agent Hijacking Evaluations: https://www.nist.gov/news-events/news/2025/01/technical-blog-strengthening-ai-agent-hijacking-evaluations
- NIST, AI Risk Management Framework: https://airc.nist.gov/airmf-resources/airmf/5-sec-core/
- OWASP, Top 10 for Agentic Applications: https://genai.owasp.org/2025/12/09/owasp-top-10-for-agentic-applications-the-benchmark-for-agentic-security-in-the-age-of-autonomous-ai/