AI for SharePoint and Microsoft 365 Without Giving Up Control of Your Data

Yes, and this is an architectural guarantee rather than a promise the model makes. At ingestion, every chunk inherits the access control list of its source item, including item-level unique permissions where inheritance has been broken. At query time we resolve the asking user's Entra ID group membership and filter the candidate set before retrieval, so content the user cannot open in SharePoint never enters the prompt context. That ordering matters: filtering after generation would mean the model had already read the document, and a sufficiently clever prompt could extract it. We validate this adversarially before go-live, using real accounts from each of your access tiers and deliberately attempting to retrieve restricted content. Where the tenant assessment finds over-shared or broken-inheritance sites, we surface that as a finding for you to remediate first, because AI does not create that exposure but it does make it far easier to discover.

They solve overlapping but distinct problems, and running both is a normal outcome rather than a compromise. Copilot lives inside the applications and is excellent there: drafting in Word, summarising a Teams meeting, triaging Outlook. A private layer is better when answers must draw on systems outside Microsoft 365 such as Xero, MYOB, LEAP or JobAdder, when the model needs tuning on your organisation's vocabulary rather than a generic index, or when a corpus is sensitive enough that you want the model, index and prompts on infrastructure you control and can audit. Cost also diverges, though not in the way a per-seat comparison suggests: Copilot is licensed per user and rises with headcount, while our pricing tiers on query volume rather than seats, starting at $2,999 per month on the Starter tier for a single custom model and up to 100,000 queries. Adding staff does not by itself add cost, but heavier use does, so the comparison turns on how much your people actually ask rather than on headcount alone — see our pricing page for the current tiers. The usual design splits by data classification: Copilot for everyday in-app productivity, the private layer for the corpora your risk committee cares about. We will tell you if Copilot alone is the right answer.

Chunks, embeddings, the vector index and the generative model all sit on infrastructure you control, either in an Australian cloud region such as Azure Australia East in Sydney or Australia Southeast in Melbourne, or on your own hardware for a fully on-premises deployment. The embedding model runs locally, which is the detail most implementations get wrong: if embeddings are generated by a hosted API, your document text has left the country to be vectorised regardless of where the resulting vectors are stored. Nothing about your content is used to train a third-party model. Your Microsoft 365 tenant remains the system of record and this layer holds a derived index alongside it. Worth noting separately: Microsoft offers Advanced Data Residency as a paid add-on covering core Microsoft 365 workloads, and exactly what that covers for AI processing is worth confirming directly with Microsoft or your reseller, as the commitments are repositioned periodically.

Technically yes, through the same Microsoft Graph application registration, and both are opt-in rather than included by default. Teams channel messages are often valuable because decisions get made in channels and never make it into a document, so a question about why an approach was chosen frequently only has an answer in Teams history. Outlook is more delicate. Mailboxes contain personal correspondence, HR matters and legally privileged material, and staff have a reasonable expectation that mail is not searchable by colleagues. Where we do include Exchange, it is usually shared and functional mailboxes such as accounts or enquiries rather than individual mailboxes, and permission trimming applies exactly as it does to SharePoint. We would rather scope Outlook out at the start and add it deliberately later than have a staff member discover their mail was indexed without a conversation first.

The index tracks change continuously rather than rebuilding on a schedule. Microsoft Graph delta queries and change notification subscriptions push new, modified and deleted items into the pipeline, so a typical update is re-chunked, re-embedded and retrievable within minutes of being saved. Deletions matter more than most people expect: if a document is removed from SharePoint or a permission is revoked, that change has to propagate or the AI keeps answering from content that no longer exists or is no longer permitted. We handle tombstones explicitly and treat permission changes as index events in their own right. On top of the delta stream we run scheduled reconciliation passes, because change feeds occasionally miss events during throttling or service interruptions, and a corpus that silently drifts out of sync is a quiet correctness problem rather than a loud one.

Eight to twelve weeks from scoping engagement to production is typical for a mid-sized tenant, and the distribution of that time surprises people. Roughly the first two to three weeks are tenant and permission assessment, which is where most of the real complexity surfaces: broken inheritance, orphaned sites, archives nobody will make a decision about. Ingestion and indexing is fast, often a couple of weeks. Validating permission trimming and tuning retrieval against real questions takes longer than building the pipeline did, and it is the part we will not compress, because an AI that is fast and wrong is worse than no AI. Tenants that take longer usually do so for governance reasons rather than technical ones, most often waiting on decisions about which sites are in scope. If your permission structure is clean and scope is a single well-defined corpus, the shorter end is realistic.