August 2, 2026 is the date EU AI Act Article 26 deployer obligations bind. As of May 2026 — when this lesson is written — the architect has roughly twelve weeks to convert the regulation from a slide deck into a control plane the team can demonstrate. Article 26 is not the only relevant framework: NIST's AI Risk Management Framework with the Generative AI Profile (AI 600-1) is the de facto reference U.S. boards expect, and ISO/IEC 42001:2023 is the certification basis enterprise buyers increasingly demand in vendor questionnaires. The temptation is to treat the three as three projects. The architect's job is the opposite: translate the three into a single internal control set so the team executes once and produces evidence three times. This lesson is that translation. Which agents trigger Article 26's deployer obligations under Annex III high-risk categories. What the Fundamental Rights Impact Assessment (FRIA) actually contains and when it is required. How the 6-month log retention discipline becomes operational. How NIST's GOVERN / MAP / MEASURE / MANAGE functions map to the same evidence. How ISO 42001's clause 8.3 operational planning and control aligns. The single control set, with cross-references, the architect uses to brief Legal, Security, and the audit committee in one conversation rather than three.

The Three Frameworks and Why One Control Set

The first instinct of a new program is to read each framework end-to-end and produce three separate response documents. By the time the third document is in review, the first is out of date and contradicts the second. The architect's better path is to read each framework with one question: what evidence does this framework expect, and where does that evidence overlap with the others? The answer is: roughly 70-80% overlap. A single control set with framework cross-references covers the overlap; framework-specific addenda cover the remaining 20-30%.

EU AI Act Article 26 in one paragraph

Article 26 of Regulation (EU) 2024/1689 imposes obligations on deployers of high-risk AI systems — the entities that put a system into use, not the provider that built it. The obligations include: ensure human oversight of the system; use the system in accordance with the provider's instructions; monitor operation against the intended purpose; inform the provider and affected persons if serious incident occurs; retain automatically generated logs for at least six months; for some deployers, conduct a Fundamental Rights Impact Assessment before first use. The obligations attach to AI systems classified as high-risk under Annex III: biometric identification and categorization, critical infrastructure, education and vocational training, employment and worker management, access to essential private and public services (including creditworthiness), law enforcement, migration / asylum / border control, administration of justice and democratic processes. Most agent programs in 2026 will not deploy systems formally classified as high-risk under Annex III — but many will deploy systems adjacent enough that the architect should apply Article 26 controls anyway for risk-management and demonstration purposes.

NIST AI 600-1 in one paragraph

The Generative AI Profile of NIST's AI Risk Management Framework, released in July 2024 as NIST AI 600-1, applies the four NIST RMF functions — GOVERN, MAP, MEASURE, MANAGE — to generative AI specifically. It enumerates twelve risk categories particular to generative AI (CBRN, confabulation, dangerous content, data privacy, environmental impact, harmful bias, human-AI configuration, information integrity, information security, intellectual property, obscene content, value chain) and lists ~200 suggested actions across the four functions. Unlike the EU AI Act, NIST is not law — it is a voluntary framework. But the voluntary part is misleading: U.S. enterprise procurement, board oversight, federal contracting, and insurer questionnaires increasingly reference AI 600-1 by name. A 2026 vendor assessment that cannot speak fluent AI 600-1 is a vendor assessment behind the curve.

ISO/IEC 42001:2023 in one paragraph

ISO/IEC 42001:2023 is the world's first AI Management System Standard, structured like ISO 27001 (Information Security Management) and ISO 9001 (Quality Management). It defines requirements for establishing, implementing, maintaining, and continually improving an AI management system. The structure: clauses 4 (context), 5 (leadership), 6 (planning), 7 (support), 8 (operation), 9 (performance evaluation), 10 (improvement) plus Annex A (controls) and Annex B (implementation guidance). Clause 8.3 ("AI system impact assessment") and clause 8.4 ("Lifecycle management") are the most agent-relevant operational clauses; Annex A controls A.6.1 through A.10.5 cover policy, organizational roles, resources, impact assessments, lifecycle, data, information for interested parties, use of AI systems, and third-party relationships. Certification to ISO 42001 is increasingly a procurement gate. The architect's interest is using the standard as the spine of the internal control set even when formal certification is not (yet) being pursued.

Which Agents Trigger Article 26 Deployer Obligations

Most of an architect's worry on Article 26 is identifying which agents are deployer-obligated. The classification is binary at the system level: a system is or is not high-risk per Annex III. The agent program inventory becomes the working list against which the classification is applied.

Annex III categories in agent-program language

Translating the legal categories into agent use cases an architect actually sees in 2026:

