Certification Standard

AI Management System Standard

— AIMSS v1.1

AIMSS requires organisations to identify, assess, control, monitor, and disclose material risks arising from AI systems. Certification is granted only where the organisation provides sufficient evidence that its AI governance system is implemented, effective, independently verifiable, and proportionate to the risks of the AI systems within scope.

Document control

Version
1.1
Status
Ratified
Domains
10
Risk classes
4 + Prohibited
Annexes
A · B · C · D

Core positioning

A certifiable management system for the full AI lifecycle.

AIMSS applies to organisations that design, develop, deploy, procure, or operate AI systems. The standard requires demonstrable governance across design, data sourcing, development, testing, deployment, monitoring, incident response, user recourse, supplier management, environmental impact, labour conditions, and decommissioning.

Certification does not guarantee that an AI system is harmless, lawful in every jurisdiction, or error-free. It indicates that the organisation has implemented verifiable controls to identify, manage, monitor, and improve AI-related risks.

Section 1 · Risk classification

AIMSS risk classes.

Requirements are proportionate to risk. Every AI system in scope shall be assigned a class and re-assessed at material change.

Class 1
Minimal Risk
Internal productivity or low-impact AI.
Inventory, owner, basic monitoring.
Class 2
Moderate Risk
User-facing or business-impacting AI.
Impact assessment, testing, user disclosure.
Class 3
High Risk
Affects rights, access, safety, finance, employment, health, education, law enforcement, or essential services.
Independent validation, human oversight, appeal process, enhanced monitoring.
Class 4
Critical Risk
Could cause severe, irreversible, systemic, or large-scale harm.
Executive approval, independent review, red-team testing, deployment restrictions.
Prohibited
Prohibited Use
Unlawful, deceptive, exploitative, or uncontrollable uses.
Must not be certified.

Section 2 · Scope of certification

One Blue Ribbon. The full AIMSS surface.

Every AIMSS certification examines the same comprehensive scope — governance, AI inventory, data controls, lifecycle, ethics review, transparency, security, resilience, user recourse, environmental sustainability, labour safeguards, supplier oversight, systemic risk, and market conduct. Engagement depth, sampling, and surveillance cadence are scoped to each organisation's size and risk profile.

Examination

Document review, staff interviews across engineering and operations, on-site evidence walkthroughs, sample testing of live systems, and ethics & safety culture review.

Surveillance

Continuous assurance during the certification period: scheduled and unannounced surveillance visits, complaints-register monitoring, and a recertification examination at cycle end.

Public commitments

Every certified organisation publishes its AI register summary, governance policy, risk-assessment method, complaints register, and annual incident, bias, and safety summary.

Section 2 · Control domains

Ten certifiable control domains.

Each domain answers the same five questions: who owns it, what must be done, what evidence proves it, how often it must be reviewed, and what happens if it fails.

D01

Governance and Accountability

The organisation shall:

  • maintain an AI system inventory;
  • assign an accountable executive for AI risk;
  • assign owners for each AI system;
  • define risk appetite and prohibited uses;
  • maintain an AI Risk Committee for material systems;
  • ensure independence between model builders, validators, and approvers for high-risk systems.

Evidence · AI inventory, governance charter, role descriptions, committee minutes, approval records.

D02

AI Risk and Impact Assessment

The organisation shall:

  • conduct an AI Risk and Impact Assessment before deploying any Class 2, 3, or 4 system;
  • cover intended use, foreseeable misuse, affected stakeholders, data risks, bias, safety, privacy, security, environmental impact, labour impact, explainability, oversight, and recourse;
  • document mitigations and residual risk acceptance with named approvers.

Evidence · Completed assessments, approval records, mitigation plans, residual risk acceptance.

D03

Data Governance

The organisation shall:

  • document provenance, legal/contractual basis, quality, representativeness, and known limitations;
  • control sensitive-data handling, retention, deletion, third-party dataset terms, and synthetic-data risks;
  • for high-risk systems, test whether data limitations could lead to unfair, unsafe, or materially inaccurate outcomes.

Evidence · Data sheets, lineage records, data-quality reports, licensing records, retention logs.

