Saša Tomić

EU AI Act compliance engineering

The EU AI Act is the European Union’s law regulating artificial intelligence.

It does not impose one set of rules on every use of AI. The obligations depend on:

Several parts of the law already apply.

The dates that matter

2 February 2025
The AI Act’s prohibited-practice rules and AI-literacy requirements started applying.

2 August 2025
The rules for providers of general-purpose AI models, or GPAI models, started applying.

2 August 2026
The Article 50 transparency rules started applying.

These include rules for:

There is one narrow transition period:

AI systems that generate synthetic audio, images, video or text and were already on the market before 2 August 2026 have until 2 December 2026 to add the machine-readable marking required by Article 50(2).

The other Article 50 duties have no equivalent grace period.

2 December 2027
The main high-risk requirements start applying to Annex III high-risk AI systems.

These are mainly standalone AI systems used for sensitive purposes such as employment, education, creditworthiness, law enforcement and access to essential services.

2 August 2028
The main high-risk requirements start applying to certain AI systems covered through Annex I.

These are AI systems used as products or safety components of products governed by specified EU product-safety legislation.

What applies today?

As of September 2026, Article 50 already applies.

What does this mean in practice? For many ordinary AI features, what matters today is transparency. The complete high-risk AI Act compliance package is still not required.

For example:

You have an AI customer-support assistant.
Users generally need to know they are interacting with AI.

Your AI system generates images, audio, video or text.
The provider of that generative AI system may need to make those outputs machine-readable as AI-generated or manipulated.

You publish an AI-generated deepfake.
The person or company using the AI to publish it generally needs to disclose that it was artificially generated or manipulated.

You use AI to analyse people’s emotions.
People exposed to the system generally have to be informed about its operation. Separate AI Act rules may also prohibit some uses entirely.

The full high-risk requirements are a separate layer with later deadlines.

Does the AI Act apply to a Swiss company?

It can.

The AI Act is not limited to companies established inside the EU.

It applies, among other cases, to:

A provider is explained below. A deployer is the company or organisation using an AI system under its control.

For example:

A Swiss company builds an AI customer-support product and sells it to EU customers.
The AI Act can apply even though the company is Swiss.

A Swiss company runs an AI system in Switzerland and its output is used by an EU customer.
The AI Act can also apply depending on the arrangement.

A Swiss employee privately uses an AI image generator for a hobby.
Personal, non-professional use is generally outside the deployer obligations.

First: what counts as an AI system?

Under the AI Act, an AI system is a machine-based system that operates with some level of autonomy and infers from its input how to generate outputs such as:

Those outputs can influence physical or digital environments. The technical behaviour decides whether your software is an AI system, a simple statement is not sufficient.

Provider or deployer?

This distinction is fundamental.

Provider

A provider is the person or organisation that develops an AI system, or has it developed, and places it on the market or puts it into service under its own name or trademark.

You do not need to train the underlying neural network yourself.

For example:

A Swiss SaaS company builds a customer-support product using an external language-model API.

The underlying model may have been trained by another company.

But if the Swiss company develops the complete AI system around that model and offers that system to customers under its own name, it can be the provider of the resulting AI system.

The model company remains responsible for its own role, for example as provider of the underlying general-purpose AI model.

Deployer

A deployer is a company or organisation that uses an AI system under its authority.

For example:

A retailer purchases an AI recruiting product from another company and uses it to assess job applicants.

The retailer can be the deployer.

The company selling the recruiting system can be the provider.

You can have both roles

One company can be a provider for one system and a deployer for another.

The roles are determined per AI system and use case, not once for the entire company.

“We only call an AI API”

That does not by itself determine your role.

If you simply use somebody else’s finished AI product internally, you may be a deployer.

If you integrate an external model into a product that you develop and provide under your own name, you can be the provider of that resulting AI system.

Using an API therefore does not remove AI Act obligations.

It changes which part of the AI stack you are responsible for.

What is a general-purpose AI model?

A general-purpose AI model, or GPAI model, is a model capable of performing a wide range of different tasks and being integrated into many different downstream systems.

