Before You Upload a Confidential Spreadsheet to an AI Tool: Decide What Data Actually Needs to Leave Your Browser
Published August 2026 by Solarc Labs
Start with the job you need done, not the whole workbook
A spreadsheet used for one operational task can contain far more information than that task needs: names, email addresses, customer notes, salaries, account references, free-text comments, historical tabs and hidden working columns. If the goal is to clean a date column, group transactions, answer one read-only question or produce one chart, the entire workbook may not need to be exposed to the same processing path. Write down the output you actually need first. Then identify which sheets, columns and rows are necessary to produce it. That turns “can we upload this spreadsheet to AI?” into the more useful question: “what is the minimum data this specific step needs?”
Minimise personal data before choosing the AI feature
The ICO’s AI and data-protection guidance says the data-minimisation principle requires organisations to identify the minimum personal data needed for their purpose and process no more than that. Its current guidance also describes local inference and other privacy-preserving approaches as techniques that can reduce the personal data revealed to a remote model or service. For a spreadsheet workflow, minimisation can be very ordinary: remove unrelated tabs, drop columns the task does not use, replace direct identifiers where appropriate, aggregate rows when individual detail is unnecessary, or perform deterministic cleaning locally before deciding whether any model-assisted step is needed at all. Data minimisation does not make every remaining use lawful or safe by itself, but it reduces the amount of information placed at risk.
“Local-first” should describe the real data path, not act as a privacy slogan
Local processing can reduce unnecessary data movement because some transformations can happen on the user’s own device or in the browser. The ICO also cautions that local processing does not automatically remove data-protection obligations, and the relevant legal and security responsibilities still depend on the actual processing. Ask the product to describe the boundary concretely. Which operations happen in the browser? Does raw row data leave the device? If a model is used, what exact text or derived values are sent to it? Which outputs are stored, for how long, and by whom? A useful privacy statement answers those questions for the current workflow rather than relying on a single “local” badge.
Separate deterministic spreadsheet work from model-assisted work
Many spreadsheet jobs do not require a model to see raw rows. Parsing a supported file, normalising dates, trimming whitespace, applying explicit filters, calculating known formulas or drawing a chart can often be defined as deterministic transformations. If a model-assisted query is useful later, the workflow can decide whether the model needs the full source, a reduced table, aggregated values, a schema description or no row-level data at all. Keeping those stages separate also improves reviewability. The team can see what changed because of a deterministic rule and what came from a model-assisted interpretation instead of receiving one opaque “AI cleaned the workbook” result.
Before using a public AI service, understand the provider’s current data terms
The NCSC has warned organisations not to put sensitive information into public LLM queries without understanding the consequences, and recommends reviewing the provider’s terms of use and privacy policy before sensitive business use. The exact retention, access, training and enterprise-control position can differ by service, account type and configuration, so do not copy assumptions from one AI product to another. For a confidential spreadsheet, record the service and account being used, what information will be transmitted, the approved purpose, retention or deletion expectations, who can access the result and whether organisational policy permits that path. If those answers are unclear, reducing the data or keeping the job local is usually a better next step than uploading first and investigating later.
SheetPilot is scoped around one explicit spreadsheet workflow and its data boundary
SheetPilot Workflow Pilot is positioned as one bounded browser-side spreadsheet cleaning, read-only query, chart or export workflow. Its scope should state the accepted file types, transformations, outputs and the raw-row/model boundary for the target environment before sensitive business data is relied on. That is not a claim that every spreadsheet stays entirely on-device under every possible configuration, and it is not a general data platform or compliance certificate. The commercial job is narrower: make one repeatable spreadsheet workflow understandable enough that the team can see what is processed locally, what—if anything—crosses the model or service boundary, and what evidence they should review before adoption.
Primary sources
Sources used for this article
Continue the job