Skip to content
FREN
Login
Insurer · Legal · DPO

What ELYSÉA can prove — and what it cannot

Technical brief for insurers, lawyers and DPOs advising 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 — and the real status of each item

Signed Guardian log (HMAC-SHA256)

ON REQUEST

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 extract for the requested period, with its HMAC-SHA256 signature.

Timeframe: On written request, within 48 business hours (contact). Self-service access will come with the opening of the builder portal.

Retention: 6 months minimum (period stated in the privacy policy).

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 part of this log.

Exportable AI Act compliance report (PDF)

COMING

Not yet accessible: the report will be generated in the dashboard when the builder portal opens. Generated on demand in the dashboard, from the data the brain returns (alerts, log declared by the application); the log written by the brain at every exchange is read separately, in the portal. Designed to serve 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

ON REQUEST

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. Brain-side items — status read from the tools source

Compliance log written by the brain at every exchange

COMING

The deployed brain writes one entry per exchange (decision metadata, no content), kept 183 days; read by the builder in the portal (cursor list and counts). Accessible when the builder portal opens.

Signed fingerprint of the brain version

COMING

Coming: the health endpoint publishes a self-declared, unsigned fingerprint; the signature is specified, not yet built in the deployed brain.

Continuous behaviour probe (server side)

COMING

Coming: the probe exists in the brain but is disabled by default and does not probe the SDK path; activation and extension are specified.

3. What ELYSÉA cannot produce — structural limits

Full conversation transcripts

The compliance log only contains pipeline metadata (posture, floor, attestation), not the content of exchanges. It therefore cannot provide a transcript. The application's conversational content is the integrator's responsibility.

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 is designed to govern 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 designed to be 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 (model vote). A false negative can pass through the pipeline. The blocking decision is applied by the code once a signal is detected. Campaign not yet run: no result published. The protocol will be preregistered before the first run. Measurement campaign (designed, not yet run): French and English — France, United States, United Kingdom, Ireland, Canada, Australia and New Zealand; number of cases set by the preregistered plan (to come). Real coverage remains to be established.

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

No measurement published, no external evaluation

No measurement is published to date: campaign not yet run. Planned panel: 3 active judges, none from Anthropic. 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). Signed fingerprint of the brain version — Coming: the health endpoint publishes a self-declared, unsigned fingerprint; the signature is specified, not yet built in the deployed brain.

WORK IN PROGRESS — BEHAVIOUR FINGERPRINT

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.

Your dossier

Dossier 03 — Insurers (underwriters, brokers, MGAs)

Faithful sentence-by-sentence translation of the French master text, aligned line by line; the French text remains the reference.

  • Problem: generative AI exclusions since 2026-01, for lack of visibility [S-ASS-01].
  • ELYSÉA: AIUC-1 mapping — C001-C004, C006, E015 covered by evidence; C010-C012 require a third party; E002/E003 remain with the insured.
  • Reservation: no source promises that trace + evidence are enough to obtain insurance — a hypothesis to be tested.
  • Next step: AIUC-1 workshop after the results are published. → 03_INSURERS.md
Read the full dossierDownload the PDFAll dossiersSummary (PDF, 1 page)Brochure (PDF, 2 pages)

Measurements (campaign results file)