AI Change Desk

di Michael Hanna-Butros Meyering

Stagione 1

AI Change Desk | EP047: Who Checks the AI Safety Claim?

A reviewer has expertise. A sponsor has a budget. An operator has a launch button. Who owns the answer when the safety finding says the work is not ready? In this 19-minute AI Change Desk episode, Michael follows a safety recommendation into an accountable decision and a concrete change to work. The practical distinction: changing a control, testing it, and verifying an outcome are three different claims. OpenAI's September 22 assessment proposal is a framework for scrutiny, not certification of a deployment. Its September 25 disclosure describes ongoing remediation. A separate September 28 Australian ministerial account describes a changed notification route and continuing investigation. Microsoft's September 24 worked example links a finding to a control and retest while preserving residual failures. Use the five-part Recommendation-to-Decision Check: the precise decision, evidence examined and excluded, actual recommendation, responding authority, and resulting change to work. Set aside 45 minutes with the people who can answer those questions. A worksheet cannot create missing evidence or grant exception authority. Listener question: can the operator explain what the review changed about the work they may do? This continues episode 46's incident-ownership discussion by moving earlier: what does a review establish, and what changes after the finding? OpenAI assessment principles, September 22 OpenAI incident updates, September 25 Minister Gallagher interview, September 28 Microsoft control-and-retest example, September 24 Source-checked September 28, 2026. These are separately attributed accounts, not independent corroboration of one another or a guarantee for your environment. AI-assisted tools were used in parts of the research and production workflow. Final editorial judgment, risk posture, and release approval stayed human-led. This is operational guidance, not legal advice. These are my opinions and are not representative of any organization. My current role includes privacy work, so you will hear me pay closer attention to purpose, access, retention, deletion, and accountability. I will not discuss nonpublic work here. These are my personal views and do not represent the State of Oregon or any other organization. Episode, sources, and audio Full transcript Recommendation-to-Decision worksheet

AI Change Desk | EP046: Who Owns the AI Incident?

AI Change Desk | Episode 46 | Runtime 20:51 When an AI workflow crosses a real boundary, an alert is only the beginning. This episode examines the authority needed to classify an event, interrupt work, preserve evidence, coordinate notifications, explain what is known, and authorize recovery. The practical tool is a seven-part AI Incident Authority Card: named decision owners, reachable backups, and evidence that the handoffs work. Evaluation boundaries and the difference between a model stopping itself and an independent stop control. Why an announced AI Force is not the same as an established operating structure. Why a reported privacy notification is not a final regulatory finding. The separate clocks for containment, notification, public disclosure, and closure. A 45-minute exercise for the workflow your organization cannot afford to improvise around. Choose one consequential AI workflow. Assign the classifier, scope authority, stop owner, evidence custodian, notification reviewer, public-statement approver, and recovery/closure authority. Test the handoffs with safe data. Treat gaps as work with owners, not agenda items without deadlines. AI Incident Authority Card worksheet Chapter markers are included in supported podcast players. Interior body times are estimates. Irregular investigation update - 2026-08-14 Google statements reported by Gerrit De Vynck in The Washington Post - 2026-09-18 Trump public post - 2026-09-19 Axios report on the announcement - 2026-09-19 AEPD notification notice - 2026-09-14 OpenAI model misalignment reporting framework - 2026-09-16 NIST identity and access token guidance - 2026-09-15 The transcript is derived from the approved render scripts and reusable disclosure, not an independent ASR transcription. Music positions follow the final assembly. Quick disclosure before we start. AI-assisted tools were used in parts of the research and production workflow. Final editorial judgment, risk posture, and release approval stayed human-led. This is operational guidance, not legal advice. These are my opinions and are not representative of any organization. One additional disclosure as the Desk evolves. My current role includes privacy work, so you will hear me pay closer attention to purpose, access, retention, deletion, and accountability. I will not discuss nonpublic work here. These are my personal views, and they do not represent the State of Oregon or any other organization.

AI Change Desk | EP045: Who Approved the Question?

