What to record in an AI system and agent log: an event log that helps you undo a mistake and show what happened

On our page about the AI Act technical compliance sprint we say that we design the record of the system’s actions “with an agreed, minimal set of fields” and “no default archive of full conversation contents”. The AI Act is the EU regulation on artificial intelligence. On AI agents — programs that use an AI model and carry out actions in other systems — we write about an action record: what the agent did and on what basis. Both statements are true, and both leave the question that comes up in the first technical meeting: what exactly goes into a single entry? The AI Act’s six-month rule on its own does not answer that. We start one step further: with the fields you need to record so that, three months from now, you can say what the system did, why, who approved it and what can still be done about it.

We describe what to build and what to record. We do not decide whether your system is a high-risk system within the meaning of the AI Act, or what the legal basis for processing the data is — your lawyer assesses that. Your lawyer’s assessment of whether a high-risk system is already subject to the log-retention duty determines whether tier 3 described below applies to you; tiers 1 and 2 follow from whether the system processes personal data or deals with customers.

What AI Act Articles 12, 19 and 26(6) say — and who they apply to at all

The Regulation calls them logs: automatic records of what the system did. We simply call them the log. Three provisions, all in Chapter III, which means only for high-risk systems:

• Article 12 — system design. A high-risk system must technically allow for the automatic recording of events over its lifetime. The events to be recorded are those relevant for three purposes: identifying situations in which the system may present a risk (within the meaning of Article 79(1)) or that may lead to a substantial modification; post-market monitoring of the system; and monitoring of its operation by the deployer. This is an obligation of the provider: whoever develops the system or has it developed and places it on the market or puts it into service under its own name or trademark (Article 3(3)) — not always the party that technically builds it. The Regulation gives a minimum list of fields only for the systems in point 1(a) of Annex III (remote biometric identification, Article 12(3)). For everything else the set of fields is a design decision, as long as the log still serves those three purposes.
• Article 19 — the provider keeps the logs. The provider keeps the logs referred to in Article 12(1) “to the extent such logs are under their control”, for a period appropriate to the intended purpose of the system, of at least six months — with the same reservation as in Article 26(6): unless other law, in particular on personal data protection, provides otherwise.
• Article 26(6) — the deployer keeps the logs. A deployer of a high-risk system — whoever uses it under their authority, outside personal, non-professional use (a company, public body or other person) — keeps the automatically generated logs that are under its control “for a period appropriate to the intended purpose of the high-risk AI system, of at least six months, unless provided otherwise in applicable Union or national law, in particular in Union law on the protection of personal data”.

Article 19 and Article 26(6) are two separate duties assigned to different roles: the system provider and the deployer. Each covers the logs under that party’s control — which may even be the same logs. Where the data sits does not on its own determine either the role or control. In practice, if you buy the system as a service in the seller’s cloud, some records are controlled by the seller and some — for example what your integration (the program connecting your systems to the model) writes on its side — by you. So when you buy, ask which logs can be exported from the seller’s console and for how long.

From when. According to the consolidated text of 27 July 2026 (after the amendments made by Regulation 2026/1744, the so-called Digital Omnibus), Sections 1–3 of Chapter III, and therefore Articles 12, 19 and 26, apply to high-risk systems under Annex III (a list of uses treated as high risk, such as employment or creditworthiness assessment) from 2 December 2027, and to high-risk systems under Annex I (linked to EU product-safety legislation, such as toys or medical devices) from 2 August 2028 (Article 113, point (c)). Exception: for systems classified as high-risk under Article 6(1) and related to products covered by the legislation in Section B of Annex I, such as machinery, vehicles or certain aviation products, Articles 12, 19 and 26 do not apply (Article 2(2)). There is also a transitional rule (Article 111(2)): the Regulation applies to operators (providers, deployers and the other Article 3 roles) of a high-risk system placed on the market or put into service before the date that applies to it only if the system’s design is significantly changed after that date. In any event, providers and deployers of high-risk systems intended to be used by public authorities must comply by 2 August 2030 at the latest. The rule does not cover components of the EU’s large-scale IT systems, for which Article 111(1) sets its own deadline, and it does not postpone the Article 5 prohibitions. Whether this transitional rule covers your system is for your lawyer to assess. We set out the wider timeline in our article on the AI Act in Poland.