Large language models are common examples.

The term foundation model is often used informally for similar technology, but general-purpose AI model is the term used by the AI Act.

If you merely use an API from a GPAI provider, you do not become the provider of that underlying model just because you call the API.

If you develop or place your own general-purpose AI model on the EU market, the separate GPAI rules can apply.

Those rules have applied since 2 August 2025 and cover areas such as:

GPAI models presenting systemic risk, meaning particularly capable models that can create broad or serious risks, have additional requirements.

This page focuses mainly on AI systems and Article 50 rather than the separate GPAI regime.

Article 50: what actually applies today?

Article 50 does not create one generic “AI label.”

It creates several different obligations for different situations.

1. AI that interacts directly with people

If you provide an AI system intended to interact directly with people, it must normally be designed so the person knows that they are interacting with AI.

Examples include:

The information must be clear and distinguishable and provided no later than the first interaction.

For example:

You are speaking with an AI assistant.

A legal disclaimer hidden in the terms of service is not the same thing as informing the user at the interaction itself.

When is a separate disclosure unnecessary?

The disclosure is not required when it is obvious to a reasonably informed and observant person, given the circumstances, that they are interacting with AI.

That exception should not be treated as permission to hide the AI nature of a system simply because somebody might eventually figure it out.

There is also a specific exception for certain AI systems authorised by law for detecting, preventing, investigating or prosecuting criminal offences, subject to the applicable safeguards.

2. Machine-readable marking of AI-generated content

Providers of AI systems that generate synthetic:

must generally ensure that their outputs are marked in a machine-readable format and can be detected as artificially generated or manipulated. This is a technical requirement.

It is not required that every AI-generated image or paragraph displays a giant visible “MADE BY AI” badge. Machine-readable marking means information or signals that software can detect.

Depending on the content and implementation, this can involve techniques such as:

The technical solution must be effective, interoperable, robust and reliable as far as technically feasible.

Existing systems

If the generative AI system was already placed on the market before 2 August 2026, its provider has until 2 December 2026 to implement this Article 50(2) marking requirement.

If the system was placed on the market from 2 August 2026 onward, that grace period does not apply.

Exceptions

The marking requirement does not generally apply where the AI system only performs standard editing assistance or does not substantially change the user’s input or its meaning.

For example, ordinary correction or editing functionality may fall outside this marking duty when it does not substantially transform the content.

There is also a specific law-enforcement exception.

3. Emotion recognition and biometric categorisation

A deployer using an emotion-recognition or biometric-categorisation system generally has to inform the people exposed to it, no later than the person’s first exposure to the system.

Note that some uses of emotion recognition or biometric AI are separately prohibited by Article 5.

4. Deepfakes

A deepfake is AI-generated or manipulated image, audio or video content that resembles real people, objects, places, entities or events and could falsely appear authentic.

A deployer using AI to generate or manipulate a deepfake generally has to disclose that the content was artificially generated or manipulated.

This is a human-facing disclosure, unlike the provider-side machine-readable marking described above.

The same piece of content can therefore involve two separate duties:

Provider of the generative system:
machine-readable marking

Person or company publishing the deepfake:
human-facing disclosure

For evidently artistic, creative, satirical, fictional or similar works, the disclosure can be made in an appropriate way that does not unnecessarily interfere with the work itself.

5. AI-generated public-interest text

There is also a specific rule for AI-generated or manipulated text published to inform the public about matters of public interest.

The deployer generally has to disclose that the text was artificially generated or manipulated.

This is not a requirement to label every AI-assisted sentence on the internet.

The rule specifically concerns publication intended to inform the public on matters of public interest.

There is also an important exception where:

In that case, the Article 50 disclosure is generally not required.

Machine-readable marking and visible disclosure are different

This is one of the easiest parts of Article 50 to misunderstand.

Machine-readable marking

Usually a provider duty. It applies to providers of systems generating synthetic audio, images, video or text.

The output must technically carry detectable information indicating that it was artificially generated or manipulated.

Human-facing disclosure

