Your finance team has asked for ChatGPT. Some of them are already using it on their own accounts, which you may or may not know yet. Somebody sensibly said this needs to go past compliance first, and that is where it has sat for two months, because the request arrived as "can we use AI" and there is no useful answer to that question.
The conversation restarts when you stop asking whether AI is permitted and start describing what the tool will do, with what data, reviewed by whom, and recorded where. Those are implementation questions, and they are answerable.
To be explicit before any of it: this is an implementation guide, not compliance advice and not a regulatory opinion. Your compliance function and your own advisers decide what is permissible in your firm. Everything below is written to be taken to them, not used instead of them.
The regulator's published position is that your existing rules already apply
The FCA states on its own website that it does "not plan to introduce extra regulations for AI" and will "rely on existing frameworks", describing its approach as "principles-based and focused on outcomes". The two frameworks it names there are the Consumer Duty and the Senior Managers and Certification Regime, and it says its rules "emphasise accountability for senior managers". Its AI Update publication sets out how existing rules apply.
The operational consequence is not "carry on", it is the opposite of a shortcut. There is no separate AI standard to satisfy, so the tool has to fit the controls you already operate and be evidenced the way you already evidence things, with a named senior individual accountable in the ordinary way. Which specific rules bite in your firm depends on your permissions and your business, and that is a question for your compliance function, not for this post.
What finance teams realistically use it for, and where the risk concentrates
The honest use cases are unglamorous, and most are drafting and reading rather than calculating. Summarising long documents (audit findings, contracts, policy packs, lender or investor correspondence). A first draft of commentary, board narrative or a policy update that a person then rewrites. Explaining an unfamiliar accounting or regulatory concept. Writing formulas, queries and reconciliation logic. Turning messy text into structured data. Finding where a document set deals with something.
The risk sits in three places, and only one is about the model.
What goes in. Client and personal data, unpublished results, pricing, board material, anything price sensitive or inside information, and anything under a confidentiality undertaking. This exposure starts on day one, before any project exists, on personal accounts.
What comes out and is relied on. A plausible, confident, wrong answer is more dangerous than an error, because an error gets noticed. Treat this as a drafting and reading assistant, not a calculation engine: a number produced in a chat window has no working behind it for a reviewer to check, and "the AI worked it out" is not a working paper. Anything reaching a customer, a regulatory return or an audit file should have a named reviewer whose review is recorded. That is our method, not a rule we are stating on the regulator's behalf.
Whether either leaves a trace. The part firms discover last, and the subject of the next section.
The consumer and business distinction matters more here than anywhere else
The training default inverts between the two, in the direction that catches people out.
Content from ChatGPT Business, ChatGPT Enterprise and the API is not used to train OpenAI's models by default: business customers are opted out unless they explicitly opt in. Consumer ChatGPT is the other way round, and content from the individual plans may be used for training unless the user turns it off in the privacy settings. One carve-out surprises people who believe they have switched training off: if a user gives a conversation a thumbs up or down, that whole conversation may be used for training regardless.
So the population that matters most in a regulated firm is not the one in the procurement paper. It is the staff who never moved off a personal plan and are pasting client correspondence, draft results or contract text into a service that is opted in by default, with no record that it happened. Buying corporate seats does nothing about them until you find them and move them.
Record-keeping and supervision: decide what you would be able to show
Ask your compliance colleague what they would need to produce if this work were ever questioned, and you get a version of the same four things: what was produced, what went into it, who checked it, and that the record still exists.
Most of that is your job rather than the vendor's, which is the reframe worth making early. If an AI-assisted draft becomes a board paper, a customer letter or a regulatory submission, the evidence that matters is the review and approval step, recorded where you already record approvals. The chat transcript is supporting material. Building the control into your own document workflow is easier and more defensible than reconstructing it from the vendor later.
Where the vendor does matter is visibility of the tool itself, and that splits sharply by tier. ChatGPT Enterprise and Edu have the Compliance Platform, which pushes workspace log events into eDiscovery, DLP or SIEM tooling, with named integrations including Microsoft Purview, Netskope, CrowdStrike and Varonis. One detail before you write a retention process around it: the platform holds 30 days of data, so anything longer means continuously pulling those logs into your own store. ChatGPT Business has no equivalent export.
There is also an unresolved point not to let a supplier gloss over. OpenAI's enterprise privacy page states that Business admins can view, access, export and delete end-user conversations. A more recently updated help-centre article states that data export is not available in a ChatGPT Business workspace and that members cannot automatically view other members' private chat history. Those two OpenAI-owned sources contradict each other. If your supervision approach depends on either being true, get the answer in writing before you commit and keep it with your DPIA.
Why regulated firms usually land on Enterprise
Not because Enterprise is better in the abstract. Plenty of firms are well served by ChatGPT Business, and Enterprise is sales-led, meaning a procurement cycle and a security review you have to run. Four gaps decide it in a regulated firm. The full comparison is in the ChatGPT Business and Enterprise governance gap rather than repeated here.
ISO 27001 is the one that stops deals. OpenAI's certification covers the API, ChatGPT Enterprise and ChatGPT Edu. Business sits outside that scope, and UK procurement packs ask for ISO 27001 by name far more often than for SOC 2.
Audit log export, covered above, is Enterprise and Edu only.
SCIM provisioning is absent on Business, so joiners and leavers are handled by hand. Single sign-on controls how people authenticate. It does not deprovision them, and leavers are exactly the sample an auditor pulls.
Data residency cannot be retrofitted. It is not available on Business at all, and on ChatGPT it applies to new Enterprise and Edu workspaces, provisioned at creation. A firm that runs on Business for eighteen months and then wins a client contract requiring UK storage is not looking at a settings change.
One more for the finance function itself: Business is self-serve and does not support invoice billing, purchase orders or net terms. In some firms that decides the tier on its own.
Third parties and outsourcing, at a high level
In most firms' frameworks this is a third-party arrangement and gets assessed like one. Scope and materiality are for your compliance function, but the facts they will ask for are the same every time and you can gather them before the meeting.
Your DPA counterparty as a UK customer is OpenAI OpCo, LLC, the US entity, not OpenAI UK Ltd, even though a UK entity appears on OpenAI's sub-processor list. The transfer mechanism named in that DPA is the EU Standard Contractual Clauses as amended by the ICO's UK Addendum, which is a different instrument from the standalone IDTA. If your DPIA template names that instrument, correct the wording. Your transfer risk assessment and lawful basis remain yours.
Two more come up. Zero Data Retention is not a switch in settings: it requires prior approval by OpenAI and acceptance of additional terms, it is an API-side control, and it carries carve-outs where content can still be retained or reviewed with advance written notice. If a supplier or an internal champion tells you nothing is ever stored, that is checkable and the answer is a document. And if you commission anyone to build on top of this, accountability stays with your firm, so the same questions apply to them: whose account, whose repository, whose keys, and who you call when it stops. What it does and does not cover is set out in zero data retention, in practice.
A sequence that gets approved instead of blocked
Roughly in this order, and none of it needs an engineer until the last step.
- Write down three named use cases, not a capability. For each one: what data class it touches, who does it today, and what the output feeds into.
- Find the personal accounts first. Expenses claims, single sign-on logs and a direct question in a team meeting will get most of them. Closing that exposure is an argument for the project, not against it.
- Test the tier against your own paperwork. Search your DPIA template and your last three client questionnaires for ISO 27001, audit log, SIEM, data residency and provisioning. Their answers pick the tier, not a feature comparison.
- Write the human review rule per use case. What may never leave the firm without a named reviewer, and what that reviewer is confirming. One line each.
- Decide where the evidence of review lives and for how long, in the systems you already use for approvals.
- Agree with compliance who the accountable senior individual is, and let them decide whether anything needs to change in that person's responsibilities.
- Run a bounded pilot with a review date, with compliance inside it rather than reviewing at the end. A pilot a compliance colleague helped design is one they can defend.
- Take all of it back to your compliance function and advisers for the decision, which is theirs.
How to decide this cheaply
The real choice is not whether to allow ChatGPT. It is whether the use in your firm is documented and supervised or undocumented and invisible, because the second is already happening while the request sits in the queue. A blocked request does not remove the risk. It moves it onto personal accounts where you have no visibility, no export and no record. If you have the internal capacity, run the sequence above yourself: it is written so you can.
The wider comparison, including the options either side of this one, is in our guide to what OpenAI offers a UK business.
We are an OpenAI Select Partner and we do this work, so read that with appropriate scepticism. We resell nothing and take no margin on your usage, so we have no reason to talk you up a tier or into a build you do not need, and we do not give regulatory opinions: that decision belongs to your compliance function and your advisers. If you want the scoping, the tier decision and the controls documented before you commit, request a quote, or read what an implementation involves on our OpenAI implementation page.
Stay Updated with Our Latest Insights
Get expert HubSpot tips and integration strategies delivered to your inbox.




