AI data privacy and security for companies: a practical guide

Where does your data go when you use AI?

When you use an AI tool, the text, files and context you give it are sent to a model, often hosted by a vendor, and may be stored in logs. To protect company data, know what data goes where, limit who and what can access it, test for prompt injection, ask vendors clear questions and set retention rules.

Every AI system has a data path. A person types a request, or a connected tool passes one in. The request, along with any files or records attached, goes to a model that usually runs on a vendor's servers. The reply comes back, and parts of the exchange may be kept in logs, in a conversation history or in a search index that the system builds. If the system is connected to your email, documents or database, it can read from them too, and an agent can write to them. Each step is a place where data can leak, be kept longer than intended or be seen by someone who should not. Start by drawing the path for each AI tool in use: what goes in, where it is processed, what is stored and for how long, and who can see it. Include the tools that people adopted on their own as well as the ones you approved, because unofficial tools are often where the gaps are.

This is general guidance, not legal advice. Rules on personal and confidential data differ by country and by sector, and they change. Your legal or compliance adviser should confirm what applies to you, and in regulated work AI should support professional judgement, never replace it. What follows is the practical side that any company can act on.

Who should have access?

Give every AI tool and agent the least access it needs, and no more. A shared login or a copy of an employee's credentials is the common shortcut, and it is the wrong one: access is wider than the task, actions cannot be traced to a purpose and nobody notices when permissions outgrow the job. Instead, give each tool or agent its own identity, scope its permissions to the task and keep a record of what it does. Separate read access from write access, and require a person to approve actions that send data outside the company, spend money or change records that matter. Review access on a schedule and remove it when a tool or a person leaves. The aim is simple: if something goes wrong, the damage is limited and you can see exactly what happened.

Prompt injection is the attack that AI systems are most exposed to. Text inside an email, web page or document can contain hidden instructions, and a model that reads it may follow them as if you had written them. An agent with access to sensitive data and the ability to send messages is the risky combination. You cannot remove the risk entirely, so you reduce what is at stake: keep untrusted content apart from sensitive data, restrict what the agent can do after reading it, and keep a person in the loop for risky actions.

What should you ask an AI vendor?

Before you buy or connect an AI service, ask the vendor plain questions and expect plain answers. Where is our data processed and stored? Is it used to train models, and can we switch that off? Who at the vendor can see it? Which other companies process it on the vendor's behalf? How is it protected in transit and at rest? What happens to it when we leave? If the answers are vague, treat that as an answer. Ask for the terms in writing and have your legal adviser check them.

Keep less data, for less time. Decide what each AI system is allowed to store, how long it keeps prompts, files and conversation histories, and who can delete them. Do not send a model data it does not need: remove names, account numbers and other identifiers where the task does not require them. Set a retention period for logs and review it. Make sure you can find and delete a person's data if you are asked to, including copies held in search indexes or conversation histories. Write these rules down in a short policy so that the people who choose and use tools can follow it. A policy that fits on a page will be read, and a long one will not.

The right controls depend on how your company really works. During the Embedded Week we sit with your team for a week, watch where data moves between people and tools, and map where sensitive information is handled by hand, copied between systems or sent to unofficial tools. That map becomes the basis for the build plan, so access, approvals and retention are designed into the custom solution from the start. We then train your team to run it and to spot problems.

The checklist takes a few minutes to read. It turns the points above into questions you can check at your next review. To talk it through, or to see how an Embedded Week would map your own data flows, book a meeting.