BrainDup and the AI Act
Compliance as a property of the architecture, not an administrative layer on top
Since 2 August 2026, the question is no longer “are you compliant?”
It is: can you prove it? The European regulation on artificial intelligence does not accept good intentions, nor contractual undertakings signed by a supplier. It asks for traces, logs, documentation and demonstrable human oversight. Material evidence, produced by the system itself.
Two strategies answer that demand. The first stacks a compliance layer on top of a foreign cloud tool: written procedures, registers kept by hand, screenshots, contractual promises. It is expensive, it is fragile, and it leaves untouched a dependency on a supplier that Brussels is itself watching.
The second chooses an architecture where those obligations are not an added layer but properties of the system. A log that no application code can rewrite is worth more than a folder of procedures. That is the choice BrainDup made, and it can be checked line by line.
Article by article, the matching mechanism
Every requirement in the regulation becomes a precise technical mechanism in BrainDup, not a tick box in a spreadsheet.
| Article | What the regulation requires | The mechanism in BrainDup |
|---|---|---|
| Art. 10: data governance | Documented and governed provenance of datasets | A cryptographic fingerprint computed before any processing; every fragment, vector and graph node carries its provenance; duplicates are refused; distribution rights are closed by default |
| Art. 12: logging | Automatic recording of events | Seven append-only logs, locked by database triggers; the audit trail is written even when an operation partly fails |
| Art. 13: transparency | Clear information on how the system works | Citations assembled by the code from the catalogue, never written by the model; outside the corpus it declines to answer |
| Art. 14: human oversight | Oversight, intervention and interruption must be possible | Human arbitration on uncertain merges and disputed facts; causation is never inferred from co-occurrence; decisions stay auditable and reversible |
| Art. 15: accuracy and robustness | An appropriate level of accuracy, and its measurement | A fixed set of reference questions replayed on every change; 100 % correct citations, ≥ 80 % correct answers, zero invention; the evaluation is deterministic |
| Art. 50: disclosure | Make clear that the user is dealing with an AI | The interface states what it is: no imitation human adviser, no maintained ambiguity |
| Art. 53 onwards: general-purpose models | Obligations falling on model providers | Open models running on your own infrastructure; the absence of outbound dependencies is checked automatically on every code change |
| Art. 26: deployer obligations | Compliant use, oversight, retention of logs | Roles and permissions, a full log of the corpus lifecycle, a governance view, usage and cost statistics |
Four guarantees that do not depend on goodwill
Provenance is a constraint
A document's fingerprint is computed before text recognition and before extraction. Every derived object carries the identifier of its source and of its ingestion batch. “Where does this information come from?” calls for a query, not an investigation.
Logs that cannot be altered
Editing and deleting are forbidden at the database engine level, not by developer convention. A system that only writes its traces when everything goes well records nothing useful.
A false citation is impossible
The model writes the answer, never the reference. Author, number, date, page and address are assembled by the code from the document catalogue. Not because the model would be reliable, but because it has no hand in it.
Humans arbitrate where the machine hesitates
Uncertain cases go to an arbitration queue rather than being settled automatically, and every decision stays auditable and reversible. Oversight that leaves no trace is not oversight: it is a forgotten opinion.
The tipping point: dependency on the model provider
Providers of general-purpose models carry obligations of their own, supervised by the European Commission. If your system rests on them, part of your compliance depends on a third party you do not control, whose terms of use, versions and availability change without you.
BrainDup runs entirely on your own infrastructure, with open models. No data leaves the company, and that is not a sales line: a blocking check refuses any undeclared outbound dependency on every code change. It changes the nature of the problem. You no longer hand your documents to a third party and hope it stays compliant: there is no handover.
These guarantees are not features bolted on afterwards. They are architectural invariants, rules the code cannot break, verified automatically, and everything else is built on them.
What BrainDup does not do for you
No piece of software makes an organisation compliant, and anyone promising otherwise deserves suspicion. Compliance is assessed per system and per use, not per product.
Depending on what you do with it, your deployment may count as high risk: you will then run your own risk assessment, produce your technical documentation, appoint those accountable and complete the required formalities. BrainDup gives you the technical evidence; it does not write your file and does not take on your liability. Training your staff, required since February 2025, also remains yours; that is what our training is for.
A word on penalties, which are often quoted wrongly. The ceiling of 35 million euros or 7 % of worldwide turnover applies to prohibited practices. Failing the obligations for high-risk systems falls in another band, around 15 million euros or 3 %. That remains substantial, and the reasoning does not change: an architecture that produces its own evidence beats a file reconstructed after the fact.
Let us look at your situation
Thirty minutes to map how you use AI, work out what counts as high risk, and see what evidence your current architecture can produce.