Engineering Standard

Responsible AI Standard

This is the standard AI is built to at eazyCare.Ai. It is written for the people building the platform, and published so that patients, clinicians and partners can hold us to it.

Scope and status

This standard is binding on everyone building eazyCare.Ai — employees, contractors and integration partners alike. It applies to every model, prompt and automated pipeline that produces health-related output, whether that output reaches a patient, a clinician or a published page.

Work that cannot meet this standard does not ship. Where a requirement here conflicts with a delivery deadline, this standard wins.

It is a living document. Where we describe controls already enforced in the platform, we say so. Where a commitment is still being built, it appears on our security page under work in progress rather than being presented as done.

Our commitments

Seven commitments that govern how AI is designed, evaluated and operated here.

01

Human oversight is never optional

AI supports clinical decisions; it does not make them. Any output that could influence care is either reviewed by a licensed clinician or clearly presented as information rather than advice. No feature may be designed so that a clinician is removed from a decision they would otherwise make.

02

Users always know they are talking to AI

AI-generated output is labelled as such. We do not simulate a named clinician, imply human authorship, or design interfaces that blur the two. Where an answer draws on published guidance, it is cited so a reader can check the source.

03

Equity is a Southeast Asian requirement, not a footnote

Models and thresholds must be validated against the populations we serve. Clinical cut-offs that differ regionally — Asia-Pacific BMI thresholds are the clearest example — must use the regionally correct value. Evaluation is reported by language and population subgroup, not just in aggregate.

04

Patient data is not training data by default

Identifiable patient data is never used to train or fine-tune models without explicit, informed, revocable consent. We collect the minimum needed to deliver the service, and are building toward fully homomorphic encryption so records can be analysed without being decrypted.

05

Nothing ships without evaluation

Every model or prompt change affecting user-facing health output is evaluated before release: benchmark performance, adversarial and red-team testing for unsafe output, and clinical review where the change touches guidance content.

06

Monitoring continues after launch

Model behaviour drifts as providers update weights beneath us. We monitor output quality post-deployment, log AI-safety incidents, and maintain the ability to roll back to a previously validated configuration.

07

Every AI capability has a named owner

Each model in production has an accountable owner, a documented intended use, known limitations, and a change history. An AI capability with no owner is a defect.

Rules for developers

The commitments above, stated as things you can check your pull request against.

You must

  • Route any user-facing health output through the automated safety audit before it can publish or display.
  • Include an explicit escalation path — emergency guidance and a 'when to see a doctor' route — in any symptom-related feature.
  • Attach a medical disclaimer to informational health content.
  • Log the model, provider and prompt version used for any generated clinical content.
  • Use the regionally correct clinical threshold, and state which standard it comes from.
  • Fail closed: if a safety check cannot run, block the output rather than shipping it unchecked.

You must not

  • ×Generate a personal diagnosis, or language that a reader would reasonably read as one.
  • ×Emit specific drug dosages, or instruct a user to start, stop or change a medication.
  • ×Claim or imply that AI output substitutes for professional medical assessment.
  • ×Train or fine-tune on identifiable patient data without explicit consent.
  • ×Swap the underlying model or provider in production without re-running evaluation.
  • ×Suppress, weaken or bypass a safety check to make a feature ship.

How this is enforced today

These are not aspirations awaiting a process. Health content produced by our automated pipeline already passes a rule-based safety audit before it can be published, with checks that block output containing a personal diagnosis or specific drug dosages, and that require an emergency escalation route, a “when to see a doctor” section and a medical disclaimer to be present.

Failing a critical check blocks publication outright rather than lowering a score — content is routed to human review instead. Structural and readability checks run against both new and already-published content, so a page is held to the standard continuously, not only on the day it was written.

As the clinical product moves toward beta, the same gate model extends to patient-facing AI output, governed by the hazard process in our clinical safety standard.

Standards this is built on

We did not invent our own ethics framework. This standard implements requirements from established published guidance.

WHO — Ethics & Governance of AI for Health (2021)

Six core principles: protecting autonomy; promoting well-being and public interest; transparency and explainability; responsibility and accountability; inclusiveness and equity; and responsive, sustainable AI.

WHO — Guidance on Large Multi-Modal Models in Health (2024)

Obligations specific to general-purpose and generative models used in health contexts, including disclosure, evaluation and the risk of fluent-but-wrong output.

NIST AI Risk Management Framework 1.0

The Govern / Map / Measure / Manage cycle we structure AI risk work around, including documented context, measurable evaluation and post-deployment management.

ISO/IEC 42001:2023 — AI Management Systems

Management-system requirements for AI: defined roles, impact assessment, lifecycle controls and continual improvement.

ISO/IEC 23894:2023 — AI Risk Management

Guidance for identifying and treating AI-specific risk throughout the model lifecycle.

FDA / Health Canada / MHRA — Good Machine Learning Practice

The ten guiding principles for medical-device machine learning, including representative datasets, clinically meaningful performance and human-AI team performance.

EU AI Act (Regulation 2024/1689)

Referenced for its risk-tier model and transparency obligations. AI intended for health decision support attracts the strictest duties, and we design to that bar regardless of jurisdiction.

Referencing a framework means we build against its requirements. It does not mean eazyCare.Ai is certified against it — see security for our current certification status.

Read this alongside

Responsible AI covers how models behave. Clinical safety covers what happens when they are wrong.

Clinical Safety Standard