AI Services

Control generative AI models in your environment

Use the AI Services screen in the Admin Console to control which generative AI models are used in your Appian applications. As AI providers release models with improved capabilities, the AI Services screen allows you to adopt them in a secure and controlled way to benefit from the latest improvements in performance and accuracy.

Use the Appian tab to manage the generative AI models provided by Appian. When you select Appian as the cloud provider, the Appian tab includes Claude models, Amazon Nova 2 Lite, and GPT models (GPT 5.4 and GPT 5.5).

You can also configure a custom provider to route AI traffic through an internal AI gateway or proxy service. A custom provider lets you define a custom endpoint (Base URL) that points to your own infrastructure while still using a supported communication protocol, such as AWS Bedrock Converse, Google Cloud, Azure OpenAI, or OpenAI Chat Completion.

How AI model enablement works

You enable models when you select a processing region in AI Services, making the model available to power various AI capabilities in your environment. For certain models, you must also select a processing region. For Appian sites in a US region, the US processing region is selected by default.

A processing region is a setting that controls which geographic regions can process your AI data. Unlike single-region settings, a processing region can allow processing across multiple pre-defined regions. A processing region provides greater flexibility for data governance while ensuring access to the most powerful models.

Model card status tags

Model cards display status tags to help you quickly identify the state of each model:

• ENABLED: The model card displays this tag when a processing region is selected for the model, indicating it is active.
• DISABLED: The model card displays this tag when no processing region is selected. The model card is grayed out to show it is inactive.

Scroll or drag to pan · ⌘+/⌘− to zoom · Esc to close

What to know before enabling AI models

Enabling a model on the Appian tab changes which models are available for your AI capabilities. Before you enable a model, keep these considerations in mind:

• System administrators can enable models and select processing regions in the Admin Console. For sites in a US region, a US processing region is enabled by default.
• For FedRAMP sites, Appian AI models are automatically configured based on your service agreements and cannot be selected in the Admin Console.
• If you select a processing region that doesn't match your site's region, Appian automatically uses one of the regions defined in that setting to connect to the generative AI service. The region mismatch does not cause an error.
• Disabling a model by selecting None for its processing region impacts any features that rely on that model. This is different from disabling an entire model provider, which prevents all routing to that provider's models at once.

Impact on AI capabilities when changing models

The following AI capabilities in AI Services automatically use the latest available models in the environment:

• CMS Data Type Recommendation
• Composer
• Data Fabric Chat
• Process Insights
• Sample Data Generation
• Test Case Generation

Impact on AI agents when changing models

AI agents use the model and provider configured by the developer on the AI agent object. If the developer selects Auto, the AI agent uses the latest model from the configured provider with automatic fallback. Model changes in the Admin Console affect all AI agents that use the changed provider or model—including agents configured with a specific model. If an administrator disables a model that an agent uses, that agent will fail at runtime until the developer selects a different model or the administrator re-enables it.

For full details on AI agent model selection and runtime behavior, see AI Agent Reference.

Impact on generative AI skills

Generative AI skills behave differently than other AI capabilities when you change models.

• New skills: New AI skills default to Auto model selection, which uses the Appian recommended model for each execution. You can also select a specific model instead.
• Existing skills: Your existing AI skills will not automatically update. To use the new model, you will see a banner in the prompt builder with instructions to perform the update. If a new model is not selected, existing skills will continue to use the previously available models.

Model routing and fallback behavior

AI skills route model requests differently depending on whether Auto mode or a specific model is selected:

• Auto mode (any provider): Appian automatically selects the Appian recommended model within the configured provider at execution time. If the highest-priority model is unavailable, Appian routes to the next available model within the same provider. No cross-provider fallback occurs.
• Specific model with third-party cloud provider: If the selected model is unavailable, the execution might fail with an error. To gain fallback protection for third-party cloud providers, use Auto model selection.

The following conditions apply to all modes:

