The AI Act Stopped Being Theoretical
For two years the EU AI Act lived in slide decks and think-pieces. In 2026 it lives in your product backlog. The regulation entered into force in August 2024 and applies in staged waves, and several of those waves have already broken over any company that puts AI in front of European users.
Since February 2025, the ban on prohibited AI practices has been enforceable. That includes social scoring, untargeted scraping of facial images to build recognition databases, emotion inference in workplaces and schools, and certain manipulative or exploitative systems. These are not high-risk-with-paperwork; they are simply illegal to place on the EU market, with penalties reaching up to 35 million euro or 7 percent of global annual turnover.
Since August 2025, obligations for general-purpose AI models apply. If you fine-tune or distribute a foundation model, you inherit transparency and documentation duties. If you merely consume one through an API, you still need to know what your provider has committed to, because their compliance becomes an input to yours.
The next big wave lands in August 2026, when the bulk of the high-risk system rules become applicable, with certain embedded-product cases extending into 2027. The practical message for 2026: the runway is short, and the parts that bite hardest apply to ordinary SaaS features, not just to exotic AI labs.
Risk Classification Is the First Real Decision
The Act is built on a risk pyramid, and your legal exposure is decided almost entirely by where your feature sits on it. Getting this classification right is the single most important engineering-adjacent decision you will make.
- ▸Unacceptable risk — banned outright. Manipulation, social scoring, most real-time biometric identification in public spaces, workplace emotion recognition. If a feature idea touches these, it does not get redesigned; it gets dropped.
- ▸High risk — permitted but heavily regulated. This covers AI used in recruitment and worker management, credit scoring and access to essential services, education and exam scoring, critical infrastructure, medical devices, and biometric categorisation. High-risk systems require a risk management system, data governance, technical documentation, logging, human oversight, accuracy and robustness testing, and a conformity assessment before market entry.
- ▸Limited risk — transparency obligations. Chatbots must tell users they are talking to a machine. AI-generated or manipulated content, including deepfakes and synthetic media, must be labelled in a machine-readable way. This is where a large share of everyday product features actually land.
- ▸Minimal risk — spam filters, recommendation tuning, most analytics. No specific obligations, though voluntary codes of conduct are encouraged.
The trap most teams fall into is assuming their feature is minimal risk because it feels harmless. An AI that ranks job applicants, screens loan eligibility, or moderates access to a public service is high-risk regardless of how simple the model is. Classification follows the use case and the stakes for the person affected, not the sophistication of the code.
What This Means for the Feature You Are Building Now
Concrete obligations you can act on in 2026, even before your full compliance programme exists:
- ▸Disclosure by default. Any conversational AI, generated image, generated voice, or synthetic text shown to a user needs a clear notice and, where content is synthetic, a machine-readable marker. Build this into the component, not the terms of service.
- ▸Traceability and logging. High-risk systems must keep automatic logs of operation. Even for lower tiers, log the model version, prompt, inputs, and outputs so you can reconstruct any decision an auditor or a complainant questions.
- ▸Human oversight that is real. A human-in-the-loop who cannot actually override the system does not satisfy the Act. Design an interface where a person can inspect, correct, and reverse an AI decision, and record when they do.
- ▸Data governance. For high-risk use, training and validation data must be relevant, representative, and checked for bias. You need documentation showing where data came from and how it was assessed.
- ▸GDPR still applies in full. The AI Act sits on top of GDPR, it does not replace it. Lawful basis, data minimisation, and the right to an explanation of automated decisions remain live obligations. For regulated finance, DORA adds ICT resilience duties, and NIS2 raises the security baseline for essential and important entities. Most real AI features touch two or three of these frameworks at once.
A Practical Compliance Checklist Before You Ship
Run every AI feature through this sequence before it reaches production:
- ▸Classify the use case. Write down which risk tier applies and why, referencing the specific Annex III category if high-risk. Have someone who is not the author challenge it.
- ▸Confirm no prohibited element. Check the feature against the banned-practices list. This is a hard gate, not a discussion.
- ▸Map the data. Document sources, lawful basis under GDPR, retention, and any cross-border transfer. Flag personal or special-category data early.
- ▸Design oversight and disclosure into the UI. Add the human-override path and the AI-notice or synthetic-content label as build requirements, tracked as tickets.
- ▸Instrument logging. Capture model version, inputs, outputs, and confidence so decisions are reconstructable.
- ▸Test for accuracy, robustness, and bias. Define acceptance thresholds and record the results as evidence, not just as a passing CI run.
- ▸Assign accountability. Name the person or role responsible for the system after launch, and set a review cadence.
- ▸Prepare the paperwork. For high-risk, assemble technical documentation and the conformity route. For limited-risk, keep your transparency evidence on file.
If any step cannot be answered, the feature is not ready, however good the demo looked.
How TuniCyberLabs Builds Compliant AI, Nearshore from Tunisia
Most compliance failures are not legal failures; they are engineering failures that surface as legal problems. That is exactly where custom engineering beats a bolted-on wrapper around a generic tool. When compliance is designed into the system rather than papered over afterwards, audits become routine.
TuniCyberLabs is structured for this reality. Our parent company is in Tallinn, Estonia, giving clients EU-anchored contracts and a GDPR footing inside the single market, with an office in Limassol, Cyprus. Our engineering team works from Sousse, Tunisia, in the same working hours as Europe, in English, French, and Arabic, at genuine nearshore cost. You get EU legal certainty and same-timezone delivery without paying Western-European rates.
We build in four phases. First we understand the use case and run the AI Act risk classification with you, so obligations are known before a line of code is written. Then we design the architecture with disclosure, human oversight, logging, and data governance as first-class components. We build and deploy production-grade systems with the traceability, testing, and security controls that NIS2, DORA, and the AI Act expect, not retrofitted later. Finally we support and evolve the system as guidance from the AI Office and national regulators matures through 2026 and into the 2027 deadlines.
The regulatory picture will keep shifting, but the direction is fixed: AI that affects people in the EU must be documented, overseeable, and defensible. Businesses that treat that as an engineering requirement now will ship faster than competitors who discover it during an audit. If you have an AI feature on your roadmap for 2026, the right time to classify it is before you build it, not after a complaint lands.