---
title: "AI policy 2.0: what the system may do, and who decides"
url: https://zerofive.ai/en/blog/ai-governance/ai-policy-2-0-what-the-system-can-do
canonical: https://zerofive.ai/en/blog/ai-governance/ai-policy-2-0-what-the-system-can-do
language: en
published: 2026-10-24
updated: 2026-10-20
author: "ZeroFive.AI"
tags: AI policy, AI agents, governance, AI Act, delegation levels
abstract: "From a policy that restricts people to one that configures systems: eight elements, owners, AI Act references and a path to rewrite yours."
---

# AI policy 2.0: what the system may do, and who decides

**In brief.** The AI policy most companies wrote over the last two years is a list of things people must not do, designed for an AI that answered in a chat window. Now that agents open connectors, write to business systems and sometimes spend money, that policy says nothing about what the system itself may do. Policy 2.0 states it through eight elements grouped in four layers (perimeter, autonomy, traceability, control), uses measurable values instead of principles, changes intensity with the level of delegation, and is signed jointly by IT, legal and the business.

We discussed it at Confindustria with Ernesto Belisario, starting from a line we had put at the top of a slide: policy 1.0 said what not to put in the prompt, policy 2.0 must say what the system can do. Here we take that slide and develop it the way we use it in our projects, with the elements, who is accountable for each, the regulatory references and a path for rewriting the policy you already have.

![AI policy 2.0: eight elements in four layers, perimeter, autonomy, traceability and control](/policy-ai-2-0-elements-en.png)

## The first-generation policy

Look at the AI policies approved by most companies between 2023 and 2025 and you will find roughly the same document: which tools may be used, which data must not go into a prompt, the duty to review what the model produces, an address to write to when in doubt. It is a code of conduct for people, consistent with the way AI entered companies, as a chat window where someone pasted a text and read the answer.

That document did its job. It reduced the use of personal accounts, made the customer data problem visible, gave users a written reference, and it is still the starting point for anyone dealing with [shadow AI](/en/blog/approfondimenti/shadow-ai-company-risks-policy). It worked because the person did the work and the AI stayed at the margins, what we call the [AI-assisted](/en/blog/strategia/ai-assisted-ai-first-ai-native-delegation-levels) level in our assessments.

Agents change the audience. An agent connected to the CRM, the mailbox and the ERP reads documents, prepares orders and answers customers, and no rule addressed to people tells it which systems it may touch, read-only or read-write, up to what amount, with what record of its actions. That information exists only if someone has decided it, and the place to decide it is the policy.

## The eight elements of policy 2.0

The slide we presented listed eight items. In our work we group them into four layers, each with the question it answers, because the question helps establish who should fill in the element and with what data.

| Layer | Element | What the policy sets | Example parameter | Owner |
|---|---|---|---|---|
| Perimeter | Authorised tools | Models, assistants and agents allowed, with version and activity | Assistant on the corporate tenant allowed, consumer accounts excluded | IT |
| Perimeter | Usable data | Data categories per system, legal basis, exclusions | Pseudonymised customer data allowed for analysis, health data excluded | Legal and DPO |
| Autonomy | Permissions and connectors | Systems reached, read or write, identity used | CRM read-only, email drafts only, no ERP access | IT |
| Autonomy | Activities requiring approval | Actions the system prepares that a person must approve | Customer communications and contract changes | Business |
| Autonomy | Spending thresholds | Spending limits per action and per period | Orders above a set threshold go to the purchasing manager | Business and CFO |
| Traceability | Logging | What is recorded, for how long, who can access it | Every action with user, time and outcome, kept for a set period | IT |
| Traceability | Incident reporting | Definition of incident, recipients, timing | Wrong output sent to a customer, reported to the owner within hours | Legal and IT |
| Control | Suspension and kill switch | Who stops the system, how, how fast, how it restarts | Revocation of connector credentials, scheduled test | IT and business |

