AI regulation is shifting from principles to implementation

Most organizations discover that AI is already present before the governance programme begins. It sits inside office suites, customer-service platforms, fraud tools, recruitment systems, analytics products and employee subscriptions. A register limited to projects labelled “AI” will miss much of the actual exposure.

The inventory needs to describe the use, not merely the vendor. The same model can draft harmless internal text, rank job applicants or generate customer advice. Those deployments differ in affected people, legal role, data, consequence and required oversight.

A useful record links the business owner, technical owner, supplier, model version, data categories, users, affected groups, countries, purpose, decision authority, risk class, controls, evidence, incidents and retirement status. It should be updated through procurement, change management and technical discovery rather than an annual email survey.

Risk classification fails when teams classify a vendor instead of a use case. Regulation commonly turns on purpose, affected context and the role of each actor. A company integrating a model into an employment decision may face different duties from the model provider, reseller or ordinary user.

The EU AI Act illustrates the point. It distinguishes prohibited practices, high-risk systems, transparency duties and general-purpose-model obligations. Some rules already apply, while others have phased or amended implementation dates. Commission guidelines help with system definition, prohibited practices, transparency and high-risk classification, but authoritative interpretation remains with courts and competent authorities.

Classification should therefore produce a reasoned record: facts considered, role, jurisdiction, legal sources, outcome, unresolved questions and reviewer. A drop-down menu without reasoning is difficult to defend when the use changes or guidance evolves.

A governance file often contains excellent documents that do not prove anything about the live product. A general model card, a vendor security certificate and a fairness policy may all be genuine while the production prompt, retrieval data, threshold and interface behave differently.

The evidence chain should connect requirement, risk, control, test, approval and deployed version. For example, a human-oversight claim should point to the actual review screen, the authority of the reviewer, training material, override logs and a test showing that reviewers can detect representative failures.

Versioning matters because AI services change. Providers may update a model, safety layer or data policy. Internal teams may change prompts, tools or retrieval sources. A change register and supplier-notification process determine whether old evidence remains applicable.

Impact assessments are useful when they force a decision. They should identify affected people, benefits, foreseeable harms, data flows, alternatives, distributional effects, human review, contestability and residual risk. A narrative that ends with “monitor carefully” has not assigned a control.

The assessment should test whether the proposed purpose is necessary and whether a less intrusive process could meet it. It should also describe what happens when the model is uncertain, unavailable or challenged. Human oversight must include time, information, authority and competence—not a person placed at the end of an automated queue.

Standards such as ISO/IEC 42001 and ISO/IEC 23894 provide management-system and risk-process structure. NIST’s AI RMF organizes work through Govern, Map, Measure and Manage. These frameworks do not replace legal analysis, but they help an organization build one reusable operating system rather than a separate checklist for every rule.

Procurement teams increasingly receive model cards, security reports and responsible-AI statements. The difficult question is whether those materials cover the actual service and give the customer enough information to operate it safely.

Contracts should address permitted use, data handling, retention, training on customer data, subprocessors, security incidents, model changes, service withdrawal, audit support, intellectual property, evaluation access and cooperation with regulatory requests. A promise to follow “industry best practice” is hard to test.

Customers still need their own evidence. A supplier cannot know every local workflow, affected population, user interface or human-review arrangement. For regulated or high-impact uses, the organization should maintain an exit path and preserve the records needed if the supplier changes or disappears.

A control is credible when the organization can observe whether it works. Training attendance does not prove that staff can identify a prohibited or high-risk use. A human-review policy does not prove that reviewers notice errors. A bias statement does not show performance across affected groups.

Testing should cover normal operation, edge cases, protected or vulnerable groups, misuse, security attacks, degraded inputs, model refusal, outages and change. The acceptance threshold should be set before the result is known and should reflect the consequence of error.

The test record needs enough detail to be reproducible: dataset origin, sampling, labels, model and prompt version, parameters, environment, metrics, limitations, reviewer and date. Where representative testing is impossible, uncertainty should increase oversight rather than disappear from the report.

AI governance becomes operational after launch. Inputs change, users find new purposes, suppliers update models and staff develop workarounds. The original approval can remain formally valid while the live risk has moved elsewhere.

Monitoring should combine technical and process signals: performance drift, refusal rates, overrides, appeals, complaints, incidents, data changes, prompt revisions, supplier notices, access patterns and use outside the approved purpose. Thresholds should trigger investigation or automatic restriction.

Material-change rules are essential. A new model version, new population, new country, new decision authority or new data source may require partial or full reassessment. Small wording changes should not overload the process, but a vague “minor change” category can become a route around review.

AI governance should connect with procurement, privacy, cybersecurity, product approval, model risk, accessibility, employment law, records management and incident response. Creating a parallel committee for every AI decision usually adds delay without improving evidence.

A central team can maintain the method, taxonomy, tools and difficult interpretations. Business and technical owners remain responsible for their systems. Independent legal, risk, privacy or security functions challenge the assessment according to consequence. Internal audit tests whether the process operates as described.

The result should be proportionate. Low-impact use can follow a short approved path. High-impact or uncertain use needs deeper assessment, testing and approval. Exceptions must identify the reason, owner, compensating controls and expiry date.