Inside Opus · Part 8 of 13
This series follows a hypothetical supplier-invoice exception workflow. The Agent node that extracts and interprets invoice fields may use an externally hosted model. This article is about what that model is allowed to see. Part 1, “A piece of work through Opus”, is the map; Part 7 covered who may act.
Redaction that destroys the question
For this check, the exception case compares two documents: the invoice and a remittance advice from an earlier payment. The purchase order is still missing. The task is to identify a potential duplicate of something already paid. Useful signals include relationships: is the supplier on the invoice the same supplier on the remittance, is the account the same account, and does the service period overlap?
Now suppose the customer’s policy is that supplier names, account numbers and personal names may not be sent to an external model. The naive approach removes them. The model receives two documents in which every supplier is “[REDACTED]” and every account is “[REDACTED].” It can no longer tell whether the two suppliers are the same one. The privacy control has removed information the task needs to reason about.
The requirement
The system has to decide, for each inference, whether data may leave the trust boundary at all, and if it may, in what form. Where sensitive identifiers must not leave, the transformation applied to them must preserve the relationships the task needs: that this entity is the same as that one, that this date is a service date and not an invoice date, that these two accounts are different.
By trust boundary I mean the customer’s configured Opus environment: the cluster and the managed services approved as part of that deployment. Whether a provider-hosted service belongs inside it depends on the approved service configuration and data-handling arrangements, rather than the provider’s name alone.
Three inference choices
Opus offers three arrangements for inference, and they trade differently.
Inference inside the trust boundary. Models run within the tenancy, whether self-hosted open-weight models or approved cloud-provider model services configured within the customer’s declared boundary. This path keeps the model input inside that boundary. Identifier transformation is not needed for the inference boundary itself, although other policies may still restrict what the model receives. Quality and capacity depend on the chosen model and deployment; self-hosting also brings serving and operations costs.
Inference outside the trust boundary, as standard. An externally hosted model receives the permitted prompt, including any untransformed source data. This avoids operating the main model locally, but exposes that prompt to the external provider. Task quality, quotas, price and retention terms depend on the model and provider.
Inference outside the trust boundary with Smart Aliasing. Detected sensitive entities are replaced, inside the boundary, with typed stable aliases before the external call, and restored afterwards under policy. This is the middle option, and the rest of the article is about it.
Data sent to an external model
Inside boundary: None on this inference path
Outside, standard: The permitted prompt, including raw identifiers if allowed
Outside with Smart Aliasing: Transformed context; residual sensitivity remains
Task quality
Inside boundary: Evaluate the local or approved in-boundary model
Outside, standard: Evaluate the selected hosted model
Outside with Smart Aliasing: Evaluate the model and the effect of transformation
Cost drivers
Inside boundary: Model serving, capacity and operations
Outside, standard: Provider usage and integration
Outside with Smart Aliasing: Local processing, mapping and restoration, plus provider usage
Capacity constraints
Inside boundary: Provisioned capacity or in-boundary service quotas
Outside, standard: Provider quotas and availability
Outside with Smart Aliasing: Local processing capacity and external provider quotas
These describe mechanisms to assess, not a universal ranking of privacy, quality or price.
The choice can be made per node, per workflow, or enforced across a whole tenancy. Smart Aliasing requires GPU capacity inside the boundary and adds processing and restoration work to each external call; total cost depends on usage and the deployment.
Classify and extract inside the boundary
Before any external model call, workflow and task inputs are parsed for modality, language, complexity, sensitivity and machine-readability, and classified by genre and domain. This classification routes the rest of the pipeline: it decides which extraction path to use, which semantic types apply (a supplier, an account and a regulator are different roles in a finance document than a patient and an insurer are in a claim), and in some cases that the task can be done locally without any external call.
Documents are then turned into structured text inside the boundary, using Opus-hosted OCR and language models. This is not just text extraction. The extraction preserves structure such as order, table membership, header associations, key-value pairs and links between visual regions and text. The reason becomes clear in the next step: an alias has to be consistent across pages, tables and repeated references, which requires resolving whether “Northwind Ltd” in the header and “Northwind” in the footer refer to the same entity.
Type the entities, then alias them
Sensitive entities are detected locally: names, identifiers, addresses, account numbers, dates, organizations, signatures and so on. Each is assigned a semantic type and a role in context. The same raw string can play different roles: a date may be an invoice date on one line and a service date on another, and the alias has to carry that difference.
Then the stable semantic alias service replaces resolved entities with typed, stable aliases. For these two documents, that might produce SUPPLIER_01 for Northwind, ACCOUNT_3 for the bank account on both documents, INVOICE_DATE_1 for the invoice date, and SERVICE_DATE_12 and SERVICE_DATE_13 for the service-period endpoints. Alias generation is deterministic for the resolved entity and role, with a stable mapping during the workflow execution. The service is designed to give distinct resolved entities distinct aliases. Detection and resolution can still miss or conflate entities; a stable alias does not prove the original match was correct. The mapping from alias to original stays inside the trust boundary.
What the external model sees
The external model receives documents in which SUPPLIER_01 and ACCOUNT_3 recur across the invoice and remittance. If both documents carry the same service-period endpoint aliases, it can also identify that they refer to the same period. Those links support a potential-duplicate flag; they do not establish that the invoice was paid twice.
Opaque aliases do not encode chronology. SERVICE_DATE_12 does not necessarily precede SERVICE_DATE_13. Determining the order or overlap of different date ranges requires temporal information that policy permits the model to see, or a check inside the boundary. The supplier’s name and account number are replaced on this path when detection succeeds, but the surrounding document context still reaches the model.
That is the useful distinction from blanket redaction: stable typed aliases preserve repeated-entity links and semantic roles while replacing the corresponding identifiers. They do not preserve every property of the original values.
Restore what is permitted, and check
The response comes back inside the boundary. A restoration layer resolves aliases against the mapping, and it does so under policy: re-identification is task-specific and restores only permitted fields needed by the task. Before restoration, the layer checks for aliases that were never issued, corrupted aliases and invalid combinations of entities. Detected failures block re-materialization; these checks do not establish that every entity was correctly resolved in the original documents.
Under the customer’s selected audit profile, retained outputs can include a copy with aliases for logging and review and a re-identified operational copy for authorized use inside the protected environment. Their availability and retention follow the applicable capture, access and retention settings. A copy with aliases can still contain sensitive surrounding context.
The remaining trade-off
It is worth being direct about what this does not achieve.
It is a privacy transformation, not formal anonymization. Context can still be sensitive even when identifiers are aliased: an unusual combination of amounts, dates and locations may be identifying on its own. Entity detection can miss things, and a missed entity can cross the boundary unaliased. Resolution errors can also link entities that should remain distinct. Some tasks genuinely need the original values, and for those the choice is between local inference and accepting exposure under the applicable policy.
The measurements that assess the mechanism are how much raw data still leaves, how much task quality is retained compared with the standard path, and how often restoration produces errors. Those are measurable on representative data, and stronger claims than the ones here should wait for them.
The alternative, and the cost
Fully local inference is the right choice for strict data boundaries and for tasks where the local model is good enough. It has no mapping state and no restoration step.
Simple redaction may be sufficient when the removed entities are irrelevant to the task: a sentiment classification does not need to know whose sentiment it is.
Stable semantic aliases target the tasks between those two: tasks that need relational continuity across sensitive entities and benefit from a frontier model. The costs are local GPU processing, mapping state that has to be protected, restoration checks, and expense per call.
Next
Once the permitted inference options for a node are known, there is still a choice of which model to use within them. Part 9 explains why we make that choice before the workflow runs rather than on every request.