Evidence & audits

A control that works but can't be shown to work is, to a regulator or an auditor, a control that doesn't exist. Evidence — the durable proof that controls operate as designed — is the currency of compliance, and generating it is a first-class governance activity. The difference between a program that passes an audit and one that scrambles is whether evidence was designed in or reconstructed after.

What counts as evidence

• Records the controls generate as they run — the append-only audit logs (who did what, when), eval and red-team results with dates and versions, monitoring dashboards, bias-test outputs, human-review sign-offs, incident records. The technical track's outputs are the evidence; governance ensures they're retained, dated, and tied to the system in the inventory.
• Documentation — impact assessments, the model inventory, data datasheets, the technical documentation the EU AI Act requires. The 'show your work' the law demands for high-risk systems.
• Immutability & retention — evidence that can be edited isn't evidence. Append-only logs and defined retention periods are why the engineering courses insisted the audit log be un-editable — it's a legal property, not a nicety.

The kinds of audit

First, the org design behind auditing — the three lines of defense: the first line is the teams running the AI systems, who own and operate their controls; the second line is compliance/risk, which monitors and tests those controls; the third line is internal audit, which provides independent assurance that the first two lines actually work — independence is its defining property. Second-line testing catches problems routinely; the third line is what boards and regulators trust, precisely because it doesn't report to the people it checks.

• Internal audit — the third line's periodic, independent check that controls operate: sample systems, verify each has its assessment, current evals, human oversight, and clean logs. Not the second line re-checking its own work — internal audit's independence from the teams and functions it examines is what makes its assurance credible, and it catches what routine testing missed before an external party does.
• External / third-party audit — an independent assessor verifying compliance, increasingly required (EU AI Act conformity assessment, ISO 42001 certification, customer due-diligence). Independence is the point: your say-so isn't enough for high-stakes systems.
• Algorithmic / bias audit — a specialized examination of a system's outcomes for discriminatory impact across protected groups. Legally mandated in places (NYC LL144 requires an annual independent bias audit for automated hiring tools, plus a published summary of the results, notice to candidates before use, and impact-ratio metrics by sex and race/ethnicity — directly hitting Meridian's HR tool for any NYC hiring). A distinct competency worth naming.

Audit-readiness as a design goal

The mature posture is continuous audit-readiness: because controls generate dated, immutable evidence automatically and the inventory ties it all together, you could face an audit any day with a query, not a fire drill. This is the exact philosophy behind Edova's products — Sentinel's continuous access audit, Vigil's always-on data-health evidence, the append-only logs in Sentinel and Vigil: they exist so that 'prove it' is answerable instantly. A governance program that has to prepare for an audit hasn't built the controls right; one that's always ready has.