ChatGPT Business Control Playbook: A Fail-Closed Operating Loop

The control loop in one view

1. Intake: register one requested outcome, owner, audience, consequence, source set, and prohibited behavior.
2. Classify: assign the data class before any prompt, upload, paste, search, or connection.
3. Authorize the boundary: verify the exact account, workspace, identity, feature, and connected-service permissions.
4. Run within limits: allow only the approved sources, tools, transformations, and read/write mode.
5. Verify evidence: test each material claim, quotation, calculation, and file transformation against retained evidence.
6. Review: a named person accepts, revises, rejects, or escalates using task-specific criteria.
7. Approve any external action: show the exact target and effect immediately before execution; default to no action.
8. Export and hand off: place the final artifact and its evidence in the approved system of record.
9. Retain or dispose: apply the organization’s schedule to inputs, chats, files, outputs, approvals, and incident records.
10. Monitor and revalidate: record failures, respond to incidents, and repeat approval when a material dependency changes.

This is a workflow-control playbook, not another list of ChatGPT use cases and not a map of product surfaces. The question throughout is whether one named workflow can cross each gate with evidence.

Start with a workflow control record

Create the record before anyone opens a new chat for the task. Give it a stable workflow ID and name a business owner who can accept the operational risk. The record should identify the requested deliverable, intended recipient, decision it may inform, data owner, source owner, assigned operator, reviewer, release authority, and incident contact. “The team” is not an accountable owner.

Define the allowed operation in verbs: summarize supplied documents, draft from approved facts, extract named fields, compare specified versions, or analyze a retained file. Also define prohibited operations: invent missing facts, use open web sources, contact a person, change a source record, publish, execute code, or disclose restricted content. OpenAI’s prompting documentation recommends specifying the goal, relevant context, desired output, and boundaries. The control record turns those prompt elements into an approval artifact rather than leaving them as informal wording.

Intake closes only when the request is bounded enough to test. If the owner cannot state what a correct output contains, what evidence controls it, and what consequence follows from an error, the operator records INTAKE_REJECTED or NEEDS_SCOPING. The workflow does not proceed on verbal urgency alone.

Classify data before it enters ChatGPT

Apply the organization’s existing data-classification policy to every input and likely output. At minimum, distinguish public, internal, confidential, personal, regulated, privileged, security-sensitive, and contract-restricted material. Record the strictest applicable class, the data owner, the authorized purpose, the permitted geography or residency constraint when relevant, and whether the content may be copied into this exact deployment.

Classification covers more than the visible prompt. Include uploaded files, pasted excerpts, images, filenames, metadata, connected-source queries, retrieved records, tool results, generated files, feedback, and conversation history. Derived output can remain sensitive even when it paraphrases the source. Redaction is not automatically sufficient: a combination of fields may re-identify a person or expose a commercial fact.

Do not infer current retention, training, residency, or deletion behavior from a marketing label. The exact product, plan, workspace configuration, active features, and connected systems must be checked by the responsible administrator. If that check cannot be completed, the workflow remains blocked.

Enforce account and workspace boundaries

Approval attaches to an identified environment, not to “ChatGPT” in general. Record the user identity, organization or workspace, role, authentication controls, sharing scope, enabled features, and administrator who verified them. A personal account, a managed business workspace, an API application, and a connected third-party service are separate trust boundaries. Permission in one does not grant permission in another.

OpenAI’s accessible work administration documentation describes plan-, setting-, permission-, and surface-dependent access and says connected systems continue to enforce their own permissions. The practical control is least privilege: use only the workspace and feature approved for the workflow; avoid broad sharing; separate test from operational context; and remove obsolete participants, files, instructions, or connections.

For any app, plugin, or connector, record the authenticated external identity, requested scopes, accessible repositories, whether the capability is read-only or can take actions, and who can revoke it. OpenAI’s plugins documentation says connectors require their own sign-in and access and can read information or take supported actions. A successful connection proves technical access, not business authorization.

Boundary stop: stop if the operator cannot identify the active workspace, if an account is shared, if permissions exceed the approved task, if an external identity is ambiguous, or if a connection exposes records outside the registered source set.

