What Did the AI See?

Imagine hiring an assistant who can follow you through selected rooms of your workday. Not every room. Only the rooms you choose. The assistant does not take screenshots. It does not record the screen. It does not listen to the microphone or system audio.

Private browsing is outside the boundary. But inside the selected rooms, it can keep a timeline of interaction events so ChatGPT and Codex can use that context later. That is how OpenAI describes Computer History, an optional feature announced for eligible Enterprise users on the Mac app.

It is off by default. An administrator must grant access by role. Then the individual member decides whether to opt in. The member can pause it, choose the apps and sites, inspect timeline items, and delete them. Those are meaningful controls.

And they still leave an organization with a very adult question. What, exactly, did the AI see? Because the admin can explain who had access to the feature. The user can explain what they selected. The product page can explain what the feature excludes.

Privacy can ask what purpose justified the context. Records can ask what deletion means. Security can ask what evidence exists. And somehow everybody can be correct while nobody has the whole answer. A checkbox is not an operating model.

It is a very small square with excellent public relations. This week, we are not asking whether ambient context is useful. Of course it can be useful. We are asking whether useful context can become governed context before it becomes invisible infrastructure.

Useful context is still collected context. And if the organization cannot prove the purpose, the scope, the choice, the lifecycle, and the evidence, then it does not have a context strategy. It has a helpful assistant carrying a clipboard through rooms nobody mapped.

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.

Opening music

Welcome back to AI Change Desk. I am Michael. Today is Monday, August seventeenth, twenty twenty-six. And this is episode forty-one. What Did the AI See? That standing privacy disclosure matters in this episode. The point here is operational.

What should an organization be able to prove before a context feature quietly becomes normal? I checked the source pages again Sunday morning, because the timing matters. On August thirteenth, OpenAI added Computer History to its Enterprise and Education release notes.

On August tenth, OpenAI also announced the retirement of individual-user sync connections. Existing individual connections were scheduled to be disabled on August fourteenth, and deletion of associated synced data was to begin. Administrator-managed sync is unaffected. And on August second, specified transparency obligations under Article fifty of the European Union AI Act began applying to providers and deployers within the rule's scope.

Those are different changes. One is a product feature. One is a connection-lifecycle change. One is a legal transparency layer. I am not pretending they have one architecture or one universal compliance answer. I am saying they expose one operating pressure.

AI transparency now has two directions. What context went into the system? And what did people learn about the AI interaction or output coming back out? If you can explain only one direction, you do not have transparency.

You have a window with a mirror taped over one side. Start with the product facts. OpenAI says Computer History is optional. It is available through the ChatGPT app on Mac for eligible Enterprise members. It can bring context from selected apps and websites into ChatGPT and Codex.

OpenAI says it records interaction events. It specifically says it does not record screenshots, screen recordings, microphone input, or system audio. It says private browsing is not included. And it says the feature is currently unavailable in the European Economic Area, the United Kingdom, and Switzerland.

Those boundaries matter. We should not inflate the feature into something the source does not say. This is not permission to call it screen recording. It is not permission to say it is listening. And it is not permission to turn one release note into an emergency meeting with the lighting of a submarine thriller.

But accuracy cuts both ways. We also should not shrink the feature because the word screenshot is absent. Interaction context can still matter. Which app was active? Which site was involved? What event entered the timeline? How long was it available?

Which conversation or task used it? Could the member inspect it? Could the organization investigate it? What happens when the member pauses the feature? What happens when the member deletes a timeline item? And what evidence distinguishes requested deletion from completed disposition?

The release note does not answer every one of those questions. That is not an accusation. It is the boundary between vendor documentation and organizational operation. The vendor describes the capability. The organization has to describe the use.

There is a second August thirteenth signal that makes this distinction even clearer. Google announced that Take Notes for me can now extend beyond video calls into in-person meetings. A user can start a session from the Google Meet home screen on the web or a mobile device.

Gemini captures the meeting audio. When the session ends, Google says it creates structured notes, action items, and a complete transcript inside a Google Doc saved to Drive. Then it emails the link. That is a different kind of context.

Computer History specifically excludes microphone and system audio. Google's meeting feature deliberately uses audio to create persistent work artifacts. One follows activity across selected digital surfaces. The other can turn a physical room into a source system. Context is not one data type.

And a context inventory that says only AI notes is not an inventory. It is a shrug with a spreadsheet. Google also provides an administrator control that can require participants on supported devices to actively agree before note-taking, recording, or transcription begins.

Google calls that an explicit-consent control. That product label should not be treated as a universal legal conclusion. But it creates a concrete operating test. Who can start the capture? Who was present? What did each person see?

