“Context is the new source code.”

Most LLM context windows contain PII on day one. Most teams find out when the DPO asks.

Companies that avoid this don't start with the model — they start with a process map. They trace where decisions are made, where personal data flows, and what the model will actually see. Then they build a knowledge system: the structured context the LLM reads as its operating reality. The context window is the program. Bad context is a liability.

SEQUENCE The five-stage setup

1. Process mappingWhich workflows touch an LLM, what decisions it influences, who owns the outcomes.
2. Risk assessmentWhere PII enters the workflow, and what regulatory obligations apply.
3. Knowledge systemThe structured context the LLM reads: policies, definitions, decision rules, org vocabulary.
4. RAG layer optionalRetrieval-Augmented Generation (RAG) connects the LLM to live internal documents. Every retrieved chunk is a potential PII exposure point and must be sanitised before it enters the context window.
5. Context engineeringShaping what the LLM sees on each request. The context is the program.
6. Verification loopTest harness, held-out test sets, regression checks after every change.

Dark skills spread like viruses — through the packages your team already trusts.

Every AI tool your team installs ships with instruction files — CLAUDE.md, AGENTS.md, system prompts, tool configurations. These files tell the AI assistant how to behave. When a compromised package lands in your dependency tree, its instruction files execute silently alongside your legitimate ones.

A well-meaning vendor ships a developer tool. The tool's CLAUDE.md contains hidden instructions injected by an attacker. Every developer on your team now has a compromised AI assistant — and no one triggered any security alert.

ATTACK CHAIN How supply-chain poisoning works

Reference. The TrapDoor campaign (May 2026) planted malicious instruction files across 34 packages on npm, PyPI, and Crates.io. Standard security scanners did not flag them.

Fast, specialised, and yours. It runs locally. It doesn't phone home.

General-purpose LLMs are generalists. For specific, high-frequency tasks — detecting PII in documents, classifying intent in support tickets, routing Jira issues — a small fine-tuned classifier runs in under 5ms, outperforms the general model on your data, and costs nothing per call once deployed. You own it.

PIPELINE How training works

1. Collect 200–400 labelled examples from your actual data (anonymised).
2. Pre-process: normalise formats, handle edge cases, split into train / validation / test sets.
3. Fine-tune on GPU — typically 7 iterations, each validated against a held-out test set.
4. Early stopping prevents overfitting; the validation F1 score gates each iteration.
5. Security audit: adversarial samples, edge-case stress test, output boundary checks.
6. Deploy: the classifier runs in your Docker container, <5ms inference latency.

Hardware: NVIDIA H100 (80GB HBM3) # the GPU that runs the training
          3.5TB/s memory bandwidth.

A BERT-class NER fine-tune completes one iteration in ~6 GPU-hours.
Seven iterations → one validation-gated model.

Raw compute cost:  ~€180
The expertise is what costs.

Your internal vocabulary is PII.

Project codes map to client names. Ticket IDs map to employees. Workflow state labels reveal process context that regulators may classify as personal data. A foundational model that can't read your language can't protect it — it will hallucinate your identifiers, skip them, or pass them through unredacted.

Fine-tuning teaches the model your vocabulary. A labelled dataset of 100–300 examples and a LoRA adapter (Low-Rank Adaptation — a technique that modifies a small fraction of model weights without full retraining) are enough to make a general model domain-fluent on your specific patterns.

PATTERNS What custom detection covers

Technical note.Fine-tuning uses LoRA (Low-Rank Adaptation) — modifying a small fraction of a model's weights without retraining from scratch. A 7B model with a LoRA adapter fine-tuned on 300 examples runs on a single H100 in under 12 hours.

Once you've mapped your processes, the PII problem becomes obvious.

When you complete the process map from Section 01, one pattern appears in almost every workflow: personal data flows through the LLM request. Names, contract parties, employee IDs, health indicators — all in the context window, all transmitted to an external API endpoint outside EU jurisdiction.

Reversible anonymisation solves this without breaking the workflow. The AI receives sanitised text, produces a useful response, and your application receives the response with originals restored. The external model never sees real values.

FLOW How reversible anonymisation works

1. OutboundSkilmo replaces each PII span with a placeholder — [PERSON_1], [IBAN_1], [EE_ISIKUKOOD_1].
2. Key storageMapping stored locally under a one-time session key — never transmitted.
3. AI processingThe AI receives sanitised text and responds normally.
4. InboundSkilmo restores the originals into the response before your application sees it.

COVERAGEBaltic & Nordic identifiers

Trust nothing, ship tested.

Models update without announcement. Regulatory guidance shifts. Attack patterns evolve. An AI deployment without a verification loop is a system you're flying blind. Every classifier we ship includes a test harness: held-out test sets, regression suites, adversarial samples for edge cases. When the underlying model updates, the test suite runs automatically. If F1 drops, we know before your users do.

STACK The verification loop

• Held-out test set — 20% of training data reserved, never used in training, gates every iteration.
• Regression suite — curated edge cases from production incidents, re-run after every change.
• Adversarial samples — deliberately crafted inputs designed to fool the classifier, run before every deployment.
• Drift monitoring — F1 score tracked over time; alerts when accuracy degrades past threshold.
• Human audit checkpoint — Klaus Jõgi reviews outputs on every engagement before sign-off.

REGULATED Why this matters

ISO 27001 Annex A.12 requires evidence of system testing and monitoring. GDPR Art. 32 requires appropriate technical measures. A test harness is not optional in regulated deployments — it is the evidence. Zero-trust architecture applied to AI means every model output is treated as untrusted until validated — the test harness is the trust gate.

Keeping a classifier current requires monitoring model updates, re-running test suites, and re-calibrating when accuracy drifts. Across multiple classifiers, multiple document types, and a changing regulatory landscape — this is a full-time function. We maintain it as part of every engagement.

We are ISO 27001 certified IT security auditors. We treat your AI stack like a software supply chain — every component verified, every instruction file accounted for. We sign off on deployments. If something we build introduces risk, we find it before it ships.

Each answer is written to stand alone as a complete definition.