Using AI under GFSC regulation: a practical guide

AI can now draft a trust review, summarise a due-diligence file, or answer a client's call before a person has finished reading the brief. For a firm regulated by the Guernsey Financial Services Commission, the question was never whether the technology works (it plainly does) but whether you can put it in front of client work and still answer for the result. The Commission has said publicly that it does not see innovation and good regulation as opponents, and that it is open to responsible adoption of AI in financial services. What it has been equally clear about is that using a tool never moves the responsibility for the outcome away from the firm. This is a practical guide to what a regulated business should have in place before AI touches client work. It is not legal advice, and none of it depends on the regulator approving a particular product. It will not, and you should not wait for it to.

Oversight and accountability

Start with a simple question that has an uncomfortable habit of going unanswered: who owns the outcome when an AI-assisted process gets something wrong? In a regulated firm the answer cannot be "the tool" or "the vendor", and it cannot be nobody. Every process where AI touches client work needs a named, accountable person (usually the same senior individual who already owns that function) who understands what the system does, where it can fail, and what they are signing off when they let its output stand.

The good news is that you are not inventing a governance framework from scratch. The disciplines you already apply (four-eyes review, sign-off thresholds, committee oversight of material change) extend naturally to AI. The mistake we see is treating an AI tool as a special case that lives outside the org chart, an orphaned process that hums away in the background because someone clever set it up and everyone assumes it is fine. Map each AI-assisted workflow to a responsible owner, write down what the tool is permitted to do and what it explicitly is not, and put material changes to it through the same governance you would use for any other change to how client work is done.

Audit trails

If a client, an auditor or the Commission asks how a particular conclusion was reached, you should be able to reconstruct it after the fact: not from memory, but from a record. That means capturing, for each AI-assisted step, what went in, what the model produced, who reviewed it, what they changed, and when. A conclusion that exists only in a chat window that has since scrolled away is not an audit trail; it is a story.

Practically, this argues for AI that runs inside a system you control rather than through staff pasting into consumer tools where nothing is logged. Keep the prompts and their versions, because the instruction given to the model is part of how the output was produced. Retain the record for the same period you retain the underlying client file. The regulatory clock does not run differently because a machine was involved. Done well, this is not a burden bolted on afterwards; it is a by-product of building the process properly, and it is the single thing that turns "we think it worked" into "here is exactly what happened".

Data arrangements and residency

Before any client data reaches a model, you need a clear answer to where it goes and what happens to it there. That means a written agreement with the provider that covers what they may and may not do with your data (in particular, whether it is used to train their models) along with their sub-processors and the physical location where processing happens. The trap here is the consumer account: a free or personal AI subscription carries no agreement covering client data, which is precisely how well-governed firms spring leaks at the edges.

For a Guernsey firm, residency is often the deciding factor. On-island hosting is available, and for the most sensitive workloads a right-sized model can run on dedicated hardware inside your own office, so client data never leaves the building or the jurisdiction. Frontier cloud models still have their place for tasks that genuinely need them, but that should be a deliberate choice with an approved data flow behind it, not the accidental default of whichever tool a member of staff happened to open. Map the data flow before the work starts, not after an incident forces you to.

Human review points

AI drafts; a person decides. That sounds obvious, and it is exactly where firms drift, because a tool that is right ninety-five times running trains its reviewer to stop reading. Guard against that automation bias deliberately. Define, for each workflow, where the human sits, what they are actually checking, and what would cause them to reject the output. A reviewer who is not competent to catch the error, or not empowered to say no, is decoration.

Tier the review to the risk. A first draft of an internal summary can carry a lighter touch than a client communication, a regulatory filing, or anything that moves money or makes a commitment on the firm's behalf. Decide in advance which outputs may never leave the building without a person's explicit approval, and design the system so that "auto-send" is impossible for those categories rather than merely discouraged. The aim is not to slow everything down; it is to put the weight of human judgement where the consequences actually sit.

Vendor assurance

The tool itself is a third party, and it deserves the same diligence you would apply to any critical outsourcing arrangement. Before it touches client work, understand its security posture, where it runs, how it handles your data, whether it has had incidents and how it responded, and (the question people forget) what happens to your data and your process if the vendor disappears or is acquired. Ask for the security documentation rather than the sales deck, and treat unverifiable claims as unverified.

This matters doubly for AI features that were themselves built quickly, whether by a vendor, a contractor, or your own team using AI coding tools. Speed of construction is not evidence of safety, and the failure modes (exposed keys, unauthenticated endpoints, over-permissioned access) are common enough that an independent review before go-live is cheap insurance rather than paranoia. A regulated firm should be able to say not only that a tool works, but that someone with no stake in the answer confirmed it was safe to put in front of client work.

None of this requires you to slow to a halt, and none of it requires a signal from the regulator that is not coming. It requires you to treat AI the way you already treat every other part of a regulated operation: owned by someone accountable, recorded so it can be reconstructed, run on data you control, checked by a competent human at the points that matter, and supplied by a vendor you have actually assured. Firms that put those five things in place first tend to move faster afterwards, because they are not relitigating trust with every new use. If you would find it useful to pressure-test your own arrangements, that is exactly what our operations audit is for, and where the work calls for it, we can deploy on-island so the data never leaves the jurisdiction.