Picture a Tuesday morning in the third quarter. Internal audit has announced a review of how the AI assistant is used and sends three questions ahead of time: Who used the assistant and the workflows over the last thirty days? Which processes had an effect on the outside world, and who confirmed them? What went wrong, and how was it noticed?
If you can answer those questions from one system within ten minutes, the review will be short and factual. If you have to phone colleagues, search mailboxes and compare recollections, it will be long and uncomfortable.
This scenario is a thought experiment, not a customer case. But sooner or later it reaches every company that does not just try out AI but builds it into its processes. And audit rarely comes alone: data protection asks a second, related set of questions. This article collects both sets, maps them to the columns of the audit log in TheroAI and describes honestly where the log stops.
Our thesis: an audit log is the last link in a chain of evidence. It tells you reliably what happened and when. Whether it was allowed to happen and whether it was right is decided elsewhere: in the permissions before and in the approvals during.
Why the Questions Arrive Before You Are Ready
Classic software does what its menus offer. An AI assistant, together with the agents and workflows around it, does more: it searches documents, drafts text, triggers actions and often works while nobody is watching. That is what makes it useful, and it is exactly what makes it interesting to reviewers.
Audit and data protection look at the same subject through different lenses. Audit examines procedures: who may do what, which checkpoint sits in between, and what evidence remains afterwards? Data protection examines data: which personal details are involved, what for, how long they stay, and who sees them? Neither side wants to stop the use. Both want to be able to reconstruct it.
A process is reconstructable if weeks later you can still say what happened without relying on the memory of individuals. With an email that is easy, because it sits in a mailbox. With an AI run it is only easy if the system leaves a trace itself. An agent can complete dozens of runs in a day. Anyone who is later asked to remember the one run that raised a question will fail.
There is also a timing problem. The questions do not come when you introduce the system but a year later, when the use has become routine and the original people have moved on to other tasks. Evidence that has to be laboriously reconstructed at the time of the review is not evidence. It is a story.
The Catalog of Questions: What Audit and Data Protection Want to Know
Before we look at the product, it is worth looking at the questions themselves. The list below is not a standard but a practical collection of what tends to come up in review conversations. It is ordered by the columns of the audit log, as far as the questions can be answered there.
| Question | Why it is asked | Where the answer lives |
|---|---|---|
| When did it happen? | Placing it in time, linking it to an incident | Time column |
| Which process was involved? | A review starts with an inventory of processes | Process column |
| What exactly was done? | Telling reading, drafting and executing apart | Action column |
| Did it work? | Errors and how they were handled | Status column |
| How long did it take? | Unusual runs, too fast or too slow | Duration column |
| Who was behind it? | Responsibility and attribution | Person column |
| Did a human agree before it took effect? | A checkpoint before irreversible steps | Approval step, in the log as a decision |
| Was the person allowed to see the data at all? | Access control | Permissions, before the log |
A single row in the audit log answers the first six questions directly, each in its own column. The last two belong to the stages before and during. That is neither an accident nor a flaw but the core of this article: a log can only record what a system does. What it should have been allowed to do must be settled beforehand.
What the Audit Log Contains
In TheroAI, organization administrators find the audit log under Insights (“Auswertungen” in the German interface), in the tab “Audit log”. It lists agents and workflows as processes, one row per run. The table has six columns that match the six questions above.
| Column | What it records | Example from the product capture |
|---|---|---|
| Time | Date and time of the entry | 08.10.2026, 12:09:20 |
| Process | Name of the process, marked as agent or workflow | Workflow “Wochenbericht Vertrieb” (weekly sales report) |
| Action | Kind of operation | run (a single run) |
| Status | Outcome of the operation | Successful, Failed or Pending |
| Duration | How long the operation ran | 2.8 s or 1.6 min |
| Person | Who triggered the operation, if recorded | a dash in the capture |
One detail of the capture deserves attention: in the Person column, these runs show only a dash. The capture does not say why. For processes that are not started by a person, such as scheduled ones, there is simply nobody the log could name. That comes with a task: for every such process there should be a named person responsible in your organization, because an empty Person cell does not answer the question of responsibility. Audit will ask about it.
With “Show stats” you reveal four figures above the table: Total, Successful, Failed and the average duration. They follow the filters for type, process and time range and are useful for an overview in the review conversation. The evidence, however, lies in the rows, not in the statistics.
Clicking a row opens the detail view of the entry. It shows, as far as the entry has them:
- the input of the operation, meaning what the run was started with
- the output, meaning what the run delivered
- the decision for approvals: Approved, Rejected or Automatic
- the decision comment, if someone left one
- the error message, if the run failed
Not every entry fills every field. If an entry has no input or output data, the view says so explicitly. That is worth knowing for the review as well: the log is a record of what happened, not a complete duplicate of all content.
The Chain of Evidence: Before, During, Afterwards
The audit log sits at the end of a chain. Before it lie two stages that give the log its weight. We order them by the time in which they act.
Before: What was permitted? The first stage consists of permissions. The assistant should only answer from sources the asking person is entitled to see, so the access rights of the connected systems keep applying. On top of that come tool rights: for each tool and service you decide whether it is allowed, whether the assistant has to ask first, or whether it stays blocked. Tools that act on the outside world carry the “Schreibend” (writing) badge. You can find more on the page about tools and their permissions.
During: Who agreed? The second stage is approvals. In a workflow you can add a step at which the run pauses and waits for a person. You choose the approvers, set a deadline (72 hours in the product capture) and can optionally switch on the four-eyes principle, which requires a second person. How this looks in practice is described on the page about workflows.
Afterwards: What happened? Only the third stage is the audit log. It records that the run took place, how it ended and, for approvals, how it was decided. The CSV export turns that into evidence you can file outside the system and hand to audit.
A thought experiment shows why the order matters. Suppose a company keeps an exemplary log, but permissions are generous and there are no approvals. Then the system records neatly, row by row, what should never have happened. The log is complete, and the review is unpleasant all the same. The reverse holds too: whoever sets permissions and approvals carefully but records nothing cannot prove their care. Only together do the two make a chain that does not snap under review.
More background on security and data hosting is on the security page. Data hosting in Germany and AI processing in the EU are the basis on which the data protection questions below build.
An Example, Step by Step
A concrete run makes the chain tangible. The following example is explicitly fictional and uses the demo material from our industry pages, the filler FL-200 and the error E-217. It is not a customer case.
A workflow called “Kundenantwort freigeben” (approve customer reply) answers inquiries about machine errors. It has three steps: an agent drafts the reply based on the documents, an approval step pauses the run, and then the reply is released.
On a timeline, the fictional run looks like this:
At 14:02 the run starts with the request. At 14:03 the agent has created the draft and the run waits for approval. At 15:41 a person approves and leaves a comment, 1 hour and 38 minutes after the wait began. At 15:42 the reply is released and the run is complete. The wait stays well within the 72 hour deadline.
What does audit see? In the audit log it finds the run of the workflow with time, status and duration. It finds the person's decision: Approved, with the comment they left and their name. And in the detail view it can check what the agent received as input and what it produced. Each of the four questions under the timeline has an answer from the system, not from memory.
More interesting than the success case is the counter-check. Suppose that in one quarter audit sees nothing but approvals, each a few seconds after the request. Then it is fair to ask whether the approval was reviewed or just clicked through. Conversely, a decision “Rejected” with a comment shows that the checkpoint has a real effect. A log with rejections in it is therefore not a bad sign but often the best one: it proves that somebody looked.
Filters and CSV Export: From Question to Audit Set
Audit rarely wants all entries. It wants the ones that fit its question. For that there are four filters above the table:
- Type: agent or workflow
- Process: a specific agent or workflow from the list
- Status: Successful, Failed or Pending
- Time range: all time, last hour, last 24 hours, last 7 days or last 30 days
The filters can be combined. That turns an audit question into a selection:
| Audit task | Filter |
|---|---|
| All failed runs of the last month | Status: Failed, time range: last 30 days |
| Everything a specific workflow did | Process: that workflow |
| Only automated processes, no agents | Type: workflow |
| Runs that are not finished yet | Status: Pending |
| Overview for the report | Show stats |
How strongly the filters narrow a set is shown by an illustrative calculation. The numbers are assumed, not measured, and serve only as an illustration.
| Step | Filter | Entries left (assumption) |
|---|---|---|
| 1 | All entries | 2,000 |
| 2 | Time range: last 30 days | 800 |
| 3 | Type: workflow | 500 |
| 4 | Process: one workflow | 200 |
| 5 | Status: Failed | 20 |
From 2,000 entries you arrive at 20, which is one percent of the starting set. Those 20 rows can be worked through, opened one by one and compared with the incident.
With “Export CSV” you carry the filters you have set over into a file. The file is separated by semicolons for German Excel and contains, per row, time, type, process (identifier and name), action, status, decision, duration, person and error message. The input and output data from the detail view are not part of it. A single export is limited in row count, currently to 5,000 rows. For very large periods you therefore export in sections, for example by time range or by process.
The export solves a practical problem of reviews: audit wants to run its analysis independently of the product and file the material in its own working papers. A file it can filter, sort and check itself is better for that than a screenshot.
What Data Protection Asks in Addition
The audit log has a trait that data protection notices immediately: it exists for control and is itself a collection of data about people. The Person column contains a name, and the detail view may show content depending on the run. A log is therefore both a safeguard and a processing of personal data.
Data protection's questions complement those of audit. They are not legal advice but a checklist for the conversation with your data protection officer:
| Question | Why it is asked | What you check |
|---|---|---|
| What personal data does the log contain? | Names in the Person column, possibly content in input and output | Who may see the log, and is the circle small enough? |
| What is the log kept for? | Purpose limitation and data minimization (Art. 5 GDPR) | Define the purpose in writing: traceability, error analysis, audit |
| How long do entries remain? | Storage limitation (Art. 5 GDPR) | Compare the system's period with your deletion concept |
| Who processes on whose behalf? | Processing on behalf (Art. 28 GDPR) | Contract, data hosting in Germany, AI processing in the EU |
| Is the processing documented? | Record of processing activities (Art. 30 GDPR) | Describe the log as a processing activity of its own |
| Does the works council have to be involved? | Co-determination for technical systems that monitor employees (section 87(1) no. 6 BetrVG) | Define purpose and use of the log together, early |
Two of these rows deserve a few more sentences.
First, the purpose. An audit log shows which runs took place and who triggered them. It does not assess people, and it should not be used to compare the performance of individual employees. Anyone who does not state this explicitly creates distrust before the first entry is written. German works constitution law (section 87(1) no. 6 of the Betriebsverfassungsgesetz) gives the works council a co-determination right over technical systems designed to monitor the behavior or performance of employees. Whether and how far it applies to an audit log is a matter for the individual case. The safer route is to involve the works council early and describe the purpose of the log together.
Second, retention. A log is only helpful if it reaches back far enough, and from a data protection view only defensible if it does not exist indefinitely. In the current product version, audit log entries are removed automatically after 90 days. If you have longer proof periods, you should export regularly and keep the files in your own storage under your own retention rules. Settle the period with us in a binding way before going live, because periods are exactly the kind of detail that can change.
This is not legal advice. Clarify the individual case with your legal counsel, especially the questions of purpose, retention and co-determination.
What an Audit Log Does Not Do
An article that only lists what a log can do would be dishonest. Audit will find the limits anyway, and it is better if you know them beforehand.
It does not say whether the answer was right. The log records that a run ended successfully. “Successful” means the process ran through, not that the content is correct. Whether an answer is right is something you check against the sources it relies on. Answers with source references make that possible but do not replace professional review.
It does not say whether an approval was careful. A decision “Approved” proves that someone pressed approve. Whether that person read the draft is visible at most indirectly, from the time between request and decision and from the comment. Care comes from training, clear responsibilities and a procedure that makes the review realistically doable. The log can only make it visible.
It does not see what happens outside the system. If someone copies an answer into another program and sends it by hand, the trail ends there. That holds for any software and is not a defect of the log but a limit of its scope.
It is only as complete as its scope. The audit log in the insights area lists agents and workflows as processes. If you also have to document the free use of the assistant in conversation, clarify beforehand which traces exist for that. There is a second point: a log should not hold up operations. That is reasonable, but it has a consequence you should ask every vendor about, including us: how is an entry handled that could not be written, and how do you spot gaps?
It is not a seal of quality. The term “audit-proof” (“revisionssicher”) is often used carelessly. Whether a log is sufficient evidence for your procedure is for your audit function to judge, not the vendor. Among the things to ask: who can change or delete entries, and how long they exist. We claim nothing blanket on this, and you should not accept it from any provider.
These limits are not an argument against the log. They are an argument for treating it as what it is: evidence about processes, not a verdict on quality.
What You Can Take Away
You do not have to use TheroAI to take something from this catalog of questions. If you are evaluating an AI system for your company, these steps help before audit asks:
- 1.Write the questions down yourself. Take the eight questions from the catalog and add whatever is specific to your organization. Whoever knows the questions can measure the system against them.
- 2.Test every question on a real row. Have a run shown to you in a trial and answer the six column questions with it. Where a column stays empty, as with automated processes, decide who is responsible.
- 3.Settle permissions and approvals before the log. Set tool rights, build approval steps in especially where something takes effect on the outside world, and consider the four-eyes principle.
- 4.Clarify purpose, access and retention in writing. Who may see the log, what is it used for, how long does it exist, and how is it described in the documentation of your processing activities?
- 5.Involve data protection and the works council early. A purpose described together prevents later conflict.
- 6.Practice the export. Assemble an audit set once, for example all failed runs of a month, and file the document. With limited retention this belongs in a fixed rhythm.
- 7.Ask about the limits. What does the log cover, what not, who can change entries, how do gaps become visible? An answer that also names weaknesses is more reliable than one that does not.
Our position: an audit log is not insurance against mistakes, but it is the precondition for mistakes not remaining a riddle. It turns the question “What happened there?” into a search with filters instead of a survey among colleagues. And it only develops its value together with permissions before and approvals during.
If you would like to see how a run, an approval and the matching audit log entry fit together in practice, we are happy to show you in a conversation with a demo, calmly and with your own audit questions.
See Thero live
Book a short demo. You talk directly to the founding team.