Adopt AI without leaking your business.
What we actually do
Four pieces of work, run by the same operators who run the rest of your environment. No separate AI product, no separate bill.
Fix the oversharing first
Most AI leaks are not clever attacks. They are a file share set to everyone, a mailbox with delegated access nobody revoked, a site inheriting permissions from a template. We find and close that exposure before any AI tool is pointed at it, which is worth doing whether or not you ever adopt AI.
See what is already in use
Your team has almost certainly started without you. We work through the accounts, browser extensions, and connected apps in your tenant to build an honest picture of what is being used and with what data, so the conversation starts from facts instead of assumptions.
Set baselines that hold
Sensible defaults on the tools you keep: which data they may reach, which accounts may use them, what gets logged, and what is simply blocked. Configured in your tenant by the people who operate it, not handed to you as a recommendation to implement yourself.
Put a policy behind it
A short acceptable-use policy your team can actually read, in language that matches how they work, with a record of who has acknowledged it. Enough to answer a customer asking how you govern AI, without pretending you run an AI assurance programme you do not.
Where the pressure actually comes from
It is worth being straight about this, because a lot of AI governance marketing is not. If you are a US company under a few hundred people, there is most likely no AI-specific statute compelling you to do any of this today. Anyone telling you otherwise is selling from fear.
The pressure is real, it just comes from somewhere else. It comes from your customers, whose security questionnaires have started asking how you govern AI use. It comes from your insurer at renewal. It comes from your own exposure, because the permissions problem underneath AI was already a problem.
Where we need a reference point, we work from published, voluntary frameworks rather than inventing our own: the NIST AI Risk Management Framework and ISO/IEC 42001, the AI management system standard. Neither is a legal obligation for most of our customers. Both are a sane place to borrow structure from.
If your obligations are genuinely more specific than this, because of your sector, your contracts, or where you operate, that is a conversation with your advisory lead, not a claim we will make for you on a web page.
What this is not
We are not here to sell you AI.
We do not resell an AI product, we do not take a margin on your model spend, and we have no interest in which assistant you land on. Our job is that whichever one you choose cannot reach what it should not reach, and that you can show someone how you decided.
If the honest answer for your business right now is not yet, we will tell you that, and the exposure work still leaves you better off.
Where it lands
The work shows up where the rest of your program does.
Exposure findings, the tools we agreed on, the baselines we set, and who has acknowledged the policy all sit in the platform alongside everything else we run for you, so an AI question at your next review is a page you open rather than a scramble.
Start with what is already exposed.
The permissions problem underneath AI is worth fixing on its own. Adoption gets easier once it is done.
Published tiers. AI governance is part of the operated program, not a separate line item or a per-seat meter.
Thirty minutes on what your team is already using and what it can currently reach.