A useful tool can become a problem when people keep adding capabilities without asking what those additions can access. One team connects an AI assistant to internal documents, email, and customer records. Another installs spreadsheet extensions until a simple planning file depends on half a dozen outside services.
The additions may save hours. They also create new dependencies, permissions, and failure points that somebody needs to understand.
AI access should follow a business purpose
Enterprise AI often starts with a narrow experiment. A customer support team might use a model to summarize tickets. Sales may generate account briefs. Finance could extract information from invoices.
Then somebody connects the system to more data.
Enterprise AI risk management provides a structured way to consider what can go wrong as those uses expand. Teams need to examine the information an AI system can access, the actions it can perform, the people affected by its decisions, and the controls surrounding it.
Consider an AI assistant connected to a company’s CRM. A salesperson asking for a summary of their own accounts is reasonable. The same assistant should not casually expose another division’s restricted customer records because both happen to live in the same database.
Access should match the task.
Human approval belongs around meaningful consequences
Automation becomes more useful as software gains authority, but authority deserves boundaries.
An AI tool that drafts a customer response creates relatively limited exposure if an employee reviews the message before sending it. Give the same system permission to issue refunds, change account details, or approve contracts and errors become much more expensive.
The answer is not to require human approval for every minor action. That can make automation pointless.
Use approval where consequences justify it. A support agent might allow AI to categorize tickets automatically while requiring an employee to approve refunds above $500. Finance could automate invoice data extraction but flag unusual amounts or missing purchase orders for review.
Good governance distinguishes routine actions from consequential ones.
Spreadsheet extensions deserve the same scrutiny
Spreadsheets feel familiar, which can make extensions seem harmless.
Google Sheets add ons can expand what a spreadsheet can do, including tasks such as mail merges, data imports, reporting, workflow automation, and document generation. That can be genuinely useful when a team has a repetitive process that formulas alone handle poorly.
Imagine a recruiting team maintaining candidate information in Sheets. An extension that generates interview documents from selected rows could remove repetitive copying. Another might pull information from an external system on a schedule.
Before installing one, check what permissions it requests.
Does it need access to the current spreadsheet, every spreadsheet in the account, email, or external services? Who publishes it? What business information will pass through it?
A useful feature does not automatically justify broad access.
Every extension creates another dependency
The spreadsheet still opens, so the underlying dependency can be easy to forget.
Suppose a sales report relies on one add-on to import CRM data and another to produce formatted PDFs. If either service changes its pricing, permissions, authentication method, or product support, the reporting process may suddenly stop working.
Keep track of the Google Sheets add ons that matter to recurring operations. Document what each one does, who owns the account, and what the fallback process looks like.
This does not require a giant governance program. A short internal record is often enough for a small team.
The important point is knowing which apparently simple spreadsheets are actually small systems.
Governance should match the size of the risk
Enterprise AI risk management can become overly bureaucratic when every experiment receives the same treatment as a production system handling sensitive records.
Classification helps.
An internal brainstorming tool using public information may need basic controls. A system summarizing confidential contracts deserves tighter data rules. An AI agent capable of modifying customer accounts needs deeper testing, access controls, logging, and clear responsibility for its actions.
Spreadsheets have their own versions of these tiers.
A personal vacation planner does not need the same scrutiny as a workbook containing payroll information. A marketing calendar can tolerate different extension choices from a finance workbook used for board reporting.
Apply controls where the consequences demand them.
Periodically remove what no longer earns its access
Software accumulates.
The AI pilot from last year still has database credentials. A spreadsheet extension installed for one project remains connected long after the project ends. Nobody notices because neither causes an obvious problem.
That is exactly why periodic review matters.
Ask what is still being used, what information each tool can reach, who owns it, and whether the original reason for granting access still exists. Remove stale connections and retire abandoned experiments.
Extending familiar tools can be a smart way to get more from systems people already understand. The discipline comes afterward: every new capability should keep earning the access, authority, and complexity it adds.
