1.4 Data Security

The most important data-security question of the AI era is not whether a system can be hacked — it is what happens to the data users voluntarily type into it. This chapter delivers the decision rules for which data may go into which AI system.

Historical context: data security before AI

Classical IT security protects deterministic systems: a database releases data only to authorized users, a firewall blocks defined access, and since 2018 the GDPR has regulated who may process personal data for which purpose. The threat model, at its core: unauthorized parties want data that sits in clearly bounded systems.

Probabilistic systems shift this model in two places. First, data no longer flows only into storage but potentially into training processes — and what a model has once learned cannot be selectively deleted. Second, an LLM can be manipulated through its input: an attacker needs no security hole in the code, only cleverly written text. Both shifts follow directly from the deterministic/probabilistic distinction of Chapter 1.1.

The risk landscape: what actually happens to your input

Three stations matter. Transmission and processing: with cloud services, your input leaves your device and is processed on the provider's servers — for US providers regularly outside the EU, which raises GDPR questions. Storage and logging: providers typically retain conversations for operations, abuse detection, and support; retention periods are stated in the privacy policies and differ substantially. Training: depending on provider and account settings, inputs may be used to train future models. This is where the longest-lived risk sits: the Samsung case of 2023 — employees had pasted internal source code into ChatGPT, after which the company banned internal use — became the standard example of how trade secrets leak through AI inputs.

OWASP: a living reference

Instead of memorizing individual risks, reach for a maintained framework: the OWASP Top 10 for LLM Applications(2025 edition) lists the ten most important risk classes for LLM applications — among them prompt injection(manipulated inputs that override system instructions), sensitive information disclosure (leakage of confidential data in the output), and supply-chain risks in embedded models and components. The list's value lies less in its current content than in its function: it is continuously updated and therefore serves as a permanent reference point for classifying new developments — the same role the classic OWASP Top 10 has played for web security for years.

The regulatory frame: the AI Act from a data perspective

The EU AI Act from Chapter 1.1 returns here with concrete relevance. For high-risk systems — in finance, most prominently creditworthiness assessment — the regulation prescribes requirements for data governance, documentation, and human oversight. More important for most users' daily work: the regulation does not replace the GDPR, it complements it. Anyone entering personal data into an AI system remains fully inside the GDPR regime — legal basis, purpose limitation, and data-processing agreements included. The detailed treatment of the AI Act follows in Chapter 1.5.

Decision rules for practice

For everyday use, three data classes with one rule each are enough:

• Your own, non-critical data (lecture notes, public information, your own drafts without personal references): unproblematic for any reputable AI tool.
• Personal data of third parties (names, contact details, application documents, customer data): as a rule, not into consumer AI tools. If processing is necessary: anonymize or pseudonymize before the text enters the prompt — or use an enterprise solution with a data-processing agreement.
• Company and client data (employer internals, pre-publication figures, contract contents): only through systems approved by the company, never through private accounts. In doubt, the internal AI policy governs — and where none exists, the conservative reading does.

Controlling your own data: disabling training use

Reputable providers offer settings to control whether your conversations are used for model training. In Claude, the option sits in the privacy settings of your account; Anthropic maintains the current documentation of settings and retention periods in its support documentation (support.claude.com). The course shows the path in the video — with the advice to repeat the same check for every other tool you use for study or work.

[VIDEO: Walkthrough — checking and disabling training-data use in the Claude settings, 2–3 minutes.]

[CONCLUSION] Data security in the AI era is first a matter of input discipline, not firewalls. Whoever internalizes the three data classes and the litmus test has already neutralized the biggest everyday risk — and, along the way, fulfilled a core component of what Article 4 of the AI Act means by AI competence.