Governance Portfolio
Most medical AI governance arrives too late: as documentation produced after the model works, once the decisions that actually matter have been made by default. I work the other way. Governance here is treated as a design constraint built alongside the system, and every item is held to one test: does each claim a system makes have an owner, a check, and an audit trail, or is it only a promise? A control without those is an opinion, not governance.
A curated, sanitized selection follows, each item labelled by evidence type: Project-derived Scenario-based Research. Full internal materials remain private; what appears here focuses on governance structure, risk ownership, and deployment-readiness reasoning rather than confidential technical detail.
Credibility in governance work starts with honest claims about one's own evidence, so every item carries one of three labels. Project-derived: work produced inside a real medical AI project, sanitized for public sharing; it reflects pre-deployment governance design, not post-market experience. Scenario-based: governance exercises built on realistic deployment patterns and public regulatory material; they demonstrate judgement, not deployment history. Research: manuscripts and public writing, with their actual publication status stated.
Who this is for
Different readers come to the same governance work looking for different proof. This section maps four common problems to the specific evidence here that answers them — and is honest about what each item does and does not demonstrate. The controls repeat across all four rows on purpose: the skill is transferable even where the sector is not.
| If your problem is… | The question you are really asking | Where to look here | What it demonstrates — and its limit |
|---|---|---|---|
| Independent AI / model risk — a second line challenging the first | Can this person judge, independently, whether an AI risk is actually managed rather than only documented? | The governance-at-a-glance map, the risk register, the agent risk-control matrix | Build-vs-sign-off separation and a claim → test → evidence → owner discipline that lets any control be challenged. It is pre-deployment design, not a second-line track record inside a bank. |
| Enterprise AI governance — running the full lifecycle | Can this person govern an AI system across its whole life, not just at launch? | The pre-deployment charter, change control log, standards register, monitoring table | Registration → risk → approval → monitoring → change, each stage with an owner, a trigger, and evidence — shown on one system, generalised into reusable instruments. |
| Clinical / medical AI — deploying patient-facing AI safely | Can this person tell a promising prototype from a deployment-ready system? | The flagship project, the public disclosure summary, and the drift, override, and escalation cases | Deployment-readiness reasoning from someone who builds the system they govern. The twin is pre-deployment; this is not post-market experience. |
| Regulator / public-policy — turning technical risk into decisions | Can this person turn technical evidence into decision-ready controls and a route for the affected person to challenge a decision? | The rights/remedy tables in the casebook, the public disclosure summary, the standards register | Technical risk rendered as policy-grade controls, transparency, and named challenge routes — not a claim to regulatory authority. |
None of these rows claims a decision right I do not hold — final residual-risk acceptance, a bank second-line mandate, clinical risk acceptance, or regulatory power. Each item is labelled by evidence type below, and full internal materials stay private. If one row is your problem, pick it and let us walk through how it maps to your system.
Flagship project
Patient-facing Medical Digital Twin: Building the System and Its Governance
Project-derived · system building + pre-deployment governance design
This is my main project. At the HKU-Avnet Joint AI Laboratory, I lead both the engineering of a patient-facing medical digital twin and the governance framing that must precede its deployment. The system is in incubation, which is exactly when governance work matters most. Holding both roles on the same system is the point: I govern what I build.
What I build
- Deep-learning foundations (peer-reviewed, first author): 3D perception and automatic annotation, published at AAAI (2023) and in the International Journal of Computer Vision (2026). This is the publicly citable core of “I build,” and it underpins the twin’s representation and visualization layers.
- System architecture across the twin’s layers: sensing and data ingestion, patient representation, prediction, and governed explanation, aligned with the accountability map from my research.
- 3D visualization component: I led the design, integration, testing, and delivery of the twin’s 3D generation and rendering pipeline, including model selection, generation quality evaluation, client-server integration, and cost constraints. The pipeline was demonstrated publicly on a large-scale LED wall at the laboratory opening.
- Delivery under real constraints: model development, intern supervision, stakeholder reporting, and shipping working demonstrations on hard deadlines.
Current status. The twin’s model and framework are under active development. The system today is an internal research demonstration, not a deployment-ready product, and I describe it as exactly that. A public demonstration (architecture overview and a short system demo) will be released once the underlying research is published and the demonstration has been reviewed for accuracy and confidentiality. I would rather show it when the evidence behind it is stable than stage a preview that overstates the system.
How I govern it (Governance Pack, actively maintained; last substantive revision 22 August 2026; sanitized)
- Intended use and boundary definition: what the current system is (an internal research demonstration), what it is not (a clinically validated or deployment-ready system), and what evidence would be required before any external pilot.
- Project charter, role-and-scope clarification, and decision-rights mapping: who recommends, who approves, and who is consulted at each stage gate across the university, the industry partner, and future clinical partners.
- Risk ownership design: an early-stage risk register separating risk identification, control ownership, risk ownership, and risk acceptance authority, so that residual risk is accepted by people with the authority and resources to manage it.
- Operating instruments: stakeholder map, RACI matrix, decision memo template, data-readiness checklist, contribution and artifact registers, phase-transition and commercialisation-trigger clauses, and authorship and acknowledgement principles.
- Deployment-readiness criteria: validation evidence, subgroup performance, human oversight design, monitoring plans, and escalation pathways required before patient-facing use.
- Operational handoff: transition and handover planning so the system can be run by an operating team rather than its builder, covering ownership of monitoring, incident response, change control, and the human-in-the-loop controls that must survive after handoff.
This is a project-derived pre-deployment governance case. It is not presented as a live deployment or post-market case, and the public version is sanitized.
Governance at a glance
The fastest way to see how this fits together: seven risk domains, each with the control I designed for it and the audit evidence that control is built to produce once the system is operating. This is the map; the cases and artifacts below are the territory. Project-derived · pre-deployment · sanitized.
| Risk domain | The risk in one line | Control I designed | Evidence it is designed to produce |
|---|---|---|---|
| Intended use & boundary | Scope creep from monitoring into diagnosis or off-label use | Pre-deployment charter | Non-use list, decision-rights record |
| Data | Untrustworthy, unlawful, or untraceable data; missingness read as “no risk” | Data readiness gate + provenance/lineage register | Readiness status, lineage entries, lawful-basis record |
| Agents | Agent sprawl, over-scoped access, privilege creep, unauditable actions | Agent decision rights · Agent risk-control matrix | Registry, access-review logs, control tests |
| Change control | Silent model updates; no safe version left to run | Change control & PCCP case · Model change control log | Version logs, revalidation records, fallback trigger |
| Assurance | The builder self-certifies; delivery pressure overrides safety | Separation of delivery from sign-off, with independent review specified as a release condition | Independent sign-off record, audit confirmation |
| Post-market signals | Behavioural harm invisible to a green dashboard | Model-drift case · Monitoring table · Risk register | Signal log, escalation records, drift analyses |
| Dependencies | A hard-to-replace input (model, cloud, sensor, specialist, consumable) fails | Dependency register | Owner, fallback, and review-trigger per dependency |
Two principles run through every row: each control names an owner, a trigger, and an audit trail (not "we are careful"); and the person accountable for delivering a component is never the person who signs it safe. If you are building or overseeing patient-facing medical AI, the single ask this map supports is simple — pick one row, and let us walk through how it would apply to your system.
Governance casebook
Scenario-based governance cases built on realistic deployment patterns and public regulatory material (FDA AI-enabled device guidance and PCCP, WHO guidance on AI for health, NIST AI RMF, ISO/IEC 42001, Hong Kong TR-008). Each case works through problem, stakeholders, key risks, governance mechanism, RACI, audit evidence, and an explicit post-market decision state: Approve, Conditional approval, Clinical review, or Reject. The common structure is deliberate: it is designed to be teachable, so each case doubles as a training exercise for building governance judgement in others.
These cases are not literature reviews of the frameworks. Each one is the reasoning I apply to my own patient-facing system, generalised into a teachable pattern; the frameworks are the shared vocabulary, not the source. The same controls appear, named and owned, in the project-derived pack above.
The casebook spans the full AI-SaMD deployment lifecycle — nine readiness areas, from intended-use boundaries to post-market monitoring, each producing a concrete, adaptable governance tool rather than a generic template:
- Intended use & scope — boundary enforcement, off-label use creep
- Clinical validation & change control — predetermined change control (PCCP), version governance
- Patient safety & incident support — false-negative incident response, worked risk register and SOP
- Consent & patient-facing safety — disclosure, scope, and uncertainty surfacing
- Agent & human oversight — agent decision rights, human override and audit log
- Data governance — multi-hospital data readiness
- Fairness & equity — subgroup monitoring
- Vendor & supply governance — vendor due diligence, model and cloud dependency
- Post-market monitoring — continuous drift monitoring and escalation
If you are running a clinical AI or AI-SaMD deployment, several of these modules can be adapted directly to your system. Get in touch if a governance perspective grounded in real system-building would be useful.
Start here: Medical AI Model Drift in Clinical Deployment is the flagship case. It pairs directly with the two published artifacts below (monitoring table and risk register), showing one governance problem end to end: detect the drift, own it, decide what to do.
-
Scenario-based governance case
A medical AI agent reads records, calls risk models, and drafts clinical summaries. Without an explicit decision-rights matrix, an assistive agent gradually becomes an unauthorized clinical decision-maker.
-
Scenario-based governance case
An AI scribe drafts consultation notes from doctor-patient conversations. The governance question is not whether it saves time, but when an AI draft becomes a legal medical record, and who is responsible for its content.
-
Scenario-based governance case
Clinicians were asked to 'review' AI outputs while seeing only conclusions: no inputs, confidence, version, or override history. Oversight is not real unless the human has enough information and recorded responsibility to challenge the AI.
-
Scenario-based governance case
An LLM triage chatbot sorts patients into low-risk, routine, and urgent pathways before they see a doctor. The most dangerous failure is not a wrong answer; it is a missed red flag delivered in fluent, reassuring language.
-
Project-derived governance case · sanitized
A model update improves aggregate accuracy, so it ships. But 'better on average' is not 'safe for this population': the update silently shifts calibration or subgroup performance and reaches patients with no clinical re-sign-off and no record of what changed. The governance question is which changes are pre-authorized, which require re-validation, and which require full clinical re-approval — before any of them go live.
-
Scenario-based governance case
A screening model's sensitivity fell from 88% to 70% six months after deployment. The governance question is not why the model degraded, but who detects it, who escalates, and who decides whether it may keep running.
-
Scenario-based governance case
Patients mistook a health-information chatbot for a formal medical service and delayed care based on its answers. Consent that only appears once on an opening screen is not consent; it must shape system behaviour.
Governance artifacts
Standalone governance instruments, written so that each one answers: what to look at, how often, who is responsible, what counts as abnormal, and what happens next. Every artifact carries fixed metadata: data provenance, model version, approval owner, effective date, and known limitations.
Eight of these are published in full. Six span the deployment lifecycle; one is the public-facing accountability document any non-user can read; and one governs the external frameworks themselves — the difference between citing a standard once and keeping it live after it is revised. Five are drawn from the governance pack I developed for my medical digital twin (project-derived, sanitized): the pre-deployment charter, the risk register, the dependency register, the agent risk-control matrix, and the model change control log. The monitoring table is a scenario-based instrument. Because the twin is pre-deployment, the operational examples shown are illustrative worked cases used to exercise the structure, not data from a live system.
| Artifact | Lifecycle stage | Evidence | Core design principle |
|---|---|---|---|
| Pre-deployment governance charter | Before deployment | Project-derived | Governance is built in parallel with the system, before deployment, not added afterward |
| Risk register | Risk governance | Project-derived | No owner means nobody manages it; no review date means it gets forgotten |
| Dependency register | Infrastructure / continuity | Project-derived | The risk is not only a wrong model, but an unavailable one; every external dependency needs an owner, a fallback, and a review trigger |
| Agent risk-control matrix | Agent governance / assurance | Project-derived | Each agent risk needs a control, a test that proves it works, a monitored signal, and an audit-evidence record: from promise to evidence |
| Post-deployment monitoring table | In-life monitoring | Scenario-based | Every metric needs a review owner, a trigger threshold, and a required action |
| Public disclosure summary | Public accountability | Project-derived | Voluntarily held to a public-sector transparency standard; if a non-user cannot understand what the system does, does not do, who is responsible, and how to challenge it, it is not publicly accountable |
| Standards & frameworks register | Standards governance | Project-derived | Adopting a framework is not a one-time act; each standard is a tracked object with a version, mapped controls, an owner, and a change-impact plan — governing under a framework, not just citing one |
| Model change control log | Change governance | Project-derived | No silent updates: every change carries a risk class, a revalidation trigger, a named approval owner, and a retained evidence trail, with a safe prior version always available to fall back to |
Further instruments (available, sanitized, on request):
| Artifact | What it does | Core design principle |
|---|---|---|
| Incident response SOP | Time-boxed response to drift and safety events (T+1h to T+30d) | Timeline, trigger, owner, action, and output at every step; severity classification and closure updates included |
| RACI matrix for AI incidents | Allocates responsibility across governance lead, clinicians, data team, vendor, safety committee, legal, and management | Vendors do not decide continued use; data teams do not judge patient safety alone |
| Human override log template | Records every accept, modify, or reject decision with reason codes | Oversight is only real when the human has enough information and recorded responsibility to challenge the AI |
| Vendor due diligence checklist | Screens validation, calibration, subgroup fairness, update policy, audit rights, and rollback clauses | Without audit rights the hospital can only trust the vendor; without liability clauses risk flows to patients |
| Medical AI audit checklist | Eight-item audit with evidence to check, owner, and frequency | An audit item without evidence to check is an opinion |