Enforcing an AI Policy at the Point of Use

Most AI policies contain a sentence like this one: employees must not use AI tools that have not been approved. It is clear, it is reasonable, and it describes a state of the world rather than an action. Nothing in it says what happens at the moment somebody opens an unapproved tool.

That gap is where enforcement lives, and it is wider than it looks, because the available answers are not variations on a theme. Recording that it happened, warning the person, blocking the request, and stopping the application from running are four different interventions with four different costs, four different failure modes and, in much of Europe, four different conversations with a works council.

This guide is about choosing deliberately between them. It covers what each action actually is, where in the stack each one can be enforced and what cannot be enforced anywhere, the employment law layer that enforcement runs straight into, and why the control that scales best is the one nobody counts. It follows our generative AI usage policy template, which owns the policy text, and picks up where endpoint governance leaves off, at the point where discovery turns into action.

A policy is a sentence

There is a predictable sequence in AI governance programmes. The policy lands first, because it is the artefact that can be written without anyone else's cooperation. Discovery follows, because the policy immediately raises the question of whether anyone is following it. And then the programme arrives at enforcement and discovers that it is not one decision but a series of them, each requiring a different team to agree.

The reason enforcement is treated as a single step is that the policy phrases it as one. "Not permitted" reads like a binary. In implementation it is a spectrum, and where you land on it determines the cost, the legal exposure and whether people route around you.

Four actions, not one

Three things follow from laying them out this way.

The second action is underused. Alerting at the moment of use is cheap, reversible, and pointed at the actual cause of most unapproved use, which is somebody not knowing there was an approved option. It is also the only one of the four that can carry a route to compliance rather than just a refusal. An alert that says "this is not approved, the approved alternative is X, and you can request this one here" does work that a block cannot.

The fourth action displaces rather than stops. Our guides on shadow AI and endpoint governance both record the same pattern: prohibition without a fast sanctioned alternative moves the activity to machines and accounts you cannot see. Blocking a managed laptop is not a reduction in use if the person has a phone.

The first action is not neutral. Recording without acting is a defensible choice for a period and an indefensible one as a steady state, because the record itself becomes evidence that you knew. If the answer is to tolerate something, the honest version is a documented acceptance with an owner, not a quiet log.

Where each one can actually be enforced

Enforcement needs a chokepoint, and the chokepoints available depend on how the tool reaches the model. This is the same structural problem that caught network controls, described in full in our endpoint guide, and it determines which of the four actions is even available.

The employment law layer

This is the part that turns enforcement from a technical project into a negotiation, and it is the part most likely to be discovered late.

The GDPR anticipates it directly. Article 88 allows Member States to adopt more specific rules by law or collective agreement for processing employees' personal data in the employment context, covering purposes such as recruitment, performance of the contract, management, health and safety and termination. Paragraph 2 requires those rules to include "suitable and specific measures to safeguard the data subject's human dignity", legitimate interests and fundamental rights, with particular regard to the transparency of processing, transfers within a group of undertakings, and monitoring systems at the workplace.

That last item is the point. Workplace monitoring is a named area where national law is expected to diverge, and Member States had to notify the Commission of their provisions. An enforcement control rolled out uniformly across an EU estate is being deployed into a patchwork by design, not by accident.

The AI Act adds a specific duty in the other direction. Under Article 26, before putting a high risk system into service or using it at the workplace, employer deployers must inform workers' representatives and the affected workers that they will be subject to it. That duty is about the AI systems you deploy to employees. Whether a governance enforcement agent is itself in scope depends on how it is classified, which is a question worth asking your own counsel rather than assuming either answer.

Two practical consequences. First, the distinction between reading configuration and observing behaviour matters legally and not only ethically, and a design that reads what is installed and how it is configured is a much easier case than one that watches what people type. Second, the consultation is cheaper before the rollout than after it, and in several jurisdictions it is not optional.

The control nobody counts