Where did the transcript land? Who inherited access? How long will the artifacts remain? And what proves the capture actually stopped? A participant prompt is an important control. It is not the entire lifecycle. And this is where teams often collapse four different events into one word.

Enabled. An administrator can grant role access. Chosen. A member can decide whether to opt in. Scoped. The member can choose included apps and sites. Used. The context can actually support a ChatGPT or Codex interaction. Those are not synonyms.

A feature can be available but not granted. Granted but not chosen. Chosen but narrowly scoped. Scoped but never used in a particular task. If your inventory has one column called enabled, then four governance questions are currently sharing a studio apartment.

And one of them is definitely eating the others' groceries. OpenAI's same August thirteenth update adds another useful clue. Workspace owners can review supported audit events through the Global Admin Console, but OpenAI says event coverage depends on the selected workspace and admin role.

The update also describes additive role-based access controls. Ordinary custom roles can inherit the default, explicitly grant a permission, or explicitly deny it. An explicit denial in an applicable ordinary role prevents access, while Lockdown Mode is evaluated separately and can further restrict network-enabled capabilities.

Again, those are meaningful controls. But a control existing in the product is not proof that your organization configured it, tested it, or can explain the effective result for one person. The receipt has to connect the documented feature to the observed tenant state.

Otherwise the evidence is basically, the brochure says the brakes are excellent. That is encouraging. I would still like to know whether this car has them. Now look at the sync retirement. OpenAI says new individually authorized sync connections stopped being available on August tenth.

Existing individual-user sync connections were scheduled to be disabled on August fourteenth, and deletion of associated synced data would begin. Administrator-managed sync is unaffected. That sentence is doing more work than it looks like. It separates connection ownership.

The source might still be Google Drive, SharePoint, GitHub, or another system. But the operating path changes depending on whether the connection belonged to an individual or was managed by an administrator. That changes who must migrate the workflow, who must communicate the change, who can prove the new scope, and who verifies the old data's disposition.

Same source does not mean same connection owner. And same delete button does not mean same deletion evidence. OpenAI says deletion begins. That is not the same claim as deletion is complete. The organization needs a status model that can hold the difference.

Requested. Started. In progress. Completed. Verified. Exception. If every lifecycle event goes directly from active to deleted, you do not have a lifecycle model. You have a magic trick. And the rabbit is probably in legal hold. Now move to the output side.

The European Commission says Article fifty transparency obligations began applying on August second for the providers and deployers that fall within scope. The Commission's guidance addresses several different situations. It includes informing people when they are directly interacting with an AI system.

It includes machine-readable marking requirements for specified AI-generated or manipulated content. And it includes deployer disclosures in specified situations, such as certain deep fakes, certain public-interest content without human review or editorial control, and certain emotion-recognition or biometric-categorization uses.

That is not a universal sticker requirement for every spreadsheet formula, every draft email, or every sentence an employee cleans up with AI. Scope matters. Role matters. Content matters. Jurisdiction matters. Exceptions matter. This is operational guidance, not a legal applicability opinion.

But the direction is clear enough to pressure-test the operating model. If your organization is becoming more deliberate about telling people when AI is involved downstream, it should also become more deliberate about documenting what context was available upstream.

A label on the output cannot repair an unmapped input. And a clean input inventory cannot substitute for a disclosure that is actually required at the point of interaction. Two directions. One operating model. This is the next step in the receipt chain we have been building across the last few episodes.

Episode thirty-eight asked whether the trajectory stayed inside the approved boundary. Episode thirty-nine asked whose identity and authority moved the work. Episode forty asked what object the interface created. Now we ask what context the system was allowed to notice before the answer appeared.

Trajectory. Identity. Object. Context. These are not four competing frameworks. They are four views of the same execution. Who acted? On what? Through which path? With which surrounding information? And what evidence survives afterward? That is how the episodes connect.

We are moving from whether AI can do the task toward whether the organization can reconstruct the work. So what does a context-collection receipt contain? Six parts. Not sixty. Nobody needs a committee to produce a decorative binder that immediately becomes context for another AI system.

Six parts. First, the purpose receipt. What approved use requires this context? What decision or workflow is it supporting? Which context is necessary? Which context is prohibited? And who owns the outcome? If the purpose is, because the feature is available, that is not a purpose.

That is a toddler reviewing a light switch. The purpose should be concrete enough to reject unnecessary context. For example, help a member recover the state of a documented research workflow across selected approved applications. That is more testable than, make the assistant know everything.

Second, the enablement receipt. Is the feature available in your plan and region? Which administrator granted role access? Which population is eligible? What is the default state? What configuration is effective now? And did you observe the state in the actual tenant?

