Designing for the EU AI Act
Transparency, documentation, and explainability in regulated environments. How we approach these as design inputs from the start, written as a perspective rather than a claim of certification.
As a European AI company, we read regulation less as a list of boxes to tick and more as a description of what users were always owed: to know when they are dealing with a machine, to understand why it did what it did, and to see how it was built. Those are good design goals on their own, independent of any law.
This note is about how we approach three of those ideas: transparency, documentation, and explainability. It is a perspective on our design choices. It is not a claim of certification, conformity, or compliance with any specific regulation.
This article describes design intent and working principles. It does not assert that any product is certified, audited, or formally compliant with the EU AI Act or any other framework. Where formal status matters, it is documented separately and not implied here.
Three ideas we design toward
Transparency
People should be able to tell that they are interacting with an AI system, and to understand, in plain terms, what it is for and what it is not.
Documentation
The choices behind a system, what it does, its limits, how it was evaluated, should be written down as it is built, not reconstructed afterwards.
Explainability
Where a system shapes a decision, there should be a path to understanding why, in language a person can follow without a manual.
Built in from the start
The reason we treat these as design inputs is practical. Each of them is far cheaper to build in early than to add at the end, and some of them cannot be added at the end at all. Documentation written during the work is honest. Documentation reconstructed after launch is a guess.
Concept
Decide what is in scope
Name the purpose and the limits early. A system that knows what it is not for is easier to be transparent about later.
Design
Leave room to explain
Choices that affect a person are made so they can be described afterwards, rather than buried where no explanation can reach them.
Build
Document as you go
What the system does, how it was tested, and where it is weak is recorded while it is fresh, not assembled from memory before a deadline.
Review
Check against intent
Before anything ships, the behaviour is read back against the purpose it was meant to serve, and the gaps are written down honestly.
What we treat seriously, and what we do not assert
Design inputs we take seriously
- Clear signalling that a system is AI, and what it is for
- Documentation produced while the work happens
- A path to explain decisions that affect a person
- Honest records of limits and known weaknesses
Claims we do not make here
- Any statement of certification or formal compliance
- That good design removes the need for legal review
- That a perspective substitutes for an audit
- That these principles are unique to us
Regulation tends to ask for things careful engineering should produce anyway: a clear account of what a system does, why it does it, and where it falls short. We try to build so those answers already exist.
The short version
We design toward transparency, documentation, and explainability because they make a system easier to trust and easier to improve. We describe that as intent, and we keep questions of formal status to the places where they belong.