CONTROL OF LEGAL AI

Who Controlsthe Legal AI Stack?

Open Source, Data Sovereignty and Regulatory Responsibility

READING KEY

Legal AI
Open source
Data sovereignty
Build provenance
Artificial Intelligence Act
Vendor lock-in

Abstract. A public repository may allow software code to be inspected and changed. By itself, it does not reveal which code was deployed, which model and legal data produced an answer, who can update the system or how the organisation can leave it. Control of legal AI exists only when an organisation can identify and inspect the decisive components, constrain access and changes, reproduce an outcome within known limits or restore the version used, replace a critical dependency and assign responsibility for every decision. Open source can make all of this materially easier. It does not, on its own, prove secure deployment, correct data, data sovereignty or compliant use.

This final article brings together four earlier questions: whether a source is temporally correct, whether the retrieval layer finds it at all, what an evaluation actually proves and where a confidential document travels. All four meet in one question: who can identify, change and stop the system that produces a legal answer, who can restore its verified state and who can replace it?

One Answer on Friday, Another on Monday

A large public institution uses an artificial intelligence system for legal research and first drafts. During the sales presentation, the supplier described it as open source. It showed the institution a public repository — an online collection of source code — and explained that the solution ran in the customer’s own environment.

On Friday, a lawyer enters a question about the legal consequences of particular conduct. The answer cites three authorities, explains their relationship and flags an exception. She saves it in the working file.

On Monday, she repeats the check. The question is exactly the same. The relevant law has not changed over the weekend. The system, however, cites a different set of authorities, omits the exception and reaches the opposite conclusion.

Both answers are fluent and confident. Both cite real documents. Neither indicates that it was produced in a different system state. The lawyer cannot treat the difference as a stylistic variation: Friday’s answer has already become part of the working material, while Monday’s would change the direction of the analysis. Before deciding which is better, she needs to know why they differ.

Monday’s answer may be better. A missing authority may have been added to the legal collection. The supplier may have installed a security patch. But the generative model may also have been replaced, the retrieval method changed, the system prompt updated or a new software dependency may have introduced an error.

The institution first asks its administrator what changed. The administrator can see that the service ran throughout the weekend, but has no inventory of every deployed version. The supplier confirms a “routine maintenance update” without identifying which container was deployed. The public repository is still there. It now contains new code. No one can prove whether either Friday’s or Monday’s production version was actually built from it.

The legal team asks for a change log. It receives a description of improvements, not a link between a change and a specific output. The procurement documents refer to an open solution and local deployment, but do not say who must retain previous artefacts, how long model versions must remain available or which data and settings will be exported when the customer changes supplier. Each document contains part of the answer. None assembles the whole.

They do not know:

whether the two answers were produced by the same model version;
whether the same adapter — a smaller addition to a model — or the same quantised, numerically simplified version of the weights was used;
whether the legal corpus was identical;
whether the documents were split and ranked in the same way;
whether the system called the same external service;
who approved the update;
or whether Friday’s state can be restored.

If all you can see is the code, you do not yet control the system. You control it only when you know what actually ran, who could change it, where the data went, how to reproduce the outcome or restore the relevant state, and when to abandon the system.

The problem in this scene is not that the label “open source” must have been false. The code may genuinely be public and its licence genuinely open. The mistake is to assume that openness in one layer proves control of the whole.

The example is wholly fictional. It does not describe a real institution, supplier, system or incident.

A Repository Is Not a System

Source code is the human-readable form of a program. When it is released under an appropriate open-source licence, it can be inspected, used, modified and distributed within the terms of that licence. This materially changes the balance of power: a customer is no longer entirely dependent on the supplier’s description and can inspect at least part of the technology itself or appoint an independent expert to do so.

But a running system is not only source code.

In this article, the connected layers of data, models, software, infrastructure and governance are the technology stack. Control of one layer does not automatically amount to control of the entire stack.

Code must first be combined with dependencies and built into a program, package or container image. A container image is a packaged runtime artefact: it contains the application and the environment in which it is intended to run. A supplier may build public code with a private patch, a different library version or a setting absent from the repository.

