Hyun-woo Park had a whiteboard covered in sticky notes, and every note was a different way someone in his building wanted to use generative AI. As a digital services officer at a state department of health, he had become the unofficial clearinghouse for AI requests, and they were arriving from every direction at once. The communications office wanted AI-generated images for a vaccination campaign. A program team wanted AI to draft and even write code for a new eligibility-screening web form. The training division wanted a synthetic narrated video of a "patient" walking through an intake process. And a dozen staff were already pasting case notes into a chatbot to summarize them. Hyun-woo's problem was that "generative AI" was not one thing. Each request used a different kind of model, with a different failure mode, and lumping them together was how agencies got into trouble. He needed a way to reason about each modality on its own terms.

Generative AI means any model that produces new content: text, images, code, audio, or video. The previous lesson covered how text models predict the next word. This lesson widens the lens to every modality, because each one fails differently and each one carries different governance obligations. The unifying idea is the same across all of them: these systems produce output that is statistically plausible given their training, not output that is verified to be correct. What changes from modality to modality is how that gap between plausible and correct shows up, and how much damage it can do.

Why the Modality Determines the Risk

Generative AI is expanding past text faster than most agency policies are being rewritten. Agencies are exploring image generation for training simulations, diagrams in policy documents, and synthetic datasets. They are using code generation to accelerate software development. They are experimenting with video synthesis for training material and public communications. Each of those is arriving through a different door, often from a different part of the building, and frequently without anyone recognising that the same governance question applies to all of them.

The reason a single policy struggles is that the failure modes are genuinely different in kind. An image model can generate a plausible-looking but counterfactual diagram, which fails in the eye of a reader who has no way to check it. A code model can produce secure-looking but vulnerable code, which fails silently in production months later and is discovered by an audit or an incident. A video model can create a deepfake that spreads misinformation, which fails outside the agency entirely and cannot be recalled. Detection differs, timing differs, and the person who would catch each one is a different person with a different skill set.

That is the practical case for reasoning modality by modality. If your control is "a subject matter expert reviews the output," you need to know which expert: a clinician for a case summary, a security engineer for a validation function, an accessibility specialist for narration, a communications lead and a community reviewer for a campaign image. A policy that says "review AI output before publication" without naming the reviewer per modality reads as coverage and functions as a gap. Hyun-woo's card exists to make that assignment explicit, so that a request arriving on a Tuesday afternoon does not require anyone to reinvent the answer.

Text Generation: The Familiar Baseline

Text generation is what most of Hyun-woo's staff were already using. A large language model (LLM) takes a prompt and produces fluent prose: summaries, draft letters, plain-language explanations of policy. The opportunity is real. The summarizing of long case notes saved his caseworkers genuine time.

The signature failure mode is plausibility without accuracy, often called hallucination. The model can confidently state a benefit threshold, cite a regulation number, or summarize a case note with a detail that was never there. Because the output reads as authoritative, the error is easy to miss. For a health department, a summary that silently drops or invents a clinical detail is not a cosmetic problem. The required control is grounding the model in real source documents and keeping a human reviewer on anything that informs a decision about a person. Note what grounding buys and what it does not: supplying the real source text removes the model's need to answer from memory, which eliminates a large class of invented detail, and it leaves open whether the model read the supplied text correctly. Grounding converts an unverifiable question about the model's memory into a checkable question about its use of a document the agency holds, which is a real improvement and not the same as a guarantee.

Image Generation: How Diffusion Works, Explained Simply

The communications office wanted generated images, so Hyun-woo learned how image models work. Most use a method called diffusion, and the idea is surprisingly intuitive.

Imagine taking a clear photograph and adding a little visual static, then more, then more, until the image is pure random noise. That direction is easy, which is the point: the model can be shown the noisy versions and the originals together, and asked to learn the mapping between them. What it learns is a prediction, made at many different noise levels, of what the underlying image was before the noise was added. A diffusion model is trained to run that process backwards.

Generation then works by starting from pure random noise and removing it step by step, with your text description steering each step, until a coherent image emerges. Ask for "a nurse administering a vaccine in a community clinic," and the model denoises its way toward an image that statistically matches that description based on the millions of images it trained on. Nothing in the sequence consults a fact. Each step is a prediction about what a slightly less noisy version of this image would look like, given the words.

