There is a version of "we used AI on this" that ends the conversation and a version that starts an interrogation, and the difference is almost never the facts - it is the framing. Disclose defensively and you sound like you are confessing to something, which invites the listener to treat it as something to be confessed. Disclose nothing and you are one leaked prompt or one curious legal reviewer away from looking like you hid it. The senior move is the third path: disclosure that is honest, specific, and non-defensive, calibrated to who is asking and what they actually need to know. This lesson teaches you to draft three disclosure scripts - one for a client, one for a CPO, one for your own team - each built on the provenance log from the previous lesson, each defensible without being apologetic. The artifact is three disclosure scripts you can adapt and reuse, so that the next time someone asks "how much of this was AI," you are reading from a prepared, confident answer instead of improvising a nervous one.

Why Disclosure Is a Craft Skill, Not a Compliance Chore

Most designers treat disclosure as a thing legal makes them do - a checkbox, a line of boilerplate, a disclaimer nobody reads. That framing is exactly why most disclosure goes badly. Disclosure is not a compliance artifact; it is a trust transaction, and like every trust transaction it is won or lost on how it is conducted, not just whether it happened. The same fact - "the hero image was generated with Adobe Firefly" - can land as "this team is sloppy and cutting corners" or as "this team is rigorous and knows exactly what is in their deliverable," and which one it is depends entirely on how you say it. A designer who can disclose well protects the team's credibility; a designer who discloses badly, or not at all, hands that credibility to whoever asks the first hard question.

There are two failure modes and the skill lives between them. The first is the defensive disclosure: hedged, apologetic, over-explained, the verbal equivalent of flinching. "So, um, we did use some AI, but only a little, and we checked everything, and it should be fine" is a disclosure that creates suspicion out of nothing, because confidence is contagious and so is its absence. The second is non-disclosure: saying nothing and hoping the question never comes, which works right up until it does not, and then the conversation is not about the AI at all - it is about why you did not mention it, which is a far worse conversation to have. The defensible disclosure threads between these: it states what AI did plainly, states how you verified it, states what protections apply, and stops. No hedging, no hiding, no apology for using a tool well.

Why Three Audiences Need Three Scripts

The reason there are three scripts and not one is that a client, a CPO, and your own team are asking fundamentally different questions even when they use the same words. "How much of this was AI" means something different from each mouth, and a disclosure that answers the wrong question - however honestly - misses. The senior move is to hear the real question under the literal one and answer that.

A client is asking, underneath the words, "am I exposed, and did I get what I paid for." Their concern is risk and value: is this deliverable safe to use commercially, and is it genuine work or did you just press a button and bill me for craft. A CPO is asking "is our process sound and is my team's judgment trustworthy." Their concern is the system: not this one asset but whether the design org has a defensible practice around AI that will not blow up in a board meeting or a press cycle. Your own team is asking "what is the norm here, and am I doing this right." Their concern is permission and standard: they need to know what good practice looks like so they can match it, and a disclosure to your team is really the establishment of a shared standard. Three questions, three scripts. Using the client script on your team is sterile and legalistic; using the team script on a client is alarmingly casual. Calibration is the craft.

The same fact lands as "this team is sloppy" or "this team is rigorous" depending entirely on how you say it. Disclosure is not a compliance checkbox - it is a trust transaction, won or lost on framing, and the framing has to be calibrated to the real question under the literal one.

The Client Script: Risk and Value, Plainly Stated

The client disclosure answers their two real questions - am I exposed, did I get value - directly and in that order, because risk is what they will worry about and value is what they paid for. It draws straight from the provenance log, which is what lets it be specific instead of vague, and specificity is the whole source of its credibility.

The shape of it: name where AI was used and where it was not, name the protections that apply, name the verification you did, and name the value you added that the AI did not. For example: "On this deliverable, AI was used for three things: the hero image was generated with Adobe Firefly, which carries commercial indemnification on our plan; the body copy was drafted with an AI assistant and then edited by our team; and one background was composited using AI background-removal over a licensed stock photo whose license we hold. Everything else - the layout, the brand system, the interaction design, and the final art direction on every asset - was designed by our team. We keep a provenance log of every AI-generated asset and the disclosures that apply to each, which we can share with your legal team. The Firefly hero carries one disclosure worth noting: Adobe has stated roughly five percent of Firefly's training data included AI-generated images; the commercial indemnification still applies, and we flag it so your review has the full picture."