Legal AI may also use model weights — the numerical parameters learned by a model during training. An adapter, a smaller artefact that changes the behaviour of the base model, may be added to those weights. A model may be quantised, meaning that its weights have been converted to a lower-precision numerical form so that it uses less memory. Such a change can affect the output even if the user interface continues to display the same model name.

Then come the legal data. The same code and model can answer differently if the collection of legislation, case law, metadata or historical versions changes. A different method of splitting documents into passages, a new embedding model, a different ranking of retrieved authorities or a changed temporal filter can alter the result.

Behaviour is also shaped by system instructions, permitted tools, thresholds, refusal rules and routing between local and external services. The final layer contains servers, accounts, keys, network connections, logs, backups, remote support and people with administrative privileges.

A public repository can be an open window into one room. The system is the entire building, including its locked rooms, wiring, keys and the people who can replace its parts overnight.

“Open” Is Not a Single Property

In AI, the word “open” is used for several very different things.

What is accessible	What it enables	What it does not prove by itself
source code	reading and, where the licence permits, using, modifying and distributing the program	that the deployed program was built from that code
model weights	downloading and running the model under stated conditions	an open-source licence, access to training data or access to the training process
information about data	understanding the stated sources, composition and collection process	completeness, lawfulness or the ability to recreate the model
build instructions	attempting to create the program or model artefact	that production used the same build process
configuration	seeing prompts, filters, thresholds and tools	that these are the settings actually deployed
runtime artefact	running a particular image, package or model file	trustworthy origin, security or compliance
open export formats	transferring data and settings more easily	that migration to another system has been tested

A model whose weights are accessible — often called an open-weight model — is therefore not necessarily an open-source model. Its licence may restrict particular uses, modifications or distribution. Published weights also do not automatically reveal the data or process from which the model was produced.

The Open Source AI Definition 1.0, developed by the Open Source Initiative, requires the freedom to use, study, modify and share a system for any purpose. To make study and modification effective, it also requires sufficiently detailed information about training data, the code used for training and operation, and the model parameters.

That is a useful professional test of the term. It is not European Union law. The Artificial Intelligence Act uses the concepts of free and open-source licences in particular provisions and for particular legal effects. A community definition must not be presented as the official interpretation of the Regulation.

There is also an important difference between open-source and source-available software. In a source-available solution, the code can be read, but the licence may restrict commercial use, hosting or other forms of distribution. Publication can substantially improve transparency. It does not necessarily grant all the rights normally associated with open source.

A serious assessment therefore does not begin with a label. For every layer, it asks: what has been published, under which terms, in which version, with which parts missing, and how does it relate to the system that actually runs?

Openness Enables Verification; It Does Not Verify

Public code can enable an independent expert to find a defect, a dangerous network connection or incorrect handling of a document. It does not mean that anyone has already done so. Thousands of lines of code do not become reviewed merely because they can be opened in a browser.

The same applies to a community. Large numbers of stars, downloads or contributors may demonstrate interest. They do not prove that anyone reviewed the particular component that selects a historical version of legislation, protects professional secrecy or restores the system after a defective update.

A reproducible build is not necessarily a correct program. The same defect can be reproduced perfectly. A signed artefact can be authentic and still unsafe. A complete bill of materials can accurately list a vulnerable component. An open legal corpus can contain incorrect metadata or omit a judgment.

Openness is therefore not an alternative to professional scrutiny. It is one of its foundations. Its value appears only when someone:

determines which parts are material to the decision;
verifies the version actually used;
performs legal, technical and security review;
records the limitations;
requires remediation;
and checks that the remedy actually reached the deployed environment.

This restates the series’ central principle that a result is not a method: an accessible artefact does not prove how it was produced, reviewed and deployed.

A proprietary solution may offer less independent visibility into some of these questions. Yet it may have stronger contractual audit rights, more stable versions, clearer export arrangements and a better-tested incident response than a poorly maintained “open” deployment. This article does not select a winner between open and closed business models. It requires evidence of control from both.

Six Verbs of Control

Control of legal AI can be tested with six verbs.

