On-Prem AIFree templatePDF, Excel, Word exportOpenText Content Server / Documentum

OpenText Content Server and Documentum Private AI Layer Blueprint Generator

This generator turns a handful of facts about your OpenText Content Server and Documentum environment into a structured architecture plan for a private AI assistant. It covers the components, the security controls tied to your hosting choice, a three-phase rollout and the questions IT has to answer before build.

Fill in

Live preview
Download:

OpenText Content Server and Documentum Private AI Layer Blueprint Generator

Context

Company: Acme Precision Ltd System: OpenText Content Server and Documentum, version OpenText Content Server 21.x to 23.x, database Oracle Database Hosting: On-prem server Scale: 1500 named users across 3 sites Target: Pilot in 8 weeks, production in 6 months

Goal: add a private AI assistant over the existing system without moving data to a public cloud service and without replacing the system.

Use cases in scope

Find the approved revision of an SOP, compare two revisions, answer questions from controlled documents with lifecycle state shown, summarize supplier and contract records.

Data that must never leave the site

Records under legal hold, export-controlled technical data, objects with restricted classifications and encrypted content.

Control: this data is excluded from the index or processed only on On-prem server infrastructure, with access logged.

Components

ComponentDesign
Data access pathDocumentum DQL, DFC, DFS or REST; Content Server REST API and search; text from the PDF rendition where available
Retrieval indexChunks of the approved version with version label, lifecycle state, effective date and ACL principals
Model servingOpen-weight model on vLLM or Ollama on 1 x 24 GB GPU
Tool serverMCP or HTTP server with search_controlled_docs and get_revision tools, read-only
Identity and permissionsRepository ACLs or node permissions mirrored per chunk; group membership resolved from the directory per question
AuditAppend-only log in your SIEM plus the repository's own audit trail for any write-back

Security controls

Retention, hold and classification rules honored in the ingestion filter; read-only service identity; ACL filtering before retrieval; no external calls at question time; updates to model weights through hash-verified transfer.

Hosting mode On-prem server: when air-gapped, models, containers and packages enter through a hash-verified transfer and no component calls an external network.

Rollout

PhaseScopeExit criteria
1. Read-only questionsCited answers over a pilot scope for a small user group on 1 x 24 GB GPUAnswers verified by process owners; no permission leaks in tests
2. DraftsSummaries, comparisons and drafted records a person reviews and entersReviewers accept drafts without major edits in agreed share of cases
3. Approved actionsNarrow actions through the supported API with a named human approverEvery action logged; rollback path tested; sign-off from system owner

Open questions for IT

1. Which cabinets, folders or workspaces are in scope, and which lifecycle states count as current? 2. How are renditions stored, and are PDFs generated for every approved version? 3. Which classifications or holds must be excluded from processing? 4. How is group membership managed and synchronized from the directory? 5. Is the vendor's own AI already licensed and acceptable to security?

Approvals

IT architect / Date
Security officer / Date
System owner / Date

This is a planning document, not a security certification. Component choices (vector store, model size) depend on your pilot measurements; confirm API names and limits against the documentation for your exact version.

Review my blueprint

Send the exported plan for an optional review of the data access path, permissions design and rollout.

Optional. The tool and every export work without this. No spam.

How to use it

Enter your system version, database engine and hosting model, then describe the use cases and the data that must never leave the site. The blueprint fills the context, components, controls and rollout sections, and exports to PDF, Word or Excel. Walk through it with your IT architect and security officer, correct the defaults, and attach it to the project request. Change the GPU field to see how the rollout row for phase one reads on different hardware.

  • Be specific about restricted data: it becomes a design constraint, not a footnote
  • Pick hosting first; it sets the security controls
  • Keep use cases to three or four for the pilot
  • List the people who can approve write-back

What the blueprint assumes

The design is the same on every on-prem system: a read-only copy or supported API for data access, a retrieval index that carries permissions, a tool server that exposes only approved read actions, an open-weight model on vLLM or Ollama, and an audit log. Repositories have versions and lifecycles, so the unit of retrieval is the approved revision. The components table names the access path for this system, but you must verify the object and API names for your exact version.

  • Read-only by default
  • Permissions mirrored from the system
  • Write-back only through supported APIs with human approval
  • Everything logged

Reading the rollout table

Phase one proves the data and permissions work: cited answers over a small scope. Phase two adds drafts that a person reviews. Phase three allows narrow, approved actions through the system's own API. Do not skip phases: most failures come from skipping permission testing in phase one. Exit criteria are examples; replace them with numbers your process owners agree to, such as the share of answers verified correct in a sample of fifty questions.

Common mistakes

Teams often size the model before they have defined the use case, grant the assistant a powerful service account, or index everything to avoid deciding scope. Another is leaving the open questions unanswered until build starts. Long controlled documents mean large contexts. Use the open-questions section as the agenda for your first IT workshop and assign an owner to each item.

  • Powerful service account for convenience
  • No permission tests with restricted users
  • Indexing without scope decisions
  • No owner for open questions

Frequently Asked Questions

Does this document commit us to buying anything?

No. The generator runs in your browser and exports a plan you can share internally. It is a starting point for architecture and security review, and every default can be changed.

Is the plan valid for air-gapped sites?

Yes. Choose the air-gapped hosting option and the controls section adds transfer and network isolation rules. All components in the table run inside the closed network with no external calls.

Why does the plan avoid giving model sizes?

Model size and GPU count depend on concurrency, context length and answer quality targets. Measure them in the pilot, then use the sizing calculator for ranges rather than committing to a number early.

Can we reuse the plan for another system?

The structure transfers, but the data access path, permission model and open questions are specific to each system. Generate a separate blueprint for each platform and compare them.

Netray designs and runs private AI layers on OpenText Content Server and Documentum with your IT team. If you want a second opinion on your blueprint, we can review it with you.