Contents
Construction companies keep their working knowledge in project sites, and each site carries its own members and often its own permissions. In our production environment, 865 SharePoint sites and about 400,000 documents in four languages, the private AI assistant went live in about eight working days. The hard part is permissions, not the model, and this chapter shows what to check in your own tenant first.
What does a construction company keep in SharePoint?
Almost everything that matters on a job: HSE plans, risk assessments, contracts and their amendments, drawings registers, subcontractor correspondence and meeting minutes. In the environment I run, that material sits in 865 SharePoint sites holding about 400,000 documents, measured on the production index.
In a typical construction tenant each project gets its own site and its own members when it starts, and those sites are rarely cleaned up when the project ends. That is normal in construction. It is also the reason an AI assistant across such a tenant is not mainly a model problem.
Microsoft’s customer material shows the same pull toward SharePoint content. A UK homebuilder reports that using Microsoft Copilot to search the company’s SharePoint intranet “is now one of the biggest use cases”.[1] The value is in the documents people already have. The risk is in who may see them.
Why do project sites make permissions hard for an AI assistant?
SharePoint permissions flow downward by default. Microsoft Support explains that, by default, content in a site collection inherits its permission settings from the site directly above it.[2] A project team breaks that inheritance the moment a folder is shared with one subcontractor, and from then on that folder carries its own permissions.
Microsoft writes that “we highly recommend using the built-in SharePoint groups for communication sites and managing team site permissions through the associated Microsoft 365 group.”[2] On a live construction site that advice competes with a deadline, and the deadline usually wins.
Multiply that by several hundred projects over several years and nobody can say from memory who may open what. Microsoft’s deployment guidance for Microsoft Copilot describes the assistant as “grounding responses in the data users already have permission to access”.[3]
Microsoft’s documentation for the site permissions report adds that “Sites with many users accessing content pose higher risk for unintended data exposure through Copilot interactions.”[4] The same logic applies to any assistant you place alongside it.
In the environment I run, permissions are therefore checked before the answer. A person gets answers only from documents he may open himself. That rule is cheap to state and expensive to skip.
How long does a rollout across hundreds of sites take?
In that construction company the assistant went live in about eight working days. That is my own data from one tenant, not a benchmark.
If permissions in your tenant are unknown, add the time it takes to learn them, and the box below shows how. An assistant that respects permissions can only be as good as the permissions it respects.
Does it work in several languages?
Construction in the Nordics and Baltics is multilingual by nature: the contract may be in one language, the site diary in another, and the HSE plan in a third. In this environment the assistant is configured for four languages.
That is a configuration decision, not a property of the documents. Test it with real project files from your own tenant rather than assuming it.
What happened when the index missed documents?
The honest part of this chapter. Between 24 August and 2 September 2026, about 30 documents and about 20 deletions never reached the index. Index cycles took 20 to 87 minutes, and one cycle hit the job timeout of 5,400 seconds.
The mechanism matters because any indexer built on Microsoft Graph delta can make the same mistake. Microsoft documents the change feed as follows: “To check for changes in the future, call delta again with the @odata.deltaLink from the previous response.”[5] And: “Deleted items are returned with the deleted facet. Items with this property set should be removed from your local state.”
The same documentation says: “After you have finished receiving all the changes, you may apply them to your local state.”[5] If an indexer stores the new deltaLink before it has actually processed every item, a file that failed for an infrastructure reason is simply gone from the feed. Nothing reports it.
What changed afterwards is a design rule, not a patch. A failed file no longer disappears silently; it goes on a list with its reason, and the change feed does not move forward when the failure is in the infrastructure.
The full account is published as the SharePoint Graph delta link silent document loss story. Ask any vendor the same question: what happens to a document when indexing fails, and who finds out.
What we do not know
The eight-working-day figure comes from one tenant that I already administered. I do not know how it transfers to a tenant where nobody can name the permission model.
The index loss was found and measured in one production environment between 24 August and 2 September 2026. I cannot say how often the same pattern occurs elsewhere, only that the same design choice, storing a deltaLink before processing finishes, can cause it anywhere.
I have not published a per-language measurement of answer quality. Four languages is a configuration, and only your own project files can tell you how well the assistant reads them.
The Microsoft report above counts unique permissions and users. It does not tell you whether a given permission is wrong. That judgement still needs a person who knows the projects.
How KSJ does it
For more than six years I have run the Microsoft 365 platform of a construction company in Latvia, Norway and Sweden: the SharePoint architecture and its move to modern sites, permissions and governance, the Power Automate and Power Apps flows that site managers use to approve invoices, and the private AI assistant that answers from its 865 SharePoint sites and about 400,000 documents. This chapter is built on that daily work.
The design follows what that work taught. The assistant checks SharePoint permissions before it answers, so that a person only receives answers from documents he may open, and is configured for four languages.
A failed file goes on a list with its reason instead of vanishing, and the change feed waits when the infrastructure is at fault. It runs alongside Microsoft Copilot where a company has it. If you want the mechanics, this is how Answergrove works across many sites.
Drafted with AI assistance, checked against the cited Microsoft sources and approved by Kaspars Jurjāns.
References
- ^ a “Taylor Wimpey harnesses Microsoft 365 Copilot aiming to become the UK’s first digital housebuilder | Microsoft Customer Stories” (opens in a new tab). Microsoft. Retrieved 11 November 2026.
- ^ a b “Customize permissions for a SharePoint list or library” (opens in a new tab). Microsoft Support. Retrieved 11 November 2026.
- ^ a “Secure & Governed Data Foundation for Microsoft Copilot – Foundational Deployment Guidance” (opens in a new tab). Microsoft Learn. Retrieved 11 November 2026.
- ^ a b c d e “Data access governance reports – get site permission states snapshot report for SharePoint sites – SharePoint in Microsoft 365” (opens in a new tab). Microsoft Learn. Retrieved 11 November 2026.
- ^ a b “driveItem: delta – Microsoft Graph v1.0” (opens in a new tab). Microsoft Learn. Retrieved 11 November 2026.
- ^ a “Prerequisites for SharePoint Advanced Management – SharePoint in Microsoft 365” (opens in a new tab). Microsoft Learn. Retrieved 11 November 2026.
- ^ a “Data access governance reports for SharePoint sites – SharePoint in Microsoft 365” (opens in a new tab). Microsoft Learn. Retrieved 11 November 2026.
- ^ a “Manage sites in the SharePoint admin center – SharePoint in Microsoft 365” (opens in a new tab). Microsoft Learn. Retrieved 11 November 2026.