Is it safe to use ChatGPT for internal audit work?

With a consumer chatbot, no: not with evidence, draft findings, access lists, names or anything else from an engagement. With a business or API plan under your organisation's contract, in a region you chose, with a policy that says what may be sent, yes. With a model you host on your own infrastructure, yes, and the question of what leaves the network mostly disappears. The tool is not the problem. The terms, the data and the absence of a rule are.

Why the consumer tool is the wrong one

In 2023, three Samsung engineers pasted confidential source code and meeting notes into ChatGPT within weeks of the company allowing its use. Nothing malicious happened; the code was simply now outside the company, in a system whose consumer terms at the time allowed it to be used for training. Samsung restricted the tool and the story became the standard example because it is so ordinary. Nobody set out to leak anything. They set out to fix a bug before lunch.

The terms are the point. On consumer plans, conversations may be used to improve the provider's models unless the user turns that off; on business and API plans the main providers state that they do not train on customer data by default (OpenAI's own summary is the clearest example). The same model, two different contracts. An auditor on the free tier is working under the first.

Audit material is worse to leak than most. An internal audit system holds the risk assessment, the evidence, the draft observations before management has seen them, and every action plan that is late: the most concentrated map of an organisation's weaknesses that exists anywhere in it. The post on single-tenant audit systems goes through why that changes the hosting conversation; it changes the chatbot conversation for the same reason.

What to keep out, whatever the tool

• Evidence. Bank statements, access lists, contracts, screenshots, extracts. If it is in a work paper, it does not go in a prompt.
• Draft observations and reports before they are final, and most of them after. (What a model can usefully draft from inside a system that holds the work paper is in can AI write audit observations and reports.)
• People. Names, email addresses, employee numbers, anything about an individual's performance or conduct. In India the Digital Personal Data Protection Act 2023 applies to this as it applies to any processing; in Europe the GDPR does. The model does not need to know who the control owner is to draft the finding.
• Anything from an investigation, a whistleblowing case or a regulator's correspondence.
• Anything a contract says stays inside. Customer data under NDA, audit-committee papers.

What is fine with a public tool: a question about a standard, a generic control description, the wording of a sentence with the specifics replaced by placeholders, a summary of a document that is already public. The test is whether you would be comfortable seeing the prompt quoted in the audit committee minutes.

The four options, from least to most contained

1. A consumer chatbot. Free, fast, and the data is under the provider's consumer terms. Fine for the public-only uses above. Not for anything else, and the policy should say so in one line.
2. A business plan. The same tools under a contract that excludes training by default and usually adds retention controls and an admin console. The provider still holds the text. Read the data-processing terms and the region, and keep people out of prompts anyway.
3. An API under your own key, in your region. Amazon Bedrock, Azure OpenAI and Anthropic's API are built for this: your organisation's agreement, a region you pick, no training on your data, and on Bedrock a guardrail that can mask personal data on every call. This is what "bring your own key" means in an audit system, and it is the practical answer for most functions that want a strong model with a defensible contract.
4. A model you host. Ollama, vLLM or a similar server running an open-weight model on your own machines. Nothing leaves. The trade is quality and effort: a small local model drafts a finding well and writes an executive summary less well, and someone has to run the server. For a function whose policy says audit text does not leave the network, it is the only option, and it works.

The EU AI Act adds one more duty since February 2025: Article 4 requires organisations to ensure a sufficient level of AI literacy among staff who use AI systems. For an audit function that means the people using the tool know what the terms say and what the model cannot be trusted with. This post is a reasonable start.

A policy that fits on a page

Six lines cover most of it. Which tools are approved, and under which plan. What may never be pasted (the list above). Where the approved tools run and under whose key. That every draft is edited by a person before it becomes a record. That the use is logged where the work is done. And who to ask when it is unclear. Standard 10.3 of the Global Internal Audit Standards makes the chief audit executive responsible for the function's technology and requires collaboration with IT and information security to implement it; a page like this is what that collaboration produces.

The post on how audit teams use AI and where it fails covers the other half of the policy: what the tools are good for once the data question is settled. And if your organisation's AI use is bigger than your own team's, the post on auditing an AI system is the next one.

How AuditEase Pro handles it

AuditEase Pro ships with the AI off. Nothing leaves the deployment until an administrator names a provider, and the boot log says which one, so a silent fallback cannot hide. The choice is yours: Amazon Bedrock in a region you pick, Azure OpenAI, Anthropic, or any OpenAI-compatible server such as Ollama or vLLM on your own network. The key is yours in every case; on the self-serve plans it is set as a secret on your workspace with a monthly budget you choose, and the custom offer runs Bedrock or Azure inside your own cloud account with your guardrails.

What is sent is record text only: the prompt builders never read a person field, email addresses and users' full names are replaced with "[person]" before anything leaves, and with Bedrock a guardrail can mask personal data on every call. Documents are read only through the system's own document route, by a sandboxed process with memory, time and size limits. Each run is a ledger row with the provider, the model, the prompt version, the tokens and the cost; a monthly budget refuses requests past the limit; a daily cap applies per person. When an audit is purged, the texts of every run that read it are blanked too. Search and answers start from the records the person may open, so a business owner's question never reaches the audit team's drafts.

The live demo runs the same product with the AI on, against a model Hikmah hosts, with a fictional organisation in it. The Settings screen there shows the provider, the model and the switches, which is the page your own deployment would show your IT team.