Advokat Frida

Advokat Frida

Privacy and AI governance, by design and in practice. For the people who have to make principles actually work.

The Plain-English AI Glossary

The words that keep turning up in vendor decks, model cards, and that one Slack thread nobody understands, translated into plain English. A living field reference, simplified on purpose. No lanyard required.

Somewhere between "agentic orchestration layer" and "we don't train on your data," the AI conversation quietly stopped defining its own words. This is the decoder ring.

Every term below is written the way you'd want a sharp colleague to explain it: plain, fast, and honest about why it matters to your actual work. These are field definitions, simplified on purpose to get you oriented. They are not formal or legal definitions, and where a word has a precise technical meaning, we cheerfully trade a little precision for a sentence you can use in a meeting.

It's a living list. When a new word starts turning up in vendor decks often enough to be annoying, it earns a seat here. Tap any term to open it.

The basics: what the thing actually is

LLM (large language model)
The "AI" behind ChatGPT, Claude, Gemini, and the rest. Underneath, it's an enormous pattern-prediction engine trained on a staggering amount of text, which makes it startlingly good at producing the next plausible word and gives it no built-in sense of whether that word is true. A useful mental model: a brilliant, fast, confident intern who has read most of the internet and remembers none of the sources.
Model
The brain doing the thinking (GPT, Claude, Gemini). It's distinct from the product (ChatGPT, the service with the login and the terms) and the interface (the app or window you actually click). One model can sit behind many products. If you want the full map, that's the job of Part 1 of our Field Guide to AI Tools.
Token
The unit an AI reads and writes in. A token is a chunk of text, very roughly three-quarters of a word, so "cookie" might be a single token while "de-identification" gets chopped into several. Tokens are how usage gets measured and billed, and they're why pasting a 300-page contract can get expensive or quietly cut off at the edge.
Tokenizer
The machine that does the chopping: before the model sees anything, the tokenizer chops your text into pieces from a vocabulary fixed at training time (the usual algorithm is byte-pair encoding, or BPE, if a vendor deck wants to impress you). Familiar words stay in one piece; rare words, names, and non-English text get split up, which is why the same sentence often costs more tokens in German than in English.
Context window
How much the model can hold in its head at once, counted in tokens, including both what you put in and what it writes back. Modern windows are large (anywhere from a few thousand tokens to well over a million, depending on the model) but never infinite. Blow past it and the model silently forgets the earliest material, which is exactly how a long document review goes wrong with no error message to warn you.
Prompt
Whatever you send the model: the question, the instruction, the pasted document, all of it. "Prompt engineering" is the slightly grand name for writing the request clearly enough that the machine does the right thing the first time.
System prompt (or custom instructions)
The standing instructions sitting behind every conversation, setting the role and the rules before you type a word ("you are a careful privacy analyst, preserve uncertainty, never invent citations"). It's the difference between re-explaining yourself every single time and setting expectations once. More on this in Part 4 of the Field Guide.
Parameters (or weights)
The internal numbers a model learns during training, usually quoted in the billions. Treat "more parameters" as a rough proxy for capability, not a promise. A bigger engine isn't automatically a better driver.
Training data
The mountain of text a model learned from. This is the single most important phrase in any AI vendor's terms. "Do you train on our inputs?" is the question that decides whether your contracts, client data, and half-formed strategy quietly become someone else's model improvement.
Knowledge cutoff
The date the training data stops. Ask a model about something after its cutoff and, unless it can search the web or read files you hand it, it's guessing from before the line. This matters because "it only knows its training data" used to be the whole story. Now many tools can search or be handed current documents, which is the entire point of the next few terms.

Why it acts like that: the behaviors that bite

Hallucination
When the model states something false with total confidence, up to and including citing a regulation, case, or statistic that does not exist. It isn't lying. It has no concept of truth, only of plausible-sounding text. This is the reason you never ship an AI's facts, citations, or legal references without checking them yourself. Confidence is not evidence.
Grounding / RAG (retrieval-augmented generation)
The standard fix for hallucination and stale knowledge. Instead of answering from memory, the model is handed the relevant source material at question time (your documents, a search result, a policy) and answers from that. A grounded answer you can trace to a source beats a confident answer you can't, every time. "Give it the files" is most of the job.
Temperature
A dial for randomness. Higher temperature means more varied, creative, unpredictable output; lower means more focused and repeatable. It's why the same prompt can hand you a different answer twice. Plenty of consumer apps hide this dial, but it explains the variability you've definitely noticed.
Fine-tuning
Further training of a base model on specific examples to specialize it, say a model tuned on your house style. It's different from prompting or handing it documents. It's powerful, costly, and usually not what you need. Nine times out of ten, good instructions plus the right documents beat fine-tuning.
Inference
The act of actually running the model to get an answer, as opposed to training it in the first place. When a vendor mentions "inference cost," they mean the price of every answer, not the one-time cost of building the model. Training is the tuition; inference is the payroll.