• Biometric identification and categorization. Voice agents that use voice biometrics for identification. Vision agents that process facial images for identification or characteristic inference. Excluded: authentication of an enrolled user for the user's own account (a narrower category).
• Critical infrastructure. Agents that manage or control safety components of critical digital infrastructure, road traffic, water, gas, heating, electricity. Includes operational technology orchestration agents in regulated utilities.
• Education and vocational training. Agents that determine admission to education, evaluate learning outcomes, assess level of student, monitor for prohibited behavior in tests. Includes some classes of learning-platform tutoring agents and proctoring agents.
• Employment and worker management. Agents that screen or filter job applications, evaluate candidates, make hiring or termination decisions, allocate tasks based on individual behavior, monitor and evaluate performance and behavior. This is the highest-probability category for a typical enterprise agent program in 2026: any HR-screening agent, any worker-monitoring agent.
• Access to essential private and public services. Credit scoring, evaluating creditworthiness of natural persons, evaluating eligibility for essential public services (benefits, healthcare). Includes some classes of underwriting agents and benefits-determination agents.
• Law enforcement. Agents in law-enforcement contexts assessing risk of offense, evaluating reliability of evidence, predicting commission of offense, profiling natural persons.
• Migration, asylum, border control. Agents used as polygraphs, agents assessing risk of person crossing borders, examining asylum applications.
• Administration of justice and democratic processes. Agents assisting judicial authorities in researching and interpreting facts and the law, applying law to a concrete set of facts, influencing the outcome of elections.

A 2026 mid-market enterprise's agent portfolio typically has zero to three Annex III systems. Most agents (customer-success drafting, code review, internal Q&A, sales-ops, finance-ops, marketing) fall outside Annex III. The high-probability category is employment and worker management — if a team has built a screening or evaluation agent, it is in scope. The credit-scoring category catches some financial services agents. Education catches some EdTech agents. The rest are usually outside.

Substantial modification and the provider trap

One subtlety: an organization that "substantially modifies" a high-risk AI system is treated as a provider of that system, with the heavier provider obligations attaching. The architect's question: does the team build agents that materially alter the behavior of an underlying high-risk model or platform? Fine-tuning a foundation model with internal data on hiring decisions, for example, may cross the substantial-modification line. The classification is contextual; the architect documents the team's position with legal.

Built-in deployer obligations regardless of classification

Independent of Annex III classification, a deployer that knows or should know a system is being used in a context where it materially affects rights or duties has duties under both Article 26 and the broader GDPR / sectoral framework. The architect's safest posture is to apply Article 26 controls to all high-risk and medium-risk agents in the inventory, regardless of whether Annex III strictly applies. The cost is incremental; the upside is that the team is positioned for Article 26 compliance for any agent that escalates into Annex III through scope creep or regulatory expansion.

The FRIA and the Deployer Checklist

For deployers of certain high-risk AI systems — particularly bodies governed by public law, private operators providing public services, and certain financial-services deployers — the Act requires a Fundamental Rights Impact Assessment (FRIA) before first use. The FRIA is the operational artifact most architects underestimate.

What a FRIA actually contains

The Act specifies the FRIA must include:

• A description of the deployer's processes in which the high-risk AI system will be used in line with its intended purpose
• A description of the period of time within which, and the frequency at which, each high-risk AI system is intended to be used
• The categories of natural persons and groups likely to be affected by use in the specific context
• The specific risks of harm likely to have an impact on those categories of persons or groups identified
• A description of the implementation of human oversight measures, according to the instructions for use
• The measures to be taken in case the risks materialize, including arrangements for internal governance and complaint mechanisms

The right template is a 6-12 page document with named sections. The architect's job is to make the document tractable for the agent owner: provide a template with prompts; require the agent's business owner and legal contact to co-sign; file in the agent register. The FRIA is updated when the agent's use changes materially.

The full Article 26 deployer checklist

For each agent classified as Annex III high-risk in the register, a 12-item checklist:

