First, the dates — because they moved
Regulation (EU) 2026/1744 (the "Digital Omnibus on AI") was published in the Official Journal on 24 July 2026 and entered into force on 27 July 2026. It replaced Article 113(3)(c) of the AI Act with fixed dates:
- 2 December 2027 — high-risk obligations for Annex III systems (Chapter III, Sections 1–3, i.e. Articles 6–27, except 6(5)).
- 2 August 2028 — high-risk obligations for Annex I systems (AI embedded in already-regulated products).
- Already in force: Article 4 (AI literacy, softened to "take measures to support", since 27 July 2026), Article 5 (prohibited practices), and Article 50 transparency, since 2 August 2026 — with a grace period to 2 December 2026 for machine-readable marking of AI-generated content by systems already on the market (new Article 111(4)).
Articles 9, 12, 13, 14, 15, 26, 50(1)–(6), Annex III and Annex IV were not amended. Any page still telling you "Article 12 logs by August 2026" is out of date.
Does any of this apply to a GenAI feature in a B2B SaaS?
Article 8(1): "High-risk AI systems shall comply with the requirements laid down in this Section." A chatbot, RAG assistant or coding agent that is not in an Annex III use case (employment, credit, education, essential services, law enforcement, and so on) is not high-risk, and Articles 9–15 and 26 do not apply to it. What does apply today: Article 4, Article 5 and Article 50. The only hook for voluntary application of the high-risk requirements to other systems is Article 95 (codes of conduct).
If your feature does fall in an Annex III category — a hiring screen, a credit decision, a student assessment — and is not exempt under Article 6(3), it becomes high-risk on 2 December 2027, and the table below becomes operational rather than advisory.
EU AI Act — provision by provision
| Provision | What it requires (paraphrase) | Binds | Bundle | Why |
|---|---|---|---|---|
| Art. 9 Risk management | A documented, continuous, iterative risk management system; testing "against prior defined metrics and probabilistic thresholds" (9(8)). | Provider | PARTIAL | Steps 2–5 of our method are direct evidence for the 9(6)–(8) testing step. A bundle is a point-in-time input; it is not the continuous system 9(1)–(2) require. |
| Art. 10 Data governance | Training, validation and testing data meeting quality criteria; provenance documented; for non-trained systems, applies to testing data only (10(6)). | Provider | PARTIAL (narrow) | Only where the engagement's eval set is the provider's testing data set and we document its provenance. Training data is untouched. |
| Art. 11 + Annex IV Technical documentation | Annex IV 2(g): "validation and testing procedures … metrics used to measure accuracy, robustness … test logs and all test reports dated and signed by the responsible persons." | Provider | PARTIAL | This is the closest textual fit in the Act: a signed, dated external test report with test logs. It is one element of the file, not the file. |
| Art. 12 Record-keeping | The system must "technically allow for the automatic recording of events (logs) over the lifetime of the system", capturing risk situations, post-market monitoring and 26(5) monitoring. | Provider (design) | PARTIAL | Domain D evidences whether that capability exists and what it captures. Our bundle's own logs are assessor evidence, not the system's Art. 12 logs. |
| Art. 13 Transparency to deployers | Instructions for use must state "the level of accuracy, including its metrics, robustness and cybersecurity … against which the high-risk AI system has been tested." | Provider | PARTIAL | Measured hallucination and robustness results with their limits are usable content for 13(3)(b)(ii). We do not write instructions for use. |
| Art. 14 Human oversight | 14(4)(e): oversight persons can "interrupt the system through a 'stop' button or a similar procedure that allows the system to come to a halt in a safe state." | Provider (design) | PARTIAL if scoped | The Domain D stop-path test empirically checks whether an interrupt halts an agent in a safe state. Nothing in the bundle addresses interface design or automation bias. |
| Art. 15 Accuracy, robustness, cybersecurity | "Appropriate level of accuracy, robustness, and cybersecurity"; resilience against "inputs designed to cause the AI model to make a mistake (adversarial examples or model evasion)" (15(5)). | Provider | PARTIAL | Hallucination measurement (15(1)) and prompt-injection red-teaming (15(5)) are the most direct fits in the whole Act. We evidence testing, not that an "appropriate level" is achieved across the lifecycle. |
| Art. 26(5) Deployer monitoring | Deployers monitor operation and suspend use if the system may present a risk. | Deployer | PARTIAL (weak) | A logging review shows the deployer has the means to monitor. The obligation is continuous and operational. |
| Art. 26(6) Log retention | Deployers keep automatically generated logs "for a period appropriate to the intended purpose … of at least six months." | Deployer | NONE | A timestamped manifest proves a log extract existed unaltered at time T. Retention is a separate, ongoing duty the bundle does not perform. |
| Art. 50 Transparency | Users told they are interacting with AI (50(1)); synthetic content marked machine-readably (50(2)); deployer disclosure for deep fakes and public-interest text (50(4)). | Provider / deployer | NONE as scoped | None of our four domains tests marking or disclosure. Can be added to scope as screenshot evidence for 50(1). Note the Commission's B2B carve-out is narrow: output must be "strictly technical" and never leave the company. |
| Art. 4 AI literacy | "Take measures to support the development of AI literacy" of staff; no guaranteed level required (post-Omnibus wording). | Provider and deployer | NONE | An evaluation report is not a literacy measure. |
| Art. 72 Post-market monitoring | Providers of high-risk systems document a post-market monitoring system; Commission template due by 2 September 2027. | Provider | PARTIAL | Periodic re-runs of the same reproducible evaluation (a retainer) are usable monitoring data. |
ISO/IEC 42001:2023 — Annex A controls
An independent assessment with signed evidence is audit evidence for your management system, never certification. Controls it supports, with the control statement paraphrased (the standard is paywalled; wording verified against a published Statement of Applicability):
| Control | Statement | Support |
|---|---|---|
| A.6.2.4 Verification and validation | Define and document verification and validation measures and the criteria for their use. | Strong |
| A.6.2.6 Operation and monitoring | Define the elements for ongoing operation, at minimum system and performance monitoring. | Partial (point in time; strong under a retainer) |
| A.6.2.8 Event logs | Determine at which lifecycle phases event logging is enabled, at minimum when in use. | Strong (Domain D) |
| A.6.2.7 Technical documentation | Determine what technical documentation each interested party needs. | Input |
| A.5.2 / A.5.3 Impact assessment | Process and documentation of AI system impact assessments. | Partial — findings feed it |
| A.7.4 / A.7.5 Data quality and provenance | Quality and provenance of data for AI systems. | Narrow — eval set only |
| A.9.2 / A.9.4 Responsible and intended use | Processes for responsible use; intended use documented. | Partial — red-teaming evidences resistance to foreseeable misuse |
| A.10.3 / A.10.4 Suppliers and customers | Supplier usage aligned with the organisation's approach; customer obligations. | Usable as supplier due-diligence evidence |
| A.3.x, A.8.3, A.8.4 Roles, external reporting, incidents | Roles and responsibilities; external reporting; incident communication. | None |
NIST AI RMF 1.0 and the Generative AI Profile (AI 600-1)
Voluntary, and the framework everyone maps to. The MEASURE function is where an external evaluation lives. Quoted subcategories:
- MEASURE 1.3 — "Internal experts who did not serve as front-line developers for the system and/or independent assessors are involved in regular assessments and updates." The one subcategory that names what we do.
- MEASURE 2.1 — "Test sets, metrics, and details about the tools used during TEVV are documented." Our methodology and reproducibility note.
- MEASURE 2.3 — "AI system performance or assurance criteria are measured qualitatively or quantitatively and demonstrated for conditions similar to deployment setting(s)."
- MEASURE 2.5 — validity and reliability demonstrated; "limitations of the generalizability … are documented."
- MEASURE 2.7 — security and resilience evaluated; the GenAI Profile action MS-2.7-007: "Perform AI red-teaming to assess resilience against … GAI attacks (e.g., prompt injection)."
- MEASURE 2.13 — "Effectiveness of the employed TEVV metrics and processes … are evaluated and documented"; MS-2.13-001 asks for measurement-error models and documented bias in applied metrics or human-feedback processes. This is our Domain C, almost verbatim.
- GOVERN 4.3, MAP 5.1, MANAGE 4.1 — supporting evidence only.
AI 600-1 names confabulation — "the production of confidently stated but erroneous or false content (known colloquially as 'hallucinations')" — as GenAI risk number two, and defines AI red-teaming as "a structured testing exercise used to probe an AI system to find flaws and vulnerabilities." Both are what Domains A and B measure.
What we will and will not say
We say: independent technical evaluation; reproducible; evidence of testing against pre-defined metrics; input to your Annex IV technical documentation where high-risk rules apply; supports NIST MEASURE 1.3, 2.1, 2.3, 2.5, 2.7, 2.13 and ISO 42001 A.6.2.4, A.6.2.6, A.6.2.8, A.10.3; supports voluntary application of Chapter III requirements under Article 95.
We do not say: "AI Act compliant"; "conformity assessment" (Article 3(20) — a formal procedure under Article 43); "certified"; "audit" in the statutory sense; "NIST certified"; "presumption of conformity" (Articles 40–41 only); "meets Article 12 or 26(6)"; "required by the AI Act" — none of our four engagement types is required for a non-high-risk system.
What the signature and timestamp are worth in law
eIDAS Article 41(1): an electronic timestamp "shall not be denied legal effect and admissibility as evidence in legal proceedings solely on the grounds that it is in an electronic form." Article 41(2): a qualified electronic timestamp "shall enjoy the presumption of the accuracy of the date and the time it indicates and the integrity of the data to which the date and time are bound." Qualified status requires a trust-listed provider under Article 42.
RFC 3161 is a protocol, not a legal status. Our default timestamp, from a public authority, is admissible under 41(1) without the 41(2) presumption. For EU regulated clients we obtain qualified timestamps on request. Under the AI Act itself, the one textual hook is Annex IV 2(g) — "test logs and all test reports dated and signed by the responsible persons" — which a signed, dated external report satisfies as one element of the provider's file.
Not verified. The official ISO/IEC 42001 text (paywalled — control wording taken from a published Statement of Applicability and two secondary lists); whether the Commission has published the SME simplified technical-documentation form under Article 11(1); the status of CEN-CENELEC JTC 21 harmonised standards for Articles 9–15; national rules on how much weight a non-qualified timestamp receives in a given court.
- Regulation (EU) 2026/1744, OJ L 24 July 2026 — EUR-Lex. White & Case, "EU AI Omnibus enters into force", July 2026.
- Regulation (EU) 2024/1689, consolidated — Articles 3, 4, 6, 8, 9–15, 26, 43, 50, 72, 95, 113; Annex IV — AI Act Explorer.
- European Commission, Guidelines on transparency obligations under Article 50, 20 July 2026, and FAQ.
- Regulation (EU) 910/2014 (eIDAS), consolidated 18 October 2024 — Articles 25, 35, 41, 42, 46.
- NIST AI 100-1, AI Risk Management Framework 1.0 (January 2023); NIST AI 600-1, Generative AI Profile (July 2024); NIST AIRC Playbook, MEASURE.
- ISO/IEC 42001:2023 Annex A — control wording via a published Statement of Applicability (Darktrace) and secondary control lists (DeepInspect, iso42001toolkit), accessed 12 September 2026.