AI Audit Logs for Data Centers: What to Record and Retain

A building management system might record that a valve moved from 42% to 36%. If an AI application proposed the change, the event alone does not answer whether the sensor feed was stale, whether an independent limit approved the action or whether the anticipated saving actually occurred. A useful audit trail adds enough context to investigate those questions.

That does not mean storing every raw sensor reading forever. Effective logging selects the records needed to reconstruct material decisions, protect equipment and meet applicable obligations while limiting security exposure and unnecessary personal-data retention.

Start with an event record that can be understood later

Use consistent identifiers across the inference service, gateway, independent control layer and BMS. Where large telemetry sets are stored separately, the event may reference a versioned snapshot instead of duplicating thousands of measurements.

Do not invent a “confidence score” field when the model cannot generate a calibrated confidence estimate. For some controllers, a predicted thermal response or bounded operating range is more defensible than a pseudo-probability.

Example: one logged cooling recommendation

This sample is fictional and intentionally small; production schemas need access controls and stable relationships to the plant historian and change records.

{
  "event_id": "AI-COOL-208",
  "timestamp_utc": "2026-10-13T08:30:00Z",
  "system_id": "cooling-optimizer-hall-b",
  "model_version": "2.4.1",
  "inputs_ref": "telemetry-snapshot-1884",
  "data_age_seconds": 7,
  "proposal": {"asset": "CRAH-B03", "fan_percent": 54},
  "guardrail": {"status": "approved"},
  "execution": {"status": "operator_pending"}
}

The operator_pending state is significant: the AI suggested an action but did not execute it. Conflating those states could lead a later investigation to attribute a manual control change to the model.

Choose retention periods instead of copying a generic template

Different data types support different purposes. A raw environmental stream may be operationally useful for a shorter period than a signed commissioning report. Decide retention according to the investigation window, contractual commitments, regulatory classification, privacy rules, litigation holds and storage cost. Document both the initial period and the deletion process.

Suggested commercial schedules like “30–90 days for telemetry” or “ten years for all model files” are not universal laws. Legal requirements must be checked before setting or changing a disposal policy.

Make logs reliable without giving the AI deletion rights

Synchronize clocks across the AI system, OT gateways and physical controllers; preserve original time-zone information; and monitor missing records. Separate the logging destination from the AI account that issues commands. Restrict log modification, implement tamper detection and test restoration as well as storage.

• Event timestamps can be correlated with BMS/EPMS records.
• AI operators cannot alter or delete audit events.
• Relevant snapshots and model versions remain retrievable.
• Exports include the fields needed for incident review.
• Retention and disposal rules have named owners.

WORM storage and hash chaining can be useful integrity mechanisms, but neither is a universal requirement for every operational AI installation. Choose a proportionate design based on threat model and evidence needs, consistent with OT access controls.

What does the EU AI Act actually require?

The EU AI Act contains specific record-keeping provisions for high-risk AI systems. Article 19 addresses automatically generated logs kept by providers to the extent under their control; Article 26(6) addresses deployers' logs under their control. The law sets a minimum of six months in the relevant provisions, subject to applicable EU or national rules, including data-protection law. Requirements and dates of application must be checked for the particular system.

A practical logging architecture therefore begins with incident needs and traceability, then adds any system-specific statutory obligations—not the other way around.

Takeaway: preserve enough trusted context to connect a model's proposal, its safety checks, any human decision and the physical outcome. More data is not automatically better evidence.