Intellectual Property, Open Source and Sovereignty in the Toolchain

This chapter treats three questions that every development organisation inherits when AI enters its toolchain: who holds the rights in what the toolchain produces, what the toolchain rests on, and what the organisation can do if a part of it must be replaced. It concerns three of the five developer functions. D2 Design is where the choices are made and recorded: which model, which licence, which hosting, which exit. D3 Build is where generated code enters the repository and where a licence problem starts. D5 Steward is where the organisation lives with the consequences for years. Legal statements are attributed to the instrument and article and framed as organisational and architectural implications, not legal advice. Chapter 24 maps the wider regulation of the toolchain and Chapter 18 treats procurement and public code; this chapter takes the rights and the dependencies.

Figure 26.1: The toolchain dependency map. The gateway, the licence and provenance checks and the exit route are held outside the assistant; the record joins them and has a named owner and a review date.

The thesis, drawn in the Summary, is plain: a dependency nobody recorded is one nobody decided, and a right nobody checked is one the organisation only hopes it has. The stewardship principle of Chapter 4, Name, Understand and Revert, applies to the supply side of the toolchain as to code.

Copyright in generated code

The question that developers ask first is whether anyone owns what an assistant generates. The honest answer is that European law answers it only by implication, that the answer turns on the human contribution, and that no court has ruled on it for code.

Authorship and ownership

Directive 2009/24/EC on the legal protection of computer programs protects a computer program by copyright as a literary work. A program is protected if it is original "in the sense that it is the author's own intellectual creation", and ideas and principles underlying any element of it, including its interfaces, are not protected (Article 1(2) and (3)). The author is "the natural person or group of natural persons who has created the program" or, where the law of a Member State permits, a legal person designated as the rightholder (Article 2(1)). Where an employee creates a program in the execution of their duties or on the employer's instructions, the employer alone may exercise the economic rights unless the contract provides otherwise (Article 2(3)) (20, European Union, 2009).

Three implications follow, as the book's reading and not a ruling. The directive's test is built on a person: code that a developer selects, edits, integrates and tests is plausibly the developer's own intellectual creation where the developer's choices are expressed, and code accepted whole and unread is a weaker candidate. The employer's entitlement under Article 2(3) attaches to what the employee creates and does not turn machine output into a person's creation. And an organisation that relies on exclusive rights, for example to stop a supplier reusing its code, should not assume that every generated file carries them.

The United States Copyright Office examined the question for copyright generally in January 2025. It concluded that AI tools used to assist human creativity do not affect the availability of protection for the output, that copyright protects the original expression a human contributes even where a work includes generated material, that it does not extend to purely AI-generated material or material where human control over the expressive elements is insufficient, that "prompts do not alone provide sufficient control" with current generally available technology, and that each case turns on its facts (249, United States Copyright Office, 2025). It is United States law and concerns works in general, not software; it is cited because it states the structure the directive implies, that the line is drawn by the human contribution and not by the tool. The sources read for this book show no judgment of a court of a Member State or of the Court of Justice on the copyright status of generated code. Expected: courts in the Union will have to decide the point for some kind of work, and the human-contribution structure is the likeliest frame. Speculation: a separate right in machine output; the Copyright Office found the case for one had not been made.

The practical consequence is modest. The repository records who wrote what, Chapter 12 puts a named owner on every component, and the provenance record PRV-* of Chapter 10 states where AI took part in a change. Those records are also the evidence of human contribution if the organisation must assert rights in a component, so the rule here is to keep the provenance record for any component whose exclusivity matters: code it licenses to others, publishes under a chosen licence or contracts out.

Who owns what the team commissions

Much of the code in the two organisations is written by people who are not employees. Nordvik Region buys about 22 consultant developers through framework agreement NR-2025-102, and Hansa Mutual about 190 external developers, about 110 of them from Wiślana Software under HM-PROC-DEV-2026-02. Article 2(3) gives the employer the economic rights only for employees. For a consultant the position rests on the contract, and a contract written before assistants were in use may say nothing about generated code or about whether the consultant's own assistant retained the client's code. Chapter 10 recorded that NR-2025-102 had no clause on AI tools when a consultant pasted a connection string into an unapproved assistant in March 2030. The remedy belongs in the call-off: an assignment or licence that covers generated material, a list of approved tools, a duty to record AI assistance in the provenance record, and a statement that the supplier's tools do not train on the organisation's code.

Licence contamination

Licence contamination is the arrival in a codebase of code whose licence terms the organisation cannot or will not meet, so that a later obligation, usually one to release source code or to preserve attribution, attaches to a product that was not meant to carry it. It is not new. Developers have long copied code from forums and added libraries with incompatible licences. What AI changes is the number of routes and the visibility of each.

How it arises

The toolchain contributes to each of four routes.