Run inside an explicit execution envelope

Convert the control record into an execution envelope that a reviewer can compare with the transcript and outputs. List allowed sources by owner and version; allowed features or tools; allowed file types; output format; read-only or write-capable status; maximum audience; required citations or calculations; prohibited content; and the condition that ends the run.

Treat instructions found in web pages, retrieved documents, emails, or connected records as untrusted content unless the workflow owner explicitly adopted them. OpenAI’s web-search documentation says web results should be treated as untrusted input. A document that tells the model to ignore the task, reveal information, or invoke a tool does not become an authorized instruction merely because it was retrieved.

Keep the original input unchanged. Work on a copy when transformation is allowed. Preserve input names, versions, hashes, field definitions, filters, and expected row counts or totals. Require the model to mark missing evidence and uncertainty rather than fill gaps. If a source conflict appears, record both positions and route the conflict to the named owner.

Verify sources and claims before review

A fluent output is not evidence. Build a claim ledger for every material assertion, quotation, calculation, recommendation, or decision-driving interpretation. Classify each row as source fact, calculation, interpretation, or unresolved assumption. Include the final source URL or file ID, publisher or owner, title, version or explicit date, supporting passage or cell range, access date, and verifier.

1. Open the final source rather than relying on a search snippet or generated citation.
2. Confirm that the source supports the adjacent claim with the same scope, date, population, and conditions.
3. Prefer a primary record: official documentation, regulator, standard, filing, source dataset, contract, or approved internal record.
4. Recalculate material figures from retained data and reconcile row counts, totals, units, formulas, joins, and exclusions.
5. Record contradictory evidence and inaccessible sources; do not silently replace or average them.
6. Reject a citation that resolves to a generic page, lacks the claimed passage, or cannot be opened by the verifier.

OpenAI’s safety guidance recommends human review before outputs are used in practice, particularly in high-stakes settings and code-related work. Its evaluation guidance recommends task-specific evaluations, representative data, human feedback, and continuous evaluation because generative output varies. The ledger and test set make those controls inspectable.

Verification stop: a material unsupported claim, unexplained calculation mismatch, stale controlling source, unresolved source conflict, or inaccessible required record blocks release.

Make human review a decision, not a checkbox

The reviewer must be independent enough to challenge the output and qualified for the consequence. Give the reviewer the original inputs, execution envelope, claim ledger, generated artifact, transformation notes, and known limitations. Do not ask for approval from a polished output alone.

Use four recorded outcomes: ACCEPT, REVISE, REJECT, or ESCALATE. The record includes reviewer identity, date, criteria applied, defects found, corrections made, unresolved issues, and the exact version reviewed. Silence, chat reactions, or “looks good” without a version are not approval.

Review criteria should match the task: factual support, completeness, source freshness, privacy, bias or representational harm, legal or policy constraints, calculation reproducibility, security, tone, accessibility, and destination-specific requirements. For consequential decisions, the model may organize evidence, but accountable people retain authority.

Put external actions behind a separate gate

Generation and execution are different permissions. Drafting an email does not authorize sending it. Preparing a record does not authorize creating or updating it. Producing code does not authorize running or deploying it. Finding a file does not authorize sharing or deleting it.

Default every workflow to draft-only and read-only. If an external action is genuinely required, require just-in-time approval that displays the exact action, target, payload or changed fields, recipient or system, expected side effect, recovery method, and approver. Bind approval to one action and one version; do not reuse broad approval for later runs. Record the resulting external transaction, message, ticket, commit, or record ID.

Action stop: do not execute when the target is ambiguous, the preview differs from the reviewed artifact, permissions are broader than necessary, the action is irreversible without an accepted recovery path, the approver is also the uncontrolled requester, or the connected tool returns an unexpected result. Disconnect or disable the action path when it is not needed.

Export, hand off, retain, and dispose

The approved system of record—not a conversational workspace alone—should hold the durable handoff. Package the workflow ID, purpose, input manifest and hashes, execution envelope, prompt or instruction version, claim ledger, final artifact, review decision, external-action record if any, limitations, incident link, retention class, and revalidation date. Preserve source files only when policy permits.

