Since 2 February 2025, companies that provide or use AI systems in the European Union have carried a new and rarely discussed obligation. Article 4 of the European AI regulation requires those organisations to develop AI literacy among their staff and anyone operating these systems on their behalf — the knowledge needed to deploy AI in an informed way, aware of its risks and the harm it can cause.

Notice what the rule does not say. It does not ask for a document, a signed policy or a recorded training session. It asks for a demonstrable capability inside the operation. And that is precisely the distinction most companies have not yet made.

The numbers explain why. ISACA's 2025 AI Pulse Poll, with 3,029 digital trust professionals, found that 59% of organisations already permit generative AI — but only 28% have a formal, comprehensive AI policy. Deloitte's State of AI in the Enterprise, published in January 2026 with 3,235 business and IT leaders across 24 countries, shows the next step down: only 21% report mature governance for the risks of AI agents. Roughly four in five companies lack clear decision boundaries for those agents, real-time monitoring or audit trails.

The document exists. The control does not

Most companies that "have an AI policy" have, in practice, a PDF. Someone in legal or security wrote it, a meeting approved it, an email announced it. Everything is in there: which data may not be pasted into external tools, which decisions require human review, which departments may use AI for what.

And none of it operates.

The document does not know who is who. It does not know whether the person who just asked for a contract summary is authorised to read it. It does not stop outdated information from becoming an official answer. It records nothing about what was done, by whom and when. When an audit or an incident investigation arrives, the company has a written rule and no evidence that it was followed.

It is the difference between a "do not enter" sign and a door with a lock. The sign communicates intent. Only the lock changes behaviour — and only the lock leaves a record of who walked through.

What regulators and standards already require

What regulators and standards already require

Three international references converge on the same point, and they are worth knowing even if none applies directly to your company today.

The European AI regulation entered into force on 1 August 2024 and applies in stages: prohibitions and the AI literacy obligation since 2 February 2025; general-purpose models since 2 August 2025; the remainder from 2 August 2026, with further obligations for high-risk systems from 2 August 2027. Companies outside Europe that serve European clients tend to enter that calendar through contracts long before they enter it through law.

ISO/IEC 42001, published in 2023, is the international management system standard for AI — and it is certifiable through external audit. It does not ask for good intentions: it asks for a defined AI policy, assigned roles and responsibilities, documented risk assessment, operational controls (data governance and access control among them), continuous monitoring, regular internal audits and an annual policy review by leadership.

The NIST AI Risk Management Framework in the United States, published in 2023 and voluntary in adoption, organises risk management into four functions: govern, map, measure and manage. Govern is the only one that cuts across every stage — meaning governance is not a project phase, it is a permanent condition of the operation.

In Brazil, bill PL 2338/2023 was approved by the Senate floor on 10 December 2024 and has been under review in the Chamber of Deputies since 17 March 2025. The text structures regulation by risk level and provides rights for people affected by automated decisions. Meanwhile, the Brazilian data protection law already governs the personal data that passes through any AI tool. None of this is legal advice — reading what applies to your case is your legal team's job. The operational point is different: the controls these three references describe are almost identical, and they are exactly what is missing when the policy lives only in the PDF.

Five controls that turn a rule into a mechanism

An AI policy becomes a control when each of its sentences has a matching mechanism inside the tool people actually use. There are five.

Corporate identity. People sign in with the company badge, not with an account of their own. Role, department and employment status come from the corporate directory. When someone leaves, access ends with them — without depending on anyone remembering to revoke it.

Role-by-role access. The rule "finance does not see HR contracts" has to be a configured permission, not an expectation. Whatever a person may read, the AI working for them may read — and nothing beyond that.

Approval according to the risk of the action. Not every action needs a brake. Deleting a record, changing a credential or sending a sensitive communication do. A risk classification defines where human approval is required.

Review and approval of critical content. Critical documents can require two-step review and approval, with separation of duties and audited exceptions. This is the control that stops an outdated file, dropped into the wrong folder, from becoming the company AI's official answer.

Audit trail. Who did what, when and from where. Without a record, a company can neither prove compliance nor reconstruct an incident — and the policy, however well written, stays undemonstrable.

What has to be in place

What has to be in place

The five controls only count when they live where the work happens: sign-in with corporate identity, access defined by role, agents bounded by what the person using them may already see, sensitive actions that pause and ask for confirmation, and a searchable record of every relevant action. No piece works alone — identity without a trail proves nothing; a trail without permissions records the improper access after it happened.

There is an obstacle that comes first: many companies do not have the written processes their policy is supposed to reference. Postponing governance until the house is in order is the most common way to never govern at all. Starting from ready templates — HR, finance, operations, customer service, quality — and adapting them shortens that step. And what one person creates and the company approves has to stay available to the authorised roles instead of dying in its author's account. That is how Skyller was designed.

A five-step route to get the policy out of the PDF

  1. List the assertions in your current policy. Every sentence that says "may not", "only with approval" or "restricted to department X" is a candidate rule to become a mechanism. If the policy has no sentences like these, it is still a statement of intent.
  2. Map each rule to the control that enforces it. Identity, permission, risk-based approval, content review or audit trail. A rule without a matching control is a rule nobody follows — and nobody can prove they follow.
  3. Start with the two or three routines with the most exposure. Contracts, customer data, payroll, pricing. Governing everything at once stalls the project; governing what hurts first produces evidence quickly.
  4. Define where the AI has to stop. Write down the list of actions that require human confirmation before they happen, and configure it. Without that list, companies swing between blocking all agent use and letting it run with no brake.
  5. Put the review on the calendar. The international references converge on periodic review and internal audit. A policy that is never revisited ages faster than the technology it is meant to govern.

Three questions to take into the next board meeting: if an auditor asked today for evidence that our AI policy was followed last quarter, what could we hand over? When someone leaves, how long does it take before they lose access to the company's AI tools? And who, by name, approves a document before it becomes the AI's official answer for the entire company?

Discover Skyller