TL;DR: Clinical AI systems retrain on daily or weekly cycles. Auditors rebuild decisions from 90 or more days in the past. The model, its features, its preprocessing code, and its training data are all gone by then. An audit-defensible architecture captures inference context at the moment of prediction. It stores that context without change. Any past decision can then be replayed against the exact model that produced it.

Key Takeaways: - The 90-day gap is structural, not a process failure you can fix with better docs. - A model registry stores artifacts but not the universe that produced a specific inference. - Three layers make continuous learning auditable: immutable inference logs, rebuildable feature stores, and reproducible training pipelines. - Governance must include promotion gates, drift-to-outcome mapping, and quarterly replay drills. - A live audit trail compresses audit prep from weeks of log archaeology to hours of structured query.

Your clinical model has been retrained repeatedly since the last NABH audit cycle began. Each cycle produces a different artifact. The auditor will rebuild a decision from the model that existed on the day the decision was made. You have no guarantee that model, its features, or its training data still exist.

The 90-day window is structural. It is not a process choice. NABH accreditation cycles run annually. ABDM reviews happen at defined intervals. Payer audits arrive on their own schedule. They often come months after the clinical encounter that triggered them.

The model that made the decision is long gone by the time the auditor asks to see it.

Modern MLOps practice moves the other direction. Models retrain daily. Some retrain weekly on a fixed cadence. Others retrain on drift triggers, sometimes hourly. Feature pipelines shift as upstream hospital information systems that house the clinical decisions your AI influenced update schemas. Lab codes get remapped. Reference data refreshes.

The same patient record can produce different feature vectors on different days. Nobody is being reckless. This is just how production ML works in 2026.

The collision is where liability lives. An auditor asks: "Why did the model recommend treatment X for patient Y on date Z?" The system serving that decision has been overwritten dozens of times. The model artifact often exists in a registry. The exact features, preprocessing code, and training snapshot almost certainly do not.

You cannot prove what a destroyed model would have done. You cannot defend a decision whose reasoning you can no longer replay.

This is a CTO-level liability problem, not an MLOps hygiene problem. The legal exposure is asymmetric. A clinical decision that turns out wrong can be defended only if the model that made it can be rebuilt exactly. The cost of rebuild failure is the difference between a defensible decision and a negligence finding.

Most teams respond with a model registry. That sounds right. It is not nearly enough.

A model registry is a version control system for weights and code. It tells you which model version ran at inference time. It does not tell you what the model saw.

A registry that passes every test can still fail audit, as we covered in Your Model Registry Passes Tests. It Will Still Fail Audit.

Consider what an auditor actually needs to rebuild: - The exact feature vector the model received, not just the prediction it returned - The preprocessing code that turned raw clinical events into that feature vector - The training data snapshot that produced the model, with consent and source metadata intact - The upstream pipeline state, including which version of the hospital information system was feeding the model

The silent killer is feature drift. The same patient record produces different feature vectors on different days. Upstream HIS pulls change schemas. Lab codes get remapped. Reference tables update.

The model's "X" feature in January is not the same shape as "X" in April. Your registry shows the model version changed. It cannot show that the feature definition also drifted underneath you.

Training data is non-deterministic across runs even with the same seed. GPU ordering, library versions, and floating-point behavior all break bitwise reproducibility. Two models trained on the same snapshot with the same code produce different weights.

The only way to defend a model's training-era behavior is to rebuild it from declared inputs. Then verify the rebuild matches.

Auditors want to know more than which model ran. They want to know what data the model saw. They want to know what features it computed. They want to know whether the training set was itself compliant. The compliance surface for clinical AI extends well beyond the model artifact.

AI governance frameworks that explicitly address continuous learning make this surface explicit. Vanilla governance does not.

The hospital CISO gets the audit. The data engineering team inherits the rebuild. Neither is built to do it. So what does an audit-defensible architecture look like when the model never stops learning?

The architecture rests on three independent layers. Each captures a different link in the inference chain. Together they let you replay any past decision against the exact model, features, and training data that produced it.

Layer 1: Immutable Inference Log. At the moment of every clinical prediction, capture the input features, model version hash, code commit SHA, preprocessing pipeline version, and the prediction itself. Write this to append-only storage.

WORM buckets, signed log streams, and content-addressed ledgers all qualify. The point is non-repudiation. Once written, the log entry cannot be edited, backdated, or deleted. The log is the witness. Everything else is rebuilt from it. Without it, the auditor's question has no answer.

Layer 2: Reconstructable Feature Store. Store feature definitions as versioned code, not just values. When an auditor asks "what features did the model see," replay the exact change pipeline against archived raw inputs.

The feature pipeline that ran in production on the day of the decision is the only one that can answer the question correctly. Storing only the post-processing feature vector loses information the moment a feature definition changes. The raw input plus the versioned code is the only pair that survives drift.

Layer 3: Reproducible Training Pipeline. Containerized training with pinned dependencies, content-addressed datasets, and lineage tracking. A model version must be rebuildable from its declared inputs. If you cannot rebuild the model that produced a specific prediction, you cannot defend the prediction.

The training certificate includes the data SHA, code SHA, evaluation metrics, and the human sign-off that approved the version for production.

The key insight is simple: separate "what the model knows now" from "what the model knew then." Never delete. Only supersede. Always link the superseded version back to the inference logs it produced.