The key limitation falls straight out of that mechanism. The model produces what is likely given your words and its training, not what is true. Ask for something specific or unusual, like an accurate anatomical diagram or a real building, and it will blend similar examples into something that looks right but may be subtly or seriously wrong. A diffusion model does not understand anatomy or facts. It understands what images of those things usually look like.

Four Risks Specific to Generated Images

Agencies reach for image generation to produce diagrams, training scenarios, and illustrations for public materials, and each of those uses runs into a distinct hazard. The first is visual plausibility without accuracy. An image can look entirely real while depicting something false, and a diagram can look professional while representing relationships that do not hold. A polished graphic carries an authority that a paragraph of text does not, which makes this failure worse in public-facing material than the equivalent error in prose.

The second is bias in visual representation. Image models trained on internet-scale data encode assumptions about how people in particular roles look. Asked for a nurse, a claimant, or an inspector, a model will produce demographics reflecting its training distribution, and a public campaign built from unreviewed outputs can reinforce stereotypes at the exact moment the agency is trying to reach an underserved community. The third is copyright and intellectual property. Some models are trained on copyrighted images, and generated output can resemble training data closely enough to raise questions the agency inherits rather than the vendor.

The fourth is the deepfake concern: image generation used to depict real people in situations they were never in. For an agency this cuts two ways, as producer and as target, and the second is discussed below. The practical response across all four is the same in shape. Have a subject matter expert verify any image that carries factual content, have people from varied backgrounds review any image depicting people, label generated images as illustrative, avoid generated imagery entirely in high-stakes contexts such as recruiting materials or anything that could be mistaken for a real event, and be transparent about which images are generated and which are photographs.

Code Generation: Fast, Fluent, and Sometimes Unsafe

The eligibility-form team wanted AI to help write code. Code-generation models are LLMs trained on enormous amounts of public source code; given a description or partial code, they produce likely-correct completions. The opportunities are substantial: accelerating routine development, helping staff work in an unfamiliar language, generating test cases, and drafting documentation for code that has none.

But "likely correct" is not "secure" and not "current." Four risks follow. Generated code can contain injection vulnerabilities, weak input validation, or weak cryptography that looks perfectly normal to a non-expert, because the training corpus contained secure and insecure code alike and the model has no inherent preference between them. It can reproduce patterns from code under open-source licenses that impose obligations the agency never agreed to. Because the model has a training cutoff, it can confidently use libraries or functions that are deprecated or no longer supported. And the most insidious risk is the human one: a developer who pastes in code they do not fully understand cannot maintain or debug it later.

The controls are correspondingly specific. Run security scanning on all generated code, and understand what that buys: a scanner matches known vulnerability patterns, so it raises confidence without certifying that the code is safe. Have security specialists review anything touching user input, authentication, cryptography, or sensitive data, since those are the areas where a plausible-looking mistake is most expensive. Test with malicious inputs and not only with the happy path. Review for license obligations before the code enters a repository. Generated code is a draft to be reviewed and scanned, never a finished component to be trusted on sight, and nothing generated should reach production without a human who understands every line shipped.

Audio and Video Synthesis: The Deepfake Frontier

The training division's request, a synthetic narrated video, sat in the highest-risk category. Audio generation now spans text-to-speech, voice cloning from a short sample, and music; video generation spans text-to-video, image-to-video, and direct face and voice replacement. The legitimate government uses are genuine: accessibility narration, multilingual support, narrated training material, and simulated scenarios for staff practice.

The danger is that the same technology produces deepfakes, convincing fabricated audio or video of real people. For a government agency, two harms dominate. First, an agency that produces synthetic media of a real official or a real-looking citizen, even for training, risks creating content that can be lifted out of context and mistaken for authentic. Second, and more pressing, agencies are increasingly targets: a fabricated voice of an agency director authorizing a payment, a fake video of a public health official giving false guidance, or manipulated media inserted into a records dispute.

Any synthetic media an agency creates should be clearly marked as synthetic and provenance-marked, staff should be trained on how deepfakes work and how to verify authenticity, and some uses are worth prohibiting outright rather than governing: voice cloning or video synthesis for impersonation has no legitimate agency application. Watermarking and digital signatures belong in the toolkit, with a precise understanding of what each does. A signature or provenance record you apply to your own output lets a recipient confirm that a file came from you unaltered. It does nothing to establish that an unsigned recording arriving from outside is authentic, and visible or embedded watermarks can be cropped, re-encoded, or otherwise degraded in ordinary handling. That is why any audio or video used as evidence or as an authorization needs verification through a channel other than the recording itself.

