Does data security only protect personal information?

No. Business plans, model assets, source code, and operational records may also need protection.

Is authorization the same as authentication?

No. Establishing who an actor is does not determine everything that actor may do.

Can a public dataset still need integrity protection?

Yes. Public readability does not mean anyone should be able to alter the authoritative version unnoticed.

AI Glossary / Governance, ethics and safety / Intermediate

Data security

Definition

Data security is the protection of data against unauthorized access, disclosure, alteration, destruction, and loss of availability. It combines technical safeguards, operating practices, and clear responsibilities. In an AI system, it applies to training datasets, prompts, retrieved records, model-related assets, outputs, and logs, as well as the systems that store and process them.

What it means

Three common security goals are confidentiality, integrity, and availability. Confidentiality concerns who can see or use information. Integrity concerns protection against improper changes or destruction. Availability concerns whether authorized users can obtain the information and services they need. These goals overlap but are not interchangeable. A dataset can remain secret while being corrupted, or remain accurate while being inaccessible. Security design should therefore identify the ways data could be harmed and the operational consequences of each, instead of relying on one safeguard such as encryption.

How it works

Start by identifying important data assets, their locations, and the people or services that can access them. Classify their sensitivity and operational importance, then apply controls suited to the risks. Authentication checks an identity, while authorization determines permitted actions. Encryption can protect information in storage or transit, but keys and endpoints also need protection. Versioning and integrity checks help detect changes, and tested backups support recovery. Monitoring and incident procedures help respond when prevention fails. In AI workflows, access boundaries must continue through retrieval and generated outputs; permission to use an assistant should not automatically grant access to every connected document.

Three practical examples

A training-data pipeline restricts who can modify reviewed labels and records which dataset version produced each model.
A document assistant retrieves only material the requesting employee is authorized to access, including when results are summarized rather than displayed verbatim.
An analytics service tests restoration from backups so that a storage failure does not permanently interrupt a critical workflow. These examples protect different goals and require complementary controls.

Think of it this way

Think of a records room with controlled entry, a process for approving changes, and a duplicate archive available after damage. The lock supports confidentiality, the change process supports integrity, and the archive supports recovery and availability. The analogy has limits: digital information can be copied or modified quickly, and access can occur through service accounts, software integrations, and generated outputs rather than a physical door. Security must follow those routes as well.

Worked example

Suppose an AI reporting system backs up its data once each day at midnight. A failure occurs at 18:00, and the latest backup is intact. Without another recovery mechanism, up to eighteen hours of subsequent changes may be unavailable for restoration. If restoring service takes three hours, users may also face a three-hour interruption. These are different consequences: potential data loss and service downtime. A requirement to lose no more than one hour of changes cannot be satisfied merely by making the daily restore faster. The team needs an appropriate update-preservation method as well as a recovery process, and must test both. This example assumes a successful backup and restore; actual recovery depends on backup completeness, integrity, access, and the surrounding system.

Illustrative case study

Fictional case: Beech Reports introduces an assistant connected to internal project documents. The application enforces document permissions during ordinary browsing, but an early assistant prototype uses a shared retrieval account with broader access. The team identifies the mismatch in testing and changes retrieval to enforce the requesting user's permissions. It also checks cached answers and logs for the same boundary. The case illustrates why security must be evaluated across the complete information path, rather than inherited by assumption from one interface.

Common misconceptions and mistakes

Encryption alone does not prevent an authorized but overprivileged account from retrieving data. A backup that has never been restored is not proof of recoverability. Integrity checks also have limits: a matching hash proves consistency with a reference value, not that the original content was accurate or legitimate. Another mistake is treating internal networks or employees as automatically trustworthy for every dataset. Permissions should match the required task, and changes in roles or integrations should trigger review. Finally, data security and data privacy overlap, but a secure system can still process personal information for inappropriate purposes.

Business use

Assign owners for important data and define acceptable access, change, and recovery behavior. Review service accounts, integrations, and administrative privileges alongside ordinary user permissions. Keep inventories and recovery plans current as the AI workflow changes. Test whether outputs and logs disclose information beyond their intended audience, and whether altered source data can be traced to a responsible process. Use a risk framework to organize priorities and evidence, but avoid treating a checklist as proof that every threat has been eliminated. Security is an ongoing operating responsibility, not a one-time product feature.

Check your understanding

A database is encrypted, but a shared service account can read every customer's records and the assistant uses that account for all users. Is confidentiality automatically protected?

Answer: No. The retrieval and output path still needs appropriate authorization. Encryption does not correct excessive access privileges.

Related terms

Learn next

Follow one dataset from collection through an AI-generated answer. At each step, record who can read it, who can change it, how changes are detected, and how it can be restored. Test one realistic failure and one unauthorized-access scenario within an approved environment.

Sources

NIST CSRC, Information security glossary: https://csrc.nist.gov/glossary/term/information_security NIST, The Cybersecurity Framework 2.0: https://doi.org/10.6028/NIST.CSWP.29 DAMA UK, Glossary of Data Management Terms: https://www.dama-uk.org/pages/glossary

Previous: Data redundancy Next: Data storage