The Digital Omnibus pushed the EU AI Act's high-risk obligations out to 2027 and 2028, so many teams assumed they had breathing room. Article 50 was not part of that delay. Its transparency duties have applied since 2 August 2026, they cover ordinary chatbots and AI-generated content, and one marking deadline still lands on 2 December 2026.
If you already run ISO 27001, a large part of ISO 42001 is a system you have already built. The management structure carries over almost wholesale. What is genuinely new is the AI-specific substance: the impact assessment, the AI controls, and a risk lens that reaches beyond your own organisation.
The EU AI Act assigns obligations by role, not by company. Most organisations using AI are deployers, some are providers, and many are both. Here is how to work out which you are for each system, and the trap that turns a deployer into a provider.
Boards are accountable for AI risk whether or not they understand the technology. What leadership actually needs is not how models work, but the right questions to ask, a named owner, and evidence that oversight exists.
ISO 42001 is a management system standard, so it looks like a job for a management systems specialist. That is half right. Governing AI well also takes someone who has built AI, because you cannot write a real control for a system you do not understand from the inside.
If your AI runs on Databricks, much of what a governance framework demands can be generated by the platform rather than assembled by hand. How Unity Catalog, the Unity AI Gateway and lineage map to ISO 42001 and the EU AI Act.
Databricks managed MCP servers let AI agents reach your Unity Catalog data, Genie spaces and functions through one governed interface, with Unity Catalog permissions enforced on every call.
Most AI policies fail, not in the writing, but in the following. A document nobody reads is governance theatre, and worse than nothing because it gives false assurance. Here is why AI policies get ignored, and how to build one that actually changes behaviour.
Using an LLM to grade AI output is scalable and often the only practical way to evaluate open-ended work. But an unvalidated judge is just another AI making decisions you cannot account for. Here is how LLM-as-a-judge fails, and how to build one you can actually trust.
Evaluating an agent is a different problem from testing a chatbot. A single right answer tells you almost nothing: you have to grade the whole path it took, its reliability across repeated runs, and whether it stayed in bounds. Here is how to evaluate agents properly.
The EU's Digital Omnibus defers the AI Act's high-risk obligations to December 2027. But it does not delay everything, it is not yet law, and it is not a reason to down tools. Here is exactly what moved, what did not, and what to do with the extra runway.
Self-assessment has a ceiling. Some claims about your AI only carry weight when an independent party stands behind them. This is what third-party AI assurance is, how it differs from certification and audit, what an engagement examines, and how to get assurance-ready.
You probably already test your AI. The gap is turning those results into evidence an auditor or regulator will accept. Here is how evaluation maps onto ISO 42001 and the EU AI Act, and how to structure your testing as an audit trail instead of an engineering side-note.
Clause 10 is what makes the AI management system a living thing rather than a snapshot. It commits you to continual improvement and gives you a disciplined way to handle things that go wrong: nonconformity and corrective action. Here is what Clause 10 requires, and why it closes the loop.
Clause 5 is where AI governance either gets real or stays a slide deck. It puts three duties on top management: lead and commit, set an AI policy, and assign clear roles and authority. Here is what Clause 5 actually requires, and why auditors treat weak leadership as a fail.
Clause 6 is the engine room of ISO 42001. It is where you assess AI risk, treat it, produce a Statement of Applicability against Annex A, assess system impact, and set measurable objectives. This is the clause auditors spend the most time on. Here is what it actually requires.
Clause 7 is what makes the plan runnable. It covers the resources, competence, awareness, communication and documented information the AI management system needs to actually function. Neglect it and a well-designed system quietly stops working. Here is what Clause 7 requires.
Clause 8 is where the plan meets reality. It requires you to run the processes you designed, and to actually perform your AI risk assessment, risk treatment and impact assessment, not just once at build time, but on a schedule and whenever things change. Here is what Clause 8 requires.
Clause 9 is how you find out whether the AI management system actually works. It requires you to monitor and measure it, audit it internally, and have leadership review it. This is where governance stops taking its own word for it. Here is what Clause 9 requires.
Accuracy is the metric everyone reaches for and the one that hides the most. If you want to know whether an AI system is safe to ship, these are the metrics that predict how it behaves in the real world: faithfulness, relevance, safety, calibration, task success, and the operational numbers underneath them.
Clause 4 is where an AI management system starts. It asks you to define your context, your interested parties, your role in the AI value chain, and the scope of the system. Get it wrong and everything built on top inherits the mistake. Here is what Clause 4 actually requires, in plain terms.
A practical ISO 42001 checklist, grouped the way the standard is: scope and leadership, your AI inventory, risk and impact assessment, the Annex A controls, competence, monitoring and audit. Use it as a gap analysis to see what you have and what is missing before you certify.
Human oversight is the most-claimed and least-delivered AI control. The EU AI Act (Article 14) makes it a legal requirement for high-risk AI, but a human who rubber-stamps the output is not oversight. Here is what the Act actually asks, and what meaningful oversight looks like in practice.
"Build an agent" is the default answer to every AI problem right now. It is usually the wrong one. Most tasks are better served by a workflow, cheaper, more predictable, easier to trust. Here is the real distinction, and how to tell when a task genuinely needs an agent.
Most AI pilots never reach production. An MIT study in 2025 found 95% of enterprise generative-AI pilots delivered no measurable impact on the bottom line. The reasons are boringly predictable, and fixable. Here is why pilots die, and how to be the 5% that ships.
AI assurance is how you prove your AI is trustworthy: measuring, evaluating and communicating it so a customer, regulator or board can place justified trust in it. It is fast becoming a condition of selling AI. Here is what it is, the techniques involved, and how to get assurance-ready.
The EU AI Act puts a whole set of obligations on general-purpose AI (GPAI) models like GPT, Claude and Gemini. The good news for most businesses: those duties fall on the model makers, not on you. Here is what the GPAI rules actually are, and the one trap, fine-tuning, that can put them on your plate.
An AI impact assessment asks who your AI could harm, and how badly, before it goes live. It is required by ISO 42001, detailed by ISO 42005, and, for some organisations, made law by the EU AI Act as a FRIA. Here is what it is, how it differs from a DPIA, and how to actually run one.
You cannot fully eliminate LLM hallucinations, but you can engineer them down to a rate you can live with. The trick is to stop treating it as a prompt problem and build a layered system: ground the model, make it cite, verify the answer, and gate what ships. Here is what actually works in production.
An AI policy is the top-level document that sets how your organisation uses AI. Under ISO 42001 it is the anchor of your AI Management System, not a standalone PDF. Here is what to put in one, a template you can adapt, and how to make it stick.
When a RAG system gives wrong or vague answers in production, the model is almost never the problem. It is retrieval: the system fetched the wrong context, too little, or none at all. Here is where retrieval breaks and how to make it reliable.
Article 4 of the EU AI Act requires providers and deployers to ensure a sufficient level of AI literacy among the people using AI on their behalf. It has applied since February 2025, it is not limited to high-risk AI, and it is one of the easiest duties to meet, and to overlook.
Most AI risk now comes from tools you buy, not models you build. Evaluating a vendor well is how you avoid buying a liability: what happens to your data, how it is secured, whether it locks you in, and whether it helps or hinders your own compliance. Here is a practical way to do it.
An AI agent is a system that takes a goal and pursues it: reasoning, using tools, and taking multi-step actions in your systems, not just answering a question. Here is what that means, how they work, and where they earn their place in a business.
An AI system register is the single, maintained inventory of every AI tool, model and feature your organisation uses. It is the foundation the rest of AI governance sits on. Here are the fields that actually earn their place, and how to keep it from rotting.
Risk classification is how you decide which AI systems need heavy controls and which need almost none. It is the step that turns an AI inventory into a governed one, and both ISO 42001 and the EU AI Act depend on it. Here is a practical method.
The EU AI Act is law that tells you what you must do with AI. ISO 42001 is a voluntary standard that tells you how to organise to do it. They are complementary, not alternatives, and a well-run ISO 42001 system gives you most of the machinery the Act expects.
Shadow AI is the AI tools your staff use for work without approval or oversight. It is now the norm: staff at over 90% of companies use personal AI tools, while only 40% have sanctioned ones. Finding it is the first step to governing it.
An AIMS is the running set of policies, roles, processes and records you use to govern AI, defined by ISO 42001. It is not one document; it is a system you operate: an AI policy, an inventory, risk classification, controls, accountability, oversight, monitoring and an evidence trail.
ISO 42001 is the international standard for managing AI responsibly. You need it if customers demand it or you sell AI and must prove governance. Most other organisations need the governance it describes, but not the certificate yet.
MCP is an open standard that lets AI assistants connect to your tools and data through one common interface. Build the connection once, and any MCP-compatible AI can use it.
If the task follows the same rules every time, you need automation. If it needs judgement on inputs that vary, you need an agent. Most business processes need automation more often than teams expect.
The EU AI Act phases in over several years. AI literacy and banned practices are in force now, transparency lands on 2 August 2026, and under the Digital Omnibus the high-risk duties are deferred to 2 December 2027.
If you use AI rather than build it, you are a deployer, and the EU AI Act still gives you real duties: AI literacy and banned-practice rules now, transparency from 2 August 2026, and, under the Digital Omnibus, high-risk obligations deferred to 2 December 2027.
You can't improve what you can't measure, and you can't ship AI safely without a way to catch regressions. Here is why the eval harness comes first.
Agentic systems take actions, not just produce text. Governance is what makes those actions safe to ship. Here is the working definition we build against.