AI agents: 40% of enterprises could restrict or retire them by 2027

SECTION 1

What the forecast says

On 26 May 2026, Gartner published a blunt forecast: by 2027, 40% of enterprises will demote or decommission autonomous AI agents because of governance gaps identified only after production incidents. It should not be confused with another forecast from the firm, published in June 2025, according to which over 40% of agentic AI projects will be cancelled by the end of 2027.

The firm's explanation comes down to one idea: organisations treat agent governance like a switch. Either the agent is locked down, or it is fully trusted. Yet agents have neither the same degree of autonomy nor the same access. Applying the same controls everywhere produces two symmetrical failures.

Too much control over simple agents

An agent that only reads and summarises ends up subject to the same approvals as a critical system. Delivery slows down, teams work around the rules, and agents appear outside any framework.

Not enough over autonomous agents

Conversely, an agent able to act in the company's systems gets the same light review as a conversational assistant. Operational, security and compliance risk grows without anyone seeing it, until the first incident.

SECTION 2

An agent is not a chatbot

The difference does not lie in the quality of the answers, but in what the agent is allowed to do. A conversational assistant produces text that a human reads. An agent calls tools, opens tickets, changes code, triggers deployments. It acts within the information system.

Risks the chatbot did not pose

This shift from words to action opens new risks. A malicious instruction slipped into a document the agent reads can hijack its behaviour. Data can leak through a tool it has access to. A poorly bounded action can repeat without anyone stopping it. In practice, an agent's risk grows with its capabilities, its autonomy, its access and its speed of action, and falls with the quality of oversight.

Questions that need a written answer

What data does the agent access? What actions can it launch on its own? Who can stop it, and how quickly? Who can trace its decision six weeks later? As long as these questions have no written answer, the agent remains a pilot, however impressive it may be.

Related read AI agents shouldn't be a security nightmare

SECTION 3

Four levels of autonomy, four levels of control

Governance starts with classification. Each agent is given a level, and the level determines which controls apply. An agent changes level when its rights are extended, never silently.

We use the four levels of autonomy proposed by Gartner. Each level keeps the controls of the previous one and adds more. We add one rule that applies at every level: some actions, sensitive by nature, always require human approval.

Interactive figure: see the online version of the article

Level 1: observe

The agent reads, searches, summarises. It changes nothing, and only the requester sees the result. The controls: read-only access to defined sources; the agent only sees what the user is allowed to see; sources cited; exchanges logged; no unfiltered outbound links or images, a protection against prompt injection.

Level 2: propose

The agent drafts a ticket, a reply, a code change. A human decides. Added to this: quality evaluation before going live and then continuously (accuracy, hallucinations), review of every proposal (at Adservio, AI codes and the engineer validates) and user training.

Level 3: act with approval

The agent carries out the action itself, but only after explicit approval from a human, action by action. Added to this: a technical identity specific to the agent, rights granted action by action, the action presented clearly before approval (diff, recipients, volume) and monitoring of approval fatigue (rejection rate, response time, spot checks).

Level 4: act autonomously

The agent acts on its own within guardrails; a human reviews exceptions and logs afterwards. Added to this: a scope and prohibitions enforced by the interface, not by the agent, cost and volume caps, isolated execution, planned rollback, a tested emergency stop and written criteria for moving up or down a level.

A rule for every level: sensitive actions

A production configuration, regulated data or an outbound communication requires human approval, whatever the level. The more critical the action, the higher the approval goes: a manager for an outbound communication, two cross-approvals for billing data. Deletion is forbidden by default; a one-off exception goes through the technical director.

One sheet per agent

In practice, each agent is described in a versioned sheet, just like code. It states what the agent can do, what it will never do, and what happens when a request goes beyond its mandate. Here, as an example, is the sheet of a level 4 remediation agent: it adjusts the number of instances of two services on its own, within set bounds, and escalates everything else.

# Anything not declared is forbidden.
agent: incident-remediation
version: 1.3.0
level: 4                           # act autonomously within guardrails
owner: first.last                  # named person who holds the mandate
team: sre
review_date: 2026-12-15
identity: sa-remediation-agent     # dedicated service account, never a human's
model: model-name-and-version      # listed in the register

data:
  accessible: [application-logs, metrics]
  max_sensitivity: internal

tools:
  - id: read_logs
    access: read
  - id: scale_instances
    access: write
    targets: [orders-api, billing-worker]
    environments: [production]
    bounds: {min: 2, max: 6}
    reversible: true
    human_approval: false          # reversible, within bounds and below the caps

guardrails:                        # enforced by the interface, not by the agent
  window: "mon-fri 07:00-20:00 Europe/Paris"
  caps:
    actions_per_hour: 10
    daily_cost_eur: 50

out_of_mandate:
  fallback: human_escalation       # the decision goes to the on-call team
  channel: sre-on-call