Notice what that script does. It is specific (named tools, named roles), it leads with the protection (indemnification) because that is the client's first worry, it volunteers the inconvenient Firefly detail before they find it, it names the human work so they know they got craft and not a button-press, and it offers the log as evidence. It is not defensive - there is no "but" and no apology - and it is not hiding anything. A client who hears that walks away thinking "this team is on top of it," which is the entire goal. The disclosure protected the relationship instead of threatening it.

What the Client Script Must Not Do

It must not over-disclose into their anxiety. The client does not need a lecture on training-data ethics or a tour of every prompt; they need the risk picture and the value picture, accurately. Burying the two facts they care about under ten facts they do not is its own failure - it reads as either showing off or deflecting. And it must not under-disclose to seem more impressive: claiming the team hand-made what AI generated is the one move that converts a manageable disclosure into a genuine integrity problem, because a single discovered prompt then makes you a liar rather than a tool-user. Tell the truth, calibrated to their concern, and stop.

The CPO Script: The System, Not the Asset

The CPO does not care that one hero image came from Firefly. They care whether the design org has a sound, defensible practice around AI - because their job is to answer for the system to the board, to legal, and to the press, and they cannot do that if their designers each handle AI by personal improvisation. So the CPO script discloses up a level: not "here is what AI did on this deliverable" but "here is how we govern AI across our work, and this deliverable is an instance of it."

The shape: name the practice, name the controls, name the evidence, name the boundaries. "Our design org has a standard practice for AI-augmented work. Every AI-generated asset goes into a provenance log that records the model, the prompt, the date, and any disclosures - so we can answer a legal review on any deliverable in minutes rather than reconstructing from memory. We use indemnified tools by default for client-facing commercial work, and we flag and review anything that is not before it ships. We disclose AI's role to clients as a matter of practice, not just when asked. And we have explicit lines we do not cross - for example, we do not present AI-generated work as hand-crafted, and we do not ship assets carrying active-litigation exposure without legal sign-off. This deliverable followed that practice; the log is attached." That disclosure answers the CPO's real question - "can I trust this team's judgment as a system" - with yes, and here is the system. It elevates the conversation from the anxious "are we using AI too much" to the confident "we have this governed," which is exactly the posture a CPO needs to carry upward.

The CPO script is also where you protect the team's craft budget, which is a quietly strategic act. By framing AI as a governed accelerant rather than a replacement - "AI does the high-volume production, our designers do the judgment, the verification, and the art direction, and here is the log proving the division" - you give the CPO the language to defend headcount in the offsite where the CEO read one McKinsey report. A disclosure that says "AI made everything fast" invites the question "then why do we need the designers." A disclosure that says "AI accelerates production and our designers supply the judgment that makes it shippable, governed by this practice" answers that question before it is asked. Disclosure to a CPO is partly an act of self-advocacy, done in the language of process maturity.

The Team Script: Setting the Standard by Example

The disclosure to your own team is the one most designers skip, and it is the most important, because it is not really a disclosure at all - it is the establishment of a norm. When you tell your team how you handled AI on a deliverable, you are not informing them of a fact; you are showing them what the standard is, and they will calibrate to whatever you model. If you log everything and disclose honestly, that becomes the team's floor. If you are vague about your own AI use, you license vagueness across the team, and then a junior's unlogged Firefly asset is not their failure - it is yours, because you modeled that logging was optional.

