ChatGPT Projects for Teams: Set the Boundary

A shared ChatGPT Project keeps chats, files and instructions in one place, which makes it a new access surface that needs an owner, a source scope and an offboarding step.

What a Project is

A Project is a folder inside ChatGPT. It holds a set of chats, a set of uploaded files and a block of instructions that apply to every chat inside it. ChatGPT reads those files and instructions as context, so a Project for "tender responses" can answer with your standard wording and your case studies without anyone pasting them in again.

At the time of writing, Business and Enterprise workspaces can share a Project with named colleagues, and Projects can be set to keep memory inside the Project rather than across the whole account. Both details change between releases, so confirm the current behaviour in the OpenAI Help Centre before you rely on it.

The useful part and the risky part are the same thing. Once three people share a Project, the files in it are effectively a small document library with an AI reading layer, and nobody set it up the way they would set up a SharePoint site.

Where small teams get this wrong

A typical example: a sales lead in a twelve-person firm creates a "Proposals" Project, uploads the full price book, last year's board pack and a folder of client contracts, then shares it with the whole sales team including a contractor. Every question in the Project can now draw on board-level margin data and named client terms. Nobody decided that. It happened because "upload everything" felt efficient.

The second common mistake is treating the instructions block as a security control. "Do not reveal pricing to anyone outside sales" is a prompt, not a permission. Anyone with access to the Project can ask the model to summarise the file directly.

The boundary checklist

Work through these before a Project is shared. Each item takes minutes, and each one removes a real failure.

1. Name one owner. The owner decides what goes in, who is a member and when it closes. Shared things with no owner drift.
2. Write the purpose in the first line of the instructions. "Draft first-response emails for support tickets using the attached tone guide" tells members what the Project is for and tells the owner what does not belong in it.
3. Set the source scope. List the files by name with a version date. Upload approved copies, not the live master. If the price book changes, the owner replaces the file and notes the date.
4. Keep personal data out unless the purpose needs it. Client contracts, HR records and anything with names and addresses need a reason and a workspace with admin controls. A Project on a personal account is not that.
5. Decide the memory setting. If the Project handles one client or one sensitive topic, keep memory inside the Project so it does not leak into everyone's unrelated chats.
6. Match membership to the data. Members should be the people who would be allowed to open the underlying files in SharePoint. A contractor who cannot see the board pack there should not see it here.
7. Treat instructions as guidance, not access control. If some members must not see a file, it goes in a separate Project.
8. Set a refresh date. Stale policy files produce confident wrong answers. Quarterly is enough for most teams.
9. Write the offboarding step. When a member leaves the team, remove them the same day. When the Project ends, export anything worth keeping and delete the Project.
10. Record it. One line in your AI register: name, owner, purpose, data class, members, review date.

Projects, connectors and custom GPTs

These overlap and teams mix them up. A Project holds copies of files you chose. A connector reads live data from SharePoint, Google Drive or another system with the permissions of the person asking, which is broader and harder to reason about. A custom GPT packages instructions and files for reuse, and can be shared more widely than a Project.

For most small-business knowledge work, a Project with hand-picked files is the safest starting point because the scope is visible. If your team has already connected drives, the ChatGPT connectors oversharing audit is the next check to run.

Policy lines to add

You do not need a new policy document. Add these to the existing acceptable-use or AI-use page:

• shared Projects live on the company workspace, never on personal accounts;
• every shared Project has a named owner and a written purpose;
• files in a Project must be documents the members already have access to elsewhere;
• Project instructions are not a control on who can see what;
• leavers are removed from Projects as part of the standard offboarding checklist; and
• the AI register lists every shared Project and its review date.

If you want the register, owners and review cadence set up once and maintained, that is the kind of work an AI governance review is for.

Source basis

• ICO: guidance on AI and data protection
• ICO: a guide to data security
• NCSC: cloud security principles