A Quieter Modality: Synthetic Data

One request on Hyun-woo's whiteboard did not fit the others. A data team wanted to generate synthetic data: artificial records that statistically resemble real patient data but describe no actual person, so developers could build and test systems without touching protected health information. This is a genuinely promising use, because it can reduce privacy exposure during development. But it carries its own quiet failure modes. Generated records can reproduce a real individual's pattern closely enough to re-identify them, especially for rare conditions where only a handful of real cases exist. And synthetic data inherits the biases of the real data it was modeled on, so a system tested only on synthetic records can pass every check and still fail on the real population. Hyun-woo's rule was that synthetic data is a development convenience, never a substitute for testing against real, governed data before launch, and any synthetic dataset built from health records gets a re-identification risk check before it leaves the building.

Worked Case: Accessibility Through Text-to-Speech

A state agency publishes regulatory documents online. Citizens with visual impairments use screen readers, but screen readers struggle with complex formatting, tables, and diagrams. The proposal is to use text-to-speech to produce high-quality audio versions, so that a citizen listens to natural-sounding narration rather than working through a document the screen reader mangles.

The challenges are practical and easy to underestimate. Quality varies by model and by material. Acronyms have to be pronounced as an agency's audience expects, punctuation and emphasis have to land correctly, and a mispronounced statutory term in a regulatory document is a substantive error rather than a cosmetic one, so the audio has to be reviewed for accuracy rather than published on generation. Two limits are worth stating plainly. Generated narration is an addition to accessible publishing, not a replacement for it: the underlying document still has to meet the agency's accessibility obligations, including structural markup, alternative text, and captions where applicable, and an audio file does not satisfy those requirements on its own. And a narration that reads a table aloud in document order can be less usable than a properly structured table, so test with the people who will actually rely on it before assuming the audio is an improvement.

Worked Case: Accelerating Compliance Code Development

An agency needs compliance-checking software, and developers currently write the validation logic for each regulatory requirement by hand. The proposal is to use code generation to accelerate that work, with human code review for security. In practice a developer writes a docstring describing what a validation must enforce, the model proposes a complete function, and the developer reviews it, adjusts it, and commits.

The discipline lives in the word "reviews." A generated validation function that looks correct can enforce a subtly different rule than the regulation states, and compliance code is exactly where that gap matters, because the whole point of the software is to be right about the rule. So the review is two-layered: a subject matter check that the logic matches the requirement as written, and a security check on anything handling input, since a validation routine is by definition input-facing. Nothing generated goes to production without both. Used this way the acceleration is real, because the model handles the shape of the function and the person supplies the judgement about what the function is supposed to mean.

Worked Case: Illustrations for a Policy Document

An agency publishes a detailed policy document on a new benefits program and wants illustrations of the key concepts and workflows so that stakeholders can follow it. The policy team describes each step of the process and the image model produces illustrations tailored to the agency's style. It is fast, it is cheap, and it is the request that most often ships without review.

Two requirements apply. The illustrations must be accurate to the actual process, because a diagram that misrepresents a workflow will confuse the exact stakeholders it was made to help, and a graphic carries more apparent authority than the paragraph beside it. And the illustrations must not perpetuate bias, which means having people from varied backgrounds review any depiction of applicants, staff, or communities. Human review and iteration are the whole method here; the generation step is the cheap part. It is also worth labelling the images as illustrative, so that no reader mistakes a rendered clinic for a photograph of one.

When the Modality Is Hidden Inside a Product

The hardest cases on Hyun-woo's board were not the explicit AI requests. They were the products that quietly embedded a modality without naming it. A new case-management platform the agency was about to buy included an "auto-illustrate" feature that generated images for reports, and a "smart draft" feature that was a text model under a friendly label. The vendor's sales sheet never used the words "generative AI." Hyun-woo learned to ask every procurement the same three questions: does this product generate any text, image, code, audio, or video; if so, which model and whose; and what does it do with the data we put into it. Under federal acquisition rules and standard data-handling clauses, the answers belong in the contract, not in a verbal assurance. A modality the agency does not know it bought is a modality it cannot govern, and "we did not realize the tool used AI" is not a defense an Inspector General accepts.

The Modality Risk Decision Card

Hyun-woo turned the whiteboard into a single reference card. When a new request arrived, he could find the row, read across, and know the dominant failure mode, the control he would require, and a concrete example from his own building.

When Generative AI Is Appropriate, and When It Is Risky

