Security & Trust · Confidentiality

Your data and simulations remain within explicit boundaries.

What data enters, where does it go, and how are engagements separated? A synthetic population is not a file of real people: it is built from statistical constraints and aggregated reference data.

Client

Question, context, and any proprietary data.

Imagine All The People

Preparation, population construction, simulation, delivery.

Potential external services

Technical services required by the selected configuration.

Three successive scopes: the client, the Imagine All The People environment, then any external services, separated by explicit boundaries.

Conceptual view. The external services actually used depend on the selected deployment level.
01What data enters

Four distinct types of data that should not be conflated.

  • Reference data

    Public statistics and aggregated data used to build and calibrate populations, without identifying individuals.

    Statut : EN PLACE

  • Client proprietary data

    Provided only when required by the engagement, under the applicable protocol.

    Statut : CONFIGURABLE

  • Potential personal data

    Until preparation and identifier reduction have taken place, data provided are treated as potentially personal.

    Status: TO QUALIFY

  • Population synthétique

    System output, generated under constraints: neither real people nor digital replicas of identifiable individuals.

    Statut : EN PLACE

02Data flows

The journey of a data item, from source to deletion.

  1. Source
  2. Preparation
  3. Processing
  4. Calibration / simulation
  5. Results
  6. Retention / deletion
Conceptual view. The level of qualification reached and retention periods depend on the engagement protocol and deployment configuration.
03Engagement isolation

One engagement should not become the raw material for another.

Client A

Engagement A

Questions, scenarios, results, and any proprietary data.

Client B

Engagement B

Questions, scenarios, results, and any proprietary data.

Conceptual view of separation between engagements. The effective level of separation depends on the selected deployment level (sovereign SaaS, dedicated hosting, air-gapped).
  • Engagement isolation

    Questions, scenarios and results are associated with an engagement and intended for the relevant client.

    Scope — Strengthened with dedicated hosting and air-gapped deployment.

    Statut : CONFIGURABLE

  • Cross-client reuse

    The architecture is not designed to use elements from one engagement for another.

    Scope — Commitment included in the contract where applicable.

    Statut : CONTRACTUEL

  • Team access

    Internal access is tied to teams assigned to the relevant engagement.

    Statut : CONFIGURABLE

  • Logging

    Access and operations are logged.

    Scope — Details on the Operational Security page.

    Statut : EN PLACE

04Use of inputs

Your questions should not become our training corpus.

  • No training on client inputs

    The architecture is not designed to train a shared model on the questions, scenarios or data from an engagement.

    Statut : EN PLACE

  • Processing limited to the engagement

    Inputs are processed to produce the requested result, within the scope of the engagement.

    Statut : EN PLACE

  • No self-training

    Commitment documented in the general terms and enterprise clauses.

    Statut : CONTRACTUEL

  • Third-party review

    A client may engage an independent external audit to examine it.

    Statut : CONTRACTUEL

05Client data

Three distinct classifications.

Aggregated
Grouped data describing a set, not an individual.
Pseudonymized
Direct identifiers replaced; re-identification remains possible with additional information.
Anonymized
Re-identification reasonably impossible; this level is assessed case by case.

Regulatory classifications and roles of the parties: see the dedicated page. Understand the regulatory scope →

06Access and commitments

What is provided for technically is made enforceable by contract.

  • Engagement access

    Access restricted to teams assigned to the relevant engagement.

    Statut : CONFIGURABLE

  • No self-training

    Contractual commitment not to use inputs for training.

    Statut : CONTRACTUEL

  • Contractual isolation

    Separation between engagements and clients reflected in the applicable clauses.

    Statut : CONTRACTUEL

  • Data handling at the end of the contract

    Return or deletion according to the terms set out in the contract.

    Statut : CONTRACTUEL

07Limitations

Isolation reduces one area of risk. It does not eliminate risk.

  • Isolation ≠ invulnerability

    Logical or physical separation of environments does not eliminate operational risks: access, operations and human error still need to be addressed.

  • Identifier reduction ≠ automatic anonymization

    The effect of preparation depends on the process applied and the residual re-identification risk.

  • No training ≠ no processing

    Inputs are processed to produce the requested result, even when they are not used to train a model.

  • Confidentiality ≠ availability

    Protecting access to data does not guarantee service continuity, which is an operational matter.

Continue

Where the environments run and which controls are operated: see hosting → et operational security →

Contact the team →

Your next decision

Which decision do you want to explore?

Describe your need. We can point you to the right level of support.

What if you tested
your next decision?

State your decision. See the future it produces.

Explore the product