Reading the primary source: a model card, a system card, and what they do not say

So, on January 29, 2025, the most important document in the history of artificial intelligence basically dropped. Oh, absolutely. And what's fascinating is that it wasn't, you know, it wasn't some breakthrough algorithm and it wasn't a new piece of hardware.

Right. It was a report. Yeah, exactly.

Specifically, it was the first full international AI safety report. I mean, this thing was led by Yoshua Bengio. It was commissioned by 30 nations right after the Bletchley Park Summit and written by like 96 of the smartest minds on Earth.

Just a massive undertaking. Huge. It ran to hundreds of pages.

But if you talk to anyone in the governance space today, they don't even talk about what was in those pages. No, they really don't. They talk about what the report absolutely refused to do.

I mean, it made zero policy recommendations. It didn't tell governments what to ban. It didn't offer a single rigid framework or a definitive thou shalt not.

Which, honestly, completely broke the mold for how we expect the international summits to work. Right. Usually they want a soundbite.

Yeah. Usually when you get that many world leaders and experts in a room regarding a high stakes globally disruptive technology, the natural instinct of governance is to, well, draw a very clear, very heavy line in the sand. But they didn't.

No. Those 96 experts looked at the state of AI and realized that drawing a hard line was actually the most dangerous thing they could do because the ground was just moving too fast. Yeah.

So instead of dictating policy, they did something infinitely harder. They rigorously marked their own confidence on every single claim. I love that.

They separated the risks that actually had robust empirical evidence behind them from the risks that rested purely on laboratory modeling or theoretical math. And crucially, they stated out loud exactly where the evidence simply wasn't in yet. Exactly.

They embraced the muddy waters instead of pretending the water was clear. Which is so rare. And the report gave us this brilliant phrase for this reality.

They called it the evidence dilemma. The evidence dilemma. Yes.

It's just the fundamental problem of having to act like having to make massive consequential decisions before the definitive proof actually arrives. Because I mean, AI capabilities are scaling so much faster than the science of evaluating those capabilities. Right.

They're outpacing the science by miles. If you wait for perfect certainty, you're paralyzed. Right.

But if you pretend the evidence is stronger than it actually is, you're reckless. So the disciplined response to the evidence dilemma isn't to freeze and it isn't to guess. It's to size your deployment decision to the exact strength of the evidence you have in your hand at that exact moment.

Precisely. And that evidence dilemma is exactly what we are tackling in this deep dive today. Because if you're listening to this, you are likely that sharp, busy professional who actually has to make these high stakes deployment decisions.

You're in the franchise. Yeah. You're running governance or you're directing IT or leading a product team.

You have to sign your name on the line that says, yes, we are turning this AI on for our customers. And here is the catch. The documents you rely on to make that decision aren't written by 96 independent experts with a mandate to be intellectually honest.

Oh, not even close. You are reading vendor documentation. You are reading the materials provided by the very company selling you the software.

And navigating that transition from the academic standard of a safety report to the corporate reality of a vendor's technical documentation, that is like the most critical skill an operator can develop right now. It's the difference between actually governing your AI and just being a passenger on the vendor's hype cycle. OK, let's unpack this.

We're treating this as an executive master class today. Zero fluff. We need to define the actual materials you're going to be staring at on your screen when you make these calls.

Absolutely. So in the trenches, this usually comes down to two specific types of documents. First you have the model card.

Simply put, a model card is a short, structured document describing a trained model in the laboratory environment. It tells you what it is, what it was trained to do, where it excels, where it completely falls apart, and exactly how the vendor knows that information. It's essentially the spec sheet for the raw engine.

But you don't drive an engine, you drive a car. And that's where the second document comes in, the system card. While the model card describes that underlying engine on a test block, a system card describes the fully deployed product that is built around one or more of those models.

So it's got all the extras bolted on. Exactly. The system card is supposed to detail the guardrails, the output filters, the user interface constraints, the human oversight mechanisms, and all those residual risks that remain even after the vendor has tried to mitigate the dangers.

The engine versus the car, I really like that analogy. So if I'm buying an API to power, say, a customer service chatbot, the model card tells me how smart the raw language model is, but the system card tells me if the vendor actually put a filter in place to stop it from swearing at my customers. Precisely.