1. Use in accordance with provider's instructions. The instructions-for-use from the model or platform provider are filed; the deployment respects them; deviations are documented.
2. Human oversight measures. Specific human-in-the-loop or human-on-the-loop arrangements are documented per use case.
3. Input data appropriateness. Where the deployer controls input data, the data is sufficiently representative for the intended purpose.
4. Monitoring of operation. The agent's operation is monitored against intended purpose; the inventory documents what monitoring exists.
5. Serious-incident reporting. When the system functions in a way that constitutes a serious incident, the provider and competent authorities are informed without undue delay.
6. Risk-of-fundamental-rights infringement reporting. Where the deployer considers the system poses a risk of infringement of fundamental rights, the provider and authorities are informed.
7. Log retention. Automatically generated logs are retained for at least six months, in a manner appropriate to the system's purpose.
8. Worker information. Before deployment in the workplace, workers' representatives and affected workers are informed.
9. Data protection impact assessment. Where required by GDPR Article 35, a DPIA is performed (and the FRIA can be combined with it).
10. FRIA performed. Where required (banks, insurance, public bodies, certain operators), the FRIA is performed and submitted to the relevant authority.
11. Affected-persons information. Natural persons subject to decisions assisted or made by the system are informed.
12. Right-to-explanation cooperation. The deployer cooperates with the right of affected persons to obtain clear and meaningful explanations of decisions.

The checklist becomes a register column with a link to the evidence for each item. An auditor asks "show me item 7 for this agent" and the register answers with a link to the Datadog retention policy showing 365-day retention plus the LangSmith trace store policy.

The Six-Month Log Retention Discipline

Item 7 is operationally the heaviest. Six months of logs sounds easy until the architect computes what it actually means at agent-program scale.

What counts as a log under Article 26

"Automatically generated logs" includes anything the system records about its operation that can be used to assess functioning against intended purpose. For an agent, the practical reading: full input, full output, tool calls with arguments, tool responses, model identifier, prompt version, eval-set version, user identifier (where applicable, under GDPR), business-context identifier (which ticket, which case, which document), timestamp, latency, cost, any flags raised by guardrails or moderation.

The temptation is to log only summary metrics. The temptation is wrong: an auditor evaluating a serious incident months later needs to reconstruct what happened, not just count how often it happened.

Cost arithmetic

A high-volume agent — say 100K calls per day, 4KB average payload per call — generates ~12GB per day of raw log data, or ~2.2TB over six months. Multiplied across a portfolio of 47 agents (a mid-size 2026 program), the storage footprint is non-trivial but very manageable in 2026 cloud-storage pricing: ~100TB at ~$23/TB-month for S3 Standard-IA = ~$2,300/month. Glacier-tier retention is cheaper still. The cost objection is not the bottleneck; the discipline is.

Retention architecture

A defensible architecture has three tiers: hot (last 7-30 days, queryable in the observability platform — Datadog, Splunk, LangSmith, Helicone, Langfuse, AgentOps.ai), warm (30-180 days, queryable with some delay — typically S3 + Athena or equivalent), cold (180+ days, accessible for compliance review — Glacier or equivalent). Personal data is segregated by data-subject identifier to allow GDPR Article 17 erasure requests; pseudonymization at write reduces the surface.

The architect's audit-ready answer: a log retention policy document specifying the tier architecture, retention periods per tier, access controls, GDPR erasure handling, and per-agent verification that the agent's logs flow through the pipeline. Retention is verified quarterly by sampling: pick a random call from 5 months ago and confirm reconstruction.

NIST AI 600-1 Mapping

The NIST framework provides a structured way to demonstrate that the agent program does what it says. The four functions map cleanly to controls the team already runs.

GOVERN — the program-level layer

GOVERN actions in AI 600-1 include policies, accountabilities, structures, and processes that the program runs across all agents. The evidence: AI use policy. Agent governance committee charter. Risk tiering rubric. Intake form. Incident response plan. Roles and responsibilities document. Training records. Third-party governance procedures. The agent inventory itself.

MAP — the per-agent context layer

MAP actions identify the context in which each agent operates and the specific risks it poses. The evidence: each agent's intake-form submission. Each agent's FRIA where applicable. The risk-tier rationale. The stakeholder-impact analysis. Data flow diagrams. Use-case fit-for-purpose analysis. Each agent's eval set, organized by risk category.

MEASURE — the operational telemetry layer

MEASURE actions quantify identified risks. The evidence: eval scores by risk category (confabulation rate, harmful-bias eval, data-privacy eval, information-integrity eval, value-chain eval). Production-traffic monitoring with shadow eval. SLO compliance reports. Incident counts and types. Cost-per-run metrics. The architecture diagrams showing where measurements happen.

MANAGE — the response and improvement layer

MANAGE actions act on the measurements: prioritize, treat, escalate. The evidence: action items from incidents. Eval set growth tied to incidents. Risk-treatment decisions documented. Resourcing decisions documented. Lessons-learned reviews. The QBR artifact described in the inventory lesson.

The cross-reference table

For each control in the internal control set, the architect maintains a cross-reference column: which Article 26 obligation it satisfies, which NIST AI 600-1 action(s) it implements, which ISO 42001 clause and Annex A control it addresses. The cross-reference table is what makes "one control set, three frameworks" credible to an audit committee and to external auditors.

