The Intern that Doesn't Leave the Building

For most of corporate history, confidential information had a helpful physical property, which is that it was annoying to move.

You had to print it. Or email it. Or put it in a data room. Or give someone a login to the data room, then give their associate a login to the data room, then revoke both logins six months later after no one remembered why they had access in the first place. This was not a perfect security model, but it had a certain frictional dignity. Secrets did not usually sprint across the internet on their own. Someone had to make a decision. Often a bad decision, yes, but at least a decision.

Then AI arrived, and a lot of companies discovered a new workflow:

Take the confidential information, paste it into a little box, and ask the box what it thinks.

This was, in fairness, a pretty good workflow. The box was useful. The box could summarize the 90-page contract. The box could explain the strange indemnity language. The box could turn a messy meeting transcript into an action plan. The box could read the customer complaint, compare it to policy, draft the response, and do in eight seconds what had previously required three people, two meetings, and a shared Google Doc called “FINAL_v7_revised_REALFINAL.”

Naturally, people liked the box.

The problem was not that the box was evil. The problem was that the box was an intern.

Not an ordinary intern. An extraordinarily fast, cheerful, slightly gullible intern who never sleeps, reads every document you give it, remembers patterns you did not notice, writes fluently about things it may or may not understand, and is always eager to help. This is a wonderful employee to have, provided you do not hand it your customer database and say, “Go work on this somewhere else.”

And yet that has been the default shape of much of the AI boom: the intern is not in your building. The intern is in someone else’s building. You send it your files. It sends you back an answer. There are contracts and policies and privacy commitments and enterprise settings, and many of these are serious and useful. But at the conceptual level, the workflow is still strange. A company spends years building walls around its most sensitive information, and then, because the intern is charming and very good at bullet points, begins sliding documents through a slot in the wall.

This is why private AI matters.

Not because public AI is bad. Not because every cloud model is a trap. Not because the only safe computer is a laptop in a basement wrapped in aluminum foil. The point is simpler and more useful than that.

Private AI is what happens when you decide that the intern should work inside the building.

It should sit near the documents. It should follow the company’s rules. It should have a badge. It should have access to some rooms and not others. It should write down what it did. It should ask permission before doing anything irreversible. It should not be allowed to accept instructions from every piece of paper it reads. And when it leaves a project, it should not take a souvenir copy of the strategy deck.

This sounds boring. That is the point. A lot of good security is boring. Doors are boring. Badges are boring. Audit logs are boring. Permissioning is boring. “Please do not email the merger model to your personal Gmail” is boring. And yet whole industries are built on these boring ideas, because the alternative is discovering that your crown jewels have become training material, source material, or just material-material for a system you do not really control.

There is a common way to talk about private AI that is technically correct but undersells the idea. It goes like this: “Our data is confidential, so we do not want to send it to a third-party model.”

Fine. True. Sensible. Also not very exciting. Companies have preferred not to send confidential data to third parties for a long time. There are procurement forms about this. There are vendor-risk questionnaires. There are people whose entire job is to ask whether the subcontractor has a subcontractor, and whether that subcontractor has a SOC 2, and whether the SOC 2 says anything useful, and whether anyone has actually read it. This is civilization.

But the more interesting argument for private AI is not that it helps companies do less risky AI.

The interesting argument is that it helps companies do more useful AI.

If the AI lives outside the wall, you ask it outside-the-wall questions. Rewrite this paragraph. Summarize this public article. Draft a generic onboarding plan. Explain this regulation in general terms. Write a polite email declining a meeting. These are useful tasks, but they are not the deepest tasks. They are the tasks you can do without giving the AI much context.

Real work requires context.

Real work sounds like: What did we promise this customer last quarter? Which contracts have the clause we are worried about? Which support tickets suggest a product defect? Which sales claims conflict with the approved language? Which internal documents support this answer? What changed between the old policy and the new one? Which deal files are missing approvals? Which security incidents look similar to this one? Which code paths handle the sensitive data? Which employees are asking the same question in five different ways?

Those questions are valuable precisely because the answers are buried in private information. The useful stuff is the sensitive stuff. The customer history, the contract archive, the board materials, the R&D notes, the incident reports, the source code, the investment memos, the clinical notes, the legal analysis, the messy internal chat where someone finally explained what the policy actually means.

A generic AI cannot answer those questions well because it does not know the institution. A cloud AI can answer them only if the institution is willing to send it the third party. A private AI changes the bargain.

Private AI is not less capable AI. It is AI allowed to know the useful stuff.

That is the optimistic case. It is not about hiding from the future. It is about making the future deployable.

The immediate AI security problem is not, mostly, that the model might become conscious and develop a taste for wire fraud. The immediate problem is that AI turns passive information into active influence.

A PDF used to be a PDF. It could contain wrong information, secret information, embarrassing information, or legally explosive information. But it was mostly inert. It sat in a folder. A person opened it. The person read it or pretended to read it. The person made a decision.

With AI, the PDF can become part of a decision-making loop. An agent reads the PDF, extracts instructions, updates a workflow, drafts a message, files a ticket, queries a database, or calls a tool. The PDF is no longer just a document. It is part of the interface. In some cases, it is part of the control surface.

