Before your client sees a subcontracted AI demo, you run it once without the subcontractor in the room. You run it on data shaped like theirs, not on a fixture that flatters the model. You include the case where the answer is wrong, and you can say why, without turning your head. If you cannot open it, if their real mess is not in the room, or if a second firm's name is on the screen, the meeting is a rehearsal of someone else's product. Do not put your name on it yet.
This is the hour before the calendar invite. It is not the subcontract, and it is not the list of what you still have to own when the work is AI. The clauses — assignment, non-solicit, who may speak to the client — are already a document or they are not. The model-vendor organisation, the production keys, and the golden set are a different inventory. Both can be in perfect order while the demo you are about to show still only works on a laptop you do not control. The client will not audit your files. They will watch the screen. The screen is the claim. Whether they should already know the other firm's name is when to tell a client you subcontract. What the brief had to hold so the build could read as yours is what a white-label brief must hold. This hour assumes both of those are settled.
You can open it alone. The URL, the login, and the corpus have to work after the subcontractor has left the call. A demo that requires their screen share is a performance with a single point of failure, and the failure mode is ordinary: their laptop sleeps, their VPN drops, their engineer is in another meeting. NIST's AI Risk Management Framework says the MEASURE function exists so that performance is demonstrated, and the measures are documented, rather than narrated (NIST, AI RMF 1.0, January 2023). Documentation here is not a slide. It is you, the night before, producing the same answer the meeting will depend on. If the only person who can produce it is not in your firm, you have not taken delivery of the demo, whatever the subcontract says about intellectual property. What you keep when you subcontract the system itself — the organisation on the model account, the keys, the set you can re-score — is a separate article. This gate is narrower. Can you open Tuesday's build on Wednesday morning.
The data is shaped like the client's. MEASURE 2.3, in Table 3 of the same framework, says AI system performance or assurance criteria are measured qualitatively or quantitatively and demonstrated for conditions similar to the deployment setting, and that the measures are documented. A fixture of three clean paragraphs is not a condition similar to a client whose records are scanned, duplicated, and written in three formats. The happy path on the fixture can be perfect and still fail 2.3, because 2.3 is about the setting, not about the politeness of the answer.
Count the table before you turn 2.3 into a slogan. Table 3 lists 22 subcategories under MEASURE: three under category 1 (1.1 through 1.3), thirteen under category 2 (2.1 through 2.13), three under category 3, and three under category 4. 13 of 22 sit in category 2, "AI systems are evaluated for trustworthy characteristics," and 2.3 is one of those thirteen. The count is of rows in that table, read as published. It is not a maturity score, and it is not a claim that a demo which hits one row has hit the function. The publication says the actions "do not constitute a checklist, nor are they necessarily an ordered set of steps." What the count is for: evaluation in conditions like deployment is not a footnote inside a function about something else. It is inside the category that holds most of the measurement rows. A fixture demo skips the category with the most rows in it.
Show the miss on purpose. The U.S. Digital Services Playbook tells builders to test with the people who will use the thing, and to keep doing it: "We need to continually test the products we build with real people to keep us honest about what is important," and the checklist under that play includes "Test prototypes of solutions with real people, in the field if possible" (U.S. Digital Service, Digital Services Playbook). Your client is the real person in that sentence. A demo that hides the refusal, the low-confidence handoff, or the question the corpus does not contain teaches them that the product cannot be wrong. They will discover the opposite in the first week they use it, under your name. The interface work of making a wrong answer legible — what the user sees when the system should say it does not know — is designing for a system that is sometimes wrong. You do not have to redesign it the night before. You do have to be willing to click the case that fails.
Your name is the only name on the screen. The URL bar, the browser tab, the footer, the slide master, the Slack screenshot someone left in the recording. White-label delivery fails in the pixels before it fails in the contract. A client who sees a second brand has been introduced to a second firm, whether or not anyone meant to introduce them. Who they then trust, and what your non-solicit can and cannot do about it, is who your client trusts when you subcontract. The hour before the meeting is when you look for the leak with your own eyes, on the build you will actually project, not on a promise that the staging theme was updated.
You can explain one wrong answer without them speaking. Pick a question the demo gets wrong, or a question you will force into the refusal. Say, out loud, in an empty room, why that happened: which passage was missing, which field was empty, which action the product is not allowed to take. If the only honest sentence is "they would know," you are not ready to host the meeting. You are ready to attend someone else's. That is a legitimate way to run a partnership. It is a bad way to run a meeting you billed as yours. The trace you would need in order to answer — the question, the passages, the prompt — is the same record you will wish you had the day a real user complains. Collect it for the demo question now, while nobody is angry.
Production records do not belong in the room. A client who offers a live export the afternoon before is offering you a corpus you have not scoped, under a permission you may not have written down, with a person from the subcontractor about to see it. Use a scrubbed sample that preserves the mess — missing fields, duplicate names, a scanned page — and leave the live tenant closed. What access the subcontractor already has, and what they must not be given for a meeting, is what access to give a subcontractor. A demo is not a reason to widen it.
Write the result down in four lines, because a feeling that it "went fine" will not survive the client's first hard question. The URL you opened, and whether you opened it alone. The sample you used, and how it resembles their data. The wrong answer you showed, and the sentence you can say about it. The screen you checked for a second brand. If a line is blank, the meeting moves. Friendliness is not a fifth line.
There is a version of this meeting you should not staff with a delivery partner at all. You have not sold the work, so there is no client to protect and no demo to gate — you are still writing an offer. The client has asked to meet the people who will write the code, and you have decided to allow it — that is a relationship design, and the demo checklist will not hide it. The thing in the room is a slide deck of capabilities, with no build behind it. A white label software development partner is the wrong purchase for a pitch deck. If you cannot yet say what the demo has to prove, the prior step is a short AI readiness assessment: one workflow, the data it will see, and the miss you are willing to show. Buying a build so that a meeting has something to click is how agencies end up demonstrating a fixture they do not own.
The shape of a demo that already includes the miss, rather than a tour of the happy path, is visible in work that had to face a real queue. An AI support agent for a DTC brand answers order status, returns, and product questions from the brand's own order data and policies, escalates to a person when confidence is low, and is scored for resolution accuracy before and after a release. The client in that engagement was the brand, not an agency's customer, so it is not a white-label story and it is not a claim about anyone's margin. The shape transfers. A meeting that can show the escalation, on data that looks like the queue, is a meeting you can host. A meeting that can only show a clean answer is a meeting you should postpone.
The night before, open the URL alone, run one question on the messy sample, and say the wrong answer out loud. Then look at the tab title. If all four hold, host the meeting under your name. If one of them does not, move the meeting. The client can forgive a later date. They will not forget a demo that only worked while someone else was driving, or a second logo you did not know was in the corner. The evaluation harness that makes the wrong answer a score you can repeat, rather than a story you tell once, is AI evaluation and observability.
Find this useful? Tell Google to show you more of it.