Compliance & governance

Administrators own the platform’s compliance posture: responding to data-subject requests, handling takedowns, keeping an auditable record of operator actions, and overseeing the content-safety floor. These surfaces live under Settings and Dashboards.

🎬 Compliance tooling tour

Prefer to read? Open the step-by-step transcript

1. Settings → DSAR management — log and fulfil GDPR data-subject access/erasure requests.
2. Settings → Takedowns — triage and decide takedown notices (Pending / Decided / All).
3. Settings → Operator audit log — an immutable record of who changed what, with revert where supported.
4. Dashboards → Compliance — attribution coverage and rights status across productions.

Data-subject requests (DSAR)

GDPR gives individuals rights over their personal data. Settings → DSAR management lets you log a request against a subject and platform, and record fulfilment. JARAI’s stance is informed-consent + transparency: the platform surfaces risks and records decisions rather than silently blocking.

Takedowns

Settings → Takedowns lists takedown notices filtered by Pending / Decided / All. The public-facing intake is documented in Submit a takedown notice. Each notice is acknowledged and worked to an SLA; decisions are recorded for audit.

Note

A legitimate takedown notice or GDPR complaint is a defined escalation trigger for the platform’s legal posture — handle promptly and record the decision.

Operator audit log

Settings → Operator audit log captures sensitive operator actions with a before/after snapshot, written by the platform’s audit service. Where an action is reversible, the log offers a revert. Treat the audit log as the source of truth for “who changed this and when”.

Content safety

JARAI runs a hard-floor content-safety classifier (Azure Content Safety + a blocklist) that blocks a narrow set of categories (e.g. CSAM, NCII, terrorism, GDPR-violating biometric use). Beyond that floor the platform’s default is to warn-and-log, not block — surfacing risk signals (copyright, likeness, privacy) as advisory while the publisher decides. The hard floor reproduces across environments via seed/bootstrap data.

Caution

The hard floor is deliberately minimal and not operator-tunable down. Adding new blocking classifiers is a policy decision, not a routine config change.

Trial-abuse review

Settings → Trial-abuse review surfaces sign-ups the platform flagged for abuse signals — a repeated IP, phone or payment card across trials. Each row shows the customer, the signals that fired, and the automated outcome: Passed, Blocked, or Suspended.

For a Suspended customer you make the call:

• Reinstate — resume the account and subscription (a note is required).
• Confirm block — permanently cancel the subscription (a note is required; this can’t be undone).

Each customer also carries a risk score that ticks up on payment disputes; you can reset it once a customer is cleared. Filter the list by outcome or search by customer to work the queue.

Note

Trial-abuse outcomes are produced automatically; your job here is review and the final reinstate/block decision — both recorded with your note for audit.

Attribution & rights

The Compliance dashboard tracks attribution-package coverage and rights status across productions, so you can see at a glance which deliverables carry complete source attribution. Per-platform rights review during approval is documented for customers under Approval and rights review.