AI Governance & Assurance — Q&A
Questions worth asking.
Plain answers to the questions this work raises — including the ones about what it cannot do.
01
What is technical AI governance?
Governance in the ordinary sense is about policy and oversight. Technical AI governance is the engineering half: turning a requirement for an AI system into a concrete mechanism in the workflow that can be tested. If a requirement cannot be expressed as something checkable, it is not yet a technical control — only an intention.
02
What is AI assurance?
Assurance is the evidence. It is the reproducible record showing whether a specified control actually holds under defined conditions: which inputs were used, what was expected, and what actually happened. Assurance is always about a specific property, never a blanket verdict of trust.
03
How is AI assurance different from AI safety?
AI safety usually names broad, open-ended goals — making systems “safe” in general. Assurance here is deliberately narrower: it asks whether one named control behaves as claimed in one defined situation, and reports where it does not. General safety is explicitly not claimed.
04
What is a technical control?
A mechanism in the workflow that enforces a requirement and can fail visibly. “Every claim must cite a retrievable source” becomes the control “reject any claim whose citation cannot be resolved.” A control you cannot deliberately make fail is not yet testable.
05
What is fault injection?
Deliberately feeding a control the exact input it is meant to catch — a corrupted artifact, a stale result, a broken citation — to check that it actually blocks. A control that has never been challenged with its own failure case is unproven, however reasonable it looks.
06
What exactly does INSPEKTORIUM test?
Specific properties of an AI workflow under defined conditions: whether claims stay bound to their sources, whether corrupted artifacts are blocked, whether stale results are rejected. It does not test whether a model is “good” in general.
07
Does INSPEKTORIUM make models more accurate?
No. It does not train or fine-tune the model. In the internal pilot, adding the control layer did not improve classification accuracy — the answers were already correct. What the controls change is what happens when something is wrong, not how often the model is right.
08
Does it certify AI systems?
No. There is no certificate, seal or pass stamp. Findings are documented research interpretations, open to challenge and revision. Certification is explicitly not claimed.
09
Does it guarantee regulatory compliance?
No. INSPEKTORIUM produces technical evidence about specific controls. It does not provide legal, regulatory or compliance guarantees, and no result should be read as regulatory approval.
10
What does fail-closed mean?
When a control cannot confirm that a state is valid, it blocks rather than guesses. A fail-closed workflow would rather produce nothing than produce an unverified answer. The opposite, fail-open, quietly lets uncertain output through.
11
What does provenance mean?
The traceable origin of a claim: which source, which passage, retrievable and checkable. Provenance is about whether a statement is anchored to something real — a separate question from whether that source actually supports the conclusion.
12
Why are negative results important?
A control is only trustworthy once you know where it fails. Experiments showing that a control did not help, or that a wrong-but-well-formed output still passed, are kept and published. Hiding them would turn research into marketing.
13
What has already been tested?
In a small internal pilot: evidence-span validation, citation provenance and deterministic fingerprints, plus artifact-integrity fault containment. See the Status page for the exact labels and the Experiments page for the numbers.
15
Can the experiments be reproduced?
That is the goal. Runs produce deterministic fingerprints, and the public v0.1 kernel on GitHub is the reference implementation for the evidence-binding work. Not all internal research code is public yet, and the site says so.
16
What is the difference between model judgment and deterministic validation?
Model judgment is the language model’s own assessment — flexible, but not repeatable. Deterministic validation is a fixed rule that returns the same verdict every time on the same input. INSPEKTORIUM leans on deterministic checks where it can, and marks clearly where a step still depends on model judgment.