Usually a deployer duty for specific uses. It applies to situations such as:

And provider-side interaction disclosure applies when people directly interact with AI.

Generally, whether a machine-readable mark is required needs to be decided separately from whether the human-visible disclosure is required, on a case by case basis.

What about AI-generated summaries?

Several questions matter in case of AI-generated summaries:

What about automated decisions about people?

An AI system making or supporting decisions about people may or may not be high-risk, based on the purpose. The AI Act lists specific high-risk areas.

High-risk AI: two different tracks

The Digital Omnibus moved the high-risk deadlines.

There are now two main dates.

Annex III: 2 December 2027

Annex III is a list attached to the AI Act describing sensitive uses that can qualify as high-risk.

Important categories include AI used for:

The full high-risk requirements for Annex III systems start applying on 2 December 2027.

If your business is in one of these broad areas, the exact intended purpose matters. Article 6 contains exceptions for some systems that perform only narrow, preparatory or procedural tasks and do not create a significant risk to health, safety or fundamental rights. Systems that profile natural persons receive stricter treatment.

The classification therefore has to be made per actual use case.

Annex I: 2 August 2028

A separate group covers AI used as a product, or as a safety component of a product, governed by specified EU product-safety legislation and subject to the relevant third-party conformity-assessment conditions.

A safety component is something whose failure or malfunction can endanger people or property.

These systems follow the Annex I route.

Their main high-risk AI Act requirements apply from 2 August 2028, not December 2027.

That distinction matters for companies building AI into regulated physical products.

What happens to high-risk systems already deployed before those dates?

The AI Act contains transition rules.

High-risk systems placed on the market or put into service before their applicable high-risk deadline are generally brought under the new high-risk requirements when they undergo significant changes in their design after that date.

There is a separate deadline for high-risk AI systems intended for use by public authorities: providers and deployers of those systems must take the required compliance steps by 2 August 2030.

The transition rules need to be checked against the actual system and deployment rather than assuming that every old system is permanently exempt.

What does full high-risk compliance involve?

High-risk AI is substantially more work than Article 50 transparency.

For a high-risk provider, the requirements can include:

Risk management

A risk-management system is a documented, ongoing process for identifying, evaluating and reducing risks created by the AI system throughout its lifecycle.

It is not a one-time risk spreadsheet prepared before launch.

Data governance

Where training, validation or testing data is relevant, the provider needs processes for managing its quality, relevance, representativeness and other characteristics required by the AI Act.

Technical documentation

The provider needs documentation explaining what the system is, how it was developed, how it performs, which risks were identified and how the applicable AI Act requirements are met.

This is the evidence file behind the compliance claim.

Record-keeping

High-risk systems need technical capabilities that allow appropriate automatic logging.

Logs are records generated by the system about its operation, not necessarily a detailed log of every chatbot conversation. Logs should make it possible to investigate what happened, monitor behaviour and provide evidence when something goes wrong.

Human oversight

The system has to be designed so appropriate people can understand relevant limitations and intervene when necessary. The oversight needs to be active oversight, in practice.

Accuracy, robustness and cybersecurity

A high-risk system must achieve an appropriate level of:

Post-market monitoring

Post-market monitoring means continuing to monitor how the system performs after it has been released or put into use.

The provider needs a plan for collecting and analysing relevant information throughout the system’s lifetime.

Conformity assessment

A conformity assessment is the process used to demonstrate that the high-risk system meets the applicable AI Act requirements before it is placed on the market or put into service.

The exact route depends on the system.

What obligations do deployers of high-risk AI have?

High-risk compliance is a duty not only for the provider but also for the deployer. Depending on the system and context, duties can include:

A fundamental-rights impact assessment examines how use of the AI system could affect legally protected rights such as privacy, non-discrimination and access to services.

It is required only for specified deployers and use cases, not every company using high-risk AI.

Prohibited AI

Some AI uses are not merely high-risk, they are prohibited. Most of these rules have applied since 2 February 2025. Examples include certain uses involving:

AI literacy