The **perimeter** sets what the system works with. These are the two elements policy 1.0 already had, but here they are declared system by system rather than for the whole company, because a writing assistant and an agent that reconciles invoices need different data.

**Autonomy** sets what the system may do without asking. This is the layer first-generation policies did not know about, and it holds the most delicate decisions: which connectors to open and with which permissions, which actions go through a person, how much it may spend. Spending thresholds are the element that surprises boards the most, because until recently no business software could commit the company to a supplier without an employee pressing a button.

**Traceability** sets what remains and who gets notified. A log of the agent's actions is needed to reconstruct what happened, and a reporting procedure is needed so that someone knows in time. We wrote about the link between logs and the reversibility of an agent in the piece on [four layers and the delegation perimeter](/en/blog/ai-governance/ai-agents-four-layers-delegation-perimeter).

**Control** sets how the system is stopped. It has a single element and we treat it as a gate: for high-risk systems the AI Act, in Article 14, requires that whoever oversees the system can interrupt it through a stop button or a similar procedure, and for an agent in production we consider this a requirement outside that scope too. A kill switch nobody has ever tested is worth as much as not having one, so the policy must also state how often it is tested.

## Values instead of principles

The most visible difference between the two generations is the kind of sentence. Policy 1.0 says "personal data must be used in compliance with the law", policy 2.0 says which data categories a given agent may read and which it may not. A statement of principle cannot be configured in a system, a threshold can.

This is why policy 2.0 has two parts. The first is a short document with principles, roles and the rules that apply to everyone. The second is a sheet for each system in production, with the eight elements filled in: values, permissions, thresholds, timings, names. When a system changes, its sheet is updated and the general document stays stable.

The sheet must stay aligned with the actual configuration. The risk we see most often, and one we have run into with our own internal agents, is a sheet that says "email drafts only" while someone, to fix an operational problem, has given the agent permission to send. The periodic review consists of comparing the two, and whoever does it must be able to read both.

## How much each element weighs by delegation level

Not every system needs the eight elements at the same intensity. An assistant suggesting text to an employee, who then decides what to use, is governed with the perimeter and a minimal log. An agent running a process end to end needs every element configured in the system and verified.

![Intensity of the eight elements by delegation level: AI-assisted, AI-first, AI-native](/policy-ai-2-0-delegation-en.png)

| Element | AI-assisted | AI-first | AI-native |
|---|---|---|---|
| Authorised tools | Defined | Configured and verified | Configured and verified |
| Usable data | Defined | Configured and verified | Configured and verified |
| Permissions and connectors | Not needed | Defined | Configured and verified |
| Activities requiring approval | Not needed | Defined | Configured and verified |
| Spending thresholds | Not needed | Defined | Configured and verified |
| Logging | Defined | Configured and verified | Configured and verified |
| Incident reporting | Defined | Configured and verified | Configured and verified |
| Suspension and kill switch | Not needed | Defined | Configured and verified |

"Defined" means the sheet states explicit values. "Configured and verified" means those values are set in the system (connector permissions, spending limits, log retention) and someone has checked that the system honours them. At the AI-first level approval is already part of the definition, because a person reviews every output, so the policy must say who reviews and against which criteria.

## The joint signature

The slide closed with a line about who signs: IT, legal and the business. Each of the three owns different elements. IT is accountable for tools, connectors, logs and stop mechanisms. Legal, together with the DPO, is accountable for data, incidents and regulatory alignment. The business is accountable for approvals and spending thresholds, because deciding how far a system can commit the company is a choice for whoever owns the result.

The joint signature avoids policies written by a single function, which we know well: the IT version is precise on permissions and silent on accountability, the legal version cites every regulation and translates into no configuration at all. Each system then has a named owner who answers for its sheet, a point we covered in the piece on [agents without a named owner](/en/blog/ai-governance/ai-agents-named-owner-production).

