Owning your AI

There’s a quiet question every CTO and CISO will eventually have to answer: who decides what your AI says no to, or nudges an organization toward? How leaky is an organization’s information security? How much influence do third party companies have on how your own company does business?

Recently, for most enterprises today, the honest answer has often been, “a policy team at an LLM backend vendor.” Simply put, this is not a defensible position. It is not a strategic position. Depending on what data you are sending across the wire — and what the vendor’s employees decide to do with it next quarter — it is increasingly not even a legal position to adopt.

There is a technical answer to this problem, and it is called, in typical jargon, ablation.

What “Ablation” Is

Large Language Model (LLM) backends are produced in two broad phases.

The first builds raw capability: a model that can predict the next “token” — a piece of text — across the breadth of human language. This is a remarkable achievement, and grew from a research tradition originating with Luigi Galvani. In 1943, the mathematical model of a neural network had already been described. Hardware technology caught up through market demand for first-person shooters, of all things, but when you give people hammers, they begin to seek nails.

The second imposes behavior: refusals, tone, safety conditioning, brand voice. This second phase of processing is where the vendor of the model encodes its own policy preferences directly into the weights of the model. There are things that are “baked in” regarding the behavior of these “artificial” intelligences.

Ablation refers to the surgical removal of those interventions and preferences about a model’s behavior, while leaving the underlying capability intact. Done well, in mathematical jargon, this minimizes the KL (Kullback–Leibler) divergence between the ablated model and the base model — meaning the system behaves almost identically to the original neural network model on the things you care about, but no longer enforces refusals you didn’t request it to make.

“Ablation” isn’t “jailbreaking” — we’re not removing criminals from prison. It’s not a prompt trick, either. Ablation of censorship is a deliberate, weight-level act of adopting ownership.

Once this has been accomplished, any company or organization can prompt-engineer and configure policies based on as clean a slate as we can create.

The Governance Question

Censorship is policy. Chatbot refusals to respond are policy. The decision to decline a user request — whatever the request may be — ought be an organizational choice, carrying legal, ethical, and operational consequences.

When that choice is made by a vendor’s policy team, three things happen. None of these is particularly good.

First, you lose alignment with your own use case. A pharmaceutical company has legitimate reasons to discuss controlled substances. A law firm has legitimate reasons to discuss violent crime. A defense contractor has legitimate reasons to discuss weapons systems. A medical educator has legitimate reasons to discuss almost anything. A vendor optimizing for the median consumer cannot possibly serve all these contexts, and so it can serve none of them well.

Second, you accept a moving target. Vendor policies change quarterly, often chasing legislation. The behavior that your team relied on six months ago may now produce a refusal, a hedge, or a redirect to a help page. You did not approve that change. You were not consulted. You discovered it when something broke in production.

Third, you create a data dependency you cannot audit. Every prompt that’s sent to a vendor API is data leaving your perimeter. For low-stakes workflows, this is probably acceptable — but for anything touching customer identifying information (PII), internal financials, M&A activity, legal matters, source code, or whatever it may be, it is not.

No amount of “we don’t train on your data” boilerplate language in a contractual agreement can substitute for true ownership. It also cannot prevent revealing enterprise secrets when agreeing with a third-party vendor for “plug-and-play” LLMs.

AI Sovereignty

A credible enterprise AI deployment looks different from third-party reliance. Instead, it’s a broad, cohesive strategy. A full accounting would include for things such as:

• The base LLM model is open-weight or licensed for self-hosting.
• It is ablated to remove vendor-imposed behavioral constraints.
• It is re-aligned — fine-tuned or constitution-trained — to enforce the organization’s own guardrails.
• Those guardrails are written down, and signed off upon by named officers.
• The model runs strictly inside the InfoSec perimeter.
• Prompts do not ship owned IP, secrets, or information up to another enterprise to read.

These components are the beginning of how to get ahead of this new industrial revolution and gold rush.

Staffing and Use

Be wary of privacy and information flows. With vendor APIs, a great deal of the data-leak risk in enterprise AI flows through the chatbot prompt itself. Staff may paste contracts, spreadsheets, customer records, and code into chat windows because those are the artifacts they work with. Most importantly, the motivations and demands upon people in an organization will be determinative — specifically, deadline pressure is the leaky valve.

If your staff training program is anything less than emphatic, your data is already leaving. Sovereignty over model weights does not absolve you of the need for sovereignty over the inputs. The two are complementary; both are truly needed in a cohesive enterprise AI strategy.

An AI model that will refuse certain requests, escalate or shape something, that policy belongs to the chief officers responsible for the organization as a whole. Those who handle and sign various regulatory filings, and are ultimately responsible.

Questions

If you are running AI inside a regulated, sensitive, or strategically important domain, I would urge anybody to ask these three questions:

1. What is the path to moving sensitive workflows inside the organization’s perimeter?
2. What does our AI refuse today, what does it suggest, and who wrote those refusals and “nudges”?
3. Who, by name and through legal / fiduciary responsibility, owns the guardrails for what the deployed AI will and will not do?

If ready answers are not at hand, you do not own your AI. Someone else owns it. The day that this becomes a problem is not the day to begin solving it.