The 2026 words: agents and tools

Agent / agentic
An AI that doesn't just answer but takes steps. It can use tools, read and write files, call other software, and chain several actions toward a goal, with more or less supervision. An agent that can act is both more useful and more dangerous than a chatbot that can only talk. The whole game becomes what it's allowed to touch.
Tool use (or function calling)
The mechanism that lets a model do things beyond text: run a search, query a database, send a request, open a file. The moment a model can use tools, "what can it access?" stops being a theoretical question.
MCP (Model Context Protocol)
An open standard for plugging tools and data sources into AI assistants in a consistent way, instead of every vendor hand-wiring its own. You'll see it more and more through 2026. It's becoming the USB-C of AI connectors, which is convenient, and worth a glance from anyone tracking what their AI can quietly reach.
Connectors
The pre-built bridges that let an AI product reach into your other systems: email, calendar, Drive, a ticketing tool. Every connector is a new door into data. Convenient, and a fair question for your risk register.
Instruction file (CLAUDE.md, AGENTS.md)
A plain text file that gives an AI agent standing instructions for a project: the role, the house style, the rules, the things it must never touch without asking. Claude reads CLAUDE.md; a growing set of other tools (Codex, Cursor, and friends) read the shared AGENTS.md convention. Think of it as the system prompt's filing cabinet: a briefing you write once instead of re-typing every morning. It's the difference between an assistant that keeps forgetting your rules and one that starts every session already briefed. It's also a terrible place for secrets, because it gets read on every single run. Part 4 of the Field Guide covers what belongs in one.
Multimodal
Handles more than text: images, audio, PDFs, screenshots, sometimes video. Useful for reading a scanned contract or a screenshot, and a reminder that "don't paste sensitive data" now includes pictures of it.

The words that touch your data: read these twice

"We don't train on your data"
The vendor's promise that your inputs and outputs won't be folded back into model training. This is the line separating "private tool" from "free product where you are the training set." Get it in writing, and check whether it's the default or something you have to go switch on.
Zero data retention (ZDR)
A stronger setting where your inputs and outputs aren't stored after they're processed, only handled in the moment. No retention means a smaller breach surface and a much easier conversation with security. It's often gated to enterprise plans, so ask.
Data minimization
The old privacy principle that keeps outliving trends: use the least data that does the job. The least collected, the least pasted, the least connected. In AI work it becomes a very practical habit: share the clause, not the contract; the folder, not the drive; the sample, not production. Everything extra the model can see is something you now have to account for. If a tool needs access broader than the task justifies, that isn't a setup step, that's a finding.
Scrubbing (or: placeholder prep)
Stripping the identifying details out of text before it goes to an AI: real names become [NAME], account numbers become [ACCOUNT_REF], and the work still gets done. A prompt shapes the answer; it does nothing about the data you paste in to get it, and no clever instruction un-sends what already left. Two honest limits: a placeholder is only as good as your ability to keep the mapping to yourself, and automated scrubbers hand you candidates to review, not a guarantee they caught everything. This is the one privacy control that works on any AI tool, on any plan, with no procurement meeting. Our Build-A-Prompt tool has a placeholder mode wired in.
Secrets (API keys, tokens, credentials)
In tech-speak, a "secret" is any string that is the access: API keys, passwords, session tokens, signing keys. They ride along in exactly the things people paste into AI chats without a second look, like config files, error logs, code snippets, and that one screenshot of the deployment settings. Personal data leaking is a process failure you manage; a live credential leaking is a door standing open right now. Keep secrets out of prompts, out of connected folders, and especially out of instruction files, which get loaded every run. If one slips, rotate it. Don't negotiate with hope.
Prompt injection
An attack where hidden instructions buried in content the AI reads (a web page, an email, a document, a calendar invite) hijack it into doing something it shouldn't, like leaking data or ignoring its own rules. The more an agent can read untrusted content and use tools, the less theoretical this gets. It's the new "don't click the link," except now the AI is the one doing the clicking.
"Runs in your browser" (zero network)
A claim about where the work happens: the page does its computing on your machine, and nothing you type or paste is sent anywhere. It's the strongest version of "we don't store your data," because there is no server to store it, and it's how our own tools are built. The claim is checkable, and you should check it. Open your browser's network tab, use the tool, and watch for requests. A tool that phones home while saying "local" has just answered several of your vendor-diligence questions early.
Human in the loop
A person reviews, edits, or approves the AI's output before it actually does anything or goes out the door. For anything with legal, financial, or privacy consequences, this isn't optional caution, it's the design. The AI drafts; a human decides.

The de-identification aisle: when data claims to be anonymous

