Policies vs. technical controls for AI

Most organizations land on policy first. It is the lowest-cost intervention: write down what is and is not allowed, communicate it, and refer back to it during reviews. Policy is genuinely useful and this article is not an argument against it.

The argument is narrower: policy alone struggles when the tool being governed is faster than the workflow it replaces. AI is that kind of tool. A realistic AI control program pairs policy with technical controls that operate in the data path.

Why policies exist

Policies set expectations, support training, and document intent for auditors and reviewers. They define what "acceptable use" means for a given org and a given dataset. When an incident happens, the policy is what an investigation is measured against. Without a policy, every decision is ad-hoc.

Why policy alone struggles

Three reasons that come up consistently:

• Policies are not in the request path. They cannot stop a prompt that is already in flight.
• The people writing prompts are usually not the people writing the policy, and they read it once.
• AI tools make work materially faster. People will use them, on a deadline, with whatever data is in front of them.

None of this is moral failure. It is a predictable consequence of the tools getting better.

Human behavior and AI

Studies and incident reports converge on the same pattern: sensitive data shows up in prompts even when policy explicitly forbids it. It is not that people are ignoring the policy on purpose; it is that the friction of compliance — "rewrite this, anonymize that" — competes with the friction of shipping. We cover the behavior in more depth in Why employees paste sensitive data into ChatGPT.

Categories of technical controls

A short, neutral list of what teams actually deploy:

• Self-hosted models. The data does not leave a controlled environment. Strongest privacy posture; highest operational cost. See Managed vs. self-hosted LLMs.
• Prompt masking and redaction. Detect supported sensitive values in the prompt and replace them — with deterministic placeholders (masking) or with empty markers (redaction). See PII redaction vs. PII masking.
• BYOK. The provider relationship — contract, key, billing — stays inside the org. Useful regardless of which other controls are in place. See BYOK for privacy-sensitive AI.
• Access controls. Which services and which users can reach which providers. Often enforced at a gateway.
• Governance systems. Catalogs, approvals, decision records. These are not in the request path either, but they make the policy operational rather than aspirational.
• Provider-side controls. Account-level retention settings, region restrictions, training opt-outs. Useful, and worth verifying — but they are a layer you do not fully own.

Layered AI controls

No single control is sufficient. A realistic stack looks something like: policy and training at the top; upstream data minimization in the application; a gateway that masks and enforces retention; BYOK; allow-listed models; structural observability. The layers compensate for each other's gaps.

Where Privian fits

Privian is one layer: a privacy-first LLM gateway that operates in the data path between the application and the model provider. It masks supported sensitive values before they leave, supports BYOK end-to-end, and persists structural metrics rather than raw bodies. The reference for what is and is not retained lives on /data-path.

Honest limitations

Masking only catches values its detector recognizes; the detector is improved over time but is not omniscient. A gateway only protects prompts that route through it. None of this replaces policy or training; it makes them enforceable in the cases the detector covers.