What to Log for AI Compliance: The Eight Fields Every Per-Decision Record Needs
EU AI Act Article 19, Fannie Mae LL-2026-04, HIPAA, and SOC 2 with AI all converge on a per-decision record. The vocabulary differs across regimes. The fields do not. This piece walks through the eight fields every per-decision record needs to satisfy the converged requirement: identity of the natural person, identity of the agent, role and scopes, data classification, policy version, model and route, decision outcome, and a tamper-evident timestamp.
EU AI Act Article 19, Fannie Mae LL-2026-04 effective August 6, 2026, HIPAA's Security Rule applied to AI workloads, and SOC 2 controls for AI usage all converge on the same artifact: a per-decision record of what the AI system did, who initiated it, and what policy governed the decision. The vocabulary across regimes differs. The fields do not. Eight specific data points carry the weight of the converged requirement, and applications that omit any of them produce records that cannot be reconstructed during a regulatory review.
I want to walk through the eight fields a per-decision AI record needs, where each comes from at runtime, and what fails when the field is missing.
The eight fields
Each field below is referenced by at least two regulatory regimes. Where a field has a specific regulatory anchor, the citation appears.
1. Identity of the natural person
Required by Article 19 (identity of natural persons involved in result verification), Fannie Mae LL-2026-04 (the lender attests to who took the action), HIPAA Security Rule (audit controls under 164.312(b)). The verified human identity behind the request. Where the AI is operating autonomously without a user-on-whose-behalf, the field captures the authorized owner of the autonomous workflow.
2. Identity of the agent or workload
Required by NIST's AI agent identity and authorization framework (Pillar 1: agent identity). The verified workload identity of the calling agent. Distinct from the natural person, because one human can drive many agents and one agent can act on behalf of many humans. The field captures both endpoints of the delegation chain.
3. Role and scopes
Required by EU AI Act Article 14 (human oversight design), HIPAA 164.308(a)(4) (information access management), SOC 2 CC6.3 (logical access). The role or group the natural-person identity belongs to, and the scopes the agent is operating under for this specific request. Different roles attract different policies. The same person acting under different scopes carries different authority.
4. Data classification
Required by EU AI Act Article 10 (data and data governance), HIPAA 164.502 (uses and disclosures of PHI), GDPR Article 35 (DPIA inputs). The classification of the data inside the prompt or in the retrieval context. Categories vary by deployment: PII, PHI, sensitive personal data under GDPR Article 9, intellectual property, regulated information specific to the industry. The classification is what the policy decision evaluates against.
5. Policy version
Required by EU AI Act Article 25 (substantial modification), SOC 2 CC6.6 (change management). The version of the policy that governed the decision at the moment of decision. Policy changes over time. The record needs to capture which rule applied to this specific decision, not the current rule.
6. Model and route
Required by EU AI Act Article 11 (technical documentation includes the model used), Fannie Mae LL-2026-04 (AI inventory with model and version). The model identifier (OpenAI gpt-4o-2024-08-06, Anthropic claude-3-5-sonnet-20241022, internal-llama-3.1-70b), the endpoint URL, and the route the call was forwarded to. Multi-provider deployments need this field to reconstruct what happened.
7. Decision outcome
Required by EU AI Act Article 12 (events that affect compliance), HIPAA Security Rule (information system activity review). The action the policy took: permit, redact, deny, human-review. Where redact, the record captures what was redacted. Where deny, the record captures the reason. Where human-review, the record captures the reviewer's identity and the override outcome.
8. Tamper-evident timestamp
Required by EU AI Act Article 19 (period of use timestamps), HIPAA 164.312(c)(1) (integrity), 21 CFR Part 11 for FDA-regulated AI. A timestamp at millisecond resolution from a verifiable source, plus a cryptographic signature or equivalent integrity mechanism that prevents post-hoc modification. The timestamp is correlatable across systems for incident reconstruction.
Where each field comes from at runtime
Each field has a natural source in the request flow. The architecture has to make sure the source value reaches the record.
Identity of the natural person, comes from the application's session
The application that originated the user interaction holds the verified user identity. The identity travels to the AI gateway as a signed delegation token. The gateway verifies the token signature and captures the identity field from the token claims.
Identity of the agent, comes from the workload identity provider
The agent runtime authenticates to the AI gateway using a workload identity issued by the identity provider (SPIFFE, AWS IAM, Azure AD, GCP IAM). The identity is verified at the gateway and recorded directly.
Role and scopes, come from the identity provider claims
The delegation token includes the user's role and the scopes the user delegated to the agent. The agent's workload identity carries its own role at the runtime level. Both sets of claims are recorded.
Data classification, comes from the gateway's classifier
The gateway runs a prompt classifier that tags the request with data classes. The classifier output is the field value. Where the classifier is uncertain, the record captures the uncertainty.
Policy version, comes from the gateway's policy store
The policy in effect at the moment of decision carries a version identifier (typically a content hash or a versioning ID). The version is recorded with the decision.
Model and route, come from the gateway's routing layer
The forward target (provider, model, endpoint) is recorded at the moment the call is forwarded.
Decision outcome, comes from the policy evaluation
The policy evaluation produces the outcome. The outcome and any side effects (redaction details, denial reason) are recorded.
Tamper-evident timestamp, comes from the gateway's signing infrastructure
The gateway signs the record at write time using a key the application does not control. The signature includes the timestamp.
Compliance gap
Most enterprise deployments today produce application logs that capture two or three of the eight fields. The remaining five are either missing entirely or stored in a system that cannot be reconciled with the AI decision later.
Missing identity at the request layer
Static service credentials at the AI provider mean the natural person and the agent identity collapse into a single service-account record. Articles 12 and 19 of the EU AI Act cannot be satisfied from that state.
Missing data classification
Application logs typically do not include a data classification of the prompt content. The classification has to happen at the AI request boundary, before the call reaches the model.
Missing policy version
The policy that governs an AI decision lives at the gateway. Application logs reflect what the application chose to do, not what policy was in effect. Substantial modifications under Article 25 cannot be reconstructed without policy versioning.
Missing tamper-evidence
Application logs are mutable. The system being audited generates the audit record. This is the self-attestation problem that fails the traceability test.
Mandate vs. Compliance
The eight fields are what the converged regulatory landscape asks for. The application-controlled log captures, at best, the application's view of the call: request body to upstream service, response status, timestamp. The fields the regulators care about live above and below that log layer.
The disclosure test
When the AI Office or a national competent authority opens an inquiry, the deployer must produce the eight fields per decision. Where the deployer produces only the application-side log, the regulator's follow-up question lands on the missing fields: identity of the natural person, data classification at the moment, policy in effect at the moment, integrity of the timestamp. The application-side log fails the disclosure test on each of these.
Records that survive litigation
Per-decision records with the eight fields are admissible as evidence in civil and regulatory proceedings under EU evidentiary rules. The protection runs in two directions. If a user disputes a decision, the deployer can produce the record showing identity, role, policy, classification, and outcome. If a regulator investigates a breach, the same records show what was authorized, by whom, under what policy.
Compliance gap
The structural fix is to move the recording layer from the application to an independent enforcement layer at the AI request boundary. The application supplies the identity context; the enforcement layer captures the remaining seven fields and produces a signed, tamper-evident record.
DeepInspect
This is the architecture DeepInspect was built to provide. DeepInspect sits at the AI request boundary as a stateless proxy between any application and any LLM. Per request, the gateway captures the eight fields from their natural sources and produces a per-decision audit record that is signed and tamper-evident. The record is committed before the model response returns to the application.
For Article 19, the record satisfies the period of use, identity of natural persons, and input data fields. For LL-2026-04, the record satisfies the audit trail and disclosure obligations. For HIPAA, the record satisfies the audit controls under 164.312(b). For SOC 2, the record satisfies the logical access and change management controls. The eight fields are the converged ask. The records are the converged answer.
If you are facing the August 2 EU AI Act deadline or the August 6 Fannie Mae deadline, let's talk.
Frequently asked questions
- What's the minimum acceptable timestamp resolution?
Millisecond resolution is the practical floor. The EU AI Act Article 19 language requires the period of use, which is implicitly start-end timestamps; the resolution is not specified. Operationally, millisecond resolution is what correlates across systems during incident reconstruction. Lower resolution (second-level) makes it hard to order multiple requests within the same second, which often matters in agent workflows where many calls fire in close succession. Higher resolution (microsecond) adds marginal value and complicates clock synchronization across distributed systems. The Network Time Protocol with stratum-1 reference is the standard source.
- How long do the records have to be retained?
Article 19 sets the EU AI Act floor at six months. HIPAA Security Rule sets the floor at six years from the date of creation. Financial-services regulators typically require five to seven years. The practical answer for most regulated deployers is seven years, with the option to extend for specific industries. The records should be designed for that retention from day one because retrofitting integrity controls onto older records is operationally hard.
- Can application logs satisfy the eight-field requirement if engineered correctly?
In principle, application logs that capture all eight fields could satisfy the requirement. In practice, two architectural properties make this hard. The application does not have a natural source for data classification of the prompt content. And the application that generates the decision also generates the log, which is the self-attestation problem that fails admissibility. The cleanest architecture is to move the recording layer to an enforcement gateway that the application does not control. The application supplies the identity context; the gateway captures everything else.
- How does this list map to the Fannie Mae LL-2026-04 requirements?
LL-2026-04 requires the lender to maintain an AI inventory, governance framework, risk assessment, and audit trail. The eight-field per-decision record is the audit trail at per-decision granularity. The inventory and governance pieces live above the record layer. The records feed the audit trail and let the lender satisfy the disclosure obligation when Fannie Mae asks "which model decisions touched this loan file." Without the records, the audit trail is reconstructable only from application logs that lack identity, classification, and policy fields. The lender remains liable for AI mistakes by subcontractors regardless.
- What if the policy classifier is uncertain about the data class, do we still record?
Yes, with the uncertainty captured. The record includes the classifier's confidence and the fallback policy that was applied. A high-confidence PII classification is recorded as PII. A low-confidence classification is recorded as low-confidence-PII with the fallback policy that was applied (typically the more conservative of the two possible outcomes). The record carries the information a reviewer needs to reconstruct what happened, including the classifier's limitations at that moment. Hiding the uncertainty makes the record less defensible, not more.