The cost of this discipline is storage and indexing complexity. The cost of skipping it is rebuild failure on audit day. These AI compliance patterns that turn continuous learning into a defensible position are not exotic. They are table stakes for any clinical AI that retrains.

This sounds clean in diagrams. The implementation is where most teams stall.

The architecture only works if the implementation is faithful. Each step below is a load-bearing decision, not a nice-to-have. For context on how healthcare AI vendors in India approach continuous learning and audit, the practical patterns look like this.

Step 1: Instrument the inference path. Wrap your model serving layer to write a signed, hash-chained log entry per prediction. Capture timestamp, patient encounter ID, feature vector, model SHA, code commit SHA, and a digital signature. The wrapper sits on the critical path of every prediction.

If a fallback path or degraded mode can bypass it, your audit trail has a gap. Treat the wrapper as production-critical code with its own tests and SLOs.

Step 2: Version everything. Training code, preprocessing code, feature definitions, training data snapshots, and model weights each get a cryptographic content hash. Store these in a model registry that understands the dependency graph, not a flat list of artifacts.

When an auditor asks what the model depended on, the registry walks the graph backwards from the model hash to the data, the code, and the environment. A flat list cannot answer that question. A graph can.

Step 3: Pin the feature pipeline at inference time. The serving system must lock to the exact feature computation code that was in production on the day of the decision, not the current version. This is the most common failure point in clinical AI.

Teams upgrade the feature pipeline to add a new lab mapping or a new reference table. The upgrade silently changes how past decisions would be rebuilt. The pin must travel with every inference log entry. It cannot be inferred later.

Step 4: Archive raw inputs alongside predictions. Storing only the feature vector loses information the moment a feature definition changes. You need the raw clinical event so the feature pipeline can be replayed later under a different definition.

Storage cost grows linearly with inference volume. Rebuild failure costs more. The Your AI Ships Daily. Your Risk Reviews Don't. problem is the same shape: speed of change exceeds speed of review.

Step 5: Build the auditor's replay tool. A query interface that takes a patient encounter ID and rebuilds the exact model behavior, feature values, and prediction that occurred on that date. The tool is what makes the architecture usable, not just correct.

Without it, your rebuild logic lives in a notebook on someone's laptop. That laptop is unavailable on audit day. The blueprint is not exotic. The discipline is.

Architecture without governance is just a pile of logs. The governance layer is what makes it survive a real audit.

The architecture produces evidence. Governance turns evidence into a defensible position. The blind spot in your AI stack that audits always find first is almost always governance, not the model itself.

Define a promotion gate. Training, validation, and production promotion are three separate steps. Every model version that enters production produces a lineage certificate: data SHA, code SHA, evaluation metrics, and a human sign-off. The certificate is the artifact an auditor reviews, not the model. Without the certificate, the version is a candidate, not a release.

AI governance practices that turn continuous learning into a compliance asset treat the promotion gate as a hard wall, not a checklist.

Map drift to clinical outcomes. Drift alone is not a problem. Unexplained drift in a clinical decision model is an audit finding waiting to happen. If your sepsis model's sensitivity moved three points last Tuesday, you should explain why within hours, not quarters.

Build a dashboard that links model behavior changes to clinical events, not just statistical metrics.

Map controls to frameworks. NABH standards cover clinical care documentation, patient safety, and quality improvement. ABDM's Health Data Management Policy governs how patient data is handled. HIPAA technical safeguards apply to US-facing systems. 21 CFR Part 11 enters the picture if your AI touches clinical trials.

Each framework wants a slightly different piece of evidence. A well-designed lineage certificate satisfies all of them. That is what AI compliance automation that reduces the manual audit burden actually delivers.

Set a retention horizon. Decide upfront how long inference logs, feature definitions, and model versions are kept. For clinical AI, indefinite retention of the inference log is the only safe default.

Storage cost is the constraint. Rebuild failure on audit day is the larger cost.

Run a quarterly rebuild drill. Pick three random clinical decisions from 90 or more days ago. Rebuild them fully. If the drill fails, the architecture has a gap. The cost is hours. The payoff is audit-day calm.

What changes when your clinical AI is continuously auditable rather than just continuously learning?

Audit preparation compresses from weeks of log archaeology to hours of structured replay. The auditor's question becomes a query, not a forensics project. Your team spends time on the question, not the search.

AI compliance outcomes that move beyond checkbox auditing look like this: a live trail, not a quarterly scramble.

Liability shifts decisively. You can now prove non-malfunction. That is the difference between defending a clinical decision and being unable to defend it at all. The rebuildable pipeline is your evidence. Its absence is your exposure.

Trust compounds. Clinicians stop treating the AI as a black box. Compliance officers stop treating it as a liability. Regulators stop treating it as an uninsurable risk. That trust is what allows faster deployment of new model versions without the usual governance friction.

The 90-day gap is not a problem you think your way out of. It is a problem you architect your way out of. Start with the inference log this week.

How often should clinical AI models be retrained? Retraining cadence should be driven by measured data and concept drift, not arbitrary schedules. Most production clinical models retrain on a weekly or biweekly cadence. Some run drift-triggered emergency retrains when upstream data shifts. The audit-defensible approach makes the retraining interval itself a documented policy, with promotion gates that log every model version transition.

What is the audit window for clinical AI in India? NABH accreditation cycles run annually. The operative audit window for clinical decisions is the retention period your hospital commits to. This is usually a minimum of three years for clinical records, and effectively indefinite for AI inference logs if you want to defend historical model behavior. There is no single mandated 90-day rule.