A plain-language question can now become an enterprise analysis, a dashboard, a copied artifact, and an approved action in one workflow. Existing source permissions matter. They do not, by themselves, approve the purpose, metric definition, audience, derivative copy, or downstream decision. In this episode, Michael introduces the seven-part Question-to-Action Receipt for governing AI-assisted analytics from the first question through final disposition. Can the organization prove that an AI-assisted analysis used an approved purpose, identity, source, metric definition, audience, and action path - not merely data the user was technically allowed to retrieve? Purpose. Identity and authority. Source. Meaning. Evidence. Audience and copy. Action and disposition. Run the 45-minute Question-to-Action drill on one recurring business question. Approve, narrow, hold, or stop the workflow based on the evidence. AI Data Agent Question-to-Action Receipt: https://michaelhbm.com/downloads/ai-change-desk/resources/ep045-who-approved-the-question/EP045-ai-data-agent-question-to-action-receipt.docx OpenAI, , September 10, 2026: https://openai.com/index/put-data-to-work/ OpenAI Help Center, , updated September 10, 2026: https://help.openai.com/en/articles/20001518 Google Workspace Updates, , September 8, 2026: https://workspaceupdates.googleblog.com/2026/09/context-aware-access-controls-are-available-for-Gemini-Enterprise-in-the-Admin-console.html Google Workspace Updates, , September 10, 2026: https://workspaceupdates.googleblog.com/2026/09/manage-external-sharing-for-gemini-notebook-in-the-Admin-console.html NIST, , updated August 29, 2025: https://www.nist.gov/privacy-framework/getting-started-0 AI-assisted tools were used in parts of the research and production workflow. Final editorial judgment, risk posture, and release approval stayed human-led. This is operational guidance, not legal advice. These are Michael's personal views and do not represent the State of Oregon or any other organization. His current role includes privacy work; no nonpublic work is discussed.

AI Change Desk | EP044: Who Owns the AI Audit Trail?

The organization finally gets the AI audit trail it asked for. That is progress. It is also the moment a second data plane appears. In episode forty-four, Michael examines new Google Workspace audit capabilities for Gemini Notebook alongside emerging Anthropic and OpenAI control architectures. The episode does not argue against logging. It asks operators to govern what the log can become: a record containing identities, network context, source details, resource ownership, generated-artifact identifiers, administrator actions, and downstream copies under separate access and retention rules. The episode introduces the seven-part Two-Plane Privacy Receipt and a focused 45-minute exercise for mapping one AI workflow's content evidence and control evidence separately. This Labor Day episode also acknowledges a practical worker-impact boundary: systems that monitor AI use can create records about people. Purpose, transparency, proportionality, access, and correction therefore need named ownership before those records influence a decision. Why an audit trail is necessary but not privacy-neutral. The difference between the content plane and the control plane. What Google's new Gemini Notebook audit documentation makes visible. Why regional audit-log routing does not prove regional storage for underlying content. How optional warehouse exports create separate access, correlation, and lifecycle questions. Why planned or preview safety architectures should remain qualified until their documented state changes. A 45-minute harmless-event test for one real AI workflow. Auditability is not outside the data system. The audit trail is a second data plane. Purpose. Content plane. Control plane. Location. Access. Lifecycle. Correlation and action. Use the to map one AI workflow, test one harmless event, and decide whether to pass, hold, fix and retest, or stop. Google Workspace Updates: Introducing comprehensive audit logs for Gemini Notebook in the Workspace Admin console Google Workspace Admin Help: Gemini Notebook log events Google Workspace Admin Help: Gemini Notebook BigQuery log schema Anthropic: Developing Enterprise Frontier Safeguards with our customers OpenAI: Offering Zero Data Retention for frontier models AI-assisted tools were used in parts of the research and production workflow. Final editorial judgment, risk posture, and release approval stayed human-led. This is operational guidance, not legal advice. These are Michael's personal views and do not represent the State of Oregon or any other organization. Michael's current role includes privacy work; no nonpublic work is discussed.

AI Change Desk | EP043: Was the Safeguard Actually Running?

