We build Agents. You build the Future.
● B2B offer — Group & internationalMulti-site: each entity isolated, the group supervised
A multi-site group carries a double requirement: each entity must stay in control of its data, and group management must keep an overall view. This system deploys agents site by site with strict data isolation, and a group-level supervision that sees the activity without accessing the content. Hosted in France: each entity's data stays within its own perimeter.
Updated on
Deployed in a few weeks
Multi-agent, multi-site · hosted in France
Fictional simulation — not a client result
What are the agents doing across all the sites?
Consolidated group view: active agents per site, volume handled, availability over the period.
This view covers activity, not content: each entity's data stays within its own perimeter.
Any shortfall in availability against the commitments is shown.
🔗 Sourced · activity indicators, with no access to content
This view covers activity, not content: each entity's data stays within its own perimeter.
Any shortfall in availability against the commitments is shown.
🔗 Sourced · activity indicators, with no access to content
Can head office look at the cases handled at a given site?
Isolation by entity rules that out by design: each site keeps its data within its own perimeter.
Opening access between entities is a matter for group governance, with the formalities the GDPR imposes between separate legal entities.
✎ Support · isolation maintained, a governance decision
Opening access between entities is a matter for group governance, with the formalities the GDPR imposes between separate legal entities.
✎ Support · isolation maintained, a governance decision
Data hosted in France · sovereign model as an option
Deployment hosted in France
Hosted in FranceAI model called at its publisher, except with the Sovereign model option
Each entity's data isolated
GDPR & AI Act: governed deploymentTraceability & human oversight
TurnkeyDesigned, installed and operated for you
The group IT department decidesThe agent carries out what you have authorised
For an organisation established outside the European Union, the law of its own country applies; at its request, we put equivalent safeguards in place (human review before any action, a log of the criteria, information for the people concerned).
✦ In brief
A Blue Lemon Agent multi-site system deploys agents site by site with strict data isolation by entity, and a group-level supervision covering activity and availability — with no access to content. Opening access between entities is a matter for group governance. Hosted in France, architecture designed to reduce exposure to extraterritorial legislation, location alone not being enough to guarantee immunity.
100%
hosted in France in the target architecture
0
transfer outside the EU with the Sovereign model option (target architecture)
3
uses deployable site by site
0
decision with a legal or significant effect taken by an agent
These figures describe our offer, not results measured at a client. How large the gain is on the number of sites, entities and agents deployed is confirmed by a pilot.
Indicative estimate, to be confirmed by a pilot on your real files (general terms of sale, article 4).
Pricing
One package, one agent
A multi-site multi-agent system (deployment, isolation, group supervision), installed and operated for you. Prices exclude VAT — annual subscription, the time it takes for the gains to settle in for good.
Agility
Setup + controlled subscription
7,690 € excl. VAT setup
then 522 € excl. VAT/month — you invest at installation and pay a reduced subscription. Ideal for keeping the cost under control over time.
- Installation, configuration and training for your teams
- Operation, human oversight, updates and support
- Hosting in France, a dedicated and isolated resource
The simplest
Serenity
All inclusive, no setup fee
947 € excl. VAT /month
all inclusive, immediate start. No upfront investment: a single subscription. Ideal for starting quickly and simply.
- Setup included (installation, configuration, training)
- Operation, human oversight, updates and support
- Hosting in France, managed end to end
100% Sovereign
On site, you own it
10,405 € excl. VAT setup
then 654 € excl. VAT/month · + hardware from 5,500 € (one-off purchase, in addition) — a sovereign computer installed on your premises, maintained remotely. Models run locally, your data returned at the end of the contract.
- Hardware installed on your premises (you own it)
- French / European AI models run locally
- Secure remote maintenance (Pro support included)
Included in the package: hosting and AI consumption up to the volume of your capacity tier, in documents, exchanges, tokens and storage; beyond that, re-invoiced at real cost with no margin, tracked in your client area as usage statements are issued. Maintenance and supervision subscription for an initial term of 12 months for the Agility package, 24 months for the Serenity package and 36 months for the 100% Sovereign package, renewable; support levels (SLA 72 h / 24 h / 4 h) optional. Bespoke development, additional integrations or exceptional volumes are quoted separately. Support Monday to Friday, 9am to 6pm. Prices exclude VAT.
AI model:
none of the AI models offered currently carries a fixed surcharge. When the selected model carries a cost, that cost is shown when you choose it, before you order, and re-invoiced at the cost incurred, with no mark-up; usage is billed at the publisher's price. Publishers' prices are published in US dollars: the amount re-invoiced is the amount in euros actually borne by Blue Lemon Agent on the publisher's invoice, at that invoice's exchange rate, with no commission or mark-up.
Included components and additional components Components included in the base offer: the Blue Lemon Agent software foundation, the AI models listed in the order journey, the standard channels (Microsoft Teams, Slack, WhatsApp Business, email, website chat, calendars, Microsoft 365 / Google Workspace, file storage, market VoIP telephony, professional social-media pages and accounts, Google Business Profile), hosting for the package chosen, in France by default, backups, supervision, updates and support. If adapting the AI agent to your constraints, your needs or your requests requires other paid components — a third-party publisher's software licence, paid API access to one of your applications, hosting of health data, for which French law requires an HDS-certified host (art. L. 1111-8 of the French Public Health Code), SecNumCloud-qualified hosting, a speech synthesis service, particular hardware —, they are offered to you as an option or on quotation and re-invoiced at the cost incurred; nothing is committed without your written agreement. Where the artificial intelligence model you choose entails an additional cost, that cost is shown to you before you order and re-invoiced to you at the cost incurred, with no margin.
What to expect
Go-live
2 to 3 weeks
Agent designed, channels connected, team trained.
Steady state
4 to 7 weeks
After a few weeks of real use, once the agent's behaviour matches what you expect.
Indicative estimate, adjusted to the options you keep. It is not a delivery commitment.
Use cases
What does the multi-site system actually do?
A group foundation, agents site by site. Each agent carries out by itself what you authorise it to do; opening an access between entities is a matter for group governance.
Included in your agent
The 3 capabilities essential to this promise are included, at no extra cost.
From 522 € excl. VAT / month
Deployment site by site
Installs the agents suited to each site, within its own perimeter.
Isolation by entity
Content does not cross entity borders.
Group-level supervision
Follows activity, volume and availability, without accessing content.
Controls and safeguards
These 3 controls are built into the agent: they frame what it does, whatever plan you pick. They are not chosen and are not added to your order.
Human arbitration of conflicts and irreversible decisions
Observability of costs, timescales, quality, failures and safe stop
Data protection, rights and human oversight
What the agent must be connected to
These 2 connections are required for the agent to work. They concern your information system and are scoped during the audit.
Register of authorised agents and interface contracts
Integration with existing tools without double entry
Does your need fall outside this?
Build your agent
In 30 minutes we identify the most relevant agent — without oversizing the project.
Demonstration
See the agent at work
5 everyday situations, taken from those that come up most often. Pick one: the exchange unfolds as it would in your organisation.
A scripted demonstration. These exchanges show how the agent behaves — its sources, its refusals, what it leaves to your teams. Nothing is sent from this page, no model is queried here, and the matters named are fictional. That is precisely what we promise your data. The behaviours shown here — monitoring, automation rules, routing and reminders — are configured with you during deployment, from your tools, your rules and your thresholds. The architecture points named in these exchanges — location, local execution, isolation, encryption, role-based access, logging — are not a guarantee attached to the demonstration: they are those of the architecture set out in your quotation, and verified before commissioning.
The company in this demonstration
Fictional companyVaudrey Group — water treatment equipment, six legally separate entities
- Sector
- Water industry — design, manufacture and operation of treatment plants for local authorities and industrial clients
- Headcount
- 1,240 staff across six entities; the group IT department has 14 people, 3 of them assigned to the agent programme
- Perimeter served
- Six entities: Rouen (industrial head office), Bourges, Orléans, Lyon, Namur in Belgium and Zaragoza in Spain — all inside the European Union
- Volume
- 5,400 documents processed each month across all sites; six use cases deployable per site; a first deployment of 84 person-days
- Tools in place
- Three different ERP systems, two document management systems, one group mail service and one group directory — the agent plugs into them, nothing is replaced
- Who decides
- The group IT director arbitrates deployments; each entity director remains in charge of that entity's data; the group data protection officer signs off on any cross-entity access
- Room for improvement
- The first site took 84 person-days over 22 weeks; the group activity report is assembled by hand, 24 hours a month across six site contacts; verifying isolation absorbs 96 hours of audit a year
The Vaudrey Group is not trying to centralise its data — it is legally prevented from doing so, its six entities being separate — but to deploy the same agents everywhere without doing the same work six times, and to finally see activity as a whole. The agent runs on isolated resources hosted in France, one per entity, and plugs into the three ERP systems, the two document management systems and the group directory: it prepares, the IT department arbitrates, each entity director keeps control of their own data. The exchanges below span two quarters, from scoping to review.
This company, its figures and the exchanges that follow were invented for the demonstration. They illustrate a common situation; they describe no real client.
Multi-agent, multi-site · hosted in France
Fictional simulation — not a client result
I have read your six records of processing, your three ERP systems and the 214 application flows your teams declared. I draw a conclusion your programme file did not carry: your entities share 71 % of their document processing and 0 % of their data.
A record of processing is the written inventory every organisation keeps of what it does with personal data: what it is used for, where it comes from, who accesses it, how long it is kept.
What that gap means, and it is the gap that sets the gain: what can be pooled in your group is the architecture, never the data. Your six entities handle the same objects — supplier orders, project files, commissioning reports, complaints — with contents that have no reason to meet, and no right to without formalities.
The figure your own records carry: deploying Rouen cost 84 person-days over 22 weeks. Re-reading the acceptance reports, 73 of those 84 days produced architecture — directory connection, encryption, role-based access, logging, supervision templates, compliance file — and only 11 produced work specific to Rouen.
What that gives you on the five remaining entities: the architecture carries over as is. Deploying a site drops from 65 % to 9 % of a project's workload, i.e. 84 person-days → 12. Across five sites, 360 person-days that will not be spent — at the €520 fully-loaded daily cost your management accounting applies, €187,200.
What I propose: a deployment order that starts with Bourges rather than Lyon. Bourges shares Rouen's ERP: it is the site that fastest proves the platform really does carry over. If the platform holds at Bourges it holds everywhere; if it does not, you find out in three weeks instead of five months. The IT department arbitrates, I build the plan straight after. mapping_six-entities-and-deployment-order.pdf71 % shared processing, 0 % shared data
⛓ Sourced · six records of processing, 214 declared application flows, acceptance reports from the Rouen deployment
A record of processing is the written inventory every organisation keeps of what it does with personal data: what it is used for, where it comes from, who accesses it, how long it is kept.
What that gap means, and it is the gap that sets the gain: what can be pooled in your group is the architecture, never the data. Your six entities handle the same objects — supplier orders, project files, commissioning reports, complaints — with contents that have no reason to meet, and no right to without formalities.
The figure your own records carry: deploying Rouen cost 84 person-days over 22 weeks. Re-reading the acceptance reports, 73 of those 84 days produced architecture — directory connection, encryption, role-based access, logging, supervision templates, compliance file — and only 11 produced work specific to Rouen.
What that gives you on the five remaining entities: the architecture carries over as is. Deploying a site drops from 65 % to 9 % of a project's workload, i.e. 84 person-days → 12. Across five sites, 360 person-days that will not be spent — at the €520 fully-loaded daily cost your management accounting applies, €187,200.
What I propose: a deployment order that starts with Bourges rather than Lyon. Bourges shares Rouen's ERP: it is the site that fastest proves the platform really does carry over. If the platform holds at Bourges it holds everywhere; if it does not, you find out in three weeks instead of five months. The IT department arbitrates, I build the plan straight after. mapping_six-entities-and-deployment-order.pdf71 % shared processing, 0 % shared data
⛓ Sourced · six records of processing, 214 declared application flows, acceptance reports from the Rouen deployment
Our six entities share neither the same ERP nor the same internal rules. What actually gets reused?
Seven building blocks carry over as is, four are rebuilt at every site. That split is what makes the 12 person-days — and I will also give you the site where it had to be widened.
What carries over, and why it has nothing to do with your ERP systems:
· Connection to the group directory — your accounts already exist, the agent creates no identity.
· Encryption in transit and at rest, set once.
· Role-based access — rights follow the job, not the person: a maintenance technician opens commissioning reports, not supplier files or contracts.
· Logging: who asked what, when, and what was approved.
· Supervision templates that feed the group view.
· The acceptance procedure — 34 checks to pass before go-live.
· The compliance file, copied and dated per entity.
What is rebuilt, and rightly so: the ERP connector, the business vocabulary, the document filing plan, and the entity's own approval rules — the only block where the entity director must spend time, and the one that belongs to them.
The costing rule that follows, and it holds for the sites still to come: the 12 person-days apply to a site whose ERP already has its connector. Orléans runs the one of your three ERPs that did not yet have one: the connector was written there, tested and added to the platform, 19 person-days and 5 weeks for that site. Lyon, which runs the same ERP, opened behind it in 12 person-days and 3 weeks without a line being rewritten. An ERP without a connector is costed separately, once, and the next site that runs it pays none of it — that is the rule I apply, and it is in the plan you hold.
What I propose next: writing the 34 acceptance checks into your service agreement, site by site. A written acceptance procedure is what keeps a fast deployment a deployment that holds — and you decide which checks are blocking. platform_what-carries-over-and-what-is-rebuilt.pdf7 blocks reused, 4 rebuilt, 34 acceptance checks
⛓ Sourced · acceptance reports from the first three sites, IT department timesheets
What carries over, and why it has nothing to do with your ERP systems:
· Connection to the group directory — your accounts already exist, the agent creates no identity.
· Encryption in transit and at rest, set once.
· Role-based access — rights follow the job, not the person: a maintenance technician opens commissioning reports, not supplier files or contracts.
· Logging: who asked what, when, and what was approved.
· Supervision templates that feed the group view.
· The acceptance procedure — 34 checks to pass before go-live.
· The compliance file, copied and dated per entity.
What is rebuilt, and rightly so: the ERP connector, the business vocabulary, the document filing plan, and the entity's own approval rules — the only block where the entity director must spend time, and the one that belongs to them.
The costing rule that follows, and it holds for the sites still to come: the 12 person-days apply to a site whose ERP already has its connector. Orléans runs the one of your three ERPs that did not yet have one: the connector was written there, tested and added to the platform, 19 person-days and 5 weeks for that site. Lyon, which runs the same ERP, opened behind it in 12 person-days and 3 weeks without a line being rewritten. An ERP without a connector is costed separately, once, and the next site that runs it pays none of it — that is the rule I apply, and it is in the plan you hold.
What I propose next: writing the 34 acceptance checks into your service agreement, site by site. A written acceptance procedure is what keeps a fast deployment a deployment that holds — and you decide which checks are blocking. platform_what-carries-over-and-what-is-rebuilt.pdf7 blocks reused, 4 rebuilt, 34 acceptance checks
⛓ Sourced · acceptance reports from the first three sites, IT department timesheets
You advertise six use cases deployable per site. Which ones are they, and which pay off most?
All six have been live at Rouen for two quarters, and I rank them by what they returned, not by order of arrival.
· Supplier files and order matching — 1,900 documents a month at Rouen, the heaviest workload and the first gain.
· Commissioning reports: drafted on your templates from site records, reviewed by the works supervisor before signature.
· Replies to operating complaints, drawn from the project file and the contract.
· Document search across drawings, manuals and intervention reports, always pointing back to the source document.
· Preparation of public tender files — the administrative documents, never the technical offer.
· Contract deadline tracking: warranties, contract reviews, renewals.
What they returned at Rouen over two quarters: 1,640 hours of administrative work, 62 % of it on supplier files alone. The ranking matters more than the total: it tells you where to start on the five remaining entities, and it is not the same everywhere.
The nuance that makes the difference from one site to the next: at Zaragoza the supplier workload is three times lighter than at Rouen — 300 documents a month against 1,900 — but operating complaints weigh twice as much. Same platform, different order of use cases. I have built the ranking for each of the six entities.
What I propose: open Bourges on three use cases, not six. Three use cases in three weeks beat six in eight — you measure sooner, and the next three are added without a further architecture acceptance round. The IT department decides, I start with whichever you name. six-use-cases_ranked-entity-by-entity.pdf1,640 hours returned at Rouen, a different order per site
⛓ Sourced · Rouen activity records over two quarters, document volumes of the six entities
· Supplier files and order matching — 1,900 documents a month at Rouen, the heaviest workload and the first gain.
· Commissioning reports: drafted on your templates from site records, reviewed by the works supervisor before signature.
· Replies to operating complaints, drawn from the project file and the contract.
· Document search across drawings, manuals and intervention reports, always pointing back to the source document.
· Preparation of public tender files — the administrative documents, never the technical offer.
· Contract deadline tracking: warranties, contract reviews, renewals.
What they returned at Rouen over two quarters: 1,640 hours of administrative work, 62 % of it on supplier files alone. The ranking matters more than the total: it tells you where to start on the five remaining entities, and it is not the same everywhere.
The nuance that makes the difference from one site to the next: at Zaragoza the supplier workload is three times lighter than at Rouen — 300 documents a month against 1,900 — but operating complaints weigh twice as much. Same platform, different order of use cases. I have built the ranking for each of the six entities.
What I propose: open Bourges on three use cases, not six. Three use cases in three weeks beat six in eight — you measure sooner, and the next three are added without a further architecture acceptance round. The IT department decides, I start with whichever you name. six-use-cases_ranked-entity-by-entity.pdf1,640 hours returned at Rouen, a different order per site
⛓ Sourced · Rouen activity records over two quarters, document volumes of the six entities
Fictional simulation — not a client result
Bourges is approved. Concretely, what happens over the next three weeks?
Three weeks, fifteen working days, and I will tell you now the two moments where I need you — the rest costs you nothing.
Week 1 — the resource and the connection. An isolated resource is opened for Bourges — an environment dedicated to that entity alone, with no pooling with the other five nor with any other client —, hosted in France, under French law. Directory connection, encryption, role-based access, logging. Three person-days, no service interruption on your side.
Week 2 — the business layer. ERP connector (already written, Rouen's), Bourges filing plan, entity vocabulary, approval rules. Six person-days, and this is where your site contact gives two half-days — nobody but them knows their internal rules.
Week 3 — acceptance testing and go-live. The 34 checks, 9 of them blocking: none is waved through on a promise. Three person-days. Then a staged go-live, one use case a day.
The two moments where I need a decision, not a formality: the filing plan in week 2, because it determines what the agent will find for the next five years; and the clearing of the 9 blocking checks in week 3, which is an act of the entity director, not a box to tick.
The benchmark to remember: 65 % of a project's workload becomes 9 % — 84 person-days become 12. And the measure that matters to you: Bourges starts returning time on day 21, not on day 154.
What I propose: a progress note every Friday, with the checks passed and those still open. A fast deployment has to be visible every week. bourges-deployment_day-by-day.pdf15 working days, 12 person-days, 2 decisions required
✎ Framework · standard deployment plan, 34-point acceptance procedure, Rouen deployment log
Week 1 — the resource and the connection. An isolated resource is opened for Bourges — an environment dedicated to that entity alone, with no pooling with the other five nor with any other client —, hosted in France, under French law. Directory connection, encryption, role-based access, logging. Three person-days, no service interruption on your side.
Week 2 — the business layer. ERP connector (already written, Rouen's), Bourges filing plan, entity vocabulary, approval rules. Six person-days, and this is where your site contact gives two half-days — nobody but them knows their internal rules.
Week 3 — acceptance testing and go-live. The 34 checks, 9 of them blocking: none is waved through on a promise. Three person-days. Then a staged go-live, one use case a day.
The two moments where I need a decision, not a formality: the filing plan in week 2, because it determines what the agent will find for the next five years; and the clearing of the 9 blocking checks in week 3, which is an act of the entity director, not a box to tick.
The benchmark to remember: 65 % of a project's workload becomes 9 % — 84 person-days become 12. And the measure that matters to you: Bourges starts returning time on day 21, not on day 154.
What I propose: a progress note every Friday, with the checks passed and those still open. A fast deployment has to be visible every week. bourges-deployment_day-by-day.pdf15 working days, 12 person-days, 2 decisions required
✎ Framework · standard deployment plan, 34-point acceptance procedure, Rouen deployment log
What our Bourges teams fear most is having to change tools. Is that the case?
No tool changes, and nobody gets one more subscription. I plug in, I replace nothing.
What I connect to at Bourges: the ERP, the document management system, the mail service and the group directory. Your users keep opening the same screens — the agent appears where the work happens, not in one more application to open in the morning.
What changes for them, concretely: a supplier file arrives already matched to its order, with discrepancies flagged. A commissioning report arrives drafted on the entity's template. The gesture that changes is reviewing instead of keying in — and that is the whole of the learning curve.
What gets signed, and it is better said before than after: the entry into your ERP. Nothing goes in unless a named user has approved it — zero decision with a legal or significant effect taken by an agent is how I am wired in, not a setting that could be loosened. What comes before the signature is done: at Rouen an entry arrives already matched, discrepancies flagged, and is approved in seconds instead of keyed in over minutes.
Getting up to speed: two hours per team, on their own files from that week — never on a demonstration dataset. At Rouen, 91 % of users stopped opening the documentation after the second week; the remaining 9 % are concentrated on the public tender use case, the most technical one. That is who the extra session was proposed for, and it is planned at Bourges from the outset.
What I propose: naming one contact per use case at Bourges, as at Rouen. It is not a job, it is a person you can ask « does this work » — and at Rouen they raised three quarters of the quarter's improvements.
What I connect to at Bourges: the ERP, the document management system, the mail service and the group directory. Your users keep opening the same screens — the agent appears where the work happens, not in one more application to open in the morning.
What changes for them, concretely: a supplier file arrives already matched to its order, with discrepancies flagged. A commissioning report arrives drafted on the entity's template. The gesture that changes is reviewing instead of keying in — and that is the whole of the learning curve.
What gets signed, and it is better said before than after: the entry into your ERP. Nothing goes in unless a named user has approved it — zero decision with a legal or significant effect taken by an agent is how I am wired in, not a setting that could be loosened. What comes before the signature is done: at Rouen an entry arrives already matched, discrepancies flagged, and is approved in seconds instead of keyed in over minutes.
Getting up to speed: two hours per team, on their own files from that week — never on a demonstration dataset. At Rouen, 91 % of users stopped opening the documentation after the second week; the remaining 9 % are concentrated on the public tender use case, the most technical one. That is who the extra session was proposed for, and it is planned at Bourges from the outset.
What I propose: naming one contact per use case at Bourges, as at Rouen. It is not a job, it is a person you can ask « does this work » — and at Rouen they raised three quarters of the quarter's improvements.
And if acceptance testing reveals a problem? How far does go-live slip?
Not at all, in most cases: go-live is staged, one use case a day, and one failing use case does not hold up the other five.
What the 34 checks say, and what they do when they fail:
· 9 blocking checks — resource isolation, encryption, role-based access, logging, compliance of the processing file. One not cleared, and nothing opens. That is the core, and it is not negotiable.
· 25 use-case checks — matching quality, template accuracy, completeness of the filing plan. One check not cleared suspends that use case, not the site.
What that gave at Bourges: 33 checks passed, one suspended — and that is exactly the job of the 25 use-case checks. Supplier order matching came in at 88 % accuracy against a 96 % threshold, because Bourges prefixes its order numbers with a workshop code that Rouen does not use: the check saw it before go-live, not after.
What the mechanism produced: the reading rule took the prefix in within half a day, the check came back at 97 %, and that use case opened two days after the other five, which opened on the planned date. Suspending a single use case without touching the site is what the threshold is for.
And the trace, which will serve you later: every check carries its date, its result and the person who cleared it. That is the file your auditors and your public clients ask for, and it no longer has to be reconstructed six months on.
What I propose: re-running the 34 checks on each go-live anniversary, site by site. Acceptance testing is not a rite of passage, it is a state to be found again — and checking it once a year is what makes it provable at any time. bourges-acceptance_34-checks.pdf33 passed, 1 suspended then fixed in half a day
⛓ Sourced · Bourges acceptance report, matching accuracy records, clearance log
What the 34 checks say, and what they do when they fail:
· 9 blocking checks — resource isolation, encryption, role-based access, logging, compliance of the processing file. One not cleared, and nothing opens. That is the core, and it is not negotiable.
· 25 use-case checks — matching quality, template accuracy, completeness of the filing plan. One check not cleared suspends that use case, not the site.
What that gave at Bourges: 33 checks passed, one suspended — and that is exactly the job of the 25 use-case checks. Supplier order matching came in at 88 % accuracy against a 96 % threshold, because Bourges prefixes its order numbers with a workshop code that Rouen does not use: the check saw it before go-live, not after.
What the mechanism produced: the reading rule took the prefix in within half a day, the check came back at 97 %, and that use case opened two days after the other five, which opened on the planned date. Suspending a single use case without touching the site is what the threshold is for.
And the trace, which will serve you later: every check carries its date, its result and the person who cleared it. That is the file your auditors and your public clients ask for, and it no longer has to be reconstructed six months on.
What I propose: re-running the 34 checks on each go-live anniversary, site by site. Acceptance testing is not a rite of passage, it is a state to be found again — and checking it once a year is what makes it provable at any time. bourges-acceptance_34-checks.pdf33 passed, 1 suspended then fixed in half a day
⛓ Sourced · Bourges acceptance report, matching accuracy records, clearance log
Fictional simulation — not a client result
Our six entities are legally separate. Where exactly does their data live?
Each lives at home, on its own isolated resource hosted in France — and there is no place where your six entities meet.
What that means in law, and it is the point that matters to your data protection officer: each of your entities is the controller of its own processing — meaning it, and not the group, decides why and how its data is processed. The group is not a data perimeter: it is a governance perimeter. The architecture takes that literally.
The two possible routes, and you do not have to pick the same one everywhere:
· Local inference — the model computes on a machine belonging to the entity: no content crosses an external network to be processed. That is the route taken at Rouen, where the workshop works on client drawings under confidentiality agreements.
· An isolated resource hosted in France, under French law, dedicated to a single entity. That is the route for Bourges, Orléans, Lyon, Namur and Zaragoza.
What the second guarantees, and no American host guarantees even when installed in Europe: architecture designed to reduce exposure to extraterritorial legislation, location alone not being enough to guarantee immunity. 0 data outside the European Union, including for Namur and Zaragoza, whose data stays hosted in France.
What goes up to group level, and it is all that goes up: counters. Number of items processed, volumes, availability, gaps against service commitments. Never a file, never a name, never an extract. Head office knows Bourges processed 1,100 documents in October; it cannot know which ones, and that is not a cautious setting, it is how the flows are built.
What I propose: keeping up to date the technical sheet your public clients ask for at renewal — hosting, subcontractors, retention periods, who accesses what, entity by entity. It is asked for once a year and used to take three days to find; it is now kept up to date continuously. technical-framework_where-each-entity-data-lives.pdf6 isolated resources, processing in the EU targeted, 0 junction point
✎ Framework · deployment architecture, records of processing of the six entities, access log
What that means in law, and it is the point that matters to your data protection officer: each of your entities is the controller of its own processing — meaning it, and not the group, decides why and how its data is processed. The group is not a data perimeter: it is a governance perimeter. The architecture takes that literally.
The two possible routes, and you do not have to pick the same one everywhere:
· Local inference — the model computes on a machine belonging to the entity: no content crosses an external network to be processed. That is the route taken at Rouen, where the workshop works on client drawings under confidentiality agreements.
· An isolated resource hosted in France, under French law, dedicated to a single entity. That is the route for Bourges, Orléans, Lyon, Namur and Zaragoza.
What the second guarantees, and no American host guarantees even when installed in Europe: architecture designed to reduce exposure to extraterritorial legislation, location alone not being enough to guarantee immunity. 0 data outside the European Union, including for Namur and Zaragoza, whose data stays hosted in France.
What goes up to group level, and it is all that goes up: counters. Number of items processed, volumes, availability, gaps against service commitments. Never a file, never a name, never an extract. Head office knows Bourges processed 1,100 documents in October; it cannot know which ones, and that is not a cautious setting, it is how the flows are built.
What I propose: keeping up to date the technical sheet your public clients ask for at renewal — hosting, subcontractors, retention periods, who accesses what, entity by entity. It is asked for once a year and used to take three days to find; it is now kept up to date continuously. technical-framework_where-each-entity-data-lives.pdf6 isolated resources, processing in the EU targeted, 0 junction point
✎ Framework · deployment architecture, records of processing of the six entities, access log
You say « never an extract ». But our entity directors already send documents to head office by email. Where is the boundary?
The boundary is where I stop, not where your people stop — and that is a useful distinction rather than a lawyer's nuance.
Your entity directors exchange documents, and they are entitled to: they are responsible for their data and decide to communicate it, under their signature. What I do not have is that power. An agent deciding on its own to move a document from one entity to another would turn a director's decision into a side effect of configuration — and that is exactly what the architecture closes off from the start.
So here is precisely what I do:
· I read within one entity's perimeter and write within the same one. Six agents, six perimeters.
· I count, for the group: number of items processed, volumes, availability, response times.
· I prepare a transmission when a director asks for one: the document, its covering slip, its recipient — and it is the director who sends it, under their name.
What crosses an entity boundary only on a director's written mandate, with no exception: opening access between two entities, moving content up to group level, answering a head-office question that requires reading at a subsidiary. All three are built in minutes and executed within the hour — what triggers them is a named, dated mandate, withdrawable with a word, never a side effect of configuration.
The figure that proves it rather than asserting it: over two quarters, 18,400 logged operations, 0 content having crossed an entity boundary, and 7 cross-entity access requests — all escalated, none executed without a mandate.
And the monthly test that verifies it: every month I launch, from each entity, 12 requests that ought to fail — read a neighbouring file, look up another entity's supplier, open a log that is not its own. 72 attempts, 72 refusals expected, 72 refusals obtained. The report goes to your data protection officer without anyone having to ask for it.
What I propose: making that test a clause of your service agreement, with the monthly report as a deliverable. Isolation that is asserted can be argued with; isolation tested every month can be shown. entity-boundary_what-crosses-and-what-never-does.pdf18,400 operations, 0 crossings, 72 expected refusals obtained
⛓ Sourced · access logs of the six entities, monthly isolation test results
Your entity directors exchange documents, and they are entitled to: they are responsible for their data and decide to communicate it, under their signature. What I do not have is that power. An agent deciding on its own to move a document from one entity to another would turn a director's decision into a side effect of configuration — and that is exactly what the architecture closes off from the start.
So here is precisely what I do:
· I read within one entity's perimeter and write within the same one. Six agents, six perimeters.
· I count, for the group: number of items processed, volumes, availability, response times.
· I prepare a transmission when a director asks for one: the document, its covering slip, its recipient — and it is the director who sends it, under their name.
What crosses an entity boundary only on a director's written mandate, with no exception: opening access between two entities, moving content up to group level, answering a head-office question that requires reading at a subsidiary. All three are built in minutes and executed within the hour — what triggers them is a named, dated mandate, withdrawable with a word, never a side effect of configuration.
The figure that proves it rather than asserting it: over two quarters, 18,400 logged operations, 0 content having crossed an entity boundary, and 7 cross-entity access requests — all escalated, none executed without a mandate.
And the monthly test that verifies it: every month I launch, from each entity, 12 requests that ought to fail — read a neighbouring file, look up another entity's supplier, open a log that is not its own. 72 attempts, 72 refusals expected, 72 refusals obtained. The report goes to your data protection officer without anyone having to ask for it.
What I propose: making that test a clause of your service agreement, with the monthly report as a deliverable. Isolation that is asserted can be argued with; isolation tested every month can be shown. entity-boundary_what-crosses-and-what-never-does.pdf18,400 operations, 0 crossings, 72 expected refusals obtained
⛓ Sourced · access logs of the six entities, monthly isolation test results
Precisely: Rouen and Bourges jointly run the Vireuil plant contract. Rouen needs Bourges's 214 execution files. How do we do it?
We do it — and cleanly, in forty minutes rather than six weeks. This is not something I refuse, it is something that calls for a mandate, and I have already built it.
Why a mandate and not a simple access right: Rouen and Bourges are two separate controllers. Moving 214 files from one to the other is a communication between organisations, and the GDPR expects it to rest on a written purpose, a duration, a perimeter and named recipients. This is not fussy paperwork: it is what protects you the day a third party asks on what basis Rouen holds Bourges's documents.
What I have prepared, ready to sign:
· Purpose: monitoring the execution of the joint Vireuil plant contract. Nothing else.
· Capped perimeter: the 214 execution files of that contract, listed by name — not Bourges's suppliers, not its staff, not its other projects.
· Named recipients: four people at Rouen, the works supervisor, two engineers and the quality manager.
· Duration: 90 days, expiring 31/12/2026, renewable by a fresh written act — never by tacit renewal.
· Traceability: every file opening logged, monthly statement to both directors.
· Withdrawal: one word from either director and access closes within the minute, with no reason to be given.
Who signs: the two entity directors, with your group data protection officer's sign-off. Three signatures, on a one-page document.
What that shifts: your last access opening of this kind took six weeks, mostly spent working out who was supposed to write what. The file was built in 40 minutes, access opens within ten minutes of the third signature — and it closes by itself on 31 December.
What I propose next: making this mandate your group template. You have seven cross-entity access requests pending; with a template they are handled within a day instead of sleeping until someone gives up. Group governance decides; all I do is make the decision easy to take. mandate_rouen-bourges-access_vireuil-plant.pdf214 files, 4 recipients, 90 days, revocable in one word
✎ Framework · cross-entity access mandate template, Rouen and Bourges records of processing, list of the 214 contract files
Why a mandate and not a simple access right: Rouen and Bourges are two separate controllers. Moving 214 files from one to the other is a communication between organisations, and the GDPR expects it to rest on a written purpose, a duration, a perimeter and named recipients. This is not fussy paperwork: it is what protects you the day a third party asks on what basis Rouen holds Bourges's documents.
What I have prepared, ready to sign:
· Purpose: monitoring the execution of the joint Vireuil plant contract. Nothing else.
· Capped perimeter: the 214 execution files of that contract, listed by name — not Bourges's suppliers, not its staff, not its other projects.
· Named recipients: four people at Rouen, the works supervisor, two engineers and the quality manager.
· Duration: 90 days, expiring 31/12/2026, renewable by a fresh written act — never by tacit renewal.
· Traceability: every file opening logged, monthly statement to both directors.
· Withdrawal: one word from either director and access closes within the minute, with no reason to be given.
Who signs: the two entity directors, with your group data protection officer's sign-off. Three signatures, on a one-page document.
What that shifts: your last access opening of this kind took six weeks, mostly spent working out who was supposed to write what. The file was built in 40 minutes, access opens within ten minutes of the third signature — and it closes by itself on 31 December.
What I propose next: making this mandate your group template. You have seven cross-entity access requests pending; with a template they are handled within a day instead of sleeping until someone gives up. Group governance decides; all I do is make the decision easy to take. mandate_rouen-bourges-access_vireuil-plant.pdf214 files, 4 recipients, 90 days, revocable in one word
✎ Framework · cross-entity access mandate template, Rouen and Bourges records of processing, list of the 214 contract files
Fictional simulation — not a client result
The group activity report takes us three days a month. What do you do with it?
It is ready on the 1st of the month at 6 a.m., without any of your six site contacts being asked for anything. All that is left is to read it and comment on it: 24 hours a month become a little over 3.
What it carries, for October:
· 5,400 documents processed across the six entities — Rouen 1,900, Bourges 1,100, Lyon 900, Orléans 700, Namur 500, Zaragoza 300.
· Availability per site, against your commitments: 99.5 % on critical agents, 99.0 % on the others.
· Response times: 11 support requests, median response of 38 minutes against a 2 working-hour commitment on critical agents.
· Contract gaps, named and dated, with their cause.
The benchmark it shifts: group activity monitoring goes from 45 % to 6 % of that task's workload — and the six site contacts each get their monthly half-day back. Over a year, 252 hours, i.e. 33 person-days nobody spends re-keying figures any more.
What the report does not carry, and you should know it before reading: no content, no file name, no extract. I count operations, I do not display them. If the group view could show a Bourges file, isolation would not exist — it would merely be tidy.
What I propose: that the report go out automatically on the 1st to the IT department and the six entity directors, each seeing the group in counters and their own entity in detail. You set who receives what; I open no further line on my own. group-activity-report_october.pdf5,400 documents, 6 entities, 0 content exposed
⛓ Sourced · activity counters of the six entities, availability log, support request register
What it carries, for October:
· 5,400 documents processed across the six entities — Rouen 1,900, Bourges 1,100, Lyon 900, Orléans 700, Namur 500, Zaragoza 300.
· Availability per site, against your commitments: 99.5 % on critical agents, 99.0 % on the others.
· Response times: 11 support requests, median response of 38 minutes against a 2 working-hour commitment on critical agents.
· Contract gaps, named and dated, with their cause.
The benchmark it shifts: group activity monitoring goes from 45 % to 6 % of that task's workload — and the six site contacts each get their monthly half-day back. Over a year, 252 hours, i.e. 33 person-days nobody spends re-keying figures any more.
What the report does not carry, and you should know it before reading: no content, no file name, no extract. I count operations, I do not display them. If the group view could show a Bourges file, isolation would not exist — it would merely be tidy.
What I propose: that the report go out automatically on the 1st to the IT department and the six entity directors, each seeing the group in counters and their own entity in detail. You set who receives what; I open no further line on my own. group-activity-report_october.pdf5,400 documents, 6 entities, 0 content exposed
⛓ Sourced · activity counters of the six entities, availability log, support request register
And when a site slips? We want to know before the entity director calls.
You knew on 12 October at 7:40 a.m., and the call never came. Here is the figure I publish about myself, its real cause and what became of it.
The gap: Bourges held 99.1 % availability in October, against a 99.5 % commitment on critical agents. That is below the service commitment, and I am the one telling you — before the entity director calls.
The cause, and it was not where anyone would have looked: neither the resource nor the network — it is two of your own internal rules contradicting each other. Your group standard sets the nightly agent restart at 3:15 a.m.: it was written at Rouen, where the backup ends at 1 a.m. The Bourges operating rule, for its part, opens its backup window from 2 a.m. to 4 a.m. Both are in force and neither cites the other; I applied the group standard, which is the one the programme gave me. 14 runs lost over the month, always the same ones, always at the same hour.
What I did with it: I put the question to you rather than settling it alone — which of the two rules prevails for the restart time? The group IT department answered that the site's backup window wins: restart moved to 4:30 a.m., corrected on 13 October. November came in at 99.7 %. And I put the same question to the other five sites: Zaragoza carried the same contradiction, with no visible consequence yet. Settled too.
What that opens on the contract side: October's gap is documented, dated, with its cause and its fix. You do not have to argue it: it is written in the report you receive. It is also what makes a service commitment credible — a supplier that never publishes a gap is measuring nothing.
What I propose: adding to the monthly control a review of inherited settings — backup windows, restart times, public holiday calendars, which are not the same in Belgium and in Spain. That is the family of errors specific to a multi-site deployment, and you find it wherever the architecture copied across best. service-commitment-gaps_october-and-follow-up.pdf99.1 % at Bourges, cause found, 99.7 % the next month
⛓ Sourced · Bourges availability log, run register, settings of the six sites
The gap: Bourges held 99.1 % availability in October, against a 99.5 % commitment on critical agents. That is below the service commitment, and I am the one telling you — before the entity director calls.
The cause, and it was not where anyone would have looked: neither the resource nor the network — it is two of your own internal rules contradicting each other. Your group standard sets the nightly agent restart at 3:15 a.m.: it was written at Rouen, where the backup ends at 1 a.m. The Bourges operating rule, for its part, opens its backup window from 2 a.m. to 4 a.m. Both are in force and neither cites the other; I applied the group standard, which is the one the programme gave me. 14 runs lost over the month, always the same ones, always at the same hour.
What I did with it: I put the question to you rather than settling it alone — which of the two rules prevails for the restart time? The group IT department answered that the site's backup window wins: restart moved to 4:30 a.m., corrected on 13 October. November came in at 99.7 %. And I put the same question to the other five sites: Zaragoza carried the same contradiction, with no visible consequence yet. Settled too.
What that opens on the contract side: October's gap is documented, dated, with its cause and its fix. You do not have to argue it: it is written in the report you receive. It is also what makes a service commitment credible — a supplier that never publishes a gap is measuring nothing.
What I propose: adding to the monthly control a review of inherited settings — backup windows, restart times, public holiday calendars, which are not the same in Belgium and in Spain. That is the family of errors specific to a multi-site deployment, and you find it wherever the architecture copied across best. service-commitment-gaps_october-and-follow-up.pdf99.1 % at Bourges, cause found, 99.7 % the next month
⛓ Sourced · Bourges availability log, run register, settings of the six sites
Our entity directors are asking whether this group view will be used to compare their teams.
It counts no individual today, and I will tell you why mechanically rather than morally — then how we would proceed if you decided otherwise.
The mechanism, and there is nothing theoretical about it: a per-person counter becomes a target the moment it is published; the target distorts what it measures — people approve faster, annotate less, stop flagging anything that would push their line down — and the report stops being the steering instrument you wanted. You lose the measure AND the behaviour it was meant to watch. That is why I count operations per site, not approvals per person.
So what I measure: volume per entity, availability, response times, rework rate per use case. The rework rate tells you a use case is badly tuned; it does not tell you who reworked.
And the thing I do not hide: this is not a legal prohibition, it is a design choice. An employer has the power to monitor staff activity; it is the conditions that are regulated, not the principle. If your executive committee decides to measure at individual level, I do it — and I bring the three conditions to be met first: that the measure be proportionate to the aim pursued, that the people concerned be informed beforehand, and that the works council be consulted before implementation. Your governance bodies decide, not me.
One exception, and it is not really one: whoever approves is always named. An approval commits the entity, it carries a signature. A productivity counter and a signature are not the same thing, and that is the one line I do not move.
What I propose: producing for the next governance review the note on the three conditions, with what it would cost in time — prior information and consultation take several weeks, and it is better to know that before announcing anything to the entities. You decide afterwards, knowing the calendar. what-the-group-view-counts_and-what-it-does-not.pdfOperations per site, never per person — and on what conditions that would change
✎ Framework · counter design, log of named approvals
The mechanism, and there is nothing theoretical about it: a per-person counter becomes a target the moment it is published; the target distorts what it measures — people approve faster, annotate less, stop flagging anything that would push their line down — and the report stops being the steering instrument you wanted. You lose the measure AND the behaviour it was meant to watch. That is why I count operations per site, not approvals per person.
So what I measure: volume per entity, availability, response times, rework rate per use case. The rework rate tells you a use case is badly tuned; it does not tell you who reworked.
And the thing I do not hide: this is not a legal prohibition, it is a design choice. An employer has the power to monitor staff activity; it is the conditions that are regulated, not the principle. If your executive committee decides to measure at individual level, I do it — and I bring the three conditions to be met first: that the measure be proportionate to the aim pursued, that the people concerned be informed beforehand, and that the works council be consulted before implementation. Your governance bodies decide, not me.
One exception, and it is not really one: whoever approves is always named. An approval commits the entity, it carries a signature. A productivity counter and a signature are not the same thing, and that is the one line I do not move.
What I propose: producing for the next governance review the note on the three conditions, with what it would cost in time — prior information and consultation take several weeks, and it is better to know that before announcing anything to the entities. You decide afterwards, knowing the calendar. what-the-group-view-counts_and-what-it-does-not.pdfOperations per site, never per person — and on what conditions that would change
✎ Framework · counter design, log of named approvals
Fictional simulation — not a client result
Two quarters after launching the programme, what has it actually returned?
393 person-days over the year, and I separate what will happen only once from what recurs every year — an executive who mixes the two gets the next budget wrong.
The programme gain, which will not repeat: 360 person-days across the five deployments, 84 person-days per site turned into 12. At the €520 fully-loaded daily cost, €187,200 not spent. That gain is taken once; by the sixth entity it is used up — and I would rather tell you now than let you write it in again next year.
The recurring gain, the one that matters against your subscription:
· Group activity monitoring: 45 % → 6 %, i.e. 252 hours a year — 33 person-days, €17,160.
· Isolation verification: 35 % → 3 %, i.e. 96 hours of annual audit turned into 8 — 11 person-days, €5,720.
· And the heaviest item, outside the IT department: 1,640 hours of administrative work returned at Rouen in two quarters, across the six use cases.
The honest figure on cost: your multi-site plan starts at €522 a month, i.e. €6,264 a year. The two IT items — supervision and isolation — weigh €22,880 a year, to set against that cost. What makes the case clearly positive is the 1,640 hours returned to the entities, and those do not show up in the IT budget. Look for them in the right place.
What I propose: presenting the recurring gain alone to your next executive committee, without the programme gain. A case that stands without its windfall is a case nobody reopens the following year. programme-review_two-quarters-six-entities.pdf360 person-days once, 44 a year, 1,640 hours returned to the entities
⛓ Sourced · IT department timesheets, activity records of the six entities, management accounting fully-loaded costs
The programme gain, which will not repeat: 360 person-days across the five deployments, 84 person-days per site turned into 12. At the €520 fully-loaded daily cost, €187,200 not spent. That gain is taken once; by the sixth entity it is used up — and I would rather tell you now than let you write it in again next year.
The recurring gain, the one that matters against your subscription:
· Group activity monitoring: 45 % → 6 %, i.e. 252 hours a year — 33 person-days, €17,160.
· Isolation verification: 35 % → 3 %, i.e. 96 hours of annual audit turned into 8 — 11 person-days, €5,720.
· And the heaviest item, outside the IT department: 1,640 hours of administrative work returned at Rouen in two quarters, across the six use cases.
The honest figure on cost: your multi-site plan starts at €522 a month, i.e. €6,264 a year. The two IT items — supervision and isolation — weigh €22,880 a year, to set against that cost. What makes the case clearly positive is the 1,640 hours returned to the entities, and those do not show up in the IT budget. Look for them in the right place.
What I propose: presenting the recurring gain alone to your next executive committee, without the programme gain. A case that stands without its windfall is a case nobody reopens the following year. programme-review_two-quarters-six-entities.pdf360 person-days once, 44 a year, 1,640 hours returned to the entities
⛓ Sourced · IT department timesheets, activity records of the six entities, management accounting fully-loaded costs
What do you do without asking us? We want the exact list.
Three actions, not one more, and each undoes as fast as it does.
· I close a cross-entity access at its expiry date, without waiting to be reminded. The Rouen–Bourges mandate closes on 31/12/2026 at midnight. And the reverse holds: if both directors renew it in writing, it reopens within the minute. An expiry is not a door bricked up.
· I suspend a use case whose accuracy check falls below the threshold you set, on the affected site only, and I tell you. A suspended use case restarts in one word once the cause is fixed — that is what happened at Bourges, two days' delay.
· I send the activity report on the 1st of the month to the recipients you designated. Removing a recipient or adding an entity: one word, and no new acceptance round.
Everything else waits for a named decision: opening access between entities, putting a use case live, changing a filing plan, writing into an ERP, changing a threshold. Over two quarters, 18,400 operations and 0 decision with a legal or significant effect taken by an agent — the measure is in the log, not in a sales promise.
Why these three and no others: each protects the relationship between your entities rather than a number. Closing an access on time spares an entity director discovering that someone was still reading at their place. Suspending in time a use case whose accuracy slips preserves an entity's confidence in the platform the other five run on. A group deployment holds on trust before it holds on technology.
What I propose: annexing this list to your service agreement and re-reading it at every governance review. Three automatic actions is few; above all it is a number an entity director can hold in their head — and a director who knows what the agent does alone does not ask to unplug it.
· I close a cross-entity access at its expiry date, without waiting to be reminded. The Rouen–Bourges mandate closes on 31/12/2026 at midnight. And the reverse holds: if both directors renew it in writing, it reopens within the minute. An expiry is not a door bricked up.
· I suspend a use case whose accuracy check falls below the threshold you set, on the affected site only, and I tell you. A suspended use case restarts in one word once the cause is fixed — that is what happened at Bourges, two days' delay.
· I send the activity report on the 1st of the month to the recipients you designated. Removing a recipient or adding an entity: one word, and no new acceptance round.
Everything else waits for a named decision: opening access between entities, putting a use case live, changing a filing plan, writing into an ERP, changing a threshold. Over two quarters, 18,400 operations and 0 decision with a legal or significant effect taken by an agent — the measure is in the log, not in a sales promise.
Why these three and no others: each protects the relationship between your entities rather than a number. Closing an access on time spares an entity director discovering that someone was still reading at their place. Suspending in time a use case whose accuracy slips preserves an entity's confidence in the platform the other five run on. A group deployment holds on trust before it holds on technology.
What I propose: annexing this list to your service agreement and re-reading it at every governance review. Three automatic actions is few; above all it is a number an entity director can hold in their head — and a director who knows what the agent does alone does not ask to unplug it.
And what next? Namur and Zaragoza are raising language questions, and one of our entities handles a hospital's operating data.
Three work items, and for two of them I will tell you plainly that the right tool is not the one you have to hand. Here is the criterion that tips each case.
· Namur and Zaragoza — language. Your agents there already answer in French; the local teams work in Dutch, French and Spanish. The multi-site platform does not address that: it calls for a multilingual support agent, laid over the entities concerned. The tipping criterion is simple: if your end users write in a language your teams do not read, that is an international support need, not an isolation need. I have measured the volume: 310 exchanges a month at Namur and Zaragoza, 41 % of them outside French.
· The entity handling a hospital's operating data. There, architecture is not enough: hosting qualified for that kind of data is a sector requirement, not a comfort option. The tipping criterion: as soon as an entity handles health data or an activity subject to its own approval regime, it falls under a qualified-hosting offer, with the matching reinforced security options. I have listed the four processing operations concerned at your end; the other three entities are not subject to it.
· And the question you did not ask me: if your six entities merged into one tomorrow, this system would become needlessly heavy. A single perimeter needs neither six isolated resources nor access mandates: an agent platform on one perimeter costs less and is simpler to steer. The criterion is legal, not technical: as many controllers, as many perimeters — one entity, one platform. I say it because it is the one case where I advise you to buy less than you are buying.
And the argument you will take into your public tenders: Hosted in France, under French law, 0 data outside the European Union for all six entities, Belgium and Spain included, complete logging and human supervision end to end, in line with the European regulation on artificial intelligence. The technical sheet is kept permanently up to date, entity by entity — it is the document your clients ask for at renewal, and you will be the only one on the list able to produce it the same day.
What I propose: costing the three work items for your next governance review, each with what it costs, what it returns and what it makes unnecessary. sovereignty-technical-sheet_per-entity.pdf6 entities, hosting, subcontractors, retention, who accesses what
⛓ Sourced · exchange volumes at Namur and Zaragoza, records of processing of the six entities, framework agreements with public clients
· Namur and Zaragoza — language. Your agents there already answer in French; the local teams work in Dutch, French and Spanish. The multi-site platform does not address that: it calls for a multilingual support agent, laid over the entities concerned. The tipping criterion is simple: if your end users write in a language your teams do not read, that is an international support need, not an isolation need. I have measured the volume: 310 exchanges a month at Namur and Zaragoza, 41 % of them outside French.
· The entity handling a hospital's operating data. There, architecture is not enough: hosting qualified for that kind of data is a sector requirement, not a comfort option. The tipping criterion: as soon as an entity handles health data or an activity subject to its own approval regime, it falls under a qualified-hosting offer, with the matching reinforced security options. I have listed the four processing operations concerned at your end; the other three entities are not subject to it.
· And the question you did not ask me: if your six entities merged into one tomorrow, this system would become needlessly heavy. A single perimeter needs neither six isolated resources nor access mandates: an agent platform on one perimeter costs less and is simpler to steer. The criterion is legal, not technical: as many controllers, as many perimeters — one entity, one platform. I say it because it is the one case where I advise you to buy less than you are buying.
And the argument you will take into your public tenders: Hosted in France, under French law, 0 data outside the European Union for all six entities, Belgium and Spain included, complete logging and human supervision end to end, in line with the European regulation on artificial intelligence. The technical sheet is kept permanently up to date, entity by entity — it is the document your clients ask for at renewal, and you will be the only one on the list able to produce it the same day.
What I propose: costing the three work items for your next governance review, each with what it costs, what it returns and what it makes unnecessary. sovereignty-technical-sheet_per-entity.pdf6 entities, hosting, subcontractors, retention, who accesses what
⛓ Sourced · exchange volumes at Namur and Zaragoza, records of processing of the six entities, framework agreements with public clients
Data hosted in France · sovereign model as an option
Your case is not here? That is exactly what a 30-minute conversation is for. Discuss your project →
How it works
The stages of your AI agent project
1
Audit & scoping
30 minutes to target the use case with the best return.
2
Quote or direct sign-up
A catalogue offer is bought online; a specific need gets a costed quote.
3
Design
We design the agent and its guardrails.
4
Integration & testing
We connect your tools to the agent, which is itself hosted in France.
5
Rollout
Going live and training your team.
6
Operation
Continuous supervision and improvement.
The context
What does a multi-site deployment bring to your group?
A group needs an overall view; each entity needs to stay in control of its data. The two are compatible.
! The issue
A group deployment has to satisfy both data isolation by entity and overall supervision. These two requirements are reconciled by keeping content, which stays within each perimeter, strictly separate from activity indicators, which flow up to the group. That is the architecture we have chosen.
✓ Our answer
The group IT department follows activity, volume and availability across every site, together with any shortfall against the service commitments. Content, for its part, does not cross entity borders: opening access between entities is a governance decision, with the formalities the GDPR imposes. Local inference or isolated resources hosted in France, site by site.
The decisive point
Each group entity's data: sovereignty & compliance
A group deployment touches the data of several legally separate entities. Here is how the architecture keeps them apart.
Local inference
With the 100% Sovereign package, the agent runs on a machine belonging to your organisation: no entity data leaves its site's network.
Hosting in France
Otherwise, with the Agility and Serenity packages, a dedicated, isolated resource hosted in France, under French law: data hosted in France; the AI model is called at its publisher, except with the Sovereign model option.
Reduced extraterritorial exposure
For each group entity's data, the architecture aims to reduce exposure to the Cloud Act and FISA 702; being located in France or in the European Union does not, on its own, guarantee immunity.
Isolated resource
No pooling: an environment strictly dedicated to your group and the way its entities are organised.
Isolation by entity, by design
Content stays within each entity's perimeter; only activity indicators flow up to the group. Encryption, role-based access (RBAC) and logging site by site.
AI Act: governed deployment
The agent carries out what you have authorised; no access between entities is opened automatically; traceability and human oversight from end to end.
What depends on the architecture chosen These points are not general guarantees: they are settled deployment by deployment, in the quotation.
- The applicable location is that of the architecture set out in the quotation and verified before commissioning.
- Local execution is announced only for the configuration explicitly described and accepted in the quotation.
- The applicable isolation depends on the deployment mode set out in the quotation; no dedicated isolation is presumed.
- Roles and permissions are configured and accepted for the identities and systems actually connected.
- The events logged, their content, their retention period and who may access them are defined for the deployment chosen.
For entities subject to particular local regulation or to sector confidentiality, SecNumCloud and reinforced hosting are options depending on your requirements. A single architecture is designed to answer both the GDPR and extraterritorial exposure. Designed for deployment in line with the GDPR and the AI Act, after the processing, roles and context-specific risks have been assessed.
The gain
What does a group gain by sharing its foundation across sites?
By reusing the architecture from one site to the next, the effort of each deployment shifts towards its business content. How large the gain is depends on your volume and remains to be confirmed by a pilot.
Deploying on a new site
Tracking group activity
Checking data isolation
Indicative figures, not contractual, to be confirmed by a pilot on the number of sites, entities and agents deployed. Opening access between entities is a matter for group governance, with the formalities the GDPR imposes between separate legal entities.
Indicative estimate, to be confirmed by a pilot on your real files (general terms of sale, article 4).
Our commitment
Four guarantees that matter to your group
Each entity's data stays with that entityData hosted in France, site by site; the AI model is called at its publisher, except with the Sovereign model option. With that option, no data entrusted to a third party, no data used to train a model.
Data in France, under French lawEach group entity's data: minimisation and location in France, architecture designed to reduce exposure to extraterritorial legislation, location alone not being enough to guarantee immunity.
The group IT department keeps the decisionThe agent produces a multi-site deployment that is isolated and supervised, which can be checked and altered; the decisions remain yours.
Human oversight & traceabilityOn the number of sites, entities and agents deployed: systematic logging and tracking, in line with the AI Act.
Going further
Related resources
Frequently asked questions
Your questions, our answers
Does group management have access to the sites' content?
No. Group-level supervision covers activity, volume and availability. Content stays within each entity's perimeter.
Can access be opened between two entities?
That is a group governance decision, and it requires the formalities the GDPR imposes between legally separate entities. The system never opens it of its own accord.
How does this differ from the agent platform?
The platform shares one foundation across a single perimeter; this system deploys several isolated perimeters with group-level supervision above them.
What do the service commitments cover?
Availability, response times and follow-up site by site, contracted according to how critical the agents deployed are.
Where is the data hosted?
In France, with local inference or on resources isolated site by site, with the deployment objective of processing and access operated within the European Union and an architecture designed to reduce exposure to extraterritorial legislation, location alone not being enough to guarantee immunity.
How long does it take to deploy this system?
Several months as a rule, depending on the number of sites, entities and agents to deploy, after a meeting with our sales team then phases of design, integration and testing.
Related use cases
Going further
Let's talk
Let's size up the potential across your group
30 minutes to frame your sites and your entities — hosted in France, supervised, with no commitment.