1. Reproduction by the model. A code model can emit passages that match code in its training data. The study LiCoEval measured this for 14 popular models and reported that even the best-performing produced between 0.88 and 2.01 per cent of code that is strikingly similar to existing open-source implementations, and that most of the models failed to provide accurate licence information, particularly for code under copyleft licences (250, Xu et al., 2025). Copyleft is the family of licences that require derivative works to be released under the same terms. The figures come from a benchmark in one study, not from any organisation's repository, and say nothing about whether a similar passage is a copy in the legal sense. They support only this: reproduction is measurable, it is a minority of output, and a model's own statement of a licence cannot be relied on.
2. A dependency that the assistant or agent adds. An agent that proposes a library has chosen a licence along with it. The package-hallucination problem of Chapter 10 is the security face of the same route; the licence is its legal face.
3. Code pasted in by a person, from a chat answer or a forum, with origin unknown; the assistant only makes this route faster.
4. Code leaving. The organisation's own code may be sent to a provider that trains on it, or published by the organisation under a licence chosen without thought. The first is a matter for the contract; the second for the decision to publish (Chapter 18).

Detection and policy

Detection has two layers, and the toolchain can supply the first at the point of generation. Some products offer a setting that suppresses suggestions matching public code. GitHub documents one: with the setting on, Copilot checks each suggestion together with about 150 characters of surrounding code against public code on GitHub and hides suggestions that match or nearly match (251, GitHub (n.d.), n.d.). It is one vendor's control for one product, it does not cover code outside that public corpus, and its absence from another product is a procurement question, not a defect to assume.

The second layer is the organisation's own, and it works on the repository, whatever produced the change. A software bill of materials lists the components in a build with their versions and licences; SPDX is an open standard for this, with a licence list and identifiers, and is recognised as ISO/IEC 5962:2021 (27, SPDX Project & Linux Foundation, 2021). The pipeline produces the bill of materials and Chapter 10 puts it into the provenance record PRV-*; this chapter adds the policy that reads it. A usable policy names licences that are allowed for a class of use, licences that need a named person's approval and licences that are denied. The classes matter: a licence acceptable for an internal tool may not be acceptable for software distributed to brokers or customers, as Hansa Mutual's mobile claims app and broker plug-in are, because obligations of some licences arise on distribution.

licence_policy: LIC-HM-DEV-01
owner: {name: Lukas Frey, role: ROLE-HM-PLT-01}
review_due: 2031-07-31
classes:
  internal-service:
    allow: [MIT, Apache-2.0, BSD-3-Clause, ISC]
    approval_by_named_developer: [MPL-2.0, LGPL-2.1-only]
    deny: [AGPL-3.0-only, SSPL-1.0]
  distributed-to-customers:        # mobile claims app, broker plug-in
    allow: [MIT, Apache-2.0, BSD-3-Clause, ISC]
    approval_by_named_developer: []
    deny: [GPL-2.0-only, GPL-3.0-only, AGPL-3.0-only, LGPL-3.0-only, SSPL-1.0]
on_unknown_licence: block_and_ask_owner
check: {where: hansa-forge pipeline, input: bill of materials, standard: SPDX identifiers}
generated_code: {similarity_scan: true, on_match_over_threshold: human_review_and_record_in_PRV}

The values are illustrative, not a recommendation of particular licences; which licences an organisation can accept is for its counsel. The file makes the position checkable by a pipeline and names an owner, so that the Name test has an answer. The line on_unknown_licence: block_and_ask_owner matters most in an AI-assisted flow, because the code that arrives fastest is the code whose licence nobody has read.

Text and data mining and the AI Act

The tools themselves raise a second rights question, which lies upstream: on what terms were the models trained? A developer organisation is normally a deployer of a coding model, not the party that trained it, but the answer shapes what the provider can promise, and a few organisations will fine-tune or train their own.

Directive (EU) 2019/790 on copyright in the Digital Single Market defines text and data mining as "any automated analytical technique aimed at analysing text and data in digital form in order to generate information which includes but is not limited to patterns, trends and correlations" (Article 2(2)). Article 3 gives research organisations and cultural heritage institutions an exception for scientific research. Article 4(1) requires Member States to provide an exception for reproductions and extractions of lawfully accessible works for the purposes of text and data mining, expressly reaching the reproduction right in computer programs (Article 4(1)(a) and (b) of Directive 2009/24/EC), and Article 4(3) applies it "on condition that the use of works and other subject matter referred to in that paragraph has not been expressly reserved by their rightholders in an appropriate manner, such as machine-readable means in the case of content made publicly available online" (21, European Union, 2019). For lawfully accessible code, a commercial miner may reproduce it for mining unless the rightholder has reserved the right appropriately.

The AI Act adds an obligation on the model side. Providers of general-purpose AI models must "put in place a policy to comply with Union law on copyright and related rights, and in particular to identify and comply with, including through state-of-the-art technologies, a reservation of rights expressed pursuant to Article 4(3) of Directive (EU) 2019/790", and must make publicly available "a sufficiently detailed summary about the content used for training", according to a template from the AI Office (Article 53(1)(c) and (d)). The exemption for free and open-source models in Article 53(2) covers paragraph 1, points (a) and (b), not (c) and (d), and does not apply to models with systemic risk. Recital 106 says a provider placing such a model on the Union market should comply regardless of where the training took place (1, European Union, 2024). Chapter V has applied since 2 August 2025 (Article 113(b)). Article 1 of the AI omnibus, Regulation (EU) 2026/1744, amends other provisions of the AI Act, among them the dates in Article 113 for high-risk systems, and not Article 53 (5, European Union, 2026).