Identify. The organisation can name the precise model, weights, adapter, quantisation, application release, dependencies, system instructions, corpus, index, configuration and execution environment. A commercial label is not enough.

Inspect. It has enough code, documentation, information about data, tests, contractual rights and expert access to examine the relevant properties. Inspection need not be entirely public; sensitive security information may remain restricted. Its status must be clear, as must the entity responsible for it.

Constrain. It is clear who may read data, replace the model, change a prompt, open a network egress route, deploy an update or restore a backup. These powers are not merely technically available; they are formally authorised and traceable.

Reproduce or restore. The organisation can reconstruct the decisive conditions of an outcome and return to a verified state. This does not always mean reproducing an identical generated sentence. It means being able to identify the artefacts, corpus, retrieval result and configuration used, and to explain the limit of reproducibility.

Replace. It can transfer data, evidence, configuration and knowledge. It can replace a model, host or another critical component without disproportionate loss of function or complete dependency on the original supplier. Replaceability becomes a strong claim only after a migration test.

Assign responsibility. It is known who provides the model, who provides the system, who deploys it, who hosts the infrastructure, who approves an update and who must act when something goes wrong. Technical power and legal responsibility are not the same, but they must be connected.

An organisation can perform one verb well and fail another. It may possess all the code but not the key needed to stop the system. It may have a complete component inventory but no right to export its data. It may have a contractual exit while no one knows how to build a replacement environment. It may know the responsible person but be unable to determine which version caused the error.

Control is not a single score. It is a matrix with visible gaps.

A Model Is Not a System

A large language model is only one layer of legal AI. A language model trained on broad, general material can generate text, but it does not know on its own which version of a Slovenian statute applied on a particular date, which judgment is material or which document from a case file is a permitted source.

A legal system may surround the model with several layers:

legal sources and corpus — legislation, case law, documents, metadata and temporal versions;
data preparation — optical character recognition, cleaning, splitting and labelling;
retrieval — an index, numerical representations, filters and reranking;
generative model — weights, adapters, quantisation and inference parameters;
orchestration — system instructions, permitted tools, sequences of steps and refusal rules;
application — the user interface, permissions, business rules and human review;
execution environment — servers, containers, clouds, keys, networks and copies;
evidence and governance — logs, approvals, contracts, responsible people, restoration and exit.

A change in any layer can change the answer. A new authority on Monday is not necessarily an error. Correcting a temporal filter may be essential. Refusing to move from Friday’s version after a vulnerability has been fixed may itself be dangerous.

The aim of control is not to freeze the system. It is to ensure that change is visible, justified, approved, tested and reversible where necessary.

From Public Code to the Deployed Artefact

Return to the public repository in the opening scene. How could the institution prove that Monday’s application was produced from it?

It must first identify an exact source state: not merely the project name, but a specific revision of the code. It must then know which dependencies and build environment were used. The process must produce a defined output — a container image, for example — with its own cryptographic hash.

A hash is a short digital fingerprint of content. If a single bit changes, the fingerprint will ordinarily change as well. It tells us whether we have the same artefact. It does not tell us who produced it, whether it is secure or whether its use is lawful.

A digital signature adds information about the issuer. Systems such as Sigstore support the signing of software artefacts with the issuer’s identity and recording of the event in a transparency log. A properly verified signature can show that the expected entity issued the artefact and that it has not changed since signing. A signed defect remains a defect.

Next comes build provenance: evidence of where, when, how and from which inputs an output was built. The Supply-chain Levels for Software Artifacts, or SLSA, defines ways to link a build to its source and to make that evidence more resistant to interference. It does not assess the legal correctness of code or the good faith of a legitimate issuer.

Finally, deployment evidence is needed. A complete build history is of little use if a different image is running in production. The deployment record must therefore identify the hash of the actual artefact, its environment, configuration and deployment time.

The chain is short, but no link can be skipped:

source code → build process → signed artefact → deployed version → specific output

If one link is missing, the organisation may know something about its system, but it cannot prove the complete path.

An Inventory Is Not Provenance; Provenance Is Not a Test

