Responsible AI in compliance: what ISO/IEC 42001 changes in practice
That distinction matters for compliance technology. A plausible but incorrect answer in a general productivity tool may be inconvenient. An incorrect output in a statutory reporting, e-invoicing or digital-identity process can contribute to a rejected filing, an invalid document, an inappropriate access decision, a missed deadline or an audit finding. Responsible AI therefore requires an operating system for governance, not simply an ambition to innovate.
ISO/IEC 42001:2023 provides that management-system perspective. ISO describes it as the international standard specifying requirements for establishing, implementing, maintaining and continually improving an Artificial Intelligence Management System (AIMS). It is intended for organisations that develop, provide or use AI-based products and services.
An AI policy is only the beginning
Many organisations started with an acceptable-use policy for generative AI. Such a policy is valuable: it can define prohibited data, approved tools and basic responsibilities. But it does not answer the questions that determine whether AI is controlled in practice.
A functioning AIMS connects policy to ownership, risk assessment, competence, supplier governance, lifecycle controls, monitoring, incident management, internal audit and continual improvement. It asks not only whether a model performs a task, but whether it should perform that task, under which conditions, with what data, and with what safeguards when the output is wrong.
This is an important shift. AI governance is not a project owned solely by an innovation team or an information-security function. It requires coordinated decisions by management, product, engineering, privacy, legal, compliance, quality, procurement and operations. The controls must become part of the organisation's normal way of working.
Start with visibility: know where AI is used
An organisation cannot govern AI it does not know it is using. A practical first control is therefore an AI-system inventory covering customer-facing capabilities, development tools, internal business applications and AI embedded in third-party services.
For each use case, the inventory should identify the purpose, accountable owner, provider, users, data inputs, outputs, dependencies, affected stakeholders, risk classification, approval status, controls and monitoring arrangements. This makes decentralised and supplier-provided AI visible, including functions that may have appeared in an existing cloud product after a routine update.
The inventory should support innovation rather than become a static register. New ideas can enter through a defined assessment path, while unapproved or obsolete uses can be identified and addressed. Visibility makes responsible experimentation possible because teams know which questions must be answered before deployment.
Apply controls in proportion to the consequences
Not every use of AI creates the same risk. Improving the wording of non-confidential internal text is fundamentally different from proposing a mapping between financial data and a regulatory taxonomy, influencing an identity decision or flagging a transaction as suspicious.
A risk-based approach considers intended purpose, data sensitivity, stakeholders, degree of autonomy, legal and contractual obligations, likelihood of error, severity of impact, reversibility and the availability of effective human review. Higher-impact applications may require formal impact assessments, stronger testing, enhanced logging, explainability, independent approval, fallback procedures and continuous monitoring.
Proportionate governance also preserves the option not to use AI. Some compliance outcomes should remain deterministic, rules-based or fully human-controlled. Responsible innovation is not measured by how many processes contain AI; it is measured by whether AI adds value without weakening the certainty the process is intended to provide.
Keep authoritative rules separate from probabilistic assistance
Traditional compliance software often applies explicit specifications and validation rules. Many AI systems, by contrast, produce probabilistic outputs that may vary with prompts, context, model versions, training data or supplier configuration. Their responses can sound confident even when they are incomplete.
The control design must reflect that difference. AI may help a user understand a validation message, compare disclosures, classify a document or propose a mapping. The official taxonomy, filing rules, technical specification and deterministic validations must remain authoritative. A suggestion should be clearly labelled, reviewable, traceable and reversible before it influences a statutory result.
The same principle applies to e-invoicing. AI can support exception handling or anomaly detection, but an anomaly is a signal, not proof of non-compliance or fraud. The applicable specification and validation controls must determine whether the invoice is technically compliant, while qualified people decide how an exception should be handled.
Digital identity demands even greater care because AI-supported outputs may affect authentication, access or legally significant transactions. Accuracy, security, privacy, fairness, explainability, appeal mechanisms and human intervention should be designed into the full use case.
Human oversight must be meaningful
Organisations often say that a human remains 'in the loop'. That phrase is not sufficient. Oversight is meaningful only when the reviewer has the information, competence, authority and time needed to challenge the output and change the outcome.
A reviewer may need access to the source data, applicable rule, model or service version, confidence indicators, known limitations and supporting evidence. The interface must make it possible to correct or reject the proposal, record the reason, escalate uncertainty and suspend the process when necessary.
This matters because automation bias can turn formal approval into ceremonial approval. If reviewers routinely accept AI output without understanding it, the presence of a human does not provide a reliable control. Training should therefore address both the intended capability and the circumstances in which the system should not be trusted.
Govern suppliers and model changes
Many organisations do not build the models they use. Their AI capability may depend on a cloud platform, software supplier, foundation-model provider, data source or specialist service. Outsourcing the component does not outsource accountability for the use case.
Supplier assessment should cover security and privacy, data locations, retention and training practices, subcontractors, technical documentation, testing evidence, incident notification, service continuity, portability and exit arrangements. Contracts and operating procedures should reflect the impact of the use case, not only the commercial importance of the supplier.
Change control is particularly important. A supplier can update a model, safety mechanism or configuration without changing the name of the service. Behaviour that was acceptable during initial testing may shift. Organisations need notification where possible, version visibility, regression tests for critical scenarios, defined acceptance criteria and a fallback if a material change cannot be approved.
Monitor performance after deployment
Pre-deployment testing is necessary but not sufficient. AI performance can change when data, user behaviour, regulatory requirements, operating conditions or model versions change. Monitoring should therefore be tied to the purpose and risk of the use case.
Relevant measures may include accuracy, error rates, false positives and false negatives, human override rates, complaints, security events, data-quality issues, response time and evidence of drift. The important point is not to collect every possible metric, but to define which signals matter, who reviews them and which threshold triggers investigation, restriction, retraining, rollback or suspension.
Monitoring should also test whether the process around the model remains effective. Are people still reviewing the right cases? Are exceptions being escalated? Are supplier changes being assessed? Does the fallback work? A technically stable model can still operate within adeterioating control environment.
Treat AI incidents as organisational incidents
An AI incident may involve inaccurate output, unintended disclosure, biased treatment, model unavailability, prompt manipulation, corrupted data or a supplier change that alters behaviour. The response should connect with existing security, privacy, quality, service and business-continuity procedures.
A disciplined response identifies and contains the issue, determines affected outputs and stakeholders, preserves evidence, corrects the immediate problem and addresses the underlying cause. Where customers or partners may have relied on a material output, notification and remediation responsibilities should be clear. Lessons should feed back into risk assessment, testing, training and supplier governance.
Integrate AI governance with the wider management system
ISO/IEC 42001 does not replace information security, privacy, quality, service management or continuity. It provides an AI-specific management layer that connects those disciplines to the AI lifecycle.
For example, information-security controls can protect an AI service and its data from unauthorised access, while AI governance addresses whether the intended use is appropriate, whether output limitations are understood and whether oversight is adequate. Quality processes can support testing and corrective action, while the AIMS makes AI-specific performance, impact and change part of those processes.
Integration prevents duplicate administration and improves evidence. Existing risk registers, supplier reviews, training programmes, incident procedures, audits and management reviews can be extended with AI-specific criteria. The goal is not another isolated compliance programme, but a coherent system of accountability.
What effective ISO/IEC 42001 implementation should change
A credible implementation should be visible in daily decisions. It should influence how AI ideas are proposed, assessed, acquired, designed, tested, approved, deployed, monitored and retired. It should affect documentation, supplier agreements, staff competence, customer information, release management and incident response.
Five questions provide a useful practical test:
1. Where is AI used, including within suppliers and embedded tools?
2. What decision or process can the output influence, and what is the potential consequence of error?
3. Which source, rule, validation or qualified person remains authoritative?
4. What evidence allows the result and subsequent decision to be reconstructed?
5. How will changes, degraded performance and incidents be detected and handled?
If these questions cannot be answered, the use case is not ready for uncontrolled operational use, regardless of how impressive the demonstration appears.
Semansys: responsible AI for dependable compliance technology
Semansys has implemented the ISO/IEC 42001 framework and associated controls within its wider trust and governance environment. This supports the controlled use of AI across internal operations and relevant product development, while preserving the role of authoritative rules, deterministic validation and qualified human judgement.
The purpose is not to add AI to every product. It is to use AI where it creates measurable value, apply stronger controls where consequences are greater and remain accountable throughout the lifecycle. That approach reflects the reality of regulatory technology: innovation is valuable only when customers can continue to rely on the outcome.
Governance is what makes AI scalable
The next phase of AI adoption will be shaped less by experimentation and more by evidence. Customers, auditors and regulators will increasingly ask where AI is used, which data it processes, how it was tested, who approved it, how its output is reviewed, how suppliers are controlled and what happens when the technology fails.
ISO/IEC 42001 provides a recognised structure for answering those questions. It does not promise that AI will never make a mistake. It creates the management discipline needed to understand limitations, control risk, demonstrate accountability and improve over time.
In compliance technology, that discipline is not an obstacle to innovation. It is what makes responsible innovation sustainable.
Discuss responsible AI and controlled automation with Semansys: Book a discovery call