Artificial Intelligence, Technology

Model Cards for LLMs — what they are, why they matter, and how the EU AI Act gives them a boost

TL;DR: Model cards are structured “fact sheets” for AI models. They document purpose, training data, performance, risks, limitations, and responsibilities — making them the fastest route to reliable transparency. Under the EU AI Act, exactly these information duties for general-purpose/LLM models are becoming binding in stages: since 2 August 2025, transparency and copyright obligations apply in the EU, including a public summary of training data; particularly capable models face additional safety and risk obligations. A well-crafted model card helps fulfill these duties efficiently.

What are model cards (for LLMs)?

Model cards were proposed in 2018/2019 as a standard for model-accompanying documentation: concise, structured documents that disclose a model’s intended use, performance metrics (including subgroups), known limits, and ethical considerations. For LLMs, this additionally means pretraining/finetuning details, the RLHF process, benchmarks (e.g., MMLU/MT-Bench), resilience to hallucinations and jailbreaks, privacy tests, and the energy footprint.

In practice, model cards have become a de facto standard — for example on the Hugging Face Hub as a README.md plus metadata.

What does this have to do with the EU AI Act?

1) Timeline and scope

The EU AI Act entered into force on 1 August 2024. For general-purpose AI (GPAI) — which includes LLMs — transparency and copyright obligations have applied in stages since 2 August 2025; models placed on the market earlier benefit from transition periods until 2 August 2027.

2) Concrete obligations for LLM/GPAI providers

  • Transparency and technical documentation: Provide information on capabilities, limitations, and safe use (Art. 53).
  • Copyright: Maintain policies/processes for copyright compliance.
  • Public training-data summary: Publish a “sufficiently detailed” summary of the content used for training — following the EU template made available by the Commission in 2025 (Art. 53(1)(d)).
  • Systemic risks (very large models only): For models above a compute threshold (e.g., 10^25 FLOPs), additional obligations apply, including risk assessment, red teaming, incident reporting, cybersecurity, and more.

The Act also requires transparency toward users — for example, labeling synthetic content and informing people when they interact with AI (Art. 50).

In short: The information the AI Act requires forms the core of a good model card.

How to build an “AI-Act-ready” model card for LLMs

Below is a practical structure — with an indication of which AI-Act idea it supports:

  1. Model profile (name, version, date, contact) — technical documentation/accountability.
  2. Intended uses and out-of-scope uses — safe use, minimization of misuse.
  3. Training-data summary (source classes, curation logic, geographies/languages, licensing mix, exclusion criteria) — public summary per the EU template (link/appendix).
  4. Copyright policy (handling opt-outs/opt-ins, TDM exceptions, rights preservation) — copyright compliance.
  5. Model development (pretraining objective, finetuning, RLHF, safety filters) — transparency/technical documentation.
  6. Performance and evaluation (benchmarks, methodological notes, domains/languages, subgroup analyses) — traceability and fairness assessment.
  7. Risk profile (hallucinations, bias, privacy leakage, jailbreaks, known failure modes) — risk management/systemic-risk topics for large models.
  8. Red teaming and safety (test design, adversarial testing, content moderation, incident process) — safety obligations for systemic risks.
  9. Energy and operations (training compute, inference cost/footprint, efficiency measures) — best-practice transparency.
  10. User guidance (prompt examples, limitations, labeling duties for synthetic media, monitoring tips) — Art. 50 transparency toward end users.
  11. Governance and maintenance (versioning/changelog, deprecation policy, incident contact channels) — continuity and compliance evidence.

Common pitfalls (and how the model card helps)

  • “We can’t disclose our training data.” — You don’t have to: what’s required is a summary, not a raw data dump, and there is an official template.
  • “Our model is open source, so we’re exempt.” — Only partially: open GPAI models still need to provide a training-data summary and a copyright policy, among other things; exemptions do not apply where systemic risk is concerned.
  • “Transparency ≠ marketing brochure.” — A model card is technical documentation that should be audit-ready — not just nicely phrased.

Conclusion

Model cards were “good practice” for years. With the EU AI Act, they become an operational lever for implementing transparency, copyright, and safety requirements concretely and verifiably. Put more personally: a good model card ultimately saves time — because it answers the right questions up front.

https://arxiv.org/abs/1810.03993 “Model Cards for Model Reporting”
https://huggingface.co/docs/hub/en/model-cards “Model Cards”
https://commission.europa.eu/news-and-media/news/ai-act-enters-force-2024-08-01_en “AI Act enters into force – European Commission”
https://artificialintelligenceact.eu/article/53/ “Article 53: Obligations for Providers of General-Purpose AI …”
https://digital-strategy.ec.europa.eu/en/policies/contents-code-gpai “The General-Purpose AI Code of Practice”
https://digital-strategy.ec.europa.eu/en/faqs/general-purpose-ai-models-ai-act-questions-answers “General-Purpose AI Models in the AI Act – Questions & Answers”
https://digital-strategy.ec.europa.eu/en/news/eu-rules-general-purpose-ai-models-start-apply-bringing-more-transparency-safety-and-accountability “EU rules on general-purpose AI models start to apply, bringing …”
https://artificialintelligenceact.eu/article/50/ “Article 50: Transparency Obligations for Providers and …”
https://artificialintelligenceact.eu/high-level-summary/ “High-level summary of the AI Act”

