Audit Log Validator: A Free Tool That Checks Your AI Audit Records Against EU AI Act and NIST Field Requirements

AI audit records that look complete in a Kibana dashboard often fail an Article 19 field check. The dashboard answers operational questions (latency, error rate, throughput). The Article 19 review asks a different question: can you reconstruct what happened on this specific request, who initiated it, what data class it carried, and which policy version was in effect.

The audit log validator scores a sample of your AI audit records against the three regimes most enterprise deployers face. The check runs in your browser, against records you paste or upload. No copy of the records leaves your environment.

What the validator checks

The validator runs three field-set checks in parallel.

EU AI Act Article 19

Article 19 names the fields that have to appear in the automatically generated logs for high-risk AI systems:

• Period of use (start and end timestamps)
• Reference databases checked
• Input data leading to the match
• Identity of natural persons involved in result verification
• Logs must persist at least six months

The validator flags a record as Article 19 compliant only if all required fields are present and the timestamps satisfy the period-of-use semantic.

NIST AI RMF MANAGE 1.3

MANAGE 1.3 asks the deployer to document risk responses for AI system actions. The audit record satisfies MANAGE 1.3 when it carries:

• The verified subject of the request
• The route (model vendor and model ID)
• The data class classification verdict
• The policy version identifier
• The decision and the reason code
• A tamper-evidence signature

Fannie Mae LL-2026-04 (effective August 6, 2026)

Lender Letter LL-2026-04 requires the lender to produce per-decision evidence on demand for any AI model that influences a credit decision. The audit record satisfies LL-2026-04 when it carries the MANAGE 1.3 field set plus:

• The model output hash (so the actual influence on the decision is reconstructable)
• The downstream consumer of the model output (which decision the output fed)
• The retention proof for the required 7-year window

How the validator runs

Paste a record or upload a NDJSON file. The validator runs each record through the three field-set checks and returns a structured report:

The recommendations are actionable. Each one maps to a specific field the audit writer has to add.

What "passing" actually means

A passing verdict means the field set is structurally complete. It does not certify that the policy was correct, the classifier was accurate, or the retention infrastructure is durable. A complete record from a misconfigured policy is still a complete record; it documents a wrong decision.

The validator's value is in catching the structural gaps before a regulator does. The classes of failures we see most often:

• Service-account identity. The subject field carries the application's service account, not the natural person on whose behalf the application acted. Article 19 fails.
• Unsigned records. The records are stored in an append-only collection but carry no signature chain. Tamper-evidence under MANAGE 1.3 fails.
• Policy version missing. The records carry the decision but not the policy that produced it. A regulator cannot pull the bundle in effect at the time. Both Article 19 and MANAGE 1.3 fail.
• Cleartext prompt in record. The records store the full prompt body for forensic reasons. The deployer has unintentionally created a GDPR derivative-storage liability. Article 19 does not require the prompt body; the input hash is sufficient.

Sample run from a deployer assessment

A pre-audit assessment we ran for a finance deployer in May 2026 scanned 11,300 records across two weeks of production traffic. The results:

• Article 19 passing: 24%
• MANAGE 1.3 passing: 18%
• LL-2026-04 passing: 0%

The 0% on LL-2026-04 was the headline. The deployer's audit writer did not record the model output hash and did not name the downstream consumer of the output. With LL-2026-04 taking effect on August 6, 2026, the gap was a 10-week scramble to close.

The MANAGE 1.3 gap was the tamper-evidence chain. Records were stored in a standard append-only store but did not carry HMAC signatures linking each record to the prior one. The fix was a config change in the audit writer plus a backfill on the existing records.

When to run the validator

Three triggers:

1. Before any compliance attestation. Score the existing audit records before signing the attestation that the field set satisfies the regime.
2. After a policy change. A new policy bundle may not propagate the policy_version field correctly to the audit writer. Re-validate.
3. During an audit. A regulator asking for evidence will ask for a sample of records. Run the validator on the sample before submitting it; the resulting report is the deployer's own pre-audit.

What the validator does not do

The validator does not check the content of the records, only their structure. A record that names the wrong subject (a fabricated identifier) will pass the structural check. Detecting fabricated content requires the broader audit infrastructure (tamper-evidence chain, identity provider correlation, retention store integrity check) that the validator does not run.

The validator does not produce the audit records. The deployer's gateway or audit writer produces them. The validator scores what is produced.

DeepInspect

DeepInspect's gateway produces records that satisfy EU AI Act Article 19, NIST AI RMF MANAGE 1.3, and Fannie Mae LL-2026-04 by default. The validator is the public version of the internal pre-flight the platform runs on its own outputs. Deployers running the platform see 100% on all three regimes from week one.

For deployers running other infrastructure, the validator names the gaps. The gateway closes them.

Try the validator at deepinspect.ai/tools/audit-log-validator.

If you are facing the August deadline, let's talk.