Private AI for OpenText Content Server and Documentum On-Prem
AI integration for OpenText Content Server or Documentum on-prem
Also searched as
- Documentum DQL query for AI retrieval
- OpenText Content Server REST API private LLM
- Documentum RAG on-prem without cloud
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.
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.
Roll out a private AI layer over a document repository
- 1Choose the scope: a few cabinets, folders or workspaces holding SOPs, drawings, supplier documents or contracts. Record the object types and metadata that matter.
- 2Create 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.
- 3Enumerate objects with DQL or the REST API and store object id, name, version label, modified date and permissions.
- 4Download the current version's content rendition and extract text. Use the PDF rendition where one exists to avoid proprietary formats.
- 5Chunk, embed locally and store each chunk with its source id, version and the principals allowed to read it.
- 6Poll for changes by modify date or, in Documentum, by r_modify_date and dm_audittrail events, and apply updates and deletes to the index.
- 7Expose approved read tools through an MCP or HTTP server and put the model behind it with every call logged.
Data access: what each product gives you
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.
-- 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: <ticket from /api/v1/auth>
Reference architecture and the air-gapped variant
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
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
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.
Try it here, free
OpenText Content Server and Documentum Private AI Layer Blueprint Generator
Fill in your OpenText / Documentum environment and export an architecture plan for a private, on-prem AI assistant: components, security controls, rollout and open questions.
Common 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.
How an ERP-grounded AI assistant handles this
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.
Frequently asked questions
Should we query the Documentum database directly?
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?
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?
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?
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?
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.
Related
How to Add AI to SharePoint Server On-Prem Without Moving Your Data
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.
CIO briefingOn-Prem vs Cloud ERP AI for Regulated Manufacturers
For ITAR, CMMC, and export-controlled manufacturers, the deciding question is not on-prem versus cloud in general but whether controlled unclassified information (CUI) or export-controlled technical data ever leaves your boundary to reach an AI model. An on-prem or private-VPC-deployed AI layer keeps that data inside your control boundary; a vendor's shared cloud AI service usually does not, regardless of how the core ERP itself is hosted.
CIO briefingIs Your ERP Data Ready for AI? A Readiness Checklist
Most ERP data is ready enough to start a scoped AI pilot immediately; full data-quality remediation is not a prerequisite. A handful of specific gaps - duplicate item or customer masters, inconsistent units of measure, missing descriptions, and orphaned records - will visibly degrade AI answers and are worth checking before the pilot, not after.
AdvancedHow to add a private AI layer to Infor LX / BPCS on-prem
BPCS and Infor LX run on IBM i with their data in Db2 for i, in files that carry short coded names by module. A private AI layer reads those files through read-only SQL views over a replica, indexes documents and attachments separately, exposes approved queries through a tool server, and serves an open-weight model on local GPUs. Writes, if any, go through the supported transaction programs with human approval.
AdvancedHow to add a private AI layer to Infor System21 on-prem
System21 runs on IBM i with its business data in Db2 for i. The practical private AI pattern is a read-only replica or extract, SQL views that give files readable names, a retrieval index over documents, a tool server of approved queries, and a locally served open-weight model. User visibility is carried over from System21 security and company set-up, and writes only go through its supported entry points after approval.
AdvancedHow to add a private AI layer to Infor EAM on-prem
On-prem Infor EAM stores its data in an Oracle or SQL Server schema whose tables use the R5 prefix, and it exposes web services for supported access. A private AI layer reads equipment, work order and parts data through read-only views on a reporting copy, indexes failure notes and manuals for retrieval, mirrors EAM organisation security, and serves an open-weight model locally. Work orders created or changed by the assistant go through EAM's web services after a person approves.
AI for ERPA Private LLM Grounded on Your ERP Data
How a private LLM answers questions on your ERP data: RAG plus text-to-SQL, role-based permissions inherited from the ERP, and where each fits.
AI for ERPAI Agents for ERP, Running On-Prem
A practical guide to on-prem AI agents for ERP: what they can safely automate, where human approval belongs, and how to design the guardrails.
Stuck on OpenText Content Server and Documentum?
Talk to engineers who work inside OpenText Content Server and Documentum every week, and who build private AI that answers these questions from your own ERP data.
Keep exploring
Free tools
- OpenText Content Server and Documentum Private AI Layer Blueprint GeneratorFill in your OpenText / Documentum environment and export an architecture plan for a private, on-prem AI assistant: components, security controls, rollout and open questions.
- OpenText Content Server and Documentum AI Assistant Sizing and Value CalculatorEstimate GPU count, token volume, index size and payback for a private AI assistant on OpenText / Documentum from users, usage and time saved.
Runs with your ERP
- OpenText Vendor Invoice Management with SAP S/4HANA and ECCHow OpenText Vendor Invoice Management runs inside SAP on ECC and S/4HANA: OCR capture, exception workflow and posting, plus setup, pitfalls and options.
- OpenText Trading Grid and SAP S/4HANA: B2B connectivityHow OpenText Trading Grid connects SAP S/4HANA and ECC to trading partners for EDI, API and file exchange. Adapter, data flows, setup, pitfalls, and AI.