Software supply-chain discussions often refer to a software bill of materials, or SBOM. Like the bill of materials for a physical product, it lists components and their relationships.

SPDX 3.0 supports machine-readable descriptions of software, licences, security information, datasets, AI components and build information. CycloneDX 1.7 can describe components, services, external application programming interfaces, dependencies and data flows. Its machine learning bill of materials (ML-BOM) can also include models, datasets, configuration and deployment information.

This is useful. When a defect is discovered in a vulnerable library, an organisation can more readily identify the systems that contain it. If a model’s licence changes, it can locate every deployment that depends on that model.

But an automatically generated bill of materials may list declared packages rather than those actually loaded. It may be incomplete or outdated. It also does not show, by itself, that an image was built from the public repository.

Different evidence serves different purposes:

an inventory says principally what is supposed to be included;
provenance says from what and how something was produced;
a hash says whether the content is identical;
a signature helps identify who issued it;
a deployment record says what actually ran;
a test says how that version performed on a defined task;
and a legal assessment says whether its use for the particular purpose is permissible.

No one document performs all of these functions.

The same is true of a model card describing intended uses, measurements and limitations, and a datasheet explaining the origin and composition of a dataset. Both are important documentation methods. Neither proves, by itself, that production weights match the description or that every item of data was obtained lawfully.

For a legal system, the ordinary inventory needs a domain layer: the origin of a legal text, its jurisdiction, date of acquisition, temporal applicability, rights of use, transformations performed and the identity of the derived index. A retrieval index is not an independent source of law. It is a derivative that should be capable of reconstruction from a verified legal state.

Reproducibility Without an Impossible Promise

The word “reproducibility” can promise too much unless we say what is to be reproduced.

The first level is identity: do we have the same bits of code, weights, configuration and data snapshot? The next is the build: can the stated inputs produce the same or a verifiably equivalent artefact? The third is reconstruction of execution: do we know the request, sources, settings, tools and environment used? Only the fourth level is reproduction of the output.

For a deterministic step, such as calculating a hash or searching the same unchanged index under the same rules, an identical result may reasonably be expected. A generative model will not always reproduce the same sentence exactly. Randomness, parallel computation, hardware and service changes invisible to the customer can all affect its output.

A hosted provider may also withdraw an earlier model version. Friday’s state may then no longer be callable even if the customer recorded its name precisely. That is not a reason to abandon evidence. It is a reason to define the limit of reproducibility in advance and maintain an alternative route.

For legal analysis, it is often more important to recreate the same evidence package: the same retrieved authorities, temporal cut-off, candidate passages, selection rules and system version. A slightly different final sentence based on the same inspectable legal material presents a different problem from a system that mysteriously uses a different statute.

Restoration must therefore cover more than the application code. Restoring an old program while leaving the new corpus, index, model and system instructions in place does not restore Friday’s system.

Who Can Change Monday’s Answer?

Many actors can cause a change.

A model developer may release new weights. A host may withdraw an earlier version or change the execution environment. An application supplier may update the orchestration. The customer’s administrator may change the configuration or network route. The owner of the legal data may add an authority. The security team may block a vulnerable component. The legal policy owner may alter the permitted uses.

Not all such interventions are undesirable. Some are essential. The problem begins when the system does not distinguish:

who may propose a change;
who assesses its legal, quality and security impact;
who approves it;
who technically deploys it;
who verifies the production state;
and who may initiate restoration.

A person with the administrative password has technical power. That does not mean that they have organisational authority or the legal role of provider. Conversely, a provider may have a maintenance obligation without being entitled to change the customer’s production environment unilaterally.

A sound change-control process must therefore connect three things in its records: the technical artefact, its approval and the responsible entity. If a new model is deployed on Monday, the record must show who proposed it, which tests supported the decision, who approved it and how to return to the previous version.

This is also why an audit trail is not a log: it must record not only an event but its state, reason, approval and evidence.

The change then ceases to hide behind the phrase “routine maintenance”.

Who Is the Provider, and Who Is the Deployer?

The Artificial Intelligence Act does not classify technical actors by who wrote the most code. It looks at their actual roles.