Three implications follow for the development organisation, as the book's reading. A deployer can ask the model provider for the copyright policy and the training summary, and a tender can require them (Chapter 18). A self-hosted open-weight model does not remove the question, since the provider of the weights still has the Article 53(1)(c) and (d) obligations. And an organisation that trains or substantially adapts a model should take advice on whether that makes it a provider; that is for Chapter 24, and the Commission's guidance on it was not verified for this book.

"Open" is used loosely. The Open Source AI Definition 1.0 requires, besides freedoms to use, study, modify and share, that the preferred form for modification include sufficiently detailed information about the training data, the complete source code used to train and run the system, and the parameters (26, OSI, n.d.). A model with published weights and restrictive terms is open-weight and not necessarily open source in that sense, so the licence of the weights is a field in the dependency record.

Litigation as signal

Public cases do not settle what the organisation should do, and a book should not present a single first-instance judgment as the law. They are signals: they show which arguments are being made, where courts hesitate and what may be coming. The four below were read at their primary text or at the court's own summary; where a source was a copy or a press release, the entry in the bibliography says so.

Doe v. GitHub (Ninth Circuit, 16 September 2026). Programmers sued GitHub, Microsoft and OpenAI, alleging that Copilot and Codex reproduced their code without attribution. The complaint had been reduced to one claim under section 1202(b) of the Digital Millennium Copyright Act and two claims for breach of contract. The panel held that the plaintiffs had standing but affirmed dismissal of the DMCA claim: on the "output" theory pleaded, the tools do not remove or alter copyright management information from an existing copy but create new works that never contained it. It treated "identicality" as a gloss on the statute, not an independent element, and declined to consider the "input" theory about training as forfeited. The contract claims, which concern the open-source licences, were pending (245, United States Court of Appeals for the Ninth Circuit, 2026). The signal: whether generated code carries licence obligations is not answered, because the most direct claim failed on its pleading and the licence-based claims continue. It is not Union law.

GEMA v OpenAI (Landgericht München I, 11 November 2025, 42 O 14139/24). A case about the lyrics of nine songs, not code. According to the court's press release, it held that memorisation of the lyrics in the model's parameters is a reproduction under European and German law, that storage as probability values does not change that, that the mining exception in section 44b of the German Copyright Act, the transposition of Article 4, does not cover reproduction of works within the model, and that the operators, not the users, were responsible for infringing outputs. The judgment was not final (246, Landgericht München I, 2025). Only the press release was read, not the judgment, and whether an appeal has been decided was not established. The signal: a court in a Member State has treated memorised content in a model as a reproduction, which bears on the first route to licence contamination, and has read the exception narrowly for that case.

Getty Images v Stability AI (High Court of England and Wales, 4 November 2025). Getty abandoned its claim about training, because it accepted there was no evidence that training took place in the United Kingdom, and its claim about outputs largely fell away once Stability had blocked the prompts used. On secondary infringement the judge held that although an "article" may be intangible, a model that "does not store or reproduce any Copyright Works (and has never done so)" is not an "infringing copy" under sections 22 and 23 of the Copyright, Designs and Patents Act 1988; Getty succeeded in part on trade marks for watermarks generated by users (247, High Court of Justice of England and Wales et al., 2025). It is a first-instance judgment on images under United Kingdom law, and whether it is under appeal was not established. Beside the Munich judgment it shows courts reaching different results on whether a trained model contains the works, on different facts and law: the signal is divergence.

Like Company v Google Ireland (Court of Justice, Case C-250/25). A Hungarian court referred questions on a chatbot's use of press publications, including whether training falls within Article 4 of Directive 2019/790. Advocate General Szpunar proposed on 3 November 2026 that the Court declare the questions on training inadmissible and answer those on press publishers' rights and on retrieval and reuse. He nevertheless discussed the mining exception at length and observed that the definition in Article 2(2) is broad and not confined to analysis of "Big Data". His opinion does not bind the Court, whose judgment was pending (248, Szpunar, 2026). Observable: the case is pending. Expected: a judgment on retrieval and reuse; whether it will settle training is uncertain, because those questions may not be reached. Speculation: a ruling that makes the Article 4 reservation of rights the working rule for training across the Union.

None of the four decides that an organisation using a coding assistant infringes, or that it does not. The exposure of the user is least settled where the organisation does most: accepting generated code into distributed software. Its defence is the process of the previous section, a licence policy, a similarity check and a record, together with contract terms that put obligations on the provider. Whether a provider offers an indemnity for generated output varies by product; No vendor's indemnity was reviewed for this book, and the criteria sheet of Chapter 18 should ask for it and read it.

Open source and maintainers' load

