How secure is AI automation for business data?

An AI automation is a set of connections: it reads from some systems, sends information to an AI model, and writes results back somewhere. Each connection is a place where data can travel further than it should. The AI model itself is only one part of the risk.

That means the same idea, such as sorting incoming enquiries, can be built carefully or carelessly. The difference is in choices made before any code is written: what the system can see, where information goes and what it is allowed to do.

Least access

Give the system its own account with only the permissions the task needs. A tool that drafts replies does not need to delete records or read the whole shared drive.

Only the data needed

Send the model the parts of a record the task uses, not the entire customer file. Leaving out fields such as dates of birth or account details removes them from the risk entirely.

Know where data goes

Check the AI model provider's terms: whether your data may be used to train their models, what retention settings are available and how long inputs are kept, and which region data is processed and stored in. Business and API plans often differ from consumer apps on these points, so read the terms for the plan you actually use.

Credentials handled properly

Passwords and API keys belong in a secure secrets store, not in spreadsheets, emails or code. Each key should be limited in scope and easy to revoke if something goes wrong.

Human approval for sensitive actions

Work involving customers, money, approvals or permanent records should normally keep a person in the decision loop. That means anything that messages customers, moves money, deletes information or changes records permanently waits for approval by default.

Logging and an audit trail

Record what the system read, what it decided and what it changed. Logs let you trace a mistake, correct it and show what happened if someone asks.

Test with non-sensitive data first

Build and test using sample or anonymized records. Real personal information should enter the system only once it behaves as expected.

• –Passwords, API keys and security answers, in prompts or in documents the system can search.
• –Payment card numbers and full banking details.
• –Government identification numbers, such as a Social Insurance Number.
• –Health information and other highly sensitive personal details, unless the system has been specifically designed and reviewed for it.
• –Confidential material you are contractually obliged to protect, unless you have checked that the setup meets those obligations.

A simple rule helps staff: if you would not paste it into an email to an outside supplier, do not paste it into an AI tool either.

For example, an accounting firm wants AI to answer staff questions from its internal procedures manual. A careful version gives the system read access to the procedures folder only, not to client files. Questions and answers are logged, the model provider's settings are checked for training and retention, and the system is tested on the manual before going live.

If the firm later wants the system to draft client emails, that becomes a separate step with its own review: drafts go to an accountant, who checks and sends them. Nothing reaches a client without a person seeing it first.

Businesses in Canada have privacy obligations when they collect, use and share personal information, and some provinces and sectors add their own rules. Sending personal information to an AI provider, especially one that processes data outside Canada, can bring those obligations into play.

This page is not legal advice. Before personal information goes into any AI system, confirm your obligations with a privacy professional or legal adviser, and check whether your customers need to be told how their information is handled.

1. 01Which systems and data will this automation be able to access, and why does it need each one?
2. 02Which AI model provider will receive our data, under what terms, and in which region is it processed?
3. 03Can our data be used to train models, and what retention settings will be used?
4. 04Where will credentials be stored, and who can see them?
5. 05Which actions need a person's approval before they happen?
6. 06What is logged, where, and for how long?
7. 07How will you test before real customer data is involved?
8. 08If we stop working together, how do we revoke access and get our data back?

A good provider will answer these plainly and put the answers in writing. In our own AI integration work, ownership, hosting, data handling and ongoing maintenance are agreed before the build begins, so there is an agreed answer to each of these questions from the start. The same questions are useful alongside what to ask before hiring someone to build AI.