The system card represents the reality of the software you are actually integrating into your tech stack. Which brings us to a really uncomfortable reality about these documents. Because vendors are now legally mandated to provide them in many jurisdictions, they aren't just dry technical manuals anymore.

No, they're highly strategic assets. Right. And this is the first foundational rule we have to establish.

It's the lens through which you must read every single word. Here's the core idea. The card is a primary source written by an interested party.

Let's pull that apart, starting with the legal reality you just mentioned. Under the European Union AI Act, specifically Regulation EU 2024-1689 as of August 2, 2025, providers of general purpose AI are legally required to supply this technical documentation to you, the downstream deployer. They have to hand it over.

They have to give you a detailed summary of the training content, the capabilities, and the limitations. And the law expects you to actually read it. It's not just a box to check.

The FTC guidelines in the U.S. regarding deceptive claims operate on a very similar wavelength, right? Absolutely. Your entire compliance posture, your legal defensibility assumes you are receiving this documentation and using it as the foundation of your governance. So you can't just say, oh, well, I read a really great teardown of this model on a tech blog, so I figured it was safe.

No. A tech blog is a secondary source. A leaderboard is a secondary source.

The vendor's card is the primary source. It's the original document from which all those downstream summaries and hot takes are derived. And you are entirely responsible for the claims made in that primary source.

You are. But, and this is the massive flashing red light here, you are reading a primary source authored by the party with the strongest possible financial interest in you saying yes to their product. I mean, they have a product launch to worry about.

They have quarterly earnings. They have a marketing adjacent team that likely had a heavy hand in drafting or at the very least heavily editing that card right up until the midnight deadline. Yeah.

Even the most conscientious engineering driven vendor and, you know, they're phenomenal ones out there. They still have to run these documents through legal and PR. Which means the vendor gets to choose what to foreground, what to put in a giant bold font, what to phrase very gently and what to omit entirely.

They choose their own confidence markers. You know, it's funny, when I look at a restaurant menu and the menu says we use world famous pristine premium ingredients, my brain instantly translates that to marketing fluff. Right.

I don't treat the menu as a health inspection grade. No one does. I know the chef wrote it to sell me a $20 burger.

That's a phenomenal analogy. But because these model cards are formatted like scientific papers, I mean they have abstracts, they have charts, they use Greek letters for mathematical formulas, we completely drop our guard. We read a menu and treat it like an independent safety audit.

The formatting is literal camouflage. Because it looks like an academic paper, you assume academic neutrality. But you legally cannot skip reading the menu because the law says the menu is your starting point.

So you're stuck with it. You are. You just have to learn how to read the menu like a forensic accountant rather than a hungry diner.

You have to strip away the polish and isolate the actual operational truth. So how do we actually do that? If I have a 20-page PDF in front of me and it's beautifully formatted and full of really reassuring language, how do I break it down? You do it by fundamentally changing how you process the English language. Yeah.

You can't read it like a novel. You have to break every single sentence you read into one of three distinct registers. The three registers.

When you scan a paragraph, you must categorize every line. Every single line is either a claim, a hedge, or a silence. Okay.

Let's take those one by one. I really want to build a mental framework for this. What qualifies as a claim? A claim is a firm assertion backed by stated evidence that could, in principle, be checked or reproduced by you.

It is falsifiable. Okay. Give me an example.

So if a vendor card states, on the MMLU benchmark, the model scored 88.7 percent, that is a claim. Why? Because it names a specific known test, the MMLU. It names the specific number 88.7, and it implies a specific condition.

You could literally go look at the MMLU, see what questions it asks, and prove that number of true or false. But just because it's a claim doesn't mean it's practically useful, right? Like, if they just say 91.2 percent accuracy, my immediate thought is, on what? Accuracy on a math test. Accuracy on identifying images of dogs.

Exactly. And that is a very specific trap we call a masked claim. A masks claim.

Yeah. It is a cousin of the claim that you have to learn to spot instantly. A masks claim gives you a highly specific number, which makes your brain think it's rigorous, but it strips out the exact condition that makes it checkable.

So it's useless. Completely. 91.2 percent accuracy, with no benchmark named, no data split defined, and no demographic population specified is entirely unusable.

