What the regulations actually ask of an agent stack, and which layer has to answer
Parts 1 and 2 drew the stack. Before deciding how to govern it, it is worth reading what the law asks, in the text, not in the vendor slide. Five sources matter for a European or Swiss deployment: the EU AI Act as amended in July 2026, NIS2, ISO/IEC 42001, the Swiss Data Protection Act, and FINMA's guidance for financial institutions. Most of what they ask is about records and control, not about the model.
HokonokenSeptember 2026Reading time: 9 minNot legal advice · Views are my own, not my employer's
Three things to take away
The obligations are mostly about evidence and control. Logs kept for at least six months, a documented risk process, a person who can override or stop the system, an inventory with a risk class, incidents reported on a clock. The model's quality matters, but the texts spend more words on what surrounds it.
The dates moved this summer, but not all of them. Regulation (EU) 2026/1744 pushed the high-risk obligations to 2 December 2027 (Annex III) and 2 August 2028 (Annex I). The transparency duties of Article 50 did not move: since 2 August 2026, people must be told they are talking to an AI.
Two demands have no box in the stack from parts 1 and 2. A surface where the human oversight of Article 14 actually happens, and a way to enforce "intended use only" (ISO 42001 A.9.4) at the level of a task. Part 4 is about that.
The five texts in one page
Each entry gives the article, the wording that matters, and the date it applies. Quotations are from the official English texts; where a text has no English version, the Swiss FADP for instance, the quotation is from the Federal Council's unofficial translation on Fedlex.
EU AI Act, Regulation 2024/1689, amended by 2026/1744
High-risk: 2 Dec 2027 (Annex III) · 2 Aug 2028 (Annex I) · Art. 50: since 2 Aug 2026
Art. 12: high-risk systems "shall technically allow for the automatic recording of events (logs) over the lifetime of the system", for traceability and post-market monitoring.
Art. 26(6): deployers keep those logs "for a period appropriate to the intended purpose… of at least six months".
Art. 14(4): the overseer can "decide, in any particular situation, not to use" the system, "disregard, override or reverse the output", and "intervene in the operation or interrupt the system through a 'stop' button or a similar procedure".
Art. 26(2): oversight is assigned "to natural persons who have the necessary competence, training and authority".
Art. 9: a risk management system "established, implemented, documented and maintained", "a continuous iterative process" over the lifecycle, with testing "against prior defined metrics".
Art. 15: "resilient against attempts by unauthorised third parties to alter their use, outputs or performance"; the text names data poisoning, model poisoning, adversarial examples, model evasion and confidentiality attacks.
Art. 11: technical documentation "drawn up before that system is placed on the market" and "kept up-to date".
Art. 72, 73: a post-market monitoring plan; serious incidents reported within 15 days, 2 days for critical infrastructure, 10 days when a death is involved.
Art. 50: providers design systems so that people are told they interact with an AI "at the latest at the time of the first interaction"; synthetic content is "marked in a machine-readable format"; deployers disclose deepfakes and AI-generated public-interest text.
NIS2, Directive 2022/2555
Transposed by 17 Oct 2024 · applies to essential and important entities
Art. 21(2): "appropriate and proportionate technical, operational and organisational measures", including "incident handling", "supply chain security", "security in network and information systems acquisition, development and maintenance, including vulnerability handling", "access control policies and asset management", "the use of cryptography", "multi-factor authentication".
Art. 23(4): "within 24 hours… an early warning", "within 72 hours… an incident notification", a final report "not later than one month".
Art. 20: management bodies approve the measures and are accountable for them.
An agent stack that calls tools against production systems will usually fall within the directive's broad definition of a network and information system; what NIS2 binds, though, is the operating entity, if it is essential or important, not the agent itself. Its supply chain includes the model weights, the MCP servers and every container image.
ISO/IEC 42001:2023
Certifiable management system · reference controls in Annex A
A.6.2.8 AI system recording of event logs; A.6.2.6 operation and monitoring; A.6.2.7 technical documentation.
A.9.4 intended use of the AI system: the system is not used outside its documented purpose.
A.5 impact assessment, documented; A.8.4 communication of incidents; A.10.2, A.10.3 responsibilities allocated with suppliers.
ISO 42001 does not bind anyone by itself. It is what an auditor will use as a checklist, and what the AI Act's harmonised standards are expected to lean on. Control titles above are paraphrased for readability; the standard's text is not reproduced.
Swiss Federal Act on Data Protection, FADP, in force since 1 Sept 2023
Applies to any processing of personal data in Switzerland · AI bill expected for consultation by end 2026
Art. 21: for a decision "based exclusively on automated processing" with legal or considerable adverse effect, the controller informs the person, who "may request that the automated individual decision be reviewed by a natural person".
Art. 22: a data protection impact assessment "if processing is likely to result in a high risk", carried out "beforehand".
Art. 7: protection by design "from the planning stage"; Art. 8: "a level of data security appropriate to the risk"; Art. 12: a record of processing activities; Art. 24: breaches notified to the FDPIC "as quickly as possible".
Switzerland has no AI act. On 12 February 2025 the Federal Council chose a sector-by-sector approach and announced that Switzerland would ratify the Council of Europe AI Convention; Switzerland signed the Convention on 27 March 2025, and the implementing bill is expected for consultation by the end of 2026.
§2.2: "a centrally managed inventory with a risk classification and resulting measures".
§2.4: tests "for accuracy, robustness and stability and, if necessary, bias", with "performance indicators defined in advance"; fallback mechanisms.
§2.5: documentation covering "purpose of the application, data selection and preparation, model selection, performance measures, assumptions, limitations, testing and controls as well as fallback solutions".
§2.6: results that can be "understood, explained or reproduced" where decisions must be justified.
§2.7: an independent review by qualified personnel, distinct from development.
The guidance is explicit that "to date, there is no AI-specific legislation in Switzerland" and that existing, technology-neutral requirements already cover the risk.
Which layer has to answer
The rows are the demands above; the columns are the layers of the stack from parts 1 and 2. A filled cell is where the primary answer lives, a light cell is a layer that contributes. Two things stand out: observability and logs answer more rows than any other layer, and the human-oversight row has no strong answer anywhere.
Reading the matrix
Logs answer the most rows, and the stack already produces them. Article 12 logs, the six-month retention of Article 26(6), NIS2's incident timelines, ISO 42001's event logs, FINMA's monitoring: all of them start from the same raw material. OpenTelemetry traces from the agent, the MCP gateway's record of every tool call with caller, tool and server, OpenShell's OCSF security events, DCGM's GPU metrics. What the stack does not do by itself is keep them for six months in a form an auditor can read, and tie a tool call to the person who was accountable for it. That is a retention and correlation job, and it is where most first audits fail.
Human oversight is a demand without a box. Article 14 asks for a person who can override an output or interrupt the system through a stop button. Article 26(2) asks that this person have competence and authority. In the stack, the stop button exists at the infrastructure level: revoke the agent's identity at Keycloak or SPIRE, remove the tool from the MCP gateway's allowlist, scale the pod to zero. None of that is a surface a business user or a compliance officer would recognise as "a stop button". Red Hat's own blueprint says it: human approval workflows still need product-level patterns. Part 4 looks at what Microsoft's Agent Governance Toolkit brings to exactly this row.
Intended use is enforced by whom? ISO 42001 A.9.4 and the FADP's "purpose of processing" both assume the system is used only for what it was documented for. Identity says who the agent is; the MCP gateway says which tools it may call. Neither says what the agent is supposed to be doing right now, for which task. An agent allowed to read the CRM and write to the ERP is within its permissions whether it is reconciling an invoice or doing something nobody asked for. This is the second row where the stack has no strong cell.
The inventory is the easy win. FINMA §2.2 and ISO 42001 both start with an inventory carrying a risk class. The model registry, the MCP catalog, the agent definitions in Git, the signed images: the stack already has the four lists. Joining them into one inventory with a risk class per agent is mostly discipline, and it is the first thing a supervisor asks for.
What changed in July 2026, and what did not
Regulation (EU) 2026/1744, the "Digital Omnibus on AI", was published on 24 July 2026 and entered into force on 27 July. It moves the application date of the high-risk obligations to 2 December 2027 for Annex III systems and 2 August 2028 for systems embedded in regulated products, and narrows the definition of a safety component. It does not touch the content of Articles 9 to 15 or Article 26, and it does not move Article 50: since 2 August 2026, providers must design AI systems that interact with people so that those people are told they are dealing with an AI, and deployers carry their own disclosure duties for synthetic content, with a four-month transition to 2 December 2026 for synthetic-media systems already on the market. Sixteen months more to build the evidence chain; no more time on transparency.
What this means for the stack of parts 1 and 2. Nothing in the five texts requires a specific product. They require that logs exist and are kept, that a person can stop the system and be shown to have had the authority to, that the system is only used for its purpose, that there is an inventory, and that incidents are reported on a clock. The open-source stack produces the raw material for all of it. The two rows it does not answer, oversight and intended use, are where the next part goes.
Next in the series
Part 4Action governance with Microsoft's Agent Governance Toolkit: how the oversight and intended-use rows get an answer, and where it plugs into this stack.
Part 5Observability: how it is proven. What OpenTelemetry, OCSF and MLflow record, and what they cannot tell you.
Part 6Rolling out a model blue/green: how the stack changes without breaking what parts 3 to 5 established.
This article is an engineer's reading of public legal texts, checked against the official versions on the dates given below. It is not legal advice. For a real deployment, read the texts with counsel and with your supervisor's guidance for your sector.
Read, not run. Everything in this series comes from reading public code and documents at a stated date, not from running them in production. Treat it as a map to test, not a result to trust: these projects move monthly, their bugs move with them, and a component marked preview or alpha here may be stable, or gone, by the time you read this. Test it on your own cluster. When something does not match, file the issue in the project's tracker and send the fix back: that is how open code improves, and it is the only way a map like this one stays true.
Independent work, not affiliated with any regulator, standards body or vendor named. Not legal advice. Views are my own and do not represent the position of my employer. Text and diagrams: CC BY 4.0; quoted code and documents stay under their own licences.