Technology, UI/UX

Mental Models & UX: How we understand expectations and avoid friction

People never arrive at an interface as blank slates. They bring expectations, routines, and small explanatory stories that tell them how something is likely to work. These inner maps are called mental models. Put simply, a mental model is what users believe about how a system works. It is not an objective truth. It is a pragmatic working hypothesis that guides action and is rewritten with every experience. For designers it is essential to know and shape this hypothesis, because it determines whether a product feels intuitive or like a puzzle.

It is worth distinguishing mental models from so-called conceptual models. The conceptual model describes the logic that designers deliberately build into a system to make it understandable. The mental model is the version in the user’s head, formed by symbols, labels, affordances, and prior experience. Good UX brings both models into alignment so that the interface evokes the right mental picture. Don Norman sharpened this distinction early on and laid a foundation for modern human–computer interaction.

Why mental models are so powerful

People use their inner models to predict what will happen next. When you see a magnifying glass icon you expect a search. When a file sits in the trash you hope to restore it. When those expectations are met, the experience feels light and in control. When we break them without preparation, uncertainty and error rates rise. Mental models are therefore not just a neat theory. They are the operational basis for orientation, trust, and flow in digital experiences.

Mental load explained and why it matters in everyday use

Mental load here means the cognitive effort required to use a product. The more thinking a product demands, the harder search, decision making, and error recovery become. High cognitive load can result from unclear structure, conflicting labels, or unusual interaction patterns. You can reduce it through plain language, consistent patterns, sound information architecture, and progressive disclosure. The goal is to keep the mind free for the task itself rather than the mechanics of using the interface.

Personas as a bridge between the team and real expectations

Personas are concise, fictional profiles based on real data. They condense research findings into a tangible person with goals, behaviors, and contexts. Their value lies in making expectations visible. If a team says that Anna plans trips on her phone in short breaks, you can derive mental models from that. You can anticipate the navigation she expects and how much text she is willing to read. Personas help translate the right assumptions into design decisions and anchor them within the team.

Familiarity is not a nice-to-have. It is a speed booster

Familiarity means a sense of the known. Users learn patterns from other products and bring them along. Jakob’s Law captures this elegantly. People spend most of their time in other interfaces and expect new products to behave similarly. Teams that deliberately go against common conventions create learning effort and raise mental load. Successful designs use familiar patterns and introduce novelty only where the benefit justifies the learning curve. Consistency and standards are therefore not formalities. They are effective tools for activating mental models rather than breaking them.

Understanding and respecting inertia and change aversion

Inertia stands for behavioral inertia. People stick with what they know because reliability saves energy. In UX this appears as change aversion. Even sensible redesigns encounter initial resistance simply because they are new. Teams should not read this as failure but as an expected reaction. Good practice is to explain changes, make advantages visible, ease transitions, and retain familiar anchors. Complaints are part of the rollout phase in almost every case. The goal is to minimize friction, not to eliminate it entirely.

Turning theory into design without drowning in jargon

The first step is listening. Context interviews and observations reveal the stories users tell themselves about a system. From this you develop hypotheses about their mental models. In the second step you translate those assumptions into navigation concepts and interaction patterns that match familiar expectations. Prototypes help you see early whether the intended mental picture actually emerges. In the third step language creates clarity. Terms should sound the way people would describe them. If users say invoices, the area should not be called billing and receivables management. In the fourth step you refine consistently. Small improvements that strengthen orientation are often more effective than a grand overhaul. Familiarity remains the guardrail. Where novelty is necessary, microcopy, previews, and reversible actions ease the learning curve. The theoretical line between conceptual model and mental model serves as a compass. We deliberately design a clear conceptual model that evokes the desired mental picture and then measure whether users actually adopt that picture.

Common pitfalls and how to avoid them

Many problems begin with blind spots. Teams are experts in their own product and underestimate how little outsiders know. This leads to structures derived from internal departments instead of user tasks. Another pattern is confusing novelty with progress. A fresh look does not create a better experience if familiar anchors are lost. There is also the temptation to represent every exception. That bloats interfaces and increases mental load. It is better to optimize the frequent paths and handle rare cases with graceful fallbacks. The guiding question stays the same. Which expectation does this element create, and does it match what actually happens

A quick look at practice

Consider a search function. Many people expect the Enter key to submit a search, results sorted by relevance, and the query to remain in the search box so it can be edited quickly. If we interpret Enter as a line break, hide sorting, or clear the input, we collide with learned models. The result is a steep increase in mental load even if the functionality is objectively powerful. With familiar patterns, clear feedback, and gentle hints you can present the same breadth of capability in a much more accessible way. This way of thinking transfers neatly to checkout flows, file management, dashboards, and mobile navigation.

Conclusion

