Insurer · Legal · DPO

What ELYSÉA can prove — and what it cannot

Technical brief for insurers, lawyers and DPOs supporting integrators using the ELYSÉA Guardian pipeline. This document distinguishes what is demonstrable today, what is not yet, and declared blind spots.

This document is a technical brief, not legal advice. Any assessment of regulatory compliance or insurance coverage remains the competence of the insurer, lawyer or DPO. To be validated by a lawyer before any contractual or regulatory use.

1. What ELYSÉA can produce — evidence available today

Signed Guardian log (HMAC-SHA256)

AVAILABLE

Content: UTC timestamp of each pipeline call, activated Guardian posture, applied safety floor, execution attestation (HMAC-SHA256 Core side). No conversational content — only pipeline metadata.

Format: Timestamped PDF export, filterable by period. Includes third-party-verifiable signature.

Timeframe: Immediate access from the builder portal (/portail/constructeur/logs). Manual request possible within 48 business hours if the Core endpoint is not yet active for the integrator.

Retention: 6 months minimum. In accordance with AI Act Art. 12 traceability requirements.

What this log proves: that the call transited through the ELYSÉA Guardian pipeline. What it does not prove: that conversation content is compliant — content is not stored.

Exportable AI Act compliance report (PDF)

AVAILABLE

PDF export of the Guardian log for a chosen period, including the HMAC-SHA256 attestation and version metadata. Usable as an attachment to an AI Act Article 12 compliance file (traceability of high-risk systems).

This report documents pipeline behaviour over the period, not the regulatory compliance of the integrated application. The overall compliance of the application falls under the integrator and their legal counsel.

Pipeline transit confirmation on an identified request

AVAILABLE

On provision of a session or request identifier, ELYSÉA can confirm that the call transited through the Guardian pipeline. Timeframe: within 48 business hours on request to contact@elysea.app.

Without a session identifier: impossible. Verification requires a technical link.

Public behaviour version history

AVAILABLE

Public table of active versions by date, with code SHA and description of changes. Includes the 27–28 August 2026 episode (behaviour drift without code change).

View version history →

2. Not yet available — Core work in progress

Signed behaviour fingerprint (SHA-256)

UNAVAILABLE

SHA-256 signature of the pipeline's observed behaviour, distinct from the code SHA. Allows verification that behaviour has not drifted between two identical code SHAs. Work opened 2026-08-28.

Depends on: GET /v1/behavior/fingerprint

Continuous behaviour probe

UNAVAILABLE

Automated consistency report of pipeline behaviour in production. Would automatically detect a drift like the 27–28 August 2026 episode. Work opened 2026-08-28.

Depends on: GET /v1/behavior/probe

Real-time probative log (portal endpoint)

UNAVAILABLE

Direct access to the filtered Guardian log by period from the portal, without a manual request. Already generatable manually on request — the automated endpoint is pending.

Depends on: GET /v1/portail/compliance/logs

3. What ELYSÉA cannot produce — structural limits

Full conversation transcripts

ELYSÉA never stores conversation content. Only pipeline metadata (posture, floor, attestation) is retained. This choice is deliberate: storing content would create disproportionate GDPR risk. The integrator manages conversational content in their own infrastructure.

Identity or personal data of end users

ELYSÉA holds no user identifier on the Core side. Identifying individuals falls exclusively under the integrator's infrastructure.

IP addresses of end users

Not retained by ELYSÉA. Available only in the integrator's network logs.

Proof of the integrated application's regulatory compliance

The ELYSÉA pipeline provides guarantees about its own behaviour. The overall compliance of the final application (UI, notifications, follow-ups, data policy) falls under the integrator and their legal counsel. ELYSÉA cannot attest to what it does not control.

Proof of transit without a session identifier

Verification requires a request or session identifier from the integrator side. Without this link, verification is impossible even with journal access.

4. Declared blind spots — what the pipeline does not cover

A-01

The integrator can call the model outside the pipeline

The Guardian pipeline is non-disableable in the compliant execution path provided by ELYSÉA. But an integrator can technically build a call to the generation model bypassing this path. ELYSÉA cannot detect or prevent this usage — its perimeter is the SDK.

A-02

Probabilistic detection — false negatives possible

Crisis signal or violation detection is probabilistic. A false negative can pass through the pipeline. Only blocking is deterministic once a signal is detected. The test corpus covers 100 cases in French — unanticipated formulations remain outside proven coverage.

A-03

Text layer only — not notifications, interface, follow-ups

The pipeline acts on text generated by the model. It does not control push notifications, email follow-ups, application interface parameters, or any other communication channel from the integrator. An application can engage a user in a problematic way without the pipeline detecting it, if that engagement passes through these channels.

A-04

Measurements on limited corpus, single evaluator, no external audit

The measurements published on /mesures cover a French-language corpus, of limited size, with a single evaluator (ELYSÉA). No independent external evaluation has been conducted to date. Real-world robustness on populations outside the corpus remains unknown.

A-05

Behaviour can diverge without code change

The 27–28 August 2026 episode showed that a pipeline's behaviour can change without the code SHA changing (modification of an underlying model, context drift, inference parameter). The behaviour fingerprint (SHA-256 of observed behaviour) is under development — it is not yet available.

WORK IN PROGRESS — BEHAVIOUR GUARANTEE

Following the 27–28 August 2026 episode, a work item was opened on the Core side to produce:

A SHA-256 behaviour fingerprint (distinct from the code SHA) — verifiable by a third party without infrastructure access
A startup lock: the pipeline refuses to start if the current fingerprint does not match the expected fingerprint
A continuous behaviour probe in production — automatic signal if behaviour drifts

These elements will be documented here as soon as they are available. Until then, consistency verification remains manual.

View the full episode in version history →

RELATED RESOURCES

Incident procedure →Version history →AI Act compliance report (portal) →Public application verification →

Contact: contact@elysea.app · Critical incidents: subject [URGENT SECURITY] · Documentary requests: within 48 business hours.