Step 2 Tier: Decide How Much Structure the Work Needs

Not every build needs the same care. A macro that tidies one person's spreadsheet and a tool that reads claimants' files are both "something built with an assistant", and treating them alike fails one of them. This chapter concerns Step 2 Tier, the second of the twelve steps defined in Chapter 4, and the developer functions behind it, D1 Frame and D2 Design: fixing what the build must respect before it is designed. Five questions (who relies on it, what data it touches, what can go wrong, which law applies, whether it runs unattended) give a tier, one of four, that sets how much of every later step applies, and a recorded decision that someone else can check.

The chapter also explains, in plain terms, the parts of data protection law and of the AI Act that a builder meets at this step. The tier depends on them, and a builder who has never read an article of either instrument decides, by what the build reads and writes, whether the organisation's duties are engaged. The explanations are organisational and architectural implications, not legal advice; whether a particular build is lawful is for the organisation's data protection officer and lawyers.

A few terms first. Personal data is information relating to an identified or identifiable person. A controller is the organisation that decides why and how personal data is processed. A data protection officer is the person an organisation designates to advise on data protection and monitor compliance. A data protection impact assessment is a written assessment of the risks of a kind of processing, required before it begins when it is likely to result in a high risk to people. A high-risk AI system is one that the AI Act places in a class with heavier duties. The tiers are those of AI Developer, Chapter 19: Tier A personal, Tier B team, Tier C business and Tier D project.

Five questions to a tier, with the stop signs of Tier D

Figure 6.1: Five questions to a tier: a stop sign of Tier D ends the citizen build, a crossing signal makes it Tier C, and personal data brings in the data protection officer first.

The chapter builds on three conclusions of the earlier volumes. AI Developer, Chapter 19, defined the four tiers for builds by people who are not developers, and the rule that a prototype becomes production by use (86, Nordqvist, 2026); AI Developer, Chapter 24, set out how the instruments that assign duties for software reach the people who build it; and AI Governance, Chapter 13, set the principle of routing decisions to the lowest level that can take them with evidence (75, Nordqvist, 2026), which is the idea behind tiers.

What a developer does at this step

A developer asks, before building, how much it matters if the build goes wrong, and the answer sets the effort. A throwaway script for the developer's own use gets no review. A payment service gets design review, a security review, tests that someone else wrote, a pipeline that cannot be bypassed and a runbook. The care a payment service needs is absurd for a script, and the speed that suits a script is negligent for a payment service. Proportion is the professional skill.

The five questions

The five questions are the book's own, derived from the four tiers of AI Developer, Chapter 19. They are short, and each has a plain answer a builder can give without technical knowledge.

Question	What it asks	Why it matters
1. Who uses it?	Only me, my team, several units, or people outside the organisation	The more people rely on it, the more a failure costs and the more someone else must be able to run it
2. What data does it touch?	None or public, internal, personal data, special categories of personal data	Personal data engages data protection law; special categories engage its strictest rules
3. What can go wrong?	Wrong information, a wrong message to a person, money, an action that cannot be undone	The consequence, not the code, decides how careful the build must be
4. Which law applies?	Data protection, the AI Act, sector rules, public-law duties, employment rules	Law gives the organisation duties that the build can help to meet or breach
5. Does it run unattended?	Only when I run it, or on a schedule or trigger without anyone watching	A failure nobody sees goes on until someone happens to find it

The answers are not opinions. Each is given with its source: a data field list, a conversation with the unit head, a reading of the notices spreadsheet. An answer given from memory is an assumption, and Chapter 5 showed how often memory fills a gap with a plausible statement.

Four tiers and what changes

The tiers follow AI Developer, Chapter 19, and are restated here in full because the rest of the book relies on them. The definitions are the book's own.

Tier	Test	Who answers for it	Example
A personal	Used only by the builder; no personal data of others; no write access to shared systems	The builder	A macro that reformats the builder's own weekly figures
B team	Used by colleagues in one unit; internal data only; no personal data of people outside the team	The line manager, with the builder named	A script that compares three internal lists on demand for one team
C business	Personal data of citizens, customers or staff; money; a record of the organisation; more than one unit; or unattended running	A named owner and a deputy	A tool that reads claims data and drafts messages to claimants
D project	Ranks or decides about a named person; is or feeds a high-risk AI system; touches a security-critical path; or acts irreversibly on production data	The development organisation, as for any project	A rule list that orders a queue of applicants for a benefit

What changes with the tier is how much of each later step applies; Chapter 4 gives the proportion table for all twelve steps and each step chapter its own row. Tier A needs the builder's own care and a note. Tier B needs the record, tests, a named deputy and a review. Tier C needs everything the book describes, including a developer who has taken the build over in the takeover test. Tier D is not built by a builder.