Almost everything the toolchain produces rests on open-source software. The study by Fraunhofer ISI and OpenForum Europe for the European Commission estimated, as the Commission's open source observatory reports, that open source software contributes between EUR 65 and 95 billion to the Union's gross domestic product, and that a 10 per cent increase in contributions would add 0.4 to 0.6 per cent (255, Open Source Observatory & European Commission, 2021). These are model-based estimates from 2021, reported second hand, cited for the order of magnitude only. AI changes the load on those people in two documented ways, and a third is a risk to design for.

The first is the flood of low-quality reports. Daniel Stenberg, lead maintainer of curl, announced on 26 January 2026 that the project's bug-bounty programme would end on 31 January 2026. He wrote that it had confirmed 87 vulnerabilities since April 2019 and paid over USD 100,000, that the share of reports confirmed as real vulnerabilities, above 15 per cent in earlier years, fell below 5 per cent from 2025, and that triaging a flood of AI-generated junk reports took "a serious mental toll" on the team (252, Stenberg, 2026). It is one project's first-hand account. It does not show that AI-assisted reports are worthless; it shows what an unfiltered inflow of machine-written reports does to a small team. A developer organisation that points agents at open-source projects should adopt a rule: a person who has read and reproduced the finding submits it, and the report says that AI took part.

The second is the generated contribution: a project receiving tool-generated pull requests has the review problem of Chapter 9 and does not know the code's licence position. The Region's contribution guide (Chapter 18) therefore asks whether AI assistance was used, a convention of the Region and not a requirement.

The third is an old risk in a new setting: a widely used component maintained by very few people. In March 2024 Andres Freund reported that the upstream xz/liblzma release tarballs contained a backdoor that hooked into the sshd server, recorded as CVE-2024-3094 and present in versions 5.6.0 and 5.6.1 (253, Freund, 2024). The maintainer states on the project's page that only he had had access to the main project website and repositories (254, Collin, 2024). The sources support no conclusion about the maintainers' circumstances, which neither describes. The point is structural: the number of people who can change a component is a property to record, as the number of providers is. An organisation that depends on a component and does nothing for it takes the benefit of other people's unpaid work. The Cyber Resilience Act, which Chapter 24 treats, defines an open-source software steward as a legal person that systematically supports the sustained development of specific products and obliges it to have a cybersecurity policy (Articles 3(14) and 24) (242, European Union, 2024); whether a public authority that publishes code is one is the question Chapter 18 left to Chapter 24.

For the dependency record, this section gives three fields: how many maintainers a critical dependency has, what the organisation does to support it, and who in the organisation reads its security advisories.

Dependence and exit

The toolchain brings a second kind of dependency: on the providers of models and of the services around them. The question is not whether to depend, because every organisation does, but whether the dependency was decided.

Providers

Lock-in accumulates without a decision: where products are incompatible, customers are locked in to early choices and firms compete hard before lock-in to earn power afterwards (110, Farrell & Klemperer, 2007). In cloud services the Competition and Markets Authority found in its decision of 31 July 2025 a highly concentrated infrastructure market (IaaS) in which less than 1 per cent of customers switch provider each year, with egress fees, technical differences and a lack of transferable skills as barriers (109, Competition and Markets Authority, 2025). Coding models are not cloud infrastructure, so the finding does not transfer directly, but the lesson on timing does: the bargaining position is strongest before signature.

AI adds a dependency that a library lacks: the model is retired on the provider's schedule. Anthropic's documentation states that it gives customers with active deployments at least 60 days' notice before retiring a publicly released model (48, Anthropic, n.d.). Microsoft's lifecycle policy for its model catalogue sets 18 months for generally available models, 12 months for those from several publishers including Anthropic and Mistral AI, a notice of at least 60 days, and no extension of retirement dates (47, Microsoft, 2026). Both are current commitments and can change. The model that a team's habits and acceptance statistics were calibrated on will be replaced within a year or two, and the replacement behaves differently, so the record treats a model change as a reviewable event with a re-test of the oracle and of the acceptance claim.

The law supplies levers for some organisations. DORA requires a financial entity to put in place exit strategies for ICT services supporting critical or important functions, which "shall be sufficiently tested and reviewed periodically" (Article 28(8)), and to weigh whether a contract leads to a provider that is not easily substitutable or to multiple arrangements with the same or closely connected providers (Article 29(1)) (2, European Union, 2022). The Data Act requires a written contract for switching between providers of data processing services, with a maximum transitional period of 30 calendar days and support for the customer's exit strategy (Article 25(2)(a) and (b)), and from 12 January 2027 forbids switching charges (Article 29(1)) (7, European Union, 2023). Whether a hosted coding assistant is a data processing service in the Act's sense is a question for counsel. AI Leader (Chapter 26) set out the leader's decision on a strategic dependency; the developer's record is its other half (174, Nordqvist, 2026).

Self-hosted models and European alternatives

Self-hosting an open-weight model changes the dependency and does not remove it. It removes the provider's retirement schedule, the transfer of code to a third party and the foreign-law exposure of a hosted service, though AI Governance (Chapter 6) found that European origin solves legal access only for the layers it covers and that European offerings depend in part on non-European hardware (162, Nordqvist, 2026). It adds others: the organisation carries the capacity, the serving stack, the evaluation and the upgrade path. AI Platform and Security (Chapter 13) set sovereignty as verifiable properties, not a location (163, Nordqvist, 2026); for coding tools they become four questions: where does the code go, under which law does the provider operate, can the model be switched, and can the team keep working if it is withdrawn.

