{"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://atlas.maintz.dev/)"},"id":"ai/model-card","url":{"en":"https://atlas.maintz.dev/en/terms/ai/model-card/","da":"https://atlas.maintz.dev/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."},"howTo":{"steps":{"en":["Name who writes the card - the developer for training details and results, someone with legal or ethics background for bias and risks, and a project owner for intended use and contact - and start from the Hugging Face annotated template or the sections in Mitchell et al.","Describe the model details and intended use, including primary users, and list out-of-scope uses concretely, such as decisions about individuals or languages it was not tested on.","Describe the training data and its sources, or link to a datasheet or dataset card, and say plainly what you cannot disclose and why.","Choose the factors that may change performance, such as language, dialect, age group or recording conditions, and report evaluation results separately for each of them, not just one overall score.","Record the evaluation settings (data, metrics, thresholds, decoding settings) so others can reproduce the numbers, and add results from safety testing and red teaming.","Write known limitations, biases and risks with recommendations for users, and fill the metadata (licence, language, datasets, base_model, evaluation results) so the card can be searched and traced.","For a general-purpose AI model placed on the EU market, check that the card together with your technical documentation covers the information for downstream providers in AI Act Art. 53 and Annex XII, for example using the Model Documentation Form in the GPAI Code of Practice.","Update the card with every new model version, and as a deployer treat other people's cards as supplier claims by rerunning key evaluations on your own data and in Danish before you use the model."],"da":["Udpeg, hvem der skriver kortet - udvikleren til træningsdetaljer og resultater, en person med juridisk eller etisk baggrund til bias og risici og en projektejer til tilsigtet brug og kontakt - og tag udgangspunkt i Hugging Faces kommenterede skabelon eller afsnittene hos Mitchell et al.","Beskriv modeldetaljer og tilsigtet brug, herunder de primære brugere, og list brug uden for rammerne konkret, fx afgørelser om enkeltpersoner eller sprog, den ikke er testet på.","Beskriv træningsdataene og deres kilder, eller link til et datasheet eller et dataset card, og sig klart, hvad I ikke kan oplyse, og hvorfor.","Vælg de faktorer, der kan ændre ydeevnen, fx sprog, dialekt, aldersgruppe eller optageforhold, og rapportér evalueringsresultater særskilt for hver af dem, ikke kun ét samlet tal.","Notér evalueringsopsætningen (data, metrikker, tærskler, decoding-indstillinger), så andre kan genskabe tallene, og tilføj resultater fra sikkerhedstest og red teaming.","Skriv kendte begrænsninger, skævheder og risici med anbefalinger til brugerne, og udfyld metadata (licens, sprog, datasæt, base_model, evalueringsresultater), så kortet kan søges frem og spores.","Tjek for en AI-model til almen brug, der bringes i omsætning i EU, at kortet sammen med jeres tekniske dokumentation dækker oplysningerne til efterfølgende udbydere i AI-forordningens art. 53 og bilag XII, fx ved hjælp af Model Documentation Form i adfærdskodeksen for AI-modeller til almen brug.","Opdatér kortet ved hver ny modelversion, og behandl som idriftsætter andres modelkort som leverandørpåstande ved at køre de vigtigste evalueringer igen på egne data og på dansk, før I tager modellen i brug."]},"pitfalls":{"en":["Writing the card once at release and never updating it, so it describes a model version nobody runs any more.","Reporting a single aggregate score that hides the groups or languages where the model fails.","Copying benchmark numbers from the supplier's card without knowing the settings or whether the test data leaked into training."],"da":["At skrive kortet én gang ved udgivelsen og aldrig opdatere det, så det beskriver en modelversion, ingen kører længere.","At rapportere ét samlet tal, der skjuler de grupper eller sprog, hvor modellen fejler.","At kopiere benchmark-tal fra leverandørens kort uden at kende indstillingerne, eller om testdataene er sluppet ind i træningen."]},"guides":[{"title":"Model Cards - Hugging Face Hub documentation","url":"https://huggingface.co/docs/hub/model-cards","publisher":"Hugging Face","tier":"official-doc"},{"title":"Annotated Model Card Template","url":"https://huggingface.co/docs/hub/model-card-annotated","publisher":"Hugging Face","tier":"official-doc"},{"title":"Mitchell et al., Model Cards for Model Reporting","url":"https://arxiv.org/abs/1810.03993","publisher":"arXiv","tier":"reference"},{"title":"The General-Purpose AI Code of Practice","url":"https://digital-strategy.ec.europa.eu/en/policies/contents-code-gpai","publisher":"European Commission","tier":"official-doc"}]},"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}