Crossing signals. A build is not classified once. AI Developer, Chapter 19, observed that a prototype becomes production by use: a second unit begins to rely on it, personal data of people outside the team enters it, or it begins to run unattended. Any of the three moves the build to Tier C, and each can happen without anyone deciding. A tier decision therefore records its expected crossing signals in advance and names who watches for them, which is why a Tier B decision carries a review date.

Tier D: the stop signs

Four things make a build a project for the development organisation. They are the Level 4 prohibitions of Chapter 4 applied to a different kind of builder, and they are stop signs, not warnings.

It ranks or decides about a named person. A build that scores, orders, flags or decides about a named person's employment, pay, performance, access to work, benefits or services is a decision about a person, however much a human is said to review its output. Delegation moves work and never ownership (86, Nordqvist, 2026).

It is or feeds a high-risk AI system. A build that is an AI system in an area the AI Act lists as high-risk, or whose output is an input to one, is a high-risk matter whatever tool wrote it. The screening is explained below.

It touches a security-critical path. Authentication, authorisation, cryptography, payment, and clinical or life-safety logic need review by a named developer whoever wrote the code.

It acts irreversibly on production data. A build that deletes, overwrites, sends or pays in a way that cannot be undone, against real data, has a cost of failure that testing cannot cover.

Stopping at a stop sign is not a failure of the builder. It is the most useful thing the step can produce: a dated statement that the need is real and belongs to the development organisation. The intent from Chapter 5 becomes the first page of a project brief.

Law in plain terms

Three bodies of law reach a builder at this step: data protection law, the AI Act and the rules specific to the organisation's sector; employment law joins them when a build records or measures staff. Each part says what the law asks of the organisation and what that implies for the build, paraphrasing and attributing each statement to the article.

What was checked. The article numbers of the General Data Protection Regulation (GDPR), Regulation (EU) 2016/679 (4, European Union, 2016), and of the Artificial Intelligence Act, Regulation (EU) 2024/1689 (1, European Union, 2024), were checked sentence by sentence on 14 November 2026 against the authentic text held in the Publications Office repository (Cellar); for the AI Act the text is the consolidated version of 27 July 2026, which includes the amendments made by Regulation (EU) 2026/1744 (5, European Union, 2026). The articles are paraphrased, and the editor should confirm any phrase in quotation marks. The guidelines on impact assessments were read in full (16, Article 29 Data Protection Working Party, 2017).

Data protection law: the General Data Protection Regulation

When it applies. The GDPR applies to the processing of personal data. Personal data is any information relating to an identified or identifiable natural person (Article 4(1)), and processing is nearly anything done with it, including reading, storing, listing and sending (Article 4(2)). Removing names does not take data outside the Regulation: pseudonymisation is a safeguard (Article 4(5)), and pseudonymised data that could be attributed to a person by using additional information remains personal data (recital 26). A claim number, case number or employee number is therefore personal data when the organisation can look up whose it is.

Who has the duties. The duties fall on the controller, the body that, alone or with others, determines the purposes and means of processing (Article 4(7)). In the builds of this book that is Nordvik Region or Hansa Mutual, not the builder personally. A builder cannot decide on the organisation's behalf to process data for a new purpose. The decisions about personal data are not the builder's to take alone, and the data protection officer is the person the organisation has appointed to advise on them.

Principles that shape a build. Article 5(1) sets out the principles of processing: it is lawful, fair and transparent; its purpose is specified and not extended; it is limited to what is necessary (data minimisation); the data is accurate; it is kept in identifiable form no longer than necessary (storage limitation); and it is processed securely. Article 5(2) makes the controller responsible and able to demonstrate compliance. The purpose in the intent of Chapter 5 is the purpose the data is processed for, and using the output for another purpose is a new decision. The build reads only the fields it needs: a tool that checks which documents a claim lacks has no use for a claimant's name. The build has a sunset date, because data kept for a tool that no longer runs breaches storage limitation.

Design and default. Article 25(1) requires appropriate measures, such as pseudonymisation, when deciding how processing will be done and during it; Article 25(2) requires that, by default, only personal data necessary for each specific purpose are processed. The build is designed to read the least data that will do, a decision made at Step 5 and first noticed here.

Security. Article 32(1) requires technical and organisational measures appropriate to the risk, including regular testing of their effectiveness. A secret pasted into an unapproved assistant or an export left in a shared folder is an Article 32 question if personal data is reachable; Chapter 12 takes this under Step 8 Secure.

