You want the newest AI models. The customer data can't leave.

Security asks which server the data goes to
A sales rep pastes a customer list into an AI and asks it to tidy things up. When a company evaluates business AI, this is the scene the security team asks about first: "When an employee asks a question, which company's server do the question and our data end up on?" If the only answer is "the AI vendor's servers," the review tends to stop there. Insist that "nothing ever leaves," though, and you give up what the newest AI models can do.
In OwlAI, two things decide which server the data goes to: the AI models your company connects, and an "Internal models only" label on each data source. A customer database labeled "Internal models only" never appears in a conversation that started with an external model. That lets you hand public material to the newest external models while customer data stays inside your network.
Public material and the customer database need different rules
Data sensitivity varies from task to task. If summarizing public market research and querying a database of customers' personal information fall under one rule, you can only send both out or block both. What you need is a setup in which your company decides which data may go to which AI.
Your company decides which models to connect
In the on-premises edition, your company decides at installation which model servers to connect. Connect only models running on your own GPU servers, and questions and data do not leave the company. To use an external AI vendor's models as well, register that vendor's key. Each model has an enable switch, and only enabled models appear as choices in chat, meetings, and playbooks. You can also set a default model for each feature.
Even with external models, conversations are not stored on the model vendor's servers. The conversation history stays inside OwlAI, and each request sends only the context it needs.
Data labeled "Internal models only" is invisible to external models
Choosing models is not enough on its own. The same employee summarizes public material in the morning and queries the customer database in the afternoon.
Connected model servers fall into two groups: internal models, where data stays inside the company network, and external models, where it leaves the network. The installation settings decide which servers count as internal, and that cannot be changed on screen during operation. Nobody can accidentally reclassify an external server as internal.
On the data side, the administrator chooses either "All models" or "Internal models only" for each database connection, document collection, and external service connector. If your company has internal models, newly registered data starts as "Internal models only," and you open to external models only the sources that may be opened.
In a conversation started with an external model, a customer database labeled "Internal models only" appears neither in the list nor among the tools the AI can use. The AI does not even know the database exists, so it can't query it, and a stray instruction hidden in a document can't lure it into exposing that data. A conversation started with an internal model, in turn, stays with internal models to the end. Its model list shows only internal models from the start, so a conversation that handled customer data does not switch to an external model midway.
Answers are not the only way data leaves the company. There are two more exits: Excel and Word files the AI creates, and tools that write to external services, such as sending email or commenting in an issue tracker. All three exits have to pass the same checking step before anything leaves. Personal information is masked again there, and tools that write externally go through your company's policy and human approval.
Internal and external models can work side by side
In the on-premises edition, you might keep embeddings for document search (a model that turns documents into numbers so they can be searched) and meeting speech recognition on in-house servers set up at installation, and use external models only for complex analysis questions. The customer database stays "Internal models only," while public material and general documents are open to "All models."
What security teams should check during the review
There are four things for the security team to check during an adoption review.
- Which models to connect, and those vendors' data retention policies
- Which databases and document collections to keep "Internal models only"
- Paths by which data leaves outside AI conversations, such as meeting audio, document search, generated files, and external transfers
- An air-gapped setup, if the network must have no external connections at all
On an air-gapped network, every model runs in-house, and research covers internal databases and documents instead of the web.
What technology solves this?

Engineering Notes · Security and audit
External models never see internal-only data, not even its name
Put a model running inside the customer network and an external API model in one installation, and deciding wh…

Engineering Notes · Conversation engine
OpenAI stores responses by default, so we resend the conversation
The OpenAI Responses API stores every response on the provider's servers unless the request sets store, and th…
More in Security and audit

Insights · Security and audit
AI is sometimes wrong. Can it handle work involving customer data?
AI evaluations for work usually end on the same question: the performance is clear, but can we really trust it with this?

Insights · Security and audit
A hidden line in an email you asked it to summarize. Will the AI obey?
You ask the AI to summarize twenty emails from business partners.

Insights · Security and audit
Masked in chat, do national ID numbers still turn up in Excel?
You ask the AI to analyze customer inquiry data, and its answer prints customer phone numbers verbatim.