Across every modality, Hyun-woo found the same dividing line, and it had nothing to do with the technology being impressive. It had to do with two questions: how easily a human can catch an error, and how much harm a missed error causes.

The rule he wrote down was this. Generative AI is appropriate when its output is a draft that a knowledgeable human reviews before it matters, and risky when its output flows directly into a decision, a public statement, or a deployed system without that review. The model's fluency is constant; what varies is whether someone competent stands between the output and the consequence. Speed is the pressure that erodes this, because a system that produces dozens of options instantly makes review feel like the slow, optional part of the workflow rather than the part that makes the rest defensible.

That principle sorted the whiteboard cleanly. Lower-risk, with light controls: internal first drafts, brainstorming, summaries a caseworker verifies against the source, generated images that are clearly decorative and reviewed. Higher-risk, requiring strong controls or a no: anything that makes or directly shapes a benefits or clinical decision, any public-facing factual diagram, any generated code reaching production, and any synthetic audio or video of a real person. Whatever the tier, document what was generated, who reviewed it, and what was approved, because that record is the only evidence the review happened.

The legal and policy backdrop

Several real frameworks shape these choices for a public-sector body. Under the federal AI governance memorandum OMB M-24-10, AI that affects a person's access to health benefits or services is rights-impacting and triggers requirements for testing, human oversight, and the ability to appeal, regardless of which modality produced the output. Generated images and video of identifiable people raise publicity and likeness and copyright questions, and training-data provenance can create intellectual-property exposure the agency inherits. Public-facing AI-generated materials must still meet accessibility obligations under Section 508 of the Rehabilitation Act, including caption and alternative-text requirements that synthetic media does not satisfy automatically. And any modality that ingests resident health information pulls in privacy obligations, including a hard contractual line that submitted data not be retained or reused to train the vendor's future models.

Hyun-woo's deliverable to his director was the card itself plus one sentence: the agency was not adopting "generative AI," it was adopting several different capabilities with several different risk profiles, and each would be governed on its own row.

Anti-Patterns

Deploying generated content without quality review. Generation is fast and the output looks finished, so review gets skipped, especially when a first glance looks good. Then a published diagram turns out to misrepresent a workflow, generated code causes a security incident, or narration mispronounces a statutory term. Avoid by establishing a review process per modality, involving subject matter experts, and documenting what was generated, reviewed, and approved.

Treating generated code as secure because it looks right. Models trained on public code learned from secure and insecure examples alike and have no preference between them, so a plausible-looking function can carry a subtle vulnerability that surfaces in a later audit. Avoid by scanning, by having security specialists review anything handling input, authentication, cryptography, or sensitive data, and by testing with malicious inputs rather than only the intended path.

Treating a clean security scan as proof of safety. A scanner matches known vulnerability patterns. A clean result raises confidence and does not certify that the code is secure, and generated code can fail in ways no signature covers. Avoid by pairing the scan with human review, and by never letting the scan report stand in for someone who understands what the code does.

Using audio and video generation without thinking about deepfakes. Synthesis is realistic enough that teams produce it casually, and then an agency's voice-cloned training audio is extracted and used to claim an official said something they did not. Avoid by treating anything mistakable for a real event as high risk, labelling what you create, refusing impersonation uses outright, training staff on verification, and considering an outright ban on certain uses rather than a policy for them.

Relying on a watermark to establish authenticity. A provenance mark on your own output helps a recipient confirm it came from you unaltered. It says nothing about an unsigned file arriving from outside, and marks can be cropped, re-encoded, or degraded in normal handling. Avoid by verifying any recording used as evidence or authorization through a separate channel rather than through the artifact itself.

Assuming generated images are neutral. Image models reproduce the demographic patterns of their training data, so an unreviewed public campaign can carry stereotypes into exactly the communities it was meant to reach. Avoid by auditing image systems for bias before deployment, having reviewers from varied backgrounds look at depictions of people, avoiding generated imagery in high-stakes contexts such as recruiting, and being transparent about which images are generated.

Buying a modality without knowing it. A friendly feature name hides a text or image model, and the agency governs a product it has not identified as AI. Avoid by asking every procurement whether the product generates any modality, which model and whose, and what it does with submitted data, and by putting the answers in the contract.

Practice Prompts

Modality inventory. List the content your agency produces and sort it by modality: text, image, code, audio, video, and synthetic data. For each, write the specific harm that would follow if a generated version went out with an undetected error, and name who in your organisation would be accountable for it.