Outside providers. Where a provider processes personal data on the controller's behalf, Article 28(1) requires the controller to use only processors that give sufficient guarantees, and Article 28(3) that the processing is governed by a contract. The rule for a builder is plain: personal data goes only to services the organisation has approved and contracted, and an assistant the builder found alone is not one. Hence the builder describes the problem to the assistant without pasting data in.

Impact assessment. Article 35(1) requires an assessment of the impact of the envisaged processing, before it begins, where a type of processing is likely to result in a high risk to the rights and freedoms of natural persons. Article 35(3) names three cases in which one is in particular required: systematic and extensive profiling-based evaluation on which decisions with legal or similarly significant effect rest; large-scale processing of special categories of data; and large-scale systematic monitoring of a publicly accessible area. Article 35(2) requires the controller to seek the data protection officer's advice, and Article 35(4) has each supervisory authority publish a list of processing that requires an assessment. The Article 29 Working Party, predecessor of the European Data Protection Board, set out nine criteria for judging likely high risk: evaluation or scoring; automated decisions with legal or similar significant effect; systematic monitoring; sensitive data; large-scale processing; matching or combining datasets; data on vulnerable data subjects, expressly including employees; innovative use of technology; and processing that prevents people from exercising a right or using a service or contract. In most cases processing that meets two criteria requires an assessment, and sometimes one is enough (16, Article 29 Data Protection Working Party, 2017). The guidelines are guidance, not law. The builder gives the data protection officer the intent, the field list and the criteria the build touches, and the officer decides and records whether an assessment is needed.

Special categories. Article 9(1) prohibits the processing of personal data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs or trade union membership, of genetic or biometric data used to identify a person, and of data concerning health or sex life or sexual orientation, unless a condition in Article 9(2) applies. Personal-injury claims are the plain example in insurance. The cheapest control is to keep such data out of what the build reads; a build that processes it has a different tier, a decision by the data protection officer on Article 9(2) and probably an impact assessment under Article 35(3)(b).

Who to involve. Public authorities must designate a data protection officer (Article 37(1)(a)), as must other controllers whose core activities meet the conditions in Article 37(1)(b) and (c); Hansa Mutual has one at group level. The officer's tasks include advising on the impact assessment and monitoring its performance (Article 39(1)(c)). The rule of this book follows: any build that touches personal data of people outside the team is Tier C, and its tier decision is not finished until the data protection officer has screened it.

The AI Act: screening for high-risk

The AI Act asks three questions in order, and a builder can take the first two and must leave the third to the organisation.

Is the build an AI system? Article 3(1) defines an AI system as a machine-based system designed to operate with varying levels of autonomy that infers, from the input it receives, how to generate outputs such as predictions, content, recommendations or decisions. Inference carries the definition. A program that applies rules which people wrote down and checked is not, on the book's reading, an AI system, although the Commission's guidelines on the definition settle doubtful cases and were not read for this book. Both builds are of that kind. Whether using an assistant to write code engages any provision of the Act is an open question that AI Developer, Chapter 24, flagged and this book does not resolve; the screening concerns what the build is and does. A build that calls a model at run time, for example to read free text or to rank, is an AI system, and the builder needs the development organisation.

What is the organisation's role? The Act assigns duties to the provider, which develops an AI system or has it developed with a view to placing it on the market or putting it into service under its own name (Article 3(3)), and to the deployer, which uses it under its own authority (Article 3(4)). An organisation that has an AI system built for its own use and puts it into service is its provider, and a deployer becomes the provider of a high-risk system by changing the intended purpose of a system so that it becomes high-risk (Article 25(1)(c)). Building an AI system does not make the builder a provider; it makes the organisation one.

Is it in a high-risk area? An AI system is high-risk if it is a safety component of a product covered by the Union legislation in Annex I, or itself such a product, and subject to third-party conformity assessment (Article 6(1)), or if it is a use listed in Annex III (Article 6(2)). Annex III has eight areas: biometrics; critical infrastructure; education; employment and workers management; access to essential private and public services and benefits, including eligibility for public benefits and, within insurance, risk assessment and pricing for life and health insurance; law enforcement; migration, asylum and border control; and justice and democratic processes. Under Article 6(3) an Annex III system may be treated as not high-risk if it poses no significant risk of harm, for example by performing a narrow procedural task, but one that profiles natural persons is always high-risk, and a provider relying on the exception must document its assessment before the system is placed on the market or put into service and is subject to the registration obligation (Article 6(3) and (4)). A build that is, or feeds, a system in one of these areas is Tier D. AI Developer, Chapter 19, gave a Nordvik Region example: a rule list built to order a queue of benefit verifications by urgency ranked applicants for a benefit (Annex III, point 5(a)), and was reclassified as Tier D and taken into the route for AI systems (86, Nordqvist, 2026).