emergency_stop:
  who: [sre-on-call, owner]
  max_delay: 5 min
  last_test: 2026-09-30

tracing:
  tool_calls: full
  session: full                    # context, model version, calls and responses
  retention: 90 days
  personal_data: masked

evolution:
  min_observation: 30 days
  raise_if: [no out-of-scope action, success rate >= 99%]
  lower_if: [cap reached, action refused by the interface]

The last sections matter as much as the first: an agent for which you know who stops it, how quickly, and what it does with an out-of-mandate request is an agent you can let work.

Autonomy is earned

An agent's level is not fixed. It widens when the agent has met, over an observation period, criteria written in advance. It narrows as soon as it crosses a limit: cap reached, action refused by the interface. Traceability is what makes this progression possible: without traces, no proof, and therefore no reason to widen.

SECTION 4

How we govern agents

The grid is not enough without the mechanisms that enforce it. Here are the mechanisms we recommend and put in place on our agent projects.

Interactive figure: see the online version of the article

A register: what is not declared does not run

A control plane, for example a gateway through which every call to models and tools passes, holds the reference list of authorised models and tools, classifies data by sensitivity and tracks usage and costs, agent by agent. An agent or tool missing from the register stays blocked.

One identity per agent

Each agent acts under its own service account, with its own rights only. It never borrows a human's account, and its secrets are managed like those of an application.

Revocable interfaces

The agent does not query a database directly. It goes through an interface, an existing API, an MCP server or a dedicated connector, which carries the permissions, logs the calls and can be revoked without touching the agent. Withdrawing a right becomes a matter of seconds, not a redeployment. Withdrawing a right does not interrupt a session already under way: that is the role of the emergency stop, described below.

Evaluate before promoting

Before moving up a level, an agent goes through a battery of tests on real cases and trap cases, including prompt injection attempts.

Record in order to explain

Every session is recorded in full: context, model version, tool calls and their responses. A decision made six weeks ago is reconstructed from these traces, and can be replayed in a test environment, instead of being reconstructed from memory. Traces may contain personal data: they are minimised, masked where possible and kept for a defined period.

Monitor and respond

An alert is triggered when an agent departs from its usual behaviour (volume, cost, refusals by the interface). An agent incident follows the same process as a production incident.

A stop planned from the design stage

An agent must be able to be stopped quickly, and its sheet and configurations are versioned so you can return to the previous state. These mechanisms are only worth something if they are exercised: we test them the way you test a recovery plan.

SECTION 5

What about regulation?

An agent is not a “high-risk” system by nature under the AI Act: it all depends on the use. An agent that screens job applications or takes part in credit decisions falls under stricter rules; an agent that summarises internal documentation does not. As soon as an agent interacts with people, the AI Act requires telling them that they are interacting with an AI (Article 50). If the agent alone takes a decision that produces legal effects for a person or similarly significantly affects them, Article 22 of the GDPR applies: such a decision is only allowed in specific cases, and the person can obtain human intervention. An auditor, a customer or an authority will nevertheless always expect the same thing: to know what the agent does, with which rights and on which data. Traces kept from day one provide the answer.

Related read NIS2, DORA, AI Act: why cyber compliance is becoming a business issue in 2026-2027

SECTION 6

Six mistakes to avoid

• Uniform governance: the same controls for every agent, too heavy for some, too light for others.
• Shadow agents: built by teams outside any programme, missing from the register, and therefore invisible.
• Rights borrowed from a human: an agent acting with an administrator's account inherits all of their rights.
• Silently widening rights: a tool added without reviewing either the agent's level or its controls.
• Unrecorded sessions: without usable traces, an error can be neither explained nor corrected.
• An emergency stop never tested: the day the agent has to be stopped, no one knows how.

SECTION 7

Where to start

Three steps tell you where your organisation stands, before investing further in agents:

1. Inventory existing agents, including those built by teams outside any programme.

2. Classify each one by autonomy level, starting from what it is actually allowed to do, not from what it usually does.

3. Align controls with the level, easing those of simple agents as much as strengthening those of autonomous agents.

SECTION 8

How Adservio supports you

This is the approach of our AI agents offering: agents that specify, code, test and document across the whole delivery cycle, framed by multi-level guardrails. We build them with Agentic Spec-Driven Development, in four steps: specify, plan, break down, implement. AI proposes the path, the engineer decides; AI codes, the engineer validates.

In practice, we step in at three moments: the inventory and classification of your existing agents, the set-up of the register, interfaces and session recording, then supporting your teams as agents move up the levels.

SECTION 9

In summary

AI agents rarely fail because of the model. They usually fail when their controls do not match what they are allowed to do. Classifying each agent by autonomy level, declaring its rights in a sheet, tracing each of its actions and being able to stop it at any time: that is what separates an agent that goes into production from one that gets switched off.

FAQ

Frequently asked questions

SOURCES