The shape of the team script is therefore demonstrative, not defensive: "Here is how I handled AI on this project, so you can see the standard. Every AI asset is in the provenance log - here is the log. The Firefly hero has its indemnification status and the five-percent disclosure noted. The AI-drafted copy is marked as drafted-and-edited, not hand-written. Where I used AI and overrode it, I noted what I changed and why. This is the standard for our work: AI is welcome, and it is logged, disclosed, and verified, every time. If you are ever unsure whether something needs logging, log it." That is warmer and more granular than the client or CPO script because its job is different - it is teaching, not reassuring. It includes the override notes (where you rejected the AI's output and why) precisely because that is the craft judgment you want the team to internalize, and it explicitly invites erring toward over-logging, because the standard you want is one where logging is reflexive and nobody agonizes over edge cases.

A team disclosure done well is how trust scales beyond you. The provenance log is the record, but the team script is what makes the whole team keep the record, because it converts your individual discipline into a shared, visible norm. The next lesson - coaching a junior off an unchecked AI workflow - is only possible because this script established what the workflow should have been in the first place. You cannot pull someone off a standard they were never shown.

Adapting the Scripts in the Moment

Scripts are a starting point, not a teleprompter, and the skill is adapting them live when the question comes in a form you did not script for. Three principles keep an adapted disclosure on the rails. First, answer the real question, not the literal one: if a client asks "did a robot make this," the literal answer is unhelpfully binary, but the real question is "did I get value and am I exposed," so answer that. Second, lead with what they worry about most: risk for a client, system soundness for a CPO, standard for the team. Third, never let the framing slip into apology or evasion under pressure - if you feel the urge to hedge, that is the signal to state the fact more plainly, not less, because plainness is what reads as confidence and confidence is what the disclosure is actually transmitting.

The hardest live moment is the hostile follow-up: "so you just used AI and charged us full rate?" The defensive answer ("no no, we did lots of real work too") concedes the frame. The senior answer reclaims it: "AI did the high-volume production that used to eat our time. What you paid for is the judgment about what to make, the verification that it is correct and accessible, the art direction that makes it yours and not generic, and the accountability that it is all logged and disclosed - which is exactly what you are seeing now." That answer does not defend against the accusation; it reframes the value around the thing the AI cannot do, which is the same move that runs through this entire program. You are not apologizing for using the tool. You are demonstrating the understanding that the tool lacks.

Putting It to Work

Before your next AI-augmented deliverable ships, draft the three scripts from its provenance log while the details are fresh. Write the client version first, because forcing yourself to state the risk and value plainly to the most external audience clarifies the others. Then write the CPO version by elevating to the system level, and the team version by adding the override notes and the explicit standard. Keep all three as adaptable templates, because the second deliverable's disclosure is the first one with the names swapped, and a script you can adapt in ninety seconds is the difference between a confident answer and a nervous improvisation when the question lands at an inconvenient moment.

You will know the scripts are working when disclosure stops feeling like a risk and starts feeling like a credential - when "how much of this was AI" becomes a question you are glad to be asked, because the answer demonstrates exactly the rigor that makes your team worth hiring. That is the inversion this lesson is after: disclosure done well is not damage control, it is a competitive advantage, and the designers who can do it are the ones whose judgment a client, a CPO, and a team all learn to trust. The provenance log gave you the facts. The scripts are how you turn those facts into trust, calibrated to whoever is asking.

Key Takeaways

• Disclosure is a trust transaction, not a compliance chore. The same fact lands as "sloppy" or "rigorous" depending on framing. The skill lives between two failure modes: the defensive disclosure (hedged, apologetic, creating suspicion from nothing) and non-disclosure (which turns the eventual conversation into "why did you hide it"). The defensible path states what AI did, how you verified it, and what protections apply - then stops.
• Three audiences ask different questions under the same words. A client asks "am I exposed and did I get value" (risk and value). A CPO asks "is our process sound and my team trustworthy" (the system). Your team asks "what is the norm and am I doing this right" (permission and standard). Calibrate to the real question, not the literal one.
• The client script names where AI was and was not used, leads with the protection (indemnification) because risk is their first worry, volunteers the inconvenient Firefly disclosure before they find it, names the human work so they know they got craft, and offers the log as evidence. It must not over-disclose into their anxiety or under-disclose to seem more impressive - claiming hand-made what AI generated is the one move that creates a real integrity problem.
• The CPO script discloses up a level - the practice, not the asset: the provenance log, indemnified-by-default tooling, disclosure as standard practice, and explicit lines you do not cross. It is also self-advocacy: framing AI as a governed accelerant with designers supplying judgment gives the CPO the language to defend the team's craft budget against "why do we need designers if AI is fast."
• The team script is the most-skipped and most important, because it is not a disclosure but the establishment of a norm. It is demonstrative and granular - includes override notes (where you rejected AI output and why) and invites erring toward over-logging - because the team calibrates to whatever you model. You cannot later coach a junior off a standard you never showed them.
• Adapt live by answering the real question, leading with what each audience worries about, and stating facts more plainly when you feel the urge to hedge. To the hostile "you used AI and charged full rate," reframe value around what AI cannot do - judgment, verification, art direction, accountability - rather than defending against the accusation. Done well, disclosure is not damage control; it is a competitive advantage.