AI Compliance & Deployment Readiness
Written by Jakub Rusinowski · Last updated 2026-09-13 · Assessment logic is deterministic and runs in your browser
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.
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 →
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.
- Model — Which weights, which version, open or proprietary, fine-tuned or stock.
- Hardware — What it runs on — and therefore what you can log, isolate and pin.
- Deployment — Local, on-prem, air-gapped, private cloud, public cloud or a managed API.
- Data — Personal, special-category, biometric, employment, financial, criminal, children's.
- Use case — The intended purpose. This is the field the EU AI Act actually classifies on.
- Risk — Prohibited practice, high-risk pathway, transparency duty, or none of these.
- Regulatory requirements — The obligations that follow, split by your role in the value chain.
- Controls — What you build and operate, expressed independently of any one framework.
- Evidence — What you would have to show someone who asked.
- 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 purpose | What the assessment returns |
|---|---|
| Internal coding assistant | No Annex III area matches. Article 50 transparency duties where staff interact with it; the Article 4 AI-literacy duty applies regardless. |
| HR candidate ranking | Annex 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 identification | Article 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.
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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
Frequently asked questions
Keep going
- The EU AI Act and self-hosted AI — timeline, roles, and what on-prem changes
- Enterprise & Sovereign AI — the deployment hub
- GPU & VRAM checker — what your hardware can actually run
- Local AI and GDPR — the data-protection half of the question
- AI vendor evaluation checklist — 30 questions for procurement
- How this site computes its hardware figures