SAFE-AI Brings Ethics Checks Into Medical AI Development Without Adding Heavy Governance
Artificial intelligence is now woven into patient-facing tools, decision support systems, and operational software across health care. The problem is not just performance. It is whether a model can be built, reviewed, and updated in a way that keeps bias, transparency, responsibility, and ongoing monitoring inside the development process instead of treating them as an afterthought.
A design-science project published in the Journal of Medical Internet Research lays out SAFE-AI — the Scalable Agile Framework for Execution in AI — as a practical response to that problem for small and medium-sized enterprises. The framework was created for organizations that move quickly, operate with limited compliance infrastructure, and still need a defensible way to document responsible AI practices. Its central premise is blunt: ethics cannot be bolted on only after a model is built, because most smaller teams do not have the time, staff, or process depth to create a parallel governance system from scratch.
The proposal is built around a simple operational idea. If an SME already works in Agile cycles, then ethical review should live inside those cycles. SAFE-AI does not aim to replace technical expertise or statistical judgment. Instead, it gives teams a lightweight structure for deciding when ethical review should happen, what needs to be recorded, and how responsibility metrics should travel with the model from discovery through monitoring.
A Four-Phase Framework Built for Iterative Development
The co-design process produced a four-phase lifecycle: discovery, assessment, development, and monitoring. Each phase includes checklists designed to blend acceptance, fairness, and transparency measures into routine sprint work. In practice, the framework is meant to make ethical oversight feel like a normal project function rather than a separate administrative burden.
That matters because AI governance often fails at the point of implementation. Organizations may endorse fairness or explainability in principle, yet those goals disappear when deadlines tighten or when a team has no dedicated ethics officer, compliance lead, or formal review board. SAFE-AI addresses that gap by embedding review triggers directly into standard development workflows, so the need for scrutiny becomes visible at the same time as the technical task that creates the risk.
The framework’s structure also reflects the reality of small teams. A large hospital system or academic center may have committees, legal staff, and formal review pathways. An SME usually does not. SAFE-AI is designed to remain usable in that environment by keeping governance “just enough” to be workable, rather than so elaborate that it is ignored.
Responsibility Metrics Move Beyond Abstract Ethics Language
One of the more distinctive pieces of the framework is a scenario-based probability analogy mapping method. The design converts model risk and uncertainty into plain-language narratives for nontechnical stakeholders, creating what the authors describe as a responsibility metrics layer.
This is not a cosmetic feature. In medical AI, the people building a model are often not the same people who approve its use, evaluate its consequences, or inherit its downstream errors. When risk is described only in technical language, clinicians and business leaders may never get a clear sense of how uncertainty could affect patients, workflow, or regulatory exposure. By translating probabilistic model behavior into narrative form, SAFE-AI tries to make uncertainty legible to teams that need to act on it.
That translation is especially relevant in health care, where an AI system can appear statistically sound while still producing unfair outputs across patient groups or failing quietly in a new setting. A responsibility layer that documents those risks throughout development can help prevent blind spots from hardening into product decisions.
External Clinical and Regulatory Input Shaped the Design
The framework was developed over 20 weeks through a design-science, practice-oriented process. After an initial discovery workshop, a cross-functional team came together with SME employees, ethics researchers, and academic partners. The SME contributed feasibility constraints and design realities during co-design, while external stakeholders were consulted through structured feedback sessions that included clinicians, health care domain experts, and regulatory specialists.
This broadened input is important because internal teams tend to optimize for what is easiest to ship. Clinical reviewers and regulatory specialists force a different question: what would be acceptable in a real health care environment, where bias, traceability, and accountability carry direct consequences for patients and organizations? Their feedback was folded into each prototype-feedback cycle, pushing the framework toward broader clinical and regulatory relevance instead of narrow in-house convenience.
No operational pilot or production deployment was conducted. The work stops at framework design, not field validation. The article therefore offers a governance architecture, not evidence that the framework improves patient outcomes, reduces bias in practice, or performs reliably under real-world deployment pressures.
Practical Value Depends on Adoption, Not Just Design
SAFE-AI’s main claim is modest but consequential: meaningful ethical safeguards can be embedded within the kinds of Agile workflows already used by many SMEs. The checklist-driven phases and automatic review triggers are intended to make fairness, transparency, and responsibility visible at the same pace as development itself.
In health care, that could reduce the common disconnect between model building and model accountability. A team iterating on a diagnostic or operational tool would not need to invent a separate ethics program for every sprint. Instead, the framework asks developers to document the right questions at the right stage, creating a traceable record of decisions, uncertainty, and oversight.
The limitation is equally direct. SAFE-AI remains a proposed framework, not a validated implementation study. Its value will ultimately depend on whether SMEs can actually use it without slowing development, whether its checklists remain meaningful under pressure, and whether its responsibility metrics stay useful once models move into live clinical or commercial settings. Those questions were not answered here, and the next step will require real-world testing rather than design-stage consensus alone.