• If no supported models are available for the configured provider, the AI skill returns an error.
• If a model provider is disabled, Appian does not route requests to any models from that provider. Disabling a provider also removes its models from Auto mode routing.
• No cross-provider fallback occurs under any circumstances. If your configured provider's models are unavailable, executions fail rather than routing to a different provider.

Processing regions: Control where your AI data is processed

A processing region defines the regions through which data may move when using the model. Unlike single-region settings, a processing region offers more flexibility by allowing processing in multiple pre-defined AWS regions.

A processing region is required for certain generative AI models. System administrators select the appropriate processing region for your environment in the Appian Administration Console. When you choose a processing region, the model card lists the supported regions so you can confirm where data will be processed before saving your selection.

After you select a processing region, review the supported regions on the model card for that setting. Confirm where data could be processed before saving your selection. For details about regional availability and processing region concepts, see Regional Availability.

Scroll or drag to pan · ⌘+/⌘− to zoom · Esc to close

Manage processing regions

To enable or disable a model by selecting a processing region:

1. In the Appian Admin Console, go to AI Services.
2. On the Appian tab, locate the model card for the model you want to configure.
3. In the Processing Region dropdown, select a processing region to enable the model, or select None to disable it.
   • If you select None, review the warning in the confirmation message that disabling the model will impact application features that rely on it. Confirm your choice.
     
4. After you select a processing region, review the supported regions on the model card for that setting. Confirm where data could be processed.
5. Click SAVE CHANGES to apply your changes.

Connect your own models

You can configure which AI provider powers Appian's generative AI features. By default, Appian uses its own infrastructure. However, you can bring your own provider to gain greater control over security, compliance, and cloud resource management. Appian supports four approaches:

• AWS account: Connect your own AWS account to use Amazon Bedrock models directly. See Connect an Amazon Web Services account.
• Azure account: Connect your own Microsoft Azure OpenAI account to route LLM regional processing through your Azure environment. See Connect a Microsoft Azure OpenAI account.
• Google Cloud Platform account: Connect your own Google Cloud Platform account to use Google Cloud AI models, including Gemini and Claude. See Connect a Google Cloud Platform account.
• Custom provider: Route AI requests through an internal AI gateway or proxy service using a custom endpoint. See Route AI traffic through a custom provider.

Model provider behavior in AI Services

Configuring a model provider allows Appian features to use large language models (LLMs) from your own account or infrastructure. Model provider configuration applies only to LLM regional processing for generative AI features. Other AI capabilities like Advanced IDP and traditional ML Skills continue to use Appian's infrastructure.

Scroll or drag to pan · ⌘+/⌘− to zoom · Esc to close

Default model provider behavior in AI Services

When an admin sets a provider as the default provider, Appian uses that provider for AI features where a developer has not explicitly chosen a specific model or provider. Default provider behavior means:

• Features without model selection: AI capabilities like AI agents, Composer, and Data Fabric Chat automatically use the configured model provider.
• Features with model selection: Developers can select from models offered by all enabled providers.

Verify AI features after switching default providers

After switching default providers, test your AI capabilities to ensure they work as expected:

1. Test an AI capability like Composer or data fabric chat to confirm it generates responses.
2. If you have existing generative AI skills, test them in your applications to verify they execute successfully.
3. Check the application server logs for any authentication or connection errors related to AI features.

If AI features fail after switching providers, verify that the new provider has the necessary models enabled and that your credentials (for AWS accounts) are configured correctly.

Revert to the Appian provider

You can switch between Appian's default provider and your own AWS account at any time.

To revert to Appian's provider:

1. In the Appian Admin Console, go to AI Services.
2. Select Appian from the model provider dropdown.
3. From the context menu, select Set as Default Provider
   
4. Click SAVE CHANGES.

Connect an Amazon Web Services account