When. The requirements for Annex III systems apply from 2 December 2027 as amended by Regulation (EU) 2026/1744 (5, European Union, 2026), within the life of a build whose sunset runs to 2033.

Sector rules and public-law duties

The third body of law depends on who the organisation is. A short list shows how it enters the tier decision.

For a financial entity such as an insurer, DORA, Regulation (EU) 2022/2554, sets rules on ICT third-party risk in Articles 28 to 30, including a register of information on contractual arrangements (2, European Union, 2022); the builder again uses only services the group has approved. For an entity under NIS 2, Directive (EU) 2022/2555, the build runs inside its cybersecurity risk management (3, European Union, 2022), which affects Step 8, not the tier. A public authority that publishes a website or app to residents falls under the accessibility rules of Directive (EU) 2016/2102 for what it publishes (11, European Union, 2016), and its records officer decides what must be kept. A build that records or measures staff engages the employer's duties to employee representatives, such as section 87 of the German Betriebsverfassungsgesetz (7, Germany, n.d.) and, in Sweden, the duty of an employer bound by a collective agreement to negotiate with the union before an important change of operations or of working conditions, and on request before other decisions concerning a member (sections 11 and 12 of the co-determination act; section 10 gives the right to negotiate) (8, Swedish Parliament (Sveriges riksdag), 1976); a builder never decides alone to measure staff.

What vibe coding does instead

The default of vibe coding is to treat everything as a prototype until it is not. The builder begins without asking who will use the result or what data it touches, because a prototype is cheap. The weakness is that the point at which a prototype becomes something people rely on is not marked: a colleague asks for a copy, a second unit starts to use it, someone connects it to a real export, and the build is in production without anyone having decided so. AI Developer, Chapter 19, made this observation about citizen builds: use, not code, is the line (86, Nordqvist, 2026).

The evidence on what is then found is thin and indirect. A 2026 preprint audited 200 publicly deployed applications drawn from 9,041 open-source applications built with two AI coding tools and reported 1,186 vulnerabilities, with 91.0 per cent of the audited applications having at least one and 65.77 per cent of the vulnerabilities rated Critical or High, clustered in broken access control, injection and authentication failures (109, Deng et al., 2026). The applications were deployed publicly, not internal tools, the figures come from the abstract and the study is not peer reviewed. It supports a limited point: AI-built applications that reach users carry flaws that a tier-appropriate check looks for. Panko's audits of real organisational spreadsheets found errors in a high proportion of those checked (106, Panko, 2000), whose figures are in Chapter 5,, which suggests that the maker's own sense of risk is not a reliable classifier. The book's conclusion is its own: tiering makes the decision about care before the build exists, in writing, and not by drift.

How AI helps and where it misleads

The assistant helps in three ways at this step, supplying questions and drafts, not decisions. It lists the questions a careful person would ask about users, data, harm, law and unattended running, and can point out a field in an example export that looks like personal data. It drafts the tier record from the builder's answers, which the builder checks against their sources. And it explains in plain language what an impact assessment is, which helps as orientation and misleads as authority.

Where it misleads, the failures follow from how such tools behave. An assistant may state the law with confidence it has not earned, and a plausible summary of an article can be wrong in the detail that matters, such as whether an exception applies; the builder reads the instrument or asks the data protection officer. Models trained on human feedback tend to match the view the user has put, and Sharma and colleagues found this across several assistants and settings (43, Sharma et al., 2023); a builder who asks "this is just an internal tool, so Tier A, right?" has asked it to agree. State the facts and ask for the questions, not the verdict. An assistant cannot know what is in the builder's data, and asked whether fields are personal it answers from the column names. It will not volunteer that something left out, such as a free-text column, is the risk. The tier decision has two owners besides the builder: the line manager and, for personal data, the data protection officer.

Proportion: what each tier needs

The table sets out what Step 2 itself needs at each tier. The proportion of the later steps is in Chapter 4 and in each step chapter.

Tier	The tier decision	Who is consulted	Who approves	Review
A personal	The five answers in the builder's head; a one-line note that it stays personal and what would change that	Nobody	The builder	When anyone else asks to use it
B team	The five answers with their sources in the build record; crossing signals named	The deputy; the unit head where the unit's data is used	The line manager	Every 90 days, and when any crossing signal occurs
C business	The five answers with sources, the crossing signals that applied, the law screened; the data protection officer's screening attached where personal data is involved	The data protection officer; a named developer; the owner and deputy are named	The line manager and the unit head; the data protection officer's decision is recorded	Every 90 days, and at each change of data, users or schedule
D project	The stop sign and the reason, recorded; the build is handed over	A developer; the data protection officer where personal data or a person is concerned	The sponsor and the development organisation	Not applicable; the build becomes a project

