Is drawing a box enough?

Not if the underlying information remains in the released file.

Is redaction the same as anonymization?

No. Removing selected details may still leave identifying context.

Does checking six known items prove the whole document safe?

It proves only the stated check, not that no other sensitive information exists.

AI Glossary / Data governance and quality / Advanced

Redaction

Definition

Redaction is the removal or effective withholding of selected information from a version of a document or other content prepared for disclosure. In data governance, its purpose is to release permitted material while excluding information that should not be disclosed. For an electronic file, merely placing a visible shape over text may leave the underlying content recoverable. Successful redaction concerns the released information, not just its appearance.

What it means

A redacted copy can preserve useful context without revealing every detail in the original. The decision about what may be disclosed and the technical operation that removes it are separate responsibilities. Someone must identify the information to withhold, and the released copy must actually implement that decision.
The National Archives' toolkit describes redaction in a public-records context and emphasizes working on a copy while retaining the original. That context should not be mistaken for universal legal advice. For a website project, the applicable release decision may instead arise from an agreed publication policy, consent boundary or confidentiality requirement.

How it works

A typical workflow identifies the intended audience and the information to exclude, marks the relevant content, applies removal and checks the output. In Adobe's documented PDF workflow, marking content and applying redactions are distinct steps. Its sanitization process also addresses hidden information such as comments and metadata.
Verification must consider more than the visible page. Sensitive details can recur elsewhere or be revealed by surrounding context. The reviewer needs to inspect the actual release version, including relevant embedded or hidden content, rather than assuming a marked working file is finished. The original and release copy also need clear identities so that the wrong version is not distributed.

Three practical examples

Training case: A fictional AI course uses a support conversation to illustrate a service problem. The editor removes a customer's identifying details from the release copy while retaining the technical issue needed for teaching. The editor also reviews contextual clues that might identify the person despite removal of their name.
Project report: A business shares a report containing internal comments. Removing confidential text from the visible body is insufficient if a comment repeats it. The release review includes the information carried by the file, not only the paragraphs shown in a normal reading view.
Screenshot: A tutorial image includes an account identifier. The publishing team prepares a sanitized illustration and checks every occurrence of the identifier. It avoids assuming that covering one visible location resolves the entire release question, especially if another image or caption repeats the same detail.

Think of it this way

Think of preparing a public edition of a notebook while keeping the complete notebook in controlled storage. The public edition must omit the restricted passages, and its index or annotations must not reproduce them. Placing a removable sticky note over a passage in the original is different: the words remain underneath. The analogy distinguishes concealment from preparing a release copy.

Worked example

Consider a fictional document with six items that a reviewer has explicitly decided must be withheld. Four appear in visible text, one in a comment and one in document metadata.
An initial pass removes the four visible items but overlooks the comment and metadata. Against the six-item reference list, coverage is 4 / 6, approximately 66.7%, and two restricted items remain. A visually clean page therefore does not establish that the file meets the release decision.
A second pass removes the remaining two items and verifies their absence in the resulting release copy. Coverage against the known list becomes 6 / 6 = 100%. This is not proof that every possible sensitive detail has been found: the reference list itself may be incomplete, and contextual information might still reveal something the reviewer intended to withhold.
The team records both conclusions precisely: all six specified items passed the removal check, and a separate content review is still needed for omissions and inference risks.

Illustrative case study

A fictional AI publishing team prepares an article about a customer-service workflow. Its first draft contains a sample exchange, reviewer comments and an appendix. An editor removes a customer identifier from the main text and considers the article ready.
A second reviewer checks the complete release package and finds that the appendix repeats the identifier. A comment also describes the customer in a way that could undermine the intended confidentiality. The team revisits the release decision and prepares a new copy that reflects the agreed scope throughout the package.
Before distribution, another reviewer checks the exact output file rather than the earlier working document. The team retains a record of what was approved for release and which version was checked. This invented case connects content judgment, technical removal and version control.

Common misconceptions and mistakes

A black rectangle does not necessarily remove underlying text. Marking proposed redactions may not apply them. Deleting a name does not automatically anonymize a document, because other details can identify the person. Conversely, redaction need not mean deleting the original record: the release copy and retained source serve different purposes. Another mistake is treating a successful check against a known list as proof that the list captured every disclosure risk. Technical completion and completeness of the review are different questions.

Business use

For an AI website, define a release process that identifies the audience, the content to withhold and the reviewer responsible for the decision. Keep the checked release version distinct from working files. Where automation suggests sensitive passages, review its output and omissions rather than treating its confidence score as publication approval. A useful record states which version was checked and what the check covered, without unnecessarily reproducing the very details being withheld.

Check your understanding

How many restricted items survived the first pass?

Answer: Two.

What was known-item coverage?

Answer: About 66.7%.

Why is the final 100% limited?

Answer: It refers only to six specified items.

Which file needs release verification?

Answer: The exact version intended for distribution, not an earlier working copy.

Related terms

Data masking
Anonymization
Metadata
Access Control
document sanitization
disclosure review

Learn next

Create a harmless sample with repeated fictional identifiers in body text, a comment and metadata. Define the intended release, then distinguish removal checks from a broader review of what the remaining context reveals.

Metadata

Sources

The National Archives, Redaction Toolkit, historical records-management guidance: https://cdn.nationalarchives.gov.uk/documents/information-management/redaction_toolkit.pdf Adobe, Remove sensitive information: https://experienceleague.adobe.com/en/docs/document-cloud-learn/acrobat-learning/advanced-tasks/protect/redact The six-item calculation and publishing case are original illustrations. No jurisdiction-specific entitlement to withhold information is asserted.

Previous: Red teaming Next: Reduce (pyramid operator)