# AI compliance: which rules apply to your AI product and what proof they need

Source: https://airedteamingservices.com/guides/ai-compliance/
Publisher: Excession Labs (airedteamingservices.com)
Last updated: 2026-11-09

A duty-by-duty map of AI compliance: EU AI Act dates, standards, and the evidence each duty asks for, plus where security testing fits and what it cannot prove.

> **Short answer:** AI compliance means meeting the legal, contractual and standards duties that apply to the AI you build or use. For most teams that is the EU AI Act if you serve the EU, privacy and consumer law, sector rules, customer contracts and voluntary standards such as ISO/IEC 42001 and NIST AI RMF. A security test report is evidence for some duties. It does not make a system compliant.

AI compliance is the work of meeting every legal, contractual and standards duty that applies to the AI you build or buy, and keeping proof that you did. No single rule covers it. This page maps duties by type, shows which evidence each one asks for, and says where security testing fits. It is not legal advice. Ask counsel which rules apply to your product, your users and your markets.

## What does AI compliance mean?

AI compliance means matching your AI systems to the duties that apply to them and holding records for each. Duties come from four places: statutes and regulations, contracts with customers, sector rules, and voluntary standards that customers expect. The first three bind you. A voluntary standard binds you only when you claim it or sign a contract that cites it.

The work starts with an inventory. List each model, feature and agent you ship or use, who the users are, which data it reads, and which actions it can take. Without that list you cannot answer "does this rule apply to us". It also feeds the [AI security risk assessment](/guides/ai-security-risk-assessment/), which uses the same inventory.

For each system, record four facts: where it runs, whom it affects, whether it makes or supports decisions about people, and whether you build it or use a vendor's model. Duties often differ for providers and deployers, so the fourth fact matters in the EU AI Act.

## Which laws apply to an AI product?

Which laws apply depends on where your users are, what the system does and what data it handles. The EU AI Act is the one regulation written for AI across a whole market, so it is the usual starting point if you serve EU users. Other rules sit outside AI law: privacy, consumer protection, anti-discrimination, product liability and sector regulators.