Accuracy requirements and detection. Pick one use case your agency is likely to pursue. Write down the accuracy requirements it must meet, then answer the harder question: how would an error be detected, and would it be caught before or after publication? If the honest answer is after, redesign the workflow rather than the prompt.

Image bias audit. Design the audit you would run on an image model before using it for public materials. Which prompts would you test, which demographic descriptions, and what result would count as a failure? Decide in advance what you would do if the model failed, because the pressure to ship arrives after the finding.

Code review protocol. Specify your review process for generated code: who reviews, what scanning runs, which categories of code require a security specialist, how license obligations are checked, and what the rule is for code no reviewer fully understands. Write the rule as a gate, not a guideline.

Deepfake preparedness. Does your agency publish audio or video of identifiable officials? Write the response plan for a fabricated recording claiming an official said something they did not: who verifies, who communicates, how quickly, and what provenance you can point to for your own genuine material.

Reflection

Take two minutes on one modality your agency is most likely to adopt first. What is the most damaging failure it could produce, and what would that failure look like from the outside, in a news story or an appeal rather than in a log? Now describe the checkpoint that would catch it before publication, and be honest about whether that checkpoint exists today or is something you are imagining. Finally, consider the procurement question. How many of the software products already in your building generate content, and how would you find out?

Glossary

Diffusion model. A generative model trained to reverse the addition of noise, which enables it to produce an image by starting from random noise and denoising step by step under the guidance of a text description. It predicts what is likely given the words and its training rather than what is factually true.

Text-to-image. A system that produces an image from a written description. Most current systems use diffusion, and all of them share the property that a request for something specific or unusual is answered by blending similar training examples into something plausible.

Code generation. Using a model trained on large volumes of public source code to produce source code from a description, a docstring, or a partial function. Output is likely-correct completion, which is a different property from correct, secure, or current.

Deepfake. Synthetic media depicting a real person saying or doing something they did not. For agencies the exposure runs in both directions: producing content that can be mistaken for authentic, and being the subject of fabricated media created by someone else.

Voice cloning. Generating synthetic speech that reproduces a specific person's voice, often from a short sample. It has legitimate accessibility and training uses and no legitimate impersonation use, which is why some agencies prohibit particular applications outright rather than governing them.

Text-to-speech. Converting written text into spoken audio. Valuable for accessibility and multilingual support, and an addition to accessible publishing rather than a substitute for the structural markup and alternative text an accessible document requires.

Watermarking. Embedding information in generated content to mark it as synthetic or to record its provenance. It supports verification of material you produced and does not establish the authenticity of material arriving from elsewhere, and marks can be lost through cropping or re-encoding.

Synthetic data. Artificial records generated to resemble real data statistically while describing no actual person. It reduces privacy exposure during development and carries re-identification risk for rare cases along with whatever bias the source data contained.

Related Lessons

This lesson sits between the technical foundations and the governance work. How Transformers and LLMs Work explains the text-prediction mechanism that underlies every modality here, and Supervised vs. Unsupervised vs. Reinforcement Learning places generative models within the wider family. Multimodal AI: Text, Image, Audio, Video takes the next step, covering systems that work across several modalities at once rather than one at a time.

Hallucinations, Guardrails, and Prompt Injection goes deep on the text failure mode summarised here and on the attack surface that any content-ingesting system carries. Emerging AI Capabilities: Agents, Reasoning, and Tools matters because the moment a generative system can act rather than only produce, the review-before-consequence rule in this lesson needs architectural support. Data Quality and AI Performance covers the bias that image and synthetic-data systems inherit from their training sets. On obligations, PII and AI: The Bright Red Lines and Privacy Engineering for AI address the health-information handling this lesson only flags, and OMB M-24-18 and AI Procurement Governance is where the three procurement questions become contract language.

Closing

Hyun-woo's whiteboard did not get smaller. What changed was that each sticky note stopped being an instance of "someone wants to use AI" and became a specific capability with a named failure mode, a required control, and an owner. That reframing is the whole contribution of this lesson. Generative AI is good at producing plausible content quickly, and plausibility is not accuracy and not appropriateness. Every modality tests that distinction differently, which is why a single AI policy covering all of them tends to be either too loose for code and video or too tight for a first draft.