ISO/IEC 42001 Mapping

ISO 42001 is the framework most likely to drive procurement gates in 2026-2027 as enterprise buyers add AI-management-system certification to vendor questionnaires. Even without pursuing formal certification, mapping the internal control set against 42001 makes the program defensible to the buyer who is.

Clause 4-7 — the management-system foundation

Clauses 4 (context), 5 (leadership), 6 (planning), and 7 (support) cover the program-level GOVERN equivalent: scope, leadership commitment, AI policy, objectives, planning, resources, competence, awareness, communication, documented information. Evidence: the same artifacts NIST GOVERN expects.

Clause 8 — operation, where agents live

Clause 8 is the operational heart. Clause 8.1 (operational planning and control), 8.2 (AI risk assessment), 8.3 (AI system impact assessment, similar to FRIA), 8.4 (lifecycle management — design, development, validation, deployment, operation, change, decommissioning). Clause 8.3 is where the FRIA template doubles as the ISO impact-assessment artifact. Clause 8.4 is where the agent register's lifecycle column maps.

Clause 9-10 — performance evaluation and improvement

Clause 9 (performance evaluation): monitoring, measurement, analysis, evaluation, internal audit, management review. Clause 10 (improvement): nonconformity and corrective action, continual improvement. Evidence: SLO reports, incident postmortems, action item completion rates, QBR. The same evidence NIST MEASURE and MANAGE require.

Annex A controls that bind directly

A.6.1 AI policy. A.6.2.x roles and responsibilities. A.7 resources. A.8 impact assessment processes. A.9 lifecycle. A.10 information and communication for interested parties. Each Annex A control maps to one or more internal controls.

The Single Internal Control Set

The output of this lesson is a single document — call it the Internal Agent Control Set — that lists each control, what it does, and a column per framework showing cross-reference.

The control list (typical mid-market program)

1. AI / agent use policy
2. Agent governance committee charter
3. Risk-tiering rubric
4. Agent intake form
5. Agent inventory / register
6. FRIA template + procedure
7. Article 26 deployer checklist (per high-risk agent)
8. Eval-set procedure (golden / edge / adversarial)
9. Pre-prod eval gate
10. Shadow eval on production traffic
11. SLO definition + monitoring
12. Incident response runbook
13. Postmortem template + procedure
14. Log retention policy (six-month minimum, tiered architecture)
15. OAuth scope policy
16. MCP server allowlist procedure
17. Identity policy (delegated vs service principal)
18. Consent and worker information procedure
19. Affected-persons information procedure
20. Right-to-explanation procedure
21. Vendor / model provider third-party governance
22. Training and awareness program
23. Tabletop exercise procedure
24. Quarterly portfolio review
25. Annual program review

For each control, four columns: control description, evidence location, Article 26 cross-reference, NIST AI 600-1 cross-reference, ISO/IEC 42001 cross-reference. The cross-reference column lists specific paragraph numbers, sub-action identifiers, and clause numbers — not just framework names.

Worked cross-reference example: control 14, log retention

Control description: automatic, query-able retention of full input, full output, tool calls, tool responses, model identifier, prompt version, eval-set version, user/business identifier, timestamps, latency, cost, and guardrail flags for every production agent call, for a minimum of 6 months in hot/warm/cold tiered architecture; GDPR Article 17 erasure handling; quarterly sampled reconstruction verification.

Evidence location: Log Retention Policy v3.1 (link), per-agent ingestion validation report (link), GDPR erasure handling SOP (link), quarterly verification report Q1 2026 (link).

Article 26 cross-reference: Article 26(6) (six-month log retention obligation for high-risk AI deployers).

NIST AI 600-1 cross-reference: GV-1.6 (mechanisms developed to ensure incidents can be retrospectively analyzed), MS-2.5 (system performance monitoring), MG-4.1 (documentation of incidents and responses).

ISO/IEC 42001 cross-reference: Clause 8.4 (lifecycle management — operation), Clause 9.1 (monitoring, measurement, analysis, evaluation), Annex A.10.3 (information and communication for interested parties), Annex A.9.4 (operation).

The one control satisfies the three frameworks. The auditor asks; the control sheet answers; the evidence links resolve.

The Twelve-Week Execution Plan

From May 2026 to August 2, 2026 is roughly twelve weeks. The architect's plan, week by week:

