Why this lesson exists. Part A ended with you saving company context into a skill. Part B is about building a proper home for that context, shared across the team. Before you build it, you need to know what must never go in, because the damage from getting this wrong is far greater than the benefit of getting the rest right. So the warning comes first.
By the end of this lesson you will be able to decide what belongs in a shared knowledge base and what does not, because you will have seen what happens when the line is crossed and then drawn the line yourself on real examples.
This is an anonymised composite; every element of it has happened to real companies.
A professional-services firm built a shared knowledge base to help its team write better client outreach. It was a sensible idea, and it worked: the drafts got sharper and more personal. Somewhere along the way, someone had the further idea of including detailed client notes, on the grounds that more context meant better emails. However, a blind dump of internal client notes included: Which clients were in financial difficulty. Who was mid-restructuring. Details of a clients security vulnerabilities. A director's health issue that had delayed a project. Internal remarks about which contacts were "difficult".
The AI did exactly what it was asked. It wrote warm, highly personalised outreach. One email went to a prospect at a company that happened to share a board member with an existing client, and it mentioned, helpfully, that clients issues, and how they managed to deliver the project against all odds. Which it then proceeded to outlined the private details such as health issues and key contacts that were difficult to work with, but they persevered... The prospect forwarded it to the board member. The firm lost the client, received a data-protection complaint, and had to explain to its regulator how confidential client information had ended up in a marketing email.
Nobody had acted maliciously. The model was not at fault. The information simply should never have been somewhere the model could read it. The knowledge base had been treated as a private notebook when it was, in effect, a shared drive with an eloquent writer attached to it.
The public, non-composite version of this pattern: in 2023, engineers at a large electronics manufacturer pasted confidential source code into a public chatbot to get help debugging it, and the company subsequently banned the tool company-wide. Same lesson, different data.
Anything in a shared knowledge base can appear in an output. Not "might". Assume it will, at some point, in front of someone you did not intend. This follows directly from Lesson 1: the model works from what it can see, and it does not distinguish "background I was given" from "material I may quote". So the test for including something is not "is this useful?" but "would I be comfortable with this appearing in an email to a stranger?"
Applied, that rules out five categories:
Personal data about clients or their customers beyond what the job needs. No home addresses, health details, financial circumstances, personal remarks. If you would not put it in a CRM field a new hire can read, it does not go here.
Credentials. No passwords, API keys, bank details. Ever, including "just for this one skill".
Confidential material belonging to others. Client contracts, their internal documents, anything under NDA.
Unverified claims. Because the model repeats what it reads with total confidence, a guess written as a fact becomes a fact in every output. Mark uncertainty as uncertainty.
Anything you would not want quoted back to you. Internal opinions about people, "the real reason we lost that deal", pricing you have not decided to publish.
The other side of the rule is what does belong, which is the next lesson: how you describe yourselves, what you sell, who you sell to, how you sound, how you work, what you have decided. Public-facing or would-be-fine-if-public.
