AI Compliance Glossary
A practical glossary for the concepts behind AI compliance at LatentMesh. Use it to understand how obligations become controls, evaluations, evidence artifacts, owners, and response workflows.
C
Compliance loop
The repeating cycle that turns regulatory obligations into demonstrable evidence.
At LatentMesh, the compliance loop is the core operating model: obligation → control → evaluation → evidence → response. Each step feeds the next. The loop runs continuously, not as a one-time project.
Why it matters: If the loop is broken at any step — an obligation without a control, a control without an evaluation, an evaluation without evidence — the system cannot demonstrate compliance.
Read next: AI Compliance guide
Control
A mechanism that enforces or verifies a specific obligation.
A control is not a guardrail. It is not a boundary check on output. A control is a verifiable mechanism that produces evidence of compliance. It has an obligation it serves, a verification method, an evidence artifact, an owner, and a review cadence.
Why it matters: Without controls, obligations remain abstract commitments. Controls make compliance operational by defining exactly what the system does to meet each requirement.
Read next: Controls Are Not Guardrails · Regulatory Mapping Table
D
Deployer
The organisation that puts an AI system into use, as distinct from the organisation that built it.
Under the EU AI Act, the deployer uses or operates a high-risk AI system. Deployers have their own obligations — human oversight, monitoring, incident reporting — that are separate from provider duties. A deployer who substantially modifies a system may inherit provider obligations under Article 25.
Why it matters: Deployer obligations are often overlooked. Governance teams must understand whether their organisation is a provider, a deployer, or both, because the obligation set differs.
Read next: EU AI Compliance Checker
E
Evaluation
A structured test that measures whether a control is working as intended.
An evaluation is not a benchmark score. It is a repeatable verification method tied to a specific control. It produces evidence artifacts that demonstrate the control holds under the conditions the system actually operates in — not just under lab conditions.
Why it matters: Evaluations close the gap between 'we have a control' and 'we can prove it works.' Without evaluations, controls are claims rather than evidence.
Read next: The Eval Gap · Building an Eval Harness That Survives Production
Evidence artifact
A concrete output that demonstrates a control was evaluated and the result was recorded.
Evidence artifacts include test results, approval records, trace logs, configuration snapshots, and incident records. They are not the same as logs — logs record what happened; evidence artifacts prove the system meets its obligations.
Why it matters: Audit readiness depends on evidence artifacts. Without them, an organisation can describe its compliance program but cannot demonstrate it.
Read next: What Your Agent Logged vs. What the Auditor Needed
Evidence pack
A structured collection of evidence artifacts that proves an AI system meets its obligations across time.
An evidence pack bundles traces, evaluation results, approval records, configuration snapshots, and incident history into one auditable unit. It answers the question: 'Can you prove this system did what you said it would do?'
Why it matters: A system may pass an eval today. An evidence pack proves it was passing evals consistently, under real conditions, with proper oversight and incident response.
Read next: Anatomy of an Evidence Pack · Evidence Pack Guide
Evidence plane
The infrastructure layer that continuously generates, stores, and makes available the evidence artifacts a system produces.
The evidence plane sits alongside the data plane and control plane. It is not a logging system — it is a purpose-built layer that captures obligation-mapped evidence, assembles evidence packs, and surfaces them for review and audit.
Why it matters: Without an evidence plane, compliance evidence is scattered across logs, dashboards, and documents. The evidence plane makes compliance a system property, not a manual activity.
Read next: The Evidence Plane for AI Systems
G
Guardrail
A boundary check on AI system input or output, typically at the prompt or response layer.
Guardrails block or flag specific inputs and outputs. They are useful but insufficient for compliance. A guardrail does not produce evidence, does not map to an obligation, and does not prove the system is safe — it only proves the boundary was enforced at one moment.
Why it matters: Guardrails are often mistaken for safety or compliance. They are one mechanism among many. Treating guardrails as the compliance strategy leaves most obligations unaddressed.
Read next: Guardrails Are Not Safety · Controls Are Not Guardrails
H
Human oversight
The ability of a natural person to effectively monitor, intervene in, and override an AI system during operation.
Under the EU AI Act (Article 14), high-risk AI systems must be designed so that human overseers can understand the system's capabilities, monitor its operation, and interrupt it when necessary. Human oversight is a design requirement, not just a policy statement.
Why it matters: Oversight is not the same as having a human in the loop. It requires the overseer to have sufficient information, authority, and tooling to act meaningfully.
Read next: From Obligation to Evidence in 90 Minutes
O
Obligation
A requirement that the system or organisation must satisfy.
At LatentMesh, an obligation is the starting point of the compliance loop. It is the thing that must be demonstrated, not just discussed. Obligations come from statutes (EU AI Act articles), standards (NIST, ISO), or organisational policy.
Why it matters: If the obligation is vague, the downstream control, evaluation, and evidence will also be vague. Precision in stating obligations is what makes the rest of the loop actionable.
Read next: AI Compliance guide · Mapping the EU AI Act to Engineering Evidence
Owner
The person or team accountable for a specific control, evaluation, or evidence artifact.
Every control in the LatentMesh model has a designated owner — typically Safety, ML Engineering, Legal, or Product. Ownership means responsibility for maintaining the control, running evaluations on cadence, and escalating when the control fails.
Why it matters: Unowned controls decay. If no one is accountable for a control's health, it will eventually stop working without anyone noticing.
Read next: Regulatory Mapping Table
P
Provider
The organisation that develops or places an AI system on the market.
Under the EU AI Act, the provider bears the heaviest obligations: risk management, data governance, technical documentation, conformity assessment, human oversight design, and post-market monitoring. If a deployer substantially modifies a system, they may become a provider under Article 25.
Why it matters: Provider obligations drive most of the engineering work for high-risk AI systems. Understanding whether you are a provider or deployer determines which obligations apply to you.
Read next: EU AI Compliance Checker
R
Review cadence
How often a control, evaluation, or evidence artifact is reviewed or refreshed.
Review cadence is not a fixed schedule for all controls. Some controls need pre-release review; others need continuous monitoring; others need quarterly or annual audit. The cadence depends on the risk and rate of change of the system.
Why it matters: A control reviewed once at deployment and never again is not a control — it is a historical snapshot. Cadence keeps the compliance loop alive.
Read next: Regulatory Mapping Table
Risk classification
The process of determining which regulatory tier an AI system falls into.
Under the EU AI Act, AI systems are classified as prohibited, high-risk (Annex I or Annex III), limited-risk (transparency obligations), or minimal-risk. The classification determines which obligations apply. The EU AI Compliance Checker walks through the full decision flow.
Why it matters: Classification is the gate to obligations. Getting it wrong — in either direction — means either over-engineering for requirements that don't apply, or under-engineering for requirements that do.
Read next: EU AI Compliance Checker
T
Traceability
The ability to reconstruct what an AI system did, why, and with what inputs and outputs, for any given interaction.
Under Article 12 of the EU AI Act, high-risk systems must have automatic logging capabilities. Traceability goes beyond logging — it means being able to follow a complete chain from input through model reasoning, tool calls, oversight decisions, and final output.
Why it matters: Traceability is what makes incidents investigable and compliance demonstrable. Without it, an incident is a mystery and an audit is a guessing exercise.
Read next: What Your Agent Logged vs. What the Auditor Needed
Continue through the compliance system
LatentMesh organizes AI compliance as a practical loop: obligation, control, evaluation, evidence, and response.