It's an illusion of precision. As an operator, you must treat a masks claim as a completely invalid data point until the vendor supplies the missing context. Okay.

So a true claim has the metric, the number, and the condition. That's our first register. What's the second? The second register is the hedge.

And this is where legal and marketing teams earn their salaries. A hedge is a sentence engineered to sound exactly like a firm claim, but it commits to absolutely nothing falsifiable. Meaning, if I test it? If you try to test it, you'll find there's nothing to actually test.

Give me an example. What does a hedge look like in the wild? You will see phrases like, the model is designed to be safe, or it demonstrates strong performance across a wide range of tasks, or we've invested heavily in reducing harmful output. Designed to be safe.

Man, I see that everywhere. It sounds incredibly reassuring. It sounds reassuring, but look at the mechanics of the sentence.

Designed to be is an expression of the vendor's intention, not a measurement of the model's actual outcome. Ah, right. A car can be designed to be safe and still have the brakes fail on the highway.

The statement wasn't a lie, they intended it to be safe, but it carries zero operational information for you, the driver. Same with strong performance. Exactly.

Strong compared to what baseline? A wide range of tasks. Which specific tasks? A hedge is built to survive public scrutiny and legal liability without giving you anything you can hold them to. I want to put this into practice.

Let's do a quick micro-reading exercise. Imagine I am sitting at my desk, and I'm looking at a fictional vendor card for an enterprise product. We'll call it SafeReply.

It's an AI that drafts responses to customer emails. Okay, SafeReply. I'm going to read a short paragraph from their executive summary, and I want you to break it down.

Let's do it. Okay, sentence one. Our model achieves 91.2% accuracy on the industry standard SafeReply benchmark.

That goes in the claim bucket. Yeah. It names a specific metric and a specific test.

If you were physically marking up this document, you would highlight that sentence in yellow. Yellow for claim. Got it.

Now, just because it's in yellow doesn't mean you automatically trust it. You still have to ask if the SafeReply benchmark actually resembles the kind of emails your real customers write. But structurally, it is a claim.

It is checkable. Okay, sentence two. It is designed to be helpful and safe across a broad range of customer interactions.

Pure hedge. Highlight it in pink. Designed to be is an intention.

Broad range is undefined. Helpful and safe are subjective adjectives with no mathematical backing. It's just a vibe.

It's totally vibe. Okay. If a customer uses the AI to generate a legally disastrous email, the vendor can point to this exact sentence and say, hey, we only said it was designed to be safe.

We didn't guarantee it would be safe in your specific interaction. Pink. Meaningless.

Sentence three. We have invested heavily in reducing harmful outputs. And honestly, if I'm reading this fast and I'm stressed, I read invested heavily and my brain just checks a mental box that says safety handled.

Which is precisely the psychological effect it was engineered to produce. But think about it operationally. Investment is an input.

It is not an outcome. Right. You can waste a lot of money.

Exactly. A company can spend $2 billion on a safety team and still reduce harm by absolutely 0% if their methodology is flawed. It is a hedge wearing the costume of corporate diligence.

Pink highlight. So when I have a page covered in pink highlighter, what do I actually do? I can't just throw the document away. As an executive, what is my physical action to neutralize a hedge? You neutralize a hedge by rewriting it in the margins as the exact question it is dodging.

You convert their vague reassurance into your precise interrogation. Oh, I like that. So when they say designed to be safe across a broad range of interactions, you grab a pen and write.

Were your specific interactions were tested for safety? By what exact measure and what was the failure rate? You don't accept the hedge. You isolate the missing data it's trying to hide. Which brings us perfectly to the third register.

We've talked about what is physically on the page, the yellow claims and the pink hedges. But the most dangerous register isn't printed in the document at all. No, it's not.

The core idea here is that silence is not safety. We define a silence as an operator-relevant fact that simply isn't in the document. And silences are lethal because absence does not announce itself.

A hedge at least gives you a sentence to highlight in pink. A silence gives you nothing. Your brain naturally assumes that if a massive, sophisticated tech company didn't mention a risk, the risk must not exist.