With the amendments to Legislative Decree 231/2001 introduced by Legislative Decree 160/2026, the policy also falls within the scope of Italian organisational models, and its supporting documentation becomes material to produce when something goes wrong, as we explained in the article on [AI documentation as evidence](/en/blog/compliance/ai-documentation-as-evidence-decree-160-2026).

## Regulatory references

Policy 2.0 does not stem from a single specific obligation, but almost every element maps to a regulation or standard the company already has to consider.

| Element | Main references |
|---|---|
| Authorised tools | AI Act Art. 26 (deployer obligations), ISO/IEC 42001 Annex A |
| Usable data | GDPR Arts. 5 and 35, ISO/IEC 42001 Annex A |
| Permissions and connectors | NIS2 Art. 21 (access control), least privilege |
| Activities requiring approval | AI Act Art. 14 (human oversight) |
| Spending thresholds | Internal delegations and powers of attorney, Model 231 |
| Logging | AI Act Arts. 12 and 26, ISO/IEC 42001 Annex A |
| Incident reporting | AI Act Art. 73, NIS2 Art. 23, GDPR Art. 33 |
| Suspension and kill switch | AI Act Art. 14(4) |

Articles 12, 14, 26 and 73 of the AI Act concern high-risk systems, whose Annex III obligations apply from 2 December 2027 following the Digital Omnibus. For other systems we use them as a good-practice reference: the policy is prepared ahead of time and the company reaches the deadline with sheets, logs and tests already running. A dedicated piece covers [effective human oversight](/en/blog/compliance/ai-assisted-decisions-effective-human-oversight) and its implications for training.

## How to rewrite the existing policy

The path we follow starts from what the company already uses, system by system.

1. **Inventory.** List the assistants, agents and integrations in use, including those adopted by teams without going through IT, as described in the article on the [AI system inventory](/en/blog/compliance/ai-system-inventory-iso-42001).
2. **Delegation level.** Classify each system as AI-assisted, AI-first or AI-native and, where relevant, by AI Act risk class.
3. **Sheet per system.** Fill in the eight elements with measurable values, using the intensity table to know where to stop.
4. **Joint signature.** IT, legal and the business approve the sheet, and each element has its owner.
5. **Configuration.** Translate the sheet into settings (permissions, limits, log retention, alerts) and verify that the system honours them.
6. **Review.** Update the sheet at every new connector, model, incident or regulatory change, and test the kill switch at the planned frequency.

The general document of policy 1.0 is not thrown away. It becomes the first part of policy 2.0, with the conduct rules that still apply to users, and the sheets are added to it.

## The most common mistakes

The first is writing policy 2.0 as a longer version of 1.0, adding chapters on agents and automation without getting down to values. The result is a text no system can enforce and nobody checks.

The second is a single policy for every system. Applying the rules of an order-signing agent to a writing assistant blocks adoption, while applying the assistant's rules to that agent leaves uncovered exactly the part that exposes the company.

The third is treating the kill switch as a vendor feature. Many platforms let you deactivate an agent, few guarantee that connector credentials are revoked and that running processes stop in an orderly way, and you only find out by testing.

The fourth is keeping the sheet separate from the configuration. A policy that says one thing while the system does another is worse than no policy, because it gives the board a confidence that does not match the facts.

## Where to start

In the [AI Rating](/en/services/ai-rating) model the policy belongs to the AI Risk dimension, where basic compliance and governance are non-compensable gates: a company with high scores in the other dimensions does not reach class A if this part is missing. The assessment also shows which systems need a sheet first.

To see how to declare how much work to hand to each system, read the article on [delegation levels](/en/blog/strategia/ai-assisted-ai-first-ai-native-delegation-levels), and for reversibility and the gates of an agent the one on [four layers and the delegation perimeter](/en/blog/ai-governance/ai-agents-four-layers-delegation-perimeter).

To check where your policy stands you can [start an AI Rating](/en/start-ai-rating) or [book an assessment call](https://calendly.com/fabiolalli/zerofive).