We have an AI policy, but nobody knows which systems exist or who can stop them

Many organisations begin their artificial-intelligence governance by writing a policy. That is understandable: a policy can state principles, acceptable uses, prohibitions, general responsibilities and security guidelines. The problem begins when that documentary layer is mistaken for the governance system itself.

The test is simple. Ask which AI systems are operating today, for what purpose, which data they use, who is functionally accountable for each one, which model or provider is involved, and who can suspend them. If nobody can answer those questions precisely, the organisation may have a policy and still lack a governance architecture.

Governance starts by identifying the object

Regulation (EU) 2024/1689 does not treat every system, role and use in the same way. The obligations that apply depend, among other factors, on the operator’s role, the configuration and the relevant legal classification.

That is why a cross-cutting policy cannot replace the identification of each system. The organisation needs to know what exists before deciding which regime, controls and evidence apply.

A minimum inventory entry should make it possible to distinguish:

• intended purpose and actual use;
• internal owner;
• provider, model and version;
• main data, memory and sources;
• connected tools or systems;
• affected people or groups;
• the initially assigned legal position;
• status: testing, production, suspended or withdrawn;
• date and reason for the latest review.

The point is not to catalogue every software function that uses an AI technique. The point is to identify configurations that produce legally or organisationally relevant effects.

The system file matters more than the policy in isolation

A policy answers: “how do we want to act?” A system file should answer: “what is happening here, who decided it, and what has changed?”

The file is therefore not an onboarding form that is completed once and archived. In a proportionate manner, it should maintain:

1. the system’s identity and purpose;
2. the positions and functions of the operators;
3. data, sources, memory and integrations;
4. classification and acceptance decisions;
5. controls, supervision and permissions;
6. incidents and corrective measures;
7. changes of model, provider, purpose or autonomy;
8. the decision to suspend, reactivate or withdraw the system.

The AI governance system-file structure — Spanish turns that logic into a maintained unit.

The critical point: who can stop it

An organisation may have committees, policies, reviews and risk matrices and still leave one elementary question unanswered: who has the authority to stop the system when a material difference appears?

Suspension capacity should not be improvised during an incident. It has to be assigned in advance and be materially executable.

That means distinguishing at least:

• who detects a deviation;
• who evaluates its materiality;
• who can restrict permissions or functions;
• who can order complete suspension;
• who preserves evidence before changes are made;
• who decides on resumption;
• which conditions must be met before returning to production.

An escalation path that requires several days, undefined approvals or exclusive access by the provider may not amount to a real stopping capability for certain purposes.

Governance fails when the architecture changes without memory

The second common failure appears after the initial deployment. The system enters with a given purpose, version and provider. Later, access expands, the model changes, memory is added, new tools are connected or the system is introduced into a more sensitive process.

If those changes do not return to the system file, the organisation ends up governing a legal description of the system that no longer matches the real system.

The rule should be simple: a change reopens review when it may alter an obligation, position, risk, architecture, relevant date, supervision or evidence.

Not every change requires the same level of review. But the organisation should know why a particular change does not require it.

H&C criterion

AI governance should not be measured by the number of documents that have been approved. It should be measured by the organisation’s ability to keep a changing configuration legally identified.

At a minimum, that capacity requires:

inventory → system file → accountable owners → authority → controls → evidence → change → suspension/withdrawal.

A policy can establish a common language. It cannot replace that sequence.

A reality test

For a specific system, and without launching an internal investigation lasting several days, the organisation should be able to answer:

• what it does;
• what it is used for;
• who governs it;
• which provider and version are involved;
• which data and tools it uses;
• which decisions depend on it;
• who supervises it;
• who can stop it;
• what has changed since the last review;
• where the evidence for those decisions is kept.

If those answers do not exist, the problem is not necessarily the absence of another policy. The missing element may be the governance unit itself.

The legal and operational AI maturity diagnostic — Spanish can be used to locate those gaps without turning them into an automatic compliance score. The objective is not to obtain a traffic light; it is to decide which difference should be closed first.