"We comply with the AI Act" is not a document. A regulator asks for evidence: technical documentation, test results, logs. This is what you need to be able to show, and who is allowed to assess it.
A regulator doesn't ask for a promise, but for evidence: documents, logs and test results that demonstrate a system does what it claims to do, within the limits the law imposes. Without that evidence, compliance remains an intention, not a fact.
For most high-risk systems (Annex III), you carry out that assessment yourself, as the provider: an internal conformity assessment based on Annex VI. Only for a limited group, such as biometric identification systems, is an external, independent body (a "notified body") required. Assessing it yourself doesn't mean assessing it loosely: the file has to hold up under scrutiny.
Technical documentation is the centrepiece. It describes not just what the system does, but also how it was trained, validated and tested: which data, which performance figures, which known limitations. Without test results and validation, technical documentation remains a description of the system, not evidence that the system works reliably.
Three elements come up repeatedly in what a technical file needs to demonstrate:
Show how the model performs on representative datasets, including edge cases and under-represented groups.
Show how the system responds to faulty, unexpected or deliberately manipulated input.
Show that a user can override or stop the system, or disregard its output, whenever necessary.
The deadline for Annex III systems now stands at 2 December 2027, but you don't build the file in the final months. Technical documentation needs structured test results collected from the development phase onward, not reconstructed after the fact. Organisations that start classification and a minimal risk management system now won't have to write a file from scratch in 2027.
We help organisations build that test evidence: from test strategy and validation to robustness testing and documentation that supports a conformity assessment.
At a client testing a CV-screening system, internal compliance requested a mock audit six months before the planned go-live. Of the four mandatory components, one turned out to fall structurally short: logging didn't meet the retention period in Article 12, because logs were auto-purged after three months by a generic retention policy that had never been adjusted for this system.
Teams build logging for debugging, not for traceability. The result: logs that are technically informative but don't show which decision affected a user, at what point, based on what input.
An adjusted retention policy and a decision-specific log format solved the problem, but would have cost three months of extra lead time had it surfaced only at the actual assessment.
We review your documentation and test results and show you concretely where the gaps are.
Book a call