OpenAI API (GPT-4, GPT-4o) governance guidance

Reviewed 5 October 2026. Aicura is not affiliated with OpenAI.

About OpenAI API (GPT-4, GPT-4o)

The OpenAI API (GPT-4, GPT-4o) gives the organisation’s developers access to OpenAI’s AI for building their own applications, such as chatbots, content generation, summarisation, classification and reasoning. Its reach is whatever teams build with it. A drafting aid sits at one end, classifiers working at volume sit further along and applications that search the web, read files, connect to outside services or run commands through the platform’s built-in tools sit at the far end. Requests leave the organisation and are processed by the vendor, so the value comes from building quickly while keeping sight of what each application sends, what it can do and who answers for it.

Where governance makes the difference

• Applications nobody has registered. Anyone with a key can build on the OpenAI API (GPT-4, GPT-4o). Without a register and an owner for each application, the organisation cannot say what is being sent to the AI or which decisions rest on it.
• Sensitive information leaving in requests. Prompts carry whatever the application puts in them. Without agreed rules on what may be sent and controls that apply them, customer or confidential information can leave in everyday requests and be held under retention settings nobody chose deliberately.
• Outside content steering an application. An application that reads web pages, files or connected services and can call tools may follow instructions hidden in that content, sending data or taking actions its builders never intended.

---

For the executive team

The risk sits in what gets built

The OpenAI API (GPT-4, GPT-4o) is not a single tool with a fixed purpose. Each application built on it brings its own value and its own risks, depending on the information it uses and the decisions it supports. Oversight needs to follow the applications rather than the subscription.

Every application needs an owner

Each application needs a named person accountable for it, a clear purpose, agreed limits on what it may send and do and a clear view of what happens when it gets something wrong.

Spending needs the same discipline as any other cost

Use grows with every request, so cost can rise quickly when a new application takes off or a mistake repeats at volume. Budgets per application, with someone who acts when they are approached, keep growth deliberate.

Oversight needs to keep pace with change

Teams build new applications, give existing ones new capabilities and move to newer AI as the vendor releases it and retires older versions. An application approved last quarter may behave differently today, so oversight works best as an ongoing practice rather than a one-off approval.

Questions worth putting to management

• How many applications use the OpenAI API (GPT-4, GPT-4o), and who owns each one?
• What information are those applications allowed to send, and how long does the vendor hold it?
• Which applications can take actions or connect to other services, and who approved that?
• How is spending tracked against budget, and who acts when it runs over?
• What happens to an application when the vendor retires the AI it relies on?
• If a customer or regulator asked how these applications are governed, what would be shown to them?

What good reporting looks like

Expect regular reporting on which applications are live and who owns them, what kinds of information they handle, spending against budget, the main risks and how they are moving, any incidents or near misses and the significant decisions taken, with who made them and why.

How Aicura can help

• One register of every application built on the OpenAI API (GPT-4, GPT-4o), with an owner, an accountable executive and a technical contact for each.
• Spend shown as contracted, as billed and as estimated from observed use, with budgets per application and across the organisation.
• Board reporting drafted from the governance record, covering use, risks, spend, incidents and the decisions taken.

---

For risk, compliance and assurance

Set where these applications sit in the risk appetite

Decide which classes of information may be sent to the OpenAI API (GPT-4, GPT-4o) and which decisions its output may inform. Applications that classify, rank or decide at volume need sample review by someone who knows the subject, because an error repeats across every case it touches.

Assess each application on its own terms

Assess each application separately, covering the data it sends, whether its output affects people, whether it reads content from outside the organisation, which tools and outside services it can use and who reviews what it produces. An internal drafting aid and a customer-facing assistant that can act need very different treatment.

Reassess when anything changes

A new data source, a new tool or connection, a change of AI version or a move into a customer-facing role all take an application away from what was assessed. Each needs to trigger a fresh assessment rather than wait for the annual cycle.

Make the retention and residency decisions explicitly

The vendor keeps abuse monitoring records of requests and responses for a period by default, and some features keep stored content until it is deleted. Eligible customers can apply reduced retention arrangements with the vendor’s approval, across the organisation or per project, and can choose regional data storage for a project. Decide which retention arrangement and which region each application needs, check what the vendor’s current terms say for the account in use and record the decision.

Confirm which protections apply

The vendor states that API data is not used for training unless the customer opts in. Confirm the organisation has not opted in, check which accounts and projects carry the agreed data arrangements and find keys created on personal accounts or outside the approved organisation so that use can be brought into it.

Decide what applications may connect to

The platform lets applications search the web, connect to outside services and call third-party tool servers. The vendor’s own guidance notes that a tool server it has not verified can receive anything in the application’s context. Decide which services and tool servers are acceptable, which actions need a person’s approval and who signs off a new connection.

Set limits and name who acts

Agree the limits that matter, such as spend, request volume, sensitive information appearing in prompts or unusual activity from one application, and name the person who acts when one is crossed.

Be ready to show governance to others

• Policy. Maintain an AI use policy that covers building on the OpenAI API (GPT-4, GPT-4o), including what data may be sent, who may create keys and projects, which connections are allowed and how output affecting people is reviewed. Tie each commitment to the control that carries it out.
• Accountability. Record approval decisions for each application with their reasons. Have owners confirm periodically that their application still matches what was approved.
• Operating evidence. Keep records that controls actually ran, such as application approvals, retention decisions, redaction and screening events, spend checks and reviewed outputs.
• External scrutiny. Prepare for internal and external audit, certification against standards such as ISO/IEC 42001, regulator enquiries and insurer questions about AI controls.
• Customers and partners. Due diligence questionnaires increasingly ask whether customer data reaches third-party AI and how long it is held. Have a clear answer for each application, supported by evidence.
• Incidents. Be able to reconstruct which application version, which AI version, which data, which tools and which controls were in place at the time.

