AI for Professional Services Firms: Confidentiality First

A professional services firm can use AI without risking client confidentiality by keeping the work inside a boundary the firm controls: run the system on hardware you own, scope retrieval to each engagement so conflicts walls hold, require a named person to approve anything consequential, and keep a tamper-evident record an auditor can verify independently.

What actually happens to client data when a firm uses a hosted AI tool?

It leaves your control, and it may leave the country. When a fee earner pastes a draft share purchase agreement, a client board pack or a set of management accounts into a hosted assistant, that material travels to infrastructure someone else owns, is processed under terms your firm did not write, and may be retained or routed through sub-processors you have never assessed.

That is a data protection problem before it is an AI problem. Under the UK GDPR and the Data Protection Act 2018 your firm remains the controller for client personal data and carries accountability for every processor in the chain. The ICO guidance on AI and data protection is specific about what that requires: a lawful basis, transparency, and a documented assessment of the risk before deployment rather than after it.

It is also a confidentiality problem that sits entirely outside data protection. Most of what a professional services firm handles is commercially sensitive rather than personal: deal terms, financial models, dispute strategy, tender pricing, drawings that have not been filed. A data processing agreement covers none of it. Your duty of confidence to the client does, and that duty does not soften because the disclosure was convenient.

Does your engagement letter actually permit it?

Usually not, and this is the cheapest thing to check first. Standard confidentiality wording permits disclosure to named individuals, to identified subcontractors, and to advisers the client has approved. A general purpose hosted assistant is none of those, so using one is a disclosure you never obtained permission for.

There are two honest routes out. You renegotiate terms with every client, name the processor, and accept that some clients will refuse. Or you keep the processing inside your own boundary, in which case no disclosure to a third party occurs and the question does not arise. The second route is the one that scales, because it does not require you to go back to a thousand clients and ask.

Clients in regulated sectors are increasingly writing their own restrictions into your terms rather than waiting for yours. I have read supplier questionnaires that ask where model inference physically happens, which sub-processors touch the material, and whether the firm can produce evidence after the fact. A firm that cannot answer those three is at a disadvantage before the evaluation starts.

How does an AI system stay on the right side of a conflicts wall?

It has to inherit the barriers you already operate, and it has to prove that it did. An information barrier works because access is scoped to a matter and denied by default everywhere else. The moment you index every document in the firm into a single retrieval store, you have built a machine that will cheerfully summarise the other side's file.

The control is boring and it works. Retrieval scope is bound to the engagement, not to the user's curiosity. Identity comes from the directory you already run, so retrieval runs under the user's own permissions: material a person is not cleared to open is not put in front of them. Every retrieval is recorded together with the documents that were in scope at the time.

That last part matters more than most firms expect. When a conflict allegation arrives eighteen months later, the useful answer is not that your policy prevented it. The useful answer is a record showing which files were reachable, by whom, on what date.

What will an insurer, a regulator or a client's auditor want to see?

Evidence, not assurances. Assume your professional indemnity insurer will ask how AI is used in the delivery of advice, and assume that being able to show your working will matter at renewal.

This is the part we built the system around. In the Mickai Sovereign Intelligence Operating System, every consequential action is sealed in an Open Audit Record under ML-DSA-65, the post-quantum signature scheme NIST published as FIPS 204 in 2024. The record is tamper-evident: altering it makes verification fail. An auditor can export a record and verify it offline with a public key, using tools that are not ours, which is the only kind of proof worth offering.

Consequential actions also wait. Nothing reaches a client, a court, a regulator or a counterparty until a named person approves it, and that approval is part of the sealed record.

What changes when the system runs on hardware the firm owns?

The boundary moves back to where your professional duty already sits. SIOS runs on hardware the customer owns, is capable of running entirely offline, and does not send data out. Whatever the system reads stays on your equipment, which means the confidentiality analysis becomes the same one you already apply to your document management system.