Good UX is the art of synchronizing the picture in users’ heads with the inner logic of the system. Mental models provide the framework. Personas make expectations tangible. Familiarity reduces the learning curve and builds trust. A deliberate approach to inertia smooths the path through change. Teams that keep mental load low give people the luxury of focusing on the task itself. Put differently, a product feels intuitive when the story it tells aligns with the story users already bring with them.

https://www.interaction-design.org/literature/topics/mental-models?srsltid=AfmBOoolSQP4_l9q0nWkxbg2gadhua-WLtdBnYbUHG3LDIEvf0aBJgcB

Artificial Intelligence, Technology

Apertus: Switzerland Opens the Door to a Transparent AI Future

From ETH Zurich to Swisscom: Apertus marks the birth of Switzerland’s first large open-source language model — a European signal for transparency, research, and digital sovereignty.

An Open Countermodel to the AI Powerhouses

While the global spotlight shines on the major U.S. tech companies — OpenAI, Anthropic, Google, and Meta — a remarkable alternative is taking shape in Switzerland: Apertus. Unveiled in 2025, this large language model is not only the first of its kind developed in Switzerland but also one of the most transparent AI initiatives worldwide. At its core lies a bold vision: artificial intelligence as a public good, not a closed commercial product.

A Collaboration Between ETH, EPFL, and Swisscom

Apertus is the result of a collaboration among Switzerland’s leading research and technology institutions:

  • ETH Zurich and EPFL Lausanne lead the scientific development.
  • The Swiss National Supercomputing Centre (CSCS) in Lugano provides the computational power via its Alps supercomputer.
  • Swisscom integrates the model into its Swiss AI Platform, bringing it to enterprise clients.

This combination of academic excellence and industrial application makes Apertus a showcase of applied AI innovation in Europe.

Technical Foundation: GPT-Like, but with Swiss Precision

Apertus is built on the transformer architecture, similar to the GPT family of models. Two versions have been released:

  • a model with 8 billion parameters, and
  • a larger one with 70 billion parameters,

each available in instruction-tuned variants optimized for conversational use.

The training corpus consists of about 15 trillion tokens across more than a thousand languages. Special attention was given to underrepresented languages such as Swiss German and Romansh.

A custom embedding system was designed to prevent English from dominating the dataset — a frequent bias in global AI models.

Transparency as a Principle

What truly distinguishes Apertus is its radical openness.
The entire training process, source code, and datasets have been made public — an unprecedented level of transparency among large-scale language models.

This makes Apertus fully compliant with the EU AI Act’s transparency requirements and sets a new standard for responsible AI development.
Researchers, developers, and companies can trace exactly how and with what data the model was trained.

It’s not just a technical decision — it’s a political statement about accountability and democratic oversight in artificial intelligence.

Data Protection and Ethical Boundaries

The project’s creators emphasize that development followed Swiss data protection and copyright laws.

At the same time, they openly acknowledge that not every textual source used in training was formally licensed — a transparency that reflects intellectual honesty rather than negligence.

Apertus thus navigates the realistic gray zone that many AI research projects inhabit, where the ideals of openness intersect with the complex realities of digital content rights.

Not Yet a Chatbot — but a Powerful Foundation

As of autumn 2025, Apertus exists purely as a text-based model.
It does not yet support multimodal capabilities such as image, video, or audio processing. However, the development roadmap envisions extensions that could eventually make Apertus a fully fledged open-source assistant.

Even today, the model serves as a robust foundation for specialized AI applications in research, public administration, and industry.

Why Apertus Matters

Apertus is more than a research project — it is a message to Europe.
At a time when AI infrastructure is increasingly concentrated in private hands, Switzerland demonstrates that technological sovereignty and openness can coexist.

The benefits are clear:

  • Independence from U.S. platforms
  • Compliance with European data protection standards
  • Promotion of multilingual and local innovation

In this sense, Apertus stands as a symbol of an independent European AI strategy — small, precise, and transparent.

Conclusion: Apertus as a Blueprint for Open AI

With Apertus, ETH, EPFL, and Swisscom have set a new benchmark:
a powerful, auditable, and freely accessible language model designed to serve science, business, and society alike.

In a world where many AI systems operate as opaque “black boxes,” Switzerland’s Apertus — true to its Latin name meaning “open” — offers a window into a transparent, verifiable AI future.

https://de.wikipedia.org/wiki/Apertus

https://ethz.ch/de/news-und-veranstaltungen/eth-news/news/2025/09/medienmitteilung-apertus-ein-vollstaendig-offenes-transparentes-und-mehrsprachiges-sprachmodell.html

https://huggingface.co/collections/swiss-ai/apertus-llm

https://publicai.co/

Software

draw.io — Think more clearly through clear visualization

Thoughts, ideas, and evolving concepts can be pretty demanding. It’s easy to get lost in them
and maybe forget one thing or another that didn’t seem important at first. It helps to visualize
your thoughts while you’re thinking—and to try out different versions and play with them.
In my workflow, #draw.io has become an indispensable tool.

Resources