European alternatives exist and the record should treat them as candidates, not answers. Mistral AI, a company based in France, announced the model Devstral on 21 May 2025, built with All Hands AI for software engineering tasks and released under the Apache 2.0 licence, light enough by its account to run on a single RTX 4090 or a Mac with 32 gigabytes of memory (275, Mistral AI, 2025). That is a vendor announcement, cited for the licence and the release, not its capability claims. The Commission's Cloud Sovereignty Framework defines sovereignty objectives and assurance levels for a Commission procurement and is not a legal requirement (8, European Commission, 2025). Whether an alternative performs as well on the organisation's own code is measured, as AI Leader (Chapter 26) concluded: the quality of the alternative on the organisation's own held-out set, and the time and effort of the exit test. A sovereign choice can concentrate as well as free: AI Operations (Chapter 24) concluded that concentration is a property of the dependency graph and not of the number of vendors, and that a stressed exit forced by failure or a legal event and a planned exit chosen for price, quality or jurisdiction are each tested by a restore test whose scenario is the loss of the provider (170, Nordqvist, 2026). A team with a self-hosted assistant on the Region's reserved capacity and a package proxy that serves a single mirror has one dependency on its platform team and one on its registry mirror; Figure 26.1 draws these edges so that they can be seen.

Exit tested

An exit route that has never been used is a hypothesis. The test for a coding assistant is small and carries no risk to production, because the assistant is not in the production path: switch the route at the gateway to the second model, run a fixed set of tasks on a copy of a repository, and measure with an oracle that the assistant did not write (Chapter 9). Three numbers go in the record: the time the switch took, the pass rate against the quality gate and the number of manual steps. The claim "we can leave" then has an age, and the record expires it. The gateway holds the switch and a named person on the platform team holds the right to use it, the stop-path rule of Chapter 4: the stop is held outside the system it stops.

The toolchain dependency and exit record

The record is the artefact of this chapter. It lives in version control beside the contract and the exit-test records, and is read by the tech lead who accepted it and by the supervisor or auditor who asks later. It is an AI Decision Record, AIDR-*, with the fields a toolchain dependency needs, and refers to existing artefacts: the delegation profile, the provenance records and the restore-test records RST-* of AI Operations, Chapter 24.

Practical guide: Recording the dependencies of the coding toolchain with an exit route and a tested alternative

Purpose. To make every dependency of the coding toolchain a decision with a named owner, a licence position, an exit route and a dated test, so that none is held by omission.

Roles. The tech lead (owner of the record), the platform engineer who runs the gateway and package proxy, the architect who owns the dependency map, procurement and legal counsel, the data protection officer where code or prompts contain personal data, the engineering manager, and, where the toolchain logs staff activity, the works-council representative (Chapter 22).

Inputs. The contracts; the delegation profile DLG-*; recent provenance records and bills of materials; the licence policy; the provider's copyright policy and training summary; the last exit test and its date.

Steps. 1. List the dependencies by layer: the editor and its ambient features (Mode 0), the assistant and its model, the agent runtime, the gateway, the package registries and the open-source libraries that matter, and the compute. 2. For each, record the provider or maintainer, the licence or contract terms that bind the organisation, the jurisdiction, the number of people who can change it, and where code and prompts go. 3. Classify it with the three questions of AI Leader (Chapter 26): can it be replaced within a period the team can survive, how much of the team's work passes through it, and can the effect of its failure or change be undone. 4. Name the exit route and the alternative, and say who may invoke the exit and by what mechanism outside the dependency. 5. Test the exit: run the switch and the quality gate, and record the time, the pass rate and the date. If no test exists, the record is conditional on a test by a stated date. 6. Record what the team does for the open-source components it depends on, and who reads their advisories. 7. Name the owner, who must pass Name, Understand and Revert: identifiable, able to explain the choice without an assistant's summary, and able to switch. 8. Set the review date to the earlier of the evidence expiry, a model-retirement notice and a change of terms.

Resulting artefact. The record below.

Worked example (illustrative): Nordvik Region's coding-assistant dependencies

Illustrative; names, dates and values marked as new are fictional. On 10 February 2031 Henrik Dahl, the CIO, records the dependencies of the Mode 2 assistant NR-DEV-001 and of the package proxy, with Gunilla Roos, head of Applications and Integration, accountable for use. The Region prefers European and self-hosted options where feasible, because of its public-access rules and its position on sovereignty, and the record says what it depends on in each choice.

