Private AI for internal audit workpapers
An internal audit workpaper is one of the more candid documents a company produces about itself: a specific control that isn't operating as designed, a sample of transactions that didn't reconcile, a process gap nobody has fixed yet. Using AI to help draft and organize workpapers is a reasonable time saver on repetitive documentation. The findings themselves are not something most companies want sitting on a vendor's server before management has had a chance to remediate.
What a workpaper actually documents
A workpaper typically records the control being tested, the sample selected, the evidence reviewed, and the auditor's conclusion, including any exception found. Taken together across a full audit cycle, a set of workpapers is a detailed map of where a company's financial controls are weakest, exactly the information a company doesn't want circulating before the finding is remediated and closed, whether that's a segregation-of-duties gap, an access control that wasn't reviewed on schedule, or a reconciliation that's been done manually because the system integration was never finished.
Pasting excerpts of that material into a general-purpose AI tool to help write up a finding sends unremediated control weaknesses to a third party's infrastructure, under a retention policy written for general use, not for audit evidence. That's a different category of exposure than most of what goes through a shared AI tool day to day.
What changes when the drafting model is self-hosted
Running the drafting assistant on a dedicated DGX Spark keeps workpaper drafts, finding language, and sample documentation inside the audit function's own environment. The internal auditor still gets help turning testing notes into a properly formatted workpaper, or a finding into clear remediation language for management; the material behind that draft never crosses into a vendor's servers to get there.
A practical setup is Open WebUI configured with the audit function's workpaper template and prior-year findings as reference, restricted to the audit team rather than the broader finance organization. Teams that keep a library of control narratives and past findings for reference, similar to the approach in our piece on on-premise RAG, can have the model check a new finding against how a similar issue was written up previously, for consistency in severity language, without that history of prior weaknesses sitting anywhere outside the audit function.
What the model is useful for, and what stays with the auditor
A drafting model is a reasonable help for formatting workpapers to a consistent standard, summarizing a large sample of test results into a workpaper narrative, and drafting first-pass remediation language for a finding. It is not a substitute for the testing itself or for the professional judgment about whether a control gap rises to the level of a reportable finding. That judgment, and the evidence supporting it, has to trace back to work the auditor actually performed, not to inference from a model that has no access to the systems under review.
What this doesn't solve
Self-hosting the drafting model doesn't satisfy independence or documentation requirements under whatever audit standards apply, doesn't replace audit committee reporting, and doesn't decide who inside the company should see a finding before remediation is complete. Those remain audit-function policy questions. What it removes is one specific exposure: a record of unremediated control weaknesses sitting on a third party's infrastructure before management has had the chance to fix them. See pricing for what a dedicated Spark costs for an internal audit team.