AI Act Fines Reach 7% of Revenue: Time to Build Compliance Into the ML Pipeline

Fines for violating EU AI Act prohibitions reach €35 million or 7% of global annual turnover, and up to €15 million or 3% for other violations. Against that backdrop, KDnuggets has published a short but telling argument: a model can be both state-of-the-art and compliant, provided teams stop treating governance as the last barrier before release and build it into every stage of the ML pipeline. The original is a brief announcement with no metrics or case studies, so what follows is a look at how this idea works in practice.

Why the pre-release check breaks down

The typical scenario will be familiar to almost any team. Data science trains a model, picks metrics, and pushes it to staging. Then lawyers and risk managers get involved. It turns out the dataset has no documented provenance, the model's decisions are not logged, and one of the features correlates with a protected attribute. The result: weeks of rework or a frozen project.

For high-risk systems, the AI Act requires data governance, technical documentation, logging, human oversight, and a defined level of accuracy and robustness. Some of this cannot be recreated retroactively: data history and training conditions that were never recorded cannot be recovered. The application dates for individual provisions are under discussion and being adjusted, but the set of requirements is known in advance. There is no point in waiting for a final audit.

What to build in at each stage

A practical framework already exists. NIST AI RMF describes four functions: Govern, Map, Measure, Manage. ISO/IEC 42001, published in December 2023, sets requirements for an organizational AI management system. What remains is mapping them to pipeline stages:

• Data: lineage, license and legal basis for use, dataset version, a report on skews across groups.
• Training: recorded configs and seeds, experiment tracking, reproducible builds.
• Validation: quality metrics broken down by subgroup (for example, the difference in TPR and FPR between them), robustness tests, red-teaming for generative models.
• Deployment: a model card, a signed artifact, release sign-off from a named risk owner.
• Operations: drift monitoring, decision logs, alert thresholds, a rollback procedure, and a human in the loop where required.

The key technique is to turn the checklist into automation. If the repository has no current model card, or the bias report falls below a set threshold, the CI pipeline fails, just as it would with failing unit tests. Compliance becomes part of engineering discipline rather than a paper procedure.

Where the pitfalls are

Automation does not settle the substantive questions. Fairness metrics can conflict with one another: in the general case, several popular definitions cannot be satisfied at the same time if base rates differ across groups. Choosing a metric and a threshold is a decision not only for the technical team but also for the business side and legal, and it needs to be documented. There is also a cost: logging, tracking, and extra tests increase infrastructure spending and slow down the first iterations. The payoff comes later, when a finished product does not have to be redone.

Where to start

Start with an inventory: a list of all models in production and in development, each with an owner and a risk level. Pick one high-risk model and take it through the entire process. Introduce a single model card template. Add two or three automated gates to CI: presence of documentation, a bias report, a logging check. Decide who has the authority to stop a release. Once the process works for one model, scaling it to the rest will be easier than writing a policy from scratch for the whole portfolio at once.