EU AI Act Compliance: The Infrastructure You're Missing

The EU AI Act entered into force. High-risk AI systems -- those used in healthcare, financial services, employment, education, law enforcement, and critical infrastructure -- now face specific technical requirements. Not principles. Not guidelines. Requirements, backed by fines up to 35 million euros or 7 percent of global annual turnover. The regulation specifies what your AI system must do: log its operation (Article 12), provide traceability of results (Article 13), enable human oversight (Article 14), and document its accuracy and robustness (Article 15).

Most AI teams have responded by investing in model cards, ethics reviews, fairness assessments, and responsible AI frameworks. These are important. They are also insufficient. The EU AI Act does not ask only about your model. It asks about your system -- the complete infrastructure that produces, stores, serves, and verifies AI outputs. Your model is one component. Your inference pipeline is another. Your cache layer, where AI outputs live after inference and before they reach users, is a third. And that cache layer has zero compliance infrastructure.

This is the gap. Your team has spent months on model governance. Your cache -- the layer that stores and serves the actual outputs that reach users -- has no logging, no traceability, no human oversight capability, and no integrity verification. It is a Redis instance or an in-memory dictionary that stores AI outputs as opaque byte sequences with no provenance, no audit trail, and no way for anyone to verify that the output reaching the user matches the output the model produced.

Article 12: Logging of AI System Operation

Article 12 requires that high-risk AI systems include logging capabilities that allow the recording of events relevant to the functioning of the system throughout its lifecycle. The logs must enable the monitoring of the system's operation and facilitate the post-market monitoring of the system. The logs must be retained for a period appropriate to the intended purpose of the high-risk AI system, and in any case for a minimum period that is appropriate given the system's risk level.

What this means for your cache layer is specific: every time a cached AI output is served to a user, that event must be logged. Not just "a cache hit occurred." The log must record what was served (the specific output), to whom (the requesting service or user context), when (timestamp with sufficient precision), and under what conditions (which model version, which parameters, which system prompt produced the cached result). If the cached result was served instead of a fresh inference, the log must record that the result was cached, not freshly computed.

Redis does not produce these logs. The MONITOR command records all commands received by the server, but it degrades performance by 50 percent or more, records only the command syntax (not the semantic context), and does not differentiate between AI inference results and any other cached data. The SLOWLOG records only commands that exceed a latency threshold. Neither produces the kind of structured, semantically rich, retention-compliant logs that Article 12 requires.

Cachee's Article 12 solution: Every cache operation automatically produces a log entry in the hash-chained audit trail. Each entry records the computation fingerprint (which binds the result to its exact production conditions), the operation type (write, read-hit, read-miss, verify), the timestamp, and the key type that performed the operation (Owner, Regulator, or Auditor). The hash chain makes the log tamper-evident -- modifying any entry changes the hash of every subsequent entry. The log is retained per configurable policy, defaulting to 400 days (exceeding the typical minimum requirement). The log is produced as a byproduct of normal cache operation, not as a separate system that must be configured, maintained, and monitored. This is the foundation of compliance-ready infrastructure.

Article 13: Transparency and Traceability

Article 13 requires that high-risk AI systems be designed and developed in such a way that their operation is sufficiently transparent to enable users to interpret the system's output and use it appropriately. The system must include information about the degree of accuracy, robustness, and cybersecurity that the system has been tested for and approved. Results must be traceable to the conditions that produced them.

Traceability is the key word. When a user receives an AI output, they must be able to trace that output back to the conditions that produced it. Not the current conditions. The conditions at the time of production. Which model was running? What version? What system prompt? What parameters? If the output was cached, was it produced by the same model version currently in production, or by a previous version that has since been updated?

Traditional caches destroy traceability. They store a value under a key. The key is typically a hash of the input, not a hash of the production conditions. Two different model versions processing the same input produce the same cache key and share the same cached value. The cache does not distinguish between them. When the model is updated, the old cached result is served under the new model's identity until the TTL expires or the cache is manually flushed. The user receives an output from a model version that no longer exists, with no indication that the output is stale.

Cachee's Article 13 solution: The computation fingerprint is the traceability mechanism. The fingerprint SHA3-256(model_name || model_version || prompt_hash || temperature || top_p || system_prompt_hash || hardware_class) binds every cached result to its exact production conditions. The fingerprint is the cache key, so changing any production condition automatically changes the key and triggers a cache miss. The user never receives a result produced under different conditions than those currently specified. The fingerprint itself is the traceability record: given a fingerprint, you can determine exactly which model version, system prompt, parameters, and hardware produced the result.

Article 14: Human Oversight

Article 14 requires that high-risk AI systems be designed and developed in such a way that they can be effectively overseen by natural persons during the period in which the system is in use. Human oversight measures must enable the person to fully understand the capacities and limitations of the system, monitor the operation of the system, and be able to decide not to use the system or to interrupt, override, or reverse the output of the system.

