Knowledge Engineering · Access

You Keep Every Client's Data Apart. Your AI Doesn't.

You run one shared AI across every client, team, and business unit, and it indexes everything they hold into one shared pile. So a single question from client B can pull client A's data into the answer. Why? Because the walls you enforce everywhere else stop at the AI. A governed data layer puts the wall back: it checks who is asking before the AI retrieves a single document, so each request reaches only the data its asker is allowed to see.

Infozense Knowledge Engineering · CIO · CISO · GRC · Head of Data · ~5 minutes

This is the Access piece of the Infozense Knowledge Engineering library. The data layer beneath your agent has five gates: Input (who may ask) · Egress (what may leave) · Output (safe and true) · Action (who approves) · Operational (prove it later). This piece is about the first one: Input, the gate that decides who is allowed to ask, and for whose data.

Before the governed layer: client B asks one question, one AI ranks a single shared index holding every client's documents with nothing checking who is asking, and the answer returned to client B contains client A's data.
No gate. The index ranks by relevance, and relevance does not know who is asking.

You do not let one client see another client's files. You do not let one business unit read another's. Your applications enforce it, your databases enforce it, your file permissions enforce it. Keeping those worlds apart is not a nice-to-have. It is the job.

Then you build one AI across all of them. One deployment, one index, one model, because standing up a separate AI for every client would be absurd. That is efficient, and it is the right call.

But a shared AI over separated data is only as separated as the AI makes it. By default, it makes it not separated at all. It indexes everything into one pile and retrieves by relevance. Ask it a question, and it can pull a passage from any client's data into the answer, and hand it to whoever asked. The walls you enforce everywhere else stop at the AI.

One question from client B, and client A's data is in the answer. That is not a flaw in the model. It is the absence of a gate.

Who this is for

Most organizations do not have this problem, because their AI serves one audience over one body of data. If everyone who can ask your AI is allowed to see everything it holds, you can stop here.

You have this problem when one AI serves groups that must not see each other's data. Clients on a shared platform. Business units under one roof. Tenants of a service you operate. Cases, accounts, or patients that belong to different owners. If a leak between any two of them would be a reportable event, your AI is now part of the isolation boundary, whether you designed it to be or not.

What isolation actually requires

Real isolation across a shared AI has to do one thing a shared index does not: it has to know who is asking before it decides what to retrieve.

A shared index ranks by relevance. Relevance does not know who you are or what you are cleared to see. So the passage most relevant to client B's question might be a document that belongs to client A, and a system that ranks by relevance alone will serve it up. The check for who is asking has to come first, before retrieval, not after the answer is already written.

How the governed layer does it

After the governed layer: client B's request carries its identity, the Input gate pins the request to B's workspace before retrieval, only workspace B is searched, and the answer returned to client B contains only B's data.
The check on who is asking runs before retrieval, so the search never leaves the asker's Workspace.

In a governed data layer, every piece of knowledge belongs to a workspace. The workspace is the wall. One client, one business unit, one tenant: whatever must be kept apart gets its own.

Every request carries who is asking, and that identity is pinned to a workspace. Before the AI retrieves a single document, the Input gate confines the search to the asker's workspace. Client B's question can only ever reach client B's data. There is no shared pile to rank across, and no field in the request a caller can change to reach another workspace's data. Name a workspace that is not yours, and you simply do not get it.

One AI still serves all of them. One deployment, one model, one operations team. But each request runs inside its own wall, and the walls do not move.

The bottom line

A shared AI is not a shortcut around isolation. It is a new place isolation has to hold. Without a gate that checks who is asking before it retrieves, your one convenient AI is one question away from handing the wrong person another client's data. With one, the same AI serves everyone and reaches only what each asker is entitled to. The wall you keep everywhere else finally extends to the AI.

You don't build this. You configure it.

Per-tenant isolation across an AI sounds like a security project. It is not, because you do not build the enforcement. Infozense Knowledge Engineering ships the governed layer with the workspace as the boundary and the Input gate already in place. You put each client, unit, or tenant in its own workspace and pin each key to it. From the first request, the AI reaches only what its asker is allowed to, and a request that names another workspace does not get it.

That is the difference between one AI you hope is isolated and one AI that is.

Infozense Knowledge Engineering

Running one AI across clients or units that must never see each other's data?

That's the conversation we have best. Bring one real setup, and we'll walk through where the wall has to hold.

Let's talk →

contact@infozense.com  |  +66-82-242-4008  |  Bangkok, Thailand