AI Governance and Compliance

What does the law actually require of an AI system?

Less than the headlines suggest in some places, and considerably more in others. The gap matters because compliance effort is finite and tends to flow toward whatever was reported most loudly rather than whatever carries the nearest deadline.

That is the working assumption behind this cluster. Every article here starts from a primary document: a regulation, an official guidance note, an enforcement action, a filed complaint, a published audit. Where a claim appears about what you must do, the article names the instrument, the article number and the date it starts to bind, so the obligation can be checked rather than taken on trust.

Which obligations bind, and which are advisory?

The distinction is the single most useful thing to get straight, and it is rarely drawn clearly:

• Binding with a date. An in-force regulation with a compliance deadline and a named enforcement body. The EU AI Act is the clearest current example, and its dates are staggered rather than single: it entered into force on 1 August 2024, prohibited practices and AI literacy obligations applied from 2 February 2025, governance and general-purpose model rules from 2 August 2025, general application arrived on 2 August 2026, and the high-risk obligations for sensitive areas do not bite until 2 December 2027, with high-risk systems inside regulated products following on 2 August 2028.
• Binding but indirect. Existing law applied to AI conduct. Most enforcement so far has come this way, through consumer protection, data protection and anti-discrimination rules that never mention AI at all. The EDPB publishes the European decisions in this category, and they are worth reading before any AI-specific guidance.
• Advisory, and useful anyway. Frameworks like the NIST AI Risk Management Framework carry no penalty. They matter because procurement contracts and auditors adopt them, which turns a voluntary framework into a commercial requirement without any law changing.
• Announced but not yet operative. Consultations, draft guidance and political commitments. Worth tracking, worth planning for, and not yet a reason to change what you ship.

Treating all four as one category is how teams end up documenting the wrong things thoroughly.

Why does published policy diverge from shipped behaviour?

Because policy is written once and systems change weekly. A model card, a data protection impact assessment or a published usage policy describes an intended configuration at a moment in time. The deployed system drifts: a prompt changes, a retrieval corpus grows, a vendor swaps a model version under a stable API name.

Very little governance tooling notices that drift, which is why the interesting findings tend to come from measurement rather than from reading policy documents. Comparing what a system claims to do against what it observably does is the most productive question in this area, and it is one an engineer can answer directly.

What counts as evidence here?

A finding rather than an opinion. Articles in this cluster are built on something checkable: a clause in a regulation, a decision by a supervisory authority, a number reproduced from a published dataset, or a behaviour observed and recorded from a live system with the method written down.

Where the site takes a position, it is labelled as a position and kept separate from the finding it rests on. Where a question is genuinely open, the article says so rather than resolving it for narrative tidiness. Regulatory writing attracts confident summarising, and confident summarising of a document nobody opened is the failure mode worth avoiding.

How should you read this cluster?

As a working reference rather than news. Each article states the instrument it relies on, the date that instrument takes effect, and what a team would concretely do about it, so that the guidance survives longer than the news cycle that prompted it.

Where an obligation later changes, the article is updated and the change is dated in public. That matters more here than elsewhere on the site, because a compliance claim that quietly goes stale is worse than no claim at all.