Exactly. Right. If I'm reading a card for a translation model and it doesn't mention how it performs in Arabic, I don't consciously think, wow, they have zero evidence for Arabic.

I usually think, well, it's a global model. They probably handled it. And operationally, for you making a deployment decision, that assumption is a massive liability.

If a card says nothing about non-English performance, it has not told you it is safe in other languages. It has provided zero evidence. And in governance, no evidence equals a no for deployment.

Let's go back to our safe reply example. Those three sentences sounded so confident. But what were they actually silent on? Think about what wasn't there.

It never stated a training data cutoff date. It never named the languages it was evaluated in. It never provided a disaggregated failure rate.

Meaning, like, does it perform worse on high-stakes messages like refunds compared to low-stakes messages like password resets? Exactly. And it never gave a version or build date. That's five critical silences hidden behind a wall of polished text.

Imagine if those 96 experts from the AI Safety Report had written that safe reply excerpt. If they were forced to mark their own confidence and break their silences, what would it actually sound like? Oh, it would be a completely different document. A rigorous Safety Report-style version of that exact same system would read like this.

On the safe reply benchmark, Build 2026-03 scored 91.2% overall, broken down. 94% on billing questions, 88% on complaints, and 79% on refund disputes, which is our weakest category. Validated in English only, we did not evaluate other languages, known failure.

The model will occasionally state a refund policy detail that the deploying organization has not configured. Wow, okay. That is night and day.

It shifts entirely. The accuracy line is now actionable because it names a specific build date. The language scope is explicitly stated English only.

But most importantly, the vendor is volunteering their weakest category, that 79% on refunds, rather than burying it inside that 91.2% aggregate average. And they explicitly name a testable failure mode, policy fabrication. I would infinitely rather have those two lines of genuine bad news than the whole paragraph of polished hedges.

Because if I know it fabricates refund policies, I can build a filter for that. Exactly. I can train my human reviewers to specifically look for fake refund policies.

I can manage a known risk. I cannot manage a hedge. Specificity is trust.

The more specific they are about their failures, the more you can trust their claims about their successes. But let me challenge this idea of hunting silences, because the reality of these documents is getting kind of absurd. If I pull a system card from a top-tier frontier lab, let's say the Anthropic Claude Opus 4.5 system card from November 2025, that document is literally 200 pages long.

Yes, it is. It has massive appendices. It has external red teaming reports.

If a document is 200 pages of dense technical evaluation, surely a silence just means the risk genuinely doesn't exist. I mean, they wouldn't just forget to test a major limitation in a book-length document. That is one of the most dangerous assumptions an executive can make today.

You are confusing length with completeness. Really? Yes. Length creates reader fatigue.

A 200-page card can easily bury an operator-relevant limitation inside 199 pages of entirely unrelated, highly complex evaluation. When a document is that long, the risk isn't that it's thin. The risk is that you get tired by page 40, you see how much work they did on, say, bioweapons safety, and you just assume they must have also covered your specific customer service use case.

Oh, wow. Yeah, you just tap out and trust them. So how do you combat the fatigue? How do you hunt a silence in a document that massive without losing your mind? You hunt silences by holding a fixed, uncompromising checklist of what a complete card must answer for your specific deployment, regardless of whether the card is three pages or 300 pages.

You don't read to see what they have to say. You read to see if they answered your specific list of questions. Which means we need to know how to build that checklist.

We need to know exactly where to look in these massive documents. And that brings us to the architecture of the cards themselves. There are specific sections that carry immense legal and operational weight.

Yes, the load-bearing sections. We can call them the load-bearing sections. And the core idea here is that out-of-scope language shifts liability to you.

This is critical. Every rigorous card will have a section for intended use and a section for out-of-scope use. The intended use tells you exactly what the vendor actually validated the model for in their own labs.

And the out-of-scope? The out-of-scope use tells you the specific scenarios the vendor explicitly refuses to stand behind. Right. But be honest.

Most people treat the out-of-scope section like the Terms of Service on a software update. They just scroll right past it because it feels like standard legal boilerplate. And that is exactly how you end up in front of a compliance committee or a regulator.

Out-of-scope language isn't just boilerplate. It is a quiet, deliberate transfer of liability from the vendor to you. Wait, explain that.

