The AI Act Is Also a Product Question

The EU AI Act is back in the X discussion this week. People are talking about deadlines, high-risk systems, transparency obligations, AI agents, human oversight and what 2026 really means for companies building with AI.

Some of that discussion is sharper than the official timeline. A few posts make it sound as if everything changes on one date. The EU sources are more precise: the AI Act applies progressively. Some obligations already apply. Others come later. Some details are still being clarified through guidance and simplification proposals.

But it would be a mistake to use that complexity as a reason to wait.

For founders, CTOs, product owners and Mittelstand teams, the AI Act is not only a legal calendar. It is a signal that AI features in products and internal systems need to grow up.

The most useful question is not only: which article applies on which date?

The better product question is:

Which AI systems do we actually operate, what responsibility do they carry, and could we explain tomorrow how they work, how they are supervised and where their limits are?

Compliance Does Not Start In A Legal Folder

Many companies treat regulation as something that happens after development. First the team builds. Then someone reviews. Then documentation is written. Then everyone hopes the gaps are manageable.

That is already painful with normal software. With AI systems, it becomes risky.

AI features are often more than a new interface element. They change decisions, data flows and responsibilities. A chatbot answers customer questions. An agent classifies support tickets. An internal tool prioritises applications, invoices, leads or risks. A coding agent opens pull requests. A product feature summarises documents, proposes actions or automates part of a workflow.

Once AI enters those workflows, some questions cannot be cleanly pasted on afterwards:

Which data enters the system?
Which decision or recommendation does it produce?
Who is responsible if the recommendation is wrong?
When must a human intervene?
What is logged?
Which users know that AI is involved?
How can an error be reconstructed?
Which parts are model behaviour, and which parts are product logic?

These are not purely legal questions. They are architecture questions.

Companies should absolutely confirm legal interpretation with qualified counsel. But product and engineering teams need to provide the substance. Without an inventory, data flows, role models, logging, documentation and clear responsibility boundaries, even good legal advice has little to work with.

The Deadline Matters Less Than The Preparation

The AI Act timeline matters. Prohibited practices and AI literacy obligations have applied since 2025. General-purpose AI obligations became relevant in 2025. Many rules, including transparency obligations and enforcement structures, are on the official timeline for 2026. At the same time, political agreements and proposals may change how some high-risk or labelling obligations are phased in.

That is complicated.

But for most product teams, the first bottleneck is not the final legal nuance. The first bottleneck is much more practical:

They do not know exactly which AI features they operate.

That sounds basic. In practice, it often is not.

Many companies now use AI in several places:

chatbots in support or sales;
LLM features inside SaaS products;
internal assistants over documents, wikis or tickets;
automated classification and summarisation;
AI app-builder prototypes inside business teams;
coding agents in development workflows;
marketing and content workflows using generative AI;
reporting or analytics features that produce recommendations.

Individual teams may know their own tools. Almost nobody has the full picture.

That is where AI Act readiness should begin: not with panic, but with an honest inventory.

The Inventory Is The First Architecture Move

An AI inventory does not need to be perfect on day one. It needs to be useful.

For every relevant system, the company should know at least:

Where is AI used?
Which model or service is involved?
Which data is processed?
Is the use internal, customer-facing or public?
Does the system make decisions, prepare decisions or only generate text?
Is personal, financial, contractual or sensitive data involved?
Who owns the business outcome?
Who owns the technical system?
Which logs, tests and approvals exist?
How can the feature be disabled or rolled back?

This is not paperwork for its own sake. Without this picture, a team cannot sensibly decide whether a feature is minimal risk, transparency-relevant, operationally critical or potentially high-risk.

For German companies, this matters especially. Many Mittelstand teams already have a layered landscape of ERP, CRM, document management, spreadsheets, specialist applications, external SaaS tools and internal automations. AI often does not arrive as one large transformation programme. It arrives as many small functions in many places.

A plugin here. An assistant there. An automatic export. A new chat feature. A fast prototype. An integration into a ticket system.

Each decision looks small. Together, they create a new system landscape.

At McDougall Digital, we treat this inventory as architecture work, not bureaucracy. If a company does not know which AI features exist, it cannot operate them responsibly.

Risk Is A Product Property

The AI Act uses a risk-based approach. For product teams, that is useful because it reinforces an important principle:

Not every AI feature needs the same process.

A spam filter, an internal brainstorming helper or a summary of non-sensitive text is different from a tool that sorts job applicants, affects access to credit, processes medical information or supports decisions in critical infrastructure.

The problem is that teams often name those differences too late.

Good product work classifies AI features early:

Assistant feature: AI helps a person without making meaningful decisions.
Transparency-relevant feature: Users need to understand that AI is involved or that content was generated.
Data-bearing feature: AI processes personal, confidential or business-critical data.
Decision-support feature: AI influences priorities, assessments, recommendations or approvals.
Automated actor: An agent can trigger actions in other systems.
Potential high-risk feature: The use touches areas such as employment, education, critical infrastructure, access to essential services or other sensitive contexts.

These categories do not replace legal review. They give product and engineering teams a structure.