In simplified terms, a provider is an entity that develops, or has developed, an AI system or general-purpose AI model and places it on the market or puts it into service under its own name or trademark. A deployer uses an AI system under its authority in the course of a professional activity. Importers and distributors occupy their own positions in the supply chain. For general-purpose AI models, a downstream provider that incorporates the model into a downstream system can also be important.

The same organisation can occupy different roles for different solutions. The author of an open-source library is not necessarily the provider of the final legal application. The provider of a base model is not necessarily the provider of a system that adds legal authorities, tools and a user interface. A host is not necessarily the developer. A customer may cease to be merely a passive user if it puts the solution into service for others under its own name or changes its purpose.

Consider two uses of the same open component.

A law firm incorporates it into an internal tool for generic drafting that does not determine rights and is not offered to others. The classification still requires examination of the complete system and its use, but internal integration alone does not automatically impose every obligation of a provider of a high-risk AI system.

Another organisation incorporates the same component into a system that it offers under its own name to a judicial authority to assist in researching and interpreting facts and the law and in applying the law to concrete facts. That use may fall within the high-risk systems listed in Annex III. The component’s licence is identical. The purpose, complete system and legal roles are not.

The question “who owns the code?” therefore does not answer the question “who is the provider of the system?”

When a Change Also Changes the Legal Role

The most dangerous shortcut would be to claim that anyone who changes a model or a line of code becomes a provider under the AI Act. That is not the rule.

Article 25 concerns high-risk AI systems and identifies three circumstances in which a distributor, importer, deployer or other third party may assume the role of provider:

it puts its name or trademark on a high-risk AI system already placed on the market or put into service;
it makes a substantial modification to such a system in a way that leaves it high-risk;
it modifies the intended purpose of an AI system not previously classified as high-risk so that it becomes a high-risk AI system.

“Substantial modification” is a narrower legal concept. It concerns a change made after placing on the market or putting into service that was not planned or foreseen by the initial provider in the original conformity assessment and that affects compliance or changes the intended purpose. A routine fix, permitted configuration or foreseen update is therefore not automatically a substantial modification.

The facts matter. Was replacement of the model foreseen? Does the documentation specify permitted versions? Does the change affect compliance with the requirements? Is the system still used for the same intended purpose? Who places it on the market or puts it into service after the change?

Following the July amendment to the Regulation, where another entity assumes the role of provider, the initial provider must cooperate closely with it. It must provide the necessary information and other assistance, including relevant technical documentation, known limitations and failure modes, as well as targeted technical access for testing and validation. An exception applies where the initial provider has clearly specified that the system is not to be changed into a high-risk AI system.

Timing is critical. Under Regulation (EU) 2026/1744, Sections 1 to 3 of Chapter III apply to high-risk AI systems under Article 6(2) and Annex III from 2 December 2027. For the Article 6(1) systems associated with regulated products in Annex I, the date is 2 August 2028. At the research cut-off of 23 September 2026, it would therefore be inaccurate to describe the relevant regime for Annex III judicial uses as already applicable.

That does not mean that an organisation can ignore roles, documentation or changes until the deadline. It means that the article must distinguish the legal text in force, its date of application and good practice worth adopting earlier.

An Open Licence Is Not a Regulatory Vacuum

The AI Act contains specific rules for free and open-source systems and models. It does not create a general zone without responsibility.

Article 2(12) provides that the Regulation does not, as a rule, apply to AI systems released under free and open-source licences unless they are placed on the market or put into service as high-risk AI systems or fall within particular prohibitions or transparency obligations under Articles 5 and 50. The exception itself shows why the word “open” does not resolve the assessment of the complete system and its intended purpose.

The logic for general-purpose AI models is different. Under Article 53(2), a provider of a model released under a qualifying free and open-source licence may be exempt from some documentation duties where the licence permits access, use, modification and distribution, and where parameters including weights, information on the model architecture and information on model usage are made public.

This is a partial, not a complete, exemption. It does not remove the duties to maintain a policy for compliance with Union copyright law and to publish a sufficiently detailed summary of the content used for training. Nor does it apply to a general-purpose AI model with systemic risk.

