Most AI "governance" writing still mixes four different things: principles, law, a management-system standard, and a process model. Only the last one tells an organisation who does what, in what order, and how success is tested.
Principles (OECD, UNESCO) set norms. They do not assign work.
A management-system standard such as ISO/IEC 42001 says establish, implement, operate, monitor and improve an AI management system - and can be certified - but it deliberately avoids prescribing the full catalogue of management processes.
Board governance of AI sits one layer above that, in ISO/IEC 38500 and ISO/IEC 38507: the governing body evaluates, directs and monitors; management executes.
Risk guidance such as the NIST AI RMF (Govern-Map-Measure-Manage) is a thinking structure, not an operating model and not a certificate.
The EU AI Act makes defined processes a legal duty for high-risk providers
For providers of high-risk AI systems, Article 17 does not ask for a principle statement. It requires a quality management system that ensures compliance with the Regulation, documented "in a systematic and orderly manner in the form of written policies, procedures and instructions." Those procedures must cover compliance strategy and modification management; design control and verification; development and quality assurance; test and validation and their frequency; technical specifications; the data path; the Article 9 risk system; post-market monitoring and serious-incident reporting; communication with authorities; records; resources; and an accountability framework that assigns responsibility.
Implementation must be proportionate to the size of the provider. Proportionate does not mean "undefined." The Act requires processes to exist, to be written, and to be operated.
EN 18286 is that QMS written as a European standard
EN 18286:2026, Artificial intelligence - Quality management system for EU AI Act regulatory purposes, is the CEN/CENELEC JTC 21 standard aimed at Article 17. It specifies requirements and guidance for defining, implementing and maintaining a QMS for organisations that provide AI systems, primarily those placing high-risk systems on the market. It is not sector-specific. Publication as an EN is done; presumption of conformity under Article 40 still waits on citation in the Official Journal.
The clauses that matter for a process model are plain:
- 4.1 - the provider shall establish and maintain any process, procedure and activity necessary. The QMS is not limited to the headings someone remembered to file.
- 4.5.1 - the QMS must reference the documented processes and procedures defined in the standard. A manual that does not point at named processes is not the QMS the standard describes.
- Documented information supports the processes themselves. Clauses 8 and 9 give examples of operational documentation - realization and evaluation - not a substitute for the processes.
- 8.1 - those processes and procedures run along the AI system lifecycle.
Incorporating the requirements into existing processes is the desirable route to compliance. A second "AI QMS" that the change board and the incident path never touch is not what the standard is asking for.
So the stack is: the Act requires a QMS; EN 18286 requires that QMS to be a set of established, referenced, lifecycle processes, preferably inside work the organisation already runs. Neither instrument gives you the enterprise catalogue, board decision rights, or design-factor tailoring on its own. They require processes to be defined. A process model is how that duty becomes assigned work.
A process model sits between those instruments and day-to-day work
It turns outcomes into named processes, decision rights, controls, measures and evidence. Without it, organisations collect policies, buy a platform, and still cannot answer: who may change intended purpose, who owns residual risk, what work product an auditor or notified body samples, and how much of the catalogue is actually in scope.
Control Objectives for AI Systems (AICOB) is that process model.
A process model comprising forty processes, organised in six domains, provides the foundation for decision-making and accountability, scoping implementation, organising tasks and measuring performance.
The six domains keep governance and management apart, then run management in a linear line:
- Direct (DIR) - the governing body evaluates options and performance, sets policy and decision rights, monitors results and assurance, and holds management to account.
- Act (ACT) - management intake: a business need, a board direction, an incident, a vendor event, drift, or a change of intended purpose. Act opens the work and routes it. It is not Deming's final "Act".
- Establish (EST) - context, policy, objectives, architecture, portfolio, people, data, vendors, risk and the design of the management system. Depth is set by design factors, not by "implement all forty at the highest maturity".
- Implement (IMP) - design, acquire, build, test, change and deploy, including the intended purpose that later operation must not silently rewrite.
- Operate (OPR) - run, continuity, incidents, runtime authorisation and service. Policy attached to live systems, not only to documents.
- Review (REV) - performance, conformance, internal control, assurance and improvement. Findings return to Direct; a material finding opens a new Act.
That line is how Article 17 and EN 18286 land without inventing a parallel factory.