AI Security & Governance
Your staff are already using AI. Governance is the difference between that being a managed capability and an unmeasured exposure.
The problem
In most organisations, AI arrived through individual staff rather than through a decision. There is no policy, no approved tool, no logging — and therefore no way to answer a straightforward question about what has been shared.
This is not a discipline problem. The tools are free, immediately useful and genuinely faster than the sanctioned process. A member of staff summarising a supplier contract in thirty seconds instead of twenty minutes is behaving entirely rationally within the incentives they have been given.
The difficulty is what happens next. A client asks whether their data has been processed by an AI system, and the honest answer is that you do not know. A tender questionnaire asks about your AI controls. An employee leaves with a personal account containing two years of work material. None of these are hypothetical; they are the situations that prompt the call.
Governance here does not mean bureaucracy. It means a short set of decisions about what is permitted, enforced through the identity and access controls you already own, so that staff can use AI productively and the business can say what happened.
What good looks like
Risk
Not speculative harms — the situations we are called in to deal with. All of them are addressable, and none of them require abandoning AI.
Staff using consumer AI tools for work without approval, visibility or record. It is almost always already happening by the time a business asks the question, and it is usually a symptom of a slow sanctioned process rather than of carelessness.
Client contracts, pricing, personal data and board papers pasted into a free tool to summarise. The immediate exposure is the copy sitting outside your control; the harder problem is that you have no record of what was shared.
A browser extension with access to every page a user visits, a note-taking tool joining meetings, a plug-in granted permanent consent to a mailbox. Each was installed to save time, and each is a standing data export route.
An AI assistant inherits the permissions of the person or service running it. Where SharePoint access has been broadly granted for convenience, the assistant will cheerfully surface files the user could technically reach but was never expected to find.
Instructions concealed in content the AI reads — an email, a supplied PDF, a web page — attempting to make it act against your interests. It matters most for systems that both read untrusted input and can take actions.
An automation given broad permissions for a project and left running afterwards, unmonitored, with credentials nobody has reviewed since. It is the AI-era equivalent of a service account with domain admin.
Where prompts and uploads are stored, for how long, in which jurisdiction, and whether they can be used to improve a vendor's model. Consumer and business tiers of the same product often differ substantially.
Confident, plausible, wrong. A real operational risk where output feeds a decision, a customer communication or a regulatory return without anybody checking the source.
Employee use
Every governance position that succeeds has this property. Every one that fails lacks it.
Staff adopt whichever route removes the friction from their day. If the sanctioned tool requires a request form and a three-day wait while the free alternative is one browser tab away, the policy is decorative regardless of how firmly it is worded.
The practical answer is to give people something good, reached through their normal sign-in, with contractual protections behind it — and then to be clear about the small number of things that must not go anywhere near it. That combination is enforceable, and it is also considerably more popular than a ban.
It also changes the conversation internally. Staff who found a workaround because they were trying to do their jobs well are far more receptive to a boundary that comes with a better tool than to one that comes with a warning.
Where the decisions sit
Governance is not a separate workstream bolted on at the end. It is the middle three layers of every AI deployment, and it is far cheaper to decide before the tool is in daily use.
Controls
Proportionate to your size and obligations. A 40-person business does not need the framework a bank needs, and pretending otherwise produces a document nobody follows.
A short, current list of what staff may use for work, at which tier, and for what kind of information. Short enough that people can remember it; specific enough to be enforceable.
AI tools reached through your identity provider, with the same conditional access, device requirements and revocation as any other business application.
Every AI system and agent has a named identity — a person's or a service's — so actions are attributable, reviewable and revocable without disrupting anyone else.
Explicit rules on what categories of information may go to which tools. Personal data, client confidential material and commercially sensitive pricing are the ones that need naming.
A record of what was used, by whom, against what data. Without this you cannot answer a client question, satisfy an auditor or scope an incident.
How long prompts, uploads and outputs are retained by the vendor and by you, aligned with your existing retention schedule rather than left to a default.
Two pages that a member of staff will actually read, covering what is permitted, what is not, and what to do when they are unsure. Not a twelve-page document nobody opens.
A proportionate review of an AI vendor before adoption: data location, retention, training use, sub-processors, security posture and what happens to your data if you leave.
Where the model runs, whether your inputs contribute to training, what happens to embeddings and indexes of your documents, and whether the arrangement matches what you have told your own clients.
Named accountability for AI use, defined review points for consequential output, and a route for staff to raise concerns without it being treated as an admission of misuse.
For the board
If the answer is unknown, that is the first piece of work — and it is achievable in a couple of weeks.
Staff need a rule they can apply without asking. Three or four named categories is usually enough.
This is increasingly asked in tenders and contract reviews. An honest “we don't know” is a commercial problem, not merely a technical one.
A named owner, and a plan for the day something goes wrong — the same expectation applied to every other operational risk.
None of these require technical knowledge to ask, and all of them are reasonable questions for a board to put to its executive team.
Process
Discovery first. Writing a policy before you know what is actually being used produces a document that addresses the wrong problem.
Discovery of AI tools already in use — through tenant data, network and application logs, app consents and honest conversations with teams. Framed as fact-finding, not enforcement.
Agree approved tools, data categories and the handful of rules that matter. Chosen so the sanctioned route is faster than the workaround, because otherwise the workaround wins.
Identity integration, conditional access, app consent governance, logging, retention and DLP where it earns its place. Technical enforcement rather than a document.
Brief the organisation in plain terms, give people somewhere to ask, and schedule a review — because the tool landscape will look different in six months.
FAQ
A ban is easy to announce and almost impossible to enforce, and it reliably produces the worst outcome: continued use, on personal devices and personal accounts, with no visibility at all. A workable approved-tools position with a business-tier tool that is genuinely faster than the workaround achieves far more than a prohibition nobody follows.
Several routes, used together: enterprise application and app consent data in Entra ID, browser extension inventory on managed devices, network or proxy logs, expense claims for personal subscriptions, and — most productively — asking teams directly in a way that does not invite them to conceal it. The last one usually surfaces more than the technical controls do.
A sanctioned, business-tier tool that staff can actually use, reached through your identity provider. It converts an invisible problem into a managed one: you gain contractual data protection, logging, access control and revocation, and you remove the incentive to use something unmanaged.
Yes, and unremarkably so. Putting personal data into an AI tool is processing, and the usual questions apply — lawful basis, purpose, minimisation, transparency, international transfer and whether the vendor is a processor under adequate terms. AI does not create a special regime, but consumer tools frequently do not meet the terms you would accept from any other processor. We are technical advisers rather than lawyers, and we will tell you when a question needs your solicitor or DPO.
Discovery and a workable policy position typically take three to four weeks for an organisation of a few hundred staff. Technical enforcement — identity integration, app consent governance, logging — usually follows over a further four to six weeks depending on your existing Microsoft 365 posture.
Someone at director level with authority over both technology and process — commonly the operations or finance director in an SME, rather than IT alone. The decisions involved are about what data may go where and who is accountable for output, which are business decisions with technical consequences, not the reverse.
Discovery is quick, and the results are usually more surprising than uncomfortable. It is a considerably better position than finding out during a client audit.