1. Definition and scope

A Control Safety Case is a structured argument, supported by evidence, about whether an AI system can remain under control in a given deployment context. It makes explicit: the threat model, assumptions, control measures, control evaluations, residual risks, and a revision process.

• What it is: a reviewable document structure linking claims to evidence.
• What it is not: a badge, certification, regulatory approval, or compliance guarantee.
• Why it matters: it converts “control” from vague intent into auditable, testable assertions.

1. Définition et périmètre

Un Control Safety Case est une argumentation structurée, étayée par des preuves, visant à déterminer si un système d’IA peut rester sous contrôle dans un contexte de déploiement donné. Il explicite : modèle de menace, hypothèses, mesures, évaluations, risques résiduels et processus de révision.

• Ce que c’est : une structure révisable reliant revendications et preuves.
• Ce que ce n’est pas : un badge, une certification, une approbation régulatoire ou une promesse de conformité.
• Pourquoi c’est utile : rendre le “contrôle” auditable au lieu d’une intention vague.

2. Minimal structure (claims / arguments / evidence)

The core pattern is Claim → Argument → Evidence. A control safety case should be readable by a reviewer who did not build the system, and should discourage cherry-picking by making assumptions and limits explicit.

• Claims: what must be true for safe deployment under control (e.g., “control measures cannot be subverted to cause unacceptable outcomes”).
• Arguments: why the claim holds in this deployment context (threat model, mechanisms, mitigations).
• Evidence: control evaluations, red team results, monitoring data, incident history, and signed artifacts.

2. Structure minimale (revendications / arguments / preuves)

Le schéma central est Revendication → Argument → Preuve. Un control safety case doit être lisible par un relecteur externe et limiter le cherry-picking en rendant les hypothèses et limites explicites.

• Revendications : ce qui doit être vrai pour déployer sous contrôle (ex. “les mesures ne peuvent pas être subverties pour produire des issues inacceptables”).
• Arguments : pourquoi cela tient dans ce contexte (menaces, mécanismes, mitigations).
• Preuves : évaluations, red teaming, monitoring, historique d’incidents, artefacts signés.

3. Evidence taxonomy for control

Evidence should be tied to the deployment context and threat model. Typical evidence classes:

• Control evaluations: test whether control measures hold against realistic adversarial behavior.
• Red teaming: structured adversarial attempts to bypass or subvert controls.
• Monitoring and alerts: ongoing measurements, anomaly detection, human escalation gates.
• Integrity of evidence: signed logs, hashes, reproducible runs, provenance of results.
• Change management: versioning, patch notes, and reassessment triggers.

3. Taxonomie des preuves

Les preuves doivent être liées au contexte de déploiement et au modèle de menace. Classes courantes :

• Évaluations de contrôle : tester si les mesures tiennent face à des comportements adversariaux réalistes.
• Red teaming : tentatives structurées de contournement/subversion.
• Monitoring et alertes : mesures continues, détection d’anomalies, escalade humaine.
• Intégrité des preuves : logs signés, hashes, runs reproductibles, provenance des résultats.
• Change management : versioning, notes de version, déclencheurs de réévaluation.

4. Lifecycle: monitoring, incidents, revisions

A control safety case should be treated as a living artifact: updated when the system, environment, or threat model changes. It should define revision triggers and an incident pathway.

• Revision triggers: model updates, new tools/capabilities, new attack classes, policy changes, incidents.
• Incident handling: triage, containment, root-cause analysis, evidence preservation, and corrective actions.
• Review cadence: periodic review even without incidents, with explicit sign-off or governance review steps.

4. Cycle de vie : monitoring, incidents, révisions

Un control safety case doit être un artefact vivant : mis à jour lorsque le système, l’environnement ou les menaces évoluent. Il définit des déclencheurs de révision et une voie de gestion d’incident.

• Déclencheurs : updates modèle, nouveaux outils/capacités, nouvelles attaques, changements de politiques, incidents.
• Incidents : triage, containment, analyse cause racine, préservation des preuves, actions correctives.
• Cadence : revues périodiques avec étapes d’approbation/gouvernance explicites.

5. Adjacent terms and boundaries

The term “control safety case” sits next to related concepts. This site uses these terms descriptively:

• Control measures vs control evaluations: controls are the measures; evaluations are evidence they hold.
• Inability arguments: a related evidence style; often discussed as safety-case templates.
• Safety cases: legacy pattern in safety-critical engineering; here adapted to AI control contexts.

Boundary rule: this site does not maintain any “approved list”, “registry”, or “certification” marks.

5. Termes voisins et frontières

“Control safety case” se situe à côté de notions connexes. Ici, ces termes sont utilisés à titre descriptif :

• Control measures vs control evaluations : mesures vs preuves qu’elles tiennent.
• Inability arguments : style de preuve voisin, parfois présenté comme templates de safety case.
• Safety cases : héritage safety-critical, ici adapté au contrôle des systèmes d’IA.

Règle de frontière : aucun “registre approuvé”, “liste validée” ou marque de “certification”.

6. Procurement-ready language (examples)

These examples are informational only (not legal advice). They illustrate the kind of clarity a control safety case can support:

• Scope: “The control safety case SHALL define deployment context, threat model, and operational assumptions.”
• Evidence: “The control safety case SHALL link each critical claim to control evaluations and monitoring evidence.”
• Limits: “The control safety case SHALL document limitations, residual risks, and out-of-scope behaviors.”
• Updates: “The control safety case SHALL define revision triggers and a review cadence.”
• Integrity: “Evidence artifacts SHOULD be signed or otherwise integrity-protected.”

6. Langage procurement (exemples)

Exemples informationnels uniquement (sans conseil juridique). Ils illustrent la clarté qu’un control safety case peut apporter :

• Périmètre : “Le control safety case DOIT définir le contexte, le modèle de menace et les hypothèses opérationnelles.”
• Preuves : “Le control safety case DOIT relier chaque revendication critique à des évaluations et à des preuves de monitoring.”
• Limites : “Le control safety case DOIT documenter limites, risques résiduels et hors périmètre.”
• Mises à jour : “Le control safety case DOIT définir déclencheurs et cadence de révision.”
• Intégrité : “Les artefacts de preuve DEVRAIENT être signés ou protégés en intégrité.”