If you decide to deploy a customer support model to triage incoming clinical messages at a hospital, and clinical triage is listed as out-of-scope in the vendor's card, deploying it puts the full legal and operational risk entirely on your organization. Wait, so it's like if I go hiking in a national park and the park ranger puts up a massive wooden sign that says, Trail not maintained beyond this point. If I read that sign, ignore it, keep walking and fall into a ravine, I can't sue the park.

The park is already on the public record saying I was explicitly warned. Is that what out-of-scope does to a company? That is the perfect analogy. Walking past the sign doesn't magically make the rugged trail safe.

It just makes you entirely liable for your own rescue. When a vendor puts a use case in the out-of-scope section, they are hammering that wooden sign into the ground. If your use case fails, the vendor will point directly to that section and say we told them not to do it.

Okay, so intended use and out-of-scope use are massively load-bearing. What other sections actually carry weight? Let's look at the evaluations and metrics section. The single most important thing you are hunting for here is disaggregated evaluation.

You mentioned that briefly earlier with the refund example. Let's dig into the mechanics of that. What exactly is a disaggregated evaluation and why is it so vital? Disaggregated evaluation means the performance data is broken down by specific groups, specific demographic cohorts, specific languages or specific conditions, rather than being rolled up into one massive generalized aggregate score.

Because an aggregate score can hide a catastrophic failure in a minority of cases. Exactly. If I tell you a system has a 95% accuracy rate, you feel great.

But if that system processes data for 100 people and it is 100% accurate for 95 of them, but has a 0% accuracy rate for a specific minority group of 5 people, that is a catastrophic systematic failure for that group. The aggregate score of 95% completely masks the localized disaster. This reminds me of the Epic sepsis prediction case.

That was exactly this dynamic, wasn't it? Yes. The Epic sepsis prediction model is the textbook case study for why aggregate numbers are dangerous. Epic deployed a clinical model designed to predict sepsis in patients.

Based on its aggregate reputation and initial metrics, it looked stellar. It was widely deployed across hundreds of hospitals. But when independent researchers actually validated it externally out in the real world across different demographic and clinical conditions, they found that its real-world performance was far worse than the aggregate score suggested.

It was missing critical cases and generating massive amounts of false alarms in specific clinical contexts. Because the initial high score was an aggregate that smoothed over all the messy localized failures. Precisely.

When a model card gives you a single aggregate number for a test, the silence is the breakdown. You have to ask, show me the performance across different age groups, different skin tones, different language dialects, different hardware setups. If they don't provide that disaggregated data, you have a massive silence on your hands.

Let's move to the limitations section. I feel like this is another place where vendors try to hide bad news in plain sight. Counterintuitively, a long, highly specific limitations section is actually a massive signal of trust.

As we said before, specificity is trust. If a vendor writes, the model frequently fabricates policy details for events occurring after January 2024, that is a highly actionable claim. It is bad news, but it is useful bad news.

Because they can build a business process around it. Right. But if the limitation section just says, as with all AI systems, this model may produce inaccurate information, review all outputs.

That is not a limitation, it is a generic disclaimer. It's just covering their bases. It is a hedge that protects the vendor legally, but helps you, the operator, not at all.

If you cannot write a specific test that would trigger this stated limitation, it's just a disclaimer. What about the training data section? Especially with the new EU AI Act rules requiring summaries of training content, how do we read that section? You are looking for strict, unambiguous cut-off dates, and you are looking for the composition of the data. Does the card just say, trained on a large corpus of public internet data, or do they tell you the exact languages represented in the percentages of each? And increasingly, you must look for the synthetic share of the data.

Meaning data generated by other AI models, rather than collected from human sources. Yes. How much of this model was trained on the output of another model? We are seeing the consequences of training data opacity everywhere.

Look at the massive controversies around hardware vendors and data collection. We saw a stark cautionary tale with the Roomba images case a few years ago. Right.

Where sensitive, intimate images taken inside people's homes by autonomous vacuums ended up on social media because of the data annotation pipeline. Exactly. The hardware collected the data, but the pipeline involved sending those images to human gig workers for annotation to train the computer vision models, and those workers leaked the images.

