# How to Add AI to SharePoint Server On-Prem Without Moving Your Data > Source: https://netray.co/erp-help/private-ai-layer-sharepoint-server-on-prem-architecture > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## Short answer You can put a private assistant over SharePoint Server 2016, 2019 or Subscription Edition without any cloud service. Read content through the SharePoint REST API and the Search service, index it locally with the source permissions attached, and serve an open-weight model with vLLM or Ollama on your own GPUs. Microsoft 365 Copilot does not cover SharePoint Server on-prem, so this is the route for farms that stay in the data center. ## Kind advanced ## System on-prem-apps ## Erp Microsoft SharePoint Server (on-prem) ## Module Content, Search and Permissions ## Query how to add AI to SharePoint Server on-prem ## Alternate Queries - SharePoint Server 2019 AI integration without cloud - private LLM over SharePoint on-premises documents - SharePoint on-prem RAG with security trimming ## Applies To SharePoint Server 2016, 2019 and Subscription Edition, farms on SQL Server, claims-based authentication with AD DS. Check Microsoft's lifecycle page for support dates of your version. ## Steps ### Build the private AI layer in six steps **Items:** Inventory what is worth answering from: document libraries, lists, wiki and site pages, and which web applications and site collections hold them. Skip personal sites and archives at first. Create a dedicated service account with read-only rights and register it as the crawler identity. Do not read the SQL content databases directly; use REST, CSOM or the Search service. Pull documents and metadata through the REST API or an incremental crawl, and use the change log (GetChanges) so only modified items are re-processed. Extract text (Office, PDF, OCR for scans), chunk it, embed it locally, and store every chunk with its ACL principals and the source URL. Stand up an MCP or HTTP tool server with approved read tools such as search_documents and get_document_summary, and put an open-weight model behind vLLM or Ollama on local GPUs. At question time resolve the asking user's AD groups, filter the index by those principals, and ask the model to answer only from the returned passages with citations. Log the question, the passages retrieved and the answer to an append-only store, then review it weekly with the farm owner. ## Sections ### Data access paths: use the supported surface, not the content database **Body:** A SharePoint farm keeps its content in SQL Server content databases, with document metadata and binary streams spread across tables such as AllDocs, AllUserData and AllDocStreams. Microsoft does not support reading or changing these tables directly, the schema moves between versions, and remote BLOB storage can place the bytes outside SQL entirely. Treat the database as an implementation detail. The supported surfaces are the SharePoint REST API under /_api, the client-side object model (CSOM), and the Search service application with its query endpoint. REST gives you lists, files and permissions. Search gives you a security-trimmed ranked result set and a managed crawl that already handles many file formats. For bulk ingestion most teams use REST plus the change log, and keep Search as an additional retrieval signal. **Code:** # Search as the end user (Kerberos constrained delegation or an app that passes the user claim) GET https://sp.corp.local/sites/quality/_api/search/query?querytext='AS9100 corrective action'&selectproperties='Title,Path,LastModifiedTime,Author'&rowlimit=20 Accept: application/json;odata=nometadata # Incremental ingestion: items changed on a list since a stored change token POST https://sp.corp.local/sites/quality/_api/web/lists/getbytitle('Procedures')/GetListItemChangesSinceToken # Fetch the file bytes for text extraction GET https://sp.corp.local/sites/quality/_api/web/GetFileByServerRelativeUrl('/sites/quality/Procedures/SOP-114.docx')/$value ### Reference architecture **Body:** Reference architecture used on every page of this series: (1) a read-only replica or reporting copy of the data, (2) change capture so the index stays current, (3) a retrieval index with the source ACLs stored beside every chunk, (4) a tool server (MCP or plain HTTP) that exposes only approved read actions, (5) an open-weight model served with vLLM or Ollama on local GPUs, (6) an append-only audit log. For SharePoint the replica is not a database copy. It is a normalized store of extracted text and metadata that your ingestion job builds from REST responses. The vector index (pgvector, Qdrant or OpenSearch run on your own servers) holds chunks, embeddings, the source URL, the modified date and the allowed principals. A change-detection job reads the change log every few minutes and updates or deletes chunks. In an air-gapped farm the same stack runs with model weights, container images and Python wheels brought in through a transfer process and checked by hash. The tool server is where you enforce policy. Expose search and fetch only, return the citation with every passage, and cap result size. The model never gets a connection string or a service account token. ### Permissions: mirror SharePoint, do not approximate it **Body:** SharePoint security is inherited and then broken: site, library, folder and item level permissions, SharePoint groups, AD security groups and claims. If your index is built by a service account that sees everything, a naive assistant becomes a way to read documents the user could not open. There are two safe patterns. Pattern one: query SharePoint Search as the user, so the platform's own security trimming applies, and let the model see only what comes back. Pattern two: store the ACL principals resolved at crawl time on every chunk, resolve the user's AD groups at question time, and filter before retrieval. Pattern two is faster and works for a vector index, but you must refresh ACLs on a schedule and handle permission changes and deleted users. Test with a user who has limited rights and prove that restricted files never appear in the answer or the citation list. ### Sizing, rollout and write-back **Body:** Text extraction and embedding are the heavy one-time work, about 1 to 3 chunks per page; a 500,000 document farm averaging 8 pages lands in the 4 to 12 million chunk range and tens of GB of index. Serving a 7B to 32B class open-weight model for a few thousand named users is usually one to four data-center GPUs, depending on concurrency and context length. Use the sizing calculator for your numbers. Roll out in three phases. Phase one is read-only questions with citations over a few libraries. Phase two drafts content, for example a summary or a change notice, that a person pastes into SharePoint. Phase three allows narrow approved actions, such as creating a list item or starting a workflow, through the REST API with a human approving each call and the action logged. Never let the model write with a broad service account. ## Pitfalls - Reading the content databases directly. It is unsupported, breaks on cumulative updates, and bypasses security trimming. - Indexing as a farm admin and filtering later in the prompt. The model cannot be trusted as an access control layer; filter in the retrieval step. - Ignoring item-level permission breaks. Libraries with thousands of uniquely permissioned items slow ACL resolution and need a plan. - Treating scanned PDFs as text. Without OCR the index is empty for much of an engineering library. - Forgetting deletes and moves. A moved or deleted file must disappear from the index quickly, or the assistant cites documents that no longer exist. - Running a version near or past end of support and planning AI as a reason to stay. Decide the upgrade path first. ## Ai Angle ERPray and DataRay can run over a SharePoint library the same way they run over an ERP: they connect read-only, show the passages and the query behind each answer, and respect the asking user's permissions. Netray designs and runs this private layer with your IT team. If you only need search inside a hybrid Microsoft 365 tenant, Microsoft's own tools may be enough and cheaper. ## Faq ### Does Microsoft 365 Copilot work with SharePoint Server on-prem? **Answer:** Copilot grounds on Microsoft 365 content in the cloud. A farm that stays on SharePoint Server on-prem is outside that boundary, apart from whatever hybrid search you have configured. A private layer over REST and Search covers the on-prem content. ### Can the model read the SQL content database for speed? **Answer:** It should not. Direct reads are unsupported by Microsoft, depend on version specific schema, and skip security trimming. REST, CSOM and Search are slower to set up but are the surface that survives updates and keeps permissions intact. ### How do we keep answers limited to what a user can open? **Answer:** Either call Search as the user so SharePoint trims the results, or store resolved ACL principals on each chunk and filter by the user's AD groups before retrieval. Test with restricted accounts and keep the audit log. ### Can it work air-gapped? **Answer:** Yes. Embedding model, LLM, vector store and tool server all run inside the network. Weights and containers enter through a controlled transfer and are verified by hash. Nothing calls an external API at question time. ### What GPU do we need? **Answer:** For a few thousand named users with modest daily use, one to four data-center GPUs serving a 7B to 32B open-weight model is a typical range. Concurrency, context length and model size move that; measure with a pilot. ## Search terms sharepoint server on-prem ai, sharepoint 2019 ai integration, private llm sharepoint, sharepoint on-premises rag, sharepoint rest api search security trimming, air-gapped sharepoint ai, sharepoint copilot alternative on-prem, sharepoint subscription edition ai --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json