Wrong answers, sabotage, and who sees what: how a private AI stays under your control.

The fear under the fear

Wrong answers are the first concern. Underneath is a harder question: will you be responsible for work you did not control? You need to know who can change behavior, whose records can appear, and who approves work before it leaves. Private AI needs answers to all three.

Think about supervising a new associate. You review early work closely. As you see how that person handles a particular task, you change the review. Your AI follows a similar trust ladder. Weeks one and two mean line-by-line review. Weeks three through six shift toward checking sources. Weeks seven through twelve allow spot-checks on workflows with high acceptance, with full review for client-facing work. After ninety days, you decide where review can change.

Wrong answers are a cost problem, not a yes-or-no problem

Your AI will be wrong sometimes. The useful question is how quickly your people can catch and correct it. Every answer drawn from your documents shows the passage it came from. Your retrieval system pulls that passage from the actual file. Your model does not write the source passage. Your reviewer can compare the claim with the evidence.

When your documents do not contain an answer, your AI says ‘I don’t know’ instead of guessing. Work stays inside approved workflows. Requests for tax positions, legal advice, or numbers you did not provide are outside that scope. Nothing reaches a client without approval from your named reviewer.

For the first ninety days, your dashboard records acceptance without correction, per workflow. You get your own number from your own work. That record helps you decide where source review is enough and where full review stays. It does not remove your responsibility for what you send.

A source is a place to check an answer, not proof that a draft interpreted it correctly. Your reviewer checks whether the cited passage supports the statement. The acceptance record separates workflows because confidence in a familiar letter does not establish confidence in a different task. Your review decision follows the work you measured.

What a user can and cannot change

Your people can talk to your AI. Only administrators can change its behavior. Your model keeps no memory from one conversation to the next. Instructions typed in a conversation end when it ends. Lasting changes use your administrator change process. Each version and change is logged.

Retrieved documents are material to summarize or cite, never commands. Hidden instructions in a document do not become authority. The fixed order is system, administrator, user, documents. Every query records who asked, what was retrieved, and what was answered. Your firm sets retention. Attempts to change behavior or reach restricted material are flagged to your administrator even when they return nothing.

Why your AI can only see what you can already open

Every indexed document carries the permissions it has in your systems. For each question, your retrieval layer filters to documents the person asking may open. Only those passages reach your model. This happens before your model sees the material. A clever question cannot reach a document that was never retrieved.

Nothing is indexed until an owner approves the collection and who may see it. That is default deny. Payroll, personnel files, partner compensation, and transaction plans stay out entirely or in restricted collections for named roles. Your AI inherits your existing permissions, including any gaps. Reviewing those permissions comes first.

Conversations and uploads stay in the asking user’s scope. There is no shared memory or shared cache of answers. When your AI connects to another system, it connects as that user with that user’s permissions. It never uses a master credential to reach records on everyone’s behalf.

Why we do not train the model on everything

Your system has two layers. Your model learns how your firm writes from material everyone may see: templates, formats, terminology, and voice. That is how a first draft sounds like your firm. Facts, client specifics, numbers, and prior work are never memorized. Your system looks them up when you ask, from documents you may open, and shows the source.

Training everything into a model would erase the permission boundary. Once information is trained in, there is no permission on it and no way to delete it without retraining. Nothing client-specific or restricted is ever trained into your model.

Facts stay in your index. Updating or removing a document changes the next answer without retraining. A client’s data leaves when their documents do. Your firm can change its source material without rebuilding the model that learned its writing style.

For example, an approved blank letter template can teach format and tone. A client’s completed letter contains facts and prior work. Those belong in permission-filtered retrieval, not model training. The distinction keeps a familiar writing style separate from access to a particular client’s records. It also keeps document removal meaningful after launch.

How it is proven

Before launch, role-based test accounts try to retrieve restricted compensation, personnel files, and transaction plans. The correct result is nothing. The tests and results go into your deployment record. Your firm can inspect what was tested and what happened before approving launch.

The record gives you something specific to review with your administrator. Which collections were approved? Which roles attempted access? What did each test return? These are recorded results for your deployment, not a general promise about private AI.

Model updates follow a controlled process your firm is told about. They are never pushed silently. Your deployment record assigns three responsibilities: your people for what they send, your firm for the configuration it approves, and PrivateStride for your system behaving as that record says. Control remains visible after launch through logged questions, answers, and changes.