AI security and privacy start with four questions: what information enters the tool, who can see it, what actions can the tool take, and who checks the result?
For a small team, these questions belong in everyday work. A writing assistant that reads public research has different needs from an agent connected to client records or an email account. Adding an AI subscription does not settle those differences.
This guide draws on primary guidance and proposes a practical editorial workflow. The examples are hypothetical, and the suggested checks should be adapted to your data, permissions and responsibilities.
Key takeaways
- Describe the task and the information it needs before choosing an AI tool.
- Check training, retention, human access, subprocessors and deletion separately.
- Keep authorisation and tool permissions in application code.
- Treat retrieved instructions as untrusted source content.
- Review the actual release and plan how to respond if something goes wrong.
Understanding AI security and privacy in business workflows
NIST describes security through confidentiality, integrity and availability, and distinguishes resilience as recovery after adverse events. Its privacy discussion includes human autonomy, identity and dignity. (NIST)
In practical terms, security asks whether someone can access your account, change a draft or misuse a connected tool. Privacy asks whether the personal information used for the task is necessary and handled appropriately. Confidential business information also needs protection, even where it is not personal data.
Consider a hypothetical customer interview. Restricting access to the recording is a security measure. Deciding whether a model needs the interviewee's name is a data-handling decision. Both matter, but one does not answer the other. Start by describing the task and the information it actually needs.
Data minimisation and vetting model provider contracts
ICO guidance advises identifying the minimum personal data necessary for the purpose. It also explains that pseudonymised information remains personal data. Removing names does not establish anonymity if remaining details can identify someone. The guidance is under review following the Data (Use and Access) Act. (ICO)
My suggested supplier review separates five questions. Record answers for the exact product, account and agreement you plan to use; a subscription label is not an answer.
| Area | What to record |
|---|---|
| Training | Whether inputs or outputs may be used for training, and which controls apply. |
| Retention | What is stored, for how long, and any stated exceptions. |
| Human access | Who may inspect content and for what purpose. |
| Subprocessors | Which other organisations process the data and where. |
| Deletion | Available deletion mechanisms, their scope and limitations. |
Keep the relevant terms and review date with your tool record. If the answer is unclear, pause use of that data. ICO recommends choosing another solution as good practice where an organisation cannot assess a third-party system's data-protection compliance. (ICO)
Securing infrastructure with least privilege and safe tool access
OWASP recommends limiting tools, functions and downstream permissions to those needed for the task. Its implementation guidance places authorisation outside the language model and calls for validation of tool calls and parameters. (OWASP; OWASP)
For a hypothetical research assistant, I would begin with permission to read a designated source folder and create a separate draft. Publishing, sending messages and changing the source files would be separate operations with their own checks.
Keep provider credentials out of model context, browser-delivered code and article exports. Configure access in the application and its trusted environment. An environment variable is a storage mechanism, not a complete security control.
Before connecting a tool, write down its permitted action, resource and destination. Check these limits in code when an action is requested. A model's statement that an action is authorised should not grant permission.
Defending workflows against prompt injection and untrusted inputs
OWASP distinguishes direct injection through user input from indirect injection through external material. It notes that foolproof prevention remains uncertain and that retrieval-augmented generation or fine-tuning does not fully address the problem. Its suggested mitigations include limited permissions, output validation, separation of external content and approval for high-risk actions. (OWASP)
Imagine a research page that tells an assistant to send an unpublished draft to an outside address. That sentence is part of the source being read; it is not permission from the editor. In my suggested workflow, retrieved material may support a factual claim but cannot authorise publishing or disclosure.
Test that boundary with an invented document before using real confidential material. Check both the model's response and the application's actual actions. An allowlist, a sandbox or a defensive prompt can be useful, but none justifies a blanket claim that leakage is impossible. Limit the consequences if an instruction is followed unexpectedly.
Human approval output checks and incident response
For this editorial workflow, I recommend reviewing the copy, sources, permissions and image before publication. The review should check what will actually be released, including links and metadata. Our guide to fact-check AI-generated content provides a source-review process.
My suggested activity record includes the action, time, destination and reviewer. Decide what logging is necessary before collecting it; copying whole prompts into a log can create another store of sensitive information. Set access and retention rules for that record too.
The NCSC-led secure-development guidelines address providers, including systems using external APIs. They recommend incident-response, escalation and remediation plans, reviewed as systems evolve. The following is my small-team adaptation. (NCSC and partner agencies)
- Pause: stop the affected workflow while assessing the issue.
- Assess: identify what was sent, which account was used and who may have access.
- Contain: choose measures appropriate to the exposure; replace credentials if compromised.
- Contact: check provider options without assuming deletion is available or complete.
- Escalate: involve the responsible person to assess obligations and next steps.
- Learn: correct the workflow and verify the change before resuming.
A practical editorial workflow and implementation checklist
Here is a hypothetical example: an editor wants help structuring an unpublished interview into a blog article.
- Prepare a permitted excerpt. Remove information the model does not need. Check remaining details rather than assuming placeholders make the excerpt anonymous.
- Choose the approved tool. Verify that its current terms and settings suit the remaining information. If they do not, change the task or use another method.
- Create a draft. Give the assistant only the access needed for drafting; keep publication separate.
- Review the release. Check evidence, personal details, quotations, images and destinations before approving the final version.
Record one owner for these decisions and recheck when the tool, data or permissions change. To connect those operating checks with broader ownership and review rules, read the companion guide to AI governance for small teams.
Frequently asked questions
What is the difference between AI security and privacy?
Security concerns access, tampering and disruption; privacy concerns how information about people is used and disclosed. For a small team, I suggest checking both at the start of each task. Ask whether the tool can access only the intended files, and separately whether those files contain information it needs. A restricted account does not make unnecessary personal data appropriate to submit.
Can redaction make an AI prompt safe to share?
Redaction can reduce what you disclose, but removing a name does not establish that the remaining text is anonymous or suitable for the chosen service. My suggested review looks at distinctive events, job titles, dates and combinations of details, as well as direct identifiers. If the remaining information is still sensitive, use a tool and agreement appropriate to that information or change the task.
What should a small team check before connecting an AI tool?
My starting checklist is the task, permitted information, exact provider terms, available tool actions and final reviewer. Record what the assistant can read, create, change or send, and which destinations are allowed. Test those boundaries with hypothetical material before connecting real records. Keep a responsible contact for questions and incidents, and repeat the review when the product, data or permissions change.