You can configure your own AWS (Amazon Web Services) account as the model provider for Appian AI Services. Connecting your own AWS account gives you direct control over which Bedrock models are used and how your data is processed within your AWS infrastructure.

Security and connectivity for AWS accounts

When you configure your own AWS account, Appian AI Services uses a secure architecture to manage credentials and validate connectivity to your Bedrock resources. The architecture includes credential protection and connectivity validation.

Scroll or drag to pan · ⌘+/⌘− to zoom · Esc to close

Credential protection for AWS accounts

Appian handles your AWS credentials with multiple layers of security to ensure they are never exposed:

• Secure transmission: All credentials are transmitted over HTTPS.
• Masked storage: The Access Key and Secret Access Key are masked after saving and are never displayed again in the Admin Console.
• No logging: Sensitive credentials are never written to server logs.

Connectivity validation for AWS accounts

Before saving your configuration, the TEST CONNECTION feature performs a real-time validation against your AWS account. The connectivity test confirms:

• Authentication: Your Access ID and Secret Access Key are valid for the selected region.
• Permissions: Your IAM user has the required bedrock:InvokeModel permissions.

AWS IAM permissions prerequisite

Before configuring your AWS account, you must create an IAM (Identity and Access Management) user with the required permissions. Ensure your AWS administrator sets up this user before you configure your AWS account in Appian.

Your IAM policy must include at least the following permissions:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "bedrock:InvokeModelWithResponseStream",
                "bedrock:InvokeModel",
                "bedrock:GetFoundationModel"
            ],
            "Effect": "Allow",
            "Resource": [
                "arn:aws:bedrock:*::foundation-model/*",
                "arn:aws:bedrock:*:{YOUR_ACCOUNT_ID}:inference-profile/*"
            ],
            "Sid": "BedrockPermissions"
        },
        {
            "Action": [
                "bedrock:ListInferenceProfiles",
                "bedrock:ListFoundationModels"
            ],
            "Effect": "Allow",
            "Resource": "*",
            "Sid": "BedrockListPermissions"
        },
        {
            "Action": [
                "bedrock-mantle:CreateInference",
                "bedrock-mantle:CallWithBearerToken"
            ],
            "Effect": "Allow",
            "Resource": "*",
            "Sid": "BedrockMantlePermissions"
        }
    ]
}

Enable models on AWS Marketplace

Some Amazon Bedrock models are offered through AWS Marketplace and require a subscription before they can be used. The first time Appian calls one of these models on your AWS account, AWS attempts to enable the model automatically. This attempt fails if the IAM policy does not have the required permissions to subscribe. Use one of the following approaches to enable the model. If you use the IAM policy approach, it also grants the permissions needed for automatic enablement on first use.

Manual approach

An administrator on your AWS account can enable the model directly in the AWS Management Console. For details, see Simplified Amazon Bedrock Model Access on the AWS Security Blog.

Programmatic approach

To avoid manual steps, add the following statement to the Statement array in your IAM policy. This allows Bedrock to subscribe to Marketplace models automatically on first use:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
{
    "Sid": "AllowMarketplaceSubscription",
    "Effect": "Allow",
    "Action": [
        "aws-marketplace:ViewSubscriptions",
        "aws-marketplace:Subscribe"
    ],
    "Resource": "*",
    "Condition": {
        "StringEquals": {
            "aws:CalledViaLast": "bedrock.amazonaws.com"
        }
    }
}

Rate limits and capacity planning for AWS accounts

When you use your own AWS account, you're responsible for managing the rate limits on your Bedrock resources. Ensure that the rate limits on your AWS account support the volume of AI requests you expect to process in Appian. If your rate limits are too low, AI features may fail or experience delays during high-usage periods.

To check and adjust your rate limits, see the AWS Bedrock documentation on quotas.

Connect your AWS account

Your AWS IAM user must have the required bedrock:InvokeModel permissions before you begin. See AWS IAM permissions prerequisite for the full policy.

To use your own AWS account as the model provider:

