Article
Someone on LinkedIn raised a question about sanitizing information before sending it to a frontier model. It got me thinking about a different job for local AI.
I'd use a local model to help prepare what the larger model is allowed to see.
I haven't built this workflow. But if I were designing it, I'd start with the handoff between private information and the cloud service, then work backwards from there.
Give the cloud model the task without every identifying detail
Take a hypothetical law office. Suppose someone wants help organizing a chronology from a set of documents. The model might need the sequence of events, the parties' roles and their relationships. It might not need their real names.
I'd aim to prepare a version that uses consistent labels such as Client A and Party B, keeping the real-name mapping locally. The cloud model could work with those labels. Any authorized step that restores identities would happen locally too.
That is pseudonymization: replacing identifiers while retaining a way to reconnect them. It doesn't make the material anonymous. An unusual event, an address or a combination of details can still identify someone.
Whether a particular legal task could use a cloud service at all would need to be decided before building the handoff. Changing names wouldn't settle that question.
I'd give the local model a narrow job
A local model could help find identifying references that don't follow a tidy pattern. Rules could handle things such as known identifiers and exact matches. I'd use both, then check the prepared text against what the task actually requires.
For the chronology example, a useful result would preserve who did what and when, even after names changed. If the preparation merged two people into Client A or removed a date the analysis depended on, the larger model would be reasoning from damaged context.
I'd keep the label mapping within the local system, separate from the outbound brief. Labels would stay consistent within a matter, without becoming a reusable identity key across unrelated matters.
The design needs to check attachments, file names, extracted text and metadata as well as the visible prompt. It also needs to keep raw material out of remote debugging and telemetry. A cleaned paragraph doesn't help much if the original document leaves through another path.
The check has to happen before the cloud call
A hook is a piece of code that runs at a defined point in a workflow. A coding assistant might offer a hook that can call a local preparation service. Whether that hook is useful depends on when it runs and what it can block.
If the remote model has already received the original context before the hook runs, the check is too late.
I'd therefore put the raw source in a local-only stage and give the cloud-connected assistant only the approved output. I'd use a hook only where its documented behaviour lets it enforce that boundary. Otherwise, I'd use a separate local preparation step or a controlled gateway before making the request.
If a check failed or the local service was unavailable, I'd stop the handoff. I wouldn't fall back to sending the original.
A second brain needs selective access
This is where the idea connects to a business second brain: the documents, notes and decisions an assistant uses as working context.
A useful assistant may need access to a lot of that material. A particular request usually needs a smaller portion. I'd apply the same access permissions as the source system, select the relevant material locally, then prepare the minimum context needed for the task.
My thesis is that local AI can earn its place by doing this preparation, even when a cloud model handles the heavier reasoning. It gives each stage a specific job and makes the choice about what leaves the local system explicit.
Before using it with real files, I'd test it on synthetic documents containing known identifiers, indirect clues and deliberately awkward cases. I'd check both what leaked and what useful meaning disappeared. A local model's own confidence wouldn't be enough to approve the handoff.
The first version I'd build would handle one document type and one narrowly defined task, with a person reviewing the prepared context before it went anywhere.