When this does not apply to you. An ordinary invoice-flow automation, a chatbot answering questions about orders or an assistant drafting e-mails is usually not a high-risk system, and the AI Act does not require it to keep logs. A log still pays off — to find and undo a mistake and explain a decision — but it does not need the six-month tier described below. If it processes personal data, the GDPR (the General Data Protection Regulation) applies, regardless of the AI Act.

One log entry: an example

Before the table of fields, one entry in full. This is an illustrative example, not a record from a client project: an agent that reads a customer e-mail, proposes a meeting slot and enters it into the calendar and the CRM (the customer-management system). The rows follow the field numbers in the table below.

Eleven rows that someone without a technical background can read. We come back to this entry in the reconstruction below, because it has two flaws: one in the data, one in the configuration. In the first version of such an agent, booking would go through human approval; here we assume the category was released from it later — which is exactly why the log has to let you check whether that was the right call.

The schema: eleven fields and what each one is for

Every field is justified by one of four things the log has to make possible: undo a consequence, explain a decision, improve the system, or show someone outside what happened. A field that serves none of them is a storage cost, and often a risk as well.

Four notes on the table.

Record at every operation, not only at the end. If the log is written only in the last step of the automation, and on the way the calendar entry succeeds but the CRM write fails, you are left with a consequence and no trace. So field 7 is recorded at every operation: first what the agent intends to do, then what actually happened. Both records share the same operation identifier, and each attempt has its own number. A missing outcome record does not mean the operation did not run — before retrying, check its effect in the target system or use a check that stops the same operation running twice. Parameters are recorded only as far as needed to undo and explain: message content preferably as a reference, and passwords, access keys and other login details never. A summary at the end can supplement this, but does not replace it.

Reference, copy or hash — a decision for each field. A hash is a short “fingerprint” of a text: comparing it with a previously stored, protected hash reveals that the content has changed, but the hash does not let you read the content. It serves integrity checks and does not let you reconstruct a decision. To see what the system received, you need either a minimised copy in the log or a reference to a source record that lives at least as long as you decided the content should stay available. A reference to an e-mail that the mailbox deletes after a month, contrary to the agreed period, is dead by month three — and that is a design fault. Scheduled deletion of content after the agreed period is not a design fault.

Personal data is not only in the content. The customer identifier in field 5, the parameters in field 7, the answer in field 8 and the approver in field 10 can also be personal data. A hash does not help here: Recital 26 GDPR says that pseudonymised data which could be attributed to a person by the use of additional information is information on an identifiable person, and a plain hash of a phone number may in any case let someone guess the number by checking candidates one by one. So each field is assessed on this point separately.

The rationale and the human decision are statements, not proof. Field 8 records the reason the model gave, not insight into how it actually “thought”; rules and documents you can point to are stronger. Fields 9 and 10 show that approval was recorded, not that it was considered. How to use them to check that approval has not turned into rubber-stamping (median decision time, correction rate, sample audit) we covered in the article on human approval (human in the loop).

Reconstruction: the agent booked a meeting with the wrong customer

Back to the example entry. The scenario is illustrative, but every step relies only on the fields in the table.

A day later Mr Nowak calls to ask why he received an invitation to a meeting he never asked for. A different customer with the same surname did.

1. Find the step. We search field 7 for his contact identifier (contact:5531). There is one entry with an action on that contact, with case number case-2026-10-07-0412.
2. Understand what happened. Field 5 shows that the CRM search returned two contacts, and field 8 that the agent picked the first. Field 9 is empty: the model’s confidence was high, because from its point of view everything matched. That is the first flaw — two hits should be a flag in their own right. The second is the configuration in field 10: the category ran without approval.
3. Undo what can be undone. Field 7 holds the identifiers event:9930 and note:44120, and records that both operations succeeded and the invitation went out. We delete the event and reverse the note only if the target system confirms, when performing the undo, that the record still has the version after the write recorded in field 7 — that is, nobody changed it after the agent. If the version differs or this cannot be checked, a person decides. The invitation cannot be unsent — Mr Nowak gets an apology and a correction. The right customer is identified from the e-mail that the reference in field 6 points to.
4. Remove the cause. Field 4 says instruction book-meetings v7 was in use, and it has no rule “with more than one hit, ask or hand the case over to a person”. We add it as a rule in the automation, not only in the instruction for the model — an instruction is guidance, not a control. For this category we restore approval until the rule has proved itself.
5. Find similar cases. Because field 5 records the number of hits, one query returns every case in recent months where the search returned more than one contact and the agent still acted on its own. Those we check by hand.

