The EU AI Act

Where Kaimei's explanations, logs and monitoring support the EU AI Act's requirements for high-risk AI systems, and what remains your responsibility.

Not legal advice This page maps Kaimei's features to the Act's requirements to help you plan. Using Kaimei does not make a system compliant, and this is not legal advice.

#Does it apply to you?

The AI Act, Regulation (EU) 2024/1689, places its heaviest obligations on high-risk AI systems. Annex III lists uses that are high-risk, including:

evaluating the creditworthiness of people or establishing their credit score, except to detect fraud;
risk assessment and pricing for life and health insurance;
recruitment, promotion, task allocation and monitoring of workers;
access to essential public services and benefits, education, and uses in law enforcement, migration and justice.

AI that is a safety component of products such as machinery or medical devices, listed in Annex I, is high-risk too. Obligations differ for providers, who develop a system or put it on the market, and deployers, who use it.

#When it applies

The Act entered into force on 1 August 2024. Prohibited practices were banned from 2 February 2025, and the rules for general-purpose AI models applied from 2 August 2025. As adopted, most obligations for high-risk systems apply from 2 August 2026, and from 2 August 2027 for products under Annex I.

In November 2025 the European Commission proposed postponing parts of the high-risk timetable. Check which dates apply to you now.

#Requirements and where Kaimei fits

For a high-risk system, this is how each requirement lines up with what Kaimei records and measures.

Requirement	What it asks, in short	How Kaimei helps	What stays with you
Risk management Article 9	A continuous process to identify, assess and reduce risks over the system's life.	Robustness and drift analyses and behaviour curves give measured evidence for the risk file.	The process, the risk decisions and their sign-off.
Data governance Article 10	Training, validation and test data that are relevant, representative and examined for possible bias.	Summaries of the reference data, and drift between that data and live traffic.	Kaimei does not audit training data or measure bias.
Technical documentation Article 11, Annex IV	A description of the system, its logic, its performance and how it is monitored.	Model structure, global importance, behaviour curves and learned rules, all exportable as JSON.	Writing and maintaining the documentation.
Record-keeping Articles 12, 19 and 26	Automatic logging of events over the system's life, with logs kept for at least six months.	Every prediction and explanation is logged with its time, model version, input and output, and can be queried through the API.	The retention schedule. Kaimei keeps records until you delete them.
Transparency to deployers Article 13	Enough information for deployers to interpret the output and use it appropriately.	An explanation for any prediction, with plain-English summaries for images and for every insight.	The instructions for use.
Human oversight Article 14	People who can understand the output, notice problems, and decide not to use or to override it.	Explanations, counterfactuals and alerts in the dashboard, for the people doing oversight.	Who oversees, their training and their authority.
Accuracy and robustness Article 15	Appropriate, declared accuracy, and resilience to errors and inconsistencies.	Robustness to input noise, drift, and comparison between model versions.	Accuracy testing on your own held-out data, and the security of your systems.
Post-market monitoring Article 72, providers	A plan to collect and review performance data once the system is in use.	Scheduled drift analyses on logged traffic, with medium and high findings raised as alerts.	The plan and the follow-up.
Right to explanation Article 86	People affected by a decision based on a high-risk system can ask for a clear and meaningful explanation of the AI's role and the main elements of the decision.	A stored explanation for each decision, retrievable by your decision id, to draw the answer from.	The explanation you give the person.

#A practical setup

Register each production model and every version, and upload the data it was validated on as its reference data.
Log every prediction with your decision id.
Explain each decision that affects a person, with KernelSHAP and a fixed seed, at the time or on request.
Run a full analysis at each release and a drift analysis on a schedule; route medium and high findings to the oversight team.
At each release, export the model's structure and insights into your technical documentation.
Set a retention period and delete records older than it.

#Does it apply to you?

#When it applies

#Requirements and where Kaimei fits

#Related EU rules

#A practical setup