AI Model Card Usability & Developer Trust Survey

Welcome! This survey explores your experience with model cards and how model limitations influence your workflow. Your participation is voluntary — you may stop at any time. There are no right or wrong answers; we are interested in your honest opinions. All responses are anonymous and will be reported in aggregate only. Estimated time: 8–10 minutes.

In the past 6 months, how have you worked with ML models? Select all that apply.

• Implemented or fine-tuned models in code
• Consumed prebuilt APIs/SDKs
• Evaluated model performance for a project
• Selected vendors or models for deployment
• Wrote or maintained documentation
• None of the above

How familiar are you with model cards?

• Very familiar — I regularly read and apply them
• Somewhat familiar — I've read a few
• I've heard of model cards but I'm not sure what they include
• Not familiar — I've never heard of them

Based on what you currently know, which information would you expect to find in a model card? Select all that apply.

• Intended use and out-of-scope uses
• Training data sources and collection methods
• Evaluation metrics and methodology
• Performance across subgroups or conditions
• Known limitations and failure modes
• Safety/ethics considerations
• Versioning and change history
• Licensing and usage terms
• Contact/support information
• Deployment requirements and constraints
• I don't know / not sure
• Other (please specify)

Quick primer: A model card is a concise report that outlines a model's intended and out-of-scope uses, data provenance, evaluation methods and results (often across subgroups), known limitations and failure modes, and relevant safety/ethical notes. It helps you judge fit and risks before integrating a model. Please keep this definition in mind for the remaining questions.

If a model card is available, how likely are you to read it before using the model?

From the model cards you've reviewed, which elements were commonly included? Select all that apply.

• Intended use and out-of-scope uses
• Training data sources and collection methods
• Evaluation metrics and methodology
• Performance across subgroups or conditions
• Known limitations and failure modes
• Safety/ethics considerations
• Versioning and change history
• Licensing and usage terms
• Contact/support information
• Deployment requirements and constraints

In the past 3 months, how often did you consult model documentation when integrating models?

• Every integration
• Most integrations
• Sometimes
• Rarely
• Never
• Not applicable — I haven't integrated models recently

In model cards you've used, how easy was it to locate limitations and failure modes?

In general, how easy do you think it would be to find a model's limitations in a typical model card?

How confident are you in using a model card to judge a model's suitability for a safety-critical deployment (e.g., healthcare, autonomous systems)?

How confident are you in using a model card to judge a model's suitability for a fairness-sensitive application (e.g., hiring, credit scoring)?

How confident are you in using a model card to judge a model's suitability for a latency-sensitive production system (e.g., real-time inference)?

Have you ever discovered a model limitation that was not documented in its model card?

• Yes
• No
• Not sure

Please briefly describe the undocumented limitation and how you identified it.

Rank the following limitation factors from most to least important when selecting a model.

1. Accuracy on out-of-distribution data
2. Biased outcomes for specific subgroups
3. Privacy or data leakage risk
4. Robustness to adversarial or prompt attacks
5. Interpretability/traceability gaps

When limitations are unclear or missing, what do you typically do? Select all that apply.

• Run targeted tests or benchmarks
• Search issues/forums or community reports
• Contact provider or open a ticket
• Read source paper or repository docs
• Switch to a different model
• Proceed with extra monitoring/guardrails
• Defer or block the integration
• Other (please specify)

Which format would make model limitations most actionable for you?

• One-page summary with key facts
• Table with metrics by subgroup
• Risk checklist with mitigations
• Traffic-light risk labeling
• Interactive examples and failure cases
• Link to detailed paper/appendix
• Other (please specify)

Overall, how much do you trust model cards to accurately represent a model's capabilities and limitations?

Based on your responses in this survey, do you have any suggestions to make model cards clearer or more actionable?

We'd like to explore your experiences with model cards a bit further. Our AI moderator will ask a couple of follow-up questions based on your earlier responses.

What is your primary role?

• Backend/Full-stack Engineer
• ML/AI Engineer
• Data Scientist/Analyst
• Researcher
• Product Manager
• SRE/DevOps
• Security/Privacy Engineer
• Technical Writer
• Student
• Other

How many years have you worked professionally with ML/AI (in any capacity)?

• 0–1
• 2–4
• 5–7
• 8–10
• 11+
• Prefer not to say

What is your organization's approximate size (total employees)?

• 1–10
• 11–50
• 51–200
• 201–1,000
• 1,001–5,000
• 5,001+
• Prefer not to say

Which region are you primarily based in?

• Africa
• Asia
• Europe
• Latin America & Caribbean
• Middle East
• North America
• Oceania
• Prefer not to say

Which programming languages do you primarily use when working with ML models? Select all that apply.

• Python
• JavaScript/TypeScript
• Java
• C/C++
• Go
• Rust
• R
• Swift/Kotlin
• Other
• Prefer not to say

Which industry best describes your work context?

• Technology
• Finance
• Healthcare
• Retail/E-commerce
• Media/Entertainment
• Education
• Government/Nonprofit
• Other
• Prefer not to say

Thank you for your time! Your feedback will help improve how model cards communicate limitations and support better integration decisions.