For a high-risk AI system, Article 25(4) requires a written agreement between the system provider and a third party supplying a model, tool, service, component or process necessary for compliance. An exception applies to certain tools, services, processes or components made accessible to the public under a free and open-source licence, but not to general-purpose AI models. The rule is not intended to turn every volunteer author of a library into the provider of the final system. Nor does it allow a system provider to point to an open component and abandon responsibility for integration.

The Cyber Resilience Act is similarly careful. For products with digital elements within its scope, it distinguishes manufacturers, ordinary contributors and open-source software stewards — legal persons that provide sustained support for open-source software intended for commercial activities and play a main role in ensuring its viability. It provides a tailored regime for their cybersecurity policy, vulnerability handling, cooperation and reporting.

The Act also requires manufacturers of covered products to produce a machine-readable SBOM covering at least the top-level dependencies. Its Article 14 reporting obligations have applied since 11 September 2026, while the general regime applies from 11 December 2027. It does not, however, automatically apply to every AI model, internal server or legal service.

The shared lesson of the two Regulations is not that open source creates less responsibility or more responsibility. It is more precise: the law distinguishes the author of a component, an organised steward, the manufacturer or provider of the final system and its deployer. Responsibility follows the actual role.

A Server in the EU Is Not Sovereignty

Once an organisation discovers how many invisible layers a system contains, it may reach for a simple answer: deploy it on a server in the European Union.

Location matters. It can affect international transfers, latency, oversight and risk. It is not the whole of sovereignty.

Even a locally deployed system may transmit telemetry while running, fetch packages from an external registry, verify a licence with a remote server, call an external model, keep backups with another provider or permit remote supplier access. The customer may own the hardware while the supplier alone knows the build process, administrative credentials and recovery procedure.

Conversely, an organisation may use external infrastructure and retain a meaningful degree of control if it has clear jurisdictional and contractual boundaries, its own keys, transparent subcontractors, restricted access, portable data, a documented build, an alternative route and a genuine ability to terminate the service.

The European Commission’s Cloud Sovereignty Framework demonstrates that institutional assessment does not stop at a map of data centres. It assesses strategic, legal and jurisdictional, data and AI, operational, supply-chain, technological, security and environmental dimensions.

This is a Commission procurement method, not a generally binding legal definition of sovereignty. Its Sovereignty Effectiveness Assurance Levels, or SEALs, are not a universal certification scheme. The implementation guidance recognises that complete attainment of the highest level is currently difficult because of dependencies on chips and other hardware.

That corrects both extremes. Sovereignty is not merely a European server address. Nor does it require one institution to manufacture the chip, train the model, construct the database and write every line of code itself. It means having a reasonable ability to decide how critical dependencies are used and to exit from them.

For a legal system, the assessment should ask at least:

who controls the data and encryption keys;
to which jurisdictions the provider, subcontractors and infrastructure are exposed;
who can start, stop, update and recover the system;
which external dependencies are hidden beneath a local interface;
whether formats, knowledge and replacement components are available;
what happens if a licence changes, a model is withdrawn or support ends;
and what evidence supports each answer.

In a strategic procurement announced in 2026, the European Commission accepted, among others, routes using non-European technology where EU companies operated that technology exclusively under the required conditions. This does not diminish the importance of European technological capacity or jurisdiction. It shows that the origin of one component is not the only criterion.

In March 2026, the Council of Europe’s European Commission for the Efficiency of Justice (CEPEJ) also discussed judicial independence in the digital age together with data sovereignty and open-source software. That is an important European institutional direction. It is not a binding requirement and does not prove that open source alone guarantees judicial independence.

Ownership Is Not an Exit Strategy

An organisation can buy a server, obtain a copy of the code and still remain locked into a supplier. That dependency is commonly described as vendor lock-in.

It may have no right to transfer the model weights. It may be able to export documents but not their metadata, indexes or audit evidence. System instructions may be the supplier’s trade secret. The application may depend on a proprietary database, identity system or security function. All the documentation may be public while no other team has the knowledge needed to maintain the system.

Exit must therefore be planned as a process:

