How do you keep AI secure and compliant without a security team?

Most companies of a few hundred people don't have a head of security. They have an IT manager, perhaps two, who look after laptops, accounts, the network and whatever broke this morning. So when the board asks about AI risk, or a large customer sends a security questionnaire with a section on AI, the answer tends to be a worried silence or a ban that staff ignore.

Meanwhile people are already pasting customer emails, contract clauses and payroll figures into public AI tools, because it saves them time. Keeping AI secure at this size comes down to a few decisions you write down and a routine someone owns. This guide sets them out in the order you'd make them.

Start with what the system can see

Every AI system reads something: an inbox, a folder of contracts, records in your CRM or ERP. The first decision is which of those it needs for its job, and the answer should be as narrow as the job allows. A system that drafts replies to order queries needs the order records and the approved answers. It has no reason to see payroll, HR files or the board pack, so it shouldn't be connected to them.

Write the list down for each system: which sources it reads, which it can write to and which fields it uses. Reading and writing are separate decisions. A system that reads invoices and proposes a match carries less risk than one that can post entries to the ledger, so many teams start with read access and a person who approves before anything is written.

Know where it runs and where the data goes

The second question is where the processing happens and what happens to the data afterwards. Ask whoever provides the system, and get the answers in writing:

• Which country or region the data is processed and stored in.
• Whether the data you send is used to train any model that other customers use. For business data the answer should be no, and the contract should say so.
• How long inputs and outputs are kept, and how you'd have them deleted.
• Which other companies handle the data along the way, such as the hosting provider and the model provider.

These answers matter for the data protection rules that apply to you, and they're the same questions your customers will ask you. If a provider can't answer them plainly, don't send them your data.

Give access by role

Use the roles you already have. If your CRM lets sales managers see every account and account managers see only their own, the AI system should follow the same rules when it searches or summarises. The simplest way to get this right is for the system to act with the permissions of the person using it, so it can't show anyone a record they couldn't open themselves.

Apply the same test to assistants that answer questions from your documents. An assistant that indexes the whole shared drive will quote the salary review spreadsheet to anyone who asks the right question. Point it at the folders each role needs, then ask it a few questions it should refuse and check that it does.

Log every action and read a sample

A log is a record of what the system did: what came in, what it read, what it produced, who approved it and when. It lets you answer "what happened with this customer's request?" a month later, and it's one of the first things a customer's security team will ask about.

A log only helps if someone reads it. Name one person per system, usually the manager of the team that uses it, and give them a short weekly job: read a sample of ten or twenty actions and look for anything the system shouldn't have read, said or done. Problems that would take months to surface on their own show up in the first few weeks.

Take a hypothetical distributor with 300 staff and an IT team of two. They run one AI system that reads orders from the sales inbox and creates draft orders in the ERP. Their written record fits on a page: it reads the sales inbox and the customer and product tables, it writes draft orders only, a sales coordinator approves each one, the data is processed in their region and isn't used for training, and the operations manager samples twenty orders every Friday. When a customer's questionnaire asks how they use AI, that page is most of the answer.

Write a policy for staff use of AI tools

Banning public AI tools rarely works, because they're useful and people can reach them from their phones. A short written policy works better. One page is enough if it answers four questions:

• Which tools are approved: list the ones the company pays for and has checked, and say that anything else needs IT's agreement first.
• What can't go in: customer personal data, employee records, unpublished financial results, passwords and anything a contract says is confidential.
• What needs checking: anything an AI tool produces that goes to a customer, into a contract or into the accounts is checked by the person who sends it.
• Who to ask: one named person for questions, and an easy way to report a mistake without getting into trouble.

Give staff an approved option that's as easy to use as the public one, or they'll keep using the public one. Send the policy round, talk it through at a team meeting and ask managers to repeat the main points. Review it every six months, because the tools change faster than most policies do.

How to answer a customer's security questionnaire

Questionnaires now often include a section on AI. The wording varies, but the questions are mostly the same: do you use AI on our data, what data does it see, where is it processed, is it used for training, who can access it, what's logged, who reviews it and what you'd do if something went wrong.

If you keep a one-page record for each system, you can answer most of this from it. Keep a master copy of your answers, reuse it for every questionnaire and update it whenever a system changes. Say plainly where a person checks the output. A named reviewer and a sampled log reassure a customer's security team more than a list of features does.

What to ask a partner who builds it for you

If someone else builds or runs the system, their answers become your answers, so ask before you sign:

• Where will our data be processed and stored, and by whom?
• Will our data be used to train anything, and where does the contract say so?
• Does the system act with each user's permissions, or through one account that can see everything?
• What's logged, how long is it kept, and can we read it ourselves?
• What happens to our data, and to the system, if we stop working together?

There are more questions worth asking about cost, ownership and support in questions to ask an AI partner. On security, the test is whether you get answers plain enough to paste into a customer's questionnaire.

What to do this week

1. List every AI tool and system in use, including the ones staff pay for themselves. Asking each team lead is quicker than an audit.
2. For each one, write down what data it can see, where it runs and who owns it.
3. Draft a one-page policy for staff use of AI tools and send it to the leadership team for comment.
4. Pick one system and set up its weekly log review with a named person.
5. Start a master copy of your questionnaire answers from the records you've just written.

Access by role, logging and the review routine are part of deploying a system properly, and they're far easier to set up on the day it goes live than to add a year later.

Get the next article when it's published.