Preparing for the EU AI Act is the start; control happens in daily operation.

A company can have an AI policy, an AI inventory and an EU AI Act workshop—and still have very weak control over the AI systems operating inside the business.

That is the readiness gap executives should worry about now.

The EU AI Act has moved from future legislation into staged application. The current consolidated Regulation (EU) 2024/1689 is in force, with provisions applying on different dates. Article 4 requires providers and deployers to take measures supporting the development of AI literacy for staff and other persons operating or using AI systems on their behalf, taking account of their knowledge, experience, education and training and the context of use. Article 50 transparency obligations relevant to AI-generated content apply from 2 August 2026, including marking, detection and defined labelling duties. The European Commission’s voluntary Code of Practice supports implementation of those transparency obligations; adherence can facilitate compliance but is not, by itself, conclusive proof of compliance.

Source context: EU AI Act · consolidated 2026-07-27 ↗

But legal readiness and operational governance are not synonyms.

Risk classification matters because it can determine which obligations apply.

But once the classification is complete, the organization still has to run the system.

Who owns it? Which model/version is actually deployed? Which data does it use? Which vendor terms apply? Who can access it? Which decisions can it influence? Which actions can it take? What human review occurs in practice? What evidence demonstrates that controls are working? What happens when the provider changes the model?

A spreadsheet row cannot answer those questions by itself.

Article 4 is often summarized as a training requirement.

Source context: EU AI Act · consolidated 2026-07-27 ↗

Training is part of it. But operationally, AI literacy means the people who use or supervise AI need enough understanding to recognize what they are doing, what the system can and cannot support, and when escalation is necessary.

For a marketing employee, that may mean understanding disclosure and data-handling boundaries. For a developer, it may mean understanding code-generation risk and review obligations. For a manager, it may mean distinguishing a model recommendation from evidence. For an approver, it may mean understanding why a high-consequence agent action needs human authority.

A one-hour awareness course cannot substitute for role-specific operating competence.

Article 50 is especially instructive.

Source context: EU AI Act · consolidated 2026-07-27 ↗

The Commission’s 2026 transparency code addresses marking and detection for AI-generated or manipulated content and labelling obligations for certain deployers. The code is voluntary, but the underlying legal obligations are not.

To comply operationally, an organization may need to know:

Which system generated the content? Was the output AI-generated or AI-assisted? Which marking mechanism was applied? Did provenance survive transformation? Who is responsible for visible disclosure? Which content falls inside an exception? Can the organization demonstrate what happened later?

That is not merely a policy question. It is a data, workflow, provenance and evidence question.

The practical layer looks something like this:

LAW / OBLIGATION → APPLICABILITY QUESTION → ORGANIZATIONAL ROLE → SYSTEM / USE CASE → CONTROL REQUIREMENT → IMPLEMENTATION → EVIDENCE → MONITORING → CHANGE → REASSESSMENT.

Each arrow can fail.

A legal team may correctly identify an obligation while engineering never implements the control. Engineering may implement a control while nobody keeps evidence. Evidence may exist but be stale. A vendor may change the model or service terms. A new tool may give an agent additional capability. A business team may repurpose a system into a higher-consequence workflow.

Operational governance exists to keep those layers connected.

This distinction protects organizations from another common mistake: building governance entirely around one regulation.

An organization operating globally may also need to consider privacy, cybersecurity, sector rules, employment law, consumer protection, intellectual property, contractual obligations, standards and internal authority rules.

Even within the EU, a system can be low or limited risk under one AI Act pathway and still create material privacy, security, reputational or business risk.

ISO/IEC 42001 is useful precisely because it frames AI as an organizational management-system problem rather than a single-regulation checklist. NIST’s AI RMF provides another risk-management lens. Neither replaces legal analysis, and the AI Act does not replace organizational governance.

Source context: ISO/IEC 42001:2023 ↗ · NIST AI Risk Management Framework ↗

A stronger AI Act readiness review asks for proof.

Not simply:

“Do you have an AI policy?”

But:

Is the policy current? Who approved it? How is it implemented? Which systems are covered? Which exceptions exist? What evidence demonstrates the control? When was it last tested? What happens when the system changes?

UNESCO’s Readiness Assessment Methodology provides a useful methodological analogue at national level: it repeatedly asks whether strategies and policies have been evaluated for effectiveness, whether implementation bodies and budgets exist, and whether monitoring and evaluation are built in. Existence is not treated as the same thing as readiness.

Enterprises should apply the same discipline.

The strongest future operating model is not “annual AI Act assessment.”

It is continuous compliance intelligence:

AI Estate changes → applicability may change → evidence may expire → controls may need adjustment → human authority may need review → incidents may create new obligations → provider changes may create new gaps.

This is where monitoring becomes foundational.

Monitoring does not mean surveillance of employees. It means the organization has mechanisms to know when material AI-system, provider, regulatory, evidence or control conditions change.

