Why private, on-device AI could change how IT auditors approach ITGC, SOX, SAP and audit evidence analysis.
It is week three of fieldwork. Sitting in your working folder you have:
You could work through it manually. Or you could ask an AI to help — so you open a browser tab, and your cursor hovers over the upload button.
Would you upload all of that to a public AI chatbot?
Most auditors hesitate at exactly that moment. The hesitation is correct — it is professional instinct doing its job.
AI is genuinely good at the work that consumes audit hours:
The question is no longer whether AI can help auditors. The question is where the audit data is processed.
Audit evidence is unusually sensitive, even by enterprise standards. In a single engagement you routinely handle:
Many organisations restrict where this material may be sent — not because cloud AI is reckless (it is not), but because those restrictions predate AI and AI did not repeal them. The honest framing is not "cloud AI is unsafe." It is a question every auditor should be able to answer about any tool they use:
Where does my data go?
If you cannot answer that in one sentence, you are not ready to upload.
| Aspect | Cloud AI | Private / On-Device AI |
|---|---|---|
| Data processing | External infrastructure | User's device or browser |
| External API | Often required | Can operate without an external AI API |
| Internet dependency | Often required | Can support offline operation |
| Sensitive evidence | Requires governance and approval | Can remain on the device |
| Data boundary | External provider involved | Local processing boundary |
| Audit use case | Depends on organisational policy | Useful for privacy-sensitive workflows |
On-device AI does not mean "100% secure." Anyone who tells you otherwise is selling something.
It changes where your data goes. It does not remove the need for:
It narrows the data boundary. It does not eliminate the need to think.
Not a product category — a working pattern:
Private AI Auditor = AI assistance + local processing + audit-specific workflows + human validation
The third is the one people underrate: a generic chatbot does not know that SAP_ALL is a finding, that a bridging letter has required contents, or that a CUEC is the reader's problem. You can explain that every session — or the tool can already know it.
Upload your population and sample, and ask the AI to flag rows that look like exceptions against your test attributes. You decide what is actually an exception.
Analyse user and role information to surface potentially risky access — privileged profiles, dormant accounts with live authorisations, standard users that should have been locked. You confirm against the system.
Identify potentially incompatible access combinations and — more usefully — have the conflicting business activities explained, not just the technical role names. Our guide on what SOD analysis is and why it matters for SOX compliance covers the fundamentals, and the 15 S/4HANA conflict pairs external auditors flag first covers the ones that come up repeatedly. You validate every conflict.
Review change tickets for approval, testing evidence, implementation records and separation between developer and implementer. You judge whether the evidence is sufficient.
Locate relevant controls, exceptions and complementary user entity controls, and get the audit implications summarised. If a period gap is involved, bridging letters have specific requirements worth checking against. You read the exceptions yourself.
Analyse screenshots, documents and tables — extracting a SUIM output into a table you can actually work with, rather than retyping it. You verify the extraction is faithful.
Summarise risk indicators across an environment and prioritise where auditor attention should go first. You own the risk conclusion.
Convert analysis into structured observations and workpaper content — condition, criteria, cause, effect, recommendation. You sign the workpaper.
AI assists the auditor. The auditor makes the final judgment.
You are testing ITGC over an SAP S/4HANA environment, with the user listing, privileged access extract, role assignments, change tickets and configuration screenshots in hand. Here is what you might actually ask:
"Identify users with highly privileged SAP access and explain the potential audit risk for each."
"Review these change tickets and identify changes where approval evidence appears incomplete, or where the developer and implementer are the same person."
"Identify potential SOD conflicts in this role assignment extract and explain the conflicting business activities in plain language."
"Review this SAP screenshot and identify the evidence relevant to the control objective 'password parameters are configured in line with policy'."
"Summarise which of these 40 change tickets are emergency changes, and what retrospective approval evidence exists for each."
Every answer is a hypothesis, not a finding.
If the AI says user DDIC holds SAP_ALL, you open SUIM and confirm it. If it says a change lacks approval, you open the ticket. If it flags an SOD conflict, you check the actual authorisation objects — not just the role names.
The AI moved you from 4,000 rows to 12 candidates in a minute. That is the value. The last mile is yours, and it always was — anything you put in a workpaper, you can defend.
This is the problem NextGen GRC is trying to solve with the GrcAI Assistant.
The design premise: auditors should not have to choose between using AI and respecting the sensitivity of their evidence.
GrcAI is built so that the AI model runs in the browser, on the auditor's own machine. The model is downloaded once and the analysis modes are designed to work locally, so that for document and evidence analysis the content is processed on the device rather than sent to an external AI service.
That is the design intent, and it is the kind of claim you should confirm for yourself rather than take from an article — including this one. The checklist in the next section is written to be used that way.
It is built around audit work rather than general conversation. The workspace is organised into audit-shaped modes rather than a single chat box — among them Audit Prep, Workpaper Autopilot, Exception Triage, SOD Analysis, SAP Dev, Risk Score, Data Extraction & Generation, Data Analysis, Summarize and Code Review, with a separate SOC report analyser.
There is a longer write-up of the architecture in GrcAI: the private, on-device AI assistant for audit and GRC teams if you want the detail.
| Aspect | Generic AI chatbot | GRC-focused AI workspace |
|---|---|---|
| Audit terminology | Explain it each time | Assumed |
| ITGC workflows | You design the prompt | Built around the control cycle |
| SAP knowledge | General | Transaction codes, user types, authorisation objects |
| SOD | Reasons from first principles | Conflict logic already framed |
| SOC reports | Reads it as a document | Reads it as an audit artefact |
| Evidence analysis | Generic OCR | Tuned to audit evidence formats |
| Risk assessment | Generic frameworks | Audit risk language |
| Workpapers | You reformat everything | Structured toward documentation |
| Privacy architecture | Provider-dependent | A design constraint from the start |
The distinction is not intelligence — it is context. A general model is often perfectly capable; it just does not know your engagement, standards or evidence conventions until you tell it.
Which suggests the future may not be auditors using chatbots, but auditors working inside AI-powered audit environments. How generative AI is reshaping the ITGC testing lifecycle covers what changes stage by stage.
AI should not replace professional judgment, evidence evaluation, control interpretation, sampling decisions, exception validation, risk conclusions, or auditor accountability.
That last one is not negotiable. When a regulator asks why a control was concluded effective, "the AI said so" is not an answer. PCAOB AS 2201 guidance on evaluating ITGCs has not changed because a model got faster.
AI can accelerate the work. It should not own the conclusion.
Run any tool — including ours — through this:
If a vendor cannot answer 1 to 5 clearly and specifically, that is your answer.
AI will become ordinary in audit work — not a pilot or an innovation initiative, just part of how testing gets done, the way data analytics did. But enterprise adoption will turn on two things together:
Capability + Trust
Capability alone produces demos that never clear the security review. Trust alone produces a tool nobody opens. The audit AI that succeeds will help auditors work faster while respecting the sensitivity of what they are working with — and be honest about what it cannot do.
In audit, an unverifiable answer is not a fast answer. It is a liability delivered sooner.
You can try the NextGen GRC GrcAI Assistant and see how it handles your own evidence — the model is designed to run in your browser, so you can put it through the seven questions above, on your own evidence, before committing to anything.