ISO 42001 for Employee Generative AI Copilots: Bringing Shadow AI Into the AIMS

Shadow AI is a scoping problem before it is a tooling problem

ISO/IEC 42001 specifies requirements for establishing, implementing, maintaining and continually improving an AI management system. It applies to organizations that develop, provide or use AI systems, and it applies to organizations of all sizes and sectors. The word "use" is what brings employee copilots into scope. An organization does not need to build a model for the AIMS to cover how its people use one.

OWASP describes shadow AI as employees using unapproved online AI tools, unsafe browser plugins and third-party applications that add LLM features through updates or upgrades, bypassing normal software approval. That definition is wider than chat websites. It includes features that appear inside applications the organization already approved.

This is where the AIMS as written diverges from the AIMS as practiced. A policy and an inventory of sanctioned systems describe intent. If the scope statement does not reflect AI that employees actually use, an assessor testing scope, operational control and monitoring will find the difference. Certification is voluntary and independent, and no single control produces a certification outcome. The goal is an AIMS whose boundary matches reality.

Mapping copilot scenarios to AIMS requirement areas

The table names requirement areas rather than clause numbers. Confirm numbering and Annex A control identifiers against the published 2023 text when building your control set. The mapping reflects practitioner judgment about how each scenario lands in a management system. It is not a statement of how any certification body will assess it.

• Sensitive data pasted into an assistant: Risk assessment and treatment, operational control, and Annex A themes on data and responsible use. Enforceable at runtime by redacting or blocking before data leaves.
• Unapproved AI website in a browser: Scope, inventory and policy. Enforceable by allowing, blocking or routing a request for approval, based on the tool's inventory status.
• Tool invoked through a copilot: Operational planning and control, plus impact assessment for what the tool can change. Enforceable per tool call, with human approval for higher-consequence actions.
• LLM feature added to an approved app by an update: Third-party and change management inside the inventory review cycle. Mostly a process control. Runtime enforcement covers only traffic that passes through it.
• Repeated policy violations: Monitoring, internal audit, nonconformity and corrective action. These are management processes that consume runtime records but are not performed by them.

Define scope and inventory entries for discovered tools

Start with the scope statement. It should say that employee use of third-party generative AI, including tools found through discovery that were never approved, is within the AIMS boundary. It should also say how each tool is treated according to its status. A workable set of statuses is approved, restricted (approved for defined data and users) and prohibited. A prohibited tool still belongs in the inventory, because the decision to prohibit it, and the enforcement of that decision, is something an assessor can ask about.

Each inventory entry needs enough detail to support a risk decision. Useful fields include the tool and vendor, the access path (standalone site, browser plugin, or embedded feature), the business owner, the user population, the data types likely to be exposed, the status, the date of discovery, a reference to the risk and impact assessment, and the policy that applies. These fields are a practitioner suggestion, not a requirement of the standard.

Impact assessment should not be skipped for discovered tools. ISO states that 42001 makes impact assessments a consistent and required part of AI governance. For a copilot, the assessment should consider who can be affected by outputs and which actions the tool can take, not just what data leaves the organization. As of November 2026, ISO/IEC 42003 implementation guidance is still under development, so these decisions rest on the standard itself and on your own judgment.

Where runtime enforcement fits, and where it does not

A management system standard sets requirements for policy, risk treatment and improvement. It does not enforce anything by itself. Runtime enforcement closes the gap between a policy that says sensitive data must not reach an unapproved assistant and a control that stops it. The enforcement point is in the execution path of the interaction, so the decision is made before the request completes, not reviewed after the fact. The same point produces a record of each decision, which is the evidence an auditor can sample.

Trussed enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants. Decisions are allow, redact, block, rate limit or escalate for human approval, applied to individual interactions and tool calls. Enforcement generates continuous audit-ready evidence, mapped to frameworks including NIST and the EU AI Act. Trussed can be deployed self-managed in the customer cloud, with configurable retention and data residency. In production it has run continuously for 18+ months in a regulated enterprise and operates 100+ models under one policy plane.

The limits matter. Enforcement covers traffic that passes through the path, so it complements discovery and does not replace it. It does not perform risk assessment, write the scope statement, run internal audit or handle nonconformities, and it is not a GRC platform. Mapping its records to your documented information and monitoring requirements remains the organization's task. The NIST crosswalk from the AI RMF to a draft of ISO/IEC 42001 can serve as a cross-reference, but check it against the published 2023 text.