GDPR audit & access log

betool is built to meet GDPR requirements without bolted-on compliance: every access to user content by an agent belonging to another organisation is logged, and every organisation can consult its own log.

The access log

A dedicated table records, for each cross-tenant access:

• The timestamp
• The target org (whose content was read)
• The reading org (typically the vendor)
• The user who triggered the read
• The tool the read went through
• The entity type (closed vocabulary: context for a conversation, scenario for a benchmark)
• The ID of the entity read (and the precise exchange when the read targets a single turn)

The entity vocabulary is closed at the database level (CHECK constraint) and closed at the code level (application whitelist). Adding a type requires a new migration plus whitelist update. No surprise entries.

Right of access (Article 15)

Each organisation can consult ITS OWN access logs, under Organisation settings → Privacy (Access log section) or via:

GET /api/admin/me/supervisor-reads

The route returns the reads in descending chronological order (up to 1,000 entries per call).

No cross-org access on the audit log: the vendor never sees a customer's audit logs.

Right to erasure (Article 17)

The architecture makes erasure cleanly executable: all of an organisation's data is attached to its org_id (business tables, file directories, secrets), which allows targeted erasure — a specific user, a specific conversation, or the entire organisation — without touching anything else.

Erasure requests (Article 17) are handled with our support: write to contact@betool.fr from an administrator account of the organisation concerned.

Cross-tenant read opt-in & opt-out

By default, the cross-tenant read opt-in is set to FALSE. An organisation administrator can enable it — and revoke it at any time — under Organisation settings → Privacy.

• Disabled — default. The vendor cannot access any content from this org. Consequence: no cross-org content-level support is possible (structural support remains available).
• Enabled — the supervisor can read the org's conversations for diagnosis, with every access audited and visible to the org.

The vendor CANNOT activate this opt-in on behalf of the customer. This is a fundamental test: if the vendor can toggle without a customer action, the architecture is broken.

Destructive-ops guardrail

Any operation that destroys or replaces content (DELETE, REPLACE-IN-PLACE) is refused at the validator if the target org has not activated the read opt-in. Rationale: without visibility, the operator would be proposing a payload that could blindly overwrite existing content.

Cascading denial if audit is unavailable

If the audit database is unavailable (infrastructure incident), all cross-tenant reads are refused. Strict policy: no read without a trace.

Code-side consequence: a caller that catches an exception must re-raise the audit error before any business processing. This is an invariant verified by the security benchmark.

Consent cookies

The marketing site (betool.ai) measures its audience with Google Analytics 4, in Consent Mode v2:

• By default, all Google consents (analytics, advertising) are set to denied: the Google Analytics script is not loaded and no analytics cookie is set.
• The script is loaded, and measurement enabled, only after your explicit acceptance of audience measurement in the banner.
• You can withdraw this consent at any time (Manage cookies, in the footer): measurement then reverts to denied.

Advertising consents remain denied: the site does no ad targeting.