Unbelievable. That case exposed a massive gap between what consumers assumed was happening and the reality of the training data supply chain. If a vendor card from 2026 is completely silent on where its training data comes from, how it was annotated, or what its synthetic data share is, they are withholding a fact that fundamentally shapes the model's blind spots and your liability.

Okay, so that covers the model card side. But if we are looking at a system card, the deployed product, what is the load-bearing section there? In a system card, you must interrogate the system guardrail section, and you have to be hyper-vigilant for what we call oversight theater. Oversight theater.

I love that term. I assume that means human-in-the-loop steps that look great in a PowerPrint presentation but are practically useless? Exactly. It's a process designed to satisfy auditors on taper, but it fails entirely in actual daily practice.

Vendors love to say, we ensure safety by keeping a human-in-the-loop for sensitive decisions. So how do you spot oversight theater in a document? What's the test? You run the three test questions against their claims of human oversight. Question one, what does the human actually see on their screen? Do they see the raw, full context of the model's output and the user's input, or do they just see a filtered, condensed summary? Okay, what's two? Question two, how much time do they have to make the decision? Are they expected to review a highly complex clinical or financial decision in three seconds, or do they have 10 minutes? And question three, can they actually overrule the system's decision, or can they only flag it for some downstream committee to look at later? So, if the reviewer is looking at a two-sentence summary, has a quota that forces them to act in three seconds, and can only click a flag button instead of actually stopping the action.

That is oversight theater. Statistically, a three-second review window is identical to zero review. The human is just a liability sponge.

A liability sponge? Wow. They are there so the vendor can blame the human when things go wrong. If the system cart doesn't explicitly define the parameters of the human review of what they see, the time allotted, and their veto power, that is a massive silence.

This is blowing my mind a bit, because you can do everything right. You can perfectly read all these load-bearing sections, you spot the hedges, you document the silences, you highlight the claims, you expose the oversight theater. But that brilliant, meticulous reading is completely useless if the document you are holding describes a reality that no longer exists.

Oh, absolutely. Which brings us to the fifth core idea you have to master. Check the version and date first.

If you do not do this, you are building a castle on sand. The core concept you have to understand here is behavior drift. Behavior drift is a well-documented phenomenon where a model's behavior changes dramatically between back-end versions, often while maintaining the exact same stable product name, and frequently with zero public changelog from the vendor.

So the API endpoint I am calling today might behave completely differently than the exact same endpoint I called last Tuesday. Yes. Stanford researchers conducted extensive studies on behavior drift over the last few years.

They proved conclusively that a stable product name, like GPT-4 or Quad-3, does not mean a stable model underneath. An API endpoint can shift its outputs, its formatting, its mathematical accuracy, and its failure modes overnight, because the vendor pushed a silent back-end update to optimize speed or safety. So a vendor card that doesn't have a specific build version and a publication date isn't a technical document, it is just a rumor.

It's a snapshot of a ghost. That is exactly what it is. The very first practical step you must take before you read a single word of the evaluation is checking the date on the card against the vendor's actual status page, or their release notes.

If the model card is dated March 1st, and the vendor pushed a silent update to the model on April 15th, that document might be describing an endpoint you are no longer even calling. Which means every single metric in that card is potentially invalidated. Yes.

That specific uncertainty version parity must go at the absolute top of your silence list before you do anything else. If you don't know what version you are reading about, the document is operationally useless. Let's take every abstract concept we've just discussed, the three registers, the silences, the shifting liability, the oversight theater, the versioning drift, and watch a sharp professional actually apply them to a high-stakes corporate decision.

I want to see what this looks like in the real world. Let's walk through an immersive scenario with Irene at Harborline. Let's set the stage.

Irene runs AI governance for a fictional mid-sized logistics firm called Harborline. She is about to route thousands of live customer service messages through a new LLM supplied by an outside vendor. This isn't a pilot.

This is production. So the stakes are real. The final deployment decision is hers to sign.

Her director hands her a 12-page vendor model card and explicitly tells her to read it with the same discipline as the International AI Safety Report. So it's a Friday afternoon, Irene sits down at her desk, she prints the card out, and she grabs three physical highlighters, yellow for checkable claims, pink for the hedges that sound firm but mean nothing, and she puts a blank piece of paper next to her keyboard to write down the silences. She starts with the intended use section.