Without that, compliance is always looking backward.

Start with one actual use of AI rather than a company-wide compliance percentage. Write down the system, the purpose, the affected people and the organisation's role. A company may use one supplier's model, integrate another service and make its own application available to customers. Those relationships require analysis at the appropriate level. A provider's product category does not settle the legal position of every downstream use.

For each relevant obligation, connect the legal interpretation to an implementation owner and an observable test. If the requirement concerns informing a person, identify where the notice appears, which language is shown and whether it survives a move between channels. If it concerns a document, establish which version is retained and how staff find it. The legal team and the operational team need a shared object they can both inspect.

Keep interpretation separate from evidence of execution. A legal opinion can explain why a duty applies; a screenshot can show a particular disclosure; a system log can show when an event occurred. None proves all three. The point of a connected record is to make those different contributions visible, including where the chain is incomplete. A numerical readiness score can obscure that distinction if it treats every ticked box as equivalent.

The 2026 amendment changes parts of the AI Act, so an earlier checklist should not be reused without examining its legal edition. In particular, Article 50's general application date and a transitional rule for certain pre-existing provider systems are different facts. The amendment provides a transition to 2 December 2026 for the Article 50(2) marking obligation for qualifying systems placed on the market before 2 August 2026. It does not create a blanket postponement of every transparency duty. Check the precise provision and the organisation's role in the adopted amendment.

Source context: EU AI Act · consolidated 2026-07-27 ↗

That distinction matters for an ordinary project. A marketing team publishing a synthetic spokesperson should not assume that a provider's marking transition resolves the team's own disclosure duties. Conversely, a buyer should not treat every lack of a particular technical mark as conclusive evidence of a breach without considering scope and timing. The Commission's transparency guidance is a practical companion to the legal text. This article offers operating questions, not an individual legal determination.

Consider a hypothetical company using a generated voice in a customer information service. The team should inspect the first interaction, the explanation available to the customer and the route to a human. Then test the actual delivery chain: source audio, editing, translation, export, playback and any reuse by a distributor. A disclosure that exists only in the creation tool may disappear before a person encounters the final material.

Define acceptance in terms that can be observed. Can a person recognise the notice? Is it available in the page's language? Is the wording accurate about the use of AI? Does an alternative channel provide equivalent information? The test should include the mobile layout and an accessible reading path. The organisation's lawyer determines the applicable duty; the team demonstrates how the agreed implementation behaves.

Retain a concise record of the final asset, the relevant terms and the test result. If the material is changed, decide which tests need repeating. Keep an accountable editorial owner for the published content. This makes a later correction possible without collecting unnecessary personal information about every viewer. Evidence design should support accountability while respecting data minimisation.

Role-specific learning should start with the mistakes a person must be able to recognise. A service employee needs to know when a suggested answer lacks support. A procurement lead needs to distinguish a hosting option from the terms applying to the selected account. A manager reviewing a generated summary needs to know which source records remain available. The common introduction can be short; the practical exercise should fit the work.

Use realistic scenarios with an expected response. Ask participants to identify an unsupported claim, explain an escalation and find the current operating rule. Give them permission to stop an unsafe or unclear workflow. Attendance records show that training happened; they are not evidence that every individual reached a guaranteed level of competence. The amended Article 4 expressly distinguishes the obligation to take literacy measures from a guarantee of a particular individual level.

Source context: EU AI Act · consolidated 2026-07-27 ↗

Review the learning when the role or tool changes. Staff trained only to draft text may need different preparation when the same application begins taking actions. Connect the training record to the operating instructions and the person responsible for questions. That provides a useful improvement loop without presenting a course certificate as proof of organisational compliance.

A useful review pack contains the intended use, role analysis, applicable legal sources, control owners, implementation evidence, unresolved material questions and the next review trigger. Keep it focused on decisions that can change the deployment. A long document inventory is less valuable if nobody can identify which missing fact prevents the next action.

For initial market orientation, use the Prism profiles to inspect provider evidence and carry relevant questions into Compare. An AI Trust Record can organise one named system's evidence and responsibilities. A scoping enquiry can establish what technical and organisational work is useful alongside legal advice. These are request-based continuations. They do not certify compliance, activate a monitoring service or replace the organisation's accountable legal and operational decisions.

Can we identify our current AI systems and agents? Can we trace each material system to an owner and purpose? Can we identify where EU AI Act obligations may apply without pretending a questionnaire is a legal determination? Can we demonstrate AI literacy measures by role? Can we show the evidence behind material controls? Can we detect meaningful model/provider/system changes? Can we preserve human authority where consequences demand it? Can we explain unknowns and conflicts instead of converting them into false certainty?

If the answer is “not yet,” that does not mean the organization has failed the AI Act.

It means the organization has operational work to do.

And that work is larger—and more valuable—than compliance theater.