Practical guide: Classifying a build

Practical guide: Classifying a build and recording the tier decision

Purpose. Decide, in writing and with evidence, how much structure the build needs, say what would change the decision, and bring in the people who must be involved before any data is touched.

Roles.

The builder answers the five questions and writes the record.
The deputy checks the answers against their sources, and the line manager approves the tier.
The data protection officer screens any build that touches personal data of people outside the team, and decides whether an impact assessment is needed.
A developer is named for Tier C and consulted for any doubt about a stop sign.

Inputs. The intent from Chapter 5; a list of the data fields the build will read, with an example of each that is synthetic or has been made safe; knowledge of who will use the result; the unit's own list of its systems and their owners.

Steps.

Answer the five questions with sources. For each answer write where it comes from: the field list, the unit head, the system owner. An answer without a source is marked as an assumption.
Check the stop signs. Does the build rank or decide about a named person, feed or constitute a high-risk AI system (use the screening above), touch authentication, authorisation, cryptography, payment or clinical logic, or act irreversibly on production data? One yes ends the citizen build.
Check the crossing signals. Will more than one unit use it, is personal data of people outside the team, money or a record of the organisation involved, will it run unattended? One yes makes it Tier C.
Run the classifier. The script below applies the book's definitions to the answers and prints the tier, the signals and who to call. It is an aid, and its output is only as good as the answers.
Name what would change the decision. Write the crossing signals you expect, such as a planned schedule or a second unit, say who watches for them and what happens when one occurs. The tier is re-decided before a signal occurs, not after.
Involve the data protection officer. If the build touches personal data of people outside the team, send the officer the intent, the field list and the nine criteria answered, with the question of scope. Send no data. The officer's decision, including any narrowing of scope and whether an impact assessment is needed, is attached to the record.
Decide, record and approve. Write the decision in the build record. The line manager approves in writing. Where the tier is C, name the owner, the deputy and the developer who will receive the build.
Set the review. Record the decision date and a review date at most 90 days later. Evidence that a build is Tier B on 2031-09-11 does not show it is Tier B on a later date.

Exit gate. The gate is met when the build record contains a tier decision with the five answers and their sources, the stop signs checked and none found (or, if one was found, the handover note and the end of the citizen build), the crossing signals named with a person who watches, the line manager's approval and a review date, and, for Tier C, the data protection officer's screening attached and a developer named. The gate is not "when you feel ready".

Artefact. The tier section of the build record BLD-*, with the data protection officer's screening attached where it applies. The form is shown with the Hansa Mutual build.

tier:
  decided: 2031-09-18
  answers:
    users: team
    data: personal
    money: false
    organisational_record: false
    unattended: false
    ranks_or_decides_about_a_named_person: false
    feeds_a_high_risk_ai_system: false
    security_critical_path: false
    irreversible_on_production_data: false
  sources:
    data: Export columns claim_id, claim_type, doc_types_received, country, language
    users: Pilot team, one centre, handlers only
  decision: C
  reason: Claim identifiers are linkable to claimants; several handlers use it
  not_d: >-
    Ranks no person, decides nothing, does not feed a high-risk AI system;
    the handler decides and sends
  scope: Motor property-damage claims; injury claims excluded, see screening
  screening:
    by: Dr. Sabine Vogel, group data protection officer
    date: 2031-10-20
    result: Scope limited to property damage; no impact assessment required
    decision_record: AIDR-1251
  watch_for:
    - signal: free-text fields or injury claims added to the export
      who: Katarzyna Nowak
      action: Stop and re-decide with the data protection officer
    - signal: a second centre or market asks to use it
      who: Joanna Kaczmarek
      action: Re-decide before they do
  approved_by: Joanna Kaczmarek
  review_by: 2031-12-17

The classifier is a short Python script that reads the five answers and the four stop signs from the tier section of the build record and applies the definitions in the table of tiers above.

"""Step 2: classify a build from the five answers. A decision aid, not a ruling."""
import sys

import yaml

STOP_SIGNS = {
    "ranks_or_decides_about_a_named_person": "ranks or decides about a named person",
    "feeds_a_high_risk_ai_system": "is or feeds a high-risk AI system",
    "security_critical_path": "sits in a security-critical path",
    "irreversible_on_production_data": "acts irreversibly on production data",
}


