Every LLM integration logs the prompt and the completion. It happens early, for a good reason: when a model returns something strange, the first thing anyone wants is the exact input. So someone adds it during development and it ships.
Follow what that produces. A verbatim copy of every prompt, retained at whatever the platform default is, indexed and searchable, available to everyone with a dashboard login, replicated to wherever your observability vendor replicates, and exported to a data lake for analysis.
Compare that to the prompt itself, which goes to a provider you have a contract with, under retention terms you negotiated, and may not be retained at all. The log is longer-lived, more accessible, and less governed than the thing it is logging.
Then add the adjacent sources. Exception messages carry the object being processed. Traces capture span attributes that include request payloads. Analytics events fired for product metrics carry properties nobody reviewed. Error reporting tools attach the full request body by default because that is what makes them useful.
The instinct is to fix this at the call site: be careful what you pass to the logger. That fails for the same reason Chapter 12's conventions fail. There are hundreds of call sites and one of them will be wrong.
Fix it where everything converges.
public sealed class RedactingEnricher(IDeterministicDetector detector) : ILogEventEnricher
{
public void Enrich(LogEvent e, ILogEventPropertyFactory factory)
{
foreach (var (name, value) in e.Properties.ToList())
{
if (value is not ScalarValue { Value: string s }) continue;
var redacted = detector.RedactAll(s);
if (!ReferenceEquals(redacted, s))
e.AddOrUpdateProperty(factory.CreateProperty(name, redacted));
}
}
}Use Chapter 5's deterministic layer here rather than the model-based detector. It runs in 0.1 ms, in-process, with no network call. A logging pipeline cannot afford a 15 ms round trip per event, and cannot afford to fail when the container restarts. Accept the narrower coverage: catching every card number, IBAN and national identifier in your logs is a large win on its own.
Three more measures worth the hour they cost.
Deny-list the field names that should never be logged. password, ssn, ein, routingNumber, accountNumber, dateOfBirth, body, prompt, completion. Structural, cheap, and it catches the case where someone logs a whole DTO.
Set retention deliberately. Most teams have never changed it. Thirty days of application logs is plenty for debugging and dramatically better than the two years your platform defaults to.
Test it. The same shape as Chapter 14's assertion:
[Fact]
public void Logger_RedactsIdentifiersInStructuredProperties()
{
var sink = new CapturingLogSink();
var log = BuildLogger(sink);
log.Information("Processing {Payload}",
new { Routing = "021000021", Note = "card 4111111111111111" });
Assert.DoesNotContain(sink.Entries, e => e.Contains("021000021"));
Assert.DoesNotContain(sink.Entries, e => e.Contains("4111111111111111"));
}Now the half you cannot fix in code.
Three questions, and all three are contract terms rather than engineering problems:
Is the data retained, and for how long? Providers differ, and several offer zero data retention for API traffic where prompts are not stored at all.
Is it used for training? Major providers state they do not train on API traffic by default, and this is usually the easiest term to confirm.
Where is it processed? Regional processing matters for any cross-border transfer analysis. Some providers commit contractually to processing within a region you name; others commit only on particular tiers, or not at all. This is a term to read rather than a property to assume, and it is one of the few where the answer is usually written down plainly.
Two of those three are genuinely negotiable, and the third is usually already answered in the provider's standard terms.
This book deliberately names no provider's retention terms. That is not squeamishness, it is the same standard applied to itself: provider terms changed at least twice during 2026, and a figure that cannot be re-verified at the moment of reading is a figure that will mislead someone. Any per-vendor comparison table printed in a book is stale within a quarter.
What does not go stale is the structural point:
Retention, residency and training-use are negotiable contract terms. They cost a procurement conversation rather than an engineering quarter, and they are frequently the highest-leverage control available to you.
A team can spend six weeks building a redaction pipeline that catches half of what it sees, or spend two weeks getting zero data retention and regional processing written into a contract. Do the second one first. Then build the pipeline, because the contract does not help with doors two through five.
Go to the provider's own documentation, not a comparison article. Read the enterprise or commercial terms rather than the consumer privacy policy, because they differ and only one of them governs your API traffic. Record the URL, the date and the exact wording, because "we do not train on your data" and "we do not train on your data by default" are different commitments. Then check whether the term you are relying on is contractual or merely documentary: documentation changes without notice, an agreement does not.
A word about the risk climate, because it shapes how these projects get funded, and the loudest version of the story is not the accurate one. Every figure below carries the date it was verified, and every one of them moves.
California is the one with a dedicated regulator. The CPRA created the California Privacy Protection Agency, the only privacy-specific regulator in the country. At a September 2025 board meeting its staff reported hundreds of investigations and enforcement actions in progress, many at a stage where the business did not yet know it was a target.
Civil penalties are CPI-adjusted in odd-numbered years. The amounts in force since 1 January 2025, and unchanged through 2026, are $2,663 per violation and $7,988 per intentional violation, or per violation involving a consumer the business knows to be under 16. The next adjustment is due in 2027. Penalties are assessed per violation, which in practice usually means per affected consumer, so totals scale with your user count rather than with the severity of the mistake.
The CCPA also carries the only private right of action in a comprehensive US privacy law, for breaches caused by a failure to maintain reasonable security. Statutory damages are likewise CPI-adjusted: $107 to $799 per consumer per incident since 1 January 2025, not the $100 to $750 written in the statute. Statutory damages with no requirement to prove harm are what make class actions economic, and that is a different risk shape from a regulator's fine. One material qualifier: a consumer must give 30 days' written notice, and if the business actually cures the violation within that window and says so in writing, no action for statutory damages may be brought.
New CCPA regulations covering risk assessments, cybersecurity audits, insurance data and automated decision-making technology took effect 1 January 2026. Read the dates carefully, because they are not the same date. The regulations are in force now; the substantive obligation for businesses using ADMT to make significant decisions about consumers begins 1 January 2027. If your LLM feature contributes to a decision about a person's employment, credit, housing, education or healthcare, that is the deadline in your calendar, and it has not passed.
If you touch health data, OCR is the more likely counterparty. The HHS Office for Civil Rights closed 2025 with 21 settlements and civil monetary penalties, its second-highest annual total, and has continued at pace through 2026. Penalties are inflation-adjusted annually: the calendar-year cap for all violations of an identical provision rose to $2,190,294 effective 28 January 2026. Note the gap between the statutory number and practice, because it cuts both ways: since 2019 OCR has exercised enforcement discretion to apply materially lower annual caps to the three lower culpability tiers, so the headline figure is the ceiling rather than the expectation. Business associates have been directly liable since HITECH, so a vendor position does not insulate you.
One thing frequently reported as imminent is not. The proposed overhaul of the HIPAA Security Rule, published as an NPRM in January 2025, has not been finalised. As of September 2026 it remains a proposal, and OMB's target for final action has moved to July 2027. Plan for it; do not tell your board it is law.
The FTC covers the gap. Mobile health apps, fitness trackers and personal health record vendors sit outside HIPAA and inside the FTC's remit, under Section 5 and the Health Breach Notification Rule.
Now the contrast, and it needs stating carefully because it is widely misreported. The Italian data protection authority fined OpenAI €15 million over ChatGPT, and that fine was cited everywhere as proof that AI privacy enforcement had arrived. On 18 March 2026 the Court of Rome annulled the decision in its entirety, setting aside both the fine and the order to run a public awareness campaign.
Read the reason before drawing the lesson. The court annulled on jurisdictional grounds: once OpenAI established its Irish establishment in 2024, the GDPR one-stop-shop mechanism made the Irish authority the lead supervisory authority, and the Garante no longer had competence to act. The ruling therefore says almost nothing about whether the underlying processing was lawful. It is not a finding that the conduct was fine. It is a finding about who was entitled to ask.
The useful conclusion is narrower than "enforcement is toothless" and more useful than "a fine was issued". The generative-AI enforcement record is thinner than the enforcement noise, and a meaningful part of what did happen turned on procedure rather than on substance. Plan for the ordinary kind of enforcement instead. A state attorney general or the CPPA asking what personal information you collected and why. OCR asking whether a business associate agreement was in place. A plaintiff's firm counting consumers after a breach. None of those requires an AI-specific law, and all of them turn on the same question: was this data necessary?
That is data minimisation, it is Chapter 12, and it is enforceable today under every regime named above.
If you also serve EU customers, the EU AI Act adds transparency duties rather than new data protection rules. Article 50 transparency obligations became applicable on 2 August 2026, catching user-facing chatbots and synthetic content. The Digital Omnibus on AI, Regulation (EU) 2026/1744, in force since 27 July 2026, deferred the high-risk regime to 2 December 2027 for standalone Annex III systems and 2 August 2028 for AI embedded in products already covered by EU product-safety law. It left Article 50 alone, apart from a four-month grace period until 2 December 2026 on the content-marking duty in Article 50(2) for systems already on the market. Separately, the Commission's power to fine providers of general-purpose AI models under Article 101 was carved out of the August 2025 enforcement date and applies from 2 August 2026.
If you are building a chatbot, the obligation live today is telling users they are talking to a machine.
Build for minimisation. It is the thing every regulator named here can already enforce, it is the control that actually reduces your exposure, and it is cheaper than everything else in this book.
| Control | Effort | Reduces |
|---|---|---|
| Turn off prompt/completion logging | Hours | The largest store of personal data you have |
| Redact at the log sink | Hours | Everything incidental in telemetry |
| Field deny-list | Hours | Whole-DTO logging accidents |
| Shorten log retention | Minutes | Exposure window, storage cost |
| Zero data retention with your provider | A procurement conversation | Provider-side persistence |
| Confirm no training on API data | An email | Memorisation risk |
| Regional processing | A contract term | Transfer risk |
Nothing on that list is technically interesting. The top four are an afternoon of work between them and they close the widest door in most organisations. The bottom three are someone else's afternoon and they remove an entire category of risk you cannot otherwise touch.
Everything is in place: minimised inputs, a chokepoint, a trustworthy detector, closed doors, and negotiated terms. None of it counts until you can show it, and showing it is easier than it sounds if you built the previous chapters the way they were described.
All figures below were verified on 14 September 2026. Every one of them is subject to periodic adjustment; the dates are part of the claim.
The claim that your observability stack holds more personal data than your prompts do is the author's assertion from practice, not a measured finding. It is offered as a prompt to go and look at your own log store.
Download the full PDF for free?
Free download — no account required