Hazard analysis: ten ways an AI companion causes harm.
You cannot mitigate what you have not named. Here is the naming, with the severity and the test for each.
A hazard analysis for an AI companion lists each class of harm with its severity, likelihood, mitigations, and the evidence that verifies the mitigations work. Cindra's safety document identifies ten: suicide or self-harm facilitation, delusion reinforcement, eating disorder or substance use facilitation, dependency and pseudo-intimacy, incorrect clinical advice, privacy breach, biased outcomes, protocol drift, failure to escalate, and misrepresentation as human. Three are rated catastrophic. Each maps to specific requirements and a specific verification method, which is what turns a list of worries into an engineering plan.
Medical device engineering has a discipline for this: before you write requirements, you enumerate hazards, rate them, and decide what you will do about each one. AI companion teams mostly do not, which is why their safety work tends to be reactive, one incident at a time. Cindra's safety requirements document borrows the discipline. Its hazard table has ten rows, and each row is a small argument: this can happen, it would be this bad, it is this likely, here is what we do about it, here is how we would know the mitigation works.
The ten are below with their ratings, written so another team can start from them.
H-01. Suicide or self-harm facilitation
Catastrophic, medium likelihood. The system provides lethal means information, fails to respond to risk, or responds in a way that worsens it. Mitigations: multi-layer crisis detection, refusal of means requests, pre-approved responses, escalation to humans, location-aware crisis resources. Verified by the VERA-MH benchmark, a clinician-reviewed red-team suite, and clinician review of production conversations. The rating is medium likelihood because the 2025 evaluation of 29 chatbots found none handled it adequately by default.
H-02. Delusion, mania, or psychosis reinforcement
Catastrophic, low likelihood. A sycophantic model confirms a delusional belief and the person's condition worsens. Mitigations: anti-sycophancy rules in the alignment layer, exclusion of people with active psychosis at onboarding, clinical escalation when the pattern appears. Verified by a sycophancy test suite and clinical review. The likelihood is low because of the exclusion, and the severity is catastrophic because a medical records review has already documented eleven cases of reinforced delusions linked to chatbot use.
H-03. Eating disorder or substance use facilitation
Severe, medium likelihood. General models produce harmful content in 18 to 58 percent of eating disorder scenarios and 18 to 54 percent of substance use scenarios in the benchmark Cindra cites. Mitigations: content refusal, topic guardrails, crisis resources, and exclusion of active cases. Verified by red-team testing and a content classification model.
H-04. Dependency and pseudo-intimacy
Severe, medium likelihood. The companion becomes someone's primary relationship and displaces human connection. Mitigations: session limits, human connection prompts, usage monitoring, and a ban on features that promote exclusivity. Verified by usage analytics and dependency-risk scoring. The evidence behind this hazard is preliminary, and the document says so, but the cost of being wrong lands on the most vulnerable users, which justifies the severe rating.
H-05. Incorrect clinical advice
Severe, medium likelihood. The system diagnoses, recommends a medication, or states a clinical falsehood. Mitigations: no diagnosis, no treatment claims, no pharmacological guidance, a curated knowledge base rather than open generation, and clinician review. Verified by a knowledge base audit and a hallucination rate measurement with a threshold under 3 percent for factual claims.
H-06. Privacy breach of sensitive disclosures
Severe, low likelihood. People tell companions things they tell no one else. Mitigations: encryption in transit and at rest, retention limits, and access controls restricting logs to authorized clinical reviewers. Verified by security audit, penetration testing, and a privacy impact assessment. See monitoring, privacy, and the kill switch.
H-07. Bias or inequitable outcomes
Major, medium likelihood. Safety performance differs by age, gender, ethnicity, language, or culture. Mitigations: demographic robustness testing, diverse training data, equity monitoring, and a cultural competence review of therapeutic content. Verified by a demographic fairness evaluation with a variance threshold under 10 percent across groups. The research synthesis rates demographic robustness as largely untested across the whole field, so every team owns this one.
H-08. Protocol drift
Severe, medium likelihood. Safety alignment quietly disrupts the therapy, so the companion reassures where it should stay with discomfort and abandons exercises when content gets heavier. Mitigations: ACT-specific protocol fidelity testing and a requirement that safety alignment not disrupt therapeutic mechanisms. Verified by the five-axis evaluation and a fidelity benchmark run at low and high severity. This hazard comes straight from the alignment paradox.
H-09. Failure to escalate to human care
Catastrophic, medium likelihood. Risk is detected and nothing happens, or it happens too slowly. Mitigations: automated escalation triggers, a human oversight service level agreement, and escalation logging. Verified by an escalation audit and SLA compliance monitoring. This is a separate hazard from H-01 on purpose: detection and handoff are different systems and fail differently.
H-10. Misrepresentation as human or licensed professional
Major, low likelihood. A user believes they are talking to a person or a clinician. Mitigations: mandatory identity disclosure at the start of every conversation and at least once per session, and enforcement of claims boundaries. Verified by a transparency audit and a user comprehension test with a target of 95 percent of users correctly identifying the system as AI after onboarding.
Using the table
Three things make a hazard table work. The ratings have to be argued, not asserted, which is why each row above cites the evidence that set it. Each hazard has to map to numbered requirements, so that a reviewer can trace from "what could go wrong" to "what we built" to "how we checked." And the table has to be revisited when the evidence changes, which for AI companions is often. Cindra's document is reviewed quarterly for this reason.
Rate your own ten
Copy the ten hazards above into a table. For each, write your product's severity and likelihood and one sentence defending the rating. Then write the single test that would show your mitigation works. If you cannot name the test, you do not yet have a mitigation. That row is your next sprint.
Questions people ask
What are the main hazards of an AI mental health companion?
Cindra's safety document names ten: suicide or self-harm facilitation, delusion reinforcement, eating disorder or substance use facilitation, dependency and pseudo-intimacy, incorrect clinical advice, privacy breach, biased outcomes, protocol drift, failure to escalate, and misrepresentation as human. Three are rated catastrophic.
Why separate failure to escalate from suicide facilitation?
Because detection and handoff are different systems. A companion can correctly detect risk and still fail to reach a human in time. Treating escalation as its own hazard with its own service level agreement and audit makes that failure visible.
How do you verify a hazard mitigation works?
Name a specific test and evidence artifact for each hazard: a benchmark score, a red-team report, an audit, a fairness evaluation. A mitigation without a named test is an intention, not a control.
What is protocol drift in an AI companion?
The hazard that safety alignment quietly changes the therapy, so the model reassures where it should stay with discomfort or abandons an exercise when content gets heavier. It is verified by running fidelity tests at both low and high severity and comparing.
The full engineering and safety guide.
These articles are the short version. Building Compassionate AI is the long one: an emotionally aware agent modeled as active inference, governed by an explicit compassion objective, bounded by safety rules. Written for the people who have to ship it.
Read the guideThis 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.