Practice — AI governance
Most AI failures are not compliance failures. They are management failures that a regulator, a client or a journalist later reads as compliance failures. Governance is how you run AI without the incident, the embarrassment, or the system that gets switched off mid-quarter.
Novus Point installs the operating discipline underneath the legal position. An inventory that is true. Owners who are named. Oversight that is designed rather than assumed. Reporting a board can act on. Delivery is senior-led, with the specialist advisers the work requires — AI, legal, security, data — brought in under the firm's direction and responsibility.
One of three practices — AI governance
Six patterns
It is rarely ignorance. In most organisations the people are competent, the intent is good, and the failure is structural. Six patterns recur.
01
AI entered your organisation as a browser extension, a seat on someone's personal subscription, a feature switched on inside a tool you already owned. None of it passed a review gate, because none of it looked like a purchase. The result is a capability estate nobody approved and nobody can see.
02
Ask a management team what AI systems the organisation runs and you will get a number. Ask for the list and you will get a shorter one. The gap between those two answers is the whole problem: classification, risk, oversight and reporting all depend on an inventory, and the inventory is the piece everyone assumes exists.
03
IT owns the platform. Legal owns the contract. Data owns the pipeline. The business owns the outcome. Each assumes one of the others holds the system-level risk. In a governance sense the system is unowned — which becomes visible only when something goes wrong and there is nobody to convene.
04
An AI policy approved by the executive committee, published to the intranet, and never referenced again is not governance. Governance is a control that runs: a gate that stops something, a review that happens on a date, an artefact that is produced whether or not anyone asks. A policy without an operating cadence is a document about governance, not an instance of it.
05
A tool is approved as an experiment with a small user group and a low-stakes use case. Eighteen months later it is in the client-facing path and the original risk assessment — written for the experiment — is the only one on file. Nothing was hidden. The system simply grew past its paperwork.
06
Model behaviour, data use, retention, sub-processing and incident notification are all set in supplier terms. Where those terms were signed as software procurement rather than AI procurement, the organisation has usually accepted a position it has never articulated to itself.
Seven components
Seven components. They are installed in this order because each one is load-bearing for the next.
01
A single register of every AI system in use or in build — including embedded features in third-party software and anything running on a departmental subscription. Each entry carries purpose, data touched, supplier, deployment status, business owner and the date of last review. This is the artefact everything else hangs from, and it is the piece most likely to be absent when the work starts.
02
Every entry in the register is classified: what the system does, whom it affects, what a bad output costs, and where it sits against the regulatory categories that apply to you. Classification is a sorting exercise before it is a compliance exercise, and it is where the disproportionate value is — most estates resolve into a small number of systems that need real attention and a long tail that needs a light touch and a record.
03
A policy set scoped to how your organisation really works: what staff may use, what requires approval, what is prohibited outright, how outputs must be checked before they leave the building. Written to be read by the people bound by it, not by a regulator's imagined reader. We would rather hand you four rules that hold than forty that are quietly ignored.
04
Named individuals against named decisions: who approves a new system, who may move one from pilot to production, who can suspend one, who signs off a material change. Accountability that is assigned to a committee is accountability that is assigned to nobody. We put a person's name against each right, and we write down what happens when that person is unavailable.
Human oversight — from 2 December 2027
05
Oversight is a design problem, not a reassurance. The European Commission's framing of the requirements for high-risk systems — obligations that apply from 2 December 2027 — includes "appropriate human oversight measures" alongside logging, documentation and robustness, and it expects deployers to ensure human oversight and monitoring in operation. There are two tracks, and the second is the one most organisations miss: stand-alone high-risk systems under Annex III from 2 December 2027, and high-risk AI embedded in regulated products under Annex I from 2 August 2028. That means specifying who reviews what, at what point in the workflow, with what authority to override, and with what information in front of them. A reviewer who cannot see why the system produced an output, or cannot overrule it without escalating, is not oversight. They are a signature.
Serious-incident reporting — from 2 December 2027
06
Logging sufficient to reconstruct what a system did and why — the Commission lists "logging of activity to ensure traceability of results" among the requirements for high-risk systems, and it is good practice well below that threshold. Then the route: how a suspected AI incident is raised, who triages it, what the containment options are, who decides on notification, and how it reaches the board. Serious-incident reporting will apply to providers, with a corresponding duty on deployers to inform, once the high-risk obligations apply from 2 December 2027 for stand-alone Annex III systems, and from 2 August 2028 for high-risk AI embedded in regulated products under Annex I. A route that is invented during the incident is not a route.
07
A standing report the board can actually use: how many systems, in which risk categories, what changed this quarter, which controls are operating and which are not, what is escalating. Directors do not need model detail. They need to know that the estate is known, that ownership is assigned, and where the unresolved exposure sits — in a form they can minute.
The firm
Jakub Piórkowski
Founder & Principal · London & Dubai
We do not only advise on AI. The firm builds and runs AI systems in production: Hadar AI, a CRM for Dubai real-estate brokerages, and ADOZ. The inventory, ownership and oversight questions on this page are questions we answer about our own estate before we ask them about yours.
The practice is led by its Founder and Principal, Jakub Piórkowski, Chairman of the Supervisory Board of Carlson Investments SE, listed on the Warsaw Stock Exchange (WSE: CAI), elected August 2026. Board reporting on this page is written from both sides of the table.
ISO/IEC 42001 · NIST AI RMF
Two frameworks dominate the conversation. Both are useful. Neither is a compliance shortcut, and the difference matters more than most of the market admits.
Standard
Published in December 2023 and adopted in the UK as BS ISO/IEC 42001:2023, Information technology. Artificial intelligence. Management system. It specifies requirements and provides guidance for establishing, implementing, maintaining and continually improving an AI management system within an organisation. It is a management system standard in the ISO tradition — governance, roles, objectives, controls and a continual improvement cycle — and it is certifiable. The certification infrastructure around it is still forming. To be plain about our own position: certification is performed by accredited certification bodies, not by us. We are not a certification body, we do not audit for a certificate, and we will not tell you a certificate is compliance.
Framework
The NIST AI Risk Management Framework (AI RMF 1.0), released on 26 January 2023, is "intended for voluntary use" and organised around four functions — Govern, Map, Measure and Manage. It was developed through an open, consensus-driven process, and its stated purpose is to help organisations build trustworthiness considerations into how AI systems are designed, developed, used and evaluated. A Generative AI Profile (NIST-AI-600-1) followed in July 2024.
The difference
Adopting either signals seriousness to a buyer, an insurer or a board: it says the organisation has chosen a recognised control taxonomy and accepted an external review cadence. What it does not do is settle your position under the EU AI Act.
European harmonised standards for the Act are in development but not yet finalised, and none has yet been referenced in the Official Journal. That reference is the step that matters: a product or system is presumed to satisfy the essential requirements if it complies with harmonised standards referenced in the Official Journal. Until then, no standard carries the presumption of conformity.
On ISO/IEC 42001 specifically: it is a management system standard written for a different purpose, and its goals and definitions do not line up with the quality management system the Act requires.
Our position
As scaffolding, not as scripture. We take the control taxonomy from ISO/IEC 42001 and the Govern and Map functions from the NIST framework, map them against your actual estate, and keep only what earns its place. Where you intend to certify later, we build the artefacts in a shape that will survive an accredited audit. Where you do not, you still get the discipline without the overhead.
The UK government's own AI Management Essentials tool — a self-assessment drawing on ISO/IEC 42001, the NIST framework and the EU AI Act, published for consultation and explicit that it "does not provide formal certification" — is a reasonable reference point for smaller organisations, and we will say so when it is the proportionate answer.
The commercial case
The compliance case for governance is well rehearsed. The commercial case is stronger and less often made.
01
Enterprise buyers, public bodies and regulated clients have added AI sections to their supplier questionnaires: what do you run, on what data, with what oversight, under what incident process. An organisation with a register, an owner map and an oversight specification answers it from existing artefacts. An organisation without them assembles an answer from scratch — one that is, at best, partly true — and the delay itself is read as a signal.
02
The UK government has publicly backed the growth of a third-party AI assurance market, and a supplier base of auditors, testers and assurance providers is forming around it. Markets of that shape form around demand from buyers who have started requiring evidence. That demand is what lands on your desk as a questionnaire.
03
Whatever the wording, the underlying request is identical: show us that this is managed, not merely permitted.
04
Fines are avoided losses, and avoided losses never appear in anyone's numbers. Deals won because you could evidence control while a competitor could not — those appear. Governance built properly is a sales asset that also happens to reduce regulatory exposure, and that is the order in which we would argue it to a commercial board.
The entry product
AI governance sits under the firm's entry product: the audit. Three steps, and you can stop after any of them.
01
We ask what you run, who touches it, what you have already committed to contractually, and what has already gone wrong. You get a straight answer on the call about whether this is worth taking further.
02
A short document written to be handed to a board: what you have, where the exposure sits, what to do first and what can wait.
03
Scoped to the position document and priced before it starts.
Alongside AI governance, the audit covers EU AI Act compliance and AI automation.
Deliverables, at artefact level
We will not promise you compliance — the regulator decides that, not us. What we give you is an accurate picture and a defensible order of work.
Who we work with
01
The question came from the board or from a client's legal team. You cannot answer it, because the answer depends on an inventory that does not exist and a classification nobody has performed.
02
Several AI tools have moved from experiment to daily dependency without a second review. You need to know which of them are now load-bearing, and what would happen if one produced a materially wrong output tomorrow.
03
Your security controls are mature. They were designed for confidentiality, integrity and availability — not for model behaviour, output quality, human oversight or the fundamental-rights dimension that AI regulation is written around. You need the delta, not a second security programme.
04
You are not asking for a model architecture briefing. You are asking whether the estate is known, whether ownership is assigned, and whether anyone would be able to evidence either of those tomorrow morning.
05
A deal is sitting behind an AI section of a supplier questionnaire that your organisation cannot currently answer. The governance work is, in that moment, sales work.
Frequently asked
01
No, and the reason is precise rather than dismissive. Security controls protect a system from unauthorised access, alteration and outage. AI governance addresses a different failure mode: a system that is entirely secure, entirely available, and confidently wrong — or right in a way that affects a person and cannot be explained, reviewed or overturned. Your security programme is a prerequisite and a large head start. It does not cover inventory of AI capability, risk classification, human oversight design, output verification or board reporting on model-driven decisions. We map what your existing controls already satisfy and scope only the delta. Nobody benefits from a second parallel programme.
02
Different regulated object. Data protection law regulates the processing of personal data — lawful basis, purpose, minimisation, rights of the individual. AI regulation and AI governance address the system itself and its lifecycle: what it is for, how it was built and tested, who oversees it in operation, how its behaviour is logged, and what happens when it fails. The two overlap heavily and the artefacts often share evidence, but a complete data protection position tells you nothing about whether an AI system is classified, owned, overseen or monitored. In practice we treat your existing data protection work as an asset to be reused, not repeated. Where the overlap turns on a point of law or data architecture, we bring in legal and data specialists under the firm's direction, alongside the work already in train.
03
Less than directors fear and more than most currently do. The board does not need to understand model architecture. It needs to be able to demonstrate three things: that the organisation knows what AI it runs, that accountability for each system is assigned to a named individual, and that there is a route by which failures reach the board rather than stopping below it. Practically, that means a standing item, a report it can interrogate, and a minuted record of the decisions it took on the basis of that report. Where an obligation applies to your staff rather than your software, the same logic holds. AI literacy under Article 4 has applied since 2 February 2025, and Article 4 was reworded by Regulation (EU) 2026/1744, in force from 27 July 2026, into an obligation of means: organisations must take measures that support the development of AI literacy. That is a lower bar to state and a harder one to leave undocumented — the board's duty is to be able to evidence that those measures were taken.
04
Sometimes. Certification is worth real money when your buyers ask for it, when you sell into procurement processes that score it, or when an external audit cadence is the only thing that will keep the discipline alive internally. It is worth much less if it becomes an exercise in producing documents for an auditor while the estate stays unmanaged underneath. And it is not a substitute for a position under the EU AI Act — a management-system certificate is not the quality management system the Act requires, and its goals and definitions do not line up with it. Our usual advice is to build the governance first in a shape that would survive certification, then certify if and when there is a commercial reason to.
05
That is a question of fact about your systems, your users, your suppliers and the markets you sell into — and we will not answer it from a webpage. It is one of the first things the written position settles, in writing, with reasons. Separately: much of what we put in place here is not driven by the Act at all. Inventory, ownership, oversight and incident routes are what stop an AI system embarrassing you or being switched off mid-quarter, in any jurisdiction. The regulatory question determines how formal the artefacts need to be. It does not determine whether you need them.
Next step
We take a limited number of engagements each quarter. If we are not the right firm for this, we will tell you on the call rather than after the invoice.
Request a 30-minute diagnostic
jakub@novus-point.co.uk — every enquiry is answered at principal level.