How Aicura can help

• Risk and impact assessments for each application against recognised frameworks, run again on any material change and feeding a managed set of risks and controls that can mirror to the GRC platform.
• Vendor records for OpenAI with due diligence, contracts, a relationship owner and review dates, alongside the data each application uses and at which stage.
• Limits on spend and activity with responses the organisation chooses, from alerting the owner to blocking an application.
• Every approval, retention decision, control action and automated response kept as evidence that can be verified without relying on the organisation’s word.

---

For technology and security

Discover every application calling the API

Find every application, script and service that calls the OpenAI API (GPT-4, GPT-4o), whether through the official libraries, other frameworks or direct calls to the API domains. Look in code repositories, cloud accounts and network traffic, and record the project, keys, AI versions and tools behind each one.

Use projects as the boundary of each application

The platform organises work into projects, each with its own keys, service accounts, rate limits per model and spend alerts or hard limits. Give each application its own project, or at least its own service account, so use can be traced, limited and switched off per application. Keep staging and production in separate projects and use custom roles with least privilege, with membership synced from the identity provider.

Keep keys short-lived and accounted for

Restrict which kinds of key may be created, set expiry and maximum key lifetimes and narrow each key’s permissions to the endpoints the application needs. Store keys in a secrets service, remove keys held on personal accounts and rotate any key found outside approved storage.

Put configuration and applications under change control

The applications are the organisation’s own code, so prompts, AI versions and tool definitions can live in source control. The platform’s projects, roles, groups, rate limits and spend alerts can also be managed as code through the vendor’s Terraform provider and changed through its administration API. Run a preflight check in the deployment pipeline so a new application, project, AI version, tool or connection is checked against agreed rules before it goes live.

Govern every request in the request path

Calls come from the organisation’s own applications over a documented API, so they can pass through an AI gateway on the way to the vendor’s usual endpoint and be read in full. Use it to redact personal information before it leaves, screen inbound content for injected instructions, confirm each application uses its approved system prompt, restrict the AI versions and tools a request may name, cap spend and stop an application when needed.

Narrow the tools the vendor runs on its side

Built-in tools such as web search, connectors and third-party tool servers are switched on in the request itself. The gateway sees which tools each request asks for, so use it to allow only approved tools and servers. Within each application, expose only the tool functions it needs and require approval for any action that would not be run automatically.

Use the network to close the side doors

Allow traffic to the API domains only through the gateway, so applications built outside the approved route are seen and steered back to it. Unregistered traffic can be held in observe-only mode at first and blocked once teams have moved across.

Feed what the platform and gateway see into monitoring

The platform exposes audit logs of user actions and configuration changes, and usage and cost data broken down by project, key and model. Bring these into monitoring alongside gateway records and application telemetry. Apply the limits risk has agreed and set responses from alerting the owner to tightening an application’s restrictions or blocking it.

Plan for vendor change

The vendor marks AI versions as legacy, then deprecated, then shut down, and notifies affected customers by email and in its documentation. Pin each application to a specific version, record which version it depends on, track the vendor’s deprecation notices and test each affected application before it moves to a replacement.

Test applications against the live deployment

Red-team and evaluate each application before release and on a schedule afterwards, with its real prompts, tools and data. Watch for changes in behaviour between tests, especially after an AI version change.

How Aicura can help

• One inventory of applications built on the OpenAI API (GPT-4, GPT-4o) with the AI versions, tools and identities behind each one, discovery of unregistered use from code repositories, cloud inventories and device telemetry, and notice to every affected application when a model is changed or retired.
• Preflight checks in the deployment pipeline before an application, AI version, tool or vendor change goes live.
• A gateway in the request path with guardrails derived from the agreed controls, covering redaction, injection screening, approved system prompts, tool and model limits, budgets, handling of unregistered traffic and the ability to stop an application.
• A collector inside the network for platform audit and usage records, gateway and application telemetry, plus scheduled red-teaming and evals against the live deployment with drift watched between runs.

---

Getting lasting value from OpenAI API (GPT-4, GPT-4o)

The OpenAI API (GPT-4, GPT-4o) pays off when building on it is governed as an ongoing practice rather than approved once. Three things matter whatever the role. The first is knowing every application that uses it, what it can connect to and who is accountable for each. The second is controlling what data leaves in every request and how long it is held, through the request path and settings the organisation already owns. The third is keeping assessments, controls and evidence in step as applications and the underlying AI change. Organisations that get these right can let teams build faster, with confidence rather than caution.

---

Sources

• OpenAI, Data controls in the OpenAI platform
• OpenAI, Admin APIs
• OpenAI, Administration Overview
• OpenAI, How to use the Usage API and Cost API to monitor your OpenAI usage
• OpenAI, Manage permissions in the OpenAI platform
• OpenAI, Manage projects and access with Terraform
• OpenAI, Rate limits and spend with Terraform
• OpenAI, Production best practices
• OpenAI, Rate limits
• OpenAI, Using tools
• OpenAI, MCP servers
• OpenAI, Deprecations