D04

Model Development and Validation

The organisation shall:

  • maintain reproducible records: purpose, architecture or vendor model, training/fine-tuning approach, evaluation method, benchmark results;
  • document bias, fairness, robustness, security, and explainability testing, plus known limitations and release approval;
  • for Class 3 and 4 systems, validation shall be performed by personnel independent of the development team.

Evidence · Model cards, test reports, validation sign-off, release notes, version control logs.

D05

Deployment and Human Oversight

The organisation shall:

  • ensure human oversight is meaningful, trained, and documented for high-risk systems;
  • inform users when AI materially influences a decision;
  • allow affected individuals to challenge or appeal significant decisions;
  • maintain fallback procedures and monitor automated decisions for error, drift, and harm.

Evidence · Deployment checklist, oversight procedures, user notices, appeal logs, fallback test results.

D06

Monitoring, Incidents, and Corrective Action

The organisation shall:

  • monitor performance drift, data drift, bias drift, security events, complaints, harmful outputs, misuse, response times, and unresolved risks;
  • classify material AI incidents by severity (see table below);
  • perform root-cause analysis and verified corrective action for major and critical incidents.

Evidence · Monitoring dashboards, incident logs, root-cause analysis, corrective action records.

D07

Transparency and Accountability

The organisation shall:

  • publish proportionate disclosures: intended use, limitations, known material risks, oversight model, complaint route, incident policy, contact point;
  • permit redactions only where they do not prevent meaningful accountability.

Evidence · Public disclosure statements, complaint registers, redaction logs.

D08

Labour and Supply Chain Responsibility

The organisation shall:

  • identify workers and suppliers involved in development, labelling, safety testing, moderation, evaluation, and monitoring;
  • for material suppliers, assess working conditions, compensation, harmful-content exposure, mental-health safeguards, subcontracting, grievance channels, and security controls.

Evidence · Supplier due diligence, contracts, certification reports, worker safety procedures, grievance logs.

D09

Environmental Sustainability

The organisation shall:

  • for material AI systems, document compute used, energy consumption estimate, emissions estimate, infrastructure location where known, efficiency measures, hardware lifecycle, and reduction targets for large-scale systems.
  • review methodology, boundaries, assumptions, and data sources at least annually.

Evidence · Energy reports, cloud usage data, emissions methodology, optimisation records.

D10

Misuse, Security, and Resilience

The organisation shall:

  • address prompt injection, data leakage, model extraction, adversarial inputs, impersonation, fraud, disinformation, harmful automation, unauthorised access, dependency failure, vendor outage;
  • for Class 3 and 4 systems, perform red-team testing before deployment and after material changes.

Evidence · Threat models, penetration test reports, red-team summaries, dependency risk register.

§3

Incident severity classes

Level 1
Minor issue with no material harm.
Record and review.
Level 2
Repeated or material control failure.
Corrective action plan.
Level 3
Harm to users, workers, customers, or affected communities.
Executive notification and root-cause review.
Level 4
Severe, systemic, unlawful, or safety-critical harm.
Immediate containment, certification body notification, potential suspension.
§4

Nonconformity rules

Minor

A control exists but has limited documentation or isolated implementation weakness.

Consequence · Corrective action required before next surveillance review.

Major

A required control is missing, ineffective, inconsistently implemented, or unsupported by evidence.

Consequence · Certification cannot be granted or renewed until corrective action is verified.

Critical

A failure creates severe risk of harm, unlawful conduct, deception, systemic misuse, retaliation, obstruction of assessment, or deliberate misrepresentation.

Consequence · Immediate suspension, public notice, and mandatory remediation review.

§5

Assessor independence

Certification bodies and assessors shall be independent of the organisation being certified. Assessors shall disclose financial, advisory, employment, investment, or personal conflicts of interest.

A certification body shall not certify an organisation for which it designed, implemented, or materially advised on the AI management system within the prior 24 months.

Certification conclusions shall be based on sufficient appropriate evidence, including document review, system sampling, interviews, walkthroughs, technical testing where applicable, and verification of corrective actions.

Annex A

