Level 0-1 · fail-closed

Tier 1 governance — the regulatory veto right

Tier 1 governance agents are regulatory AGENT-GUIDEs injected into development sessions based on context: a project processing personal data activates AIAD-RGPD, an AI component in a European context activates AIAD-AI-ACT. They hold an absolute veto right over any non-compliant deliverable — when a SPEC conflicts with a governance agent, the governance agent prevails.

The AIAD doctrine defines four Tier 1 agents: AIAD-AI-ACT, AIAD-RGPD, AIAD-RGAA and AIAD-RGESN. The aiad-sdd package additionally ships an AIAD-CRA agent as a complement for software products placed on the EU market, bound by the same veto contract.

In the SDD Mode documentation hierarchy, these agents sit just below the AIAD Constitution, above the PRD, the ARCHITECTURE and the SPECs. No lower-level artifact may contradict them, and no veto verdict may be ignored — not even by the human within the normal flow of the cycle: lifting a veto requires a documented decision outside the cycle, never a silent bypass of the agent.

Uncertainty policy — fail-closed

If the agent cannot decide whether a Tier 1 framework applies — a module whose data, AI or interface footprint is unclear, an undocumented scope, a source file only partially readable — the default verdict is UNKNOWN, treated as a VETO until the ambiguity has been resolved on the human side. The agent never concludes "not applicable" from an absence of evidence. This is the application of the JNSP uncertainty policy (JNSP: "Je Ne Sais Pas" — I don't know) to the regulatory domain.

The expected form in the output of the regulatory-veto skill is structured:

verdict: UNKNOWN
referential: <AIAD-XXX>
reason: <what is missing to decide>
question: <reformulation for the human>

Priority hierarchy between frameworks

Several frameworks can apply simultaneously to the same code — a chatbot processing health data accumulates AI Act, RGPD and RGAA. In case of conflict, the priority order is fixed:

1. AI Act Art. 5 (prohibitions) — absolute priority, full stop;
2. RGPD + Art. 9 — a reinforced legal basis is required for sensitive data, before any implementation;
3. AI Act high-risk — procedural obligations: documentation, human oversight, logging;
4. RGAA — the interfaces required by the AI Act (disclosure, oversight, appeal) must be accessible;
5. RGESN — energy optimisation, in compliance with the four levels above.

One practical consequence: a frugal but inaccessible site violates the RGAA — frugality never justifies sacrificing accessibility or the protection of individuals.

AIAD-AI-ACT — Regulation (EU) 2024/1689

Triggered whenever the code involves an AI component (ML, LLM, scoring, recommendation). The agent enforces a risk-level qualification at the start of the session: unacceptable risk (Art. 5 — prohibited, escalation to leadership), high risk (Annex III — full regime: Art. 11 documentation, Art. 10 data quality, Art. 14 human oversight, Art. 72 monitoring), limited risk (Art. 50 — mandatory disclosure of chatbots and generated content) or minimal risk.

The application timeline was amended by Regulation (EU) 2026/1744 (Digital Omnibus on AI), adopted and published in the Official Journal of the EU on 24 July 2026, in force since 27 July 2026. It amends the EU AI Act as well as Regulations (EU) 2018/1139 (civil aviation) and 2023/1230 (Machinery Regulation). The agent applies the following consolidated timeline:

Compliance roadmaps built before July 2026 need revisiting in both directions: high-risk obligations move back (risk of a false sense of urgency), while transparency already applies and the new prohibitions arrive in December 2026 (risk of a false sense of slack). A postponement is not an exemption: a high-risk system designed today will be in production by those dates. For an agent that generates images, audio or video, safeguards against the content covered by points (b a) and (b b) are a design requirement, written into the SPEC and checked at the Execution Gate. Finally, since the Commission can now sanction GPAI model providers, the agent recommends a fallback plan to another model (model-agnostic approach): the availability of a model in the EU is not guaranteed.

The Human Authorship principle is the framework's direct answer to the human-oversight requirements of Article 14: a system where the human authors the intent and retains the override is, by construction, aligned with the AI Act. Maximum penalties: €35M or 7% of worldwide turnover for prohibited practices.

Emerging profile — agents with irreversible effects

An agent that can pay, purchase, subscribe, trigger a production deployment or act on physical equipment is no longer a mere content generator. This profile (formerly "agents with financial and operational autonomy") is qualified specifically from the initial qualification onwards:

• if it influences a decision affecting people in an Annex III domain (credit, essential services, employment…), it falls under the high-risk regime and its full obligations;
• outside Annex III, the EU AI Act imposes no oversight obligation specific to this profile. As soon as it has irreversible effects, AIAD nonetheless applies, as good practice, checkpoints inspired by Articles 9 (risk management), 12 (record-keeping), 14 (human oversight) and 26 (deployer obligations) — and general law (civil liability, GDPR, consumer law) continues to apply.

Minimum human checkpoints before any go-live: validation of the initial delegation by an identifiable human (who, what, how far); a documented cap, technically enforced; an immutable, timestamped audit log; a rollback procedure for every reversible effect, irreversible effects being listed and subject to prior validation; a reversibility class declared in the Drift Criterion of the Intent Statement (reversible, costly to reverse, irreversible); a stop threshold — any observed overrun (cap, scope, attempt to alter its own traces) stops the agent and triggers an immediate human review, a provider billing alert being no substitute; and verified isolation of the execution environment. If a SPEC involves such an agent, the Execution Gate validates these caps in addition to SQS ≥ 4/5.

AIAD prescribes properties, not products:

Outside high risk, the links to Articles 12 and 14 are AIAD good practice, not a legal obligation. Even when a protocol provides its own caps, a designated human owner is still required for each delegation: an infrastructure safeguard is not an accountability framework.

Physical effects. The irreversible class includes actions on physical equipment (instruments, robots, machines), with the same checkpoints. The safety of a cyber-physical system is never handled by this framework alone: it falls under established standards (IEC 61508, ISO 13849, ISO 14971) and, for machinery, the Machinery Regulation — the agent escalates to the Tech Lead and to a safety specialist. The authority continuum, stop points and execution perimeter that frame these agents within the SDD cycle are described on the Agent autonomy page.

Delegation trail

Every task entrusted to an agent is linked to an Intent Statement (identified human author), a SPEC (delegated scope) and the Execution Gate trace (human validation). The organisation answers for what its agents do: without this trail, it can demonstrate neither its due diligence nor the origin of the code. The agent never starts a task whose human origin cannot be traced. This trail makes accountability demonstrable in both directions: a defective SPEC validated at the Gate commits the person who validated it — a trail that could only exonerate would not be evidence. The idea that an organisation must answer for its agents is a thesis AIAD adopts (Schneier and Sanders, 2026) — a thesis, not settled law.

AIAD-RGPD — Privacy by Design

Triggered whenever the code processes personal data. The guiding principle fits in one sentence: data that is not collected cannot be breached. The agent applies Privacy by Design & by Default (Art. 25) architecturally: a documented legal basis before any collection (consent, contract, legal obligation, legitimate interest…), minimisation (Art. 5.1.c), purpose and retention limitation, and implementation of data-subject rights (Art. 15-22) — access, erasure, portability, rectification, objection, with a response within 30 days. Sensitive data (Art. 9: health, biometrics, opinions, sexual orientation…) triggers a block and a systematic escalation to the DPO or the PM before implementation.

Automated decisions and agents (Art. 22 GDPR)

An agent that decides on its own an effect significant for a person — access to a service, rating, sanction, exclusion — falls within the scope of Article 22. Precedent: on 21 August 2026, the Dutch Data Protection Authority (AP) fined Uber €824,990,000 for deactivating drivers' accounts without any human assessment (Art. 22) and for failing to provide information about that automated decision — on the basis of the GDPR alone. Uber has appealed: this is a sanction, not settled case law.

AIAD draws a criterion from it: human intervention only counts if it is real, not nominal, that is, if it meets four conditions — effective power (the reviewer can overturn the decision and does so in an observable share of cases), competence and authority (training and mandate to judge the case), sufficient information (access to the elements underlying the agent's proposal, not just its output) and traceability (a timestamped, attributable review, with decision and rationale). Bulk validation, a systematic confirmation click or after-the-fact sample checks do not meet these conditions.

An account deactivation is an action with significant effect, often costly to reverse for the person: the reversibility class of the "agents with irreversible effects" profile applies here too.

Model data residency

For any transfer outside the EU, the agent now also checks the data residency of the model itself, for the distribution channel used and as of the deployment date: the same model may offer an EU residency guarantee on one platform and not on another. Commercial availability does not mean production-readiness for a regulated sector.

Agentic AI in the DPIA

Any data protection impact assessment (DPIA) covering an agent system examines the four points of tension identified by the exploratory note on agentic AI from the CNIL and the French Council for AI and Digital Affairs — a non-prescriptive note, from which AIAD derives a set of questions:

AIAD-RGAA — digital accessibility

Triggered whenever the code produces a user interface. Reference framework: RGAA 4.1.2 (decree of 20 September 2024, 106 criteria across 13 themes), built on WCAG 2.1 levels A and AA. The French legal obligation stems from Article 47 of law 2005-102 for the public sector, and since 28 June 2025 from the European Accessibility Act for a broad private-sector scope (banking, e-commerce, transport, telephony). The agent enforces built-in accessibility — alt text on images, 4.5:1 contrast ratios, form labels, keyboard navigation, visible focus, aria-current, skip link — because fixing it afterwards costs ten times more. Supervisory authority: ARCOM; penalties up to €300,000 within the EAA scope.

AIAD-RGESN — digital eco-design

Triggered by every technical decision (performance, resources, dependencies) — it is the agent with the broadest scope. Reference framework: RGESN v2 (May 2024, ARCEP / ARCOM / ADEME / DINUM, 79 criteria, 9 themes). It embodies the AIAD value of Intentional Frugality: every line of code has a real energy cost. The Algorithms theme specifically targets computational frugality: a deterministic business rule consumes 100 to 10,000 times less than an LLM inference, the smallest sufficient model must be chosen, and every LLM call is token-capped and cached. Findings quantify the impact (kWh, gCO2eq) using an ADEME or Ecoindex methodological baseline.

AIAD-CRA — Cyber Resilience Act (shipped as a complement)

The CRA agent is not one of the doctrine's four Tier 1 guides: it is shipped as a complement by the aiad-sdd package for software products, under the same veto contract. Triggered for any software product intended for the EU market. Reference framework: Regulation (EU) 2024/2847, in force since 10 December 2024, fully applicable on 11 December 2027. The obligation to report to ENISA has applied since 11 September 2026: actively exploited vulnerabilities must be reported within 24 hours. The agent checks the 13 essential requirements (secure-by-design, secure default configuration, encryption, minimal attack surface, signed updates…) and the 8 vulnerability-management obligations: a CycloneDX SBOM regenerated for every release, a SECURITY.md with response SLAs, free patches, a CHANGELOG referencing CVEs. Before each release tag, it blocks if the SBOM is missing or if a vulnerability with CVSS ≥ 7 is unpatched. Penalties: up to €15M or 2.5% of worldwide turnover.

Regional governance packs

The Tier 1 baseline (AI-ACT, RGPD, RGAA, RGESN), complemented by the CRA agent, is EU/France-centric. For other jurisdictions and sector-specific contexts, governance packs add agents under the same contract: fail-closed veto, read-only, mandatory evidence.

A marketplace catalogue additionally references premium sector packs distributed separately (content under restrictive licences): EU healthcare (HDS, ISO 27799, MDR/IVDR), automotive (TISAX, UN R155, ISO/SAE 21434), aerospace (DO-178C, DO-326A) and industrial (IEC 62443, NIS2). They are installed via aiad-sdd gouvernance --pack-from <path>, as SHA-256-signed packs.

Claude Code subagents

Under Claude Code, each Tier 1 agent also exists as a subagent in .claude/agents/ (AIAD-AI-ACT, AIAD-RGPD, AIAD-RGAA, AIAD-RGESN), generated from the single source .aiad/gouvernance/ by npx aiad-sdd emit-rules. Their execution contract is non-negotiable:

• read-only — tools restricted to Read, Grep, Glob; Edit, Write and Bash explicitly forbidden;
• proactive triggering — the PROACTIVELY review description and path patterns (**/api/**, **/auth/**, **/gdpr/**…) cause Claude Code to invoke them without being asked;
• clear-cut verdict — CONFORME (compliant), NON-CONFORME (non-compliant) or UNKNOWN (= VETO), each verdict citing file:line evidence;
• blocking veto — advisory for the model, but enforced at the PreToolUse/Stop hook level.

Agent updates and shipped doctrine

• Backup of locally adapted agents. npx aiad-sdd update updates the project's governance agents, but a locally modified agent is first copied to AIAD-<X>.md.bak-YYYY-MM-DD in the same folder, then replaced; the command lists the backups created and prompts you to carry over your adaptations. A .aiad/gouvernance/.aiad-shipped.json manifest keeps the fingerprint of each agent as shipped, to tell a local modification apart from a mere older version. update --check writes nothing.
• Locked shipped doctrine. The package embeds the AIAD doctrine with a doctrine.lock.json fingerprint file: continuous integration checks that the shipped files have not been modified, and a release whose doctrine differs from the published version is blocked.

Related commands

All three rely on the regulatory-veto skill, which issues a PASS / WARN / VETO verdict with structured remediation — and UNKNOWN = VETO when it cannot decide. Ignoring a Tier 1 veto is one of SDD Mode's absolute prohibitions, on the same level as coding without a validated SPEC.