export source data, structured text, metadata and audit evidence;
transfer configuration, procedures, schemas and knowledge;
rebuild or restore the legal corpus and retrieval index;
replace the model, host or application layer;
verify the legal, security and language quality of the replacement route;
preserve a minimum critical function during any interruption.

The Data Act, which applies from 12 September 2025, requires the removal of contractual, commercial, technical and organisational obstacles to switching for covered data processing services. It governs the contractual process, assistance, data transfer and, for certain services, functional equivalence. Under Article 29, switching charges cease on 12 January 2027.

This provides important legal support for exit. It is not magical portability. Another provider may not use the same model, understand Slovenian legal language equally well or offer the same security function. A proprietary index may not be transferable, but it may be possible to reconstruct it from source documents and a documented method.

A contractual right to export is therefore only the first piece of evidence. The second is a successful migration exercise. Until another team tries to establish a limited replacement environment, the organisation does not know how much invisible knowledge and how many manual steps bind it to the supplier.

The Technology-Stack Control Record

The practical answer to this problem is not another general badge marked “open” or “sovereign”. What is needed is a versioned, evidence-backed record that connects the complete system to its components, decision rights and exit path.

Such a technology-stack control record should state, for every decisive layer:

what the component is and which task it performs;
its precise version or artefact hash;
its developer, maintainer and the entity able to change it;
its licence, contractual terms and restrictions;
the availability of code, weights, information about data, configuration and build materials;
the source inputs and evidence of the build process;
the actual execution environment, outbound connections and privileged access;
the data received, created, stored and transmitted;
the model provider, system provider, deployer, host and change approver;
the update, restoration, export and replacement process;
tests used, known limitations and the date of last verification;
and the evidence supporting each claim.

The record should not show only public components. A private configuration may remain protected, but its existence must be visible. A security key does not belong in a public document, but its owner, management method and evidence that access does not depend on one external person should be known.

Every statement should also carry a status: evidenced, declared, limited, unavailable, unknown, not applicable with reasons, or planned. An empty field can then no longer disappear behind a confident marketing sentence.

Its machine-readable core could use SPDX or CycloneDX for the inventory, SLSA for build provenance, and signatures and hashes for identity. Its human-readable summary must answer a simple question for a lawyer or purchaser: who has authority over this part of the system, and which evidence supports that claim?

This is not a compliance certificate. It is a way to make unknowns visible before they become incidents.

OpenLegalCore Must Apply the Same Test to Itself

If OpenLegalCore proposes such a record to others, it must first dismantle its own technology stack honestly.

As at 23 September 2026, the OpenLegalCore component register lists nine components: four public, four private and one planned. It also lists compatible external clients that are not project components.

Legal OCR Pipeline v0.1.2 is a public open-source component under the Apache-2.0 licence. Its code, tests, documentation and a local human-review tool are public. The acceptance record covers one private 174-page document and a manually reviewed 40-page sample with the result SAMPLE_PASS; it is not a general test of quality or speed. The configuration in the public repository uses the Google Vertex AI service through version v1 of its application programming interface (API), with location eu and model gemini-3.5-flash-lite. The input pages therefore leave the local device. The repository expressly does not guarantee confidentiality, data residency or regulatory compliance. This is a clear example of the difference between open pipeline code and an external model path.

Slovenian Legislation Pipeline v0.1.0 and Slovenian Case Law Pipeline v0.1.7 make their code, documentation, tests and deployment templates public. They use the Business Source License 1.1 (BUSL-1.1) and must therefore be described as source-available, not open source. Their public repositories do not include credentials, legal texts and judgments, data snapshots, managed infrastructure, the complete retrieval interface or legal advice.

Maintained snapshots of the legislation and case-law collections are separate private components available through a restricted data-partnership regime. OLC Engine v0.0.7 is a private system core in active development. Legal Fact Extractor is a private incubation component. OLC Legal Workspace is a planned direction without an available implementation. Word Connector v0.1.0-beta.1 is a public beta released under Apache-2.0. Its beta status limits what can be claimed about production readiness; it does not make the code private. Open WebUI is a compatible third-party client, not an OLC component.