aidr: AIDR-1126
title: Dependencies of the coding assistant NR-DEV-001 and the package proxy
date: 2031-02-10
decider: Henrik Dahl            # CIO
accountable_for_use: Gunilla Roos
delegation_profile: DLG-NR-DEV-01
dependencies:
  - id: model
    what: open-weight coding model, self-hosted on the Region's reserved capacity
    licence: Apache-2.0          # from the publisher's model card; weights only
    copyright_policy_and_training_summary: requested 2031-01-20, received
    code_leaves_region: false
    people_who_can_change: the platform team (seven engineers)
    exit: {route: second open-weight model behind the same serving stack, invoked_by: Maja Lindqvist}
    exit_test: {id: RST-NR-2031-0001, tested: 2031-02-03, switch_time: PT3H, quality_gate: "pass rate 0.86 against 0.90 on 120 tasks", result: failed_quality_gate}
    retest_due: 2031-03-15
  - id: serving-capacity
    what: reserved capacity run by the platform team
    exit: {route: second site or the national shared-service provider, status: study only}
    note: shares a failure domain with identity federation at SamDrift
  - id: ide-ambient-completion
    what: Mode 0 completion in the licensed IDEs
    exit: {route: switch off by policy in the IDE configuration, tested: 2031-01-27}
    decision_history: AIDR-1102
  - id: package-proxy
    what: approved registries only, one mirror
    maintainers_of_critical_libraries_checked: 14
    support_for_open_source: {action: report and fix upstream, owner: Joakim Wester}
licence_position: {policy: LIC-NR-DEV-01, bill_of_materials: SPDX, similarity_scan_on_generated_code: true}
review: {earlier_of: [2031-08-10, model_retirement_notice, change_of_licence_terms, evidence_expiry]}
answerable: {name: Gunilla Roos, understand: "reasons reconstructed from the record and the oracle results, not the assistant's summary", revert: "gateway route and IDE policy"}

The record does three things. It reports a failed test as failed: the second model passed at 0.86 against a gate of 0.90 on the held-out tasks, so the exit stands as a stated route and not as a claim that the team can leave without loss, and the re-test is dated (the figures are illustrative inputs of the book, not benchmarks). It names the shared failure domain behind the capacity and says the second site is a study, not a plan. And it carries ambient completion as history: the IDE vendor's update of March 2030 switched the feature on before anyone decided, and its exit is a tested policy switch.

Worked example (illustrative): Hansa Mutual's hosted assistant under DORA

Hansa Mutual contracts the IDE assistant HM-DEV-001 from CodeMeridian (HM-PROC-AIDEV-2029-01, AIDR-1151), licensed to about 340 developers and testers, with clauses on no training on the group's code, processing in the Union and 30 days' notice of model changes. Code of the claims, health and underwriting products is handled only by self-hosted models in Frankfurt, reached through the Hansa Forge gateway. The contract is on the register of information as a service supporting an important function, so the group's third-party policy requires an exit plan and DORA Article 28(8) requires that it be sufficiently tested. EXIT-004 concerns claims-correspondence classification, not coding tools. On 27 January 2031 the group CIO, Rainer Lehmann, records the position on the proposal of Dr Philipp Reinhardt and Lukas Frey, reviewed by the chief risk officer, Dr Annette Krämer.

aidr: AIDR-1176
title: Exit plan and dependency record for the IDE assistant HM-DEV-001
date: 2031-01-27
decider: Rainer Lehmann         # group CIO
proposers: [Dr. Philipp Reinhardt, Lukas Frey]
reviewer: Dr. Annette Krämer    # chief risk officer
delegation_profile: DLG-HM-DEV-01
dependency:
  provider: CodeMeridian
  contract: HM-PROC-AIDEV-2029-01
  register_of_information: service supporting an important function
  contract_terms: {no_training_on_group_code: true, eu_processing: true, model_change_notice_days: 30}
  reach: {licences: 340, scope: code outside claims, health and underwriting products}
  concentration_check: "no other group service on the same provider; DORA Article 29(1)(b) considered"
exit_plan: EXIT-005
  # new instance of the EXIT family of earlier volumes
exit:
  route: gateway route to the self-hosted model hansa-code-m in Frankfurt
  invoked_by: Lukas Frey
  stop_held_outside_provider: gateway switch in Hansa Forge
  test: {id: RST-HM-2031-0002, tested: 2031-01-19, switch_time: PT2H, quality_gate: "pass rate 0.91 against 0.90 on 150 tasks", result: passed, evidence_age_limit_days: 180}
licence_position: {policy: LIC-HM-DEV-01, generated_code_scan: true}
model_change_rule: "on notice: re-run the oracle and the acceptance claim before the cut-over; AVR-HM-2030-01 restated"
review: {earlier_of: [2031-07-19, model_retirement_notice, change_of_terms]}

Two details matter. The test passed, and the record limits what that means: 150 tasks, the self-hosted model, an age limit on the evidence, and code outside the three products only, since inside them the group already routes to Frankfurt. And the model-change rule links the exit record to the adoption claim: when the provider changes the model, the 42 per cent AI-assisted figure for the claims product line (IDE telemetry, AVR-HM-2030-01, against 27 per cent in a sample of merged pull requests) is restated and does not carry over.

Observable, expected, speculation