Most organizations can name their safeguards. The harder question is whether those safeguards covered the run that mattered. In episode forty-three, Michael follows new official disclosures from OpenAI and Anthropic about separate high-risk cyber evaluation or training incidents. The mechanisms and organizations differ, and the episode does not generalize those accounts to ordinary customer deployments. The shared operating lesson is narrower and more useful: a documented control is not a runtime control until the organization can prove it covered the specific model, environment, configuration, partner handoff, and alert path in use. The episode introduces a six-part Runtime Safeguard Coverage Receipt and a focused 45-minute synthetic test for checking the difference between an intended control set and the controls that were actually active. Why control availability and runtime coverage are different facts. What new OpenAI and Anthropic disclosures signal for operators. Four common coverage gaps: policy to runtime, environment to assumption, event to incident, and provider to partner. Why functional success does not prove control success. The six receipts required before a high-risk AI workflow scales or resumes. A 45-minute exercise for testing a real workflow with a harmless synthetic event. The intended control set is what should protect the workflow. The effective control set is what actually protected one specific run. Run scope. Safeguard state. Environment state. Enforcement and alert. Partner handoff. Outcome and disposition. Anthropic: Improving our alignment and security efforts OpenAI: The Hugging Face incident and the road ahead METR and Redwood Research: Brief independent investigation Hugging Face: Anatomy of a Frontier Lab Agent Intrusion AI-assisted tools were used in parts of the research and production workflow. Final editorial judgment, risk posture, and release approval stayed human-led. This is operational guidance, not legal advice. These are Michael's personal views and do not represent the State of Oregon or any other organization. Michael's current role includes privacy work; no nonpublic work is discussed.

AI Change Desk | EP042: Where Does Zero Retention End?

This episode was delayed one day because the Hawk Fire affecting the Verdi and northwest Reno area required Michael's attention. Michael's thoughts are with everyone affected and with the firefighters, emergency crews, volunteers, and neighbors supporting the response. The episode was source-checked again on August 25, 2026. OpenAI's new Private Safety Processing preview raises a useful operating question: when a provider makes a precise Zero Data Retention commitment, can your organization prove the rest of the data path? In episode forty-two, Michael separates provider-content retention from application state, operational telemetry, customer-side logs, third-party tools, outputs, records, and backups. The episode introduces a six-part retention-boundary receipt and a 45-minute synthetic test for checking whether your system's actual behavior matches the language your organization uses. What OpenAI currently says Zero Data Retention means for eligible API customers. What Private Safety Processing is designed to do, and why preview language matters. Why endpoint and tool compatibility must be checked separately. The difference between a vendor statement, contractual entitlement, configured state, runtime evidence, and repeatable assurance. Six receipts for proving a retention boundary. One 45-minute exercise to run against a real workflow using synthetic data. Zero data retention is not zero data flow. A provider boundary is not a system boundary. OpenAI: Offering Zero Data Retention for frontier models OpenAI API: Data controls in the OpenAI platform NIST Privacy Framework NIST: Getting Started with the Privacy Framework Emergency Washoe: Hawk Fire update Nevada Governor: State of Emergency for Hawk Fire AI-assisted tools were used in parts of the research and production workflow. Final editorial judgment, risk posture, and release approval stayed human-led. This is operational guidance, not legal advice. These are Michael's opinions and are not representative of any organization, including the State of Oregon.

AI Change Desk | EP041: What Did the AI See?

OpenAI Computer History and Google Meet's in-person notes turn AI context into an operating question: what was the system allowed to notice, where did the artifacts go, and what were people told?

AI Change Desk | EP040: When a Prompt Becomes a File

A long paste can become an attachment, and Voice can now work with files and Project context. EP040 gives operators a six-part default-state receipt.

AI Change Desk | EP039: Whose Account Did the Agent Use?

