Most Indian finance teams already use generative AI. The question is no longer whether the tool is present. The question is whether the company can explain, six months later, which process used which model, under whose authority, and with what residual risk. A ban is rarely enforceable. An open free-for-all leaves no evidence when an auditor or a board member asks a pointed question. A short living register closes that gap without turning controllership into a software procurement department.
Indian controllership teams operate under multiple constraints at once. Statutory audit under the Companies Act, internal audit, board risk committees, and, for listed entities, the expectations that accompany BRSR and SEBI disclosures all assume that management can reconstruct how a material number was produced. Generative AI tools sit outside traditional ERP controls. They do not appear in the general ledger. They do not leave a posting. They leave a draft paragraph, a classification suggestion, or a variance explanation that a controller then adopts or rewrites.
A formal ban sounds clean. In practice it fails for two reasons. First, staff already have personal accounts on public models and will continue to use them for drafting when official channels are blocked. Second, the ban itself creates an evidence problem: if the tool is forbidden, any residual use becomes an exception that must be explained rather than a controlled activity that can be sampled. An open free-for-all creates the opposite problem. When an external auditor later asks how a particular management-account narrative was prepared, the team has no contemporaneous record of the inputs, the model, or the human review that followed.
A living register occupies the middle ground. It treats GenAI assistance as a documented process step rather than as either a prohibited act or an invisible one. The register does not require the company to approve every prompt. It requires the company to know, at a level of aggregation that a controller can defend, where assistance is occurring, who remains accountable for the output, and what residual risk has been accepted. That knowledge is what survives a query.
The same logic applies in emerging-economy settings more broadly. Where ERP systems are mature but AI governance frameworks are still being written, the practical control is often a light, periodically refreshed record rather than a full model-risk management system. Indian controllers already maintain similar light records for spreadsheet models used in forecasting or for manual journal-entry approvals. The GenAI register is an extension of that habit, not a new discipline.
The register fails if it tries to list every prompt. It also fails if it only lists the names of the tools the company has purchased. Useful scope sits between those extremes.
Capture is required when three conditions are met. First, the output influences a number or a narrative that will appear in management accounts, statutory accounts, or a board paper. Second, the assistance is repeated rather than one-off. Third, a human later relies on the output without re-performing the underlying calculation or analysis from source data. Under those conditions the activity belongs on the register.
The register can ignore pure drafting that is fully rewritten before it leaves the desk, exploratory use on non-financial data, and one-off experiments that never reach a controlled output. It can also ignore tools that are used only for formatting or for converting a table into a chart when the underlying data and calculations remain in the ERP or in a controlled spreadsheet. The test is whether a later reviewer could reasonably ask “how did this sentence or this classification get here?” If the answer would otherwise be “someone used a chatbot,” the activity belongs on the register.
In practice this means the register is process-oriented. Typical entries include: drafting of variance explanations for the monthly pack, classification of unusual transactions for the provisions review, summarisation of customer correspondence for credit notes, and generation of first-draft responses to auditor queries. Entries do not include personal productivity uses that never touch a controlled deliverable.
A register that cannot be read six months later is not a control. The minimum fields that survive time and staff turnover are short and stable.
Optional but useful fields include the data sources that may enter the prompt (customer names, account balances, free-text notes) and any data-handling constraint (for example, “no personal data of employees is entered”). These fields become important when the company later faces a data-protection or confidentiality query. They are not required for every entry on day one.
Indian teams that already use a simple spreadsheet for key spreadsheet models can extend the same file. The register does not need its own software. What it needs is consistent naming and a single owner who is responsible for ensuring that new processes are added and that stale processes are closed.
The fastest way to kill a register is to make entry a monthly compliance task that requires a form and an approval workflow. Controllers can avoid that outcome with three practical moves.
First, start with a single facilitated session rather than a survey. In a ninety-minute meeting with the people who prepare the monthly pack, the provisions paper, and the auditor-response file, the controller asks three questions: “Where have you used a generative tool in the last quarter? Which outputs did you adopt without re-performance? Who still owns the final version?” The answers become the first set of entries. The session is repeated only when a new process appears or when an existing process changes materially.
Second, make the register visible inside existing working-paper folders. A one-page summary of the relevant register entries can sit at the front of the monthly-pack file or the quarter-end file. When an auditor or an internal-audit reviewer opens the file, the summary is already there. This reduces the chance that the register is treated as a separate document that no one opens.
Third, close entries when the process stops. If a team stops using a particular tool for variance narratives because a new ERP report now produces the draft, the entry is marked closed with a date and a one-line reason. Open entries that no longer reflect reality are worse than missing entries, because they create a false sense of coverage.
These moves keep the register inside the ordinary rhythm of controllership work. They do not require a new policy document, a new committee, or a new software licence. They do require a named owner—usually the controller or the financial reporting lead—who treats the register as part of the month-end or quarter-end close checklist.
The register becomes valuable only when it is linked to controls that already exist. Three linkages are practical for Indian companies.
The first linkage is to the management-representation or working-paper sign-off process. When a controller signs the monthly pack or the quarter-end file, the sign-off can include a short confirmation that the register entries relevant to that file have been reviewed and that residual risks remain acceptable. The confirmation does not need to be a separate certificate. It can be a line in the existing sign-off checklist.
The second linkage is to internal audit or to the statutory auditor’s risk assessment. When internal audit plans its review of the financial-reporting process, the register gives the auditor a ready list of places where AI assistance occurs. The auditor can then sample the human-review evidence for those places rather than relying on a general inquiry about “whether the company uses AI.” The same list helps the statutory auditor decide whether any AI-assisted process rises to the level of a key control that requires testing.
The third linkage is to board or audit-committee papers. A short extract from the register—process name, residual risk, and last review date—can be included in the quarterly risk or audit-committee pack. The extract does not need to name every tool. It needs to show that management knows where assistance is occurring and has accepted residual risk at a stated level. This is the language that allows a board member to ask a follow-up question without receiving the answer “we do not track that.”
For companies that already maintain a model inventory for valuation or forecasting spreadsheets, the GenAI register can sit alongside it. The two inventories serve different purposes—one for quantitative models, one for generative assistance—but they can share the same review calendar and the same owner.
The quarterly review is where the register either proves its value or becomes a stale spreadsheet. The review itself can be short. The language that comes out of it must be usable.
A usable residual-risk sentence has three parts. It names the process, it names the residual failure mode, and it names the compensating control that keeps the failure mode from reaching the final output. Example: “Monthly variance narrative is drafted with assistance from a public model; residual risk is an invented prior-period reference; compensating control is the detailed variance review performed by the reporting manager against the ERP extract before the pack is issued.” That sentence can be read by a board member or an auditor without further translation.
The review also forces closure decisions. If a process has not used the tool for two consecutive quarters, the entry is closed. If a new process has appeared (for example, the use of a model to draft responses to a new SEBI disclosure requirement), the entry is opened. The review therefore keeps the register aligned with actual practice rather than with the practice that existed when the register was first created.
For listed companies the same language can be adapted for the audit-committee minute or for the internal-control section of the annual report. The minute does not need to claim that AI risk has been eliminated. It needs to record that management maintains a living register, reviews it quarterly, and has accepted residual risk at a stated level for named processes. That record is what survives a later query from a regulator, an investor, or a successor controller.
Use the following checklist at the end of the current quarter and again before the next statutory-audit planning meeting.
The checklist is deliberately short. Completing it once creates the register. Completing the review step each quarter keeps the register alive. The result is not a perfect inventory of every prompt. It is a contemporaneous record that lets an Indian controller answer, with evidence, the question an auditor or a board member will eventually ask: where does generative assistance enter our controlled outputs, who still owns those outputs, and what residual risk have we accepted?
Further reading on DrDPKlass: earlier notes in the AI & Business series address governance of GenAI in finance operations and the containment of shadow tools. The register described here supplies the operating record that makes those higher-level controls testable.