What your auditor will ask about an AI agent

Auditors are trained to follow authority. For a journal entry, they want to know who raised it, who approved it and whether the system kept a trustworthy log of both. None of that changes when an agent raises the entry. What changes is that the usual answers, a person's login and a signature on a voucher, are no longer there unless you design for them.

The questions to expect

1. 01Which agents are in use, and what can each one change? Expect to show a list, with an owner for each agent.
2. 02Who authorised that access, and when? The answer should be a person and a date, not a ticket number.
3. 03For this action, which rule allowed it? If a rule allowed it alone, show the rule as it stood on that day.
4. 04If a person approved it, who were they, when did they approve, and what did they see when they did?
5. 05What happened to the actions that were refused, or that nobody answered?
6. 06Does your accounting software's own audit trail still cover every change, including the ones made by agents through integrations?
7. 07Can the record of these actions be checked independently, or do we have to trust the system that wrote it?
8. 08How long is the record kept, and can you read it back today?

Where Indian companies start from

Two rules already frame the conversation. Since 1 April 2023, accounting software must keep an edit log of every change that cannot be disabled, and auditors report on it under Rule 11(g) of the Companies (Audit and Auditors) Rules, 2014. Section 128(5) of the Companies Act, 2013 sets the retention period for books at not less than 8 financial years. An agent's edits fall under both. Our regulation watch brief on the MCA audit trail covers the detail.

For banks and NBFCs the bar is rising. The RBI's FREE-AI committee found that few regulated entities keep AI audit logs today, and the RBI's draft model-risk guidance proposes records of models kept for 10 years or more.

What a good evidence pack contains

• An inventory of agents, each with its own identity in every system it touches, an owner and the date its access was granted.
• The rule set as it stood on any given day, with who changed it and when.
• One record per action: the agent, the request, the rule applied, the outcome, the approver if there was one, and the time.
• The refusals and expired requests, kept with the same care as the approvals.
• A way for the auditor to verify the record without asking the vendor, and a test that it can be read back after years.

How elan1 Govern is designed to answer

Every action that passes through elan1 Govern ends in a record of 16 fields, whether it was allowed, approved or refused. Records are chained so that a missing or altered one shows. An auditor can verify a record set offline with one command, without trusting elan1. These are designed capabilities; the claims register shows the status of each.

Govern's record sits beside your accounting software's audit trail; it does not replace it. Changes still reach the books through the software's own interfaces, so the edit log records them, and Govern adds what the edit log cannot: the authority behind each one.