Regulators have collected more than $3.5 billion in recordkeeping penalties since 2021, and almost none of those cases involved missing records. Most involved records that could be altered, which is exactly the failure mode AI teams are walking into now.
The EU AI Act changed the stakes on August 2, 2026, when Article 12 obligations for high risk AI systems became enforceable. The article requires high risk systems to technically allow automatic recording of events over their lifetime, covering credit scoring, employment screening, insurance pricing, biometric identification, and other Annex III use cases. Article 19 and Article 26 add a floor: providers and deployers must keep those logs for at least six months, longer if other law requires it. Non-compliance carries fines up to 15 million euros or 3 percent of worldwide annual turnover, whichever is higher.
Financial services teams already running storage under SEC Rule 17a-4 have a head start, because the pattern is familiar: non-rewriteable retention, a defined schedule, and a trail that proves nobody touched the record after the fact. Teams building AI features as a standalone product usually do not, because their storage was designed for availability and cost, not for surviving an examiner. The architecture decision, not the compliance policy, is what determines whether that gap closes.
Regulators have collected more than $3.5 billion in recordkeeping penalties since 2021, according to SEC, CFTC, and FINRA enforcement data compiled by compliance vendor Jatheon in 2026. Almost none of those cases involved missing records. Most involved records that existed but could be altered, deleted, or never proved to be intact, which is exactly the failure mode AI teams are walking into now.
The EU AI Act changed the stakes on August 2, 2026, when Article 12 obligations for high risk AI systems became enforceable. The article requires high risk systems to technically allow automatic recording of events over their lifetime, covering credit scoring, employment screening, insurance pricing, biometric identification, and other Annex III use cases. Article 19 and Article 26 add a floor: providers and deployers must keep those logs for at least six months, longer if other law requires it. Non-compliance carries fines up to 15 million euros or 3 percent of worldwide annual turnover, whichever is higher.
Financial services teams already running storage under SEC Rule 17a-4 have a head start, because the pattern is familiar: non-rewriteable retention, a defined schedule, and a trail that proves nobody touched the record after the fact. Teams building AI features as a standalone product usually do not, because their storage was designed for availability and cost, not for surviving an examiner. The architecture decision, not the compliance policy, is what determines whether that gap closes.
WORM stands for write once, read many. Under SEC Rule 17a-4(f), a broker-dealer must preserve covered records exclusively in a non-rewriteable, non-erasable format, or, since the 2022 amendments, in a format with a secure, permanent audit trail that can reconstruct any record that was modified or deleted. WORM remains the path most firms choose, because it is simpler to prove during an exam than reconstructing a change history on demand.
Amazon S3 Object Lock offers two modes, and the difference matters more than most storage configurations suggest. Compliance Mode locks a retention period that cannot be shortened or the object deleted by any user, including the account root, until the period expires. That is the closest technical analog to 17a-4(f) non-rewriteable, non-erasable storage. Governance Mode allows users with special permissions to override the lock, which is useful for internal retention policy but does not satisfy a strict WORM reading on its own. Azure Immutable Blob Storage works the same way once a time-based retention policy is locked, the lock becomes irrevocable. Google Cloud Storage Bucket Lock enforces a retention policy that can only be extended, never shortened, once it is applied.
A locked bucket only protects what actually gets written into it. Object lock says nothing about whether the ingestion pipeline wrote the record in the first place, whether the model version and configuration that produced it were captured alongside it, or whether a failed write silently skipped a batch of inference logs. Vendors selling WORM compliance treat the storage layer as the whole answer. It is one component. The ingestion discipline that guarantees every record actually lands in the locked tier is the other half, and it lives in application code, not in a bucket policy.
EU AI Act Article 19 and Article 26 set a six-month floor for AI system logs. SEC Rule 17a-4 and FINRA Rule 4511 require general correspondence to be kept three years and transaction records six years. Sector overlays such as HIPAA and SOX can extend requirements further depending on what the AI system touches. These regimes stack rather than average out: a single global retention setting either under-retains the financial records or wastes money over-retaining AI inference logs that have no regulatory reason to sit in expensive locked storage for six years.
The fix is a retention schedule modeled per data class, enforced at the object or bucket level rather than in application logic. Application logic can be bypassed by a bug, a misconfigured job, or a well-meaning engineer cleaning up storage costs. A locked bucket policy cannot. Classify data before it lands in storage: AI operational logs get the six-month floor with headroom for internal review, financial or transaction-adjacent records get the multi-year schedule their regime demands, and everything else gets a standard lifecycle policy that never touches the immutable tier at all.
| Regime | Minimum Retention | Immutability Standard | Penalty Exposure |
|---|---|---|---|
| SEC Rule 17a-4(f) / FINRA Rule 4511 | 3 years general correspondence, 6 years transaction records | Non-rewriteable, non-erasable (WORM), or audited reconstruction alternative | $3.5B+ penalties since 2021 |
| EU AI Act Article 12 / 19 / 26 | Minimum 6 months for providers and deployers, longer if sector law applies | Automatic, tamper-evident event logging, not named WORM but interpreted as tamper-evident | Up to 15M euros or 3% turnover |
| Sector overlays (HIPAA, SOX) | Varies by record type, can exceed both rows above | Access controls plus integrity and audit logging appropriate to the record type | Case by case |
Article 12(2) of the EU AI Act spells out three purposes logs must serve: identifying situations where the system might present a risk or has undergone a substantial modification, supplying data for post-market monitoring, and supporting operational monitoring by deployers. Article 13 adds a documentation duty, providers have to explain how deployers can collect and interpret the logs, which turns log format into a contractual obligation, not just an engineering choice.
There are two separate logs here, and conflating them is a common failure. The AI system event log records what the model did: inputs, outputs, version, and the events Article 12 asks for. The storage audit trail records who touched the record afterward: every read, every access attempt, every deletion request, successful or blocked. Regulators generally want both, and an auditor asking whether logs exist is really asking whether anyone could have altered them without leaving a trace. A hash-chained or WORM-backed access log answers that question directly, similar to the access-control discipline covered in our Zero Trust Architecture guide. A plain access log that itself sits in mutable storage does not, because the log proving nothing was changed can itself be changed.
A practical pattern separates data by how long it needs to be provably untouched, not just by how often it is read. Active inference logs sit in a standard hot tier for 30 to 90 days while engineering teams actually use them for debugging and monitoring. Once that working window closes, records that fall under a retention obligation move into a WORM-locked archive tier, using S3 Object Lock in Compliance Mode, Azure Immutable Blob Storage, or an egress-light alternative such as Backblaze B2 with Object Lock or Wasabi immutable buckets. The audit trail for that archive lives in its own isolated bucket or account, so a compromised application credential that can write inference data cannot also rewrite the history of who accessed it.
GPU capacity moves between providers as availability shifts, and that pattern extends to the storage decisions built around it. A team that signed with one neocloud today and needs capacity from a different provider next quarter should not also face a six-figure egress bill to extract years of locked regulatory records, one of the hidden costs our guide to hidden costs in cloud billing covers in more depth. Placing the archive tier on egress-light storage keeps the compliance layer independent of whichever compute provider happens to have capacity this month, which matters more for AI workloads than for traditional financial archives because the underlying compute relationship changes far more often than the retention obligation does.
A sales page that says "WORM compliant" is not evidence. These six questions separate a real control from a checkbox:
Provider profiles for AWS, Backblaze, Wasabi, and the rest of the field covered here are in the Cloud Vendor Directory, which is a faster way to compare immutability and egress terms side by side than reading each vendor's compliance page in isolation. For a deeper head-to-head on two of the egress-light options named above, see our Wasabi vs. Backblaze comparison.
The storage layer is not the last stop for a regulated AI record, it is the only witness left once someone asks what actually happened. Build it to testify, not just to store.
Compare AWS, Google Cloud, Azure, and alternatives like Backblaze B2 Discover how much you could save in seconds