The sequence continues into systems that combine modalities rather than working in one at a time, where a model reads a document and an image together, or analyses video alongside a transcript. Those systems inherit every failure mode described here and add the question of what happens when the modalities disagree. The habit to carry forward is the one Hyun-woo built: name the modality, name the failure, name the control, and name the person who reviews before the output matters.

Key Takeaways

• Generative AI is not one technology. Text, image, code, audio-video, and synthetic data fail in different ways and demand different controls. Govern each modality on its own terms rather than under a single policy.
• Every modality produces plausible, not verified, output. The shared root risk is that fluent or polished output can be confidently wrong, and the polish hides the error. A generated graphic carries more apparent authority than the text beside it.
• Diffusion models denoise toward what is likely, not what is true. Image models do not understand anatomy, facts, or real buildings; treat any factual diagram as suspect until an expert checks it, and review depictions of people for stereotypes.
• Generated code is a draft, never a finished component. Scan it for security flaws, review it for license obligations, watch for deprecated libraries, and ship only code a human understands. A clean scan raises confidence; it does not certify safety.
• Audio and video synthesis is the highest-risk modality. Label and provenance-mark anything you create, train staff on verification, and treat some uses as prohibited rather than governed. Watermarks verify what you produced, not what you received.
• Synthetic data reduces privacy exposure without removing it. Rare cases can be re-identifiable and the bias of the source data is inherited, so run a re-identification check and validate against real governed data before launch.
• The dividing line is human review against consequence. Use generative AI freely for reviewed drafts; restrict or refuse it where output flows straight into a decision, a public statement, or production. Document what was generated, reviewed, and approved.
• Know what modalities you have bought. Ask every procurement whether the product generates any content, which model and whose, and what it does with submitted data, and put the answers in the contract rather than in a verbal assurance.
• Rights-impacting use triggers real obligations. Under OMB M-24-10, AI affecting access to health benefits or services requires testing, human oversight, and an appeal path, whatever modality produced it; Section 508 and data-retention limits apply across the board.

Frequently Asked Questions

Can we just write one AI policy that covers all of this?

You can write one policy with per-modality sections, and that is what Hyun-woo's card effectively is. What does not work is a single uniform rule, because the same standard that is appropriate for generated production code is absurd overhead for an internal first draft, and the standard that suits a first draft is negligent for synthetic video of a real official. Name the modality, name the dominant failure mode, and attach the control to that pairing.

Our security scanner reports no issues on the generated code. Is it safe to ship?

Not established by that result alone. A scanner matches known vulnerability patterns, so a clean report means the code contains none of the flaws the tool recognises. It does not mean the code is secure, and it says nothing about whether the function enforces the rule it was supposed to enforce. Keep the scan and add human review, with a security specialist on anything touching input, authentication, cryptography, or sensitive data, and do not let anything ship that no reviewer fully understands.

If we watermark our synthetic media, does that solve the deepfake problem?

It addresses one half. A provenance mark or signature on your own output lets a recipient confirm that a file came from you and was not altered, which is genuinely valuable for official material. It does not help you evaluate an incoming recording, since a fabricated file simply carries no mark, and marks can be cropped or degraded through ordinary re-encoding. For anything used as evidence or as an authorization, verify through a separate channel rather than trusting the artifact.

Is text-to-speech enough to make our documents accessible?

No. Generated narration is a useful addition for people who find a mangled screen-reader experience unusable, and the underlying document still has to meet accessibility obligations on its own, including structural markup, alternative text, and captions where applicable. An audio file does not satisfy those requirements automatically. Test the narration with the people who will rely on it, and watch acronyms and statutory terms, where a mispronunciation is a substantive error rather than a rough edge.

Synthetic data has no real people in it, so can we skip the privacy review?

No, and the reason is specific. Synthetic records are generated from a model of real data, and for rare combinations of characteristics, such as an uncommon condition with only a handful of real cases, a generated record can resemble an actual person closely enough to be traced back. Run a re-identification risk check before the dataset leaves its control boundary. Separately, remember that synthetic data inherits the biases of its source, so a system that passes every test on synthetic records has not been tested against the real population.

How do we find out whether the software we already own uses generative AI?

Ask the three procurement questions retroactively, in writing, of every vendor whose product produces content of any kind: does it generate text, images, code, audio, or video; which model and whose; and what happens to the data we submit. Feature names are the tell, since "smart draft" and "auto-illustrate" are marketing labels for text and image models. Get the answers into the contract at renewal, because a modality you cannot name is one you cannot govern, and an Inspector General will not accept that the agency did not realise.