Drupal AI Compliance: EU AI Act, NIST AI RMF & ISO 42001

The EU AI Act, NIST AI RMF, and ISO/IEC 42001 do not regulate your CMS. They regulate how your organization builds, governs, and evidences the AI running inside it. For a Drupal AI implementation, that means the compliance work is not a platform feature you switch on. It is a set of records your team has to be able to produce on demand.

That is an awkward place for a technology lead to sit. You own the risk, the board expects a defensible answer, and the three frameworks people keep citing are a law, a voluntary method, and a certifiable standard that were never designed to line up neatly. They do share one demand, though, and that demand is where the work actually lives.

What Changed for the EU AI Act in July 2026?

The high-risk deadline moved, but the transparency deadline did not. On 27 July 2026, the Digital Omnibus on AI entered into force, the first substantive amendment package to the Act. It defers the obligations most enterprises were racing toward, while leaving the ones that touch a website in place.

Two dates matter for a CMS. Obligations for stand-alone high-risk systems under Annex III, the Act's list of use cases treated as high-risk such as employment, education, and access to essential services, were pushed from 2 August 2026 to 2 December 2027. Product-embedded high-risk systems under Annex I moved to 2 August 2028. That is real runway for teams in scope.

The transparency rules under Article 50 survived the Omnibus almost intact and still apply from 2 August 2026. One carve-out: machine-readable marking of synthetic content under Article 50(2) moved to 2 December 2026, with a grace window for generative systems already live before August. Telling people they are talking to an AI is due now; watermarking output has four more months.

If your Drupal site runs an AI chatbot or publishes AI-generated content, this is your live date, not 2027. Location does not help you: Article 2(1)(c) reaches providers and deployers outside the EU wherever the output is used in the Union. A US university site with EU applicants is in scope.

Breaching Article 50 carries fines up to €15 million or 3% of worldwide annual turnover. The Act's top tier, €35 million or 7%, is reserved for prohibited practices. Either way, the tier you fall into is not an academic question.

Image

What Do the EU AI Act, NIST AI RMF, and ISO 42001 Each Require?

The three frameworks are a law, a method, and a certifiable standard, and they do different jobs. Treating them as interchangeable compliance checkboxes is the first mistake teams make.

The EU AI Act, NIST AI RMF, and ISO 42001 compared for a CMS implementation team.

The EU AI Act entered into force in August 2024 and phases in by risk tier: prohibited uses and AI literacy from February 2025, the latter softened by the Omnibus from ensuring literacy to supporting its development, general-purpose AI rules from August 2025, and the dates above for high-risk and transparency.

The NIST AI Risk Management Framework is a voluntary US framework built on four functions, with a Generative AI Profile added in July 2024 covering risks specific to generative systems. It certifies nothing, but it has become the common vocabulary enterprises use to organize AI risk.

ISO/IEC 42001:2023 is the first internationally certifiable AI management system standard, published in December 2023. It follows the same Plan-Do-Check-Act structure as ISO 27001, which means an accredited auditor can verify that your AI governance operates in practice rather than only on paper.

Which of These Frameworks Applies to a Drupal AI Implementation?

Most AI features in a CMS land in the EU AI Act's transparency tier, not the high-risk tier. An AI chatbot, AI-assisted content generation, semantic search, and automated alt text are limited-risk uses. Their main legal obligation is disclosure: tell people they are dealing with AI, and mark AI-generated content so it can be detected. That obligation is narrower than it first appears, and the next section covers where it stops.

The high-risk tier is triggered by what the AI decides, not by the fact that it runs on Drupal. If a public body uses AI to determine access to essential services, or a university uses it to evaluate students, that use is high-risk under Annex III and now carries the December 2027 deadline. For public-sector, nonprofit, and higher-education operators, that line is worth checking deliberately rather than assuming the CMS layer keeps you clear.

NIST and ISO/IEC 42001 apply for a different reason. No law forces them, but a US federal RFP may name NIST, and an enterprise customer or your own board may ask for ISO 42001 as proof of responsible AI. In practice, many teams run NIST as the operating method inside an ISO 42001 management system, then use both to show the EU AI Act's records exist. Our read of the Drupal AI landscape goes deeper into the data-sovereignty and residency choices that sit underneath all three.

Do You Actually Have to Label Everything?

No, and the exemptions matter more than the obligation for most CMS teams.

