How to Generate a Regulator-Ready AI Attestation Report

TL;DR

• Generic developer logs or verbal assurances don't satisfy EU AI Act Article 11 or MiCA Article 70 — regulators need a structured, signed attestation package.
• A complete package needs seven sections: entity ID, certificate details, scope of authorization, WORM audit excerpt, risk-scoring summary, revocation register, and executive attestation.
• Three named roles must sign off separately: compliance officer, CTO, and DPO (where personal data is involved) — one signature for all three is a red flag to examiners.
• Regenerate the package quarterly, on any material change (new certification, scope change), and immediately after any incident.
• Retain every generated version — don't overwrite — so a regulator can request the exact package that was accurate on any past date.

What must a regulator-ready AI compliance attestation package contain?

At minimum: entity identification, the AI agent's X.509 certificate details (serial number, KMS key ARN), its exact scope of authorization, a signed excerpt of the WORM audit log for the reporting period, a behavioral risk-scoring summary, a chronological revocation register, and a signed executive attestation statement. Three separate people should sign it — compliance officer, CTO, and DPO where personal data is involved — each attesting to a different category of claim.

Introduction: Preparing for Regulatory Audits

When supervisory authorities (such as BaFin, AMF, DPC, or national AI oversight boards) inspect an organization deploying autonomous AI systems, compliance teams must present a formal, tamper-evident Compliance Attestation Package.

Under EU AI Act Article 11 and MiCA Article 70, submitting generic developer logs or verbal assurances is legally non-compliant. Auditors demand a structured attestation letter verifying cryptographic proof of agent identity, certified scope boundaries, WORM audit log references, and executive sign-off.

---

Step-by-Step Report Generation Workflow

• Execute the Compliance Readiness Audit: Run your automated readout or access the Kakunin dashboard using our free online tool: [Free Compliance Readiness Report](/assessment).
• Access the Attestation Template: Open our printable attestation interface: [Printable Compliance Attestation Template](/attestation-template).
• Populate Required Regulatory Metadata: Fill in legal entity name, agent registration ID, certificate serial number, and AWS KMS key ARN.
• Export Signed PDF Package: Click Print / Save to PDF to generate the finalized document.

For complete regulatory mappings, consult our Regulatory Mapping Matrix.

What a Regulator-Ready Attestation Package Must Contain, Section by Section

A supervisory authority reviewing an attestation package is not evaluating prose — it is checking that each legally required element is present, internally consistent, and independently verifiable against the underlying system of record. A package assembled from screenshots or narrative summaries invites follow-up questions and, in the worst case, a finding of inadequate record-keeping. The safer approach is to structure the package as a fixed set of sections, each mapped to a specific evidentiary requirement, so an examiner can move through it the same way each time regardless of which agent or entity it covers.

At minimum, a Kakunin-generated attestation package should include the following sections, in this order, because this is the sequence most competent authorities expect when cross-referencing a filing against Article 11 technical documentation and Article 50 transparency obligations under the EU AI Act, and Article 70 governance requirements under MiCA:

• Cover letter and entity identification — legal entity name, registration number, jurisdiction of incorporation, and the name of the regulated activity the AI agent supports (e.g., algorithmic execution, client onboarding, custody operations)
• Agent identity certificate details — the X.509 certificate serial number, issuance date, validity window, and the AWS KMS key ARN (RSA_2048, eu-west-1) used to sign it, establishing cryptographic non-repudiation of the agent's identity
• Scope of authorization — the exact API scopes, transaction limits, and counterparties the agent was certified to interact with, since mTLS enforcement at the gateway rejects any request outside this scope by design
• WORM audit log excerpt — a signed export of the relevant audit_log rows for the reporting period, with a note that the table's database triggers block UPDATE and DELETE, which is itself the evidentiary basis for treating the export as tamper-evident
• Behavioral risk scoring summary — the agent's risk score trajectory across the period (0.00-1.00 scale), with any excursions toward the 0.85 auto-revocation threshold flagged and explained
• Incident and revocation register — a chronological list of any CRL/OCSP revocation events, including timestamp-to-revocation latency against the sub-60-second SLA
• Executive attestation statement — the signed declaration described in the next section, confirming the package's accuracy to the best of the signatories' knowledge

