# Private AI for OpenText Content Server and Documentum On-Prem > Source: https://netray.co/erp-help/private-ai-layer-opentext-documentum-on-prem-architecture > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## Short answer Both products expose supported APIs that a private AI layer can use without touching the cloud: the Content Server REST API and search for OpenText, DQL, DFC, DFS and Documentum REST for Documentum. Extract text and metadata through those interfaces, keep each object's permissions beside its chunks, and serve an open-weight model on local GPUs. ## Kind advanced ## System on-prem-apps ## Erp OpenText Content Server and Documentum ## Module Document management and records ## Query AI integration for OpenText Content Server or Documentum on-prem ## Alternate Queries - Documentum DQL query for AI retrieval - OpenText Content Server REST API private LLM - Documentum RAG on-prem without cloud ## Applies To OpenText Content Server 16.x to 23.x and Documentum 7.x to 23.x on Oracle, SQL Server or PostgreSQL. Verify API versions for your release. ## Steps ### Roll out a private AI layer over a document repository **Items:** - Choose the scope: a few cabinets, folders or workspaces holding SOPs, drawings, supplier documents or contracts. Record the object types and metadata that matter. - Create a read-only service identity. For Documentum use a repository user with browse rights; for Content Server a user with See and See Contents on the scope. - Enumerate objects with DQL or the REST API and store object id, name, version label, modified date and permissions. - Download the current version's content rendition and extract text. Use the PDF rendition where one exists to avoid proprietary formats. - Chunk, embed locally and store each chunk with its source id, version and the principals allowed to read it. - Poll for changes by modify date or, in Documentum, by r_modify_date and dm_audittrail events, and apply updates and deletes to the index. - Expose approved read tools through an MCP or HTTP server and put the model behind it with every call logged. ## Sections ### Data access: what each product gives you **Body:** Documentum stores metadata in the repository database as objects such as dm_sysobject and dm_document, with ACLs in dm_acl, and content files in the file store with dmr_content linking them. The supported ways in are DQL (a SQL-like language over the object model), DFC (Java), DFS web services and Documentum REST Services. Query through DQL or REST rather than going to the RDBMS, because DQL applies the repository's security and handles versions for you. OpenText Content Server keeps nodes in a relational database; the DTree table is the node table keyed by DataID, with SubType identifying documents and folders. You can read this for analysis in a replica, but for ingestion use the Content Server REST API (v1 and v2), the search engine, or an OScript/LiveReport your administrators already trust. Records management and holds add metadata you must carry into the index. **Code:** -- Documentum DQL: current documents in a folder tree, with ACL name SELECT r_object_id, object_name, r_modify_date, acl_name, a_content_type FROM dm_document WHERE FOLDER('/Quality/SOPs', DESCEND) ORDER BY r_modify_date DESC # OpenText Content Server REST (check the v2 path for your release) GET https://cs.corp.local/otcs/cs.exe/api/v2/nodes/12345/nodes?limit=100 OTCSTICKET: ### Reference architecture and the air-gapped variant **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 repositories, the retrieval index is the main new component: it stores text extracted from the latest approved version, not drafts, unless the use case needs drafts. Keep renditions separate from source content. Extract from the PDF rendition when present, run OCR on scanned images, and store the extraction method with the chunk so quality problems can be traced. In an air-gapped plant the whole stack runs on a closed network segment with the repository, using hash-verified transfers for model weights and updates. Version and lifecycle state are part of the answer. A good tool server returns the version label, the lifecycle state (Draft, Approved, Obsolete) and the effective date so the model can say which revision it quoted. ### Permissions, holds and write-back **Body:** Documentum ACLs list users and groups with permit levels such as browse, read and write, and the repository also has folder security and sometimes Mandatory Access Control or Trusted Content Services features. Content Server uses per-node permissions with groups. Store the allowed principals on each chunk, resolve group membership at question time from the directory, and filter in the retrieval step. Legal holds, retention and records classification must not be bypassed. Never index or summarize objects the policy marks as restricted, and keep deletions in the source system flowing to the index. Write-back is limited to supported API calls, for example creating a draft object or starting a workflow, with a named person approving and the action recorded in the repository's own audit trail as well as yours. ### Sizing, phases and honest limits **Body:** A repository of 1 million documents averaging 12 pages produces tens of millions of chunks after 2 chunks per page, so plan the index on dedicated NVMe storage and consider a dense plus keyword hybrid. Serving 1,000 to 3,000 named users on a 7B to 32B model is typically one to four GPUs. Initial extraction can take days; run it on spare GPU or CPU capacity off hours. Phase one: cited Q&A on a pilot scope. Phase two: drafting and comparison, for example compare two revisions of an SOP. Phase three: approved actions through the API. Limits: heavy CAD binaries, protected PDFs and encrypted objects will not yield text, and vendor AI offerings may be enough if you already license them and your policy allows their hosting. ## Pitfalls - Indexing every version. Users then get answers from obsolete revisions; index the approved version and expose state. - Going to the RDBMS to save time and ignoring ACLs. The database does not enforce repository security for you. - Skipping records and hold rules. Retention classifications can make some content off limits for processing. - Assuming every file has extractable text. Scans, drawings and encrypted files need OCR or are excluded. - Letting stale chunks live after a delete or a permission change. Run a nightly reconciliation of ids and ACLs. ## Ai Angle DataRay is built for exactly this pattern: chat over databases, file shares and document stores on-prem with read-only access and visible sources. For a Documentum or Content Server estate Netray builds the extraction, ACL mirroring and tool server with your content administrators. If the vendor's own AI is already licensed and acceptable to your security team, compare it first. ## Faq ### Should we query the Documentum database directly? **Answer:** Use DQL, DFC, DFS or Documentum REST instead. They apply repository security, handle versions and survive upgrades. Direct SQL is fine for a one-off analysis on a replica but not for an assistant that answers staff. ### How do we handle document versions? **Answer:** Index the version your policy treats as current, usually the latest approved, and store version label, lifecycle state and effective date on every chunk so the answer can name the revision it used. ### Can the assistant respect Documentum ACLs? **Answer:** Yes. Store the ACL principals per chunk or call the repository as the user, resolve group membership at question time, and filter in retrieval. Test with restricted users and review the audit log. ### Does this work for OpenText Content Server and Documentum both? **Answer:** The architecture is the same: supported API, local extraction, ACL-aware index, tool server, local model. Only the connector differs, because object models, versioning and permission models differ. ### Can this run fully offline? **Answer:** Yes. The index, embedding model and LLM run inside your network, and nothing calls an external service. Updates to models and containers arrive through a controlled, hash-verified transfer. ## Search terms documentum ai integration, opentext content server ai on-prem, documentum dql rag, private llm documentum, opentext rest api ai, documentum acl security rag, on-prem document management ai, air-gapped documentum --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json