Is integrity the same as accuracy?

No. Accuracy concerns correctness; integrity concerns protection from improper alteration or destruction. Incorrect information can retain integrity.

Does encryption guarantee integrity?

Not in every form. Confidentiality protection alone should not be assumed to detect unauthorized modification; the actual mechanism and configuration matter.

Can an authorized update create problems?

Yes. Approval can establish permission without proving quality. Changes still need appropriate validation and evaluation.

AI Glossary / Governance, ethics and safety / Beginner

Integrity

Definition

Integrity is the information-security property of protecting information and systems against improper modification or destruction. For AI, it means maintaining trustworthy control over changes to data, models, instructions, and records. A system with integrity preserves authorized content and changes it through legitimate processes; this does not automatically make that content accurate or fair.

What it means

An AI service depends on many things remaining as intended: training examples, model files, access rules, retrieved documents, evaluation results, and audit records. If someone silently changes one of these, the service may produce different behavior even though its interface looks normal.

Integrity asks whether those assets have been altered improperly, not simply whether the service is running. Accidental corruption, unauthorized editing, and deliberate manipulation can all matter.

This is the information-security meaning of the term. Personal or organisational integrity refers to ethical consistency and honesty, which is related to responsible conduct but is a different concept. Information can be securely preserved and still contain a mistaken claim, an outdated assumption, or an unfair label.

How it works

Integrity protection begins by identifying which assets matter and who is authorized to change them. Teams then control changes, retain versions, validate inputs, and keep evidence of important actions. They also need ways to detect unexpected differences and recover a trusted version.

A cryptographic hash produces a fixed-length value from content. Comparing a file's hash with a trusted reference can help detect whether the content differs. The reference itself must be protected: replacing both a file and an unprotected reference can defeat the intended check.

Approvals, access controls, signed artifacts, and audit records address different parts of the problem. None should be treated as a universal guarantee. A permitted user may introduce an erroneous update, while a checksum may identify a change without explaining whether it was legitimate. Operational procedures must connect detected changes to their authorization and purpose.

Three practical examples

1. A model release process checks that the file being deployed matches the artifact approved during evaluation, reducing the chance that a different file enters production unnoticed.

2. A business protects the source documents used by its AI assistant so that unauthorized edits cannot quietly change the answers staff receive.

3. A team preserves incident records with controlled access and version history, helping investigators distinguish the original evidence from later annotations or corrections.

Think of it this way

Think of a sealed parcel with a recorded contents list. If the seal is broken or the contents change, the recipient has a reason to investigate what happened before relying on the delivery.

The analogy has limits. A seal does not prove that the original contents were correct, safe, or useful. Digital systems also permit legitimate updates, so integrity involves controlled change rather than keeping everything permanently frozen. A convincing-looking seal is valuable only when its origin and protection can be trusted.

Worked example

A fictional team approves version 7 of a model configuration. Its release record contains a trusted reference hash for that exact file. During deployment, the computed hash differs from the reference.

The difference establishes that the deployed file's contents do not match the approved file under the intended check. It does not establish who changed it, why it changed, or whether the new content would produce worse results.

The team pauses that release and compares the versions. It finds an unreviewed instruction added after approval. The appropriate next step is to restore the approved artifact or review and approve a new version through the change process.

If the hashes had matched, that would support content consistency with the trusted reference. It would not prove the instructions were factually correct, suitable for every user, or resistant to every possible attack.

Illustrative case study

Fictional case: Harbour Supplies uses an AI assistant to explain its internal purchasing procedures. A routine review finds that a shared source document has acquired an incorrect approval threshold. The assistant faithfully repeats the changed value.

The team investigates the document history, corrects the source through an authorized review, and checks which answers may have relied on it. It also separates editing permission from ordinary reading access and introduces approval for changes to critical instructions.

The case illustrates an integrity failure in a dependency rather than proof of a defective language model. It is an invented teaching example, with no claimed company results. Improving source control still leaves a separate responsibility to test whether the assistant interprets the authorized text correctly.

Common misconceptions and mistakes

Integrity does not mean that data can never change; authorized, traceable corrections are often necessary. A hash comparison does not by itself authenticate the person who created a file or establish the truth of its contents.

Availability and integrity are also different. A service may be reachable while serving altered information. Conversely, taking a service offline to investigate suspicious changes can temporarily reduce availability while helping protect integrity. Controls should reflect the consequences of the particular change.

Business use

Businesses should identify the AI assets whose improper alteration could affect customers, operations, or accountability. Useful priorities include deployment artifacts, decision rules, trusted knowledge sources, and evidence needed to investigate incidents.

Define ownership, change permissions, approval requirements, and recovery procedures. Monitor unexpected modifications and test whether the organization can reconstruct what changed. The practical objective is confidence in controlled information and system behavior, not merely a dashboard showing that files have checksums.

Check your understanding

A model file matches its protected approved reference, but the model performs poorly on a new population. Has the comparison proved model quality?

Answer: No. It supports consistency with the approved artifact. Performance on that population requires separate evaluation; integrity and fitness for use answer different questions.

Related terms

Information security
Availability
Access Control
Model validation
confidentiality
authentication
cryptographic hash
data provenance
change management

Learn next

Next, distinguish integrity checks from authentication and provenance. Trace one AI release from approved source material to deployment, identifying where content could change and what evidence would reveal an unauthorized modification.

Sources

NIST Computer Security Resource Center, Integrity: https://csrc.nist.gov/glossary/term/integrity NIST Computer Security Resource Center, Cryptographic Hash Function: https://csrc.nist.gov/glossary/term/cryptographic_hash_function These primary definitions ground the information-security scope and hash explanation. The scenarios and worked example are original teaching material.

Previous: Integrated test facility Next: Integrity Constraint