{"licence":{"name":"CC BY-SA 4.0","spdx":"CC-BY-SA-4.0","url":"https://creativecommons.org/licenses/by-sa/4.0/","attribution":"Atlas, a bilingual technical dictionary (https://cmaintz.github.io/tech-atlas/)"},"id":"ai/model-card","url":{"en":"https://cmaintz.github.io/tech-atlas/en/terms/ai/model-card/","da":"https://cmaintz.github.io/tech-atlas/da/terms/ai/model-card/"},"term":{"en":"Model card","da":"Modelkort (model card)"},"aka":{"en":[],"da":[]},"domain":["ai"],"cluster":"ai-risk","layer":"model","status":"current","era":2019,"summary":{"en":"A short fact sheet that ships with an AI model and says what it is for, how it was tested and where it falls short.","da":"Et kort faktaark, der følger med en AI-model og fortæller, hvad den er beregnet til, hvordan den er testet, og hvor den kommer til kort."},"body":{"formal":{"en":"A structured document published with a trained model that records its intended use and out-of-scope uses, training data, model evaluation results broken down by groups of people and conditions, known limits and ethical concerns.","da":"Et struktureret dokument, der udgives sammen med en trænet model og beskriver den tilsigtede brug og brug uden for rammerne, træningsdata, resultater af modelevaluering opdelt på grupper af mennesker og forhold, kendte begrænsninger og etiske overvejelser."},"plain":{"en":"Like the paper folded inside a box of medicine - what it treats, who should not take it, the known side effects and how it was tested.","da":"Som indlægssedlen i en æske medicin - hvad den virker mod, hvem der ikke bør tage den, de kendte bivirkninger, og hvordan den er afprøvet."},"inPractice":{"en":"Before a municipality's job centre uses an open model to sort letters from citizens, its data analyst reads the model card and sees it was tested mostly on English and does much worse on Danish.","da":"Før en kommunes jobcenter bruger en åben model til at sortere breve fra borgere, læser dataanalytikeren modelkortet og ser, at den mest er testet på engelsk og klarer sig markant dårligere på dansk."},"whyItMatters":{"en":"Without one, people build on models blind to their weak spots; a model card makes limits and unfair gaps visible and is a common way to meet documentation duties under AI rules.","da":"Uden et modelkort genbruger folk modeller uden at kende deres svage punkter; det gør begrænsninger og skævheder synlige og er en udbredt måde at opfylde dokumentationskrav i AI-regler på."}},"deepDive":{"en":"Mitchell et al. proposed model cards at FAT* 2019 with nine sections: model details (developer, date, version, type, licence, citation), intended use (primary uses and users, out-of-scope uses), factors (the groups, instrumentation and environments across which performance may vary), metrics (and why they were chosen, including decision thresholds and how uncertainty is estimated), evaluation data, training data, quantitative analyses, ethical considerations, and caveats and recommendations. The key technical idea is disaggregated evaluation: reporting metrics separately for each relevant factor and their intersections (for example skin type × gender in their face-analysis example), because a single aggregate accuracy hides subgroups where the model fails. Datasheets for Datasets (Gebru et al., 2018) is the companion practice for data.\n\nOn Hugging Face, the model card is the repository's README.md: a YAML metadata header (licence, language, library, pipeline tag, datasets, base_model, and a model-index block with structured evaluation results) followed by free-text Markdown. The base_model field lets the hub build lineage graphs for fine-tunes, adapters and quantisations, which is useful for supply-chain review. Frontier labs additionally publish system cards, which describe a deployed system - the model plus safety mitigations, policies and the results of red teaming and dangerous-capability evaluations - rather than the model weights alone.\n\nRegulation has turned parts of the card into obligations without prescribing the format. For general-purpose AI models, EU AI Act Art. 53(1)(b) and Annex XII require information for downstream providers, including intended tasks and acceptable-use policy, architecture and number of parameters, input and output modalities and formats, licence, and information on training data; Annex XI lists the fuller technical documentation owed to authorities. The General-Purpose AI Code of Practice (2025) supplies a Model Documentation Form covering these items. For high-risk systems, Art. 13 instructions for use and Art. 11 technical documentation (Annex IV) cover similar ground at system level. NIST AI RMF MAP and MEASURE functions expect comparable documentation of context, limitations and test results.\n\nCommon weaknesses: cards written once at release and never updated for new versions; benchmark results that are self-reported, measured under undisclosed settings or inflated by test-set contamination; missing disaggregated results, often because demographic labels are unavailable; vague out-of-scope sections; and silence on the training data, frequently for legal reasons. A deployer should therefore treat a model card as a supplier claim to verify, re-run evaluations on its own data and languages - Danish performance, for instance, is often weaker than headline English benchmarks suggest - and record the result in its own documentation.","da":"Mitchell et al. foreslog modelkort på FAT* 2019 med ni afsnit: modeldetaljer (udvikler, dato, version, type, licens, citation), tilsigtet brug (primære anvendelser og brugere, brug uden for rammerne), faktorer (de grupper, måleinstrumenter og miljøer, hvor ydeevnen kan variere), metrikker (og hvorfor de er valgt, herunder beslutningstærskler og estimering af usikkerhed), evalueringsdata, træningsdata, kvantitative analyser, etiske overvejelser samt forbehold og anbefalinger. Den centrale tekniske idé er disaggregeret evaluering: at rapportere metrikker for hver relevant faktor og deres kombinationer (fx hudtype × køn i deres eksempel med ansigtsanalyse), fordi én samlet nøjagtighed skjuler de undergrupper, hvor modellen fejler. Datasheets for Datasets (Gebru et al., 2018) er den tilsvarende praksis for data.\n\nPå Hugging Face er modelkortet repositoriets README.md: en YAML-header med metadata (licens, sprog, bibliotek, pipeline-tag, datasæt, base_model og en model-index-blok med strukturerede evalueringsresultater) efterfulgt af fri tekst i Markdown. Feltet base_model gør det muligt for hubben at vise slægtskabet mellem finjusteringer, adaptere og kvantiseringer, hvilket er nyttigt ved gennemgang af forsyningskæden. De store AI-laboratorier udgiver desuden system cards, der beskriver et system i drift - modellen plus sikkerhedsforanstaltninger, politikker og resultater af red teaming og evaluering af farlige kapabiliteter - og ikke kun modelvægtene.\n\nRegulering har gjort dele af kortet til pligter uden at foreskrive formatet. For AI-modeller til almen brug kræver AI-forordningens art. 53, stk. 1, litra b, og bilag XII oplysninger til efterfølgende udbydere, herunder tilsigtede opgaver og politik for acceptabel brug, arkitektur og antal parametre, input- og outputmodaliteter og -formater, licens og oplysninger om træningsdata; bilag XI opregner den fyldigere tekniske dokumentation til myndighederne. Adfærdskodeksen for AI-modeller til almen brug (2025) indeholder en Model Documentation Form, der dækker disse punkter. For højrisikosystemer dækker brugsanvisningen efter art. 13 og den tekniske dokumentation efter art. 11 (bilag IV) tilsvarende forhold på systemniveau. NIST AI RMF's MAP- og MEASURE-funktioner forventer lignende dokumentation af kontekst, begrænsninger og testresultater.\n\nTypiske svagheder: kort, der skrives én gang ved udgivelsen og aldrig opdateres for nye versioner; benchmark-resultater, der er selvrapporterede, målt under ukendte indstillinger eller pustet op af, at testdata er sluppet ind i træningen; manglende disaggregerede resultater, ofte fordi der ikke findes demografiske labels; vage afsnit om brug uden for rammerne; og tavshed om træningsdata, ofte af juridiske grunde. En idriftsætter bør derfor behandle et modelkort som en leverandørpåstand, der skal efterprøves, køre evalueringerne igen på egne data og sprog - ydeevnen på dansk er fx ofte svagere, end de engelske overskriftstal antyder - og notere resultatet i sin egen dokumentation."},"edges":[{"type":"requires","to":"ai/model-evaluation","confidence":"high","strength":"normal"},{"type":"requires","to":"ai/training-data","confidence":"high","strength":"normal"},{"type":"part-of","to":"ai/ai-governance","why":{"en":"Recording what a model is for and how it performs is a basic piece of governing how AI is used.","da":"At beskrive, hvad en model er til, og hvordan den klarer sig, er en grundlæggende del af at styre brugen af AI."},"confidence":"high","strength":"normal"},{"type":"mitigates","to":"ai/ai-bias","why":{"en":"Reporting results separately for different groups makes unfair gaps visible before the model is put to use.","da":"At rapportere resultater særskilt for forskellige grupper gør skævheder synlige, før modellen tages i brug."},"confidence":"medium","strength":"minor"},{"type":"used-with","to":"ai/open-weight-model","why":{"en":"Open-weight models are usually published on model hubs together with a model card describing them.","da":"Modeller med åbne vægte udgives som regel på model-hubs sammen med et modelkort, der beskriver dem."},"confidence":"high","strength":"normal"}],"depth":3,"sources":[{"title":"Mitchell et al., Model Cards for Model Reporting (FAT* 2019)","url":"https://doi.org/10.1145/3287560.3287596","tier":"reference","publisher":"ACM"},{"title":"NIST AI 100-1 - Artificial Intelligence Risk Management Framework (AI RMF 1.0)","tier":"standard","publisher":"NIST"}],"draft":true}