1. In the Appian Admin Console, go to AI Services.
2. Select Amazon Web Services from the model provider dropdown.
3. Enter the following credentials:
   • Access ID: Your AWS access key identifier.
   • Secret Access Key: Your AWS secret access key. This value is masked after saving and doesn't display again.
4. Select the AWS Region where your resources are located. This is the source region that Appian will use when calling Bedrock.
5. Click TEST CONNECTION to validate your credentials and verify sufficient permissions.
   • Successful test: A green confirmation appears with the message "Test connection successful." This confirms your credentials are valid and have the required permissions.
   • Failed test: An error message appears indicating the issue. Common failures include:
     • Invalid credentials: Verify your Access ID and Secret Access Key are correct.
     • Insufficient permissions: Ensure your IAM policy includes the required Bedrock permissions.
     • Region mismatch: Confirm the selected region matches where your AWS Bedrock resources are configured.
6. Click SAVE CHANGES to apply your configuration.

Scroll or drag to pan · ⌘+/⌘− to zoom · Esc to close

Deploy AI model provider configurations

When you deploy applications between environments that use your own model provider, you need to configure credentials for the target environment. AWS credentials are handled differently during export and import to protect sensitive data.

Export behavior for AWS credentials

For security reasons, AWS credentials are not included when you export Admin Console settings. The Access Key and Secret Access Key are never exported from the source environment.

Import behavior for AWS credentials

When importing an Admin Console settings file that includes AWS credentials, you must provide valid AWS credentials again in an import customization file. AWS credentials—including the default provider, keys, and processing regions—are exported as a single unit. Because AWS credentials are exported as a single unit, you must include valid credentials in your import customization file even if you only modified the processing regions.

The import customization file must contain:

• AWS Access Key ID
• AWS Secret Access Key
• AWS Region

If you want to maintain the existing AWS credentials in your target environment without modification, you can exclude them during the export process.

To prevent overwriting credentials:

1. In the export dialog, deselect AWS Credentials.
2. Complete the export.

When you exclude this option, the import process will not change any existing AWS configuration in the target environment.

For detailed instructions on setting up these files, see Managing Import Customization Files.

Connect a Microsoft Azure OpenAI account

Organizations that require generative AI traffic to remain within their Microsoft Azure environment can connect their own Azure OpenAI account to Appian. This gives administrators control over data residency, security boundaries, and cloud spend alignment with existing Microsoft Enterprise Agreements.

Azure OpenAI configuration applies only to large language model (LLM) regional processing for generative AI features. AI capabilities that rely on non-LLM services — such as document extraction (Amazon Textract) and knowledge bases (OpenSearch) — continue to use Appian-provisioned infrastructure even when Azure OpenAI is configured.

Azure OpenAI prerequisites

Before configuring Azure OpenAI in Appian, retrieve the following credentials from the Azure Portal:

• Endpoint: The base URL for your Azure OpenAI resource. Format: https://<your-resource-name>.openai.azure.com/
• API key: An access key for your Azure OpenAI resource.

You must also create at least one model deployment in Azure OpenAI Studio and note the deployment name for each model you want to use in Appian.

Azure OpenAI GPT model regional availability

Regional availability for Azure OpenAI GPT models depends on the customer's own Azure deployment region, not on Appian's infrastructure regions. When an administrator configures the Microsoft Azure provider on the AI Services page, the GPT models are available in whatever Azure region the customer has deployed their Azure OpenAI resource.

Azure OpenAI model deployment mapping

When you configure Azure OpenAI, you map your Azure deployment names to Appian-supported GPT models. This mapping tells Appian which of your Azure deployments corresponds to each supported model type, allowing Appian features to route requests to the correct deployment.

Connect your Azure OpenAI account

Before connecting your Azure OpenAI account, retrieve your Endpoint and API Key from the Azure Portal and create at least one model deployment in Azure OpenAI Studio. See Azure OpenAI prerequisites for details.