Every enforcement layer in the table above shares a limitation: it works against tools somebody has already identified. New assistants appear continuously, and a recognition list trails reality permanently.

There is one control that does not have that property, and it happens to be a legal obligation. Article 4 requires providers and deployers of AI systems to "take measures to support the development of AI literacy" among their staff and others operating AI systems on their behalf, taking into account their "technical knowledge, experience, education and training", the context of use, and the persons on whom the systems are used. The article is explicit that it does not require guaranteeing any specific level for any individual, which makes it a duty to make the effort rather than to certify an outcome.

Read as an enforcement measure rather than as a training obligation, it is the only control in this article that generalises. A person who understands why a particular class of tool is a problem will make a reasonable decision about a tool nobody has assessed yet. A blocklist will not. The Commission and Member States are required to support providers and deployers in meeting this duty, particularly SMEs, and the Commission is to publish practical examples on the single information platform.

Designing the escalation

1. Decide what happens, per tier, before you deploy anything
   Write the mapping: at this tier of tool and data, the response is record; at this tier, alert; at this tier, block. Deploying an enforcement capability before deciding what it should do produces either everything blocked or nothing blocked, and both get switched off.
2. Make every block carry a route
   A refusal with no next step converts a governance control into an obstacle, and obstacles get routed around. The message should name the approved alternative and link the request path. Our guide to AI intake and approval covers making that path fast enough to be worth taking.
3. Hold the works council conversation at design time
   Bring what is collected, what is not collected, who can see it and what actions follow. Reading configuration rather than content is a materially easier case, and bringing the design while it can still change is the difference between a consultation and a dispute.
4. Start in alert mode and measure before enforcing
   Run the rule in a mode that records what it would have done. The result tells you the false positive rate and the volume, both of which are needed to size support load. A rule enforced on day one without that measurement is how enforcement programmes earn a reputation in week two.
5. Invest in literacy proportionate to what you cannot enforce
   The larger the unmanaged portion of the estate, the more of the control has to come from people making reasonable decisions. That is a budget argument, and Article 4 is the duty it attaches to.
6. Record tolerated exceptions as decisions
   Where something is known and permitted to continue, write it down with an owner, a reason and a review date. A standing exception is a legitimate answer. An undocumented one looks identical to a control failure from the outside.

The trade-offs nobody puts on the slide

Enforcement creates a performance record. Any system that attributes an attempted action to a named person produces data about that person, which has a purpose limitation, a retention period and an access model whether or not anyone designed them. Deciding who may see enforcement data about an individual is part of the design, not an operational detail.

The false positive is the expensive one. Blocking something legitimate costs the programme more credibility than missing something unapproved, because it is visible, immediate and personal. That asymmetry argues for conservative initial thresholds and for measuring in alert mode first.

Uniform enforcement across jurisdictions is not uniform compliance. The same control can be routine in one Member State and require consultation in another. A single global rollout plan will be wrong somewhere, and the places it is wrong are the ones with the strongest employee representation.

Enforcement without a fast approval path is a shadow AI programme. This is the one to say plainly. If the sanctioned route is slow and the unsanctioned route is blocked, the result is not compliance; it is the same activity on a device you do not manage, which is strictly worse than what you started with.

Frequently asked questions

Where this leaves you

The uncomfortable fact underneath all of this is that an AI policy cannot be comprehensively enforced. There is no chokepoint that sees everything, no combination of layers that reaches a personal device, and no recognition list that keeps up with the tools being released. Any enforcement design is a choice about which subset of use is governed well.

That is not an argument against enforcement. It is an argument for spending the budget where it generalises. Alerting at the moment of use changes behaviour cheaply and carries a route to compliance. Literacy is the only control that works against a tool nobody has assessed yet, and it is a duty you already hold. Blocking is a precise instrument with a high cost, and it works best used precisely. The programmes that get this wrong are not the ones that enforce too little. They are the ones that enforce first and discover the works council, the false positive rate and the personal device afterwards.