Product and intended use
Define the configuration, people, information and tasks being assessed.
Product, plan and how it is bought
Public claim only
The binding name is 'OpenText Core eDiscovery Aviator', which is clause 13 of the Legal Tech eDiscovery Additional Terms; the Australian product page markets the same thing as 'OpenText eDiscovery Aviator'. The page's FAQ defines it as 'a suite of LLM-powered features built into OpenText eDiscovery currently including: Key document summary; Summarization; Concept label summaries; Review; Rapid exploration; Aviator Agents'. The 'how to get started' table offers three commercial shapes, 'on-demand, multi-matter subscription, or private cloud options'. Two vendor statements about how it is enabled are not reconciled on the material read: the FAQ says Aviator 'is available to all OpenText eDiscovery cloud customers (single or multi-tenant) in all AWS regions, provided they have signed the appropriate legal paperwork', while the eDiscovery product page lists 'Gen AI-powered OpenText eDiscovery Aviator Review' and 'AI-generated OpenText eDiscovery Aviator Document Summarization' as line items inside the eDiscovery offering.
Ask: Is Aviator an order-form line under our existing eDiscovery agreement, or a separate signed document, and which of the six components does our entitlement cover?
Where the feature runs and what leaves the environment
Public claim only
The FAQ describes the call path: 'OpenText eDiscovery connects to Amazon Bedrock via the Bedrock API', the job 'creates a session with the LLM via the Amazon Bedrock API, directly from the customer's OpenText eDiscovery AWS environment', the request carries 'usually the prompt + document text, but depends on the feature', the response returns to that environment, and then 'the session with the LLM is closed and all data is deleted from AWS Bedrock'. Clause 13.2 of the Additional Terms says the same in contractual form: Aviator 'sends, via an in-app batch job request, documents and information ... from the Customer's Amazon Web Services, Inc., environment with encryption to Anthropic on Amazon Bedrock for the LLM services and Outputs are returned encrypted'. Purchase options include private cloud. No document read names the AWS region that holds the customer environment or the region in which the model call is served.
Ask: Name the AWS region for our eDiscovery environment and the region in which the Bedrock inference for each Aviator feature is served, and confirm whether those can differ.
What each component does
Public claim only
The Australian product page describes the components: key evidence identification and summarisation for early case assessment; exploration of a data set to surface documents and issues; plain-language summaries of dense documents; and classification, where the user uploads a review memo and 'the model rapidly sort[s] responsive from non-responsive documents with built-in testing, sampling, and token estimates'. Aviator Agents is described in the FAQ as extending 'beyond conversational prompting to intelligent search and intelligent automation within the same matter workflow', where a user describes a goal in natural language and 'an agent can plan and execute the multi-step search, review, analysis and summarization tasks required to complete it', with 'pre-configured agentic templates' and custom agents managed from a centralised dashboard. Every component is a language-model operation; the machine-learning functions of the wider platform, such as technology-assisted review and predictive search, sit outside Aviator.
Ask: For each of the six components, what is sent to the model, what is returned, and which of them can be enabled or disabled independently of the others?
Version, change history and material not opened
Public claim only
The FAQ says the suite 'currently includ[es]' six components, wording that anticipates change, and clause 13.7 of the Additional Terms expressly reserves the right to substitute the underlying model without notice. The page's resources list carries items that were not opened inside the credit budget and from which nothing is recorded here: a document titled 'OpenText eDiscovery Aviator: What's new', a blog titled "OpenText eDiscovery Aviator's Flex: Turn prompts into lasting legal intelligence", and a blog titled 'Putting AI agents to work across eDiscovery use cases'. The Additional Terms read carry the document code '01.26 | 247-000176-002' and a 2026 copyright line.
Ask: Provide the Aviator release notes for the last 12 months, the current component list with version numbers, and confirm whether Flex is generally available to Australian customers.
Australian data residency
Public claim only
The Australian sovereign-cloud page, checked 27 September 2026, is the only material read that names Australia as a hosting location, and it does so for a different deployment product: it says 'OpenText Private Cloud is purpose-built for organizations that need to be global in scale but local in execution. With data centers strategically located across key regions—including Canada, UK, Germany, France, Australia—OpenText provides customers with the flexibility to choose where their data resides', and offers 'Dedicated, single-tenant environments ... Local data processing with resources located within country borders'. That page does not name the eDiscovery service or the Aviator features, and it does not address the Amazon Bedrock inference region. The Aviator FAQ's 'in all AWS regions' is a statement about availability. No binding document read states where an Australian customer's data sits, so no Australian residency commitment for Aviator is recorded.
Ask: Can our eDiscovery environment and all Aviator inference be confined to Australia, and will you state the region in the Order rather than in a support answer?
Check for vendor content directing how AI describes the product
Not confirmed
A deliberate check for content addressed to AI models, assistants or crawlers found none for this vendor, checked 27 September 2026. Two site maps of opentext.com returned 40 and 41 URLs respectively and none was /llms.txt, /ai-info, /ai or /for-ai; the Aviator product page, the eDiscovery product page, the Australian sovereign-cloud page and the four binding documents read contain no block instructing AI models how to describe the product. One map result was a PDF titled 'OpenText DevOps Aviator legal and security FAQ', which is a legal and security document for a different Aviator product rather than content directing AI. This is a negative result on the URLs returned and the documents read; opentext.com is large and both maps were search-filtered, so it is not proof of absence.
Ask: Do you publish anywhere on your sites or in your documentation guidance addressed to AI models, assistants or crawlers about how OpenText products should be described?
Data, controls and requirements
Compare the actual configuration with firm, client and jurisdiction requirements, supported by evidence.
Client authority and responsibility for use
Public claim only
The Additional Terms place the burden on the customer. Clause 13.4(c) states that use of AI components 'does not replace decision-making and judgement by natural individuals', that the customer 'remains solely responsible for any decisions taken and judgements as a result of the Outputs', and that OpenText 'shall have no liability resulting from (i) the creation and/or use of the Outputs, and/or (ii) any decisions resulting from the use of the Outputs'. Clause 13.4(f) makes the customer 'solely responsible for identifying and complying with the requirements applicable to the implementation and use of the relevant services and products (including AI Components) in Customer's processes'. Clause 13.4(a) notes that the customer's choice of parameters and inputs 'may include assumptions, biases and limitations which will affect the effectiveness, quality, relevance and accuracy of the outputs'. Separately, clause 13.2 has the customer authorise OpenText to send documents to the model on its behalf as part of project management activities, which is a standing authority rather than a per-matter one.
Ask: Can Aviator be disabled per matter or per client so a client who has not consented to generative AI is technically excluded, and what written description of the Anthropic and Bedrock path can we give that client?
Model provider, version and the right to change it
Public claim only
The provider is named in a binding document, not only in marketing: clause 13.1 states that 'Aviator leverages generative artificial intelligence (AI) with a Large Language Model (LLM) from Anthropic on Amazon Bedrock to generate content and respond to prompts'. Clause 13.7 then reserves the right to change it: OpenText 'reserves the right, at its sole discretion and without notice, to modify, update, replace, or discontinue any LLM, including by switching to different model architectures, vendors, or configurations, provided that such changes do not materially degrade the overall functionality of the Services', and 'Unless otherwise expressly agreed in writing, no specific model version, vendor, or output is guaranteed'. No model name or version is published anywhere read. The FAQ adds OpenText's account of the hosting arrangement, that 'Amazon Bedrock performs a deep copy of the LLM and hosts it' and that the provider 'has no read/write access and no internet access to the model within Amazon Bedrock'; that is a statement on a product page about a third party's platform, not a warranty.
Ask: Will you name the Anthropic model and version used for our environment in the Order, and agree not to change the model, version or vendor without prior written notice and an opportunity to re-test?
Sub-processors, notice and objection
Public claim only
Clause 13.5 of the Additional Terms states that access to and use of the AI components 'involves the processing of personal data by third parties such as Amazon Bedrock as sub-processor'. The Data Processing Addendum takes a general authorisation: section 2.3.1 says sub-processors 'may include: (i) OT's global Affiliate companies as exist from time to time (and their vendors); and/or (ii) any of the sub-contractors that OT engages', and treats those two categories as the 'agreed list' for the Standard Contractual Clauses. Section 2.3.2 requires OpenText to inform the customer at least 14 days before appointing a new or replacement sub-processor, with written objection within 14 days, but that notice is expressly not required where the new sub-processor is an OpenText global affiliate. Section 2.3.3 limits objection to a sub-processor that 'demonstrably fails to offer the same or a reasonably comparable level of protection'. No named, dated sub-processor list was found in the documents read or in either site map.
Ask: Provide the dated list of sub-processors touching Aviator data, including Amazon, any affiliate and their vendors, and agree that affiliate changes are notified to us as well.
Training on customer content
Public claim only
The no-training statement is the vendor's own and is specific to this product, but it sits on a product page rather than in a contract. The FAQ says 'OpenText does not train models. Models accessed by OpenText eDiscovery Aviator are pre-trained by the LLM provider. Customer data, input prompts, and outputs are never used to train the LLM model. LLM results are not shared across projects.' None of the four binding documents read contains a no-training covenant. Pulling the other way is Additional Terms clause 13.4(g), which entitles OpenText 'to use, develop or share its experience and knowledge (including processes, ideas, statistical and other information) acquired by it in connection with the Products' on condition that the customer is not identified as a source and the data is anonymised.
Ask: Will you warrant in the Order that our documents, prompts and Aviator outputs are never used to train, fine-tune or evaluate any model, by OpenText, Amazon or Anthropic, and define what falls inside clause 13.4(g)?
Use of experience, statistics and feedback
Public claim only
Additional Terms clause 13.4(g) entitles OpenText to use, develop or share the experience and knowledge, including processes, ideas, statistical and other information, acquired in connection with the products, provided the customer is not identified as a source and any data arising is anonymised. The clause does not define which data classes feed those Services Statistics, no opt-out appears in any document read, and nothing states whether prompt text, thumbs-up or thumbs-down signals, or prompt libraries built by the customer fall inside or outside it. The product page's reference to 'expert prompt engineering' as a driver of the published recall figure is not tied to any statement about whose prompts are reused.
Ask: Which data classes feed Services Statistics under clause 13.4(g), are our prompts and prompt libraries inside or outside it, and can we opt out?
Retention of inputs, outputs and job records
Public claim only
Two different retention positions apply to different places the data sits. On the model side the FAQ says 'Once the session with the LLM is closed, no data from the session remains on the Amazon Bedrock/LLM side. Amazon Bedrock does not store or log customer data in its service logs', and that interaction is project-level with 'a separate session ... created for each LLM feature interaction'. Inside the platform, retention follows the eDiscovery storage states rather than a schedule: data ingested but not published stays in Storage 'until a specific request to delete this content is received', and culled data moves to Nearline Storage unless the customer gives written notice or selects Archived Storage. The Technical and Organizational Measures say centralised security logs are retained for 'a commercially reasonable period'. No document read states a retention period for Aviator prompts, outputs or job history held inside the platform.
Ask: State the retention period for Aviator prompts, outputs and job records inside the platform, and confirm in writing that nothing is retained at Amazon or Anthropic after a session closes.
Deletion and return of data
Public claim only
The Technical and Organizational Measures are the most specific document read: OpenText 'removes all copies and instances of customer data from OpenText's disk storage, backups and archives per NIST 800-88 or Department of Defense 5220.22-M standard protocols', and 'Upon request, OpenText will certify in writing that all customer data has been removed in line with these protocols subject to technical and contractual constraints (e.g., third-party cloud provider timelines) as applicable'. The eDiscovery SaaS Terms section 6.5 requires the customer to state its return-or-destroy preference before the end of the term and provide that OpenText 'will provide a one-time data return service to Customer as described in a separate statement of work, if Customer requests the data return service prior to termination of the Agreement; and Customer pays OT the applicable fee'. In-term deletion of unpublished ingested data happens only on specific request. No maximum number of days to delete is committed, and Aviator prompts, outputs and job records are not named in either document.
Ask: State the maximum days to delete our data, backups and Aviator job records after a destroy instruction, confirm the written deletion certificate covers Aviator records, and quote the data return fee now.
Vendor personnel access to content
Public claim only
The Technical and Organizational Measures state that access rights are granted on least privilege, on a need-to-know basis and with legitimate business need, that all access requests are validated by information security personnel and approved by management, that 'for access to production environments by OpenText personnel, secure logical access gates are in place and require multi-factor authentication' with activity recorded through logging on those gates, and that access privileges are validated regularly and revoked on role change or departure. Against that, Additional Terms clause 13.2 has the customer authorise OpenText to enter the feature activation token and to send documents and information to the model on the customer's behalf 'as part of project management activities', and where managed review is combined with Aviator the review team works under the customer's and its counsel's supervision. Nothing read makes vendor access to a specific matter subject to the customer's per-ticket approval, supplies the customer with access logs, or names the countries from which OpenText personnel work.
Ask: Can we require per-matter, time-boxed and customer-approved support access to Aviator projects, receive the access log for our environment, and know from which countries your personnel and any managed-review staff read our documents?
User identification and access controls
Public claim only
eDiscovery SaaS Terms section 1.1 requires each Authorized User to be a single individual employee or contractor of the customer, identified to OpenText and 'assigned a unique login name/password before being provided' access, and section 2.3 makes the customer responsible for the acts and omissions of its Authorized Users. The Technical and Organizational Measures describe least-privilege access, multi-factor authentication for production environments, periodic access reviews, disabling of unused accounts, segregation of duties, and that 'data storage is logically segregated customer-by-customer with partitioning' engineered so data is not commingled. For Aviator specifically the FAQ says interaction is at project level and 'LLM results are not shared across projects'. Customer-side single sign-on, enforced multi-factor authentication for end users, and automated provisioning standards such as SCIM are not addressed in any document read, and nothing states whether a user's matter permissions constrain what an Aviator agent can reach.
Ask: Does the platform support single sign-on and enforced multi-factor authentication for our users and automated deprovisioning, and are matter-level permissions enforced on Aviator prompts and agent runs?
Encryption in transit and at rest
Public claim only
Additional Terms clause 13.2 states that Aviator inputs are sent 'with encryption to Anthropic on Amazon Bedrock' and that outputs 'are returned encrypted'. The Technical and Organizational Measures list 'Encryption of data in transit and data at rest (as set out in the Agreement)', say that 'to protect data in transit and provide secure communication in transit, inherent encryption is applied based on transmission protocol' and that end-user browser sessions to portal applications are encrypted with HTTPS by policy, that 'select facilities support data at rest encryption using Advanced Encryption System (AES) or greater', and that OpenText maintains a Key Management Policy covering key generation, rotation, storage, access controls, separation of duties and secure destruction. No TLS version is named, at-rest encryption is qualified by 'select facilities', and customer-managed keys are not offered in any document read; the Australian sovereign-cloud page claims 'End-to-end data encryption and management with customer-controlled keys' for OpenText Private Cloud, which is a statement about that deployment product rather than about the eDiscovery cloud service or Aviator.
Ask: Name the encryption algorithms, key lengths and TLS versions applied to our environment and to the Bedrock path, confirm whether our facility is one of the 'select facilities' with at-rest encryption, and say whether customer-managed keys are available to us.
Independent assurance and audit rights
Public claim only
The Technical and Organizational Measures state that 'OpenText maintains an Information Security Management System designed to comply with recognized industry standards such as ISO/IEC 27001 and undergoes periodic audits, including SOC 2 Type II assessments for applicable services', and that on written request and subject to confidentiality it 'may provide summaries of relevant certifications or audit reports where available or a standard security questionnaire'. That is wording about design and assessment: no certificate is published, and no scope statement says whether the eDiscovery service or the Aviator features are inside a current report. The Australian sovereign-cloud page separately claims 'Comprehensive compliance support for standards such as ISO 27001, HIPAA, Protected B, IRAP, and more' for OpenText Private Cloud, which claims support for those standards rather than an assessment of this service. Data Processing Addendum section 2.11.2 requires a copy of the latest Service Organization Control report on written request 'where available', section 2.11.4 allows on-site inspection only where those documents have failed to verify compliance or a supervisory authority requires it, and section 2.11.6 requires 30 days' notice and limits an audit to two consecutive business days once per contract year.
Ask: Provide the current SOC 2 Type II report and any ISO/IEC 27001 certificate with a scope statement naming the eDiscovery service, the Aviator features and our hosting region, and state whether any IRAP assessment covers this service.
Contracting entity, governing law and liability
Public claim only
The stack is an Order plus the eDiscovery SaaS Terms and Conditions plus the Legal Tech eDiscovery Additional Terms, with the Data Processing Addendum and its Technical and Organizational Measures attaching where personal data is processed. The SaaS Terms are headed 'Open Text Corporation eDiscovery SaaS Terms and Conditions', apply the law of the Province of Ontario and give the Ontario courts exclusive jurisdiction, and cap liability, with an aggregate per-Order limb not to 'exceed fifty percent (50%) of total amount of service fees invoiced' in the relevant period alongside an exclusion of indirect and consequential damages and loss of data. The Additional Terms carry the line 'Trademarks owned by Open Text Inc.', and the Data Processing Addendum identifies the processor only as the Open Text entity that entered the principal agreement. Aviator adds a pass-through: clause 13.6 requires the customer to comply with the third-party models end user licence posted at aws.amazon.com/legal/bedrock/third-party-models/, to indemnify OpenText for any breach of it by the customer or its users, and records that OpenText 'shall have no liability or responsibility for any claims ... resulting from Customer's use of such AI functionality'. No Australian contracting entity, ACN or ABN appears in any document read.
Ask: Which Open Text entity, with its ACN or ABN, will sign our Order, will you accept Australian law and forum, and will you accept liability for the Bedrock third-party models licence rather than passing it to us with an indemnity?
Cross-border transfers
Not confirmed
The Data Processing Addendum read is built for European transfer law: it defines Restricted Transfers by reference to the GDPR, United Kingdom data protection law and the Swiss regime, and incorporates OpenText's EEA controller-to-processor and processor-to-processor Standard Contractual Clauses and the United Kingdom transfer mechanism by reference to separate published documents. Nothing in it addresses Australian privacy law or Australian Privacy Principle 8. No document read names the country in which customer data is stored or in which Aviator inference occurs: clause 13.2 places the send from 'the Customer's Amazon Web Services, Inc., environment' and the FAQ says availability is 'in all AWS regions', neither of which fixes a location. The Australian sovereign-cloud page names Australia among OpenText Private Cloud data centre regions but does not extend that to the eDiscovery service or to the Bedrock call.
Ask: For an Australian customer, list every country in which our data may be processed or from which it may be accessed, including for Aviator inference and for support, and state what you rely on for Australian Privacy Principle 8 purposes.
Incident notification
Public claim only
The Technical and Organizational Measures define a Security Incident as 'a confirmed security breach leading to an unauthorized access, use, destruction, loss or alteration of customer data', say the process follows the NIST Computer Security Incident Handling Guide or equivalent industry practices, and state that OpenText 'will notify the customer without undue delay of any Security Incident that impacts the customer data' and will provide reasonably requested information. Data Processing Addendum section 2.6.1 requires notification of a Personal Data Breach without undue delay after OpenText becomes aware, with the information the customer needs to describe the nature and likely consequences, and the customer remains responsible for notifying regulators and data subjects. No hour figure is committed in any document read, the trigger is a confirmed breach with impact confirmed, and nothing addresses notification where the incident occurs at Amazon or affects the model layer rather than OpenText's own systems.
Ask: Will you commit to notice within 72 hours of becoming aware of a suspected incident affecting our data, including one at Amazon or in the Bedrock layer, with enough detail for a Notifiable Data Breaches assessment?
Change notice for the model, sub-processors and controls
Public claim only
The change rights over the AI layer are unilateral and explicit. Clause 13.7 lets OpenText 'modify, update, replace, or discontinue any LLM, including by switching to different model architectures, vendors, or configurations' at its sole discretion and without notice, subject only to not materially degrading overall functionality, and records that the customer acknowledges 'model selection, performance characteristics, and outputs may vary over time' and that no specific model version, vendor or output is guaranteed unless expressly agreed in writing. The FAQ's description of the suite as 'currently including' six components carries the same expectation. For sub-processors the Data Processing Addendum requires 14 days' notice with an express carve-out where the new sub-processor is an OpenText global affiliate, and its definitions state that the Standard Contractual Clauses and the Technical and Organizational Measures are incorporated as may be amended, updated or replaced from time to time.
Ask: Will you agree in writing to give us prior notice of any change of model, model version or vendor for Aviator, with a testing window, and to extend sub-processor notice to affiliate changes?
Termination and getting data out
Public claim only
The two documents must be read together. eDiscovery SaaS Terms section 6.2 lets the customer terminate the Services Order without refund, subject to paying fees incurred, on five business days' written notice before the end of a month; the Additional Terms then provide, for several eDiscovery service lines, that notwithstanding that section 'there is no termination for convenience during the Initial Term', with 60 days' notice of non-renewal and automatic renewal otherwise. On exit, section 6.5 offers a one-time data return service only if the customer requests it before termination, is not in material breach, is current on payments and pays the applicable fee, scoped by a separate statement of work. No export format, no time limit and no escrow are published, and nothing addresses export of Aviator outputs, prompt libraries or agent configurations as distinct from the document set.
Ask: Confirm whether termination for convenience applies to our Order, and state whether Aviator outputs, prompt libraries and agent configurations are included in the one-time data return and in what format.
Outbound data flows and what can reach the model
Public claim only
Aviator's own outbound path is a single one: clause 13.2 sends inputs from the customer's AWS environment to Anthropic on Amazon Bedrock via an in-app batch job request. The wider platform has separate priced paths for other features, documents to Amazon Translate, audio tracks to Amazon Transcribe and video natives to AWS Elemental MediaConvert, each with its own activation token clause, so a firm enabling Aviator is not thereby enabling those. The FAQ describes Aviator Agents operating on 'intelligent search and intelligent automation within the same matter workflow'. No document read describes a tenant-level control that blocks the Bedrock path while leaving the rest of the platform running, and no public Aviator API or third-party integration point is published.
Ask: How do we block the Bedrock path at tenant level while keeping the rest of the platform, and can Aviator and agents be restricted to named projects?
Open-web access from the model
Public claim only
The FAQ answers this directly. Asked whether the model references the internet or has an internet plug-in, it says: 'No. Amazon Bedrock performs a deep copy of the LLM and hosts it. The LLM provider (Anthropic) has no read/write access and no internet access to the model within Amazon Bedrock.' The components as described all operate on the project's own document set, and the FAQ's data-flow answer says the request carries the prompt and document text from the customer's environment. These statements appear on a product page and describe a third party's platform; nothing equivalent appears in the SaaS Terms, the Additional Terms or the Data Processing Addendum, and nothing addresses whether an Aviator agent can retrieve from sources outside the matter.
Ask: Will you warrant that no Aviator feature or agent can retrieve from the open web on our matters, and evidence how that is enforced in the Bedrock configuration used for our environment?
What runs without a person initiating each step
Not confirmed
Aviator Agents is the part that acts without step-by-step instruction: the FAQ says a user 'can describe a goal in natural language, and an agent can plan and execute the multi-step search, review, analysis and summarization tasks required to complete it', with pre-configured templates and custom agents managed from a centralised dashboard. Clause 13.2 separately authorises OpenText to enter the activation token and to send documents on the customer's behalf as part of project management activities. The Review component has 'built-in testing, sampling, and token estimates' before a full run, which is a check on cost and criteria rather than an approval gate on actions. No document read describes a per-action confirmation requirement, a boundary on what an agent may change, produce or export, or a switch that disables agents while leaving the other Aviator components in place.
Ask: Which agent actions can run without a person confirming each one, what can an agent change, export or produce, and how do we disable Aviator Agents while keeping summarisation and review?
Human review before an output is used
Public claim only
Human review is addressed in the contract and in the interface, but is not enforced by the product on the material read. Clause 13.3 fixes the wording that must appear: when Aviator is enabled users see an Aviator icon or Aviator Chatbot icon whose mouseover text reads 'Aviator leverages generative artificial intelligence (AI) with a Large Language Model (LLM), to generate content and respond to your input. OpenText does not guarantee the accuracy of AI-generated responses and/or rights to use them. It is OpenText's customer's responsibility to apply judgement and consider multiple sources before making any decisions.' Clause 13.4(c) states that use of AI components does not replace decision-making and judgement by natural individuals, and clause 13.4(d) that for large-language-model components OpenText 'does not guarantee (i) the protection of privacy, (ii) rights to use, and/or (iii) the accuracy of the Outputs'. The Review component's testing and sampling step is the only published quality gate, and no control forces a named reviewer to approve an output before it is relied on, produced or exported.
Ask: Can the platform require named reviewer sign-off before an Aviator classification or summary is relied on, produced or exported, and can that sign-off be evidenced in an audit export?
