An organization adds an AI assistant to customer support. It works well during a demo, but nobody has defined which data it may use, how harmful answers are detected, who approves a model change, or what happens when an AI-generated recommendation causes an unexpected outcome. This is not only a model-quality problem. It is an AI governance and management-system problem.
ISO/IEC 42001:2023 is an international requirements standard for establishing, implementing, maintaining, and continually improving an Artificial Intelligence Management System (AIMS). It can apply to organizations developing, providing, or using AI systems. ISO/IEC 42001 supports responsible AI governance but is not itself a blanket statement of compliance with every AI law. There is no universal five-level ISO/IEC 42001 maturity scale; voluntary certification assesses management-system conformity within a defined scope.
Why ordinary security controls are not enough
ISO/IEC 27001 helps manage information security risks such as unauthorized access and service disruption. AI systems add more distinct concerns: unreliable outputs, model performance degradation, bias or unfair impacts, inappropriate autonomy, insufficient transparency, unclear data provenance, intellectual-property issues, and potentially harmful reliance on automation.
An AIMS connects those concerns to accountability, lifecycle management, impact assessment, documented risk treatment, and oversight. The two management systems can share processes such as document control, vendor review, internal audits, corrective actions, and leadership reviews, while keeping AI-specific assessments distinct.
The AI management lifecycle
AI policy and governanceInventory AI uses and stakeholdersAI risk and impact assessmentsSet controls and acceptance criteriaDevelop, procure, or deployTest and evaluateMonitor in operationReview incidents and improve
The standard uses management-system requirements including organizational context, leadership, planning, support, operation, performance evaluation, and improvement. It also includes AI-specific implementation guidance and controls. The standard’s actual applicability and documentation requirements must be determined from the licensed text and your business context.
Step 1: Define the AIMS scope and AI inventory
Start with the organization’s AI systems and uses, not only the models its engineers build. Include externally hosted large language models, automated decision-making, recommendation systems, internal copilots, classifiers, prediction services, and AI features supplied by vendors when relevant to scope.
Example inventory for Northstar Mobility:
| AI system | Business purpose | Important stakeholders | Key concern | Accountable owner |
|---|---|---|---|---|
| Support assistant | Draft replies to customer tickets | Customers, agents | Disclosure of private data; unreliable instructions | Support lead |
| Fleet anomaly detector | Flag unusual vehicle telemetry | Operators, customers | Missed incidents or false alarms | Product owner |
| Developer code assistant | Suggest code and tests | Engineers, customers | Insecure code and exposure of confidential source | Engineering lead |
For each system record its provider, model/version, interfaces, training or reference data categories, permitted and prohibited uses, geographic and contractual constraints, level of human oversight, user disclosures, lifecycle stage, and retirement plan.
Step 2: Establish policy and roles
Leadership approves an AI policy outlining objectives, responsibilities, acceptable uses, risk assessment, approval boundaries, data handling, monitoring, escalation, and continual improvement. Clearly distinguish roles: system owner, business decision-maker, AI engineering owner, data steward, security/privacy reviewer, procurement owner, and independent audit function.
An acceptable-use statement such as ‘Employees may use AI responsibly’ is too vague by itself. Add operational rules: what data may be sent to external services, which outputs require human verification, who can deploy a model, who may change prompts or tools, and what events trigger review.
Step 3: Assess AI-specific risks and impacts
Risk analysis asks what could go wrong and how to manage uncertainty. AI system impact assessment considers effects on individuals, groups, and society where relevant. The two are related but distinct activities.
For a support assistant, examine scenarios such as:
| Scenario | Potential effect | Possible treatment |
|---|---|---|
| Assistant exposes customer account details | Privacy/confidentiality harm | Authenticated retrieval, access filters, logging safeguards |
| Assistant invents a warranty promise | Customer and legal harm | Human approval for contractual statements; approved knowledge sources |
| Tool-enabled assistant performs unauthorized actions | Financial or service harm | Restricted tool permissions, confirmations, transaction limits |
| Quality degrades after data/model change | Service harm | Versioning, regression tests, monitoring and rollback |
| Outputs treat users inconsistently | Fairness and customer trust issues | Representative evaluations, complaints process, impact review |
Define scope, severity, likelihood or other appropriate risk considerations, affected stakeholders, existing controls, owner, residual exposure, and approval. Do not treat a single generic 1-5 score as a replacement for context-sensitive AI impact analysis.
Step 4: Establish AI lifecycle controls
A responsible development and deployment process should cover:
- Data governance: permitted sources, quality, lineage, rights, retention, and privacy/security requirements.
- Model and supplier selection: intended use, limitations, evaluation, contractual responsibilities, and provider change management.
- Design and build: human oversight, access boundaries, tool authorization, prompt/data handling, explainability and transparency appropriate to context.
- Testing: functional performance, safety and misuse scenarios, robustness, privacy, security, fairness where relevant, and known limitations.
- Deployment: approvals, version records, rollback capability, controlled changes, and stakeholder communication.
- Operations: monitoring, user feedback, incident handling, periodic reassessment, and decommissioning.
For generative AI, include prompt injection and tool misuse in security evaluations. A prompt instruction is not a trustworthy substitute for backend authorization checks; system permissions must enforce permitted actions independently of what the model says.
Hands-on lab: Evaluate a toy AI assistant before release
This exercise simulates a model evaluation dataset. It does not call an external AI API, so no credentials or customer information are required. Create ai_evaluation_lab.py:
cases = [
{"id": "C1", "expected": "escalate", "predicted": "escalate", "high_impact": True},
{"id": "C2", "expected": "answer", "predicted": "answer", "high_impact": False},
{"id": "C3", "expected": "refuse", "predicted": "answer", "high_impact": True},
{"id": "C4", "expected": "escalate", "predicted": "escalate", "high_impact": True},
]
accuracy = sum(c["expected"] == c["predicted"] for c in cases) / len(cases)
critical_failures = [
c["id"] for c in cases
if c["high_impact"] and c["expected"] != c["predicted"]
]
print(f"toy accuracy: {accuracy:.0%}")
print("high-impact mismatches:", critical_failures)
release_approved = accuracy >= 0.90 and not critical_failures
print("demo release gate:", "PASS" if release_approved else "BLOCK")
Code language: PHP (php)
Run python3 ai_evaluation_lab.py or py -3 ai_evaluation_lab.py. The output should show 75% toy accuracy, one high-impact mismatch (C3), and a blocked release. Discuss why a seemingly respectable aggregate score may hide unacceptable high-impact failures.
Important: the 90% gate is arbitrary training data, not an ISO requirement or sufficient AI safety measure. Real evaluations require representative datasets, meaningful metrics, statistical confidence, domain-specific risk thresholds, adversarial cases where appropriate, and human review.
Step 5: Build a credible operating evidence trail
For AI audit readiness, maintain an inventory, documented scope, policy, risk and impact assessments, approval records, evaluation plans/results, dataset and model change history, supplier reviews, incident records, monitoring results, user feedback, and corrective actions.
A practical evidence linkage:
| Management concern | Example evidence |
|---|---|
| Who approved this AI use? | Business approval and accountable owner |
| Which data can be accessed? | Data lineage, permissions, retention and supplier terms |
| What does the system fail at? | Evaluation results, limitations, risk register |
| What happens when a model changes? | Change record, regression results, approval |
| What if a harmful output occurs? | Escalation protocol, incident record, corrective actions |
| Does the program improve? | Internal audit findings and management review decisions |
A helpful control is one that demonstrably changes behavior. For example, ‘human in the loop’ is not a reliable safeguard if the human has no time, authority, or information to reject a poor model recommendation.
Integrate AIMS with an existing ISMS
If an organization already operates ISO/IEC 27001, reuse where appropriate: document control, management review, audit schedules, supplier due diligence, incident response governance, risk ownership, and corrective actions. Add AI-specific controls for impact analysis, models and datasets, stakeholder communication, human oversight, evaluation, and ongoing output monitoring. Do not assume that having ISO/IEC 27001 certification automatically grants ISO/IEC 42001 conformity.
Independent accredited certification, where sought, examines the defined AIMS against the applicable standard. A certificate is not a guarantee that each model output will be correct, safe, unbiased, or lawful in every jurisdiction.
Avoid these AI governance traps
- Inventorying only internally trained models while ignoring purchased AI features.
- Treating model accuracy as the entire risk and impact assessment.
- Claiming a generic content filter prevents every prompt-injection or authorization failure.
- Accepting vendor assurances without evaluating the deployed use case.
- Allowing unrestricted AI tools to receive confidential or controlled information.
- Deploying significant model changes without evaluation and human approval.
- Using a fictional maturity score as an official ISO/IEC 42001 certification level.
Questions and answers
Q: Can an organization using third-party AI services implement ISO/IEC 42001? A: Yes. The standard applies to organizations that provide or use AI systems, subject to defined scope.
Q: Is an ISO/IEC 27001 certificate enough to establish AI governance conformity? A: No. The AI-specific management requirements need their own treatment.
Q: Why should impact assessments be repeated? A: AI systems, stakeholders, uses, models, data, and consequences change over time.
Official references
- ISO/IEC 42001:2023 overview: https://www.iso.org/standard/81230.html
- ISO explainer on AI management systems: https://www.iso.org/insights/iso-42001-explained
- IEC publication record: https://webstore.iec.ch/en/publication/90574
- ISO integrated AI and information security standards: https://www.iso.org/publication/PUB200427.html
I’m Rajesh Kumar, a DevOps, SRE, DevSecOps, Cloud, and Platform Engineering expert passionate about sharing practical knowledge, real-world experiences, and industry best practices. I have worked at Cotocus and regularly write about technology, travel, investing, health, product reviews, and digital marketing through my various platforms.
I publish technical articles at DevOps School, travel stories at Holiday Landmark, stock market insights at Stocks Mantra, health and fitness guidance at My Medic Plus, product reviews at TrueReviewNow, and SEO and digital marketing strategies at Wizbrand.
Find Trusted Cardiac Hospitals
Compare heart hospitals by city and services — all in one place.
Explore Hospitals