The EU AI Act is the first comprehensive regulatory framework for artificial intelligence in any major jurisdiction. For European enterprises adopting agentic workflows, it is also the first time deploying an AI system carries explicit legal obligations beyond general data-protection rules. This piece is a practical orientation: not legal advice, but a frame for how to think about it.
What the AI Act actually requires
The Act takes a risk-tiered approach. Most agentic workflows in enterprise use will fall into the limited-risk or high-risk tiers depending on the use case.
Limited-risk systems (agents that interact with people, generate content, or assist decisions) must satisfy transparency obligations. Users must know they are interacting with an AI; AI-generated content must be marked as such; emotion-recognition and biometric-categorisation systems require explicit notice.
High-risk systems (agents used in employment screening, credit scoring, critical infrastructure, education access, law enforcement, justice administration, migration, or essential public services) face substantive obligations: risk-management systems, data-governance requirements, technical documentation, human oversight, accuracy and robustness standards, and post-market monitoring.
The general-purpose AI models (GPAI) that underpin agentic workflows have their own obligations: model-card-style transparency, training-data summaries, and copyright-respecting data sourcing.
What this means in practice
If your agentic workflow makes or assists employment, lending, or eligibility decisions, you are in the high-risk tier and need a documented risk-management system before deploying. If your workflow generates customer-facing content, you need transparency disclosures. If your workflow assists internal operations and humans take the consequential action, you have transparency obligations but not the high-risk overhead.
Three practical considerations matter most for enterprise deployment:
Documentation comes from the runtime, not from compliance theatre. The Act asks you to demonstrate that the system behaves as intended. A platform whose runtime emits structured audit trails, eval results, and policy-enforcement logs gives you that demonstration as a byproduct of operating. A platform that does not requires you to assemble the documentation by hand.
Human oversight is an architecture property. The Act requires that humans can intervene, override, and stop high-risk AI systems. That is a property of the workflow's design: what the agent is permitted to do autonomously, what gates a human approval, what an emergency stop looks like. It cannot be retrofitted; it is designed in.
Data governance is non-negotiable. Training-data lineage, prompt-policy enforcement, output-redaction rules, retention windows: these are platform features, not optional add-ons. A platform that cannot enforce policy as data is one you have to wrap in extra controls to make compliant.
What Myrmid does about it
Enterprise Mesh emits the audit trail by default: every agent invocation, every tool call, every model token is observable and exportable to your SIEM. Policy is data, not code: workspace-scoped allowlists, jurisdiction pins, retention windows, and redaction rules are configured without redeploy. Human oversight is a workflow primitive in Workflow Builder: you specify which agent actions auto-execute and which require human approval, per workflow.
We are not your AI Act compliance officer. But the platform is built so the Act's documentation, oversight, and governance requirements fall out of operating it, not into a separate workstream you have to assemble by hand.
Read the Enterprise Mesh capability surface for the substrate-level guarantees, and the manifesto for the broader commitments these obligations sit inside.