She reads the first line. The card claims the model is validated for customer service assistance, including summarization and drafting in English. Irene highlights that in yellow.

It is specific. It is a claim. It is checkable.

But Irene knows her own business. Here is the operational reality. Harborline's logistics customers regularly write in English, Portuguese, and Cantonese.

So Irene immediately grabs her pen and turns to her blank page. She writes, Silence. No evaluation in Portuguese or Cantonese.

Card is silent on non-English performance. The vendor didn't say it was bad at Cantonese, they just didn't mention it, but the omission just told her exactly where her deployment is legally and technically uncovered. Exactly.

Next, she moves down to the evaluation section. She reads, The model demonstrates strong safety performance across our internal benchmarks. Irene takes her pink highlighter and strikes through the entire sentence.

It is a massive hedge. Strong compared to what? What constitutes an internal benchmark? She goes back to her blank page. She writes, Silence.

No disaggregated breakdown for high-stakes messages like customer complaints or refund requests. She knows that logistics is all about refunds and lost packages. If the card doesn't break out performance for refunds, she has zero evidence it works for her most critical use case.

Then she hits the limitations section. She finds a sentence that says, The model may produce confident false text about recent events. She highlights that in yellow.

That is actionable bad news. She knows she can build a guardrail for that. She can restrict the model from answering questions about delays that happened in the last 24 hours.

Nice. But the very next sentence says, Human review recommended for sensitive cases. Pink hedge.

Because sensitive is undefined. Recommending review without specifying the parameters is just oversight theater prep. Exactly.

Finally, Irene does the drift check. She flips to the front page to look for the version. The card has a date, but the version is just the product's marketing name, Harbor Assist Pro, not a specific back-end build number.

She pulls up the vendor's online status page and discovers that the model behind that marketing name was silently updated six weeks ago. The 12-page card she is holding predates the update. Wow.

So, at the very top of her blank page, she writes and underlines in red ink, This card may not describe the model we are calling today. Behavior drift is possible since the last update. And this is where the dynamic in the company fundamentally changes.

Think about what happens when Irene's director walks back into her office an hour later and asks if they are blocked from launching on Monday. If she hadn't done this reading, she would just say, Um, I feel nervous about this. It seems risky.

And she gets branded as the anti-tech compliance roadblock. She loses political capital. But because of her evidence dilemma stance, her political footing in the room is rock-solid.

She doesn't say they are blocked. She says they are precise. She is the only professional in the room armed with documented facts about what the primary source actually supports.

Her precision dictates her exact actions. He tells the director, We are officially halting the Portuguese and Cantonese deployment paths right now because there is zero evidence in the primary source to support them. Then, she takes the English refund messages and reproduces the safety claim herself on Harbourland's own historical data.

She runs a test. Yes. And in doing so, she discovers a hidden flaw where the model literally fabricates Harbourline's specific refund policies, a flaw the vendor's aggregate benchmark completely hid.

And finally, she doesn't just complain to the vendor. She sends four specific written questions directly to her vendor rep. 1. What is the training cutoff date? 2. What languages were formally evaluated? 3. What is the disaggregated failure rate specifically on refund logic? And 4. Does the current live build match this published card? Irene's story perfectly illustrates the final core concept we need to cover.

A close reading does not revolve uncertainty. It makes it precise. The goal of reading a 200-page system card isn't to give the vendor's prose a letter grade.

It is to generate an exact punch list of next steps. We call this workflow the verify or ask split. Every single gap, every pink hedge, every silence you wrote down on your blank page gets split into two distinct columns.

Let's break down those columns. Column A is Verify Myself. Column A is for the claims that you can and must reproduce on your own proprietary data.

If the vendor claims high accuracy on routing refund tickets, you do not trust their lab test. You run 500 of your own actual historical refund tickets through the model and you measure the real result. You verify it in your own environment.

And column B is Ask Vendor. These are the facts that only the vendor holds in their black box. Things you physically cannot test.

What was the exact training data cutoff date? Which specific languages were evaluated before launch? You send these questions to the vendor in writing. But as you were filling out these columns, you will inevitably run into a very common problem, conflicting information. What happens when you have multiple sources of information about a model and they disagree with each other? How do you rank them? That's a great point.

