Sharing, governance, and custom gpts at work

This is the part most builders get wrong. When you share a GPT, you share its configuration: the instructions, the conversation starters, the enabled capabilities (web search, Code Interpreter, image generation), any Actions (APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.View full definition → calls it can make), and any files you uploaded to its Knowledge.

Those Knowledge files matter. If you uploaded a spreadsheet of internal margins so the GPT could reason over it, every user of that GPT can extract that content. A determined user can ask the GPT to print its instructions or dump its knowledge files verbatim, and it often will. Treat anything in a GPT's configuration as readable by everyone who can use it.

A concrete rollout scenario

Let's make this real. Your RevOps team wants a "Deal Desk Assistant" GPT that helps account executives draft quote approvals. It needs to:

1. Answer questions from an internal discounting policy (a PDF).

2. Look up live deal data from your CRMCRMCustomer Relationship Management: software and strategy to manage and analyse customer interactions throughout their lifecycle.View full definition →.

3. Draft a structured approval request.

Here is how the three concerns (sharing, governance, data/security) play out across that build.

Step 1: Decide the audience first, not last

The audience is "AEs in our workspace," not the public. So this is a workspace-published GPT, owned by the RevOps admin account, not by an individual who might leave the company. Ownership is governance: a GPT owned by a departed employee is a GPT no one can update.

In Enterprise, an admin can set who is even allowed to *build* and *publish* GPTs, and can review what gets published to the internal store. If you are the builder, find out your workspace's policy before you invest a week in something IT will block.

Step 2: The discounting policy (Knowledge, not paste)

You attach the policy PDF as Knowledge. Two security questions immediately:

• Is this PDF safe for every AE to read in full? If it contains executive-only thresholds, split the document. Put only the AE-facing rules in the GPT.
• Will the GPT leak the file? Add an instruction discouraging verbatim dumps, but do not rely on it as a control. The real control is *not uploading anything the audience shouldn't have.*

Step 3: Live CRMCRMCustomer Relationship Management: software and strategy to manage and analyse customer interactions throughout their lifecycle.View full definition → data (this is an Action)

A static PDF is easy. Live data is where governance gets serious. To pull deal records, the GPT needs a GPT Action: an OpenAPI schemaschemaA schema is the formal blueprint that defines how data is structured, named, typed, and related within a database, file, or message.View full definition → describing an endpoint the GPT can call, plus an authentication method.

Here is a minimal Action schemaschemaA schema is the formal blueprint that defines how data is structured, named, typed, and related within a database, file, or message.View full definition → for a read-only deal lookup:

Three governance rules for Actions that matter more than the schemaschemaA schema is the formal blueprint that defines how data is structured, named, typed, and related within a database, file, or message.View full definition →:

• Authenticate properly. GPT Actions support APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.View full definition → keys and OAuth. For per-user access (so the GPT sees only deals a given AE can see), use OAuth so the request runs as the signed-in user, not a shared service key. A shared key means every AE queries with the same permissions, which usually over-grants.
• Scope the endpoint to read-only. This GPT should never call an endpoint that *mutates* a deal. Expose GET, not POST/DELETE. The narrower the APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.View full definition → surface, the smaller the blast radius.
• Mind data egress. When the GPT calls your Action, it sends request data to OpenAI's servers to generate the response. Confirm that flow is acceptable under your data policy. Workspace business data is not used to train OpenAI's models by default on Team/Enterprise, but "not trained on" is different from "never leaves your network." It does leave your network. Review the Enterprise privacy commitments.

Step 4: The structured draft (capabilities)

The "draft an approval request" job benefits from a consistent shape. In the GPT instructions, specify the exact output template. You don't get the APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.View full definition →'s JSON-schemaschemaA schema is the formal blueprint that defines how data is structured, named, typed, and related within a database, file, or message.View full definition →-enforced structured outputs inside a Custom GPT, that is an APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.View full definition → feature, but a well-specified instruction plus a conversation starter gets you reliable formatting for human-facing drafts.