This is where things get weird.

In normal software, we try very hard to distinguish between data and instructions. Data is “Customer name: Alice.” An instruction is “Delete the customer database.” These are different categories. A well-designed system does not confuse them. A spreadsheet cell should not be able to negotiate with the payroll system. An email footer should not be able to override the CFO.

AI is useful partly because it is less rigid about categories. It reads a messy email and infers what the sender wants. It reads a policy and infers the rule. It reads a transcript and infers the next steps. This flexibility is the magic. It is also the risk. Because once a system can interpret anything, anything can try to instruct it.

A support ticket can contain a hidden prompt. A vendor document can include malicious text. A web page can tell an agent to ignore prior instructions. A retrieved knowledge-base article can steer an answer in the wrong direction. A calendar invite can attempt to manipulate the assistant reading it. These are silly examples until they are not. The old internet was full of forms that accepted text. The new internet is full of systems that treat text as advice.

So the question for AI security is not just “Is the model safe?” That question is too abstract. It floats somewhere above the actual problem, wearing a conference badge. The better questions are more practical.

Where does the model live?

What can it see?

Whose instructions does it follow?

What can it do?

What does it remember?

Who can inspect what happened afterward?

These questions are not glamorous, but they are the questions that determine whether AI becomes a toy, a liability, or infrastructure. Private and local AI give better answers to some of them.

If the model runs inside a controlled environment, sensitive information does not need to travel as far. If retrieval happens against internal systems with internal permissions, the AI can inherit existing boundaries rather than invent new ones. If the agent’s actions are logged locally, the company can audit what happened. If data retention is governed by the institution, not by someone else’s default product setting, compliance becomes more than a checkbox. If the model can be limited to a specific network, machine, tenant, or enclave, then “who saw this?” becomes an answerable question rather than an exercise in trust.

This does not make private AI magic.

A local model can still be wrong. A private agent can still be over-permissioned. A badly designed internal assistant can still leak confidential information from one employee to another. Prompt injection does not become harmless merely because it happens on-prem. If you give the intern access to every room in the building, the fact that the intern remains in the building is not much comfort. But private AI improves the shape of the problem.

It turns “Can we trust the outside system with our inside knowledge?” into “How do we govern an inside system with access to inside knowledge?” The second question is still hard, but companies (and people) have tools for it. Access controls. Logs. Segmentation. Retention rules. Approval flows. Monitoring. Least privilege. Incident response. The ancient arts of not letting everyone do everything all the time. This is the positive version of AI security: not saying no to AI, but making AI administrable.

The history of enterprise software is basically the history of taking magical new capabilities and surrounding them with boring controls until adults are willing to use them. Email was magical, and then it got archiving, permissions, encryption, filtering, legal holds, and the occasional message from IT reminding everyone not to click the attachment. Cloud storage was magical, and then it got admin consoles, sharing policies, data-loss prevention, and a lot of folders named “Do Not Share Externally.” SaaS was magical, and then procurement arrived with a spreadsheet.

AI is going through the same process, only faster and with more existential vocabulary.

At first, the magic was enough. Look, it writes. Look, it codes. Look, it makes a deck. Look, it can summarize the deposition transcript in the voice of a pirate, which is not useful but does prove something about civilization. Then companies asked the obvious next question: Can we use this for real work? But real work, inconveniently, contains real data.

So now the industry has to grow up. The future is not just bigger models, faster chips, longer context windows, and more impressive demos. Those things matter. But the future that enterprises can actually adopt is the one where AI fits into the security model instead of asking the security model to step aside for a minute while it does something impressive. That means local models where local models make sense. It means private deployments for sensitive workflows. It means retrieval systems that respect permissions. It means agents with narrow tools, not universal keys. It means human approval for irreversible actions. It means logs that explain not just the final answer but the sources, steps, and permissions behind it. It means treating the AI less like a mystical oracle and more like a very capable employee who should still not be allowed to approve its own expense reports.

The metaphor is imperfect, but useful: AI is the intern.

The intern is brilliant. The intern is fast. The intern can read every manual, compare every contract, draft every email, and remember the obscure policy from 2019 that everyone else forgot. You want the intern. The intern is going to save time, find patterns, reduce drudgery, and occasionally make a senior employee feel threatened in a way that will be described as “workflow transformation.” But you need to manage the intern.

You do not let the intern take home the customer database. You do not let the intern accept instructions from a random PDF. You do not let the intern email clients without review, merge code without tests, change bank details without approval, or decide that the most recent document is automatically the most authoritative one because it used confident language. You give the intern a desk. You give it rules. You give it access to the things it needs and not the things it does not. You watch what it does. You correct it. You make sure it can explain itself. You keep it inside the building.

That is the promise of private AI. Not that it makes AI harmless. Nothing useful is harmless. A hammer is not harmless. A spreadsheet is not harmless. A junior banker with Excel and two hours of sleep is definitely not harmless.

The promise is that private AI makes AI governable.

And governable AI is the kind people can actually use.