AI security questions, answered

Any AI service your people use for work that nobody formally approved. Someone finds a tool that summarises documents, signs up with their work email, and starts using it. No procurement, no security review, no record.

It is rarely malicious. It is people trying to get their work done faster with tools that are free, useful and one click away.

Same shape, faster and higher stakes. Shadow IT usually meant an unapproved file-sharing or project tool. The data risk was real but bounded.

With AI, the interaction is the data. People paste in contracts, customer records, source code and board papers to get a useful answer. The volume of sensitive information leaving the organisation per session is far higher, and the adoption curve has been steeper than anything before it.

AI governance is knowing which AI your organisation uses, deciding what is allowed, and being able to show that the decision was enforced. Three parts: an inventory, a policy, and evidence.

It is often confused with AI ethics, which is about how models behave. Governance is more mundane and more urgent: a register of what is in use, rules about which tools and what data, and logs proving the rules applied.

Four, in the order they usually bite. Data leaving the organisation into services with unknown retention and training practices. Compliance exposure, because you cannot evidence control over systems you have not inventoried. Duplicate spend on tools nobody tracks. And AI output flowing back into documents and code with no record of where it came from.

The data one gets the attention, but the compliance one is what turns into a deadline.

Two reasons. First, it does not work. Blocking the well-known services pushes people to the long tail, and there are thousands of AI tools with a new one every week. You end up with the same behaviour on services you have never heard of.

Second, it costs you the productivity. Most organisations have decided AI is worth using. The question is which tools, by whom, and with what.

The workable position is a short approved list, enforced technically, with everything else visible.

Yes, and that is the strongest argument against blanket blocking. Heavy-handed restriction does not remove the behaviour, it removes your visibility of it. The work moves to a personal laptop or phone where you have no policy, no logs and no way to know it happened.

This is why coaching usually beats blocking for anything ambiguous. Hard blocks are worth reserving for genuine exfiltration risk, such as uploading files to an unverified service.

They are one of the most overlooked blind spots. An AI meeting assistant is usually authorised with a work account and granted access to the calendar, and often the mailbox too. It then sits in meetings recording and transcribing whatever is discussed.

Because they are authorised rather than installed, they can be invisible to endpoint scanning. They also raise a consent question, since the other people in the meeting may not know a transcript is being made.

More than most IT teams expect, which is the point. In the run-up to the EU AI Act high-risk deadline, over half of organisations had not established a systematic inventory of the AI systems they operate, so the honest answer for most is that nobody knows.

That is what the risk check and the AI Health Check exist to establish. Guessing is the current state, not a plan.

Possibly. The Act reaches organisations outside the EU where the AI system is used in the EU or its output is used there, so UK organisations with EU operations, EU customers or EU staff can be in scope. UK-only organisations generally are not.

This is a question for your legal team rather than a security vendor, and we are not qualified to answer it for your specific situation. What we can tell you is what AI is actually in use, which is the input that question needs.

No. It was deferred six days before it was due to bite. The Digital Omnibus on AI, Regulation (EU) 2026/1744, entered into force on 27 July 2026 and moved the deadline for standalone high-risk systems under Annex III from 2 August 2026 to 2 December 2027. AI embedded in products already covered by EU product-safety law moves to 2 August 2028.

Deferred is not cancelled. The Article 26 duties on deployers are unchanged when they arrive: use systems as intended, assign human oversight, monitor operation, and keep the logs for at least six months. The inventory work that has to happen first is the same work, on a longer clock.

One part of the August 2026 date did survive. The Article 50 transparency obligations still apply from 2 August 2026, covering things like telling people they are talking to a chatbot and marking synthetic content. Those mostly bind organisations that build or deploy AI systems of their own rather than those whose staff use external AI services.

Sources: Cloud Security Alliance research note on the deferred deadline and Article 26 of Regulation (EU) 2024/1689.

Penalties for breaching high-risk obligations reach €15 million or 3% of global annual turnover, whichever is higher. The often-quoted 7% figure applies to prohibited AI practices, not to deployer duties.

No, and be sceptical of anyone who says their product does.

Compliance is an assessment your organisation makes, usually with legal input. What software can do is produce the evidence that assessment needs: what AI is in use, who is using it, what you decided to allow, and a retained log showing the policy was enforced.

We produce that evidence. The conclusion stays with you.

ISO 42001 is the AI management system standard, and it is moving quickly from novelty to expectation. It is appearing in a growing share of enterprise vendor questionnaires, and certification bodies have reported long waits for audit slots.

Like ISO 27001, it is about having a system you can evidence rather than a product you can buy. An accurate inventory of AI in use is one of the first things an auditor will ask for.

Discovery happens at the web layer, through an endpoint agent, rather than by routing your traffic through our cloud and inspecting it there.

That matters practically: coverage is not limited to a list of integrations someone remembered to connect, so a service nobody has heard of still shows up. And it means no latency penalty, no re-architecture project, and no dependency on our network being available for your people to work.

No. Today we govern which AI services can be reached and what actions are permitted within them: uploading a file, sharing a conversation, connecting a plugin, signing in with a personal account.

Inspecting the content of prompts is a different capability. It is on the roadmap and it is not shipped, so we do not claim it. If prompt-level data control is your primary requirement today, be aware that some larger platforms are ahead of us there.

Both, and the distinction is worth being precise about. There is an endpoint agent. What there is not is a proxy: your traffic is never rerouted through our infrastructure on its way to wherever it was going.

We say proxyless rather than agentless, because agentless would not be true.

Blocking stops the action. Coaching allows it but interrupts first, with a message at the moment it matters, explaining the policy and asking the person to confirm.

Coaching tends to work better than blocking for anything ambiguous. It changes behaviour without generating a support ticket, and it does not push people towards a tool you cannot see.

Minutes to a first policy, because there is no network change to make. Realistically, rolling the agent out across a few thousand endpoints follows whatever your normal software deployment process is.

The comparison worth making is with proxy-based platforms, where the deployment is a re-architecture programme rather than an install.

No. This governs how your people use external AI services. Securing models and applications your own developers build is a different discipline, usually called AI application security, and it needs different tooling.

Yes, and we would prefer it. TrustLayer is channel-led, so if you already buy security through a partner or telco, they can run the commercials and the support relationship. Tell us who they are on the demo form and we will bring them in rather than around them.

A two-week deployment that reports the AI services genuinely in use across your organisation, with no commitment to buy anything afterwards. It exists because the two-minute risk check tells you what you think is happening, and this tells you what is actually happening.

Most organisations find services they did not know about. That findings report is usually the thing that starts the internal conversation.

At minimum: which tools are approved, what data must never be entered, who to ask for an exception, and what happens to AI-generated output. Keep it to one page that people will actually read.

The most common failure is not a bad policy, it is a policy nobody enforces technically. A written rule about not pasting client data is a hope. The same rule backed by a control is a policy. If you only do one thing, publish the approved list and make it easy to find.

Often, yes, and it is the argument that lands with finance when security does not. Organisations without a central view of AI tooling tend to accumulate duplicate subscriptions across teams.

Individual teams expense similar tools separately, nobody consolidates, and nothing gets cancelled when people leave. An inventory usually pays for itself before the security case is even made.

No. AI governance sits in the Browse layer and can be adopted on its own. Whether you consolidate email, web, cloud and users onto the same platform afterwards is a separate decision, and a commercial one rather than a technical dependency.