Skip to content
AI & Software Studio
EU AI Act

Built for the AI Act, not certified against it.

Regulation (EU) 2024/1689 is in general application. Most of what it asks for is engineering — disclosure, oversight, logging, documentation and evidence that the system works — and we build those in by default.

This page describes how we build. It is not a legal opinion on your obligations, and it is deliberately specific about which parts we can help with and which belong with your counsel.

Status
In force
Our role
Engineering
Hosting
EU

Where we stand on it

2 Aug 2026
In general application

The bulk of the Regulation, including transparency duties.

6
Duties we build for

Transparency, oversight, records, data, documentation, accuracy.

6
Artefacts at handover

All of them exist on the day the system goes live.

0
Legal opinions

We are engineers. Classification belongs with your counsel.

01Where we are

The schedule, and where today sits on it.

  1. 1 Aug 2024

    In force

    Regulation (EU) 2024/1689 enters into force, with obligations phased in over the following three years.

  2. 2 Feb 2025

    Prohibitions & AI literacy

    Banned practices apply, and providers and deployers must ensure staff working with AI have a sufficient level of AI literacy.

  3. 2 Aug 2025

    General-purpose AI

    Obligations for general-purpose AI models, governance structures and penalties begin to apply.

  4. 2 Aug 2026

    General application

    The bulk of the Regulation applies, including the Article 50 transparency duties that reach ordinary business chatbots and generated content.

    In effect now
  5. 2 Aug 2027

    Embedded high-risk systems

    High-risk obligations for AI embedded in regulated products, plus the deadline for general-purpose models placed on the market before August 2025.

Dates are the Regulation’s own schedule and remain subject to amendment at EU level. Nothing here is legal advice — see the note at the foot of this section.
02Classification

Four tiers, and where your system probably sits.

The Regulation scales with risk. Knowing which rung you are on changes the size of the job from a programme to a checklist — or occasionally the other way around.

  1. Unacceptable
    Prohibited outright

    Social scoring, untargeted scraping for facial recognition, emotion inference at work or school.

  2. High risk
    The heavy obligations

    Systems that materially influence employment, credit, education, essential services or law enforcement — plus AI embedded in regulated products.

  3. Limited risk
    Transparency duties (Art. 50)

    Chatbots, assistants and generated content. Tell people they are dealing with an AI system, and mark synthetic output.

  4. Minimal risk
    No specific obligations

    Spam filtering, search ranking, forecasting, most internal tooling. Good practice still applies; the Regulation does not add to it.

Nearly everything we are asked to build sits in the bottom two tiers.

Which is worth knowing before anyone sells you a compliance programme. The work is real, but it is transparency, oversight and documentation — not certification.

Simplified for orientation. Classification depends on the specific use and belongs with your counsel — see the note below.
03Scope

Three things worth knowing before a project starts.

01

You are almost certainly a deployer

Most businesses use AI systems rather than place them on the market. Deployer duties are lighter than provider duties, but they are real: use the system as instructed, keep a human in the loop where required, retain logs, and make sure the people operating it are competent to do so.

02

You become a provider more easily than you think

Put your own name on a system, change its intended purpose, or substantially modify a high-risk one, and the provider obligations move to you. This is the single most common surprise in the Regulation.

03

Risk sits with the use, not the technology

The same model is unregulated in one context and high-risk in another. Classification follows what the system decides and about whom — not which vendor's API is behind it.

04In the codebase

Six duties, six things we do about them.

None of these is expensive designed in. All of them are expensive the week a customer sends a questionnaire and the answers have to be reconstructed from memory.

01

People are told they are talking to a machine

Transparency (Art. 50)

Every assistant we ship discloses that it is an AI system in the interface itself, not in a policy page. Synthetic content we generate on your behalf is marked as such.

02

A person can see, stop and override it

Human oversight (Art. 14)

Confidence thresholds route uncertain cases to a review queue, and every automated action has a person who can reverse it. Oversight is a screen someone actually uses, not a clause.

03

Every run leaves a trace

Record-keeping (Art. 12)

Inputs, retrieved sources, the decision and who reviewed it are logged with retention rules. If a regulator or a customer asks why, the answer exists.

04

We can name every data source

Data governance (Art. 10)

Where the training or retrieval data came from, what it contains, what was excluded and why — documented while we build, because reconstructing it afterwards is guesswork.

05

The file exists before you need it

Technical documentation (Art. 11)

Purpose, architecture, model choices, known limitations and test results, written as we go and handed over with the system.

06

Performance is a number, not an adjective

Accuracy & robustness (Art. 15)

An evaluation set built from your real cases, agreed before launch and re-run on every change, so claims about accuracy are evidenced.

Not sure which category your use case falls into?

Bring it to the discovery call. We will tell you what we think, and what your lawyer will want to see.

05Handover

What exists on the day it goes live.

Every one of these ships with the system, not after it. If your data protection officer asks for the file, it is already written.

  • A disclosure in the interface, not in a policy page
  • A named human who can see, pause and reverse decisions
  • Logs of inputs, sources, outputs and reviewers, with retention rules
  • A data-source register: what went in, what was excluded, why
  • A technical file: purpose, architecture, limitations, test results
  • An evaluation set built from your cases, re-run on every change
06Frequently asked

The AI Act, answered plainly.

Something we have not covered? Ask us directly or mail hello@befzy.com.

If your organisation puts an AI system on the EU market or uses one in the EU, it very likely applies to you in some role — most businesses are 'deployers' rather than 'providers'. It also reaches providers outside the EU whose output is used inside it. What differs enormously is how much it asks of you, which depends on the risk category your specific use falls into.

Usually not. Most customer-facing assistants, document processing and internal automation fall outside the high-risk annexes and carry mainly transparency duties — telling people they are dealing with an AI system, and marking generated content. Risk rises when a system materially influences decisions about employment, credit, education, essential services or law enforcement. We classify the specific use case during discovery rather than guessing from the category.

That the artefacts the Regulation asks for exist by the time the system is live, rather than being reconstructed under pressure: the disclosure in the interface, the human oversight path, the logs, the data sources, the technical file and the evaluation results. None of it is expensive when it is designed in. All of it is expensive retrofitted.

No. We are engineers, and this page is a description of how we build — not a legal opinion on your obligations. Classification and compliance sign-off belong with your counsel or your data protection officer. What we can do is make sure the technical evidence they will ask for already exists, and hand them documentation they can actually read.

They overlap rather than compete. The GDPR governs the personal data flowing through the system; the AI Act governs the system itself. In practice the same design decisions serve both — minimisation, retention rules, access control, logging and a human in the loop — which is why we treat them as one architecture problem rather than two compliance projects.

Next step

Let's work out what the Act actually asks of your use case.

A free 20-minute call, no strings attached. We will tell you where the leverage is — and where it is not.

  • No sales deck, no discovery invoice
  • You get a ranked shortlist either way
  • If AI is the wrong tool, we say so