AI Developer · Module 5 · Regulation, Ethics and Responsibility

Regulation as Constraint: AI Act, Cyber Resilience Act, Product Liability, NIS 2, DORA, GDPR

The lesson reads the instruments that reach software (the AI Act, the Cyber Resilience Act, the Product Liability Directive, NIS 2, DORA and the GDPR) and asks what each requires of those who write, review, release and keep code. None of the development provisions read distinguishes code written by a person from code written with an assistant. Participants apply a role test and build a dated duty register that ties each article to an addressee, an artefact and a holder. The content is framed as organisational implication, not legal advice.

Lesson 24 of 33Chapter 2490 minutes

Read the chapterThe whitepaperThe slides

All courses / AI Developer / Module 5 / Chapter 24

Learning objectives

After the lesson the participant can:

Key concepts

The role test comes first
An article is a duty only for an addressee, and one team can hold several roles at once: manufacturer of a product on the market, provider or deployer of an AI system, entity under a cybersecurity regime, controller of personal data, publisher of software others integrate.
A quiet change of role
Under AI Act Article 25(1)(c), a deployer or third party that modifies the intended purpose of an AI system so that it becomes high-risk is considered its provider. The book's reading is that prompt, retrieval and tool configuration can amount to such a change, so the event must be visible before merge.
Generated code is the manufacturer's code
Under the Cyber Resilience Act the product is designed, developed and produced to the essential requirements of Annex I, with due diligence on third-party components under Article 13(5) and vulnerability handling for a support period of at least five years. The text does not exempt code an assistant wrote.
Independence of approval
Delegated Regulation (EU) 2024/1774 asks in Article 17(1)(b) for mechanisms that ensure the independence of the functions that approve changes. Reading this as the legal form of the independent oracle is the book's own step.
Duty register
A register in version control read when a decision is taken: instrument and article, addressee, what the text asks, what developers do, the artefact and the function. Each row has a holder and deputy, and the texts are re-read at most six months later and on every announced amendment.

Interactive exercises

Do them here and get feedback at once. Choose a card and then where it belongs, or drag it.

Interactive exercise 1 · Match

From article to developer action

Match each row of the chapter's duty register to what developers do about it. The readings are organisational implications, not legal advice.

Interactive exercise 2 · Scenario

A small change to the system prompt

Apply the chapter's reading of how a change of intended purpose can change an organisation's role, and the pipeline rule Nordvik Region adopted.

Teaching plan

15 minThe teacher introduces the role test with the table for Nordvik Region and Hansa Mutual; participants answer the five questions for their own organisation.
25 minLecture by instrument: the four routes of the AI Act into development, the Cyber Resilience Act and its reporting, software as a product under Directive (EU) 2024/2853, NIS 2, DORA and the GDPR in the repository.
10 minReading of Nordvik's pipeline rule intended-purpose-change and of four rows of Hansa's register DRR-HM-001-LEG.
30 minExercise: groups read one instrument into the repository by writing duty register rows.
10 minPlenary on what the chapter says was not verified and is therefore not claimed, and why the register carries the date each text was read.

Discussion

  1. The chapter calls a configuration change that turns a general-purpose assistant into an eligibility tool Nordvik Region's sharpest regulatory risk in development. What is the equivalent quiet change in your organisation?
  2. No row of the table of work classes is satisfied by Level 4, because every instrument assigns its duty to a named holder. What does that imply for how you describe agents to a supervisor?
  3. Why does the chapter prefer existing artefacts such as specification records, verification plans and review records as evidence over a separate compliance file?

Written exercise

Exercise · 30 minutes

Read one instrument into the repository

Choose one instrument from the chapter that addresses your organisation, or take Hansa Mutual as a financial entity under DORA. List the products the organisation supplies or publishes and the AI systems it builds or configures, and apply the role test. For three articles, copy the operative words as the chapter gives them and decide who the addressee is. For each, name the artefact in version control that evidences the duty and its age limit, the events that would change the role, a holder and a deputy, the ceiling for AI, and where a Level 4 prohibition applies. Record the date the text was read. Mark anything you could not verify as open.

Deliverable: Three duty register rows with article, addressee, developer action, evidencing artefact, age limit, holder, AI ceiling and reading date.

Self-test

Choose an answer to see whether it is right, or open the answer below each question.

  1. What does the chapter conclude about how the development provisions it read treat code written with an assistant?

    Show the answer

    A. None distinguishes it from code written by a person; Article 50(2) may be the exception
    The thread of the chapter is that the instruments attach to products, systems, processing and entities; none of the development provisions read distinguishes authorship by a person from use of an assistant, and the position of code under Article 50(2) is left open.

  2. From which date does Directive (EU) 2024/2853 apply to products, and what does its Article 4(1) say about software?

    Show the answer

    C. To products placed on the market after 9 December 2026; a product includes software
    The chapter cites Article 2(1) for products placed on the market or put into service after 9 December 2026 and Article 4(1) for the definition of a product as including software.

  3. How often is the duty register re-read, according to the practical guide?

    Show the answer

    D. At most six months after the last reading, and on every announced amendment
    Step six of the guide: record the date each text was read and re-read at most six months later and on every announced amendment, because texts change and entries expire.