MQG4AI: A Living Lifecycle Blueprint for Responsible AI

MQG4AI began with a question that sounds small: which metric should we use to evaluate this model? I was working on multi-label ECG classification for emergency medicine during my PhD at the University of Augsburg, together with clinicians and engineers. The metric question turned out to have no clean answer. It depended on the clinical context, on the cost of a missed diagnosis versus a false alarm, and on choices made much earlier in the project that nobody had documented with this decision in mind. Guidance existed, plenty of it: ISO standards, regulatory texts, academic papers, ethics frameworks. What did not exist was a structure connecting that guidance to the concrete decision in front of us, or connecting that decision to the others it depended on.

That gap is the problem space MQG4AI addresses. Standards exist and regulation exists; the bridge to design does not. The EU AI Act made this concrete. Article 17 requires a quality management system for high-risk AI, and Article 9 a risk management system that runs across the entire lifecycle, including adjusting to its evolutions. These obligations are written at the level of requirements. Development happens at the level of decisions. Between the two sits knowledge that is scattered across standards bodies, domain experts, and implementation experience, and that keeps evolving as techniques and rules change. Today, every organization building AI in a regulated domain rebuilds this bridge from scratch. Interdependencies between decisions get lost along the way. Quality management risks degrading into a retrospective checklist instead of something that shapes design. Governance arrives after the fact, looking for artifacts that were never connected in the first place.

I found a precise description of the layer where this work sits in a line by Eva M. Erpenbach, connecting MQG4AI and the Erpenbach Institute: a system must first be made manageable, its complexity translated into signals and its situations turned into forms institutions can process, before it can be governed. And she names the accompanying risk, that the manageable version becomes mistaken for the system itself. MQG4AI is my attempt to operationalize that translation for AI lifecycles while designing against exactly that risk. The vision is to make the lifecycle accessible, transforming it into a tangible entity, queryable by human stakeholders and AI agents alike, without obscuring its decision-making complexity.

Technically, MQG4AI (Methodology based on Quality Gates for AI) is a generic, customizable information-management infrastructure for the AI lifecycle. Its building blocks are Quality Gates manifested by Information Layers and connected with supplementary contextual Information Blocks. All components provide sufficient flexibility to be adjusted to the scenario at hand:

• Quality Gates: hierarchical checkpoints that compose a project’s lifecycle decision-graph, from high-level phases such as conceptualization, data, development, deployment, maintenance, and decommissioning down to atomic decisions.
• Information Layers: Each atomic decision, a Leaf-QG, captures what was decided through the dimensions of content, method, and representation, records how the decision is evaluated, links to the decisions it takes input from and the ones it feeds, and connects to a risk management layer wherever it poses a risk or implements a control.
• Information Blocks: High-quality lifecycle decision-making requires access to supplementary information on e.g. the system’s intended use, relevant domain knowledge, involved stakeholders, and risk ontologies. These information models can be linked with the AI lifecycle.

Existing guidance enters as content on top of this structure. The EU AI Act, ISO/IEC 42001, ISO/IEC 5338, ISO/IEC TS 4213 and the NIST AI RMF are integrated rather than competed with, and the same holds for governance platforms, which plug in as content sources to design lifecycle information skeletons that guide implementation and ease compliance.

This is where the second half of the idea comes into play: a dual structure for decentralized learning. Shared design knowledge lives in a public layer (MQG4DK), while each project applies and adapts it in a private one (MQG4A). A project pulls a blueprint skeleton, a meta-standard for healthcare AI, generative applications or agentic systems, adjusts it to its own system, and can merge generalizable experience back into the shared layer without disclosing internals. Guidance stops being a static document and becomes a living meta-standard, updated continuously by the people applying it. Within a project (MQG4A), versioning keeps evolution traceable: a main lifecycle plus snapshots of design alternatives, comparable to Git-branching in software development.

I developed MQG4AI using Design Science Research and illustrated it through three cases. The first returns to the origin: metric selection for ECG classification, a high-risk use case under Annex III of the EU AI Act, showing alignment with ISO/IEC TS 4213 and Article 9 and how such guidance can be designed as reusable lifecycle templates (MQG4DK). The second is model selection for image segmentation on timed barium esophagram data, embedded in EsophagusVisualization, a tool we built with a small interdisciplinary team and that is used in active medical research at the University Hospital of Augsburg; it illustrates how a lifecycle evolves and is versioned (MQG4A). The third develops explainability Quality Gates aligned with the IEEE framework for explainable AI, deriving a workflow for high-level lifecycle design within MQG4AI through formalizing guidance for evaluating LIME and SHAP explanations. Medical AI is the illustration domain because that is where I worked and it can be interpreted as “our most vulnerable domain, we all live inside a body”; the architecture itself and its generic and customizable building blocks are domain-independent.

I want to be honest about the project's status, because transparency is part of the design. Every MQG4AI component is a proposition: designed and illustrated, not yet proven at scale. A living lifecycle blueprint cannot be authored alone. It only works through a critical mass of people who contribute what they see from their side, whether that is standards, implementation, or oversight. The dissertation and the publications lay the foundation; the open repository is where the structure is meant to grow.

Why do I believe it matters? Near-term, it gives organizations a way to operationalize responsible AI in evolving regulatory and clinical environments without rebuilding their methodology every time the standards and technology shift. The longer arc is incredibly fascinating to me. Imagine being able to query your AI lifecycle: a conversation with the system's documented decisions, adjusted to the stakeholder (or agent) asking, continuously bridging implementation and regulation. I call this the Socratic move, and it becomes more relevant as AI agents increasingly act alongside the humans in the lifecycle. Governance becomes representable. Implementation becomes tangible. If the approach matches what you see in your own work, or if you can show me where it does not, that exchange is exactly what the project needs.