Internal Sign-Off: Who Attests to What

An attestation package is not a technical export — it is a formal representation to a regulator, and formal representations require named individuals accepting personal accountability for their accuracy. Kakunin's template enforces this by requiring three distinct sign-off blocks before the PDF can be finalized. Skipping any of them, or letting one person sign for all three roles, weakens the package's evidentiary value and is the kind of shortcut examiners are trained to notice.

Compliance Officer

The compliance officer (or MLRO/head of compliance in smaller CASPs) attests that the scope-of-authorization section matches the entity's actual regulatory permissions and that no agent is operating outside its licensed activity. This is the signature a supervisory authority will scrutinize first, since it directly ties the technical certificate to the regulated business line.

Chief Technology Officer

The CTO (or equivalent technical accountable executive) attests to the accuracy of the cryptographic and infrastructure claims — certificate issuance details, KMS key custody, mTLS enforcement, and the integrity of the WORM audit trail. This signature confirms someone with direct system access has reviewed the export rather than accepted it at face value from a dashboard screen.

Data Protection Officer

Where the agent processes personal data — most onboarding, KYC, and behavioral-monitoring agents do — the DPO attests that the audit log excerpt and risk scoring summary do not exceed the data minimization boundaries set in the entity's Article 30 GDPR processing record. This sign-off is frequently omitted by teams that treat the attestation as a purely financial-regulatory document, which is a mistake examiners in data-protection-forward jurisdictions (Ireland, Germany) will flag.

Regeneration Cadence: When to Produce a New Package

An attestation package is a snapshot, and snapshots go stale. Treating a single package as evergreen documentation is one of the more common findings in supervisory reviews of AI governance programs — the fix is a defined regeneration schedule tied to calendar cadence, material change, and incident triggers rather than to whenever an examiner happens to ask.

