Volume 1 Edition 6 | by DATAFORT Founder Marcie D. Terman | 14 September 2026
A few years ago I was hiring scaffolding for some work being done on my home. Everything was arranged until the salesman said, perfectly casually: “Just put your credit card details into an email and send them to me.” Whenever somebody says something like this, I have to make a conscious effort not to go slightly mental.
An ordinary email inbox is not a payment system. Modern email is often encrypted while travelling between systems, but it is not necessarily protected end-to-end, and copies may sit in inboxes and on servers where they can be exposed if an account is compromised.
The problem wasn’t really the email.
It was that nobody appeared to have stopped and thought carefully about how sensitive information should move through the process.
And that is exactly the way we need to think about AI.
That gets us to the point faster and keeps the anecdote doing one job: illustrating the danger of careless process design.
WHERE DOES YOUR DATA GO?
SECURITY STARTS WITH THE DESIGN
That scaffolding company did not have a technology problem. It had a process-design problem. Nobody had apparently stopped to ask: what information are we collecting, how sensitive is it, where are we sending it and who could gain access to it along the way? Those are exactly the questions businesses need to ask when introducing AI. There is a tendency to talk about “using AI” as though it describes one particular technology arrangement. It does not.
An employee copying information into a consumer chatbot is one thing. A business system sending carefully selected information to a frontier model through a commercial API is another. A highly secure organisation operating an appropriate model within infrastructure it controls is something different again.
All three use AI.
But what happens to the data can be very different. According to the Information Commissioner’s Office (ICO)—the UK’s independent regulatory body; responsible for upholding information rights and data privacy – calls the underlying principle data protection by design and by default: privacy and security should be considered from the beginning rather than added once a system has already been built. That intentionality, is the starting point.
DOES THE AI TRAIN ON YOUR CLIENT DATA?
This is one of the questions we encounter most frequently, and it deserves a more nuanced answer than either “yes” or “no”. The leading frontier models can be accessed under commercial arrangements where customer information is not used to train the underlying model by default. OpenAI states that inputs and outputs from its API and business products are not used for model training by default. Anthropic makes the same commitment for its commercial products, including its API. Google Cloud states that customer data used with its managed Vertex AI models will not be used to train or fine-tune models without the customer’s permission or instruction. That is very different from the common fear that every piece of confidential information sent to an AI automatically disappears into the training pool.
But this is where we have to be careful. Not used for training, is in many ways the least important question to ask about access to private or commercially sensitive information. There are other data questions to ask. You still need to understand whether data is retained, how long it is retained, where it is processed, what gets logged, who can access it and what contractual arrangements sit around the service concerning the handling of that data. For example, Anthropic currently says standard API inputs and outputs are normally deleted from its backend within 30 days, subject to exceptions and alternative arrangements such as agreed zero-data-retention terms. Other providers offer their own retention controls and conditions. In the accountancy space where customer data is commercially sensitive, if the data is not anonymized, it is unacceptable that it be retained outside of the company’s control.
So “does the model train on our data?” is an important question because retaining becomes part of the equation.
In my business transactions, I always have this question in the back of my mind because why put data on public display where there may be unforeseen consequences unless that is necessary for our benefit. So the next question is:
DOES THE MODEL NEED TO SEE THAT INFORMATION AT ALL?
Suppose an AI system is comparing figures across a series of documents and identifying inconsistencies.
? Does the model need the client’s full name? ? Their physical address? ? Their National Insurance or Social Security number? ?Bank details?
Quite possibly not.
One of the fundamental principles of UK data protection is data minimisation: process the personal information needed for the particular purpose and no more. The ICO applies that same principle specifically to AI systems.
That can be reflected in the architecture.
A system might remove identifying information before sending data for analysis. This means techniques like substituting a client reference for a name. It might divide a process so that the component performing one task never receives information it has no reason to see.
There is an important distinction between anonymisation and pseudonymisation. Simply replacing “Fred Smith” with “Client 4287” does not necessarily make the information anonymous if someone within the system can reconnect Client 4287 with Fred Smith.
But reducing unnecessary identifying information still reduces potential exposure.
Sometimes the best way to protect sensitive data is not to send it in the first place.
EACH SYSTEM NEEDS ITS OWN SECURITY STRATEGY
There is no reason every use of AI within an accountancy practice should have exactly the same security architecture. For many business processes, the combination of a leading frontier model and an appropriately configured commercial/API arrangement may provide the capability and controls required. Other applications may justify a much more isolated environment. Organisations with particularly sensitive information can use models that can be deployed within infrastructure they control, whether on their own hardware or inside a tightly controlled private-cloud environment.
That comes with a qualification.
Frontier models are operated on their providers’ infrastructure. You cannot download ChatGPT or Claude and install the service on a server in the accounts department. Frontier models have their place but one should use the tool that is most appropriate to the needs of the company.
The level of security should follow the sensitivity of the work.
BUILD WALLS INSIDE THE SYSTEM TOO
Where a model runs is only part of security. You also have to decide what it is allowed to do. Imagine an AI agent assisting with payroll. That gives it a legitimate reason to access employee information. That does not mean it should automatically have access to every client file or supplier information held by the practice. An agent monitoring whether MTD records have arrived needs permission to examine a document store and send reminders. It does not need authority to make payments. This system of least privilege, is the same principle well-designed IT systems have used for years.
In the same way you structure server folder permissions; people, software and AI agents should only have permissions necessary to perform their particular job. As AI moves beyond answering questions and begins taking actions, this becomes more critical. Who can instruct the agent? Which systems can it access? What can it read? What can it alter? Which actions require human approval and which can be completed without approval? And is a log file created to establish what the model did to complete its work?
Good security therefore involves access controls, authentication, separation of responsibilities and appropriate audit trails — not simply choosing a reputable AI provider.
WHAT DO YOU KEEP — AND FOR HOW LONG?
There can be perfectly legitimate reasons to retain information.
Accountants have regulatory, legal and professional record-keeping obligations. Logs of an automated process may also be extremely useful when investigating what happened or demonstrating that a particular action took place. But that does not mean every piece of information should be retained indefinitely. UK data-protection principles require organisations to consider both how much personal information they process and how long identifiable information genuinely needs to be kept. So retention should be a decision, not an accident. What information does the system store? Why? For how long? Who can retrieve it? When should it be deleted?
This matters particularly when AI is incorporated into larger workflows. The model provider may have one retention policy, while your application, logging system, document store and backup platform each have another.
The journey of the data is bigger than the model.
AND WHAT HAPPENS WHEN THINGS GO WRONG?
Security conversations often concentrate on confidentiality: stopping the wrong person from seeing information. There is another side to security that accountants already understand very well. You also have to make sure the right people can still get the information when they need it. If an AI-enabled process becomes an important part of the practice, what happens if a supplier goes offline? What happens if data becomes corrupted? Ransomware attack? What happens if credentials are compromised? Could the practice continue operating? And could the system and its underlying data actually be recovered?
This is where backup and recovery belong in the AI discussion.
The National Cyber Security Centre points out that attackers deliberately target backups because destroying the recovery route makes a ransomware attack considerably more damaging. Its guidance recommends resilient backups and, crucially, regular testing to make sure restoration actually works. Having a backup is not quite the same thing as knowing you can recover from it. How much time passes between backups lets you theorize how much data is at 100% risk of loss because it never makes it into the backup file at all.
A well-designed AI system therefore needs the same operational discipline as any other important business system: appropriate backups, protected copies, recovery planning and testing. AI does not make those fundamentals obsolete. It makes them more important as more business processes depend on software.
GDPR ISN’T A FINAL CHECKBOX
This brings us back to the scaffolding company which I mentioned at the start of this week’s edition. The mistake was not that somebody failed to add enough security after designing the payment process. The mistake was designing a process in which emailing credit card information appeared sensible in the first place!
The same principle applies when AI is introduced into an accountancy practice.
If somebody develops an entire workflow and only then asks the compliance team, “Is this GDPR compliant?”, the sequence is backwards. Ask the questions while the system is being designed. What is the purpose? What client information does it genuinely require? Can any of that information be removed or pseudonymised? Where will the remaining information be processed? What contractual protection applies? How long will it be retained? Who or what will have access? What actions can the system take? What gets logged? How do we recover if something goes wrong?
For higher-risk processing, there may also be a requirement to conduct a Data Protection Impact Assessment. More broadly, the ICO’s guidance is explicit that organisations using AI to process personal data remain responsible for applying data-protection principles throughout the lifecycle of that system.
SO, WHERE DOES YOUR DATA GO?
There isn’t one answer. And that is actually reassuring. Using AI does not automatically mean surrendering your clients’ information to a model. A badly designed process can expose far more information than necessary. A well-designed one can minimise what leaves the business, strip away unnecessary identifiers, use commercial model arrangements with appropriate data protections, restrict permissions, separate clients and functions, maintain useful audit records, control retention and provide a tested route to recovery.
Where justified by the sensitivity of the information, a different architecture can keep even more of the processing within infrastructure controlled by the organisation. The question therefore should not simply be: “Is AI safe?” A much more useful set of questions is: What data does this particular process actually need? Where will it go? What will happen to it when it gets there? Who or what will have access to it? And what happens when something goes wrong?
Those are questions we already know how to ask about important business systems.
AI simply makes it essential that we keep asking them. Because whether it is a credit-card number travelling through an email or a client’s financial information travelling through an AI-enabled process, the underlying principle is the same:
Security doesn’t begin with the technology you buy. It begins with the care you take in designing the journey your data will make.
If you have a process in your practice that you think AI could improve, DATAFORT can help you work through what should be automated, what information the system actually needs and how the process should be structured before anything is built.
Book a 15-minute conversation with us. Bring us one process that is taking too much time, and we’ll help you start asking the right questions.
Next Edition — Don’t Automate the Inefficiency
There is an easy mistake to make once you decide to automate a process:
taking the process you already have and simply making it run faster.
But preparing work for automation often exposes something much more valuable. You begin to see the unnecessary hand-offs, repeated checking, duplicate data entry, habitual workarounds, badly designed approval stages and qualified accountants spending time on administration that never really needed their expertise.
So in the next edition we are going to look at a different approach: map the existing process → question why each stage exists → redesign it → then automate the improved version.
DATAFORT Ltd https://datafort.com/development e: [email protected]
