A shared AI memory is a new leak unless you scope it

We spend a lot of time arguing that firms should give their AI a shared, written memory of how the company works. So we should be the first to say it: done carelessly, that memory makes your security worse.

Think about what goes into it. Client names. Prices and margins. Who approves what. Notes on deals in progress. Which supplier is unreliable. A good company memory is, more or less by definition, a concentrated copy of the things you would least like to see leave the building. Every AI session that can read it is a new way for it to leave.

The numbers on the problem you already have

IBM's 2025 Cost of a Data Breach report gave AI a section of its own. Shadow AI, meaning staff using AI tools the company has not approved or cannot see, was involved in 20% of the breaches studied and added about USD 670,000 to the average cost of a breach. 63% of the organisations studied had no AI governance policy.

Those figures describe firms where data is already flowing into AI tools with no structure at all. A shared memory can reduce that, by giving people an approved place to work. It can also add a new, richer target. Which one you get depends on design.

Five rules we hold ourselves to

1. Scope memory by company and by client. One memory for everything is the easiest to build and the worst to run. At Provecta Group the rules start with naming which company a task belongs to, each company has its own channels and its own files, and records stay with the company they belong to. If you serve clients, the same logic applies one level down: a session working on client A should not be able to read client B's notes.

2. Keep secrets out entirely. Passwords, API keys, bank details and access tokens never go into memory. Memory is meant to be read by many sessions and often by more than one AI provider. Anything in it should be safe to show a careful new hire on day one. Secrets live in a proper secrets store, and the memory only says where to ask.

3. Decide who can read and who can write. Reading and changing the memory are different permissions. Many people may need the first. Few need the second. An AI agent that can rewrite the rules it is supposed to follow is a design flaw.

4. Keep the history. Every change to the memory should be recorded: what changed, when, and on whose instruction. That is how you find out how a wrong fact got in, and how you undo it. A memory you cannot audit is a liability you cannot measure.

5. Plan for deletion. If the memory holds personal data about clients, staff or prospects, data protection law applies to it like any other record. In Kenya that means the Data Protection Act, 2019. In Europe, GDPR. Decide what is kept, for how long, and how a person's data is removed when they ask.

What none of this does

These rules make a memory safer to have. They do not stop a staff member pasting a client file into a personal chatbot. They do not replace access control on your email, your drive or your accounting system. And they do not make a vendor's handling of your data any better than its contract says it is. Read the data terms of every AI tool that will touch the memory, and keep a list of which providers see what.

There is a plain trade-off underneath this. The more of the company's knowledge you put in one place, the more useful the AI gets, and the more that place needs guarding. We think the trade is worth it. We would not make it without the five rules above.

This week

Open whatever you already use as shared AI instructions, whether a custom GPT, a project file or a pinned document, and read it as an attacker would. Is there a password in it? A client's personal details? Notes from one client sitting in a file another client's work can see? Take those out first.

To check how your AI use holds up on data handling, start with the AI readiness check, then book 20 minutes at pgco.world/book.