• Quarterly baseline — regenerate on a fixed calendar schedule (aligned to the entity's existing regulatory reporting periods where possible) even if nothing has changed, so the package's own generation timestamp demonstrates an active governance process rather than a one-time exercise
• On material change — any new agent certification, scope expansion, certificate renewal or re-issuance, or change to the auto-revocation threshold configuration should trigger an out-of-cycle regeneration before the change takes effect in production
• On incident — any risk score excursion that approaches or crosses the 0.85 threshold, any CRL/OCSP revocation event, or any manual override of an automated decision should trigger regeneration within the same reporting cycle, with the incident register updated first so the executive attestation statement reflects the resolved state

Worked Example: Submitting an Attestation to a National Competent Authority

Consider a mid-sized crypto-asset service provider licensed under MiCA that operates an autonomous trade-execution agent. During a routine supervisory review, the national competent authority (the entity's home-jurisdiction financial regulator) requests evidence that the agent's automated risk controls functioned as represented in the entity's MiCA Article 70 governance filing, specifically around a trading session three weeks prior where the agent's activity briefly diverged from its normal pattern.

The compliance team runs the Compliance Readiness Audit for the affected date range, then opens the printable attestation interface and populates it with the agent's registration ID and certificate serial number. The WORM audit log excerpt for the session in question shows the agent's behavioral risk score crossing 0.85 at a specific timestamp, followed by an audit_log entry recording certificate revocation propagated via OCSP, with the elapsed time between score threshold breach and confirmed revocation falling inside the sub-60-second SLA. Because the audit_log table's triggers block UPDATE and DELETE, this sequence cannot have been altered after the fact — a point worth stating explicitly in the cover letter rather than leaving the examiner to infer it.

The CTO signs off on the technical accuracy of the KMS key ARN and revocation timeline; the compliance officer signs off confirming the agent's trading scope was within licensed limits at all times, including during the divergence; and the export is submitted as a single signed PDF alongside a reference to the entity's standing Regulatory Mapping Matrix. In this scenario, the incident is not a compliance failure to explain away — it is the control operating as designed, and the attestation package's job is to make that legible to someone with no prior visibility into Kakunin's internals.

Keeping Packages Current as Agents Are Added or Retired

Attestation packages degrade fastest at the edges of an agent fleet's lifecycle — onboarding and offboarding — because these are the moments when the entity's actual agent roster and its last-filed attestation are most likely to diverge. A regulator comparing a package against a live system and finding an uncertified agent operating, or a certified agent no longer in service, treats the discrepancy as a control gap regardless of intent.

When a new agent is certified, its X.509 certificate details and scope of authorization should be added to the next scheduled or triggered regeneration rather than held for the following quarter — the material-change trigger described above exists specifically for this case. When an agent is retired, its certificate should be revoked through the standard CRL/OCSP path even if it was never subject to an automated risk-based revocation, and the retirement itself should appear in the incident and revocation register with a reason code distinguishing voluntary decommissioning from a risk-triggered action. Leaving a retired agent's certificate in an ambiguous or unrevoked state is a common gap: the certificate no longer authenticates production traffic, but its absence from both the active-agent list and the revocation register makes the package internally inconsistent.

Finally, maintain version control over the packages themselves. Each generated PDF should be retained (not overwritten) with its generation timestamp and the audit_log range it covers, so that if a competent authority requests the attestation as it stood on a specific past date, the entity can produce that exact version rather than a current one that silently includes later changes. Full field-level guidance for structuring this archive is covered in our attestation package documentation at /docs/attestation.

Treat this version history as part of the attestation infrastructure itself, not an afterthought bolted on once a regulator first asks for a past snapshot. A simple naming convention — entity ID, generation timestamp, and the audit_log sequence range covered — combined with write-once storage for the PDFs themselves means the archive inherits the same tamper-evidence guarantees as the underlying WORM data it summarizes, rather than becoming the one mutable link in an otherwise immutable evidentiary chain.

Common Mistakes That Weaken an Attestation Package

A handful of recurring mistakes turn an otherwise solid attestation package into one that invites follow-up questions rather than closing an inquiry. The most frequent is presenting derived summaries — a chart of risk scores over time, for instance — without a way to trace any individual data point back to the underlying signed audit_log row it was computed from. Summaries are useful for readability, but every summary figure in the package should be reproducible on demand from the raw evidence, not treated as authoritative on its own.

A second common mistake is omitting the negative case: reporting that no revocation events occurred during a period without stating how that absence was verified. 'Nothing happened' is a claim that itself needs evidence — specifically, confirmation that the monitoring pipeline was operational throughout the period and that the absence of revocation rows reflects genuine stability rather than a gap in ingestion. A third mistake is treating the attestation as a marketing document rather than a legal one — overstating certainty about system behavior in language an examiner will read literally rather than aspirationally. Precise, hedged, evidence-backed language consistently holds up better under scrutiny than confident claims the underlying data can't fully support.

Automating Attestation Generation Without Losing Rigor

As the regeneration cadence described above scales from quarterly to more frequent triggers, manually assembling each package becomes impractical, and automation risks stripping out exactly the human judgment that gives an attestation its evidentiary weight. The workable middle ground automates data assembly — pulling the correct audit_log range, computing the risk score summary, populating certificate and scope details — while keeping the executive sign-off step manual and deliberate. Automation should produce a complete draft ready for the compliance officer, CTO, and DPO to review and sign, not a document that gets auto-submitted without a human reading it first. Teams building this pipeline should log the automation run itself to audit_log, so the chain from raw data to generated draft to human sign-off is as traceable as the underlying compliance data it summarizes.

Handling Multi-Jurisdiction Attestations

Operators serving customers across multiple EU member states, or operating both under MiCA and a non-EU regime such as UK or US financial rules, often need to produce jurisdiction-specific variants of the same underlying attestation. Rather than maintaining separate manual documents, the more maintainable approach is a single canonical data export from audit_log and the certificate registry, with jurisdiction-specific cover letters and formatting layered on top at generation time. This keeps the substantive evidence identical across variants — the same signed rows, the same certificate details — while letting the cover letter and terminology match what each specific national competent authority or regulator expects to see.