AI Compliance: ISO 42001, NIS2 & EU AI Act

EU AI Act: Deployer Duties

Article 26 of the EU AI Act imposes deployer duties including use in accordance with instructions, human oversight, input quality and log retention. These duties apply to Annex III high-risk systems from 2 December 2027 and to Annex I systems from 2 August 2028, following Regulation (EU) 2026/1744; transparency obligations under Article 50 already apply since August 2026. The platform generates evidence for each obligation from built-in controls rather than after-the-fact documentation. The mapping below is not a slide-deck promise; each control is produced by the same GitOps pipeline that deploys the platform.

Article 26 duty	Platform control	Evidence generated
Use in accordance with instructions	Agent profiles, system prompts and tool scopes versioned in Git	Git history of approved prompts and profiles
Human oversight	Slack Block Kit approvals for write and destructive actions	Approval ID, action hash, approver, timestamp, Slack signature
Input quality	Inline guardrails and DLP at the gateway	Guardrail hit logs and policy decision traces
Log retention	OpenTelemetry traces and Langfuse session records	Trace ID linking channel, agent, model, tool and policy decision

The "use in accordance with instructions" obligation is met because every agent profile, system prompt and tool scope is a versioned file. The approved version is the instruction set; any deviation requires a reviewed pull request. Human oversight is enforced at the action layer: reads within a user's scope run autonomously, while writes to production or business records pause at a LangGraph interrupt and request approval through a Slack Block Kit interactive message. The click is verified with Slack request signature, nonce replay protection and approver-to-IdP-role binding, then recorded as a hash-chained audit event. Input quality is not assumed; Presidio, Prompt Guard 2, NeMo Guardrails and the policy decision point evaluate every model and tool call. Log retention follows the published logging policy, with OpenTelemetry traces and Langfuse sessions providing the end-to-end traceability that Article 26 expects.

ISO/IEC 42001 & NIST AI RMF

ISO/IEC 42001 requires an AI management system: roles, risk assessment, controls and continuous monitoring. The NIST AI RMF frames the same work as Govern, Map, Measure and Manage. The reference architecture assigns clear ownership so responsibilities do not fall between teams. The AI Gateway and Tool Hub are owned by Platform / DevOps; policies and classification by Security; the agent runtime and memory by the AI platform team; individual agents by business or engineering owners; observability and SLOs by Platform / SRE; FinOps by Finance plus Platform; and GitOps repositories by Platform / DevOps with Security as code owner for policies and guardrails.

Risk assessment becomes operational through the four-tier classification model. Every tool, agent, virtual key and model deployment is mapped to Public, Internal, Confidential or Restricted. The policy decision point enforces the mapping at runtime, so a risk decision made during assessment is not ignored in production. Detection sources cover the full stack: the gateway watches for budget spikes, repeated guardrail hits, unusual key locations and tier violations; the agent runtime reports denied policy decisions, unusual tool sequences and write attempts without approval; the PDP logs deny-rate changes and bypass attempts; corporate controls including EDR, NGFW/ZTNA and CASB correlate with platform events to catch provider access that bypasses the gateway or unapproved local MCP servers; AI SaaS admin audit and identity-provider logs round out the picture. All logs are normalized and forwarded to the existing SIEM.

Continuous monitoring is backed by explicit service-level objectives. Gateway availability is targeted at 99.9% monthly. The gateway's added latency, excluding guardrail calls, is kept under p95 50 ms; including inline guardrails, under p95 800 ms for interactive use, tuned per customer. The tool hub targets 99.5% availability per critical tool. Agent task success is baselined in the pilot and then tracked per agent. These SLOs are not vanity metrics; failed canary rolls and SLO breaches trigger automatic rollback.

SLO	Target
Gateway availability	99.9% monthly
Gateway added latency, excluding guardrails	p95 under 50 ms
Gateway added latency, including inline guardrails	p95 under 800 ms for interactive use, tuned per customer
Tool hub availability per critical tool	99.5%
Agent task success rate	Baselined in pilot, then tracked per agent

GitOps as the Ultimate Audit Trail

The desired state of the whole platform lives in source control. Prompts, configurations, policies, tool definitions, agent profiles and deployments are versioned files; every change reaches production through a reviewed pull request and automation. Nobody changes production by hand: admin UIs are read-only in production and used only for inspection or non-production experiments.

Git holds infrastructure, platform deployments, gateway configuration, the tool hub registry, agents, prompts, policies, evaluation suites, dashboards, FinOps transforms and integration artifacts such as generated MDM profiles and ZTNA application definitions. It also holds documentation and runbooks. What Git does not hold are secret values (only references; values live in OpenBao / Vault and are synced by External Secrets Operator, or are SOPS-encrypted), issued virtual key values, and runtime data such as memory, traces, logs and cost records.

The change flow has six steps. First, a proposal arrives as a pull request by an engineer, by the agent lifecycle agent, or by a self-learning agent proposing a skill. Second, automated checks run: lint and schema validation, OPA policy unit tests, secret scanning, container and dependency scans, image signing, skill and MCP definition scans, and the agent evaluation suite with regression thresholds. Third, human code owners review by area: Security for policies and guardrails, system owners for tool scopes, agent owners for prompts. Fourth, the change is merged and Argo CD applies it through development, staging and production. Fifth, verification runs canary rollouts, smoke tests and SLO watching. Sixth, automatic rollback triggers on failed checks or SLO breach; manual rollback is a git revert.

Drift control keeps the running state honest. Argo CD self-heal reverts manual changes and raises drift alerts. Git history is the audit trail for every platform change and is forwarded to the SIEM. Renovate opens pull requests for platform components, container images, MCP servers and model price tables, so dependencies stay fresh through the same gates. Environments are reproducible from Git plus backups of stateful stores; restore is tested as part of disaster recovery exercises.

Step	What happens	Automated
1. Propose	Pull request by engineer, lifecycle agent or self-learning skill proposal	Partly
2. Check	Lint, schema validation, policy tests, secret scanning, container scans, image signing, MCP/skill scans, evaluation suite with regression thresholds	Yes
3. Review	Code owners approve by area: security, system owners, agent owners	No
4. Merge and sync	Argo CD applies change to dev, then staging and production through the same pipeline	Yes
5. Verify	Canary rollout, smoke tests, SLO and quality metrics watched	Yes
6. Roll back	Automatic rollback on failed checks or SLO breach; manual rollback is a git revert	Yes

Privacy by Default & Employee Monitoring

GDPR and works-council consultation require a clear logging privacy policy. The default balances audit needs against employee privacy: metadata is always logged, but prompt content is off by default for human interactive use. Agents and automations need content logging for debugging and audit, so their content is on with retention per use case. Redaction of secrets and PII runs before storage in every case. Access to content is restricted to Security on incident for human interactive use, and to agent owners plus Security for agents; every access is logged.

Data	Human interactive use	Agents and automations
Metadata (user, model, tokens, cost, latency, tools, policy result)	Always	Always
Prompt and response content	Off by default; enabled per team on request, or captured only on policy violation	On, for debugging and audit
Retention of content	Short (for example 30 days)	Per use case (for example 90 days)
Access to content	Security on incident only, access logged	Agent owners and security
Redaction	Secrets and PII masked before storage	Secrets and PII masked before storage

The logging privacy policy is owned jointly by Security and HR / Legal, with consultation of employee representatives. Logs containing content inherit the highest tier of the session, so a trace that captured Confidential content is handled as Confidential data. The policy is published to employees, not buried in an admin guide. This ownership and transparency are what make the logging default defensible under GDPR and works-council rules, rather than relying on a technical toggle alone.