Required certification artifacts

  • · AI system inventory
  • · AI governance policy
  • · Risk classification methodology
  • · AI Risk and Impact Assessments
  • · Model cards
  • · Data sheets
  • · Data provenance records
  • · Testing and validation reports
  • · Bias and fairness assessments
  • · Security and misuse assessments
  • · Human oversight procedures
  • · User disclosure notices
  • · Complaint and appeal records
  • · Incident logs
  • · Corrective action plans
  • · Environmental impact records
  • · Labour and supplier due diligence
  • · Training records
  • · Management review minutes
  • · Internal audit reports
  • · External audit reports
  • · Certification scope statement
  • · Public disclosure statement
  • · Suspension and withdrawal history, where applicable

Annex B

Core metrics

Model performance
Accuracy, precision, recall, false-positive rate, false-negative rate, or task-specific equivalent.
Fairness
Outcome differences across relevant protected or vulnerable groups.
Robustness
Performance under stress, drift, adversarial, or out-of-distribution conditions.
Explainability
Percentage of material decisions with usable explanation available.
Human override
Number and percentage of AI outputs overridden by humans.
Complaint rate
Complaints per defined unit of AI decisions or users.
Appeal success rate
Percentage of challenged decisions reversed or modified.
Incident severity
Number of incidents by severity level.
Time to containment
Time between incident detection and containment.
Time to disclosure
Time between confirmed material incident and external disclosure.
Energy use
Estimated energy consumed by material AI activity.
Emissions
Estimated greenhouse gas emissions from training, tuning, and inference.
Worker safety
Harmful-content exposure, support usage, grievances, turnover, or equivalent indicators.
Supplier coverage
Percentage of material AI suppliers assessed.

Annex C

The Ethicality Integrity Programme

  • · Unannounced or short-notice surveillance
  • · Public complaints register
  • · Ethics & Safety Culture review at recertification (interviews with engineers and frontline operators, not only management)
  • · Public suspension & withdrawal register
  • · Annual revision cycle informed by the Ethicality Policy Institute

Annex D

Scope of complaints

The public complaints register and complaint route referenced in Domain 7 exist for one purpose: to surface credible reports that a certified organisation is using, building, or deploying AI in a way that breaches AIMSS. This annex defines what we will and will not review.

What Ethicality reviews

  • · AI making consequential decisions about people without meaningful human oversight or a usable appeal route.
  • · Undisclosed AI use where disclosure is required — to customers, patients, students, applicants, or employees.
  • · AI used to surveil, evaluate, discipline, or automate decisions about workers without the safeguards required by Domains 5 and 8.
  • · AI outputs that are biased, unsafe, or materially inaccurate, where the operator has failed to monitor or correct them.
  • · Pressure on staff to use AI in ways that breach their professional duties, safety obligations, or the operator's own published policy.
  • · Retaliation against staff who raise AI safety, ethics, or compliance concerns internally.
  • · Supplier, data-labour, or moderation-worker conditions that breach Domain 8.

What Ethicality does not review

These matters belong to other authorities or to internal HR. We may forward credible reports to the appropriate regulator, but we do not investigate them ourselves:

  • · General workplace grievances unrelated to AI — harassment, pay disputes, scheduling, non-AI discrimination.
  • · Consumer complaints about product quality unrelated to AI behaviour.
  • · Criminal conduct — refer to law enforcement.
  • · Disputes between two parties where no certified organisation is involved.

Who can file

Anyone. Employees, contractors, data workers, customers, affected community members, journalists, and civil-society organisations. Anonymous submissions are accepted; complaints from named individuals receive a written response. Retaliation against any complainant by a certified operator is itself a Critical nonconformity (see § Nonconformities).

Open question · under review

AIMSS v1.1 applies one ethical bar to every certified operator. The Ethicality Policy Institute is examining whether certain contexts — state and coercive uses such as policing, immigration, and benefits adjudication; critical infrastructure; and uses involving children — should be held to a stricter bar than commercial uses. A private business deploying AI and a police force deploying AI may not warrant identical thresholds. This is an open question, not a current rule. See Policy Institute for ongoing memos.

Ready to be certified against AIMSS v1.1?

Get certified →