The more responsibility a feature carries, the earlier architecture, data modelling, permissions, logging, tests, fallbacks and human oversight need to be designed.

Human Oversight Is Not A Button

In many AI governance discussions, “human oversight” sounds as if the product only needs an approval button somewhere.

That is not enough.

Human oversight is workflow design. The human must be able to understand what they are reviewing. They need context, the right interface, clear limits, enough time and a real ability to intervene.

A weak oversight process looks like this:

The AI produces a recommendation. A person clicks “OK” under time pressure. The system records that a human was involved. Later, nobody can explain which information mattered or whether meaningful review was possible.

A better process looks different:

The AI shows the relevant input basis.
The system marks uncertainty and edge cases.
The person can see which rule or criterion was applied.
Certain actions always remain manual.
Objection, correction and escalation paths exist.
The decision is logged in a way that can be reconstructed.
Repeated error patterns feed back into product improvement.

That is architecture, UX and operations at the same time.

If an AI agent can close tickets, change customer data, pre-sort applications or bring code into a production codebase, oversight needs to live inside the system design. It cannot live only in a policy document.

Transparency obligations are often discussed as a labelling question: does the product need to say that content is AI-generated?

Sometimes yes. But from a product perspective, transparency is broader.

Users need to understand when they are interacting with a machine, when content has been synthetically generated, what role AI plays in a process and where human responsibility sits. Support teams need to explain what happened. Sales teams must not promise capabilities the system cannot reliably provide. Product managers need to decide when AI is visible and when automation runs in the background.

That has practical consequences:

Interface text needs to be precise.
Error states need to be honest.
AI-generated content needs provenance and context.
Support documentation needs to explain the AI feature.
Internal teams need to know what they may tell customers.
Logs need to preserve the relevant events.

Transparency is not decoration. It is part of product quality.

Documentation Should Come From The System

Many teams dread documentation because it sounds like extra writing after the real work is done.

That reaction is understandable, but it points to the wrong approach. In AI-supported software, much of the useful documentation should fall out of good architecture and clean implementation.

If data flows are modelled, they can be documented. If roles are clear, permissions can be explained. If prompts, models, versions, tests and evaluation data are managed structurally, documentation is not a treasure hunt. If decisions and outputs are logged, operations become more traceable.

Bad documentation is often a symptom of bad architecture.

Good readiness work therefore asks:

Are data sources and data types visible?
Are model calls and versions traceable?
Are prompts, tools and system boundaries versioned?
Are there test cases for risky scenarios?
Are failure patterns and user corrections reviewed?
Is someone responsible for operations and further development?
Is there a plan for model changes, shutdown or fallback?

These questions help with regulation. More importantly, they make the product stronger.

Why Start Now?

Because the expensive gaps do not appear on the deadline.

They appear when a team spends months adding AI features without defining data flows, responsibilities, logging and boundaries. They appear when a prototype quietly becomes a customer feature. They appear when an agent first assists internally and later starts taking actions. They appear when nobody can reconstruct which model version influenced which output.

If a company waits until shortly before a deadline, readiness becomes rework.

If it starts now, AI Act readiness becomes quality work:

better product decisions;
clearer system boundaries;
fewer shadow processes;
better documentation;
stronger support and operations;
more realistic customer promises;
less risk when expanding AI features.

That is the productive way to look at regulation. Not: how do we avoid trouble? But: how do we build AI-supported software that is explainable, maintainable, secure and accountable?

A Pragmatic 30-Day Start

Companies do not need to launch a massive AI governance programme immediately. A sensible start can be very concrete.

In the first 30 days:

Create an AI inventory: List AI features, internal assistants, agents, app-builder prototypes and generative workflows.
Classify data: Identify where personal, confidential, financial, contractual or customer-specific data is involved.
Roughly classify risk: Separate helper features from decision-support systems and automated actors.
Assign owners: Every relevant feature needs business and technical ownership.
Review transparency: Identify where users, customers or internal teams need clearer information.
Define oversight: Decide which actions require human review, escalation or manual approval.
Check logging and documentation: Ask what would be reconstructable if an error had to be investigated tomorrow.
Prioritise: Not everything needs to be fixed at once. External, data-bearing and decision-adjacent systems come first.

This does not replace legal assessment. It makes the company capable of having a useful legal and technical conversation.

How McDougall Digital Can Help

For McDougall Digital, AI Act readiness is not an isolated compliance project. It is part of bringing AI-supported software into production responsibly.

We help companies turn vague AI ideas into systems that can be operated:

inventorying AI features and agents;
mapping data flows, model calls and system boundaries;
assessing risk from a product, architecture and operations perspective;
designing human oversight and approval paths into workflows;
structuring logging, documentation, roles and responsibilities;
hardening prototypes for production or deliberately limiting their scope;
building AI-supported internal tools that remain maintainable and operable.

The goal is not to suffocate innovation with paperwork. The goal is to build good AI ideas in a way a serious company can stand behind.

The AI Act will keep being discussed. Deadlines may be clarified, shifted or supplemented by guidance. But the technical groundwork remains.

A company that knows which AI systems it operates, which data they touch, which decisions they influence and how humans can intervene is not only better prepared for regulation.

It is also building better software.