def classify(answers: dict) -> dict:
    stops = [text for key, text in STOP_SIGNS.items() if answers.get(key)]
    if stops:
        return {"tier": "D", "signals": stops,
                "call": ["a developer", "the data protection officer"]}
    signals = []
    if answers["data"] in ("personal", "special"):
        signals.append("personal data of people outside the team")
    if answers.get("money"):
        signals.append("money")
    if answers.get("organisational_record"):
        signals.append("a record of the organisation")
    if answers["users"] in ("units", "public"):
        signals.append("more than one unit")
    if answers.get("unattended"):
        signals.append("unattended running")
    call = []
    if answers["data"] in ("personal", "special"):
        call.append("the data protection officer")
    if answers["data"] == "special":
        call.append("a developer, before anything is built")
    if signals:
        return {"tier": "C", "signals": signals, "call": call or ["a developer"]}
    if answers["users"] == "team" or answers["data"] == "internal":
        return {"tier": "B", "signals": ["colleagues in one unit use it"], "call": []}
    return {"tier": "A", "signals": [], "call": []}


if __name__ == "__main__":
    with open(sys.argv[1], encoding="utf-8") as handle:
        data = yaml.safe_load(handle)
    result = classify((data.get("tier") or data)["answers"])
    print(f"Tier {result['tier']}")
    for signal in result["signals"]:
        print(f"  signal: {signal}")
    for who in result["call"]:
        print(f"  call: {who}")

Saved as tier.py and run with python tier.py docs/build-record.yaml on a build record whose tier section is the one above, it prints Tier C, the signal personal data of people outside the team and the instruction to call the data protection officer. Change ranks_or_decides_about_a_named_person to true and it prints Tier D and tells the builder to call a developer and the data protection officer. The script encodes the book's definitions and nothing more. It does not know the law, it cannot read the data and it accepts the answers it is given; the gate lies in the sources written beside the answers and in the people who approve them.

The two builds at this step

Hanna Wikström and service-point-check

Hanna Wikström decided the tier of service-point-check on Thursday 2031-09-11, the day after the intent was approved. The users were the e-services team, one unit, with a weekly report that service-point managers would read. The data were the opening hours and notices of 24 service points: the portal export is public by design, the phone-service script and the notices spreadsheet are internal. The tool takes no action, so a wrong line in its report is read by a person before any source is corrected. Data protection was not the law in focus, because none of the sources holds personal data of residents; Elin Berg read the free-text column of the notices spreadsheet for names and contact details of private persons and found none, and the record says that the check expires if the use of the column changes. The tool would run on demand, started by Hanna.

No stop sign applied: the tool ranks no person, is not an AI system, touches no security-critical path and writes nothing. No crossing signal applied on 2031-09-11, so the tier was B. The decision named two signals in advance: a schedule, which version 0.2.0 was planned to introduce, and use by service-point managers in other units. It says that Tier C applies from the day either occurs, that the tier is re-decided before it does, and that Hanna watches for both. Gunilla Roos approved the decision. Chapters 15 and 16 describe what Tier C then brings.

Gate status recorded in BLD-NR-2031-0001: Step 2 met on 2031-09-11; Tier B; no stop sign; crossing signals named (schedule, use in other units); approved by Gunilla Roos; review by 2031-12-10.

Katarzyna Nowak and claims-doc-check

Katarzyna Nowak decided the tier of claims-doc-check on Thursday 2031-09-18, the day after the intent was approved, and it was Tier C from the start. The users were the handlers of one pilot team in the Polish service centre. The data were five columns of a claims export: claim identifier, claim type, document types received, country and language. The identifier is the point: the group can look up whose claim it is, so the export is personal data of claimants even with no name in it (Article 4(5) of the GDPR does not change that). A wrong result would cost time but no money, because the handler reviews every draft before it is sent. The law in focus was the GDPR and the group's DORA arrangements for third-party services, which meant using only the assistant and pipeline the group had approved.

No stop sign applied: the tool ranks no person, decides no claim, does not feed a high-risk AI system (Annex III lists risk assessment and pricing for life and health insurance, and a motor property-damage claim is neither) and writes nothing to the claims core. Personal data of claimants was a crossing signal in itself, so the tier was C. One question stayed open on 2031-09-18: whether motor injury claims were in scope. Katarzyna had moved them out of the intent because their files hold health data. She recorded the question and asked the group data protection officer to screen the build.

