The deployment question is not “Can the model do it?”
A new AI capability can appear useful long before an organisation is ready to place it inside a production workflow.
That gap matters most when the capability has cyber-relevant consequences. An AI system that can interpret security data, generate operational recommendations, interact with tools, or accelerate technical work may create value. It may also increase the speed, scale, or accessibility of actions that require careful control.
The decision should therefore be framed as an operating question:
What could this capability do, who could invoke it, what systems could it affect, and how quickly could the business detect and stop misuse?
OpenAI’s published discussion, “Pacing model development in an era of cyber-critical capabilities”, is a useful starting point for that question. The supplied source packet provides the title and attribution, but not the underlying article text. This article therefore does not claim to summarise OpenAI’s specific recommendations. Instead, it translates the topic into a practical decision framework for business operators.
Classify the capability before approving the use case
“AI” is too broad a category for a meaningful production decision. A text assistant used to draft internal summaries should not follow the same approval path as a system that can inspect sensitive infrastructure, recommend security actions, or invoke external tools.
Start by classifying the capability along four dimensions:
- Information access: What data can it read, infer, retain, or expose?
- Action authority: Can it only produce information, or can it change records, systems, permissions, or workflows?
- Operational reach: Is its output limited to one user, or can it affect many systems, customers, or employees?
- Misuse potential: Could a malicious or careless user repurpose it to accelerate harmful activity?
The classification should describe the capability in its intended operating context, not just the underlying model. A relatively general model can become materially more consequential when connected to privileged data, automation tools, or high-impact business processes.
A useful rule is to classify the combination of model, tools, data, users, and environment. The risk belongs to the system as deployed.
Set deployment gates that become stricter with impact
A production approval should not be a single yes-or-no judgement. It should be a series of gates, with stronger evidence required as potential impact increases.
Gate one: Define the permitted job
The business should be able to state what the capability is for, what it is not for, and which decisions remain outside its authority.
Vague purposes create vague boundaries. “Improve security operations” is not a sufficient production definition. A more useful description identifies the approved workflow, the inputs it may use, the outputs it may produce, and the conditions under which a person must intervene.
Gate two: Test failure modes, not only successful outputs
Evaluation should include incorrect recommendations, sensitive-data exposure, prompt manipulation, overconfident answers, unsafe tool requests, and attempts to operate outside the approved task.
The objective is not to prove that the system never fails. That standard is unrealistic. The objective is to understand how it fails, whether those failures are detectable, and whether the resulting harm can be contained.
Gate three: Prove containment and reversibility
A capability should not reach production if the organisation cannot quickly reduce its access or stop its operation.
Containment may include restricted environments, narrow permissions, approval requirements for consequential actions, and a tested suspension path. The exact controls will vary by workflow. The operating principle is consistent: an AI component should not become difficult to disable because it has been embedded too deeply or trusted too broadly.
Gate four: Establish an accountable owner
Every production capability needs a named business owner and a technical or security contact with authority to pause it.
Ownership should cover more than uptime. The owner should be responsible for the approved use case, access decisions, incident escalation, review cadence, and the decision to expand, restrict, or retire the capability.
Limit access according to consequence
Access control is one of the most important differences between a useful pilot and an unmanaged production dependency.
Begin with the smallest group of users who can evaluate the capability properly. Separate experimentation from live operations. Avoid giving a model broad permissions simply because a workflow might eventually need them.
Access should be considered at several levels:
- Who can use the capability?
- What information can each user provide to it?
- Which tools or systems can it reach?
- Which actions require confirmation?
- Who can change its permissions or operating scope?
For higher-impact workflows, permission should be explicit rather than implied. A system that can recommend an action does not automatically need authority to execute it. Keeping those roles separate preserves an important human checkpoint while the capability is still being evaluated.
Monitor for misuse and drift
A production approval is not a permanent verdict. Models, integrations, users, data, and attack patterns change.
Monitoring should cover both normal performance and warning signals. Those signals may include unusual usage volume, access outside the approved workflow, repeated attempts to elicit restricted behaviour, unexpected tool requests, sensitive data appearing in outputs, or a growing gap between system recommendations and human decisions.
Logs should be useful for investigation without becoming an uncontrolled store of sensitive information. The organisation should decide what must be recorded, who can review it, how long it is retained, and how an incident is escalated.
Monitoring also needs a response path. A dashboard without an owner or an escalation threshold is not an effective control. The team should know when to restrict access, require additional review, suspend an integration, or stop the capability entirely.
Treat integrations as a risk multiplier
The same model can have very different consequences depending on what it can touch.
An isolated assistant that drafts a report is not equivalent to an assistant connected to identity systems, production infrastructure, customer records, financial processes, or security tooling. Each integration can expand the potential impact of an error or misuse event.
Before approving an integration, ask:
- What is the minimum data and permission required?
- Can the action be read-only or advisory at first?
- Is approval required before a consequential change?
- Can the integration be isolated from unrelated systems?
- Can access be revoked without taking down the wider workflow?
- Is there a clear record of what the AI requested and what a person approved?
These questions turn “integration” from a technical implementation detail into a governance decision.
Define the human role precisely
“Human in the loop” is not enough. A person who merely clicks through an AI recommendation without time, information, or authority to challenge it is not providing meaningful oversight.
Human accountability should specify:
- Which decisions require human approval
- What evidence the reviewer receives
- What the reviewer is expected to check
- How disagreement is recorded
- Who can override, pause, or revoke the capability
- What happens when the reviewer is unavailable
For low-impact tasks, human review may focus on sampling and exception handling. For high-impact actions, approval may need to occur before execution. The right level depends on potential harm, reversibility, and the quality of available monitoring.
Use a staged adoption path
A responsible adoption path can move through four broad stages:
1. Observe
Use the capability in a controlled setting to understand its outputs, limitations, and data requirements. Do not grant authority to change production systems.
2. Advise
Allow the capability to support a defined workflow while people retain decision authority. Compare its recommendations with existing processes and investigate material discrepancies.
3. Act with approval
Permit limited actions only when a designated person confirms them. Keep permissions narrow and make the approval record reviewable.
4. Automate bounded tasks
Consider automation only where the task is well defined, the consequences are limited or reversible, monitoring is reliable, and a responsible owner can intervene quickly.
Progression should be earned by evidence. A successful pilot in one context does not automatically justify broader access, more sensitive data, or more autonomous action.
What business leaders should require before production
Before approving a cyber-relevant AI capability, leaders should expect a concise decision record covering:
- The defined use case and prohibited uses
- The capability’s information access and action authority
- The people, systems, and customers potentially affected
- Evaluation results, including meaningful failure modes
- Access restrictions and approval requirements
- Monitoring, retention, and incident response arrangements
- Rollback or suspension procedures
- Named owners and escalation contacts
- Review dates and conditions for expansion
If the team cannot explain these points clearly, the capability may be interesting but is not yet operationally ready.
The practical answer: pace authority, not just model access
Businesses often debate how quickly to adopt new models. The more useful question is how quickly to increase authority.
A capability can be explored before it is trusted. It can be trusted for advice before it is allowed to act. It can be allowed to act in a narrow, reversible context before it is connected to high-impact systems.
That distinction helps organisations capture value without treating capability as permission. It also creates a more durable basis for adoption decisions as model performance and cyber relevance continue to change.
For leaders reviewing an AI deployment, the next step is not to ask whether the technology is impressive enough. Ask whether the proposed use is bounded, observable, reversible, and owned. If any of those answers is unclear, narrow the scope before increasing the authority.