Observable: the mining exception with its reservation of rights is in force, and the AI Act's obligations on providers of general-purpose models, including the copyright policy and training summary, have applied since 2 August 2025. Courts have produced diverging decisions, the Court of Justice has a pending reference, maintainers report an inflow of low-quality machine-written reports and providers retire models on published schedules. Expected: procurement documents will more often ask for copyright policies, training summaries and tested exits; licence checks on generated code will move into pipelines as a default. Speculation: a clear rule that settles when generated code carries obligations; a fully sovereign coding toolchain whose every layer is European; a market-wide provider warranty on licence cleanliness.

Across the usage modes

The table gives, for each usage mode, the highest degree of delegation that the starting profiles of the two organisations allow for the part of the toolchain concerned. Level 4 is used for none of them, and never for a change to an agent's own mandate, permissions, credentials, test oracles, review rules or pipeline gates, which includes the licence policy and the exit switch.

Mode	What the rights and dependency question is	Highest level allowed in the starting profiles	The owner's question
Mode 0 Ambient AI	Completion in the editor and in vendor tools, switched on by an update; licence and provenance of what is accepted are unrecorded	Level 1 Assisted (accepted line by line)	Is the feature recorded, and is there a policy switch that was tested?
Mode 1 Conversational assistants	Pasting code in and out; code may leave the organisation; origin of pasted answers	Level 0 Advisory for design; Level 1 Assisted for generation	Which classification of code may go where, and who wrote the contract term?
Mode 2 Embedded workplace assistants	Suggestions that can match public code; model retirement; contract on training	Level 1 Assisted at Nordvik; Level 2 Supervised for outside the security-critical and payment paths at Hansa	Is the match filter or similarity scan on, and does the record show a tested exit?
Mode 3 Agentic work tools	Agents add dependencies, with licences; they run on a model with an exit	Level 2 Supervised (Nordvik: platform team only, AIDR-1116); Level 3 Bounded only for the Hansa patch-level dependency class under MND-HM-DEV-01	Does the proxy enforce the licence policy, and who holds the stop path?
Mode 4 Built AI applications	The test-drafting assistant and the legacy explainer rest on the group's platform and a model	Level 1 Assisted (HM-DEV-002); Level 0 Advisory (HM-DEV-003)	Is the model behind the application a recorded dependency with an exit?
Mode 5 Autonomous production agents	Not used for development at either organisation	None	Not applicable; the rule that no coding agent merges to the protected branch alone stands.

Nordvik Region and Hansa Mutual

Nordvik Region prefers European and self-hosted options where feasible, and its record shows both the advantage and the price. Code of the case platform and the benefits-triage rules does not leave the Region's capacity, and no provider's retirement schedule binds it. The price is that the platform team of seven engineers is the single owner of the serving stack, and that the exit test for the second model failed its gate on first run. The amendment of NR-2025-102, silent on AI tools until March 2030, is where ownership of generated code is settled for its consultants (Chapter 18 sets out the criteria sheet for tender NR-2030-041, with an exit and portability weight of 10 per cent). Its rule that no repository is published without a living owner gains a licence check for generated code; 31 per cent of its 96 repositories had an owner who had left the Region or changed team in July 2030 (OWN-NR-2030-00).

Hansa Mutual accepts a global provider with a contractual exit and uses its own hosting where code is most sensitive. DORA Articles 28 and 29 require a tested exit and a concentration check for a service supporting an important function, and EXIT-005 is the first coding-tool instance. The group publishes a mobile claims app and a broker plug-in, so its licence policy distinguishes distributed code from internal code. Its largest uncovered dependency is the Mode 0 assistant that Alster Managed Services uses for the mainframe batch, where the provenance field says "not asserted" until the contract gives the right to know (Chapter 10); and the code of its 190 external developers is the group's only to the extent the framework agreements say so.

Summary

This chapter concerned D2 Design, D3 Build and D5 Steward. It has argued, as the book's own conclusion, that the rights and the dependencies of an AI-assisted toolchain are decisions that must be made and recorded, and that the stewardship principle applies to them as to code.

On rights: Directive 2009/24/EC protects a program that is its author's own intellectual creation, so the human contribution to generated code is the thread on which ownership hangs, and no court in the Union has ruled on the point for code. Keep the provenance record where exclusivity matters, and settle ownership of generated material in the contracts of consultants and suppliers. On licences: contamination arises by reproduction by the model, by a dependency an agent adds, by pasted code and by code leaving; the evidence supports measurement and process, a similarity check, a bill of materials and a policy with a named owner, not trust in a tool's statement of a licence. On training: Directive 2019/790 Article 4 gives a mining exception subject to a reservation of rights, and AI Act Article 53(1)(c) and (d) puts the copyright policy and training summary on the provider, which a deployer can ask for. The litigation diverges and does not settle, and the user's exposure is least settled where generated code enters distributed software.

On dependence: open source carries the work, few maintainers carry the open source, and providers retire models on their own schedules. Law gives some organisations levers (DORA Articles 28(8) and 29, Data Act Articles 25 and 29), and a sovereign option can concentrate as well as free. The remedy is the toolchain dependency and exit record, AIDR-1126 at Nordvik Region and AIDR-1176 at Hansa Mutual here, with a named owner, a tested exit with an age and a review date at the earlier of evidence expiry, a model-retirement notice and a change of terms. A failed test is recorded as failed.

