Product Terms

These Product Terms form part of, and are incorporated by reference into, the Viktor General Terms of Service. Capitalized terms used but not defined herein have the meanings given in the Definitions.

1. General

1.1 These Product Terms apply to Customer’s access to and use of the Viktor Service and set out the product-specific terms applicable to the Service. These Product Terms are incorporated into, and form an integral part of, the General Terms and the Agreement between Provider and Customer.

1.2 Capitalized terms used but not defined in these Product Terms have the meanings given to them in the General Terms.

1.3 In the event of a conflict or inconsistency between any of the Agreement documents, the order of precedence set out in the General Terms applies.

2. Service Description and Delivery

2.1 Service Overview

Viktor is a service that integrates with Customer’s communication and productivity tools (which are Connected Platforms) and executes tasks, generates content, and supports workflows through AI-driven decision-making. The Service is provided on a software-as-a-service basis. Provider hosts and operates the underlying infrastructure and grants Customer remote access via the Internet.

2.2 Access to the Service

Provider delivers the Service by enabling Customer’s account upon Customer’s acceptance of the General Terms and (where applicable) execution of the Order Form. Access requires Customer to install the Viktor Application in its workspace and to connect Customer’s identity and integration credentials. The Service is deemed delivered, and Customer’s payment obligations commence, upon enablement of the account or as otherwise specified in the Order Form. Customer's acceptance of the General Terms together with confirmation of the relevant subscription plan, functionalities, applicable fees, and rules of cooperation through the online flow on viktor.com constitutes an Order Form for all purposes of this Agreement, including with respect to the commencement of the Subscription Term and Customer's payment obligations.

2.3 Account Setup

After acceptance of the General Terms or execution of an Order Form, Customer is responsible for setting up its account, installing the Viktor Application in its workspace, connecting Customer's identity and integration credentials, designating Authorized Users, and configuring permission scopes, in each case using the self-service tools made available within the Service and the procedures described in the Documentation. Provider is not responsible for delays or failures resulting from Customer's setup activities, from Customer's systems, network, infrastructure, or third-party software, or from any misconfiguration not attributable to Provider.

2.4 Out-of-Scope Services

Unless expressly stated in the Order Form, the Service does not include data migration, custom development, user training, dedicated success management, onboarding services beyond the self-service tools described in the Documentation, configuration assistance, integration with systems not listed in the Documentation or any other managed services. Additional services may be procured separately at Provider’s then-current rates.

3. AI Functionality and Autonomous Actions

3.1 Nature of AI Outputs

The Service uses artificial intelligence models to generate Outputs. AI Outputs are probabilistic and may be inaccurate, incomplete, biased, or otherwise unsuitable for Customer’s intended use. Customer acknowledges that AI Outputs are not a substitute for human judgment or professional advice (including legal, medical, financial, or other regulated advice). Customer is solely responsible for reviewing Outputs before using, relying on, or distributing them.

3.2 Autonomous Actions

The Service may execute actions on Connected Platforms with varying levels of autonomy. Customer acknowledges and accepts that:

(a) Customer is solely responsible for configuring permission scopes, approval policies, and pre-authorization rules in Customer’s account settings, and for reviewing those configurations periodically;

(b) Provider executes Pre-Authorized Actions in reliance on Customer’s configuration. Customer accepts all consequences of actions executed within the configured permissions, except where caused by Provider’s gross negligence or wilful misconduct;

(c) a limited set of built-in action categories designated in the Documentation (“High-Risk Actions”) — currently including adding the Service to or removing it from workspace channels, transmitting reports to Provider, and changing the Service’s own tool-permission configuration — always require explicit per-action approval by an Authorized User before execution and cannot be designated as Pre-Authorized Actions. For actions on Connected Platforms, approval requirements are determined by the action-type controls described in Section 3.4, including the default approval levels assigned by the Service. Provider may update the categories of High-Risk Actions from time to time;

(d) Provider does not guarantee that any specific action will be executed correctly, on time, or with the intended business outcome.

3.3 Customer Remains Operator