Article 50(4) requires disclosure for AI-generated text published to inform the public on matters of public interest. It then exempts content that has undergone human review or editorial control where a person or organization holds editorial responsibility for publication. If your editorial workflow has a named reviewer who approves before publishing, you are inside that exemption.

Product pages and service copy are generally outside that scope entirely, before any exemption applies.

A second exemption covers AI that performs an assistive function for standard editing or does not substantially alter the input. Grammar correction, reformatting, and summarization of text a human wrote sit closer to this line than net-new generation does.

For chatbots, Article 50(1) waives disclosure where the AI is obvious to "a reasonably well-informed, observant and circumspect" person. That is a subjective standard, and it is a thin thing to build a compliance position on. Disclose.

One trap: the editorial review exemption releases you, the deployer, from disclosure. It does not release the model provider from the machine-readable marking obligation under Article 50(2) that lands on 2 December 2026. Those are separate duties on separate parties.

Where Vardot Lands: AI Compliance in a CMS Is an Evidence Problem, Not a Model Problem

As a Gold Sponsor of the Drupal AI Initiative and a Drupal Diamond Certified Partner, our view is that the three frameworks reduce to a single demand once you implement them on a real platform, and it is not about which model you chose. It is whether you can produce evidence of how each AI feature is governed. The teams that struggle are not the ones using the wrong LLM. They are the ones who cannot show what the AI was allowed to do, who reviewed it, and where its instructions came from.

This is where a CMS decision quietly becomes a compliance decision. In our work on AI-first Drupal builds, the failures cluster in one place: the AI's context, prompts, and permissions live in content or in someone's head, so nothing is reviewable after the fact. When the same configuration lives in Drupal's config entities, it is version-controlled, code-reviewed, and promoted across environments like any other code. That traceability is not a convenience. It is the precondition for evidencing anything the three frameworks ask about.

Put plainly, your compliance evidence for AI in Drupal is a configuration-management problem before it is a legal one. Get the config layer right and the records the frameworks demand are a byproduct of how the platform already works. Get it wrong, and you are reconstructing history under audit pressure. It is the same conclusion our team reached mapping the Drupal AI modules worth deploying in 2026: governance, not model quality, is the real readiness gap.

The exemptions make the evidence argument sharper, not weaker. Article 50 does not define human review, substantial alteration, or public interest. If you claim the editorial review exemption, the only thing that makes the claim hold is a record: who reviewed what, when, and under whose editorial responsibility. Config-level workflow produces that record. A screenshot of your editorial policy does not.

What Does a Drupal AI Implementation Team Have to Evidence?

A Drupal AI implementation team has to evidence seven things, and each maps to a place in Drupal AI and Varbase AI where the control actually lives. The Drupal AI initiative supplies the building blocks; Varbase AI ships them as pre-configured recipes so the evidence comes from applying a recipe rather than assembling the configuration by hand.

Cross-framework evidence demands mapped to Drupal AI and Varbase AI controls.

Articles 10, 12 and 14 bind high-risk systems only. If your AI features sit in the transparency tier, treat those rows as NIST and ISO practice, plus your evidence base if a use case is later reclassified. Article 50 is the row that binds everyone. Read the table as a gap analysis, not a shopping list. Where a row already produces the record you would hand an auditor, you are done.

Where it does not, that is the work, and it is usually a governance and configuration task rather than a model swap. The AI translation governance pattern shows what several of these rows look like in production, from human-in-the-loop review to public AI disclosure.

How Should You Sequence This Work Before the Deadlines?

Start with the date that is already here. Confirm whether any public-facing AI on your Drupal site needs Article 50 disclosure by 2 August 2026, and check the exemptions before you build anything: chatbot disclosure is almost certainly in scope; AI-assisted text under editorial review may not be. Implement the disclosure layer first, then content-marking against the December date. Then build the inventory, because you cannot govern what you have not mapped. Only then decide whether any of your use cases are high-risk enough to warrant the fuller Annex III program on the 2027 timeline.

If it would help to pressure-test your own AI features against this evidence map, that is a reasonable next step once you know where your current configuration cannot produce a record. A Drupal AI evidence review, the Align and Blueprint stages of our delivery system applied to your AI features, maps each feature to the record you would need to produce. It is the same review our AI-first managed services team runs on regulated Drupal environments, and the gaps are usually where the audit risk lives.