Dr. Sabine Vogel, the group data protection officer, screened it on Monday 2031-10-20, working from the intent, the five columns and the nine criteria. For the narrowed scope she found none of the criteria met in a way that made high risk likely: no scoring of people, no decision with legal effect, no special categories, a small pilot scale and a handler who decides. Injury claims must stay out, because their files hold data concerning health (Article 9(1)); the group would need a condition under Article 9(2) and probably an impact assessment under Article 35(3)(b). No impact assessment was required for the narrowed scope. The decision is AIDR-1251, attached to the build record, and Joanna Kaczmarek approved the tier. Two signals were named for watching: free-text fields or injury claims added to the export, and a second centre or market asking to use the tool.

Gate status recorded in BLD-HM-2031-0001: tier decision made 2031-09-18, Tier C; Step 2 gate met on 2031-10-20 when the data protection officer's screening was attached; scope limited to motor property-damage claims; AIDR-1251; approved by Joanna Kaczmarek; review by 2031-12-17.

Across the degrees of delegation

The table sets out what the builder's assistant may do at this step. Both builders used the conversational assistant their organisation approved, at Mode 1 Conversational assistants, with no data.

Work at this step	Usage mode	Degree of delegation	Condition
List the questions about users, data, harm, law and unattended running	Mode 1 Conversational assistants	Level 1 Assisted	The builder answers each from a source
Draft the tier record from the builder's answers	Mode 1 Conversational assistants	Level 1 Assisted	The builder checks each line against its source
Explain a legal term or paraphrase an article in plain language	Mode 1 Conversational assistants	Level 0 Advisory	The builder reads the article or asks the data protection officer; the explanation is not a source
Say whether a change creates a crossing signal	Mode 1 Conversational assistants	Level 0 Advisory	The builder decides
Decide the tier, screen personal data, rule on an impact assessment or approve the record	Not delegated	Not delegated	The builder proposes; the line manager approves; the data protection officer decides on data
Classify a build as not high-risk under the AI Act	Not delegated	Not delegated	The organisation and, where needed, counsel; a builder does not make this call

Level 4 Autonomous does not apply, because the assistant takes no action at this step. The prohibition that governs the step is the one on a decision about a named person: a build that would rank or decide about a named person's employment, pay or access to work is Tier D, and the assistant is not used to talk the builder out of it. The stewardship tests apply to the record. Name: the builder, deputy, approving manager and, for Tier C, the data protection officer and developer are named. Understand: the builder can say without the assistant why the build has its tier and what would change it. Revert: a tier decision is changed by an edit that shows who changed it and why, and a build that crosses a signal is reclassified before it goes on.

Nordvik Region and Hansa Mutual

The two decisions differ in what carried the tier. Nordvik Region's service-point-check was Tier B as an on-demand tool on public and internal data for one team, and the decision's value lay in the two signals it named in advance, which made a later promotion a planned event. Hansa Mutual's claims-doc-check was Tier C from the first day because identifiers could be traced to claimants, and the decision's value lay in the data protection officer's screening, which narrowed the scope and recorded why injury claims stayed out.

In both builds the stop signs were checked and none found, and a person other than the builder decided: Gunilla Roos for the Region, Joanna Kaczmarek with Dr. Sabine Vogel for the group. In the Region the tier turned on use, in the group on data.

When to call a developer

Call a developer, and for personal data the data protection officer, when the tier decision shows any of the following. These are the stop signs of this step.

Any Tier D sign. The build ranks or decides about a named person, is or feeds a high-risk AI system, touches a security-critical path or acts irreversibly on production data. Stop, record the reason and hand the need to the development organisation as a project.
The build calls a model at run time. It is then an AI system, and the organisation's duties as provider or deployer need the development organisation and probably the data protection officer.
Special categories of personal data are involved or likely. Keep them out of what the build reads, or ask the data protection officer and a developer before building.
The build measures or records staff. Employee representatives and the employer's rules come first.
A crossing signal has occurred or is about to. Someone in another unit asks to use the build, an export gains a column, a schedule is proposed. The tier is re-decided with the line manager, the owner and a developer before the signal takes effect.
You are being pressed to say it is smaller than it is. The decision to lower a tier is made in writing by the line manager and, for personal data, the data protection officer.

Saying no, or stopping at Tier A, is professional.

Observable, expected, speculation

Observable. The four tiers are those of AI Developer, Chapter 19; the five questions and crossing signals are this book's application of them. The articles cited exist in the Official Journal text in the numbering used here, and the Article 29 Working Party guidelines set out the nine criteria (16, Article 29 Data Protection Working Party, 2017).

Expected. The requirements for Annex III high-risk systems apply from 2 December 2027 as amended by Regulation (EU) 2026/1744 (5, European Union, 2026): decided law with a date ahead. That supervisors will expect an organisation to show how it classified a build is expected, because the instruments assign duties to the controller, provider and deployer whoever wrote the code.

