What counts as evidence

Every assessed interaction captured by AILP is structured, timestamped, and linked to a reproducible verdict:

The (redacted) input messages and model output.
The model and endpoint your product used.
Every framework expert's risk_level and reasoning.
The judge's synthesis that produced the overall verdict.
Which provider and model AILP used internally to perform the assessment.

That combination is what turns a monitoring dashboard into a defensible record — evidence you were watching for harms in real time and had a repeatable basis for every risk decision.

Exporting programme metrics

From a programme's Metrics & Reports page you can pull timestamped rollups of:

Total assessed interactions in the period.
Distribution across compliant, informational, low, medium, high, critical, and indeterminate.
Per-framework finding counts, so you can answer "how often did the EU AI Act rubric flag anything in Q1?".
Trend series over the period so the report can show whether risk is improving or worsening.

EU AI Act — Post-market monitoring

The EU AI Act requires operators of high-risk AI systems to run an active post-market monitoring programme: detect real-world safety issues, act on them, and keep evidence. AILP supports this directly:

Continuous coverage. The AILP client assesses every interaction, not a sample — so your evidence is that monitoring ran continuously, not selectively.
Framework alignment. Include the eu-ai-act slug in your client's frameworks to run the EU AI Act rubric on every log.
Evidence exports. Timestamped metrics and per-log detail pages give regulators and notified bodies the structured record the Act expects.

See the client-side selection guidance in Choosing frameworks and risk levels.

Product Liability Directive — litigation defence

Under the updated EU Product Liability Directive, AI systems are legally classified as products, meaning manufacturers and deployers can face direct liability for harms caused by defective AI outputs. In that context, the question in court is not "did an LLM ever go wrong?" — it's "did you operate a functioning monitoring programme?".

AILP helps you answer that with:

A timestamped, per-interaction record that survives long after the LLM traffic itself.
Judge and expert reasoning stored alongside the verdict, so a defensible explanation for each finding is preserved even if regulatory or product personnel change.
Programme metrics showing that monitoring was active across the period in dispute.

FCA Consumer Duty and regulated sectors

Firms regulated under the UK FCA Consumer Duty are expected to deliver good outcomes and avoid foreseeable harm to retail customers. When an AI product is in the loop, AILP supports that obligation by surfacing high-risk outputs before they become complaints. The same programme metrics and per-log evidence that satisfy EU AI Act reviewers also support Consumer Duty file notes and outcomes testing.

Internal audits and board reporting

Board packs — screenshot or export the risk distribution and trend charts from the programme's Metrics & Reports page. Pair with the assessed-interaction count for the period.
Internal audit — auditors typically sample individual logs. Use Consumer Log Analysis filters to assemble a reproducible sample (e.g. all high and critical verdicts in Q2) and share the filtered URL.
SOC / security reviews — the owasp-llm and mitre-attack frameworks are particularly relevant. Run them alongside your primary compliance rubric and extract the findings for security readouts.

What AILP is not

AILP captures and assesses AI interactions. It is not a legal opinion, and a risk verdict is not a regulatory filing — it's evidence for the humans who make those filings. Use the exports and detail pages as inputs to your legal, compliance, and risk-management processes, not as a replacement for them.

Privacy considerations

Because AILP redacts PII/PHI at ingress (before any LLM sees the log), every export and detail view you share internally already has placeholder-based content — you can circulate findings without re-redacting. If you need to correlate a redacted log back to a specific user, maintain that correlation in your own system using your original pre-redaction content rather than trying to reverse the placeholders.