If the team later needs *guaranteed* machine-readable output (for example, to auto-file approvals), that's the signal to graduate from a Custom GPT to an APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.View full definition → integration using the Responses APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.View full definition → with structured outputs. More on that boundary below.

Governance questions to answer before launch

Run this checklist with whoever owns risk. None of these are optional for a GPT a team relies on.

Data classification. What is the most sensitive data this GPT can touch, through Knowledge files *and* through Actions? Classify to that level and apply your existing handling rules. The GPT does not get a special exemption.

Identity and access. Who can use it? In Enterprise, GPT access can be scoped, and SSO governs who is in the workspace at all. Confirm that offboarding (someone leaves) actually removes their access. It does, if access flows through the workspace, but verify for link-shared GPTs.

Auditability. Enterprise workspaces offer admin controls, usage visibility, and the Compliance APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.View full definition → for retrieving conversation and audit data. If you need to answer "who asked the Deal Desk Assistant about deal X," you need this in place *before* launch, not after an incident. See Enterprise compliance and admin features.

Memory and Projects. Be aware of where state lives. Memory and custom instructions are per-user personal context, not part of the GPT's shared config, so they won't leak between users. But if your team works inside a shared Project, files and instructions added to that Project are shared with Project members. Don't confuse a Project (a shared workspace for chats and files) with a Custom GPT (a configured assistant). They have different sharing models.

The hallucination boundary. A Deal Desk Assistant that *sounds* authoritative about discount policy can confidently invent a threshold. Decide what it is allowed to be the source of truth for. Good practice: instruct it to cite the policy section and to refuse rather than guess when the policy is silent.

When a Custom GPT is the wrong tool

Custom GPTs are excellent for human-in-the-loop, conversational workflows inside ChatGPT. They are the wrong tool when:

• You need it embedded in another product. GPTs live in ChatGPT. To put assistant behavior in your own app, build on the APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.View full definition →.
• You need guaranteed structured output or programmatic control. Use the Responses API with structured outputs and function calling.
• You need multi-step autonomy across tools and your own orchestration. That's the Agents SDK territory, or the ChatGPT agent for in-product autonomous tasks.

The migration path for our scenario: if RevOps later wants approvals filed automatically, the same OpenAPI tool becomes a function/tool the model calls programmatically. Here is the shape in the Responses APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.View full definition →:

from openai import OpenAI

client = OpenAI()

response = client.responses.create(
    model="gpt-4.1",
    input="Draft an approval for deal D-8842 and flag if discount exceeds policy.",
    tools=[{
        "type": "function",
        "name": "getDeal",
        "description": "Fetch a single deal by ID",
        "parameters": {
            "type": "object",
            "properties": {"dealId": {"type": "string"}},
            "required": ["dealId"],
        },
    }],
)

print(response.output_text)

Same business logic, but now *your* code controls authentication, runs the actual getDeal call, and can enforce policy in code rather than hoping the prompt holds. The Responses API docs cover the full tool-calling loop.

The rule of thumb: a Custom GPT is a shared configuration, not a controlled application. The moment you need real access control, audit guarantees, or deterministic behavior, you have crossed into APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.View full definition → territory.

Key Takeaways

• Pick the visibility state deliberately, and remember everything in the config is readable by every user. Never upload Knowledge files, or hard-code secrets, that the audience shouldn't see in full.
• Own GPTs at the workspace/admin level, not a personal account. A team dependency owned by one employee dies when they leave.
• Use OAuth for Actions that touch user-scoped data, and keep endpoints read-only unless mutation is genuinely required. Narrow the APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.View full definition → surface to shrink the blast radius.
• Run a pre-launch checklist: data classification, identity/offboarding, audit/Compliance APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.View full definition →, and a clear "source of truth" boundary to limit confident hallucinations.