PII / personal data
Two overlapping terms for "information about a person." PII (personally identifiable information) is the American habit, and it often gets read narrowly: name, SSN, the obvious identifiers. Personal data is the GDPR term, and it's deliberately broader: anything relating to an identifiable person, including things that only point at someone in combination, like a postcode plus a birthdate plus a job title. The gap between those two readings is where "we removed the PII" goes wrong. Data can be scrubbed of the obvious identifiers and still be personal data, which is the entire subject of the next few terms.
Anonymization vs pseudonymization
Two words vendors use interchangeably that the law very much does not. Pseudonymization swaps the identifiers for stand-ins (user 4471 instead of a name) while somebody, somewhere, keeps the key. Still personal data, because it can be linked back. Anonymization is the far stronger claim that nobody can identify the person anymore, by any means reasonably likely to be used, and honestly earning that word is much harder than deleting the name column. The word on the slide decides which obligations apply. When a vendor says "anonymized," the working question is: could anyone, holding any other dataset, get back to a person? If yes, you're looking at pseudonymized data and a marketing document.
Re-identification (and the mosaic effect)
Figuring out who's who in data that was supposed to be anonymous, usually by lining it up with something else: another dataset, a public record, or simply what the observer already knows. The mosaic effect is the pattern behind it: each released piece looks harmless, and the combination is a portrait. It doesn't take a hacker. A published headcount plus a manager who knows the team can be enough to out one person. "no names in the file" is not the finish line. The question is never whether one release identifies someone; it's what that release reveals when combined with everything else out there. Our differential-privacy explainer, the Avery story, walks a full worked example.
Membership inference
Working out whether a specific person is in a dataset from the numbers that came out of it. Sounds abstract until it isn't: "is my employee in the sensitive-benefit count," "was this patient in the study." Sometimes being in the dataset at all is the sensitive fact, and an exact aggregate can give it away to anyone who knows enough context. Beating this attack is the entire job differential privacy signs up for, which is conveniently the next term.
Differential privacy (DP)
A release discipline for aggregate statistics: instead of the exact count, the system publishes a slightly noisy one, calibrated so the published answer behaves almost the same whether or not any one person is in the data. The one-person change disappears inside the wobble, and the subtraction trick that outs an individual stops working. It is not just "adding random noise": the noise comes with a formal promise about how much one person's data can move the output. DP protects the numbers that leave the system, not the raw data sitting inside it. If people can still open the underlying dataset, the math is decoration on an open door. And when a vendor says "we use differential privacy," the sharp follow-up is the next term down.
Epsilon (the privacy budget)
The dial on differential privacy. A low epsilon is a tight cap on how much any one person can shift the published answer: more privacy, blurrier numbers. A high epsilon buys sharper numbers and weaker protection. The scale is exponential: the distance between epsilon 1 and epsilon 8 is roughly a thousand-fold, not eight. And because repeated queries can be averaged until the noise cancels out, real systems track a budget: every release spends some of it, permanently. There is no officially "compliant" epsilon; it's a number someone has to justify. So the vendor question isn't "do you use DP," it's "what's your epsilon, and across how many queries?" They should be able to tell you theirs.
Synthetic data / fake data
Data manufactured instead of collected. The catch: "synthetic" covers two very different products. Fake data generated from your real data keeps the statistical shape, which is useful for analytics, and leaves you arguing about memorization, linkage, and how much of the original is still showing through the fake. Fake data that never touched real data at all, built from reserved ranges and obviously-fake structures, carries no ghost to argue about. When someone says "it's synthetic," the first question is synthetic how, because "not derived from production data" and "not personal data" are different claims, and only one of them is cheap to prove. That's the entire design argument of SafeSeed, our fake-by-design test-data tool.

The governance words: who's on the hook

Provider vs deployer (EU AI Act roles)
The EU AI Act's two lead roles. The provider builds or supplies the AI system under its own name; the deployer uses it under its own authority. Most companies rolling out someone else's AI tool are deployers. Different role, different obligation stack, and the provider's is much heavier. The catch everyone misses: roles are assessed per system, and a deployer can slide into being a provider, for instance by putting its own brand on a system or substantially modifying one. "we just use it, we didn't build it" is a legal position, not a shrug, and it stops being true faster than most teams expect. A glossary hands you the words; working out your actual role for an actual system is a stepwise determination, which is exactly what our wizards are for.
Risk tiers (EU AI Act)
The AI Act sorts AI systems by what they're used for, not how clever they are. A short banned list (prohibited: social scoring, manipulative techniques, and similar); a demanding high-risk tier for uses like hiring, credit, and essential services, which carries the heavy compliance machinery; a transparency tier where the main duty is telling people they're dealing with AI (chatbots, deepfakes); and minimal risk, which is most of everything else. General-purpose models like the ones in this glossary run on their own parallel track. The tier decides the homework, and the same model can land in different tiers depending on what you wire it into. Classifying a real system against the real annexes is wizard work, not glossary work, and ours walk it question by question.

That is the decoder ring so far. Now go forth and nod convincingly in meetings — and if anyone asks how you suddenly know what a context window is, you never saw us.

—🦊

Catch something wrong, or just want to argue with me? hello@advokatfrida.com