Know what the data is before AI touches it.
Access controls built on folders and databases break down when AI retrieves across all of them at once. Data.co labels sensitive data at ingest, carries those labels through chunks and embeddings, and lets policy act on the label wherever the data ends up.
A paragraph of PHI in a sales deck is still PHI.
Traditional controls assume sensitive data lives in known places: the EHR, the HR system, the finance share. In practice it leaks into email threads, spreadsheets, meeting notes, and exports. Retrieval-augmented AI finds all of it.
Data.co applies classification labels when data is ingested, using deterministic detectors, source-system metadata, and human-confirmed rules. Labels attach to documents, chunks, rows, and embeddings, so a retrieval policy that denies PHI to a marketing assistant works even when the PHI is sitting in a marketing folder.
Labels that policies can rely on.
Built-in classes
PHI, PII, financial, and privileged labels ship as starting points with documented detection rules.
Custom labels
Define classes such as export-controlled, trade secret, or board confidential, with your own rules.
Source-aware
Inherit labels from source systems where they exist, such as a matter's confidentiality flag.
Chunk-level
Labels apply at the chunk and field level, so one sensitive table does not lock an entire document.
Review queue
Uncertain detections go to a human reviewer instead of silently passing or blocking.
Versioned rules
Classification rules live in Git, so a change in labeling is visible and attributable.
What a label can trigger.
| Label | Typical policy effect |
|---|---|
| PHI | Retrieval limited to roles with a treatment, payment, or operations purpose; local models only |
| PII | Masked in results for analytics roles; full values for case owners |
| Financial | Denied to external endpoints; export requires approval |
| Privileged | Matter-scoped access; never leaves local models |
| Custom: export-controlled | Restricted to identities with the required attribute |
From unknown to governed.
- 1
Scan
Connect sources and run classification in report-only mode to see what is where.
- 2
Tune
Review findings, adjust rules, and confirm labels for ambiguous categories.
- 3
Enforce
Turn on policies that act on labels, starting with the highest-risk classes.
- 4
Monitor
Watch for new sensitive data arriving in unexpected places and review drift.
A customer export lands in the wrong share.
Someone in sales operations exports a customer list with tax identifiers to the team share so a colleague can reconcile it. The next incremental sync picks up the file. Deterministic detectors match the identifier pattern in two columns, and the rows are labeled PII at the field and chunk level. The rest of the share, which holds pitch decks and meeting notes, keeps its existing labels.
An hour later, a marketing assistant built on retrieval asks for recent customer context. The policy engine sees the PII label on the candidate chunks and the assistant's identity, which is not scoped for PII, and those chunks are excluded before ranking. The decision record lists the policy that excluded them. Meanwhile, the detection appears in the review queue with its source path, so the data owner can decide whether the file belongs there at all. The control worked without anyone noticing the file first, and the evidence shows exactly why.
Measures your team defines before enforcement.
Classification programs drift without targets. These are the questions teams usually answer in writing before turning policies on.
- Which classes are in scope for the first phase, and which are deferred
- Who confirms ambiguous detections, and how quickly the review queue is cleared
- What the default is for unclassified data: restricted or open
- Which sources are authoritative for labels, such as a matter or patient flag
- How false positives are reported and fed back into rules
- Which reports the privacy or compliance team needs, and how often
Questions buyers ask
Does an AI model classify our data?
Detection can use deterministic rules, source metadata, and optionally a local model to suggest labels. Suggestions below a confidence threshold go to human review. Enforcement uses the resulting label, never a model's judgment at request time.
Do labels follow data into embeddings?
Yes. Labels are stored with each chunk and its embedding, and retrieval filters on them before results reach a model.
Can we use our existing data catalog's tags?
Where your catalog or source system exposes tags, Data.co can import them as labels or as inputs to classification rules.
What happens to data that cannot be classified?
You choose the default. Many teams treat unclassified data as restricted until reviewed, which fails closed.
Is this the same as data loss prevention?
They work together. Classification decides what the data is; DLP-style policies decide what may happen to it, such as blocking a labeled class from reaching an external model endpoint or masking it in results.
Does labeling change the source system?
No. Labels are stored with Data.co's copy of the content, chunks, and embeddings. Source files and records are not modified.
See it against your own use case.
A 30-minute technical walkthrough, policy simulation on your scenarios, and a deployment recommendation for on-prem, private cloud, or hybrid.