To configure Microsoft Azure OpenAI as a model provider:

1. In the Appian Admin Console, go to AI Services.
2. Select the Microsoft Azure tab.
3. Enter your Endpoint.
4. Enter your API Key.
5. Click SAVE CHANGES.

After you save the provider configuration, you are directed to the Model list view where you can add models.

Add a model to Azure OpenAI

After configuring your Azure OpenAI account credentials, add models to map your Azure deployments to Appian features. Your Azure OpenAI provider credentials must be saved before you can add models.

To add a model:

1. In the Model list view, click Add Model.
2. From the Select a model dropdown, select the GPT model that corresponds to your Azure deployment. The dropdown lists the GPT models supported by Appian.
3. Enter a Display Name for the model. This is the label that appears in Appian when selecting the model.
4. Enter your Deployment Name. This is the name of the deployment you created in Azure OpenAI Studio.
5. Click TEST CONNECTION to validate that Appian can reach your Azure deployment using the configured credentials.
   • If the test succeeds, a confirmation message appears indicating the connection is valid.
   • If the test fails, verify that your endpoint URL, API key, and deployment name are correct and match those configured in Azure OpenAI Studio.
6. Click SAVE CHANGES to add the model.

Set Azure OpenAI as the default provider

To set Azure OpenAI as the default provider so that AI capabilities use your Azure account automatically:

1. In the Appian Admin Console, go to AI Services.
2. Select the Microsoft Azure tab.
3. From the context menu, select Set as Default Provider.
4. Click SAVE CHANGES.

How Azure OpenAI affects generative AI skills

When Azure OpenAI is enabled, the models available in the Model Selection dropdown of an AI skill reflect the model equivalents configured by the administrator. The low-code configuration of AI skills remains the same regardless of the underlying provider.

Connect a Google Cloud Platform account

Organizations that standardize on Google Cloud Platform (GCP) can connect their own Google Cloud account to Appian to use Google Cloud AI models. Connecting a Google Cloud account gives administrators control over data residency, security boundaries, and cloud spend alignment with existing Google Cloud contracts. Connecting a Google Cloud account makes Google Cloud models—including Gemini and Claude—available for selection in generative AI skills and the a!genAiModels() function.

Google Cloud Platform configuration applies only to large language model (LLM) regional processing for generative AI features. AI capabilities that rely on non-LLM services—such as document extraction (Amazon Textract) and knowledge bases (OpenSearch)—continue to use Appian-provisioned infrastructure even when Google Cloud Platform is configured.

You configure the Google Cloud Platform provider on the Google tab of the AI Services page in the Admin Console, following the same pattern as the AWS and Azure providers: enter your Google Cloud credentials, use TEST CONNECTION to validate them, and click SAVE CHANGES. You can then set Google Cloud Platform as the default provider from the context menu.

Route AI traffic through a custom provider

A custom provider allows you to route Appian AI requests through an internal AI gateway or proxy service instead of connecting directly to a public cloud API. Custom providers are useful for organizations that require all AI traffic to pass through a centralized, internally managed platform for security, auditing, or regulatory compliance.

Custom endpoint (Base URL)

The Base URL is the root address of your internal AI gateway or proxy service. When you configure a custom provider, Appian sends AI requests to this address instead of the default public cloud endpoint.

The Base URL is combined with model-specific endpoint paths to form the full request URL. For example, if your Base URL is https://ai-gateway.example.com/api/v1 and a model's endpoint path is messages/sonnet4, Appian sends requests to https://ai-gateway.example.com/api/v1/messages/sonnet4.

Protocol and provider compatibility

While the endpoint is custom, the protocol—the API request and response structure—must still match a supported provider family. Appian supports the following protocols:

• AWS Bedrock Converse
• Azure OpenAI
• Google Cloud
• OpenAI Chat Completion

