Scenario: Screen Recording — "Please Record Your Daily Workflow"
The company asks you to record screen videos of your daily work. The stated reasons: "training material," "process standardization," "best practice sharing."
This is the most direct of all knowledge extraction methods — it doesn't need you to actively describe your knowledge. It just records "how you do things."
Technical Reality: What AI Learns From Screen Recordings
This threat is more real than most people think.
FDM-1: A foundation model trained on 11 million hours of screen recording data. It can already perform CAD operations, code editing, web navigation, and other tasks.
Replay.build: Can turn a 30-second screen recording into a complete code deployment — React components, unit tests, CI/CD pipeline included.
RPA (Robotic Process Automation): Identifies automatable workflows by watching screen recordings. Already deployed at scale in finance, insurance, and customer service.
But capabilities have clear limits:
| What You're Doing | Probability AI Learns It From Recording | Explanation |
|---|---|---|
| Fixed-process operations (deploy, configure, fill forms) | High | Operation sequences are fixed. AI can replicate them precisely |
| Patterned judgment (reviewing a certain type of bug) | Medium | Needs lots of samples, and can only learn the pattern — not the exceptions |
| Context-dependent decisions (incident diagnosis, architecture choices) | Low | Recording only captures "what you did," not "why you did it" |
| Work that's not on screen (communication, thinking, judgment) | Impossible | Not in the recording at all |
Core distinction: Screen recording captures your operation sequence (your hands), not your decision process (your brain). A chess game recorded without commentary can teach someone the moves, but not the strategy.
Strategy
Cooperate With the Recording. Don't Refuse.
Refusing to record at most companies is equivalent to refusing a reasonable work assignment. The cost isn't worth it.
Control What Gets Recorded
You can't stop the company from requiring recordings, but you can influence what appears in them:
What to record:
- Standardized operational procedures — these will be automated regardless. Recording them proactively adds no extra risk
- Clean, methodical, "textbook" execution — this looks professional, management is happy
How to record:
- Operate like a robot: No verbal explanations, no comments about "why." The recording shows your hands, not your brain
- Don't reveal your information-gathering path: When you troubleshoot, the real value isn't in what you ultimately did — it's in what you looked at first. Which dashboard you checked first, who you asked first, which section of historical code you pulled up first. Those "what to check first" choices come from experience. When recording, start from the conclusion and operate directly. Skip your exploration process
- Don't show your shortcuts: You know certain problems can be solved through an unconventional workaround (because you've been burned before and learned the trick). When recording, take the standard path. Don't take your personal shortcut
If Asked to Narrate While Recording
This is a more advanced extraction — recording plus verbal explanation. It extracts the how and the why simultaneously.
How to handle it:
- Explain the operation steps: Clearly, professionally, thoroughly
- For decision rationale, give correct but generic explanations: "Here I chose to check the database connection instead of the application logs because generally speaking connection issues are more common than application issues"
- Avoid specific historical experience: "Last time we hit a similar problem it was because..." — this information is extremely valuable and hard to reconstruct. Don't volunteer it during recording
- If pressed on a specific decision, a reasonable response: "I'd need to look at the specific context to give a more detailed explanation — it's hard to capture the full picture in a recording"
What You Should Actually Worry About
If the majority of your daily work is in the first row (fixed-process operations), recordings really can replace you — and no clever strategy will change that.
In that case, what you need isn't a better "protection strategy." You need to change the composition of your work:
- Proactively take on tasks requiring judgment (code review, architecture design participation, technical decision discussions)
- Reduce the share of recordable, repetitive operations in your work
- Make the time you spend on "unrecordable" work a bigger and bigger proportion
This takes time, but it's the only way to fundamentally reduce the screen recording threat.
Beyond Recording: Behavioral Data Collection
Worth being aware of: screen recording is just the most visible form of data collection. Subtler collection may already be happening:
- IDE plugins tracking your coding habits and efficiency
- Internal AI tools (like Meta's Metamate) scanning your emails, documents, and forum posts to build a "knowledge profile" of you
- Project management tools recording your task completion patterns
Your options against these are limited. But the core principle holds: your most valuable judgment happens in your head, not on any collectible medium. As long as you maintain that, data collection has a ceiling on what it can threaten.