The next chapter turns from the toolchain to the people who use it, and treats competences and the development of the developer (Chapter 27). A reader can start tomorrow with one step: list the dependencies of the coding toolchain on one page, name an owner for each, and note which of them has never had its exit tested.

Sources

1. European Parliament and Council of the European Union (2024). 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)
2. 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)
3. 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)
4. European Parliament and Council of the European Union. Regulation (EU) 2023/2854 on harmonised rules on fair access to and use of data (Data Act). Official Journal of the European Union. (7, European Union, 2023)
5. European Commission (2025). Cloud Sovereignty Framework, Version 1.2.1. Directorate-General for Digital Services, October 2025. (8, European Commission, 2025)
6. Microsoft. Foundry Models lifecycle and support policy. Microsoft Learn, page dated 24 July 2026. (47, Microsoft, 2026)
7. Anthropic. Model deprecations. Claude Platform documentation. (48, Anthropic, n.d.)
8. Competition and Markets Authority (2025). Cloud services market investigation: summary of final decision. GOV.UK, 31 July 2025. (109, Competition and Markets Authority, 2025)
9. Farrell, J. and Klemperer, P. (2007). Coordination and Lock-In: Competition with Switching Costs and Network Effects. (110, Farrell & Klemperer, 2007)
10. Nordqvist, G. (2026). AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. The Architecture as Code Series, Book 2. (162, Nordqvist, 2026)
11. Nordqvist, G. (2026). AI Platform and Security: Building and Securing AI Platforms in European Enterprises and Public Authorities. The Architecture as Code Series, Book 3. (163, Nordqvist, 2026)
12. Nordqvist, G. (2026). AI Operations: How Artificial Intelligence Transforms IT Operations in European Enterprises and Public Authorities. The Architecture as Code Series, Book 10. (170, Nordqvist, 2026)
13. Nordqvist, G. (2026). AI Leader: How Leadership Roles Change When AI Is Used Broadly in European Enterprises and Public Authorities. The Architecture as Code Series, Book 11. (174, Nordqvist, 2026)
14. European Parliament and Council of the European Union. Regulation (EU) 2024/2847 (Cyber Resilience Act). Official Journal of the European Union, 20 November 2024. (242, European Union, 2024)
15. European Parliament and Council of the European Union (2019). Directive (EU) 2019/790 on copyright and related rights in the Digital Single Market, Articles 2(2), 3 and 4. Official Journal of the European Union L 130, 17 May 2019. (21, European Union, 2019)
16. European Parliament and Council of the European Union (2009). Directive 2009/24/EC on the legal protection of computer programs, Articles 1, 2 and 4. Official Journal of the European Union L 111, 5 May 2009. (20, European Union, 2009)
17. United States Court of Appeals for the Ninth Circuit (2026). Doe v. GitHub, Inc., No. 24-7700, 16 September 2026. (245, United States Court of Appeals for the Ninth Circuit, 2026)
18. Landgericht München I (2025). Pressemitteilung zum Urteil vom 11. November 2025, Az. 42 O 14139/24. (246, Landgericht München I, 2025)
19. High Court of Justice of England and Wales (2025). Getty Images (US) Inc and others v Stability AI Limited [2025] EWHC 2863 (Ch). (247, High Court of Justice of England and Wales et al., 2025)
20. Szpunar, M. (2026). Opinion of Advocate General Szpunar in Case C-250/25, Like Company v Google Ireland Limited. 3 November 2026. (248, Szpunar, 2026)
21. United States Copyright Office (2025). Copyright and Artificial Intelligence, Part 2: Copyrightability. January 2025. (249, United States Copyright Office, 2025)
22. Xu, W., Gao, K., He, H. and Zhou, M. (2025). LiCoEval: Evaluating LLMs on License Compliance in Code Generation. ICSE 2025; arXiv:2408.02487. (250, Xu et al., 2025)
23. GitHub (n.d.). Managing GitHub Copilot policies: Suggestions matching public code. GitHub Docs. (251, GitHub (n.d.), n.d.)
24. Stenberg, D. (2026). The end of the curl bug-bounty. daniel.haxx.se, 26 January 2026. (252, Stenberg, 2026)
25. Freund, A. (2024). backdoor in upstream xz/liblzma leading to ssh server compromise. oss-security, 29 March 2024. (253, Freund, 2024)
26. Collin, L. (2024). XZ Utils backdoor. tukaani.org. (254, Collin, 2024)
27. Open Source Observatory, European Commission (2021). Report: open source as a driver of EU's digital innovation. 6 September 2021. (255, Open Source Observatory & European Commission, 2021)
28. Open Source Initiative. The Open Source AI Definition, version 1.0. (26, OSI, n.d.)
29. SPDX Project, Linux Foundation. About SPDX. (27, SPDX Project & Linux Foundation, 2021)
30. Mistral AI (2025). Devstral. 21 May 2025. (275, Mistral AI, 2025)