AI CHANGE DESK | EP039: WHOSE ACCOUNT DID THE AGENT USE? EPISODE SUMMARY An employee asks an AI agent to send a file. The employee is allowed to run the agent, the connector accepts the request, and every dashboard turns green. But the connector authenticates with the account of the person who built the agent six months ago. Whose authority actually moved the work? This episode extends the receipt framework from episodes thirty-seven and thirty-eight. Michael separates audience permission, credential capability, organizational purpose, and action approval; explains why disclosure is necessary but incomplete; and introduces a paired authority-and-privacy receipt for connected agent workflows. The operating principle is simple: the agent has a name, but the credential carries the authority. A useful audit trail must preserve both. WHAT CHANGED • OpenAI's current Workspace Agents guidance makes the risk of publishing agents with personal connections explicit: other authorized users may be able to act through the creator's authenticated connection. • European Commission guidance says Article 50 transparency obligations under the EU AI Act began applying on August 2, 2026, with duties depending on role, context, system type, and applicable exceptions. • Microsoft guidance recommends dedicated agent identities, named owners and approvers, effective-permission review, correlation identifiers, on-behalf-of-user evidence, and tested revocation. • GitHub's agentic audit fields provide a platform-specific example of separating the agent, session, action, and initiating user. • OpenAI's Health documentation illustrates why disconnecting a source, deleting synced data, and deleting conversation history are separate privacy events. WHAT THIS MEANS FOR OPERATORS • Permission to run an agent is not authority to use every credential connected to it. • Record the requester, agent owner, publisher, approved audience, trigger, session, connection owner, authenticating account, effective downstream scope, action, approval, defender event, and final disposition. • Keep audience permission, credential capability, purpose authority, and action approval as separate decisions. Do not average them into one green status. • Place a data-handling receipt beside the authority receipt: purpose, minimum data needed, actual data returned, recipient, onward sharing, memory, retention, deletion, and required disclosure. • Test revocation. Disable the agent, rotate or remove a credential, invalidate the old token, and prove the old path no longer works. • Treat vendor documentation as a control map, not proof of your tenant's configuration or runtime behavior. THIS WEEK'S 45-MINUTE BLOCK Choose one connected AI workflow that can retrieve data or take an action. 1. Spend ten minutes mapping the requester, agent owner, publisher, approved audience, trigger, agent/session fields, connection owner, and authenticating account. 2. Spend ten minutes recording the effective downstream scope. Separate read, write, send, share, schedule, edit, and delete. Record which actions require approval. 3. Spend ten minutes mapping purpose, data category, minimum needed, actual data returned, recipient, onward sharing, memory, retention, deletion, and disclosure. 4. Spend ten minutes running one allowed action and one denied action. Remove or rotate one connection and prove the old path no longer works. Capture both agent-side and defender-side evidence. 5. Spend five minutes reconciling identities, timestamps, purpose, data returned, approval, and revocation. Record every mismatch, owner, correction, residual risk, and final disposition. Keep the workflow supervised until the receipts reconcile. LISTENER QUESTION Can your team prove which account sup...

AI Change Desk | EP032: Memory Summary Exit Check

If AI memory can be edited more visibly, turned off more easily, and still be rebuilt from old context later, the operating question is not whether the settings page looks cleaner. It is what evidence proves sensitive or stale context actually left the workflow. Why OpenAI's June 12 memory-summary controls matter operationally. Why deleting visible memories is not the same as deleting past chats or every source. Why a partial memory summary creates a partial-ledger problem. How Developer mode and model retirement add inspection and version-receipt pressure. A forty-five minute Memory Summary Exit Check operators can run this week. OpenAI ChatGPT release notes: https://help.openai.com/en/articles/6825453-chatgpt-release-notes OpenAI Memory FAQ: https://help.openai.com/en/articles/8590148-memory-faq/ OpenAI Codex browser docs: https://developers.openai.com/codex/app/browser OpenAI Lockdown Mode: https://help.openai.com/en/articles/20001061-lockdown-mode OpenAI memory product post: https://openai.com/index/chatgpt-memory-dreaming/ YouTube AI labels update: https://blog.youtube/news-and-events/improving-ai-labels-viewers-creators/ Podnews AI disclosure guidance: https://podnews.net/update/ai-disclosures AI-assisted tools were used in parts of the research and production workflow. Final editorial judgment, risk posture, and release approval stay human-led. This is operational guidance, not legal advice.

1 di 5