When there is no policy

Plenty of organisations have no AI policy. That is not automatically negligent, and it is not a defence either. The duties do not wait for internal documentation. Article 26 deployer obligations, Article 14 oversight, Article 4 literacy and Article 73 reporting all apply to an organisation that has never written a word about AI.

So the practical question is not whether you are covered. It is what you do in the meantime, and how you get a policy written without waiting for someone to volunteer.

The default rules while you wait

These are derivable from the law and from ordinary professional judgement, and none of them requires anyone's approval.

• Do not put into a tool anything you would not email to an external party. This is a crude test and it is the right crudeness for an unregulated situation. Customer data, personal data, health data, unpublished financials and legal advice all fail it.
• Do not let AI output reach a person unreviewed. If it is going to a customer, a candidate or a patient, you read it against the source first.
• Never use generated text as the reason for a decision. The explanation is produced by the same process as the answer, so it reads as a reason without being one.
• Write down what you are using. A list in a shared document with tool, purpose and data type beats nothing, and it is the seed of the register.
• Tell someone when something looks wrong, the day you notice. The clock in Article 73 runs from awareness whether or not the organisation has an escalation route.

Note what these rules have in common: none of them needs a budget, a committee or a vendor. They can be adopted by a team this week.

Asking for a policy so that it happens

Asking for an AI policy in the abstract produces agreement and no action, because it is a large, unowned, low-urgency request. Three things change that.

Bring the use, not the principle. A specific list of what your team is already doing with AI, written down, converts the conversation from whether a policy is needed to what to do about these seven things. It also makes the absence concrete for whoever reads it.

Name what you cannot answer. Frame the request as questions rather than as a document: may this data go into this tool, who approves a new use, what do I do at four in the afternoon when a model looks wrong. Questions are answerable in a meeting. A policy is not.

Ask for the smallest version. One page: approved tools, prohibited data, when to record, who to ask, who to tell. Most of the value of a policy is in that page. Asking for it explicitly gives whoever owns the decision something they can complete, and a document that exists can be extended later.

Who to ask

The owner is not obvious in most organisations, which is part of why the policy does not exist. In practice the request lands with whoever already owns adjacent risk: the data protection officer, the head of risk or compliance, or the information security lead. Pick the one whose existing remit your question touches, and if you cannot tell, ask them and let them redirect you. Being redirected is not a failure of the request; it is the request working.

What to do if the answer is no, or nothing

If you raise it and nothing happens, you have still changed your own position materially, and that is worth understanding clearly rather than cynically. You have a written record of having raised a foreseeable risk with the person whose remit it falls in. That is what a reasonable professional is expected to do, and it is what distinguishes an organisational failure from a personal one.

Keep doing the default rules. Keep the list. Raise it again when something concrete changes: a new tool, a near miss, a regulatory deadline, a customer question. Concrete triggers move things that abstract arguments do not.

As of 24 September 2026.