The critical capability here is "interrupt, override, or reverse." A human must be able to look at any AI output that was served, understand how it was produced, and if necessary, revoke it. This requires three things: the ability to find the output (search by fingerprint, by time range, by model version, by any production condition), the ability to understand the output (see the full provenance, including model version and parameters), and the ability to act on the output (revoke, supersede, or flag for review).

Traditional caches support none of these operations. You cannot search a Redis cache by "all results produced by model version X." You cannot find all cached results served between 2:00 PM and 3:00 PM on a specific date. You cannot revoke a specific cached result with an audit trail of who revoked it and why. You can delete a key, but the deletion is silent -- there is no record that the key existed, what value it held, or who deleted it.

Cachee's Article 14 solution: The AUDITLOG command enables human oversight by reconstructing the complete lifecycle of any cached result. A human overseer can search by computation fingerprint, by model version, by time range, or by any fingerprint field. They can review the provenance of any result. They can revoke a result with a documented reason and a TransitionAuthority record that attributes the revocation to a specific person or role. The revocation is recorded in the audit trail with a cryptographic proof that the transition was authorized. The result transitions to REVOKED state and is never served again. The complete chain of custody -- creation, every access, verification, and revocation -- is available for review.

Article 15: Accuracy, Robustness, and Cybersecurity

Article 15 requires that high-risk AI systems be designed and developed in such a way that they achieve an appropriate level of accuracy, robustness, and cybersecurity, and perform consistently in those respects throughout their lifecycle. The system must be resilient against errors, faults, and inconsistencies that may occur within the system or the environment in which the system operates.

For the cache layer, accuracy means that the cached result matches the result that the model produced. Robustness means that the cached result has not been modified in transit or at rest. Cybersecurity means that the cache is protected against tampering, unauthorized access, and data exfiltration.

Traditional caches provide no guarantees on any of these dimensions. When you read a value from Redis, you trust that it matches what was written. There is no verification mechanism. If an attacker compromises the Redis instance and modifies cached AI outputs, every downstream service trusts the modified outputs without question. There are no checksums, no signatures, no tamper detection. The cache is an unverified store of values that downstream systems treat as authoritative.

Cachee's Article 15 solution: Every cached entry is signed by three independent post-quantum signature algorithms: ML-DSA-65 (FIPS 204), FALCON-512, and SLH-DSA-SHA2-128f-simple (FIPS 205). Every cache read verifies all three signatures before returning the result. If any signature fails verification, the read returns an error rather than serving potentially tampered data. This means every cache read is simultaneously an integrity check. The verification is not a separate mode that you enable for audits. It is the read path. The system operates with continuous, transparent integrity verification as a structural property.

Article-by-Article Mapping: AI Act to Cachee Features

The following table provides a detailed mapping between specific EU AI Act requirements and the Cachee features that satisfy them. Each row identifies the article, the specific requirement, and the Cachee capability that provides compliance evidence.

Why Existing AI Governance Tools Miss the Cache Layer

The AI governance ecosystem has produced excellent tools for model monitoring, bias detection, and experiment tracking. MLflow tracks experiments and model versions. Weights and Biases tracks training runs, hyperparameters, and model performance. Arthur AI monitors model performance in production and detects drift. These tools address important problems. None of them address the cache layer.

MLflow tracks which model version is deployed and its training lineage. It does not track which model version produced a specific cached result that was served to a user three months ago. MLflow knows what model is running. It does not know what model produced a value that is sitting in your Redis cache from before the last model update.

Weights and Biases tracks training runs, evaluation metrics, and model artifacts. It provides excellent lineage from training data to model weights. It does not extend that lineage to cached inference results. Once the model produces an output and it enters the cache, Weights and Biases loses visibility. The cached result could be served for days or weeks with no connection to the W&B lineage record.

Arthur AI monitors model performance in production, detecting drift, bias, and anomalies in real-time. It observes the model's outputs as they are produced. It does not observe cached outputs as they are served. If a cached result from a model version that has since drifted is served to a user, Arthur AI does not detect the drift because the result is served from cache, not from the model. The monitoring gap between "model output" and "cached output" is invisible to model monitoring tools.

The gap exists because these tools were designed for the model layer, not the infrastructure layer. The cache is treated as a transparent optimization -- invisible to governance, invisible to monitoring, invisible to compliance. The EU AI Act does not share this assumption. The Act regulates the system, not the model. The cache is part of the system. Its outputs reach users. Its behavior affects accuracy and robustness. Its data retention affects logging and traceability. Governing the model without governing the cache is like locking the front door and leaving the windows open.

Cachee Configuration for EU AI Act Compliance

