L'essentiel en bref
Production-grade AI agents for Brussels institutions, federations, NGOs and Belgian FinTech.
EU AI Act compliance built in: audit trails (Art.11), incident reporting (Art.17), third-party risk (Art.28).
Key use cases: EUR-Lex monitoring, position paper drafting, KYC/AML automation, claims triage.
Trilingual (FR/EN/NL) agent interfaces and outputs as standard.
All infrastructure on OVH EU — no US cloud for production data.
AI Agents in Brussels — EU AI Act Compliant by Design
Nehos builds AI agents for Brussels' regulatory environment: public affairs monitoring, legislative intelligence, FinTech DORA compliance. Full EU AI Act Article 11/71/72 documentation.
Adapté à toute taille de structure
Questions fréquentes
#AI Agents in Brussels — EU AI Act Compliant by Design
Deploy AI agents in Brussels under the EU AI Act duties that actually bite — technical documentation under Article 11, registration under Article 71, post-market monitoring under Article 72: regulatory monitoring, public affairs automation and compliance workflows for Belgian financial institutions, sector federations and EU bodies.
#The Brussels workload agents are genuinely good at
Follow a single ordinary legislative procedure and count the surfaces you have to watch: the Commission proposal and its impact assessment, the procedure file in the Parliament's Legislative Observatory, committee draft reports, amendment tables that routinely run to several hundred entries, rapporteur and shadow rapporteur positions, Council working party progress reports in the public register, the presidency compromise texts that circulate, national parliament reasoned opinions, and eventually the Official Journal text with its transposition deadline. Multiply by the twenty or thirty files a mid-sized federation cares about, and the job stops being analysis and becomes triage. That triage is repetitive, rule-governed and high-volume — the conditions under which agents earn their place.
The second workload is linguistic. A Brussels organisation receives inbound in French, Dutch and English on the same day, often from people who will judge the professionalism of the reply by whether it comes back in their own language and in the right register. Belgian administrative Dutch is not interchangeable with the Dutch used in the Netherlands; a member federation in Flanders notices immediately when a reply reads as if it were drafted elsewhere. Routing, classification and drafting support across three languages is a well-bounded agent task — and one where a naive translate-then-answer pipeline is visibly worse than a system designed multilingual from the start.
The third is the reporting cadence in Belgian financial services. Since DORA became applicable on 17 January 2025, supervised entities have had to classify ICT-related incidents against defined criteria, produce initial, intermediate and final notifications within set windows, and maintain a register of information on ICT third-party arrangements. None of that is judgement-free, but a large share of it is assembling facts that already exist in ticketing systems, contracts and asset inventories into a prescribed structure under time pressure. Agents shorten that assembly step dramatically while leaving the judgement — and the signature — with a named human.
#Agent patterns we deploy in Brussels
The sourced-monitoring pattern. An agent watches a defined set of official sources, detects what changed, and produces a briefing where every assertion carries a reference back to the originating document and its identifier. The engineering difficulty is not the summary; it is the diff. Analysts do not want to re-read a fresh summary of a file they already know — they want to see that a specific paragraph was reworded between two committee readings, and by whom. We also draw a hard line on what cannot be tracked: consolidated trilogue texts are not published, so any system that appears to report on them is inferring. We say so in the interface rather than letting an agent imply access it does not have.
The intake-and-route pattern. Inbound messages, member questions and consultation responses arrive in three languages and land in the wrong inbox. The agent classifies by topic and urgency, identifies the file it relates to, drafts a first reply in the sender's language, and routes to the owner. Nothing leaves the organisation without a human pressing send — a constraint we build in rather than offer as an option.
The dossier-assembly pattern. For a DORA incident notification, an AI Act technical file, or a consultation response, the agent gathers the evidence that already exists across your systems, maps it to the required structure, flags what is missing, and hands a draft to the person who is accountable. The value is measured in the elimination of the search phase, not in the writing.
The compliance-inventory pattern. An agent maintains the register of AI systems in use across the organisation, tracks which are provided by third parties, which obligations attach as provider or deployer, and which deadlines are approaching. This is unglamorous and it is the single most requested capability from clients who realised their AI inventory was a spreadsheet somebody stopped updating.
The screening-support pattern for Belgian fintech. In onboarding and monitoring workflows, agents structure documents, reconcile entity data against the Belgian UBO register and sanctions and PEP sources, assemble a case file and present it with the evidence attached. The classification recommendation is a recommendation. Where a decision affects a natural person's access to a service, a qualified human decides — both because Article 14 of the AI Act requires oversight that can actually override, and because GDPR Article 22 constrains decisions taken solely by automated means.
The internal-knowledge pattern. Agents that answer staff questions from the organisation's own corpus — procedures, past positions, board decisions, prior consultation responses — inheriting the questioner's access rights so that confidentiality boundaries are enforced by the system rather than by convention.
#What makes an agent auditable
An agent is a model plus tools plus a loop. In a supervised environment, the loop is where the risk concentrates: each additional autonomous step multiplies the ways an outcome can drift from intent. Our default posture is to bound it aggressively. Tool interfaces are typed and validated, so an agent cannot pass a malformed argument and receive a plausible-looking failure. Step budgets are explicit. Anything that touches the outside world — sending, filing, publishing, writing to a system of record — sits behind an approval checkpoint by design.
Every run is recorded as a replayable trace: the inputs, the retrieved documents with their identifiers, the tool calls with their arguments and returns, the model version, the prompt version, and the final output. Article 12 of the AI Act expects automatic recording of events across a system's lifetime, and Article 72 expects post-market monitoring that draws on real operational data. Both are far easier to satisfy when tracing was designed in than when it is reconstructed from application logs that were never intended for the purpose. Prompts and configurations are versioned in the same repository as the code and move through the same review, because "someone changed the prompt" is otherwise an untraceable incident.
Two failure modes deserve specific attention in this sector. The first is silent retrieval failure: the search returns nothing useful and the model answers anyway, fluently and wrongly. We handle this with explicit abstention — an agent that cannot ground a claim says so, and an unanswered question is a better outcome than a confident invention in a briefing that reaches a Commission official. The second is prompt injection through ingested content. An agent that reads public consultation submissions, third-party position papers or inbound email is reading text that anyone can author, including text written to manipulate it. Treating retrieved content as untrusted data rather than instructions is a design decision, and it is one that monitoring agents in this city genuinely need.
Model choice is an engineering decision, not a branding one. Classification, routing and extraction — the majority of the work inside most agents — are handled well by smaller open-weight models that can run on European infrastructure, at a fraction of the latency and cost of frontier models, and with the added benefit that nothing leaves the perimeter. We reserve the larger models for the steps that genuinely need reasoning over long, messy context, and we route between them explicitly. Clients are often surprised that the answer to "which model should we use" is "four of them, for different steps".
Integration is where agent projects quietly stall. A monitoring agent that produces excellent briefings nobody reads has failed. In practice that means delivering into Teams or Slack where the team already works, writing into the association management system or CRM that holds member records, reading the SharePoint or document management estate where twenty years of institutional memory actually lives, and connecting to the ticketing system that already governs incident workflow. We treat those connections as part of the scope from the first sprint, not as a phase two that never arrives.
#What we will not let an agent do
We do not build agents that send external communications autonomously. In an environment where a misattributed position on a live file can become a story in the trade press within hours, the marginal time saved by removing human approval is not worth the exposure.
We do not build agents that decide individual eligibility on their own — for credit, for insurance pricing, for membership, for access to a service. That is Annex III territory under the AI Act, and it deserves the full high-risk treatment rather than a quiet deployment behind an internal tool.
We do not build agents whose output is submitted to a supervisor without a named person reviewing it. A regulatory filing carries a signature for a reason, and no automation should blur who stands behind the content.
And we push back on agents built where a deterministic rule would do the job better. Plenty of the workflows presented to us as agent candidates are decision tables wearing a costume. A rules engine that is right every time beats a model that is right most of the time, costs less to run, and is trivially explainable to an auditor.
#How a deployment runs
We begin with process observation rather than a requirements document — sitting with the people doing the work, watching where time actually goes. The candidate process is then specified as a set of concrete tasks with acceptance criteria, and we build the evaluation set before we build the agent: real inputs, correct outputs, including the awkward cases. Without it, quality is anecdote.
The first working version handles a narrow slice end to end with the human checkpoints in place, running in parallel with the existing process so the two can be compared on the same inputs. Autonomy is then widened only where the trace record supports it. A standard scope reaches production inside the eight-to-twelve-week window, with the narrow slice live well before the end of it. Post-launch monitoring tracks task success rate, tool error rate, citation accuracy, escalation rate and unit cost per completed task — and those numbers go to the steering committee alongside the business KPI, because an agent that is cheap and wrong is not a saving.
#The signals that tell you it is working
Our agent deployments deliver an average 55% productivity gain on high-value tasks: the hours recovered from monitoring, sorting and data assembly move to analysis and to member or client relationships. Observed availability is 99.5%, with production in 8 to 12 weeks for a standard scope and, across our AI portfolio, a 40% reduction in operating costs on the processes we automate. The qualitative signal matters as much: when analysts stop maintaining their private parallel tracking spreadsheet, the system has been accepted. When they keep it, something is wrong and we want to know what.
#Why Nehos in Brussels
- On the ground — Securex building, Cours Saint Michel 30A, 1040 Brussels, minutes from the European quarter. Process observation and reviews happen in your offices.
- Traceability as a default, not an option — every agent decision logged, versioned and replayable, which is the minimum a supervised institution can accept.
- 47 specialists in AI, data and cloud, with 200+ projects taken into production since 2014 — including agent deployments running under supervision.
- Trilingual by construction — French, English and Dutch handled in the pipeline and in the evaluation set, with Belgian usage respected.
- European sovereign hosting — production data stays in the EU under GDPR, with a processing agreement and an EU-only sub-processor list.
- Free audit — 30 minutes to identify which process is worth automating first, and which one is not.
#Complementary services in Brussels
- our national AI agent development service
- the Nehos Brussels office
- our AI agency practice in Brussels
- GEO/AEO citability for public affairs teams
- Next.js platforms for federations and think tanks
- our client success stories
- our blog on EU regulatory compliance
Related areas we cover: EU AI Act agents Brussels, regulatory monitoring AI Brussels, public affairs AI automation Brussels, DORA AI agents Belgium, agentic AI EU institutions Brussels.
The FAQ below answers the questions our Brussels clients ask most often on this topic.
Get in touch with our Brussels team for an initial conversation with no strings attached: we assess the potential of your project together and give you a costed estimate of the expected ROI.