The EU AI Act Is Here: A Practical Readiness Guide for Software Teams

The EU AI Act is now in force with obligations phasing in through 2026 and 2027, and it reaches far beyond AI startups. If your software touches the EU market and includes any automated decision-making, recommendation, scoring, or content generation, you are likely in scope — as a provider or as a deployer.

The good news: most of the work is engineering hygiene you should be doing anyway. This is the readiness sequence we run with clients, stripped of legal jargon.

Who is actually in scope

The Act distinguishes providers (who build AI systems) from deployers (who use them) — and many companies are both. Buying an LLM API and building a product on top makes you a provider of your own system in most practical cases. The law follows the function, not the marketing label: a 'smart' pricing engine, a CV screening tool, or a credit-scoring module can qualify as an AI system even when nobody calls it AI.

Prohibited practices — like emotion recognition in workplaces or untargeted facial scraping — apply now. If your product roadmap contains anything adjacent, kill it early. The fines are not the worst outcome; delisting from the EU market is.

Classify your systems before anything else

The Act is a risk ladder, and your obligations depend entirely on where each system sits. Build an inventory — every feature that makes a decision, prediction, or generation — and classify honestly:

• Prohibited: banned practices (social scoring, manipulative techniques) — must not exist
• High-risk: decisions affecting employment, credit, education, essential services — heavy documentation, human oversight, and logging obligations
• Transparency-tier: chatbots and generated content — users must know they are interacting with AI, and synthetic media must be labeled
• Minimal-risk: spam filters, game AI, most internal tooling — encouraged codes of conduct, no mandatory obligations

What regulators will ask for

For high-risk systems, expect to produce technical documentation covering the system's purpose, data governance, training and evaluation methodology, and known limitations — plus logs of operation and evidence of human oversight. This sounds bureaucratic until you realize it is a well-run ML practice written down: dataset documentation, eval reports, monitoring, and a kill switch.

Deployers of high-risk systems carry their own duties: using systems per instructions, keeping humans in the loop meaningfully (not rubber-stamping), informing workers, and documenting their own oversight. 'The vendor said it was compliant' is not a defense for skipping your half.

Engineering practices that double as compliance

Almost every AI Act artifact maps to an existing engineering artifact. Model cards become technical documentation. Eval suites become evidence of accuracy and robustness testing. Data lineage documentation becomes data governance. Access logs become logging obligations. Structured decision records become human-oversight evidence.

The efficient path is not a compliance bolt-on — it is upgrading your existing ML/AI documentation to the level where a regulator's question takes hours, not weeks, to answer. Teams that already practice solid MLOps are 80% of the way there.

A 30-60-90 day plan

Days 1-30: build the inventory and classify every system. Involve legal once, with a complete list, not feature by feature. Days 31-60: for anything in the high-risk or transparency tiers, gap-assess your documentation, logging, and human oversight against the requirements — and fix the cheap gaps immediately. Labeling AI-generated content and disclosing chatbots is usually a sprint, not an epic.

Days 61-90: operationalize. Assign an owner for each in-scope system, add AI-system review to your product intake process so new features get classified at design time, and schedule a re-assessment cadence. Compliance that lives in a PDF dies quietly; compliance that lives in your intake process compounds.