The AI Act’s AI-literacy requirement has also applied since 2 February 2025.

Providers and deployers must take measures to ensure an appropriate level of AI knowledge and understanding among staff and other people operating AI systems on their behalf.

What is appropriate depends on factors such as:

This is separate from Article 50 and the high-risk regime.

Penalties

Article 50 violations fall within the AI Act penalty tier that can reach:

€15 million

or, for an undertaking:

3% of total worldwide annual turnover from the preceding financial year

under the general rule, whichever is higher.

The AI Act contains special proportionality rules for smaller businesses.

For SMEs, including start-ups, the maximum uses the lower of the applicable fixed amount and turnover percentage.

The 2026 Digital Omnibus extends a similar lower-cap treatment for this penalty tier to qualifying small mid-cap companies.

More serious prohibited-practice violations can fall into a higher penalty tier.

The actual fine depends on the circumstances of the infringement and enforcement by the competent authorities.

What I build

I am Saša Tomić.

I build the engineering systems behind AI Act compliance.

Legal counsel determines how the law applies to the company and its use cases.

I turn those decisions into:

The work is split into three stages.

1. AI inventory and classification

The first problem is knowing where AI actually exists.

A company can have AI in:

I can help you build an inventory covering each relevant system or feature. For each one, we record information such as:

Classification

Each feature is then assessed separately. For each feature, we determine questions such as:

The result is an obligation map that engineering and legal counsel can work from together.

AI register

I turn that inventory into a maintained register. Where practical, the register is connected to the systems you already use so changes in models, vendors or product features become part of the regular engineering process.

2. Article 50 transparency

For systems subject to Article 50, I implement the relevant transparency requirements in the product.

AI interaction disclosure

For chatbots, voice agents and other direct-interaction systems, I add the disclosure at the point where the interaction begins.

It is:

That prevents a later redesign from accidentally removing the disclosure.

Machine-readable content marking

Where your system is responsible for Article 50(2) marking, I integrate machine-readable marking into the generation or export pipeline.

The implementation depends on:

I also document any claimed exception, such as standard editing that does not substantially alter the input.

Deepfake and content disclosures

Where the deployer-side rules apply, I build the visible or audible disclosure into the publication flow.

This can include:

Provider-side machine marking and deployer-side visible disclosure are tracked separately so one is not accidentally treated as a replacement for the other.

Evidence and tests

Article 50 does not require generic interaction logging.

Instead, I keep the evidence that actually helps demonstrate implementation, such as:

3. High-risk readiness

If a system could fall into the high-risk regime, I prepare the engineering side before the applicable deadline.

Annex III systems: before 2 December 2027

For each candidate system, we first determine whether the actual intended use falls within Annex III and whether an Article 6 exception applies.

For systems that are high-risk, the engineering work can include:

Annex I systems: before 2 August 2028

If the AI is part of a regulated product or safety component covered through Annex I, I map the AI Act requirements into the existing product-development and conformity process.

The applicable deadline is 2 August 2028, not December 2027.

Technical documentation from the engineering system

I generate as much evidence as practical from:

A repository is the system where source code and its change history are stored.

CI, or Continuous Integration, is the automated system that builds and tests software as it changes.

This reduces the amount of compliance documentation that has to be recreated manually every time the product, model or vendor changes.

Why me

AI Act compliance has legal and engineering parts. Legal counsel answers questions such as:

Engineering part has to make that position true in the actual product. This is what I have been doing for the last 2 years.

Over the last 2 years I’ve been professionally working with AI at the cross-section of software engineering and sensitive financial and accounting systems. While building the Storage system for the ICP network, I was also leading the buildout of the accounting system for it. We had to heavily lean on the AI tools but still make sure that we are fully compliant with all legal requirements. Before that I led the Mainnet Reliability team for a network carrying more than $2 billion in assets, and for a period more than $10 billion.

I have spent years balancing tight engineering deadlines with security and legal compliance.

More on the about page.

How an engagement works

We sign a non-disclosure agreement, or NDA, by default.

An NDA is a legal agreement requiring confidential information shared during the work to remain confidential.

