Before an incident record is cleared for an AI workflow, an operations team will often start with a PII scan. The result can look reassuring: names, email addresses, and payment details are found. Yet the same record may contain the circuit ID that identifies the affected service, the asset tag that links several alarms, or the change reference that explains why the event matters. Those values need an explicit decision before the record reaches a model.
This is where operational marker detection begins. It is not an assertion that PII tools cannot detect non-PII values. Many tools support custom recognizers, patterns, dictionaries, rules, or labels. The architecture question is whether the configuration in use covers the markers a specific workflow must protect while preserving the relationships the task needs.
Key takeaways
- Treat default PII coverage and organization-defined operational-marker coverage as separate checks.
- Build a versioned marker inventory from representative records, with expected matches and expected non-matches.
- Test repeated references, near matches, collisions, and false negatives before approving the model request.
- Detection is only the first boundary: separately verify the protected working version, approved model path, Reconstruction, and destination.
Why a clean PII scan is not a coverage decision
Most detection services begin with a catalogue of common entity types. That is useful, but it is not a substitute for an organization’s policy definition. Presidio documents predefined recognizers and custom recognizers. Google Sensitive Data Protection similarly documents built-in detectors and custom infoTypes that can use dictionaries, regular expressions, inspection rules, or metadata labels. Those features make a coverage review possible; they do not make the review automatic.
Consider a network incident package. A detector may correctly find an engineer’s email address while ignoring a locally meaningful circuit identifier. Neither result is inherently wrong. The first outcome reflects a built-in entity class; the second depends on whether the implementation team has defined, configured, and tested that identifier. The answer will vary by data source, country, business unit, and task.
This distinction applies beyond networks. A maintenance platform can use asset tags and vendor codes. A claims workflow can use internal case references and approval codes. A contract process can use matter identifiers that are not personal data but are restricted by policy. These are examples, not a universal classification. The team must decide what counts for its workflow, then retain evidence for that decision.
For the broader context, see the LLM Capsule glossary definition of operational data: the records, logs, configurations, alarms, tickets, runbooks, workflows, and contextual references that operations teams use. The important design point is not the label. It is whether a value can reveal a restricted relationship or is needed to connect one record, event, or result to another.
Start with a marker inventory, not a detector setting
A useful inventory begins with a representative source record and a real AI task. Do not start by exporting every candidate field or by accepting the detector’s default entity list as the policy.
For each operational marker, record:
- its name and data source;
- a safe representative example or test fixture;
- where it appears: structured field, free text, attachment, table, metadata, filename, or a linked record;
- why it matters to the policy or the task;
- whether repeated appearances must stay consistent and whether distinct markers must remain distinct;
- whether it may enter the approved model path as part of a protected working version; and
- the policy owner, detector configuration version, and review date.
The relationship questions matter. A circuit identifier repeated in a ticket, an alarm, and a change record may need a consistent protected representation for root-cause analysis. Two similar-looking IDs may need to remain distinct. An internal code in a filename may be subject to the same policy as the value inside the record. A field-only test will not answer these questions.
The inventory makes responsibilities explicit. The data owner defines what must be covered and why. The implementation team maps that specification to the detector, threshold, rule, dictionary, or pattern the chosen tool actually supports. Neither side should silently substitute one responsibility for the other.
Turn the inventory into a coverage test
The next step is a small, versioned test corpus. It should be representative enough to expose the shape of the live workflow, but it does not need to contain unnecessary original data. Use approved test records or carefully controlled fixtures, and keep their source and handling rules clear.
For every marker, define the expected result before running the detector:
| Test dimension | What to specify | Evidence to retain |
|---|---|---|
| Positive case | The marker and the expected finding or policy action | Test fixture ID, configuration version, result |
| Near match | A similar value that must not be treated as the marker | Expected non-match and result |
| Repeated reference | The same marker in more than one location | Consistency expectation and result |
| Collision | Two distinct values that resemble each other | Distinctness expectation and result |
| Context rule | The adjacent terms, field name, or metadata that changes interpretation | Rule or label configuration and result |
| Failure handling | What happens when a required finding is absent or uncertain | Stop, review, exception, and owner |
This table is an acceptance record, not a generic benchmark. A detector can be accurate for one pattern and unsuitable for another. Thresholds, confidence scores, hotword rules, dictionaries, and metadata conditions are all part of the configuration being approved. If any of them changes, the relevant test cases should be rerun.
A useful test corpus also includes the negative cases ordinary demos avoid: truncated values, values split across a table and a note, a marker embedded in an attachment name, an identifier that looks like an ordinary serial number, and a reference copied from an older system. These cases often decide whether a result can be trusted in the intended workflow.
Do not stop the review at detection
Detecting a policy-selected marker answers one question: which values require special handling. It does not by itself decide what the model receives, how a changed response is handled, or who can write a final result to a business system.
For a workflow that uses LLM Capsule, the documented architecture separates these steps. Original values and the protected mapping remain in the customer-controlled environment. A protected working version travels on the approved model path. Reconstruction then occurs inside that environment before the reconstructed output reaches an authorized destination. That is a first-party architecture description, not proof that any specific deployment has all of those properties; the deployment team still needs to verify its own route, configuration, logs, retries, and error handling.
The distinction is useful even when LLM Capsule is not part of the design. Any AI workflow should make the following decisions explicit:
- What selected values and relationships enter the protected model request?
- Which system owns the transformation and any associated state?
- Which caller is allowed to request a return operation?
- What should happen to unknown, altered, missing, or duplicated protected references in the response?
- Which destination is authorized to receive the result, and how are retries and rejected writes controlled?
The context-preserving data-layer evaluation checklist provides the next architecture review: following the protected request and return path rather than approving a detector in isolation.
A stop/go rule for architecture owners
Approve the detector configuration for a named workflow only when the team can show all of the following:
- a marker inventory owned by the people responsible for the source data;
- positive, negative, repeated-reference, and collision tests for the current configuration;
- an explicit decision for uncertainty, misses, and exception handling;
- a versioned record of the data source, detector, rules, and thresholds; and
- a separate record of the protected model route, return authority, and destination.
If the workflow cannot meet these conditions, the useful result is not a broad statement that the detector failed. It is a narrower decision: this workflow does not yet have evidence that its operational markers and subsequent AI data path are ready for approval.
Where LLM Capsule fits after coverage is established
LLM Capsule does not replace DLP controls for storage, endpoints, sharing, or exfiltration policy, and it does not make the detector configuration optional. Within CUBIG’s product hierarchy, it is a Syntitan capability for controlled-context AI workflows. Its role begins after the team has decided which values require protection for a specific workflow. The architecture is intended to keep the originals and mapping in the customer-controlled environment, send a protected working version through an approved model path, and perform Reconstruction before an authorized result is delivered.
That gives the architecture owner a concrete handoff: coverage evidence proves which markers the workflow selected; the data-path review proves how the protected request and reconstructed output are governed. Both records are needed before operational data is used in an AI workflow.
Validate operational-marker coverage before the model route is approved. See how LLM Capsule supports the protected request and return path.
