The Keys to the Building

A new finance director starts on Monday. You give her one key. It opens the stationery cupboard. On Friday you ask her why margins fell last quarter. She will give you an answer. It will be confident, articulate and wrong.

No board would treat a senior hire this way. Yet this is how most organisations are deploying AI. It is connected to the document library, perhaps the CRM, and then asked questions whose answers sit elsewhere.

AI multiplies what it is given. Given a fraction of the organisation, it does not report that it sees a fraction. It answers from the fraction, with the same fluency it would bring to the whole. Partial access does not produce partial answers. It produces wrong answers that look complete.

The argument of this piece is simple. AI must be given the keys to the building. Whoever hands over those keys must answer for every door they open.

Three facts make partial access untenable.

The knowledge is in the corridors, not the rooms. No single system explains why the business works as it does. The explanation is spread across email, tickets, change logs, contracts, meeting notes and spreadsheets on individual desktops. The value lies in the connections: the contract clause that explains the exception in the code, which explains the batch job that runs at 02:17. AI is good at joining these. It can only join what it can reach.

The oldest rooms hold the most. In many enterprises the core records and business rules sit in mainframe and midrange systems, reached through green screens with no modern interface. If AI can read the document library but not the mainframe, it learns the company's paperwork, not the company. Emulation is the door to these rooms. It belongs in the plan from the start, not as an afterthought.

The staff have already copied the keys. Microsoft and LinkedIn's 2024 Work Trend Index found that 78% of AI users bring their own AI tools to work. The survey covered 31,000 people across 31 countries. More than half of AI users (52%) are reluctant to admit using it for their most important tasks. Microsoft notes that this habit puts company data at risk. Contracts, customer records and source code are already passing through tools nobody approved. Withholding data from governed AI does not keep it from AI. It sends it to AI you cannot see. Refusal is also a decision, and it has an owner.

Handing over keys is not abdication. A building manager who issues keys keeps a register, decides which doors each key opens, and changes the locks when someone leaves. The same discipline applies to AI. It rests on six duties, and each needs a named owner.

Access follows the person. AI should see what the person asking is entitled to see, and no more. If a junior analyst cannot open the board papers, the AI must not summarise them for her. The requirement is permission-aware retrieval, not one model holding a master key.

Reading, drafting and acting are separate keys. Reading carries one level of risk. Drafting carries another. Acting, such as updating a record, sending a message or committing a transaction, carries a third. Each step up needs a named approver.

The source must be right. AI repeats errors faster and more convincingly than any person. Someone must own the correction of the source data, not merely the answers drawn from it.

The supplier must be known. Where the data is processed, how long it is kept, and whether it trains anyone else's model are contract questions. They have answers. Someone must have read them.

The law still applies. UK GDPR requires personal data to be collected for specified purposes and limited to what is necessary. The ICO sets these out as the purpose limitation and data minimisation principles. There is a genuine tension between giving AI the whole building and using only what a purpose requires. The responsible organisation names that tension and resolves it use by use, with an impact assessment where the risk is high. It does not pretend the tension is absent. The law also places the burden of proof on the organisation: it must be able to demonstrate compliance, not merely assert it. The ICO calls this the accountability principle.

Every door opened is recorded. Each query and each action should trace to a person, a purpose and a result.

Broad access brings real risks. They are managed by design, not by hope.

Blast radius. The more one system can reach, the more one failure exposes. Concentration is a risk in its own right. AI service accounts should be treated as privileged accounts: segmented, monitored and reviewed.

The lethal trifecta. The security researcher Simon Willison has named the most serious technical risk. He calls it the lethal trifecta. An AI agent that combines access to private data, exposure to untrusted content and the ability to communicate externally can be tricked into sending that data to an attacker. The untrusted content may be an inbound email, a web page or a supplier's document. Instructions hidden inside it are read as instructions. Willison's conclusion is that once organisations combine tools themselves, the vendors cannot protect them: "The LLM vendors are not going to save us!" The combination must be avoided by design. In practice that means three rules:

The agent that reads private data is not the agent that reads the outside world.

Read-only is the default.

A person approves anything that leaves the building.

People. Staff may reasonably object to their email and messages being searchable by a machine. Tell them what is indexed, why, and who can see the results. Trust is easier to keep than to rebuild.

The question is not whether AI should see your data. It already sees some of it, through tools you approved and tools you did not. The question is whether anyone in your organisation can say today what AI can reach, what it can do, and why.

If no one can, that is the first task. It belongs to the board, not the IT department. Within the next 90 days:

The board names one accountable executive for AI access to company data, with authority across every department's systems.

That executive publishes an access register: each AI system, the data it reaches, the actions it may take, and the named approver for each.

The CIO maps the estate, including legacy systems reached only through emulation, and identifies where critical knowledge is held but cannot yet be reached.

The security lead audits every agent for the lethal trifecta and breaks the combination wherever it is found.

The data protection officer completes impact assessments for each high-risk use before its access is widened.

HR tells staff what is indexed and why, and gives them an approved tool that is better than the one they brought from home.

If those six names cannot be written down by the end of the quarter, the organisation is not ready to widen AI's access. It is also not safe to leave it as it is.

The register is not only a matter for the board. It matters to everyone who asks AI a question and acts on the reply.

An answer is only as reliable as the evidence behind it. A person who knows which rooms the AI could enter can judge how far to trust what it says. A person who does not know cannot. They have no way to tell a reply drawn from the whole building from one drawn from the stationery cupboard. Both arrive in the same assured tone.

That is the personal impact. If you do not know what AI has access to, you cannot calibrate the veracity of its answer. You inherit its confidence without its evidence, and when you act on it, the decision is yours, not the machine's.

So the discipline ends with each of us. Before you rely on an answer, ask what it could see. If no one can tell you, treat the answer as a draft, not a fact.

AI will always give you an answer. It will be confident, articulate, and it may be wrong. Knowing which is your responsibility.