EU AI Act Compliance
The compliance gap
The AI Act doesn't ban black-box AI.
It just makes it expensive to deploy
For high-risk AI systems, the AI Act introduces a defined set of obligations: technical documentation, logging, transparency to deployers, human oversight, data governance, accuracy and robustness. None of these are abstract — each translates into evidence a deployer has to produce on request.
The problem most enterprises face is not the regulation itself. It's the gap between standard generative AI architectures and what those architectures can actually evidence.
A model that generates citations alongside its output cannot reliably show where an answer came from. A retrieval pipeline without contracts cannot demonstrate consistent behaviour. A cloud-hosted stack with third-party model APIs introduces data governance questions that the AI Act explicitly asks about.
The compliance work doesn't disappear by choosing a different vendor. But the amount of compliance work — and how much of it your team has to invent from scratch — depends heavily on what the underlying technology was designed to support.
How our stack supports your compliance work
We don't sell compliance. We make compliance work less expensive.
Our architecture was designed around verifiability and traceability — properties that happen to map directly onto several of the AI Act's technical requirements. That doesn't make our system compliant on your behalf. It means the evidence the regulation expects is something our stack can produce, rather than something your team has to retrofit.
Concretely, this affects three areas:
01.
Documentation effort
Annex IV requires technical documentation that, for many AI deployments, has to be assembled manually after the fact. Our provenance layer produces a reconstructable trail by design — query, retrieval path, contracts applied, validation result, output. Documentation is a query against the log, not a project.
02.
Logging obligations
Article 12 requires automatic logging of events relevant to risk identification and post-market monitoring. Our stack logs every retrieval, every contract evaluation, and every output decision — at the granularity an audit can act on.
03.
Data governance posture
Article 10's expectations around data quality, bias, and traceability are easier to meet when training and inference happen on infrastructure you control. Our deployment model is on-premise-first, which removes a class of governance questions that cloud-hosted models raise by default.
What we provide is technology that lowers the cost of producing the evidence the AI Act expects.
The compliance assessment itself remains yours.
Mapping our capabilities
Which feature helps with which obligation.
Quality, relevance, and traceability of training and operational data
Automatic logging of events for traceability and post-market monitoring
Information sufficient to interpret output and use the system appropriately
Human ability to monitor, intervene, and override AI system operation
Consistent performance, resilience, and protection against manipulation
Documentation of system design, capabilities, limitations, and validation
On-premise deployment keeps data within your governance boundary; retrieval operates against your indexed sources, not external corpora
Full provenance trail per query: retrieval candidates, contracts applied, validation result, output
Source-traceable output; every claim mappable to the supporting passage; behaviour under uncertainty is explicit, not hidden
Flagged uncertainty and refusal behaviour surface low-confidence outputs to a reviewer rather than emitting them silently
Contract layer enforces type and semantic conditions on every output; on-premise deployment reduces external attack surface
Reconstructable trail and contract specifications produce documentation as an artifact of operation, not as a separate exercise
This mapping is a starting point, not a certification. Your specific deployment, use case, and risk classification determine which requirements apply and how they are evidenced.
What we do not claim
What this page is not
We do not claim our stack makes you compliant with the EU AI Act. Compliance is not a property of a software product — it is the outcome of how a deployer designs, deploys, monitors, and documents a system in a specific operational context.
What we claim is narrower and more useful:
Our architecture is designed around the same properties — traceability, logging, oversight — that the AI Act expects deployers to evidence.
Choosing a stack with these properties built in tends to reduce the compliance work your team has to do.
Our consulting team can help you map your specific deployment to the relevant articles and prepare the documentation Annex IV expects.
The legal and regulatory assessment remains with you and your advisors.
We provide the technology and the engineering perspective — not the legal opinion.
Consulting
Compliance is a process, not a feature
For most enterprises, the hard part of the AI Act is not understanding the text. It's translating the text into operational reality: which articles apply, how to scope the system, what evidence to produce, how to keep the documentation current as the deployment evolves.
Our consulting team works with you on the parts of that translation where the technology and the regulation intersect:
Risk classification of the planned deployment under the AI Act categories
Mapping of system capabilities and limitations to the relevant articles
Definition of logging, oversight, and reporting workflows that survive an audit
Preparation of the technical documentation expected under Annex IV
Joint review with your legal team to identify gaps before they become findings
We are engineers and researchers, not regulatory lawyers. The work we do sits between the architecture and the legal interpretation — and that is exactly where most enterprises lose time
Substance
Engineered for traceability, not for marketing
The capabilities this page describes are grounded in our published research and open-sourced infrastructure.
The AI Act simply happens to expect what our architecture was already designed for.
Trustworthy Agent Design
A practical whitepaper on designing trustworthy LLM agents with contract-based controls that validate inputs, outputs, and semantic requirements before agents act.
HyDRA - Knowledge Graph Construction
A whitepaper on HyDRA, a hybrid-driven reasoning architecture that uses collaborative agents, competency questions, and verifiable contracts to automate reliable knowledge graph construction.
SymbolicAI Framework (Open Source)
A developer-focused whitepaper on SymbolicAI, the open-source neurosymbolic framework for composing LLMs with Python-native symbolic abstractions, semantic primitives, and contract validation.
Full publication list available on request.