August 2, 2026, marks a milestone in the journey of AI, as most obligations under the EU AI Act become enforceable across the EU, especially the safety and transparency rules for high-risk systems. For companies and creators, ignoring these rules now means facing potential fines that scale into millions of Euros.
The last comparable EU-wide digital regulation of this scale was GDPR. During the 2016–2018 rollout, as a developer, the only information I received about GDPR came top-down from an architect strictly limited to the specific feature I was coding.
In 2026, I wanted to build a solution that makes the Act accessible to everyone, whether CEO or intern. A pocket guide for anyone building or deploying AI systems within the EU ecosystem.
The idea is straightforward: an AI assistant with direct access to official legal texts from the EU and other major nations passing AI governance laws. The system analyses a user’s specific situation and provides tailored, practical feedback.
The tool does not provide legal counsel; it is another source of perspective.
I wanted a code-first, open-source approach that gave me full control over data processing and the flexibility to add more domain-specific legal texts later. I initially looked at low-code platforms like RAGFlow and Dify to handle this, but their free tiers were limited, and the interfaces didn’t feel very intuitive. I eventually settled on using Qdrant.
Choosing the right AI framework and agent design was important. I wanted a human-centric approach, akin to how this would play out if actual human experts were handling it. CrewAI felt like a natural fit with its role-based digital personas. I ruled out a single-agent setup because a single AI lacks the necessary guardrails to reliably interpret dense legal text. While CrewAI has its own built-in safety features, I wanted a more custom workflow. A decoupled two-agent team sufficed, saving on query tokens.
[ Raw User Input ]
│
▼
┌───────────────────────┐
│ AGENT 1 │
│ Intake & Triage │◄───────────────────────────┐
└───────────┬───────────┘ │
│ (Evaluates 3 Pillars) │
▼ │ [Loop Path]
< Sufficiently > ───( No: Max Cap < 2? )───► [Yes]
< Narrow? >
│
│ [Yes]
▼
[ Structured Context Payload ]
├─ Active Jurisdictions
├─ Extracted Pillars
├─ Generated Subqueries
└─ Deductive Assumptions
│
▼
┌───────────────────────┐
│ AGENT 2 │
│ Compliance Enforcer │
└───────────┬───────────┘
│ (Executes Restricted RAG)
│ (Audits & Discards Assumptions)
▼
[ Final Verified Output ]
The first agent acts as an intake specialist, analysing the user’s query to extract the three core pillars (Role, Jurisdiction, and Purpose) and generate targeted search queries. These parameters are then passed to a second agent, which queries the Qdrant database to audit initial assumptions directly against the official laws.
The structure was straightforward to implement, but it also surfaced a set of challenges that were not architectural, but behavioural in nature. These issues only became apparent once the system began interacting with a range of real-world inputs.
First, there is the compliance schema itself. Trying to accurately gauge a user’s technical background and expertise from 1–2 queries is more art than science, making it difficult to consistently tailor the complexity of the output.
Second, there is the hurdle of legal interpretation. A lawyer’s skill lies in translating reality into rigid, formal systems while working inside strict interpretive boundaries. For example, the system tended to be overly conservative in labelling use cases as “High-risk” or “Prohibited” when vulnerable groups or plausible harm were mentioned. These edge cases highlighted how much domain knowledge and human judgment still sit inside statutory interpretation.
Third, there is system-level behavioural drift. Relying on agents that “roleplay” a conversation introduced non-trivial prompt drift and additional conversational overhead, which also had a measurable impact on response latency.
The input ambiguity, legal interpretation bias and performance constraints showed up at different stages of the workflow but influenced each other during execution. It’s a start, and clearly highlights the next steps.
My next goal is to migrate the project to a cleaner, more direct framework, such as LangGraph, to keep the system fast while continuing to refine how legal reasoning is structured. I also plan to integrate a more formal evaluation layer, most likely using Ragas.
You can follow my code here.
FYI: The European Commission is set up here with more resources if you're interested.