Two things arrived in the same year: AI in daily production use across the business, and a statutory audit that looks seriously at IT controls. They are related, whether or not anyone plans it that way. The moment an assistant can read a ledger, the questions an auditor asks about that ledger apply to the assistant.
Here is what those reviews actually ask, and what AI adds to them, from the inside of a mid-size Indian group.
What an ITGC review is really about
IT general controls sound abstract until you sit in the room. The questions are concrete and they repeat:
- Who can change what? Show the access list for each material system, and show that it matches what people actually do.
- Who approved it? Not "we discussed it". A record with a name and a date.
- How does access end? Leavers are the fastest way to fail a review. The joiner process is usually fine; the exit process is where evidence goes missing.
- How do changes reach production? Who wrote it, who reviewed it, who released it, and can you show that for a change picked at random.
- Can you restore? Backups are not the control. A tested restore is the control.
Notice that none of these ask whether your architecture is clever. They ask whether you can prove what happened.
What AI adds
The model is not the control point. The access layer is. Auditors do not need to understand transformers. They need to know which identity the assistant acted as, what it was allowed to read, and where that is logged. If every AI surface goes through one governed door, this is a short conversation.
Prompts and outputs are records. If a manager asks an assistant for a customer list and gets one, that is a data access event. Treat the log like any other access log: retained, searchable, scoped.
Retrieval has to respect permissions. A knowledge base that ignores row-level security is a data leak with good search. Apply the permission check at retrieval, not in the prompt. Instructions in a prompt are not a control.
Every model vendor is a processor. Which means contracts, not just an invoice.
An AI system is auditable when you can answer three questions for any request: who asked, what were they entitled to, and where is that written down.
DPDP, in the order the work actually happens
India's Digital Personal Data Protection Act 2023 is the other clock running. Enforcement is coming, and the preparation is unglamorous. The sequence that worked for us:
- Inventory first. What personal data exists, in which system, for what purpose. You cannot protect a map you have not drawn.
- Processor register and contracts. Every third party that touches personal data on your behalf, with an agreement that says what they may do with it.
- Deletion at ingestion. Build the erasure path when you build the pipeline. Retrofitting deletion into a vector store is a bad month.
- Name a responsible person. Someone owns this. In many mid-size groups that is the technology lead, at least initially.
- Ratify the policies. Drafts protect nobody. A dated, approved policy set is the artefact.
- Engage counsel before you need them. The statute has edges that engineers should not interpret alone.
Disclose your own gaps
The counter-intuitive part: the fastest way through a review is to bring your own list of what is not ready, each item with an owner and a date.
Auditors and boards are not surprised that a growing estate has gaps. They are surprised when the person running it does not know what they are. A dated remediation plan converts a finding from a failure into a schedule, and it moves the conversation from trust to tracking.
That habit is worth more than any control I have implemented. Say the number you can defend, publish the correction when it changes, and keep the list of open items where everyone can see it.