AI Deployment Compliance

AI Compliance & Deployment Readiness

Written by Jakub RusinowskiLast updated September 13, 2026Assessment logic is deterministic and runs in your browser

Whether an AI deployment is regulated depends on what it is for, who it affects and what it decides — not on which model you picked. This tool takes the whole deployment context (model, hardware, hosting, data, users, intended purpose, oversight and your organisation's role) and produces a structured readiness assessment: which EU AI Act obligations are potentially applicable, which controls follow from them, how those controls relate to ISO/IEC 42001, ISO/IEC 27001, NIST AI RMF, CSA AICM and SOC 2, and what evidence you would need. Every result carries the rule that produced it. It is an assessment, not legal advice, certification or an audit.

Create Compliance Profile →Explore Frameworks

This section is practitioner guidance on deployment and governance mechanics, not legal advice. Regulatory classification turns on facts about intended purpose and real-world use that a questionnaire cannot establish — involve your counsel or DPO for decisions about your specific obligations. Automated assessment based on the information you provide. Not legal advice, certification or an audit.

Most AI governance tooling starts from a questionnaire about your organisation. This one starts from your deployment, because that is what this site already knows: which model, at which quantisation, on which hardware, served how. Those facts are not decorative in a compliance assessment — they decide who holds which role, what evidence you can actually produce, and which technical controls are available to you at all.

The thing that decides your obligations, though, is none of them. The EU AI Act classifies by intended purpose. The same 32B open-weight model is a minimal-obligation productivity tool as an internal drafting assistant, a potential Annex III high-risk system when it ranks job candidates, and a question for your lawyer when it identifies people from a camera feed. Nothing about the weights changed. What changed is what the system is for and whose life it touches.

That is why the assessment asks about deployment, purpose, data, users, decisions, oversight and role — and why it will tell you MANUAL REVIEW REQUIRED rather than guess when the answers do not settle the question. A tool that resolves uncertainty into a clean verdict is not being helpful; it is transferring risk from itself to you.

The assessment runs entirely in your browser. No manifest is sent to a server, logged, or processed by a language model. The result link encodes your answers into the URL itself, so there is nothing stored on our side.

What this tool assesses

Six instruments, grouped by what they actually are. They are not interchangeable, and the group headings say why.

Legal obligation

Applies to you whether or not you adopt it.

EU AI Act Regulation (EU) 2024/1689

The European Union's horizontal AI law.

Certifiable management systems

Audited by an accredited body against your organisation, not your model.

ISO/IEC 42001 2023

The first management-system standard for artificial intelligence.

ISO/IEC 27001 2022

The established information-security management-system standard, with its control set in Annex A.

Voluntary frameworks and attestation

Adopted by choice, or reported on by an auditor you engage.

NIST AI RMF 1.0

A voluntary framework NIST published to help organisations manage risks across the AI lifecycle.

CSA AICM 1.1

A control framework for securing and governing AI systems, built in the lineage of CSA's Cloud Controls Matrix.

SOC 2 Trust Services Criteria (2017, as revised)

An attestation engagement in which an independent CPA firm reports on a service organisation's controls against the Trust Services Criteria: security (the common criteria), and optionally availability, processing integrity, confidentiality and privacy.

From AI configuration to deployment readiness

Compliance depends on the whole deployment context, not on the model. Each step below feeds the next.

  1. Model

    Which weights, which version, open or proprietary, fine-tuned or stock.

  2. Hardware

    What it runs on — and therefore what you can log, isolate and pin.

  3. Deployment

    Local, on-prem, air-gapped, private cloud, public cloud or a managed API.

  4. Data

    Personal, special-category, biometric, employment, financial, criminal, children's.

  5. Use case

    The intended purpose. This is the field the EU AI Act actually classifies on.

  6. Risk

    Prohibited practice, high-risk pathway, transparency duty, or none of these.

  7. Regulatory requirements

    The obligations that follow, split by your role in the value chain.

  8. Controls

    What you build and operate, expressed independently of any one framework.

  9. Evidence

    What you would have to show someone who asked.

  10. Deployment profile

    The whole thing as a structured artefact you can export and version.

Take one deployment and change only the intended purpose. Same Qwen3 32B, same RTX 4090, same on-premise serving stack, same EU jurisdiction:

Intended purposeWhat the assessment returns
Internal coding assistantNo Annex III area matches. Article 50 transparency duties where staff interact with it; the Article 4 AI-literacy duty applies regardless.
HR candidate rankingAnnex III point 4 (employment) matches. The Article 6(3) derogation is unavailable because the system profiles people. High-risk candidate, deployer obligations under Article 26, and a fundamental rights impact assessment may be required under Article 27.
Biometric identificationArticle 5 prohibitions engage before the risk tier is even reached. The screen escalates to a human rather than returning a verdict, because Article 5 admits no compliance route.

Three different regulatory positions. One model file. This is why an assessment keyed to the model — or to your industry — cannot be right, and why this one asks about the deployment instead.

What a Compliance Profile contains

EU AI Act risk assessment

Article 5 prohibitions, both high-risk pathways, the Article 6(3) derogation and Article 50 transparency duties, evaluated as a precedence ladder rather than a score.

Actor classification

Provider, deployer, importer, distributor — determined from structured questions, including the Article 25 routes that turn a deployer into a provider.

Framework mapping

Controls mapped across ISO/IEC 42001, ISO/IEC 27001, NIST AI RMF, CSA AICM and SOC 2, each with a relationship type, a confidence and a rationale — including where a framework has nothing.

Control and guardrail recommendations

The technical and organisational controls that follow from what applies, with the specific reason this deployment gets each one.

Evidence checklist

What you would need to show someone who asked, scoped to the controls that actually apply rather than to a generic list.

Decision trace

Every automated decision with the rule id, the field it read, the value it found and the legal reference. Click any finding to see why.

Portable profile

JSON and Markdown export carrying engine version, ruleset version, framework versions and SHA-256 hashes of both the manifest and the profile body.

The guides

EU AI Act Compliance Assessment for AI Deployments

The precedence ladder an assessment has to walk — Article 5, the two high-risk pathways, the Article 6(3) derogation, and the transparency duties that apply regardless of tier.

Read the guide →

ISO/IEC 42001 and AI Deployment Governance

Why a model cannot comply with a management-system standard, what a deployment contributes to an AIMS, and why certification is not a route to AI Act compliance.

Read the guide →

ISO/IEC 27001 Controls for AI Deployments

The security controls that transfer to an AI deployment unchanged — and the three gaps the 2022 control set genuinely does not cover, named rather than papered over.

Read the guide →

NIST AI Risk Management Framework for Deployment Teams

GOVERN, MAP, MEASURE and MANAGE applied to a real LLM deployment, and why a framework mapping without a version attached rots silently.

Read the guide →

CSA AI Controls Matrix for LLM Deployments

The framework in this set that addresses AI-specific attack surface directly, and the four controls self-hosted deployments most often miss.

Read the guide →

SOC 2 and AI Deployment Controls

What an attestation actually reports, the three things buyers get wrong about it, and what a clean report does not tell you about an AI system.

Read the guide →

Local AI Compliance: What Self-Hosting Changes

Self-hosting changes your evidence, not your obligations. What it genuinely buys you, what it adds to your plate, and the hardware choices that are also compliance choices.

Read the guide →

Private AI Deployment: Governance for Controlled Environments

Six hosting modes and what each makes cheap or impossible — including an honest accounting of the air-gap trade.

Read the guide →

Frequently asked questions

Does LLM Configurator provide legal advice?

No. This is an automated readiness assessment based on the information you provide, and nothing it produces is legal advice, a certification, an audit or a conformity assessment. The European Commission's own AI Act compliance checker draws the same boundary for the same reason: classification under the Act turns on findings of fact and law that a questionnaire cannot make. Use the output to structure a conversation with your counsel or DPO, not to replace it.

Does running AI locally avoid EU AI Act requirements?

No. The Act regulates by intended purpose and by who places a system on the market or uses it — not by where the hardware sits. An HR screening system is in the same Annex III area whether it answers from your rack or a vendor API. What self-hosting genuinely changes is evidence and dependency: you control the logs the Act asks deployers to keep, you pin the model version your documentation describes, and your data path has fewer parties in it. That is a real advantage, and it is not an exemption.

Is open-source or open-weight AI automatically exempt?

No. There are carve-outs easing some obligations for models released under free and open-source licences, and they sit in the general-purpose AI model chapter — the duties of whoever trains and releases the weights. They do not reach the deployer of a system built on those weights. If your deployment lands in Annex III, it lands there whether the model is Apache-2.0 or proprietary. The practical effect of open weights on your position is about role, not exemption: downloading released weights does not make you the provider of that model.

Does using an API instead of self-hosting change the risk?

It changes who holds which role and what evidence you can produce, not which obligations exist. Your risk classification comes from the intended purpose either way. With a managed API you depend on the provider's documentation, logging retention and change control; a model that changes under you makes your risk assessment describe a moving target. With self-hosting you own those, and the corresponding cost is that you also own the security of the endpoint. The assessment asks about hosting mode because it changes the control set, not the classification.

Does the same model have the same risk in every use case?

No, and this is the single most important thing to understand about the Act. It classifies AI systems by what they are intended to do. One 32B model is a minimal-obligation drafting assistant, a high-risk candidate when it ranks candidates for a job, and a prohibited-practice question when it infers emotions of employees. The model file is identical in all three. This is why the assessment asks for a deployment context rather than a model name.

What is an AI Deployment Compliance Profile?

A structured artefact describing one deployment: the manifest you supplied, the actor classification, the regulatory assessment stage by stage, the obligations that follow, the controls those obligations imply, how those controls map across frameworks, the evidence you would need, the readiness position, and a full decision trace. It carries an engine version, a ruleset version, the framework versions it was assessed against, and SHA-256 hashes of both the manifest and the profile body — so two profiles can be compared for real change rather than for reformatting. It exports as JSON and Markdown.

What is the difference between compliance and readiness?

Compliance is a legal state, determined by regulators, courts and — for some high-risk systems — a notified body following a formal conformity assessment procedure. Readiness is an operational position: do you know which obligations apply, have you built the controls, and can you produce the evidence if asked. A tool can assess the second. Nothing that runs in a browser can determine the first, and any product claiming otherwise is selling you a false sense of resolution.

What evidence should I collect?

It depends on what applies, which is what the assessment works out — but the core set is consistent across deployments: a written intended-purpose statement, a system description, model and version metadata, a risk assessment, dataset and corpus documentation, testing results, a human oversight procedure with records of it being exercised, audit and inference logs with a deliberate retention period, incident records, the security configuration, and your guardrail configuration. The profile generates the checklist scoped to your deployment, and the Markdown export carries it as checkboxes.

Is my deployment information stored anywhere?

No. The assessment runs entirely in your browser, and the result link encodes your answers into the URL itself rather than into a database. Nothing is sent to a server, written to a log, or passed to a language model. Anyone holding the link can read the manifest, exactly as with any URL-encoded state — so treat a result link as you would the document it describes. Free-text fields are screened for credential-shaped strings and those are redacted before anything is encoded.

Keep going