EU AI Act: The Engineering Decisions That Actually Matter Before You Ship
Most of the EU AI Act coverage focuses on fines and timelines. This post focuses on the decisions that affect your architecture, your data pipelines, and your team's sprint planning right now.
Start with risk classification
The Act uses four tiers: unacceptable, high, limited, and minimal. Where your system lands determines almost everything else. High-risk is not based on your intent — it is based on use case and domain. Hiring tools, credit scoring, medical device software, and critical infrastructure management all land in high-risk regardless of how the underlying model works.
If your model's output feeds into a decision in one of those domains, start from the assumption of high-risk and work backwards. Classification is a written decision, not an internal assumption. Assign an owner and get legal sign-off.
Technical documentation is an engineering problem
For high-risk systems the Act requires a technical file with specific contents:
- System description and intended purpose
- Design logic and key design choices
- Training, validation, and testing data and methodology
- Accuracy, robustness, and cybersecurity metrics
- Risk management documentation
- Post-market monitoring plan
The documentation gap most teams have is in dataset provenance and the risk management log. If you are running MLflow or Weights and Biases, your experiment logs are the raw material. The missing piece is usually a dataset registry that records source, collection date, labeling methodology, and known limitations.
Build the systems that generate this documentation from your existing tooling rather than writing it by hand. Hand-written compliance documents go stale immediately.
Human-in-the-loop is an architecture decision
The Act requires that humans can understand, monitor, and intervene in high-risk system outputs. That is a spec, not a policy. In practice:
- Automated actions with no review step are a compliance gap for high-risk classifications
- Outputs must be interpretable enough that a reviewer can understand why a decision was reached
- Every decision must be logged and traceable
Building HITL as an afterthought means building a review queue nobody uses. Design the intervention surface and the escalation thresholds into your model serving layer before the first production release.
Data governance additions on top of GDPR
The Act does not replace GDPR. For high-risk systems, training data must meet quality criteria — relevant, representative, free of significant errors. You need to be able to demonstrate this on request.
Key questions:
- Do you have a dataset registry?
- Can you produce it for a regulator or enterprise buyer?
- If training data included EU personal data, do you have a documented lawful basis?
- What is your process if a training dataset needs to be pulled after deployment?
The last question is the one most teams cannot answer cleanly. Retraining or retiring a model quickly when a data source is found to be problematic is an operational and architectural requirement, not just a legal one.
GPAI deployer obligations
If you are building on a foundation model rather than training your own, you cannot outsource compliance to your model provider. Their GPAI compliance covers their obligations. Your application-level risk classification, any fine-tuning you apply, and the transparency requirements of your deployed system are still yours.
Get the technical documentation from your model provider. If they cannot provide it, treat it as a vendor risk issue.
What to do in the next 30 days
- Produce a written risk classification for each AI system you are shipping or planning to ship this quarter. One page per system, legal sign-off required.
- Run a gap analysis against the high-risk technical file requirements for any system that lands in that tier.
- Make the HITL architecture call before the next sprint for any high-risk system, not as a later iteration.
These are small decisions in terms of time. They have large downstream effects on your architecture and your vendor contracts.
Originally published at decipheringlogic.com
Top comments (0)