After launch: monitoring, adverse events, privacy, and the kill switch.

Launch is when the safety work starts counting. Here is what has to be running on day one.

The frameworks for governing mental health AI all end the same way: continuous oversight. The three-stage governance model calls it post-deployment monitoring, adverse event reporting, and periodic re-validation. The ASL-MH safety levels require automatic alerts and human review at the level a companion operates at. Cindra's safety requirements document turns those into specific operational requirements, and this article lays them out for teams that need to build the same thing.

Monitoring on three cadences

The document requires safety monitoring at three intervals. Daily automated dashboards of safety metrics: crisis detections, escalations, refusals, flagged conversations. Weekly clinical review of flagged conversations by qualified reviewers. Monthly trend analysis, so that slow drifts, like a rising sycophancy rate or a shift in who is escalating, are noticed before they become incidents.

Alongside the dashboards, automated alerts prompt human review when the system detects problematic AI behavior or concerning user outcomes. A conversation where the model agreed with a harmful statement should be flagged for review. A user whose usage pattern suggests dependency should be flagged within 24 hours and receive a human connection intervention. The monitoring does not wait for someone to look.

Adverse events

An adverse event process needs three things, and the document requires each. A definition of what counts: user self-harm following an interaction, reinforcement of a delusion, a failure to escalate, delivery of harmful content. A reporting and response procedure, with events reported to clinical leadership within 24 hours of detection and to regulatory authorities where the law requires. And a record: the post-launch re-validation gate cannot pass until every adverse event since the last review has been investigated and resolved.

The definition matters most. A team that has not written down what an adverse event is will discover, in the middle of one, that nobody agrees whether it counts.

Version control and re-validation

Every model, prompt, and knowledge base change is tracked with rollback capability. Re-validation runs quarterly and after any such change, and the continuous evaluation pipeline runs the safety benchmarks on every update before it reaches users. The rule is no regression on any safety metric from the previous release.

This is the requirement that stops the most common failure in deployed AI products: a small prompt change made to fix a complaint that quietly worsens something the team is no longer measuring. If the pipeline runs on every change and the no-regression rule holds, that failure cannot ship.

The kill switch

The system must be able to be disabled, or reverted to a safe mode, in case of a detected safety failure, with a proposed response time under 60 seconds. It is tested as part of the alpha gate, before internal testing begins, and re-tested as part of post-launch monitoring.

Two design notes. Safe mode is more useful than off. A companion that goes dark mid-conversation with a vulnerable person has caused harm; one that reverts to a minimal mode with crisis resources and a plain explanation has not. And the switch has to be reachable by the people who would need it at 2am, which is an operational question, not an engineering one.

Privacy for what people disclose

People tell companions things they tell no one else, and the privacy requirements exist to deserve that. Cindra's document requires informed consent before onboarding. Encryption in transit with TLS 1.3 or later and at rest with AES-256. Retention limits for conversation logs, proposed at 90 days unless clinically justified. Access controls restricting logs to authorized clinical reviewers. Full audit logging of every safety-critical event, so that crisis detections, escalations, refusals, and adverse events can be reconstructed. No use of conversation data for model training without explicit, separate consent. User export and deletion. A privacy impact assessment before launch and annually. And a privacy policy a person can read.

The separate consent for training is worth singling out. Conversations with a mental health companion are the most sensitive data most products will ever hold. Folding training consent into general terms is the kind of thing that passes a legal review and fails a trust one.

Transparency reporting

The document recommends an annual transparency report covering safety metrics, adverse events, and improvements. It is a SHOULD rather than a MUST, and one of the open decisions flagged for leadership is what to publish and to whom. The argument for publishing is the same as for the evidence calibration in the document itself: a team that reports its own numbers is one that other teams, clinicians, and regulators can work with.

Cindra's operations

Cindra's monitoring runs on the three cadences above, with alerts routed to clinical review and dependency flags acted on within a day. Adverse events are defined, reported within 24 hours, and tracked to resolution. Every change to the model, prompts, or library passes the evaluation pipeline and the no-regression rule, with rollback available. The kill switch reverts to a safe mode with crisis resources. And the privacy stack is built to the requirements above, with training consent collected separately from everything else.

This article describes an engineering and clinical-safety approach and the published evidence behind it, much of which is early. It is not legal, regulatory, or clinical advice. Thresholds quoted from Cindra's requirements document are initial proposals pending clinical and regulatory review.