Because the marketing website might say one thing, the CEO's keynote says another, and the model card says a third. You must adhere to a strict hierarchy of truth. At the absolute top of the hierarchy is your own reproduced test on your own data.

That is ground truth. Nothing beats that. Directly below that is the vendor system or model card, because that is their most legally freighted document.

Below the card is the vendor's marketing material, their sales deck, their blog posts. And finally, at the absolute bottom are third-party leaderboards, which are often highly generalized, easily gamed, and sometimes contaminated by data leakage. So if the sales deck promises fully autonomous issue resolution, but the model card says designed to assist human agents, you believe the card.

We have seen massive enforcement actions around this exact discrepancy. Regulators are actively penalizing companies for AI-washing situations, where a company's marketing claims vastly outran their actual engineering reality. Regulators look at the gap between the glossy sales deck and the technical system card.

You must do the same. If the card doesn't support the sales pitch, the sales pitch is a liability. But let me ask you the most pragmatic question of this whole process.

What happens if you send your column B questions to the vendor in writing, and they just refuse to answer? What if the vendor rep emails back and says, we consider our training cutoff date to be proprietary competitive information, so we declined to share it? It feels like a roadblock, but a declined or evasive answer is still data. It is highly valuable evidence for your governance file. If they will not confirm the training cutoff, you log that explicit refusal in your due diligence document.

You literally write down, vendor explicitly refused to confirm cutoff date. So you just document the stonewall. Exactly.

That refusal dictates that you must size your reliance on the model accordingly. You must assume the worst case scenario for its knowledge cutoff, and build your guardrails around that assumption. Because if it ever goes to court, you have the paper trail proving you tried to find the edge of the evidence, and the vendor stonewalled you.

Exactly. All of this work, the highlighters, the blank page, the testing, the emails to the vendor, culminates in creating your final artifact. We call this the source reading note.

The source reading note. This is the output. This is a one-page document you create that summarizes your entire reading process.

It lists the verified claims, the remaining silences, the results of your column A tests, and the vendor's answers or refusals from column B. It goes straight into your governance evidence annex. It is your proof that you didn't just deploy and pray. And crucially, it goes to your successor.

Or to you, three months from now. Because when the vendor inevitably pushes a massive update to the model, you don't have to start from scratch. This single page tells you exactly which load-bearing claims you need to retest.

It tells you exactly what failed last time. It makes your standing watch over this technology cheap, efficient, and targeted, instead of a frantic scramble every time the API changes. We've covered massive ground today.

We've gone from the academic purity of the International AI Safety Report to the messy, liability-laden reality of corporate vendor cards. To summarize the core philosophy, the model card is the start of your evidence chain, not the end of it. Your close reading of the core tells you exactly what you need to test, and the results of your tests tell you whether you actually deploy.

But I want to leave you with a final reflection on the illusion of documentation. Just because a file exists in a repository and it has the title model card at the top tells you absolutely nothing about its utility. That is so true.

If you go look at public model repositories today, you will find thousands of auto-generated stub files. They have the bold headers for limitations and out-of-scope uses, but the paragraphs underneath are left completely blank. The template is there, but the bad news is missing.

A missing card, or a blank section in a stub template, is a maximal silence. It is the loudest silence possible. And regulators have repeatedly found, in case after case, that a missing or intentionally vague model card is almost always sitting right on top of a massive product misrepresentation.

If they won't write it down, they know it won't hold up. Which brings us to the single most valuable move you can make on Monday morning when you get back to your desk. I want you to pull the primary vendor card for your organization's highest stakes AI system.

The one that keeps you up at night. Look at the publication date on that document. Then immediately go to the vendor status page or release notes.

If that model has been updated since that card was published, even a minor point release, you must assume the document in your hand is stale. Put version parity at the very top of your silence list and email your vendor rep immediately to ask if the current live build actually matches the published card. Because if you don't demand the evidence, you are operating on an illusion of precision.

You're walking past the sign on the trailhead, hoping the bridge hasn't washed out. Have the discipline to state exactly where the evidence stops and act accordingly. Thanks for joining us on this deep dive.