7 Min. Reading time<\/p>\n
Who brings an AI model into productive operation bears responsibility for its behavior, risks, and maintenance. That it is a new German model from a funded consortium does not change that. The CIO cannot offload this responsibility onto the origin or an open license. Sovereignty is demonstrated by how an organization steers, controls, and documents the use.<\/strong><\/p>\n Key Takeaways<\/p>\n Related:<\/span>Sovereign Cloud: When the Upscale Pays Off<\/a> \/<\/span> Muse Spark Forces CIOs to Rethink<\/a><\/p>\n Many organizations start evaluating a new model by looking at performance. That\u2019s the wrong place to begin. First, their governance structures must be in place. A consortium model, such as the one recently presented by the Soofi project, emerges from a collaboration of multiple research institutions and companies. The decision to adopt it therefore isn\u2019t just an IT matter-it touches compliance, the legal department, and ultimately the board.<\/p>\n The EU AI Act (Artificial Intelligence Act) requires transparency, risk classification, and human oversight. These obligations apply regardless of whether a model comes from a publicly funded project. Internal policies must define which use cases a model with limited commercial maturity is even allowed to enter. Without such definition, conflict arises later when a department wants to put the model into production and the legal basis remains unclear.<\/p>\n Liability also comes into play. A commercial provider typically limits its contractual liability. In a consortium, assigning responsibility is less clear because liability is spread across multiple institutions. A chief information officer (CIO) should clarify early which risks the organization bears itself and which can be covered by contracts.<\/p>\n An open license shifts dependency. It does not eliminate it.<\/p><\/blockquote>\n The integration of AI into an existing IT landscape is about more than technical compatibility. It hinges on who bears responsibility for uptime, security patches, and adapting to new regulatory demands. A research consortium is not built for long\u2011term operational support. Funding from the Federal Ministry for Economic Affairs and EU funds dries up at a fixed deadline, after which someone must step in to take ownership.<\/p>\n In practice many teams assume an open licence means they can run the model themselves indefinitely. Without in\u2011house capacity for fine\u2011tuning, security testing, and monitoring, they quickly become dependent-not on a single vendor but on the continued existence of the participating institutions or the willingness of a community to keep the model alive.<\/p>\n THE BLIND SPOT<\/p>\n Availability is not control.<\/strong> Running a model in your own data centre does not automatically mean you master it. Without monitoring data flows, without version control and without a defined escalation path, sovereignty remains a paper concept.<\/p>\n<\/div>\n Sovereignty means the organization decides itself how the model is used, which data it processes and when it is adjusted or replaced. For this, roles and processes are needed that carry these decisions. Often the competence sits with only a few specialists in IT. The business unit knows the requirements, the board the strategic risks. Without clear role distribution, exactly these gaps arise in between.<\/p>\n Structural problems arise when no entity is defined that decides on the use in a new application case. Personnel problems arise when a single expert drops out and no one can take over control. Both need to be addressed simultaneously. Building governance capability therefore requires two things: defined decision rights and targeted competence building in the teams that carry the model.<\/p>\n The Soofi project states its goal as full control over data, provenance and infrastructure. For the user this means checking whether this control actually reaches the organization. Relying on a model from a consortium without building own mechanisms to monitor data flows and model versions merely shifts dependence to another place.<\/p>\n Revision, oversight and customers increasingly ask how an organization actually exercises control over its AI systems. The claim that a model is sovereign because it was developed in Europe does not count in an audit. The CIO must be able to prove which data flowed into the training, how changes are documented, and which control mechanisms are applied in ongoing operations.<\/p>\n Especially with models originating from research contexts, documentation of training data and procedures is often not provided in the depth required by an audit. This gap was also noted by the specialist community in the Soofi-Report. For the user the question remains whether they can independently verify the consortium’s statements and what conclusions they draw for their own risk assessment.<\/p>\n Without solid evidence to internal auditors or external parties, sovereignty remains a claim. Building audit trails and the ability to provide detailed information on request must therefore be incorporated into integration planning from the outset. In regulated industries where oversight demands concrete evidence, this point decides on approval.<\/p>\n What is AI Governance?<\/strong> AI Governance is the binding framework of decision rights, risk criteria, documentation obligations and control points that determines who decides on the selection, use and decommissioning of a model and who is accountable in case of a failure. Without this framework, usage is neither controllable nor presentable in an audit. This applies to a consortium model as well as to a commercial provider.<\/p>\n<\/div>\n The strongest counterargument weighs heavily: A publicly funded, permissively licensed model from a broad European consortium is already a step forward compared to proprietary alternatives. It reduces dependence on individual foreign providers and opens the possibility for in-house adaptation. This argument holds as long as the alternative truly offers less control. It overlooks one point: The formal availability of a model does not automatically create operational control within the organization. Exactly that must be established by the CIO.<\/p>\n In the first 30 days, a team comprising IT, Legal, Compliance, and a departmental representative establishes a criteria catalog. It specifies the requirements for data provenance, update processes, escalation pathways, and documentation within the organization. The Chief Information Officer (CIO) is accountable as sponsor, while operational leadership rests with the Chief Information Security Officer (CISO).<\/p>\n In the second 30 days, a dependency matrix for ongoing AI initiatives is created. It lists, per system, the functional owner, the escalation level in case of an incident, and the existing or missing proof of data origin and control. The matrix makes visible where no one is currently named who would take responsibility in doubt.<\/p>\n In the final 30 days, the first contractual and organizational measures are defined for a selected pilot scenario. This includes clarifying who is actionable within 48 hours in the event of a model change or a security breach, and how such actionability can be demonstrated.<\/p>\n In a model from a research consortium, liability issues are usually less clearly defined than with commercial providers. The organization must assess the extent to which it itself is liable for damages caused by the model’s behavior. Contracts with individual consortium partners only help limitedly, because responsibility is distributed across multiple institutions.<\/p>\n<\/details>\n It starts with defining roles and decision-making processes and can take several months to a year depending on the starting situation. Technical integration is faster. The ability to evaluate, monitor, and, if necessary, replace a model independently requires targeted competency development and practical experience.<\/p>\n<\/details>\n A closed beta means that the model has not yet been released to the general public and that architecture, behavior, and support may still change. Those who evaluate now should clarify which commitments for further development and support apply beyond the beta. Without such commitments, productive use remains highly uncertain.<\/p>\n<\/details>\n More from the MBF Media Network<\/p>\n\n
Governance Faces Model Selection<\/h2>\n
Clarifying Operational and Integration Responsibility<\/h2>\n
Building Internal Governance Capability<\/h2>\n
Proof Obligations and Auditability in Practice<\/h2>\n
The Counterposition<\/h2>\n
The 90-Day Action Impulse<\/h2>\n
Frequently Asked Questions<\/h2>\n
What liability risks arise when using a consortium model?<\/strong><\/summary>\n
How long does it take to develop sufficient internal control capabilities?<\/strong><\/summary>\n
What does the closed beta phase mean for production use?<\/strong><\/summary>\n