I want to be careful about what I am arguing. I am not against the companies that build the compute and the cloud layer, and for a great deal of work the cloud remains the right answer. What I am against is the assumption that a regulated firm must rent its intelligence, ship privileged material offsite, and take a vendor's word for what happened to it afterwards.

The system ships as studios: focused workspaces for drafting, document reading, research, review, records and scheduling. There are 63 in total, 14 production-ready at launch and 49 in development, drawing on 50 specialised models we call brains. A firm switches on the few that match its work rather than buying a platform most of which it will never open.

Which work should a firm hand over first?

The work that is high in volume, low in ambiguity, and reversible before it reaches a client. Reading a bundle of contracts and producing a schedule of the key terms. Pulling figures out of a client's records into a working paper that cites the source page for every number. First-pass drafting from your own precedent bank rather than from the open internet. Preparing a record of a meeting and the actions agreed in it. Checking a tender response line by line against the requirements matrix.

The pattern underneath all of those is the same. The system reads and assembles, and a qualified person decides. That is also how liability stays where your regulator and your insurer expect it to sit, with the named individual who signed the advice rather than with a supplier's terms of service.

What I would not start with is anything that goes straight out of the door. Advice to a client, a statutory filing, an audit opinion, a signed certificate: put those behind an approval step on day one and keep them there long after the system has earned some trust. Most of the cost in professional work is the reading that comes before the judgement, not the judgement itself. That is the part worth giving away.

Where should a firm start?

With one workflow, one named owner and a written boundary. Take a single task from the list above, put a partner's name against it, and write down exactly what material is permitted to leave your premises. In most firms the correct answer to that last question is nothing at all.

Then write the evidence requirement into procurement before you evaluate anything. Ask any supplier to produce a record of one specific action, exported, and verified using a tool the supplier does not control. The NCSC guidelines for secure AI system development are a sensible structure for the rest of the assessment, and an ICO data protection impact assessment belongs before deployment, not alongside it.

Mickai LTD is a UK company, number 17166618, held privately by me. MICKAI is a registered UK trade mark, UK00004373277. We hold 104 filed UK patent applications carrying 2,340 claims, filed and not granted, with me as the named inventor. The closed beta is open, and one regulated company is onboarding as a design partner. If your firm's problem is that the work is confidential and the tools are not, that is the problem the system was built for.

Frequently asked questions

Can a professional services firm put client documents into a public AI chatbot?

Not without permission. Pasting client material into a hosted assistant is a disclosure to a third party, and most engagement letters do not cover it. You also take on accountability under the UK GDPR and the Data Protection Act 2018 for a processor you have never assessed. Keep the material inside a boundary your firm controls.

Do we need to change our engagement letters before using AI on client work?

It depends where the processing happens. If client material leaves your infrastructure, treat it as disclosure to a third party, update your terms, and name the processor and the location. If the system runs on hardware you own and nothing leaves the building, no third-party disclosure occurs and existing wording usually holds. Take your own legal advice.

How do you prove what an AI system actually did on a client matter?

With a record the client's auditor can verify without trusting you. In SIOS every consequential action is sealed in an Open Audit Record signed under ML-DSA-65, the post-quantum scheme NIST published as FIPS 204 in 2024. It is tamper-evident: any alteration makes verification fail. The record exports and can be checked offline with a public key.

How does AI respect conflicts of interest and information barriers?

By inheriting the barriers you already run rather than working around them. Retrieval is scoped to the engagement, identity comes from your existing directory, and access is denied by default. Retrieval runs under the user's own permissions, so material they are not cleared to open is not put in front of them, and every retrieval is recorded with the documents that were in scope.

What should a firm ask an AI supplier during procurement?

Three things. Where does inference physically happen, and which sub-processors touch the material? Can you export a record of one specific action and have it verified with a tool you do not control? Who approves output before it reaches a client? The NCSC guidelines for secure AI system development cover the rest of the assessment.

Written by Micky Irons, founder and chief executive of Mickai LTD, which builds a sovereign AI operating system for regulated organisations. More at mickai.co.uk.