Generate custom courses on any topic — with hands-on practice, AI guidance, and visuals built in.
Already have an account?
Build-phase duties under the EU AI Act turn into engineering work long before anyone writes a legal memo. The course focuses on provider obligations, meaning the duties that attach to the team that ships an AI system, because engineers and data scientists create most of the evidence those duties depend on. Teams often miss this because the work feels like building features, while the pass or fail later comes down to what was recorded, tested, and kept consistent across versions. The common failure is not bad intent. It is a gap between what the system does and what the team can prove it does.
A provider can only defend a release when the build has a clear shape from the start. That shape begins with what system is being built, what it is for, and what it can and cannot do in the real setting where it will run. It also includes what data went in, what controls shipped with it, what logs exist, and what a human can do when the output looks wrong. Seeing those areas together matters because a missing piece is usually discovered after the team has already trained, integrated, and deployed. The map below lays out the full territory before any one part is taught.
In this course, an AI system is not just a model file or a clever prompt. It is the whole setup that takes inputs from a workplace process, produces outputs people rely on, and behaves in ways that are shaped by code, data, configuration, and the interface around it. That is why a small change in a pipeline can change the system’s real world effect, even if the model weights stay the same.
A team can think it is “just integrating a model,” but the regulated object is the assembled system once it makes decisions, recommendations, or generated content part of a workflow. The training job, feature store, retrieval index, guardrails, monitoring rules, and UI copy together decide what the user sees and what they are allowed to do next. If those parts are not pinned to a version and a purpose, later testing and documentation will not line up with what was actually shipped.
Engineers and data scientists usually own the choices that fix the system’s intended purpose, inputs, and limits, because those choices are made in tickets, datasets, evaluation plans, and code reviews. Legal and compliance teams can interpret the Act, but they cannot reconstruct what the model saw in training or what the UI permitted at decision time. Product can set goals, but they cannot replace missing logs or rerun an untracked experiment.
The handoff to deployers also starts in the build. Deployers need clear instructions, usable transparency in the interface, and oversight hooks that work under pressure, because a policy PDF cannot compensate for a system that hides its own uncertainty or blocks intervention. When builders treat these as “later paperwork,” they usually end up patching the interface and rewriting documentation to match reality, which is slower than designing it once.
Before going further, it helps to spot which failure modes are already familiar.