Designing for auditability

A system a regulator can actually audit has to pass what's worth calling the reconstruction test: months after the fact, can you show exactly why the system produced a specific output for a specific input? If the honest answer is no, the system isn't auditable regardless of how well it performs, and that gap tends to surface at the worst possible time -- during an incident review or a compliance audit, not during a design review when it would have been cheap to fix.

Meeting that bar means logging the inputs, the retrieved context (for a RAG system), the exact prompt sent to the model, the model version, and the output, all tied together by a request id, from day one -- not bolted on after the first audit request arrives. It also means being deliberate about what a model is allowed to do autonomously versus what requires a human in the loop before an irreversible action, since "why did it do that" is a much easier question to answer when the answer is "a human approved it" for anything that actually mattered.