Without fields 5 and 7, steps 1, 3 and 5 turn into searching calendars and mailboxes, and the answer to “how many such cases were there?” is “we don’t know”. How much an agent may do without approval depends on its permissions — a separate design decision we describe under AI agent implementations.

A decision log versus application logs, n8n execution history and logs at the model vendor

In a typical implementation, records are created in several places, and none of them on its own gives you a complete decision log:

• Application logs are usually technical records for the development team: errors, response times, restarts. They may contain case identifiers, but rarely the full set of fields in the table.
• Execution history in n8n (a tool for building automations) stores the data that passed through the automation. On your own server, n8n by default deletes finished executions after 14 days or once there are more than 10,000; running, waiting and annotated executions are kept (as of 12 October 2026) — details in our n8n guide. It is a short-lived copy of data, not a decision log. The log is a separate step at every significant operation that writes a row with the fields from the table into your own database.
• Logs at the model vendor. As of 12 October 2026, according to the vendors’ documentation: in Amazon Bedrock model invocation logging is disabled by default; once enabled, it goes to your own AWS resources (CloudWatch Logs or S3), and logging continues until you delete its configuration; how long the files stay in CloudWatch or S3 you set separately in those services. In the OpenAI programming interface (the API, the way a program uses the service), the vendor by default keeps abuse monitoring logs, which may contain prompts and responses, for up to 30 days. Longer if required by law or reasonably necessary to protect OpenAI’s services or any third party from harm. Eligible customers can have their content (prompts and responses) excluded from these logs. A separate matter is data that some API features keep to complete a task (so-called application state): for example, the Responses API keeps response data for at least 30 days by default, and conversations stored through the Conversations API stay until you delete them; deleting a conversation does not delete its items, which have to be deleted separately. For OpenAI models in Microsoft Foundry (formerly Azure OpenAI) no prompts or completions are stored in the model itself. As part of abuse monitoring, however, selected prompts and completions may be reviewed automatically and, where necessary, by a person. For a customer approved for modified abuse monitoring, data storage and human review are not performed, while automated review may still take place. Separately, some optional features that keep state, such as the Responses API, keep message history and other content in the service, in line with how you configure them.

Abuse monitoring logs serve the vendor. Bedrock invocation logging is yours and may contain the case context passed to the model, but on its own it does not confirm who approved the proposal or what actually changed in the calendar and the CRM. Your integration — the program that sits between your systems and the model — knows that. That is where the log is created. How data flows in such a setup we described on the page about data security and the GDPR.

Retention period: three tiers instead of one number

AI Act Article 26(6) itself defers to data protection law (“unless provided otherwise in … Union law on the protection of personal data”). So the tension between six months and the GDPR is not resolved in one sentence but by a design you document. The GDPR requires data to be “limited to what is necessary” (Article 5(1)(c), data minimisation) and kept in a form which permits identification “for no longer than is necessary” (Article 5(1)(e), storage limitation).

Hence the principle we apply: the event record and the content have separate retention periods, each justified by its purpose — the retention period for content is usually shorter. Fields 1–4, 9 and 11 are mostly identifiers, versions, flags and numbers, but if they identify a person, on their own or together with other information, they are personal data too. Field 6 — the content that came in — most often contains personal data, so we set its retention period by its documented purpose, often shorter than for the event record. If field 6 is a reference, that period has to be ensured in the source system. Fields 5, 7, 8 and 10 more often contain people’s data directly. So every field is assessed, together with what it can be linked to.

Our default split into three tiers — a design, not a list from the Regulation:

