Glossary Updates6 new terms added to the glossaries · October 11, 2026, 13:38 CEST
AI TechDocKnowledge

Glossary · 6 · Quality, risk and governance

AI interaction log

Also known as: Interaction log, AI audit log, Prompt log, AI usage log, Automatically generated logs (AI Act term)

German: KI-Interaktionsprotokoll

In AI governance, an AI interaction log is a record of exchanges with an AI system — the prompt or input, the system, model and version identifiers, the returned output, and what a human then did with it — kept so that a later reader can reconstruct how an output came about. It is the evidence layer beneath review and sign-off: without it, a claim that a model version was checked or an output was approved cannot be substantiated. Scope, retention and access have to be defined deliberately, because such logs often contain confidential input, customer data and personal data. In EU law the artifact appears not under this name but as the "logs" that high-risk AI systems must be able to record automatically, and that providers and deployers must keep.

  • Intermediate
  • Technical writers
  • Technical marketers
  • Technical project managers
  • Developers

In one sentence

What an AI interaction log records, why it carries accountability, and how to set scope, retention and access.

Example

Before an AI-drafted troubleshooting procedure is published, the documentation team's log shows the prompt, the model and version used, the generated draft, and the engineer who approved the corrected text.

How it applies

  • Decide what a log entry contains before you switch logging on: A usable entry pairs the input with its context and its consequence — timestamp, user or service identity, prompt and relevant system prompt version, model name and version, key parameters such as temperature, retrieved sources, tool calls, the output, and the human decision (accepted, edited, rejected). A log of prompts alone proves activity, not diligence.
  • Know where the legal duty sits: Article 12 of the EU AI Act (Regulation (EU) 2024/1689) requires high-risk AI systems to technically allow the automatic recording of events over the lifetime of the system, with logging capabilities covering events relevant to identifying risk situations or substantial modification, to post-market monitoring under Article 72, and to the monitoring of operation by deployers under Article 26(5); additional logging specifics apply to remote biometric identification systems. Article 19 obliges providers to keep those automatically generated logs that are under their control for at least six months unless other Union or national law says otherwise, and Article 26(6) places a comparable retention duty on deployers. Naming these articles — or this entry — never establishes compliance; only implemented and documented measures can.
  • Treat the high-risk timeline as something to verify: Public trackers do not agree on when the Chapter III high-risk requirements become applicable — some still list 2 August 2026, while others list 2 December 2027 for Annex III systems and 2 August 2028 for Annex I systems under Article 113(c). Check the consolidated text on EUR-Lex and the Commission's AI Act Service Desk before you write a deadline into a plan. The existence of the logging obligation is not in dispute; its start date is what you must confirm.
  • Most AI logs are not AI Act logs: If your system is not high-risk, interaction logging is a voluntary governance control, not a statutory one. Keep it anyway where output quality matters, but say in your AI usage policy that it is a company control, so nobody mistakes an internal log for regulatory record-keeping.
  • Set retention and access as policy, not as a default: Every log is a personal-data processing operation the moment it captures who typed what. The GDPR principles of data minimization and storage limitation (Article 5(1)(c) and (e)) argue for a defined period, a defined purpose, role-based access and documented deletion — while AI Act retention floors argue for keeping certain logs long enough. Resolve that tension explicitly in writing rather than in a tool's configuration screen.
  • Technical writers: Use the log as your fact trail. When a reviewer asks where a sentence came from, the entry shows the prompt, the sources the model was given and who approved the result — which is how you answer for content that a model drafted, given that hallucination is a property of the tool. Do not paste customer-confidential source material into tools whose logs you cannot see or govern.
  • Technical marketers: Log the generation of claims, images and localized copy so rights clearance and AI content disclosure obligations can be traced to a specific run and a named approver.
  • Technical project managers: Put logging in the contract and the risk register — what the vendor logs, where it is stored, who can read it, how long it is kept, whether it is used for model training, and how you export it. Clarify the provider/deployer split early: if you only deploy a purchased system, the logs under your control are still yours to keep.
  • Developers: Log at the integration layer of your AI API calls, not only in the vendor console, and make entries immutable and correlatable by request ID so an AI agent run with tool use (function calling) can be replayed step by step. Redact secrets and personal data on write, not on read; sample verbose payloads if volume is a problem, but never sample the decision record.
  • Feed quality work, not just audits: Logged interactions are the raw material for evaluation (evals) datasets, for a maintained prompt library and for incident analysis after a bad output. That dual use is also why purpose limitation has to be written down.

Interaction log vs. model card

A model card describes a model in general: intended use, training data provenance, evaluation results, known limitations. An AI interaction log records singular events: this prompt, this version, this output, this approval, at this time. The card supports a decision to use a model; the log supports the defense of an individual output and underpins accountability (AI) and effective human in the loop review. Audit readiness needs both, and neither substitutes for the other.

External references

By knowledge.aitechdoc.world · Published October 11, 2026 · Last reviewed

Source: EU AI Act, Article 12 — Record-keeping (Regulation (EU) 2024/1689)

Definitions follow the cited standards and specifications. Where a source is a copyrighted publication, such as an ISO, IEC or EN standard, the definition is a close paraphrase, not a verbatim quotation, so as not to infringe copyright. We recommend reading the original publication. The sections “How it applies” are editorial commentary by AI TechDoc Knowledge and are not part of any standard.

Seen a mistake? Send us a note!