Using AI under JFSC regulation: a practical guide

AI can now read a fund's subscription documents, draft a periodic trust review, or handle a client's call before anyone has opened the file. For a business regulated by the Jersey Financial Services Commission, the interesting question was never whether the technology works (it does) but whether you can let it near client work and still stand behind the outcome. The JFSC has publicly positioned Jersey as a jurisdiction that is open to responsible innovation, encouraging firms to engage with it early when they are trying something genuinely new. It has been just as consistent that adopting a tool never shifts responsibility for the result off the firm. This is a practical guide to what a Jersey business should have in place before AI touches client work. It is not legal advice, and none of it waits on the regulator to bless a particular product. It will not, and you should not build your plans around it doing so.

Oversight and accountability

Begin with the question that tends to go unasked until something breaks: when an AI-assisted process gets it wrong, who owns the outcome? For a Jersey regulated business the answer cannot be the software, the vendor, or a diffuse sense that the system handles it. Jersey's Codes of Practice already place the weight of systems and controls on the board and the key people who run the business, and that weight does not lighten because part of a process is now automated. Every workflow where AI touches client work needs a named, accountable owner who understands what the system does, where it can fail, and what they are attesting to when they let its output stand.

You are not building governance from nothing. The four-eyes checks, sign-off thresholds and board oversight you already apply to material change extend to AI without much translation. The failure we see is the orphaned tool: something capable that a clever member of staff wired up, now running quietly with no owner because everyone assumes someone else is watching it. Map each AI-assisted process to a responsible person, write down what the tool may do and what it may never do, and route material changes to it through the same governance you would use for any other change to how the business serves clients.

Audit trails

If a client, an auditor, or the JFSC asks how a particular decision was reached, you should be able to rebuild it from a record rather than from memory. For each AI-assisted step that means capturing what went in, what the model returned, who reviewed it, what they changed, and when. A recommendation that lived only in a chat window since scrolled into oblivion is not a record; it is an anecdote, and Jersey's record-keeping expectations are not met by anecdote.

In practice this favours AI that runs inside systems you control over staff pasting into consumer tools that log nothing. Keep the prompts and their versions (the instruction handed to the model is part of how the output came to exist) and retain the trail for as long as you retain the client file it relates to, because a machine's involvement does not reset the retention clock. Built properly, this is not an overhead stapled on at the end; it falls out of the process naturally, and it is the difference between believing a system worked and being able to show precisely what it did.

Data arrangements and residency

Before any client data reaches a model, you need a clear answer to where it goes and what becomes of it. That means a written agreement with the provider setting out what they may and may not do with your data (crucially, whether it is used to train their models) together with their sub-processors and where processing physically happens. Jersey's data protection regime expects you to know and control that flow, and the quickest way to lose control of it is the consumer account: a personal AI subscription carries no agreement over client data at all, which is how a well-run firm springs a leak at its edges.

Residency is frequently the deciding factor for a Jersey business, particularly one holding structures for internationally mobile clients who chose the island partly for its discretion. Channel Islands 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 island. Larger cloud models keep their place for tasks that genuinely need them, but that belongs as a deliberate decision with an approved data flow behind it, not the accidental default of whichever tool someone happened to open. Map the flow before the work starts, not after an incident makes you.

Human review points

AI drafts; a person decides. It reads as obvious, and it is exactly where firms slip, because a tool that is right forty-nine times running teaches its reviewer to stop reading on the fiftieth. Design against that automation bias on purpose. For each workflow, define where the human sits, what they are genuinely checking rather than glancing at, and what would make them reject the output. A reviewer who cannot spot the error, or who is not empowered to refuse, is not a control: they are a signature.

Match the review to the risk. A rough internal summary can carry a lighter touch than a client report, a filing to the JFSC, or anything that moves money or commits the business. Decide in advance which categories of output may never leave without a person's explicit approval, and build the system so that automatic sending is impossible for them, not merely discouraged. The aim is not to reintroduce friction everywhere; it is to place human judgement precisely where the consequences land.

Vendor assurance

The tool is a third party, and it earns the same scrutiny you would give any significant outsourcing arrangement, an area Jersey's regime takes seriously, because outsourcing a function never outsources responsibility for it. Before it touches client work, understand the tool's security posture, where it runs, how it handles your data, whether it has suffered incidents and how it answered for them, and the question people skip: what happens to your data and your process if the vendor is acquired or simply disappears. Ask for the security documentation rather than the pitch deck, and treat claims you cannot verify as unverified.

This bites harder for AI features built at speed, whether by a vendor, a contractor, or your own people using AI coding tools. Quick to build is not the same as safe, and the recurring failure modes (exposed keys, unauthenticated endpoints, access far wider than the task needs) are common enough that an independent review before go-live is cheap insurance rather than nerves. A Jersey business should be able to say not just that a tool works, but that someone with no stake in the answer confirmed it was fit to sit in front of client work.

None of this asks you to stall, and none of it waits on a green light from the regulator that will not arrive. It asks you to treat AI the way you already treat every other part of a regulated Jersey operation: owned by someone accountable, recorded so it can be reconstructed, run on data you control, checked by a competent person where it counts, and supplied by a vendor you have genuinely assured. Firms that settle those five things first tend to move quicker afterwards, because they are not renegotiating trust with every new use. If it would help to pressure-test your own arrangements, that is what our operations audit is for, and where the work calls for it, we can deploy on dedicated hardware in your own office so the data never leaves the island.