• Weeks 1-2. Complete the agent inventory and risk tiering (from Lesson 1) for every agent. Identify the subset that falls under Annex III. Identify the broader high-risk and medium-risk tiers.
• Weeks 3-4. Draft the FRIA template and Article 26 deployer checklist. Walk one Annex III agent end-to-end through the template to validate. Refine.
• Weeks 5-6. Complete FRIAs for every Annex III agent. Document gaps (where a FRIA cannot yet be completed because the data is not collected). Plan to close gaps before August 2.
• Weeks 7-8. Implement six-month log retention end-to-end. Verify ingestion. Run a sampled reconstruction test (pick a call from yesterday and reconstruct).
• Weeks 9-10. Document the internal control set and the cross-reference table. Review with legal and security.
• Weeks 11-12. Audit-readiness rehearsal: a mock audit walkthrough where the program owner answers the 12-item deployer checklist for each Annex III agent against actual evidence. Close any remaining gaps.

The plan is aggressive but feasible. The risk if it slips: August 2 arrives with Annex III agents in production but without FRIA or six-month-retention evidence. The remedy at that point is to pause the affected agents until compliance is achieved, which is a costlier remedy than executing the plan now.

Anti-Patterns and Traps

The three-framework treadmill

Treating the three frameworks as three projects produces three documents that contradict each other and an unreviewable mountain of paper. Remediation: one control set, framework cross-references. Evidence is produced once.

The Annex-III blind spot

The program owner assumes "we don't do hiring decisions, so no Annex III agents." A team has quietly deployed a recruiter-assist agent that scores resumes. The blind spot. Remediation: the intake form's regulatory-regime question is explicit about Annex III categories; the program owner does an active sweep for screening, monitoring, and scoring agents quarterly.

The FRIA-as-paper

The FRIA gets written, filed, never read, never updated. When the agent's use changes materially, the FRIA is stale; the next audit finds it. Remediation: FRIA updates are a governance-review trigger (intake form question 11); material use changes force a FRIA review.

The log-retention illusion

The team turns on Datadog's default 15-day retention and assumes it counts as "six months" because the platform also archives to S3. The S3 archive doesn't have the right fields. The cold archive doesn't reconstruct. Remediation: quarterly sampled reconstruction test, with documented results in the QBR artifact.

The certification-or-nothing fallacy

The team decides not to pursue ISO 42001 certification, then concludes mapping to the standard is wasted effort. The standard is the spine even without certification. Remediation: map anyway; the cost is low and the upside is significant for procurement conversations.

Key Takeaways

• Translate EU AI Act Article 26, NIST AI 600-1, and ISO/IEC 42001 into ONE internal control set with framework cross-references — not three separate compliance projects.
• Annex III high-risk categories most relevant to enterprise agent programs in 2026: employment / worker management, access to essential services / creditworthiness, education / vocational training. Most agents in a typical portfolio fall outside Annex III, but a handful will hit and the inventory must surface them.
• Article 26 deployer obligations include 12 specific items: instructions, oversight, data appropriateness, monitoring, incident reporting, log retention, worker information, DPIA, FRIA (where required), affected-persons information, right-to-explanation cooperation, plus substantial-modification awareness.
• FRIA template (6-12 pages) covers process description, period and frequency, affected categories, specific risks, oversight implementation, materialization measures. Required pre-deployment for certain deployers; valuable evidence even when not strictly required.
• Six-month log retention discipline: tiered architecture (hot 7-30 days in observability platform; warm 30-180 days in S3+Athena; cold 180+ in Glacier), full input/output/tool/identity/metric capture, GDPR Article 17 erasure handling, quarterly sampled reconstruction test.
• NIST AI 600-1 maps the four functions (GOVERN, MAP, MEASURE, MANAGE) to evidence the team is already producing: governance artifacts (GOVERN), intake forms and FRIAs (MAP), eval scores and SLOs (MEASURE), action items and postmortems (MANAGE).
• ISO/IEC 42001 clauses 8.1-8.4 cover the operational layer where agents live; Annex A controls map directly to internal controls. Even without certification, the standard is the spine of the control set.
• The internal control set is ~25 controls with four cross-reference columns (description, evidence, Article 26, NIST AI 600-1, ISO/IEC 42001). One control satisfies three frameworks; the auditor asks once and the evidence resolves once.
• The 12-week execution plan to August 2, 2026: inventory + tiering (1-2), FRIA template (3-4), FRIAs for Annex III agents (5-6), six-month retention (7-8), control set documentation (9-10), audit-readiness rehearsal (11-12).
• Anti-patterns: three-framework treadmill, Annex III blind spot, FRIA-as-paper, log-retention illusion, certification-or-nothing fallacy. Each has a specific remediation that does not require new tools, only discipline.