The tiers overlap: if a system meets the conditions of tier 3, that tier takes precedence over tiers 1 and 2. At every tier, other laws, for example accounting, employment or sector rules, may require their own retention periods. Six months in tier 3 is a floor for logs, not permission to keep full request content for half a year. How long personal data stays in the log is decided by the data controller — the organisation that decides why and how the data are used, usually your company — with advice from your lawyer and your data protection officer, if you have one. What period is “appropriate” under the AI Act and which logs are “under the control” of your company is for your lawyer to assess on the actual facts.

Who may read the log

The log of a system that serves customers is one of the most sensitive data sets in a company, because it gathers in one place what sits scattered across the source systems. Article 32 GDPR requires security measures appropriate to the risk and lists among them pseudonymisation, confidentiality and integrity of systems, and regular testing of the measures. How to apply that to the log is a design choice; our default set is three rules. First, you decide who can see the event record. Second, you separately restrict access to content: the input (field 6), the answer (field 8) and other fields with data that needs extra protection, and every read of the content leaves its own trace. Third, entries are not edited after the fact: a correction is a new entry, and deleting data when its period ends or at a person’s request follows an agreed procedure that records the fact of deletion, without the deleted content.

Review the log regularly, at a frequency that depends on the risk — to start with, we suggest once a week. Three questions: are there flagged cases nobody looked at, has a category’s correction rate suddenly jumped, and did cost or response time jump after a change of model version or instruction?

An erasure request: what to delete from the log

A customer asks for their data to be erased (Article 17 GDPR). First the data controller, with advice from counsel, assesses whether one of the grounds for erasure in Article 17(1) applies and whether any exception in Article 17(3) applies. If the data has to be erased, you delete from the log what identifies the person: stored request and response content, copies of documents, and the identifiers, parameters, references and hashes that lead to their data. A separate content table linked by the case number makes it easier to delete the content itself, but the remaining fields have to be assessed and handled the same way. What remains afterwards is anonymous only if it genuinely cannot be linked to the person. The same problem on the side of the model itself and of search indexes we covered in the article on the GDPR and LLM implementation.

The reconstruction test: a decision from 90 days ago

Finally, a practical check of whether the log works. It is one test on one case, so it does not replace checking permissions or the deletion procedure, but it shows gaps quickly. Draw one case from 90 days ago at random — or, if you keep event records for less time, from the oldest period within your agreed retention window; do not choose it, draw it — and answer six questions using only the log and the systems its references point to:

1. What came into the system — and if the content was deleted under the agreed period, does the log show where it came from and when it was deleted?
2. Which model, in which version and with which instruction version, prepared the result?
3. Which documents or records did it use?
4. What did it do in which systems, did the operations succeed, and which records did it leave behind?
5. Was the result approved, rejected or was approval not required — who decided and when, or which rule made approval unnecessary — and what was changed?
6. What of this can be undone or corrected today — and what exactly would that take?

Every “we don’t know” that scheduled deletion does not explain points to a missing field or a reference that stopped working earlier than the design assumed. That is why we run the first such test already in the pilot — on cases a few weeks old — and write it into the criteria we agree before the pilot starts, as described in our implementation methodology. Adding these fields to a running system costs more than designing them in from the start, because part of the history simply no longer exists.

If you want to check what is missing from your system’s log, or how to design one before launch, we described that scope under the AI Act technical compliance sprint — within the scope your lawyer sets.

Sources and legal position as of 12 October 2026

• Regulation (EU) 2024/1689 (AI Act) — consolidated text of 27 July 2026 on EUR-Lex (CELEX 02024R1689-20260727) — Articles 2(2), 3(4), 12, 19, 26(6), 111(2), 113(c) and Annex I. Wording checked against the EU Publications Office copy on 12 October 2026.
• Regulation (EU) 2016/679 (GDPR) on EUR-Lex — Article 5(1)(c) and (e), Article 17, Article 32 and Recital 26.
• Amazon Bedrock — Monitor model invocation using CloudWatch Logs and Amazon S3, read 12 October 2026.
• OpenAI — Data controls in the OpenAI platform, read 12 October 2026.
• Microsoft Learn — Data, privacy, and security for Foundry Models sold by Azure, read 12 October 2026.