Customer acknowledges that AI-driven autonomous operations involve inherent uncertainty. Customer remains the operator of its business processes and bears final responsibility for all business decisions and actions executed through the Service.

3.4 Action-Type Controls

The Service may provide configuration controls that allow Customer to enable, disable, restrict, or require approval for specific categories of actions performed through Connected Platforms on an action-type basis. For example, Customer may restrict Viktor from updating Notion pages, modifying advertising budgets in Meta Ads, creating or updating records in connected systems, or performing other supported actions. Customer is responsible for configuring and maintaining these action-type controls in accordance with its internal authorization policies, business requirements, and risk tolerance. The Service assigns default approval levels to action types when an integration is connected (for example, actions assessed as read-only may default to automatic execution, while actions that modify data may default to requiring approval). Customer is responsible for reviewing these defaults and adjusting them to match its risk tolerance. Where an action type is enabled, pre-authorized, or not subject to an approval requirement under Customer’s configuration, Viktor may execute such action without separate human review. Changes to action-type controls apply prospectively and do not affect actions already executed or actions already in progress.

3.5 AI Subprocessors

The Service is powered in part by third-party AI model providers (“AI Subprocessors”), the current list of which is maintained in the Privacy Policy (Section 4) and in Provider’s Trust Center, as updated in accordance with the DPA. Provider has contractual arrangements with each AI Subprocessor that, as of the date of these Product Terms, prohibit the use of Customer Data to train general-purpose AI models or for advertising purposes. Provider’s commitments regarding AI Subprocessor behavior reflect the contractual arrangements in effect between Provider and the respective AI Subprocessor. AI Subprocessors may modify their terms unilaterally. Provider will provide reasonable advance notice to Customer (via the subprocessor change notification process described in the DPA) if Provider becomes aware that an AI Subprocessor’s modified terms would materially reduce the level of protection applicable to Customer Data. In such case, Customer may, as Customer’s sole remedy, terminate the affected portion of the Service without penalty and receive a pro-rata refund of any prepaid fees for the unused portion of the applicable Subscription Term, excluding Credits already consumed and non-refundable Credit purchases, unless otherwise required by applicable law.

3.6 AI Outputs and Third-Party Content

Customer acknowledges that AI-generated Outputs may, in rare cases, contain content that resembles, reproduces, or derives from third-party content, including potentially copyrighted material, even where Provider and its AI Subprocessors have taken commercially reasonable measures to prevent this. Customer is solely responsible for reviewing Outputs for potential intellectual property, defamation, privacy, or other third-party rights issues before using or distributing them. Provider’s intellectual property indemnification obligations in Section 7 of the General Terms do not extend to claims arising from AI Outputs that incidentally reproduce third-party material.

4. Connected Platforms and Slack Integration

4.1 Customer Warranties for Connected Platforms

When Customer connects the Connected Platform, Customer represents and warrants that:

(a) Customer is duly authorized to grant Provider the access permissions necessary to deliver the Service, including any consents required from the third-party account owner;

(b) Customer has obtained all consents required from individuals whose data will be accessed or processed through the integration; and

(c) the connection and Customer’s use of the integrated data comply with the Connected Platform’s own terms of service and applicable policies.

4.2 Workspace-Shared Model

Connected Platform integrations operate on a workspace-shared basis: once Customer connects an integration, Authorized Users with appropriate access within the Service may invoke that integration, and actions executed through the integration use the permissions of the account that authorized the connection.

Customer is solely responsible for:

(a) selecting which account is used to authorize each Connected Platform integration, taking into account the permissions that account holds in the Connected Platform;

(b) configuring workspace membership, role assignments, and approval policies within the Service to reflect Customer's intended access controls, using the configuration tools made available within the Service; and

(c) periodically reviewing such configurations.

High-Risk Actions executed through Connected Platform integrations remain subject to the per-action approval requirements in Section 3.2.

4.3 Slack OAuth Consent

The Service integrates with Customer’s Slack workspace via Slack’s OAuth 2.0 authentication and Slack APIs. During installation, Slack presents a consent screen detailing the permissions Provider requests. By granting consent, Customer authorizes Provider to use those permissions to deliver the Service.