Work is normally remote and asynchronous, meaning most work does not require everyone to be online or in meetings at the same time.

I work inside your repository and existing engineering systems under least-privilege access.

Least privilege means I receive only the permissions needed to perform the work rather than broad administrator access.

The code, inventory, documentation and evidence remain in your systems after the engagement.

A typical inventory and Article 50 engagement looks like this:

Week one

Week two

High-risk readiness is scoped separately because the amount of engineering work depends heavily on the system and its use.

Common questions

“Our chatbot already says it uses AI in the documentation.”

That is not necessarily enough.

For a direct-interaction AI system covered by Article 50(1), users must be informed no later than the first interaction unless the AI nature is already obvious from the circumstances.

The disclosure belongs where the interaction happens.

“We only use OpenAI, Anthropic or another model API.”

The model company can be the provider of the underlying GPAI model.

BUT, if you build a separate AI system around that model and provide the resulting system under your own name, you can also be a provider of that downstream AI system.

It is necessary to establish the inventory to describe who is responsible for what.

“Does every AI-generated image need a visible label?”

No.

Article 50 separates two different duties.

The provider of a generative system generally has a machine-readable marking obligation.

A visible disclosure is required in particular deployer-side situations, such as deepfakes.

They are not the same rule.

“Do we need to label every AI-generated text?”

No.

Provider-side machine-readable marking can apply to synthetic text under Article 50(2).

The separate visible deployer disclosure for text is narrower: it concerns AI-generated or manipulated text published to inform the public about matters of public interest, subject to the human-review and editorial-responsibility exception.

“Our system makes decisions about people. Is it automatically high-risk?”

No.

High-risk status depends on the system’s intended purpose and whether it falls within one of the legally defined categories.

Hiring, education, creditworthiness and other sensitive areas contain important high-risk use cases, but not every AI feature used somewhere in those industries automatically qualifies.

“Nothing we do is high-risk.”

That may be correct.

The useful part is having a documented inventory and classification showing why.

That gives engineering, legal counsel, customers and future auditors one consistent answer.

“Do we need all the high-risk documentation today?”

Not merely because Article 50 started applying.

For Annex III systems, the main high-risk requirements apply from 2 December 2027.

For Annex I product-related high-risk systems, they apply from 2 August 2028.

Article 50 transparency obligations are already active and are separate from those high-risk requirements.

“Can you just write us an AI policy?”

A policy can be part of the evidence.

It does not implement a disclosure in your chatbot, mark generated content, maintain an AI inventory, test human oversight or produce technical evidence from your release process.

I build the engineering side and coordinate it with the legal documentation.

Quick reference

SituationAI Act position
Customer talks directly to an AI assistantProvider generally must ensure the user knows it is AI, unless obvious from context
Generative system produces synthetic text, image, audio or videoProvider generally needs machine-readable marking
Generative system was already on the market before 2 August 2026Article 50(2) marking deadline is 2 December 2026
Generative system entered the market from 2 August 2026 onwardArticle 50(2) marking already applies
Company publishes an AI-generated deepfakeDeployer generally needs a human-facing disclosure
AI-generated text informs the public on a matter of public interestDeployer disclosure can apply; meaningful human review plus editorial responsibility can provide an exception
Emotion recognition or biometric categorisation is usedPeople exposed generally need to be informed; separate prohibitions may also apply
Company merely calls a model APIRole still depends on what it builds and provides; API use does not itself decide provider/deployer status
AI used for recruitment, education, creditworthiness or another Annex III purposeMay be high-risk; classify the specific intended use
Annex III system is high-riskMain high-risk obligations apply from 2 December 2027
AI is a qualifying Annex I product or safety componentMain high-risk obligations apply from 2 August 2028
Company provides its own GPAI modelSeparate GPAI regime applies
Company uses AI only for personal, non-professional activityDeployer obligations generally do not apply

Next step

Message me on LinkedIn with:

I will send you a written initial risk triage within two days.

You can use it whether or not we work together.

Sources

The main legal and implementation sources for this page are: