This page is a procurement document. It maps AISB's architectural primitives against the six EU AI Act conformity requirements that apply to high-risk AI deployed in building automation. If you are a legal / procurement reviewer evaluating AISB for an EU-domiciled enterprise, this is the surface to cite. For the narrative thesis, see the August 2 procurement deadline post.

The deadline

2 August 2026 — EU AI Act Articles 9, 10, 14 and 26 become binding for high-risk AI systems. Penalty for non-compliance: up to €35M or 7% of global annual turnover per Article 99(3), whichever is higher. The text is in force; the enforcement date is fixed.

Holland & Knight (April 2026 advisory), Baker Botts (March 2026 client note), and McKenna Consultants (May 2026 legal analysis) converge on the same reading: AI used in safety components of buildings, including HVAC and fire/life-safety control, and AI that influences access to workplaces via occupancy / hazard / code-violation monitoring, falls under Annex III high-risk scope.

Why CRE building automation is in scope

EU AI Act Article 6 + Annex III enumerates eight high-risk categories. Three of them apply directly to building-automation AI:

The first category is the dominant one for CRE smart-building stacks. An AI control loop that adjusts HVAC setpoints based on occupancy sensing, that interacts with code-violation detection, or that influences emergency-egress lighting under fire-alarm logic, is in scope. The "we only optimize comfort" defense does not work — Article 6 looks at the function in the safety system, not the marketing copy.

The six conformity requirements + how AISB satisfies each

EU AI Act requirementWhat it asksAISB architectural primitive
Art. 9 — Risk Management System Documented, iterative risk identification + mitigation across the full AI lifecycle. Update on substantial change. v82 Daily Squad Self-Test Loop — 18-test Standard Suite run nightly (06:30 TPE), routes failures to fix queue. Risk register maintained in data-logs/risk/. Documented retraining trigger thresholds.
Art. 10 — Data Governance Training, validation, testing data sets meet quality criteria. Bias examination. Statistical properties documented. CRE-EN Privacy Broker — differential privacy (Laplace mechanism, per-zone ε-budget), k-anonymity floor, GDPR Art. 9 + Colorado SB-205 + EU AI Act overlay. Per-region consent enforcement at the fusion layer, not bolted on.
Art. 11 — Technical Documentation System purpose, design, training, performance, monitoring — sufficient for a deployer + authority to assess conformity. v61 immutable raw/ landing — content-addressed (SHA-256), chmod 444, never mutated. Provenance preserved end-to-end. Architectural docs versioned in data-logs/beast-os-architecture.md.
Art. 12 — Record-Keeping Automatic logging of events over the system's lifetime. Logs retained at least 6 months. v17 Context Tree + episodic traces — every significant agent output logged to data-logs/memory-lifecycle/traces/ with timestamp, agent, confidence, source. Append-only JSONL. Retention configurable; 6-month minimum is the floor.
Art. 14 — Human Oversight Effective oversight by natural persons. Ability to intervene, override, halt. Awareness of automation bias. Recommend-only architecture (default) — 17 mandatory agents emit assumption_surface_v1 envelopes before action. Tool risk classification routes HIGH-risk actions to Robin. No autonomous money-movement, deployment, or external-comm.
Art. 15 — Accuracy, Robustness, Cybersecurity Appropriate level of accuracy, robustness against errors/inconsistencies, cybersecurity against adversarial attacks. v91 Security Hardening Plane — Trivy SCA, license + secret gates, SBOM, SARIF. Adversarial Ship Gate (v48/v65) — 4-phase intelligent pipeline reviews every patch. Taint-flow guard tracks untrusted content through agent handoff surfaces.

Article 26 — what the deployer obligation actually requires

If you are the deployer (the entity putting the AI system into use in the EU), Article 26 layers four obligations on top of the high-risk system's existing conformity:

  1. Qualified human oversight. Natural persons with the competence, training, authority, and resources to perform the oversight function. Not a checkbox.
  2. Monitor operation per instructions. Inform the provider of identified risks or serious incidents. Suspend use if risks materialise.
  3. Maintain logs for at least 6 months. Auto-generated logs from the AI system, retained, accessible to authorities on request.
  4. Fundamental rights impact assessment (where Annex III §1 / §6 / §7 apply) — documented, prior to first use.

AISB's role here is as the system provider. The deployer obligation rests with the EU-domiciled enterprise. AISB's output is structured to make the deployer's Article 26 burden tractable:

#QuestionAISB answer
1Is your system classified as high-risk under Annex III?Where deployed in HVAC / fire-life-safety control or occupancy-driven access decisions, yes — and we provision for it by default.
2Where is your Article 9 risk-management documentation?v82 Daily Squad Self-Test Loop output + risk register, both versioned. Sample artifacts available under NDA.
3How do you satisfy Article 10 data governance?CRE-EN Privacy Broker — differential privacy + k-anonymity floor + per-region consent. Sample DPIA template available.
4Can you produce Article 11 technical documentation?v61 immutable raw landing + architecture docs. Pre-deployment, we produce a per-tenant Article 11 packet.
5Can you produce Article 12 logs for any decision in the last 6 months?Yes — append-only JSONL traces, queryable by tenant + agent + timestamp. Minimum retention 6 months; configurable higher.
6How is Article 14 human oversight implemented?Recommend-only architecture by default. No autonomous action on the four blast-radius categories (money / deployment / public content / external comm).
7What is your incident-response timeline under Article 26(5)?Detection-to-provider-notification ≤ 24 hours for serious incidents. Detection-to-deployer-alert in real time via the existing alerting surface.
8If our DPA / data residency requires EU-only processing, can you accommodate?Yes — edge-deployment profile available. Microsoft Foundry Local + per-tenant key isolation. No cross-region model fine-tuning without explicit deployer consent.

What this page is not

This is not legal advice. The conformity-assessment process under the EU AI Act is a regulated procedure that produces a CE mark; AISB participates in that process as a provider, but a deployer's own qualification of any AI system for use in the EU is the deployer's own legal responsibility.

This is not a claim that AISB is exempt from the EU AI Act. We are explicitly engineered to meet the high-risk conformity requirements, not to avoid them.

This is not a substitute for the deployer's own Article 27 Fundamental Rights Impact Assessment where Annex III §1 / §6 / §7 applies. That FRIA is the deployer's to author; AISB's outputs are inputs to that document, not a replacement.

Cross-references

Reference list

Page maintained against current legal-source reading. Last reviewed: 11 May 2026. Material legal developments are tracked in the AISB regulatory queue and pushed to this page within 7 days of publication. Procurement teams citing this page in an RFP / RFI response are welcome to do so; please reference the page URL + the review date.

For technical evaluators

Need the developer-facing surface? The MCP-native CRE platform page documents the 9 tool surfaces (CRE-AD / TS / SP / PM / CON / EN squad outputs) anchored on RealEstateCore + IFC 4.3 + Speckle.dev open substrates.

Includes the open-protocol commitment, A2A/MCP routing contract, and standards-anchored output schemas your platform team can review before pilot scoping.

Companion reading — the 2026-05-14 trust trio. Three operator-grade pieces that compound the thread above:

Sources & References — Every Regulatory Claim Traces to Primary Source

Each numbered citation links directly to the EU Commission regulation text, the relevant Article, or the published law-firm advisory. This page’s claims about €35M penalties, the 2 August 2026 enforcement date, FRIA timing, and deployer obligations are anchored to the references below. Legal teams evaluating procurement defensibility can verify every numeric and procedural claim against its primary source.

  1. Regulation (EU) 2024/1689 of the European Parliament and of the Council of 13 June 2024 (the “EU AI Act”) — full consolidated text including all 113 Articles + 13 Annexes: eur-lex.europa.eu/eli/reg/2024/1689/oj. Used to verify all general claims about scope, definitions, and the August 2026 enforcement milestones referenced on this page.
  2. Article 6 (Classification rules for high-risk AI systems) — defines the two-track classification: Annex I (product safety) and Annex III (specific use cases). Article 6 text. Source for “biometric identification in the workplace” and “essential infrastructure management” high-risk classifications cited under Annex III on this page.
  3. Article 9 (Risk management system) — mandates a continuous iterative risk-management process across the lifecycle of high-risk AI systems. Article 9 text. Source for the “continuous risk-management” mapping to BEAST OS v82 Daily Squad Self-Test on this page.
  4. Article 14 (Human oversight) — requires high-risk AI to enable effective human oversight, including the ability to override decisions. Article 14 text. Source for the “Recommend-only architecture” design pattern cited on this page.
  5. Article 26 (Obligations of deployers of high-risk AI systems) — the deployer (operator/owner) obligations layer that is the principal procurement-relevant Article for CRE buyers. Article 26 text. Primary anchor for the deployer-obligations breakdown on this page.
  6. Article 27 (Fundamental Rights Impact Assessment, FRIA) — the deployer-side assessment required before placing certain high-risk systems into service. Article 27 text. Source for the “FRIA gating” claim on this page.
  7. Article 99 (Penalties) — sets administrative fines up to €35M or 7% of total worldwide annual turnover for prohibited-practices violations; up to €15M or 3% for non-compliance with high-risk obligations. Article 99 text. Source for the “€35M or 7%” figure on this page.
  8. Annex III (High-risk AI use cases) — eight enumerated categories including biometric ID, education access, employment/worker management, essential services access, and critical-infrastructure management. Annex III text. Used to determine which CRE use cases map to high-risk classification.
  9. European Commission — AI Act overview & FAQ (Directorate-General for Communications Networks, Content and Technology): digital-strategy.ec.europa.eu. Source for the August 2026 enforcement timing for high-risk obligations and the Article 50 Code of Practice June 2026 reference window.
  10. Holland & Knight LLP — client advisory on EU AI Act enforcement readiness (April 2026): hklaw.com/en/insights/publications. Multi-firm legal consensus referenced for the procurement-defensibility framing on this page.
  11. Baker Botts LLP — client note on AI Act deployer obligations (March 2026): bakerbotts.com/thought-leadership. Source for the “24-hour notification” and post-market monitoring breakdown.
  12. McKenna Consultants — EU AI Act legal analysis (May 2026): mckenna-consultants.com/insights. Third independent legal-advisory source confirming the deployer-obligations framing.

Source-traceback contract: every numeric, regulatory, and procedural claim on this page is anchored to one of the references above. If a claim’s source is missing or unreachable, flag it to robinmaa1736@gmail.com — we maintain this as a procurement-defensibility surface, not a marketing page.

Companion reading