The following configuration enables the Cachee features required for EU AI Act compliance across all four relevant articles. Each section maps to a specific article requirement.

# cachee.toml — EU AI Act compliance configuration

# Article 12: Logging
[audit]
enabled = true
log_format = "structured_json"
hash_chain = true                    # Tamper-evident audit trail
fingerprint_log = "/var/log/cachee/fingerprints.jsonl"
transition_log = "/var/log/cachee/transitions.jsonl"
retention_days = 400                 # Art. 12(3): appropriate retention period
log_all_reads = true                 # Art. 12(1): log every cache operation
log_all_writes = true
log_all_misses = true                # Record when fresh inference was required

# Article 13: Traceability
[fingerprint]
enabled = true
hash_algorithm = "SHA3-256"
fields = [
    "model_name",
    "model_version",
    "prompt_hash",
    "temperature",
    "top_p",
    "system_prompt_hash",
    "hardware_class"
]
fingerprint_is_key = true            # Art. 13(2): fingerprint = cache key = traceability

# Article 14: Human Oversight
[oversight]
query_by_fingerprint = true
query_by_model_version = true
query_by_time_range = true
query_by_any_field = true
revoke_enabled = true                # Art. 14(4a): ability to interrupt/override
revoke_requires_authority = true     # TransitionAuthority on every revocation
revoke_requires_proof = true         # TransitionProof on every revocation
supersession_chains = true           # Art. 14(4b): ability to reverse output

# Article 15: Accuracy, Robustness, Cybersecurity
[attestation]
enabled = true
algorithms = ["ML-DSA-65", "FALCON-512", "SLH-DSA-SHA2-128f"]
verify_on_read = true                # Art. 15(3): verify integrity on every read
reject_on_signature_failure = true   # Never serve unverified results
auto_invalidate_on_field_change = true  # Art. 15(1): accuracy throughout lifecycle

# Access Control
[access_control]
key_types = ["Owner", "Regulator", "Auditor"]
auditor_zk_queries = true            # Auditors verify without reading values
regulator_metadata_access = true     # Regulators see provenance, not content

The Compliance Timeline and What It Means for Infrastructure

The EU AI Act entered into force in August 2024. The prohibitions on unacceptable risk AI systems applied from February 2025. The requirements for high-risk AI systems, including Articles 12 through 15, apply from August 2026 for new systems and August 2027 for systems already on the market. If you are deploying a high-risk AI system in the EU market, you have a specific deadline to meet specific technical requirements.

The infrastructure requirements -- logging, traceability, human oversight, integrity verification -- are not features you can bolt on in the final month before the deadline. They require architectural decisions about how data flows through your system, how outputs are stored and served, and how provenance is maintained throughout the lifecycle. Retrofitting these capabilities into a production system that was not designed for them is a 6-to-12-month project, depending on system complexity. Starting now is not early. Starting now is necessary.

The compliance-ready infrastructure approach is to build these capabilities into the cache layer from the beginning. Every cache write produces a fingerprinted, signed entry. Every cache read verifies integrity. Every state change is logged with authority and proof. The compliance evidence is a byproduct of normal operation, not a separate workstream. When the audit deadline arrives, you export the evidence. You do not build the evidence collection system.

Beyond the EU: The Global Convergence on AI Accountability

The EU AI Act is the most specific regulation, but it is not alone. The US Executive Order 14110 on AI requires federal agencies to assess AI system risks and implement appropriate safeguards. The UK AI Safety Framework establishes principles for AI system transparency and accountability. Canada's Artificial Intelligence and Data Act (AIDA) proposes requirements for high-impact AI systems. Brazil's AI Bill establishes a risk-based framework with requirements for transparency, traceability, and human oversight. Japan, South Korea, Singapore, and Australia have published AI governance frameworks with similar themes.

The common thread across all of these frameworks is accountability infrastructure. Not just ethics principles. Not just model cards. Infrastructure that records what the AI system did, proves how it did it, enables human review, and maintains integrity throughout the system lifecycle. The cache layer is part of that infrastructure. Every framework asks the same question: can you prove what your AI system did? If the answer depends on mutable logs in an observability platform, the answer is "we think so." If the answer depends on a cryptographic audit trail with computation fingerprints and triple PQ signatures, the answer is "yes, and here is the independently verifiable proof."

Building compliance infrastructure for the EU AI Act today positions you for every AI regulation that follows. The technical requirements converge: logging, traceability, human oversight, integrity verification. Different jurisdictions use different terminology and different enforcement mechanisms, but they all require the same underlying capabilities. Cachee provides these capabilities at the cache layer, which is the layer that existing governance tools miss. Your model governance handles the model. Your replayable systems infrastructure handles everything after the model -- the storage, serving, verification, and audit of AI outputs throughout their lifecycle.