Data Retention Policies for Metered Usage Records in Regulated Industries
Regulators demand you keep billing records; privacy law says you must delete them.
Metered usage event records in regulated industries sit inside a legal contradiction: regulators require a minimum retention period for billing-related data, while privacy law caps how long that same data may legally exist. Every API call, every token processed, every GPU-second billed generates a record that both bodies of law claim jurisdiction over, at the same time, with no obvious way to satisfy both. This piece lays out where those floors and ceilings actually sit, sector by sector, how the EU AI Act adds a third obligation on top, and why the engineering answer turns out to be simpler than the legal one.
Metered usage event records at the intersection of two opposing legal forces
Data retention law splits into two opposing instructions, and both apply to the same record. Floor laws, the kind enforced by the IRS, OSHA, the SEC, and HIPAA, tell a business how long it must keep a given record. Ceiling laws, chiefly GDPR Article 5(1)(e) and the CCPA/CPRA regime, tell that same business how long it may keep it. Compyl's guide to data retention law makes the point directly: both sets of rules apply to the same record simultaneously, and a defensible retention schedule is the document a business builds to resolve that conflict for every category of data it holds. If litigation becomes reasonably foreseeable, a legal hold overrides both forces, and routine deletion has to stop for the relevant records no matter what the schedule says.
Metered billing has pulled this tension into sharper focus than it has ever had before. The shift to consumption-based pricing in AI and SaaS products means that a record that used to be a quiet piece of back-office administration now carries three jobs at once: it is the basis for the invoice, the audit trail a finance team needs to defend that invoice, and, in regulated industries, a compliance artifact a regulator can demand to see. A single API call or resolved support ticket generates an event record, and that event record inherits whatever retention floor applies to the sector it was generated in, regardless of whether anyone building the billing system thought about compliance.
The stakes of getting this wrong are not abstract. When Cursor generated a $7,225 invoice for a single developer in July 2025, the cause traced back to uncapped usage inside an annually billed plan, a metering architecture decision with a direct dollar consequence for a customer. The metering architecture decision is itself the cause: without a granular, retained event record behind that invoice, no one can prove which calls were made, when, or at what rate, so the dispute cannot be resolved in either the vendor's favor or the customer's. The same record that a regulator wants kept for compliance purposes is the record a billing team needs to defend a disputed charge. Serving both purposes at once turns the floor-versus-ceiling conflict into a live operational issue rather than a legal abstraction.
The retention floors regulators impose on billable event data, sector by sector
Retention floors are not uniform across industries, and treating one sector's rule as a universal default is how organizations end up either keeping data they are legally obligated to delete or deleting data they are legally obligated to keep. Financial services, healthcare, and general corporate financial reporting each impose their own minimums, and metered billing systems selling into any of these sectors inherit the relevant floor automatically, whether the engineering team building the billing pipeline knows it or not.
In financial services, electronic records must be stored in WORM format, write once, read many, unless a business has adopted the 2022 rule amendment that permits an alternative: a system with a complete audit trail capable of recreating the original record. Firms with EU operations also face MiFID II, which requires recorded communications to be stored for five to seven years, and GDPR's data-minimization requirements layer on top of that floor rather than replacing it. A financial institution running a metered billing product, in other words, does not get to choose between WORM storage and GDPR compliance. It needs both, at once, on the same records.
Healthcare carries its own set of floors, and they are frequently misunderstood. HIPAA's Privacy Rule, at 45 CFR 164.530(j), requires covered entities to retain administrative compliance documents, privacy policies, security procedures, training records, and business associate agreements, for six years from creation or last effective date. People misapply that six-year figure constantly to patient medical records, but HIPAA does not actually govern those. Medical records fall under state law instead, and state requirements vary considerably; the American Medical Association recommends that you retain all patient records for at least ten years from the date of last treatment as a matter of best practice. Medicare providers face a separate floor of seven years from the date of service. The detail that matters most for metered billing: any recorded interaction containing patient information, including an appointment scheduling call or a billing conversation, counts as a medical record under HIPAA. A billing event record that happens to contain protected health information inherits the healthcare retention floor directly, not as an analogy but as a matter of law. Healthcare call recording retention runs six to ten years on average, and the recording platform itself has to meet HIPAA's technical requirements: encryption at rest and in transit, and role-based access controls.
Cross-sector financial reporting adds a third floor. It is the one most commonly misapplied. Under SOX Section 802, you have to keep audit workpapers and the records supporting an audit report for seven years. That figure gets generalized into "SOX means seven years for everything," which is, by a wide margin, the most common retention myth in governance, risk, and compliance work. The seven-year rule binds auditor workpapers specifically, not every corporate record a business generates. General ledgers and financial statements carry a separate six-year floor under SEC and accounting standards, but many practitioners round up to seven years for tax-related documents, since that is a safe standard. A metered billing system generating general-ledger entries and an audit trail at the same time is, without realizing it, subject to two different floors that happen to look similar but are not the same rule.
A third retention obligation: the EU AI Act and billing infrastructure
Layered on top of these sector-specific floors is a newer obligation that targets usage logs specifically rather than financial or medical records generally. The EU AI Act imposes an independent log-retention requirement on both providers and deployers of high-risk AI systems. Because so much of today's metered billing runs through AI products, that requirement lands directly on billing infrastructure that was built, in most cases, before anyone was thinking about the AI Act.
The baseline figure is six months, but that number functions as a floor rather than a target. Union or national law, particularly data-protection and sector-specific rules, can extend that period well beyond six months, and regulated financial institutions are expected to follow their existing financial-services retention periods instead of defaulting to the AI Act's shorter figure. In practice, a bank or asset manager running a high-risk AI system does not get a shorter retention window because the AI Act specifies one. It keeps following SEC or MiFID II timelines, with the AI Act obligation effectively absorbed into the longer existing floor.
Timing matters here, and the picture is not fully settled. High-risk obligations, including logging and retention, start applying to standalone Annex III systems on December 2, 2027. Annex I embedded systems get a longer runway, with obligations applying from August 2, 2028. Proposals to defer parts of this timeline have moved through the relevant legislative body, but as of the most recent guidance, that deferral has been approved by one chamber without yet being adopted by the other, meaning organizations cannot assume the delay is in effect and should plan against the dates as currently set. Missing the logging requirement carries financial penalties scaled to worldwide annual turnover, which puts the AI Act's enforcement mechanism in the same category as GDPR's, a percentage-of-revenue exposure rather than a fixed fine.
This third layer is not really a new category of record; it is a new retention rule applied to the same usage event logs a billing system is already generating. The engineering problem of keeping an AI Act-compliant log and the engineering problem of keeping a billing-dispute-ready event record turn out to be the same problem, described in two different regulatory vocabularies, a point that becomes central once the discussion shifts from what the law requires to how a system should be built to satisfy it.
Multiple overlapping regimes governing the same event record
Putting the sector floors and the AI Act obligation side by side shows a single metered usage event record can end up governed by four separate regimes at once, each with its own retention period, its own rationale, and its own enforcement body. The governing principle for resolving this is simple to state even though it is demanding to implement: the longest applicable floor wins. Where two records laws cover the same document, the record is kept for the longer of the two periods, and state medical-records rules routinely exceed HIPAA's federal six-year minimum for exactly this reason. Ceiling laws do not enter the picture until every applicable floor has expired. A privacy regulation will never force the deletion of a record a business is legally required to keep, but it will penalize that business for holding the record past the point where every floor obligation has lapsed.
The Carrefour France case illustrates the ceiling side of this concretely. France's data protection authority fined Carrefour France €2,250,000, in part for holding loyalty program data on customers who had been inactive for a number of years, a clear instance of ceiling enforcement kicking in well after any legitimate floor had already expired.
Consider what this looks like for a SaaS vendor selling AI products into financial services. That vendor faces SEC Rule 17a-4's six-year floor, SOX's seven-year floor on audit workpapers, the EU AI Act's six-month floor (superseded by the longer financial-services period), and GDPR's storage-limitation ceiling, all applied to the same event log. A healthcare deployer faces a parallel stack: a billing event containing protected health information inherits HIPAA's six-year compliance floor and potentially a state medical-records floor running seven to ten years, with any applicable AI Act obligation layered on top of both. If you operate across multiple jurisdictions, you have to build retention policy around the strictest applicable standard in the mix, because each jurisdiction's regulator enforces its own rule regardless of what another jurisdiction requires.
This stack holds three distinct shapes of obligation, and retention schedules tend to break down when you treat them as interchangeable. Fixed-period floors, like SOX's seven years or SEC's six, can be automated directly: a timestamp plus a fixed offset. Open-ended floors, like HIPAA's medical records requirement tied to "last treatment" rather than a calendar date, require modeling a trigger condition instead of a fixed deletion date, since the clock does not start until a specific event occurs. Purpose-bound ceilings, the GDPR and CCPA side of the equation, require a written justification for whatever period a business chooses to retain data beyond its floor obligations, because a regulator reviewing that choice will ask why the period is four years rather than two. A retention schedule built around metered event records is not just a lookup table that maps data type to number of years.
How immutable append-only event logs satisfy multiple regulatory requirements
On paper, the regulatory stack described above looks like four separate compliance problems that need four separate solutions, but it is not. The append-only, immutable event log, which happens to be the correct architecture for metered billing pipelines on purely engineering grounds, satisfies the WORM requirement financial regulators impose, the tamper-evidence mandate the EU AI Act imposes, and the evidentiary integrity a billing dispute requires, all at the same time. They are the same underlying engineering constraint, expressed in three different regulatory vocabularies.
The core design principle is straightforward: the raw event store never gets edited. Existing data stays immutable. When a mistake occurs, a miscalculated token count, a customer misattributed to the wrong account, the correct response is to emit a new correction event that references the original record rather than rewriting it. This correction-by-addition pattern is not just good engineering hygiene. It satisfies the SEC's 2022 rule amendment directly, because that amendment accepts a complete audit trail capable of recreating original records as an alternative to strict WORM storage. The same pattern that keeps a billing system honest also keeps it compliant.
The EU AI Act's Article 12 requires logs to support full traceability across a system's life, from deployment through decommissioning. Guidance from a regulator, issued in a Q&A dated April 2026, confirms that a cryptographic hash of the input, combined with classification and policy metadata, satisfies this requirement, because that combination allows the original decision to be forensically reconstructed after the fact. That is a lighter technical bar than it might first appear, and it is one that an append-only event log with proper hashing already clears without additional architecture.
The same immutable log structure that makes a billing dispute resolvable also functions as evidence when a customer challenges an invoice, and evidence that can be altered after the fact carries no weight. A log that cannot be edited, only appended to, is the only kind of record that can serve as credible proof of what was actually billed and when.
One further requirement runs through all of this and is easy to miss: pricing rules themselves need the same retention discipline as the events they govern. Pricing configurations change over time, but every usage event has to be billed under the rule that was in effect at the moment it occurred. Applying today's pricing rule to last quarter's usage produces an incorrect invoice. The retention obligation therefore extends beyond the usage events themselves to a versioned history of every pricing configuration that ever governed them.
Storage economics round out the picture. A multi-tier structure, hot storage for active queries, warm storage for infrequent access, cold archive for long-term compliance retention, and deep archive reserved for legal holds and audits, lets an organization meet every floor obligation described above without paying hot-storage prices for records that may sit untouched for seven or ten years. The legal requirement and the cost requirement point toward the same design, which is, in the end, the real argument for building metered billing infrastructure this way from the start rather than retrofitting it once a regulator asks to see the logs.