Speculation. That a regulator would accept a builder's tier decision as evidence of compliance is speculation; the decision is an internal record, not an assessment under any instrument. That many builds cross from Tier B to Tier C by use is also speculation; no study read for this book measures it. The author's own projections are kept to Chapters 20 and 25.

Summary

Step 2 Tier asks the builder to decide, before designing, how much structure the build needs, from five questions: who uses it, what data it touches, what can go wrong, which law applies and whether it runs unattended. The chapter concerns D1 Frame and D2 Design. The answers place the build in one of four tiers, Tier A personal, Tier B team, Tier C business and Tier D project; four stop signs end the citizen build and make it a project for the development organisation, and crossing signals move a build to Tier C by use, not by decision. Saying no, or stopping at Tier A, is professional.

The chapter explained what the GDPR asks of the controller (Articles 4, 5, 9, 25, 28, 32, 35, 37 and 39) and what follows for a build: personal data includes any identifier the organisation can trace, the builder acts inside the organisation's duties, the build reads the least data that will do, personal data goes only to approved services, and the data protection officer screens any build that touches personal data of people outside the team. It set out the AI Act's three screening questions, the third of which is not the builder's to answer, and the sector and public-law duties that enter the decision. None of it is legal advice.

The practical guide produces the tier section of the build record. Its gate is met when the five answers carry their sources, the stop signs are checked, the crossing signals are named with a person who watches, the line manager approves, a review date is set and, for Tier C, the data protection officer's screening is attached and a developer named. Hanna Wikström's build was Tier B on 2031-09-11, with a schedule and use in other units named as signals. Katarzyna Nowak's build was Tier C from 2031-09-18, and its gate was met on 2031-10-20 when Dr. Sabine Vogel's screening narrowed the scope to motor property-damage claims (AIDR-1251).

Chapter 7 takes the next step, Step 3 Workshop: preparing the place where the build is made, and the mandate that sets what the assistant may do there.

Sources

European Parliament and Council of the European Union. Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). Official Journal of the European Union, 12 July 2024. (1, European Union, 2024)
European Parliament and Council of the European Union. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). Official Journal of the European Union, 27 December 2022. (2, European Union, 2022)
European Parliament and Council of the European Union. Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union (NIS 2 Directive). Official Journal of the European Union, 27 December 2022. (3, European Union, 2022)
European Parliament and Council of the European Union. Regulation (EU) 2016/679 (General Data Protection Regulation). Official Journal of the European Union, 4 May 2016. (4, European Union, 2016)
European Parliament and Council of the European Union. Regulation (EU) 2026/1744 amending Regulations (EU) 2024/1689, (EU) 2018/1139 and (EU) 2023/1230 as regards the simplification of the implementation of harmonised rules on artificial intelligence (Digital Omnibus on AI). Official Journal of the European Union, 24 July 2026. (5, European Union, 2026)
Federal Republic of Germany. Betriebsverfassungsgesetz (BetrVG), section 87. Federal Ministry of Justice. (7, Germany, n.d.)
Swedish Parliament (Sveriges riksdag). Lag (1976:580) om medbestämmande i arbetslivet, sections 10 to 12. (8, Swedish Parliament (Sveriges riksdag), 1976)
European Parliament and Council of the European Union. Directive (EU) 2016/2102 on the accessibility of the websites and mobile applications of public sector bodies. Official Journal of the European Union, 2 December 2016. (11, European Union, 2016)
Article 29 Data Protection Working Party. Guidelines on Data Protection Impact Assessment (DPIA) and determining whether processing is "likely to result in a high risk" for the purposes of Regulation 2016/679 (WP 248 rev.01). Adopted 4 April 2017, as last revised and adopted 4 October 2017. (16, Article 29 Data Protection Working Party, 2017)
Sharma, M., Tong, M., Korbak, T., et al. Towards Understanding Sycophancy in Language Models. arXiv:2310.13548, 2023. (43, Sharma et al., 2023)
Panko, R. R. Spreadsheet Errors: What We Know. What We Think We Can Do. Proceedings of the EuSpRIG Spreadsheet Risk Symposium, 2000. (106, Panko, 2000)
Deng, J., Fan, Z. & Meng, R. Understanding the (In)Security of Vibe-Coded Applications. arXiv:2606.23130, 2026. (109, Deng et al., 2026)
Nordqvist, G. AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. The Transformed Architecture, Book 2. (75, Nordqvist, 2026)
Nordqvist, G. AI Developer: How the Developer Role Changes When AI Is Used Broadly in European Enterprises and Public Authorities. The Transformed Architecture, Book 12. (86, Nordqvist, 2026)