Governance is also part of control. OpenLegalCore is a founder-led project: Rajko Majcen currently decides product direction, component boundaries, releases and the public–private boundary. Public participation can influence the work; it does not automatically transfer governance rights. Public code for an individual component is therefore not the same as community control of the complete project.

OpenLegalCore already has several building blocks for a future record: a component register with versions, statuses, licences and dates; separation of public, private, external and planned elements; documentation, tests, bounded acceptance records and a public security reporting route.

At the research cut-off, however, the reviewed public sources did not establish a unified machine-readable manifest for the complete stack, a project-level SBOM or ML-BOM covering every layer, public SLSA provenance for releases, a signed link from source through build to production deployment, or a publicly tested replacement of model and host. This is a bounded finding about public artefacts. It does not prove that no internal record exists.

The status of the proposal is therefore precise:

OpenLegalCore proposes a publicly verifiable technology-stack control record. It would extend the present component and evidence records, but neither its unified machine-readable implementation nor a publicly verified link from source through build and deployment to an individual output had been established in the reviewed public sources at the research cut-off.

This is not a weakness to conceal. It is a test of the article’s central thesis. A project does not become trustworthy by calling the whole stack open. Trust begins with stating clearly, for every layer, what exists, what is public, what is restricted, what is external and what is still planned.

Twelve Questions for the Purchaser

Before purchasing, deploying or significantly updating legal AI, a customer should obtain answers to at least these questions:

Which exact versions of the code, model, corpus, index and configuration will run?
How is the deployed artefact linked to the stated repository or supplier release?
What is open source, what is merely source-available, what is proprietary and what is an external service?
Who can access the data, keys, logs and backups?
Which network connections, telemetry, registries and remote-support routes remain active?
Who may change the model, legal corpus, system instructions or data path?
Who assesses a change for legal, security and quality effects, and who approves it?
Can a specific output be linked to the sources used and the state of the complete stack?
What exactly can be restored, and when was restoration last tested?
Which data, configurations, evidence and knowledge can the organisation take with it on exit?
Has another model, host or operator actually been tested?
Who is the model provider, system provider, deployer, host, maintainer and responsible entity during an incident?

An unknown answer does not necessarily mean that the system may not be used. It does mean that an unknown must not be relabelled as control.

The Limits of This Analysis

This article does not provide a legal opinion on a particular product, deployment or public procurement. It does not rank open and proprietary solutions from good to bad. It does not claim that every legal AI system is high-risk or that every technical change creates a new legal role.

The scope of the AI Act, the Cyber Resilience Act and the Data Act must be assessed against the particular system, service, purpose, economic activity and date. The Commission’s institutional Cloud Sovereignty Framework is not a general legal definition. SPDX, CycloneDX and SLSA are not security or compliance certificates.

Nor is control the same as quality. An organisation may fully control a model that performs poorly on Slovenian legal text. It may reproduce a wrong result and sign a vulnerable artefact. The language and legal quality of a replacement model are therefore essential conditions of exit, but they require separate research.

All legal, technical and project claims are tied to the position verified on 23 September 2026.

Back to Monday

Return to the institution and its two answers.

In a controlled system, Monday’s difference is no longer a mystery. The record shows that a new application release was deployed, that the model used to rank authorities changed or that a new snapshot of legislation was added. The associated tests, approval, responsible person and boundary of impact are visible.

If Monday’s answer is better, the institution can accept the change on stated grounds. If it is worse, it can restore the complete verified state — not only the code, but also the configuration, model, corpus and index. If the supplier does not provide the necessary evidence or exit, the institution can begin a tested transition to another route.

Open source remains important. It means that decisive parts need not be accepted on trust alone. Its true value appears, however, only when it is connected to the actual build, deployment, data, authority and ability to replace.

Control is not a claim that the system will never change. It is the ability to act rationally when it does.

The law does not need technology that is open only on a presentation slide. It needs a system for which we can prove what produced the result, who could change it and what we will do when we no longer trust it.

Selected Sources

Legal, technical, institutional and project sources last checked: 23 September 2026.