The EU AI Act is Regulation (EU) 2024/1689, published in the Official Journal on 12 July 2024. Its dates changed in 2026. Regulation (EU) 2026/1744, the Digital Omnibus on AI, is in force. As of 9 November 2026, the dates from the [Official Journal text](https://eur-lex.europa.eu/eli/reg/2026/1744/oj) are:

| Duty | Date it applies | Source note |
|---|---|---|
| Chapters I and II (definitions, prohibited practices) | 2 February 2025, except new Art. 5(1) points (ba), (bb) and Art. 5(1a), (1b) from 2 December 2026 | Art. 113 as amended |
| General-purpose AI model duties, including Art. 55 | From 2 August 2025 | Art. 113 |
| Art. 50(2) machine-readable marking, for generative systems already on the market before 2 August 2026 | By 2 December 2026 | Regulation 2026/1744 |
| High-risk systems under Annex III | 2 December 2027 | Art. 113 as amended |
| High-risk systems under Annex I | 2 August 2028 | Art. 113 as amended |

Many blogs still print 2 August 2026 for high-risk duties. That date applied before the Omnibus and now does not for Annex III systems. Check your system's category, because the classification decides which row is yours.

We did not verify US state laws, FTC enforcement positions or sector rules for this page, and they change often. Ask counsel for the current text in each state or sector where you operate. Do not copy a compliance matrix from a vendor blog without opening the statute.

## Which standards support AI compliance?

Standards organize your evidence. None of the ones below replaces a legal duty, and certification to a standard does not mean a regulator accepts it.

| Standard or framework | Type | What it gives you | Checked detail |
|---|---|---|---|
| NIST AI RMF 1.0 (AI 100-1) | Voluntary framework | A structure to govern, map, measure and manage AI risk | Published 26 January 2023. NIST says it is being revised as part of the White House AI Action Plan |
| NIST AI 600-1 Generative AI Profile | Voluntary profile | Suggested actions for generative AI, including red-teaming (MS-2.7-007) | Published 26 July 2024 |
| ISO/IEC 42001:2023 | Certifiable management system | Requirements for an AI management system, with Annex A controls | Published 18 December 2023 |
| CSA AI Controls Matrix v1.1 | Control set | 247 control objectives across 18 domains | CSA July 2026 post |
| NIST IR 8596 Cyber AI Profile | Draft profile | A cybersecurity view of AI | Initial preliminary draft of 16 December 2025. Not final |

If you want a certificate to show customers, read [our ISO 42001 certification guide](/guides/iso-42001-certification/). If you want a framework to organize testing, see [NIST AI RMF and red teaming](/guides/nist-ai-rmf-and-red-teaming/). For a governance structure that spans both, see [AI governance framework](/guides/ai-governance-framework/).

## What evidence do auditors and customers ask for?

Customers and auditors ask for records that show the control exists and ran. Procurement teams send a questionnaire, and regulators or auditors sample documents and systems. The same set of records answers most of them.

- An inventory of AI systems, models, providers and data sources.
- A risk assessment for each system, with method, date and owner.
- Policies for acceptable use, data handling and human oversight.
- Test records: what was tested, how, what was found, what was fixed and what was retested.
- Monitoring and incident records, including model or prompt changes.
- Supplier records for third-party models and tools.
- Training and role records for the people who operate the system.

Keep each record dated and tied to a version of the system. A report that names no build, model version or date is hard to use six months later. Our page on [AI security questionnaires](/ai-security-questionnaires/) lists what buyers usually ask on the security side.

## Where does security testing fit in AI compliance?

Security testing produces evidence for duties about resilience, risk management and resilience. It supports them and does not satisfy them. The text of each rule decides what it asks for, so match the test to the clause.

The EU AI Act shows both sides. Article 15(5) says high-risk systems "shall be resilient against attempts by unauthorised third parties to alter their use, outputs or performance by exploiting system vulnerabilities". It lists attacks the technical solutions should address, including data poisoning, model poisoning, adversarial examples, confidentiality attacks and model flaws. It does not use the words "red team" or "penetration test", so do not say the Act requires one for high-risk systems. Article 9 requires a risk management system for high-risk AI.

Article 55(1)(a) is more specific. Providers of general-purpose AI models with systemic risk must perform model evaluation that includes "conducting and documenting adversarial testing of the model with a view to identifying and mitigating systemic risks". That duty binds model providers, and most application teams are not in that group. See [EU AI Act and red teaming](/guides/eu-ai-act-red-teaming/) for the detail.

Voluntary frameworks are looser. NIST AI 600-1 suggests red-teaming in action MS-2.7-007 and defines it as "a structured testing exercise used to probe an AI system to find flaws and vulnerabilities". A suggested action is not a mandate.

## A compliance checklist by duty

Use this table to find the duty, the evidence to collect, and the test that supports it. Fill the last column from your own system, not from this page.

| Duty type | Ask yourself | Evidence to collect | Test that supports it |
|---|---|---|---|
| Transparency | Do users know they talk to AI? Is generated content marked where a rule asks (Art. 50(2) for generative systems)? | Screenshots, marking method, release notes | Check marking survives export and copy |
| Risk management | Is there a documented risk process for each system? | Risk register, method, review dates | Threat model and an AI risk assessment |
| Security and resilience | Can an outsider alter the system's outputs or actions by exploiting vulnerabilities (Art. 15(5) for high-risk)? | Test reports, fix and retest records | Prompt injection, data poisoning, output handling and tool abuse tests |
| Data and privacy | Does the system expose personal data it should not? | Data flow map, access rules, test results | Cross-user and cross-tenant retrieval tests, see [RAG security](/guides/rag-security/) |
| Human oversight | Can a person stop or override risky actions? | Approval rules, logs | [Approval bypass](/guides/human-approval-bypass/) tests |
| Documentation | Can you show what you shipped and when? | Model and prompt versions, change log | Compare release records with test dates |
| Governance | Does leadership review AI risk? | Management review minutes, policy | Internal audit |

## What a test report does not prove

A test report proves that someone tried specific tests on a specific version in a specific scope and recorded the results. It does not prove that the system is compliant, secure or free of prompt injection. The UK NCSC wrote in December 2025 that prompt injection "may never be totally mitigated in the way that SQL injection attacks can be", so no report can promise the problem is gone.

Three limits apply to any report. The scope may exclude systems that your duty covers. The test date may predate a model or prompt change. And a regulator, auditor or customer sets its own acceptance rules, so no report is accepted everywhere. Say what the report covers when you share it, and attach the retest results for the findings you fixed.

An [AI application security assessment](/llm-application-security-assessment/) gives you the test evidence for the security rows above, with scope, findings and fix guidance. Compliance still needs the legal analysis, the governance records and the sign-off from the people who own those duties.

## Questions

### Is there one AI compliance law for every company?

No. The EU AI Act is a single regulation, but it only reaches you if your system or its output falls under its scope. Other duties come from privacy law, consumer protection, sector rules, state law and contracts. This page is not legal advice. Ask counsel which rules apply to your product and markets.

### Did the EU AI Act deadline for high-risk systems move?

Yes. Regulation (EU) 2026/1744, the Digital Omnibus on AI, moved high-risk duties for Annex III systems to 2 December 2027 and for Annex I systems to 2 August 2028. The 2 August 2026 date for general application was not changed. Check the Official Journal text for your system's category.

### Does a penetration test or red team report make us compliant?

No. A report is evidence that you tested and what you found and fixed. Article 15 of the EU AI Act asks high-risk systems for resilience against manipulation and does not name a pentest. Your auditor, customer or regulator decides what evidence it accepts.

### Do we need ISO 42001 to comply with the EU AI Act?

No source we checked says so. ISO/IEC 42001 is a voluntary management system standard. It can organize the records and processes that regulators and customers ask about, but it does not replace legal duties or a conformity assessment.

### What should a small team do first?

List every AI feature and model you ship or use, and mark where it touches EU users, personal data or automated decisions about people. That inventory tells you which duties to check. Then pick one framework, such as NIST AI RMF or ISO 42001, to organize the evidence.

## Sources

- [Regulation (EU) 2024/1689 (EU AI Act), Official Journal text](https://eur-lex.europa.eu/eli/reg/2024/1689/oj)
- [Regulation (EU) 2026/1744 (Digital Omnibus on AI), Official Journal text](https://eur-lex.europa.eu/eli/reg/2026/1744/oj)
- [NIST AI RMF 1.0 publication page (AI 100-1)](https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-ai-rmf-10)
- [NIST AI 600-1: Generative AI Profile](https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf)
- [IEC Webstore: ISO/IEC 42001:2023](https://webstore.iec.ch/en/publication/90574)
- [CSA: AI Controls Matrix v1.1](https://cloudsecurityalliance.org/blog/2026/07/14/ai-controls-matrix-v1-1-strengthening-the-foundation-for-trustworthy-ai)
- [NIST CSRC: IR 8596 Cyber AI Profile, initial preliminary draft](https://csrc.nist.gov/pubs/ir/8596/iprd)
- [UK NCSC: Prompt injection is not SQL injection (8 December 2025)](https://www.ncsc.gov.uk/blog-post/prompt-injection-is-not-sql-injection)