4.4 Slack Scope of Access

Provider accesses messages, channels, files, and conversation context in conversations that the Viktor Application has been invited to or has joined (including message history for a limited look-back window upon joining a channel), direct messages with the bot, and other data covered by the OAuth scopes granted by Customer or its Authorized Users. Where an Authorized User grants per-user search permissions, Provider may access Slack content available to that user under the granted scopes. The currently requested scopes are presented on Slack’s consent screen at installation and are described in the Documentation.

4.5 Uninstallation

Customer may uninstall the Viktor Application at any time via the relevant Connected Platform’s app management settings. Uninstallation immediately stops Provider’s collection of new data from the Connected Platform. Upon uninstallation of the Slack application, Provider additionally deletes the associated connection credentials (OAuth tokens) and pauses scheduled tasks routed to that workspace. Uninstallation does not by itself delete other previously collected Customer Data (including conversation threads with the Service and workspace files); deletion of such data is governed by Section 11.8 of the General Terms and the DPA.

4.6 Third-Party Platform Terms

Customer’s use of Connected Platforms is governed by Customer’s own agreement with the respective platform provider. Provider is not responsible for Connected Platform availability, changes to APIs, modifications to Connected Platforms’ terms of service, or actions taken by Connected Platform providers that limit or impair the Service.

5. Security

5.1 Security Program

Provider maintains an information security program supported by an independent SOC 2 examination of Zeta AI, Inc.'s security control environment.

5.2 Technical and Organizational Measures

Provider’s security measures include encryption of Customer Data in transit (TLS 1.2 or higher) and at rest (AES-256 or equivalent), role-based access controls applying least-privilege principles, production-system logging and monitoring, regular vulnerability assessments, and personnel security training. Additional measures may be described in the DPA.

5.3 Breach Notification

Provider shall notify Customer of a confirmed security incident affecting Customer Data without undue delay, in accordance with the notification timelines and procedures set out in the DPA. The notification will include the information reasonably necessary to support Customer’s legal obligations.

6. Accessibility

Provider strives to make the Service accessible to users with disabilities and pursues conformance with the Web Content Accessibility Guidelines (WCAG) 2.1, Level AA, using commercially reasonable efforts. Conformance is not warranted and may vary across features and platforms.

7. Service Level Agreement

7.1 This Section 7 constitutes the Viktor Service Level Agreement (the “SLA”) and forms part of the Agreement between Viktor and Customer. Capitalized terms used but not defined in this SLA have the meanings given to them in the General Terms.

7.2 Unless expressly specified in the applicable Order Form, Viktor does not provide a guaranteed availability percentage, uptime commitment, or minimum service availability level. Viktor will use commercially reasonable efforts to make the production version of the Service available to Customer during the applicable Subscription Term, subject to the exclusions set out in this SLA and the Agreement.

7.3 Any availability target specified in the applicable Order Form shall be measured on a calendar-month basis and shall apply only to the production version of the Core Service. Unless expressly stated otherwise, availability calculations exclude unavailability, degradation, delay, or failure caused by scheduled maintenance, emergency maintenance, Customer’s systems, networks, devices, Slack workspace configuration, Connected Platforms, AI Subprocessors, cloud infrastructure providers, payment processors, telecommunications providers, force majeure events, suspension of the Service in accordance with the Agreement, Beta Features, trial, demo, test, or non-production environments, and any circumstances outside Viktor’s reasonable control.

7.4 Viktor may perform scheduled maintenance from time to time. Viktor will use commercially reasonable efforts to provide advance notice of scheduled maintenance that is expected to materially affect availability of the production Service. Unless otherwise specified in the applicable Order Form, scheduled maintenance will not count as unavailability, downtime, or failure to meet service-level commitments.

7.5 Viktor may perform emergency maintenance without prior notice where necessary to address security, legal, operational, infrastructure, or data integrity risks. Viktor will use commercially reasonable efforts to minimize disruption caused by emergency maintenance.