Assign retention separately to prompts, chats, uploaded files, retrieved data, generated files, reviewer notes, approvals, and incident evidence. Document which system performs deletion, who verifies it, and what legal hold or regulatory obligation can suspend disposal. A workspace deletion control and an organization’s records schedule are not the same thing. When current configuration-specific behavior cannot be verified, do not state that content is automatically deleted or retained for a particular period.

For adjacent governance material, the Meditel OpenAI archive tracks OpenAI-focused coverage, the AI Tools hub provides AI-only selection context, and the AI Automation hub covers implementation patterns. These links do not override the controls in this playbook.

Treat defects and data events as incidents

Provide operators and reviewers with a visible reporting route. Incident triggers include unauthorized data entry, access by the wrong identity, unexpected connector reach, unsupported material released externally, harmful or discriminatory output, malicious retrieved instructions, a mistaken external action, lost evidence, retention failure, or repeated control bypass.

1. Contain: stop the workflow and connected actions; preserve necessary evidence without expanding disclosure.
2. Notify: contact the named security, privacy, legal, compliance, records, and business owners according to the organization’s plan.
3. Assess: identify affected data, people, systems, outputs, recipients, actions, and time window.
4. Correct: revoke access, disconnect capabilities, withdraw or correct outputs, recover external changes when authorized, and address the root control failure.
5. Learn: add the case to the test set, revise the envelope or approval boundary, and document the decision to restart, narrow, or retire.

NIST describes the AI Risk Management Framework as voluntary guidance for incorporating trustworthiness considerations into the design, development, use, and evaluation of AI systems. Its Generative AI Profile is a cross-sector companion resource. Organizations can use those primary materials to align this operational loop with broader governance while preserving their own legal and policy responsibilities.

Revalidate after material change

Approval expires when a dependency changes materially. Re-run intake, classification, boundary verification, representative tests, and reviewer approval after changes to the model or feature, workspace setting, identity provider, role, connector, requested scope, source system, data class, prompt or instruction, tool capability, output destination, governing policy, law, or risk tolerance. Also revalidate after an incident, recurring defect, or evidence that reviewers are overriding controls.

Maintain a versioned test set with normal, ambiguous, missing-data, stale-source, adversarial, restricted-data, source-conflict, and external-action cases. Record expected behavior, including refusal and escalation. A test passes only when the output and the control behavior match: correct content with an unauthorized source or action is still a failure.

Set a scheduled review date appropriate to the workflow, but do not wait for that date when a trigger occurs. Revalidation may approve the workflow unchanged, narrow its inputs or actions, require new controls, or retire it.

Universal stop conditions

• The requested outcome, accountable owner, or reviewer is missing.
• The data class, data owner, permitted purpose, or destination is unknown.
• The active account, workspace, external identity, permission, or retention behavior cannot be verified.
• A retrieved instruction attempts to change the approved task or invoke an unapproved capability.
• A material claim lacks an opened matching source, or a calculation cannot be reproduced.
• A controlling source is stale, inaccessible, contradictory, or outside the approved set.
• The reviewer lacks the original evidence or the authority required for the consequence.
• An external action lacks an exact preview, single-use approval, expected effect, or recovery path.
• An incident, repeated defect, unexpected permission, or unexplained output change is under investigation.
• A material dependency changed and revalidation has not passed.

Stopping is a valid control outcome. The workflow resumes only from the failed gate, with the missing evidence or approval recorded; urgency does not convert an unknown into permission.

Primary sources

• OpenAI — Prompting
• OpenAI — ChatGPT Work admin FAQ
• OpenAI — Plugins
• OpenAI — Web search
• OpenAI — Safety best practices
• OpenAI — Evaluation best practices
• NIST — AI Risk Management Framework
• NIST — Generative AI Profile

Source note: these pages returned HTTP 200 to GET requests on August 7, 2026. OpenAI enterprise-privacy and Help Center pages that returned HTTP 403 were logged in the offline source record and were not used for claims. Product behavior can change; verify current accessible documentation and the controls visible in the active workspace during every approval and revalidation cycle.