OpenAI’s Decisions API is here. Are enterprise controls ready?

This week at DevDay, OpenAI introduced the Decisions API, a new API designed to classify inputs, route requests, and choose an action from a predefined set of answers. The move is widely seen as a response to the viral popularity of Jev, a decision model built by an ex-OpenAI lead and released just two weeks before.

It was worth copying. At its core, the decision paradigm makes the type of structured output that software requires much cheaper and faster to produce. The first wave of generative AI models was about producing natural-sounding text for chatbot experiences. They were built to answer questions, generate code, and summarize documents. Now, enterprises are moving past chatbots toward autonomous agents that are increasingly expected to use software cheaply and quickly.

Decision models are built for that autonomous work, not chat sessions. They are cheaper, faster, and perform at or above parity with their natural-language counterparts on boolean-type decisions.

Agents can now personalize an experience, retrieve a customer record, send an offer, or hand information to another agent. But determining that an action is useful is different from determining whether the data required for that action is permitted to be used.

For enterprises, every “What should I do?” is increasingly accompanied by another question:

Can I use this data, for this purpose, right now?

As agents grow more autonomous, they require scalable, infrastructural controls that speak the same language they do.

AI systems need more than one kind of decision

Imagine an AI agent determines that the best next action is to personalize an offer for a particular customer. From the model’s perspective, that may be the right move. The offer is relevant, the customer appears likely to respond, and personalization is an available action.

From the enterprise’s perspective, there are other factors at play.

Did the customer consent to this use? Are there regulatory requirements based on the customer’s jurisdiction? Has the customer changed a preference since the data was collected?

Decision-based models make it more possible, and more crucial, to encode and apply that type of heavily contextual policy. But agents can’t govern themselves. More deterministic decisioning is a step in the right direction, but it still isn’t audit-worthy.

Governance wasn’t built to operate at AI speed

Enterprise systems weren’t built for agents. Business rules and compliance policies live in documents, tucked away in a quiet corner waiting for yearly training. As the use of AI has exploded, enterprises are under increasing pressure to simultaneously demonstrate ROI on those investments and implement controls to prevent risk. Too often, the result is a board demanding both faster AI adoption and greater assurance that the systems being deployed are operating within the company’s rules.

Those mechanisms serve a purpose, but they were largely designed for a world where humans could sit between policy and execution.

Agents change that model.

An AI system can make enormous numbers of decisions across customers, systems, purposes, and data types. A privacy team can’t manually evaluate every record before an agent accesses it, and an engineer can’t hard-code every possible combination of jurisdiction, policy, customer preference, purpose, and data type into every new AI application.

The issue isn’t that enterprises need more policy. The policies often already exist. The challenge is turning them into decisions the systems using the data can actually understand and apply.

Policies need to be machine-enforceable, at runtime, every time, to matter.

Why isn’t access control enough for AI agents?

Traditional role-based access control (RBAC) has struggled for years to keep up with increasingly complex resource access decisions. Half your summer intern’s time is gone just getting credentials. Data can become so covered in red tape that you forget it’s there.

Most governance for agents simply lets agents inherit the permissions of their “owners,” acting on their behalf. That creates an obvious problem: a human’s accumulated access is rarely the same set of permissions an autonomous agent needs to complete a particular job.

A modestly expanded version adds distinct agent identities and takes environment variables, such as production versus sandbox, into account. This is certainly an improvement on pure inheritance, but it still fails to meet the moment.

You take a Role (who’s asking), the Resource (what they’re accessing), and the Environment (e.g., Production/Sandbox), and call it a day. But an agentic decision requires more context. For a data-use decision, that means evaluating the relevant Business Policy, Regulatory Context, and Customer Permissions for the specific use taking place. The answer may change depending on the customer, data, purpose, system, jurisdiction, and action.

Most importantly, the result needs to be something software can act on. The applicable rule is applied before anything downstream acts. A customer’s preference is honored wherever their data travels. A new AI application doesn’t require its engineering team to rebuild the organization’s permission logic from scratch.

That’s a very different model from governance as documentation. It’s data decision infrastructure.

The agentic stack needs a control plane that combines a policy engine and enforcement

The architecture that emerges is straightforward.

An agent has context and determines its next action. It makes an AI decision: personalize an experience, retrieve information, send a message, or invoke another tool.

Before the application uses customer data to carry out that decision, another decision needs to happen: is the relevant data actually available for this purpose, for this customer, under the organization’s rules?

Agent → “What should I do?” → AI decision → “Can I use this data?” → Data-use decision → Action

That second decision isn’t a static allowlist. The same data may be permitted for one purpose and restricted for another. A use allowed for one customer may not be allowed for another. Preferences change. Regulations change. Business policies evolve.

The enterprise needs to take the context surrounding a particular data use and resolve it into an answer the system can act on in real time.

Agents make this especially urgent because they dramatically increase the number and variety of potential data uses. As companies deploy more agents, encoding permission logic independently into each application becomes increasingly difficult to maintain, scale, and prove.

A common data decision layer provides another model: applications ask whether data is available for a particular use and receive an answer based on the organization’s policies and permissions before they act.

“Can I use this data?” is becoming an infrastructure question

OpenAI’s Decisions API is still in limited preview, but the direction is significant. AI is moving beyond creating content to making business decisions.

Enterprise AI controls need to make the same transition.

That’s the problem Transcend is built to solve. Transcend is the real-time agent and data governance and decision layer that answers “Can I use this data?” by encoding rules into the systems that process customer data.

As AI gets better at deciding what to do next, enterprises need to make sure their rules about data can keep up.