This is where the August thirteenth audit and role-control changes matter. Documented capability is the starting point. Observed configuration is the receipt. Third, the scope receipt. Which apps and sites are included? Which event types can enter context?

Which sources are excluded? Which private or restricted environments are outside the boundary? Does the member understand the difference between selecting an application and selecting every workflow that happens inside it? A broad app name can hide very different information contexts.

The scope needs to be narrow enough that the purpose still explains it. Fourth, the choice and communication receipt. What does the member see before choosing? What can the member change later? How do they pause the feature?

How do they inspect timeline items? How do they delete an item? What plain-language statement explains the organizational expectation? Do not call this legal consent unless counsel has made that determination for the actual context. For the operating model, the immediate question is simpler.

Can the person understand the choice and act on it without finding a seventeen-page policy that was last updated when everyone still had a fax number? Fifth, the lifecycle receipt. How is context viewed? Corrected? Exported where supported?

Deleted? Paused? Disabled? Disconnected? Migrated? Retained? And how is final disposition verified? The individual-sync retirement is the practical test. Can you identify affected connections, move approved workflows where appropriate, notify users, and distinguish deletion started from deletion verified?

Sixth, the evidence receipt. Which configuration snapshot proves enablement? Which audit events are actually supported? Which test account confirmed the user experience? Which notice was presented? Which exception was recorded? Who reviewed the result? And when will the organization check again?

NIST's Privacy Framework is useful here because it treats privacy as ongoing risk management, not a one-time ceremony. It asks organizations to identify data processing and privacy risk, govern roles and requirements, enable control, communicate practices and choices, protect information, and reassess over the lifecycle.

The framework is voluntary. It is not law. What it gives operators is a common language for turning a feature review into an accountable process. Here is the scenario. A research team wants Computer History because members move between a browser, a document editor, and a project-management tool.

The admin confirms the feature is available and grants access to a pilot role. Ten members opt in. Eight select only the approved browser and document editor. Two also select the project-management tool. One member pauses the feature during a sensitive review.

Another deletes several timeline items. A week later, the pilot owner asks whether the context improved the work. That is the capability question. Privacy asks whether the selected scope matched the purpose. That is the processing question. Security asks which events are auditable.

That is the evidence question. Records asks what deletion changed and what proof remains. That is the lifecycle question. The employee asks whether pausing the feature stops new context only or changes existing timeline items. That is the communication question.

No single toggle answers all five. And that is the point. The feature can be thoughtfully designed. The user can make a real choice. The organization can still need a better operating map. Privacy is not the department that arrives after the useful thing exists and replaces it with a PDF.

Done well, privacy helps define the conditions under which the useful thing can keep being useful. So here is the Monday action block. Forty-five minutes. One context feature. One real workflow. Do not start with every AI product in the enterprise.

That way lies a spreadsheet with twelve owners and no pulse. For the first ten minutes, name the purpose and owner. Write the approved use in one sentence. List the minimum context needed. List the context that would invalidate the pilot.

For the next ten minutes, map enablement and scope. Record the vendor-documented default. Record the actual tenant state. Record the eligible role. Record the apps, sites, event types, and exclusions you can verify. For the next ten minutes, walk the member experience.

Use a test account. Observe the choice. Pause the feature. Inspect an item. Change the scope. Request deletion where appropriate. Capture what the person sees, not what the policy assumes they see. For the next ten minutes, map the lifecycle and evidence.

Identify supported audit events. Identify retention and deletion questions that still require vendor or counsel review. Assign an owner to every unknown. An unknown with an owner is work. An unknown without an owner is folklore. For the final five minutes, write the communication.

One short paragraph. What the feature does. What it does not do according to the current source. Who can use it. What choice the member has. How to pause or change it. Where to ask a question. Then set a recheck date.

Because the release note will move. The tenant will move. The law may move. And people will absolutely find a use case that was not in the pilot slide deck. That is not cynicism. That is Tuesday. The takeaway is not that ambient context is automatically invasive.

The source does not support that claim. The takeaway is not that an opt-in control solves every privacy question. The source does not support that claim either. The useful position is in the middle. A feature can be optional, off by default, role-gated, individually chosen, pausable, inspectable, and deletable, and the organization can still need to prove why it is used, what it includes, what it excludes, what happens across the lifecycle,

and what evidence remains. Admin enablement is not user choice. User choice is not purpose. A delete control is not a deletion receipt. And an output label is not an input inventory. What did the AI see? Who decided it could see that?

What could the person change? What happened when the connection ended? And what can the organization prove now? Answer those questions for one workflow this week. Then fix the map before the clipboard becomes part of the furniture.

That is the desk for this week. One emerging change. One operating question. One action you can run before the next commute. I am Michael. This is AI Change Desk. And I will talk with you next Monday.

Closing music