Your internal gateway must accept and return data in the same format as the selected protocol. Appian does not transform requests into a proprietary format; it uses the standard API contract of the chosen provider family. Your proxy service is responsible for handling the request in that format and returning a compatible response.

The OpenAI Chat Completion protocol sends requests in the standard chat completions format, with the target model named in a model field in the request body. This protocol lets you connect Appian to OpenAI-compatible AI gateways, such as Portkey, LiteLLM, or Kong, that route to different underlying models through a single OpenAI-standard API. When you select OpenAI Chat Completion, you set the model identifier on each model. See Add a model to a custom provider.

Base URL and model endpoints

A custom provider separates configuration into two layers:

• Provider level: The Base URL and authentication credentials apply to all models under the provider.
• Model level: Each model defines its own endpoint path and protocol. The endpoint path is appended to the Base URL to form the full request URL.

The two-layer structure allows you to host multiple models behind a single gateway, each accessible at a different path, while sharing the same authentication and base address.

Authentication for custom providers

A custom provider that uses API Key authentication sends the API key in a request header. Two provider-level fields control this behavior, and both apply regardless of which protocol you select:

• API Key: The key value that Appian sends to your gateway. This is the credential itself.
• Auth Header Name: The name of the header that carries the API key. This field is optional and defaults to x-api-key if left blank. Set it to a custom header, such as x-portkey-api-key, when your gateway requires a non-standard authentication header. Header names are case-insensitive.

The Auth Header Name field is what enables gateways that do not accept the default x-api-key header. For example, Kong requires a custom authentication header, so you set Auth Header Name to the header your gateway expects and enter the key value in API Key.

Add a custom provider

To add a custom provider:

1. In the Admin Console, navigate to the AI Services page.
2. From the model provider dropdown, select your custom provider.
3. Enter a Display Name for the provider.
4. Select the Authentication Type for connecting to your gateway:
   • API Key: Authenticates requests using an API key passed in a header.
   • Basic Auth: Authenticates requests using a username and password combination.
5. Enter the authentication credentials required for the selected type.
6. (Optional) If you selected API Key and your gateway expects the key in a non-standard header, enter the Auth Header Name. This is the name of the header that carries the API key. It defaults to x-api-key if left blank. Set it to a custom header, such as x-portkey-api-key, when your gateway requires a non-standard authentication header.
7. Enter the Base URL of your internal AI gateway or proxy service. This is the root address that Appian will use for all AI requests sent to this provider.
8. Click SAVE CHANGES.

Add a model to a custom provider

After creating a custom provider, configure the specific models that Appian will leverage for generative AI features. Each model specifies the endpoint path, communication protocol, and model type. Models that use the OpenAI Chat Completion protocol also specify a model ID that Appian passes in the request body. To see which models are supported by a given feature, use the AI Feature Model & Region Explorer.

To add a model:

1. On the custom provider page, click Add Model.
2. Select the Model Type that this model represents. The model type tells Appian which AI capabilities this model can power.
3. Enter the Endpoint URL for the model. This path is appended to the provider's Base URL to form the full request URL.
4. Select the Protocol that the model endpoint uses. The protocol must match a supported provider family, such as AWS Bedrock Converse, Google Cloud, Azure OpenAI, or OpenAI Chat Completion.
5. If you selected OpenAI Chat Completion as the protocol, enter the Model ID. This field is required for the OpenAI Chat Completion protocol and does not appear for other protocols. Enter the gateway-specific model identifier that Appian passes as the model field in the request body, such as claude-sonnet-4-20250514 or openai/gpt-5.5.
6. Click TEST CONNECTION to validate that the credential and model combination is reachable through the custom endpoint.
   • A successful test confirms that Appian can reach the model at the configured Base URL and endpoint path using the configured protocol, authentication header, and model ID.
   • If the test fails, verify that the Base URL, endpoint path, credentials, protocol, authentication header, and model ID are correct.
