AI Security and Data Privacy

An AI ban is announced at the company; the result: employees use it in secret, from personal accounts, and no one knows what is being typed where. The ban created not security but shadow IT. AI privacy's first lesson is exactly that: managed use is safer than a ban.

The AI security topic has two layers: the individual user's prompt discipline and the company's system rules. This article turns both layers into a practical protocol: what must not be typed, where the settings are, how the team rule gets built.

The risk map: what can happen?

Prompt discipline: the red list

The simplest and most-violated rule: think of the prompt as text written in a public place. The red list (under no circumstances, into no tool): passwords, API keys, card numbers; personal identification documents; customers' personal data (name+phone+address combinations); undisclosed financial figures and commercial secrets; documents under NDA. The grey zone (depending on the tool/plan policy): internal documents, code fragments, strategy texts; for these the decision belongs to the company policy. The green working method, meanwhile, is anonymisation: keep the structure, remove the identifier; with "Customer A, amount X" the AI helps at the same quality.

The tool settings: 15 minutes of hygiene

• Training use: check/switch off the "improve the model"-type settings in the main assistants (ChatGPT Data Controls, the analogues elsewhere).
• History management: the temporary modes for sensitive conversations; a periodic cleanup of old chats.
• 2FA on every AI account: your chat archive is already a database; it must be protected accordingly.
• The business plans' difference: on team/enterprise plans the "data does not go into training" commitments are standard; for serious work, a business account, not a personal one (the plan differences).
• The integration audit: a quarterly look at the connected apps' permission list; cut what is unused.

The team rule: a one-page protocol

Before the big policy document (that is a separate article's topic), a one-page working rule suffices for many companies: the permitted tools list (and with which account type), the red list (the one above, adapted to the company), the anonymisation rule, the output check rule (which results pass through whose approval) and the incident procedure (I leaked by mistake; whom do I tell? a fix-it culture, not a punishment one; otherwise no one will tell). That page + a half-hour team conversation is the measure that most reduces the "secret use" risk.

Output security: the forgotten half

The privacy conversation focuses on the input; the risk exists at the output too: a security hole in AI-written code, a wrong clause in a legal text, a mistaken permission in a configuration. The rule is simple and familiar from the risk article: as the impact grows, the human check hardens. For code: tests + review; for legal/finance: specialist approval; for everything going to a customer: editing. "The AI said so" is a signature on no document.

Sources and further reading

Where to verify the source

The tool policies are changeable; the primary sources:

• OpenAI — the Data Controls FAQ
• NIST AI RMF: the risk management framework

Continuing the topic

The security line's neighbouring articles:

• The AI policy in a company
• Protecting personal data
• Cybersecurity basics
• Two-factor authentication
• Other articles on this topic

This week's 15 minutes: open your main AI tool's data settings and share the red list with your team. Security is not a big project; it is the sum of small habits.