7. After a successful test, click SAVE to add the model.

Custom provider constraints and limitations

Keep the following constraints in mind when configuring a custom provider:

• Supported models: See the Model Support and Deprecation page for supported models.
• LLM regional processing only: Custom provider configurations apply only to LLM regional processing for generative AI features. Non-LLM capabilities, such as Advanced IDP and traditional ML Skills, continue to use Appian's infrastructure and are not affected by custom provider settings.
• Protocol fidelity: Your proxy service must adhere to the exact JSON payload and header requirements of the selected protocol (for example, AWS Bedrock Converse, Google Cloud, Azure OpenAI, or OpenAI Chat Completion). Appian does not transform requests into a proprietary format, so any deviation in the request or response structure may cause failures.
• Latency: Internal gateways may introduce additional network hops, which can impact the response time of AI feature.
• Rate limiting: Ensure your internal proxy is configured with throughput limits that support the expected volume of AI requests in your Appian environment. If limits are too low, AI features may fail or experience delays during high-usage periods.

Edit a custom provider

To update a custom provider's display name, authentication, or Base URL:

1. On the AI Services page, select the custom provider.
2. Click Edit.
3. Update the desired fields.
4. Click SAVE CHANGES.

Set a custom provider as the default provider

You can set a custom provider as the default provider for your environment so that Appian routes all AI requests through your internal infrastructure. Before setting the default, ensure your provider meets the model coverage requirements.

Model coverage requirements for custom providers

Appian's AI features rely on different model types to function. If your custom provider is missing a model for a given type, any AI capability that depends on that model type will fail at runtime.

For example, if your custom provider does not include a model tagged for tool use, features that rely on tool use will fail at runtime.

The following table describes the model types that Appian AI features require. If your custom provider does not include a model for a given type, features that depend on it will fail at runtime.

Steps to set a custom provider as the default

To set a custom provider as the default:

1. On the AI Services page, select the custom provider.
2. From the context menu, select Set as Default Provider.
3. Click SAVE CHANGES.

Disable a model provider

You can disable an entire model provider at the environment level to prevent Appian from routing any AI requests to that provider's models. Disabling a model provider is different from disabling individual models — disabling a model provider blocks all models from that provider at once, regardless of individual processing region settings.

Disabling a model provider is useful for organizations that need to certify their environment does not invoke models from a specific provider, such as meeting supply chain compliance requirements.

Scroll or drag to pan · ⌘+/⌘− to zoom · Esc to close

What happens when you disable a model provider

When you disable a model provider:

• AI request routing: Appian does not route any AI requests to models from that provider.
• Fallback chain: The disabled provider's models are removed from the fallback chain. If a model is unavailable during invocation, Appian does not fall back to a disabled provider.
• AI capabilities: AI capabilities that depend on models from the disabled provider use an alternative provider if one is enabled. If no alternative is available, those capabilities return an error.
• Audit log: Appian records the change in the audit log with a timestamp, the actor who made the change, and the action taken.

Steps to disable a model provider

To disable a model provider:

1. In the Appian Admin Console, go to AI Services.
2. Click SETTINGS.
3. In the list of model providers, locate the provider you want to disable (such as Anthropic, Amazon, Meta, or OpenAI).
4. Toggle the provider from Enabled to Disabled.
5. Review the confirmation message that describes the impact on AI capabilities.
6. Click SAVE CHANGES.

What to know before disabling a model provider

Keep the following in mind when disabling a model provider:

• Configure an alternative first: Before disabling a model provider, verify that an alternative provider is enabled and that your AI capabilities work with it. This prevents disruption to AI capabilities in your environment.
• Disabling versus setting a default: Setting a default provider controls routing preference. Disabling a model provider prevents any routing to it, including fallback.
• Audit log entries: Appian logs model provider disable and enable actions in admin_console_audit.csv. Use these entries to verify compliance during audits. See Admin Console audit logs for details.

Feedback