AnsiblePilot — Master Ansible Automation

AnsiblePilot is the leading resource for learning Ansible automation, DevOps, and infrastructure as code. Browse over 1,400 tutorials covering Ansible modules, playbooks, roles, collections, and real-world examples. Whether you are a beginner or an experienced engineer, our step-by-step guides help you automate Linux, Windows, cloud, containers, and network infrastructure.

Popular Topics

About Luca Berton

Luca Berton is an Ansible automation expert, author of 8 Ansible books published by Apress and Leanpub including "Ansible for VMware by Examples" and "Ansible for Kubernetes by Example", and creator of the Ansible Pilot YouTube channel. He shares practical automation knowledge through tutorials, books, and video courses to help IT professionals and DevOps engineers master infrastructure automation.

Connect the AAP Intelligent Assistant to Azure OpenAI: Setup Guide

By Luca Berton · Published 2024-01-01 · Category: installation

Step-by-step guide to connecting the AAP Intelligent Assistant to Azure OpenAI with AAP 2.7 BYOM, covering prerequisites, config, and BYOK context.

Red Hat Ansible Automation Platform 2.7 opens up the Intelligent Assistant — the AI chatbot embedded directly in the AAP UI — to a Bring Your Own Model (BYOM) approach. Instead of being locked into a single hosted model, platform teams can now point the assistant at the large language model provider that already fits their enterprise's cloud footprint, compliance posture, and existing contracts. For organizations standardized on Microsoft Azure, that provider is Azure OpenAI, and Red Hat confirmed support for it at Red Hat Tech Day Netherlands 2026 in Bunnik.

This guide walks through what "Azure OpenAI support" actually means for the Intelligent Assistant, what you need before you start, and how to configure the connection so your automation teams can ask AAP-aware questions and get answers grounded in your own environment.

What the Intelligent Assistant Actually Does

The Intelligent Assistant is a conversational chatbot surfaced inside the AAP web UI. It's designed to help automation engineers and operators without requiring them to leave the platform to search documentation, Slack threads, or tribal knowledge. Typical use cases include:

  • Asking how to structure a job template or workflow
  • Getting explanations of failed job output
  • Looking up recommended patterns for credentials, inventories, or execution environments
  • Querying organizational runbooks and procedures (once BYOK, discussed below, is enabled)
Because the assistant is a chat interface backed by an LLM, its usefulness — and its trustworthiness — depends heavily on which model is answering the questions. That's precisely why BYOM matters: it lets you choose a model your organization already trusts and governs.

See also: AAP BYOM Provider Comparison 2026: Red Hat AI vs OpenAI vs Azure vs watsonx vs Gemini

BYOM Provider Support at a Glance

Red Hat's compatibility matrix, presented at Red Hat Tech Day Netherlands 2026, draws a clear distinction between the two AI surfaces in AAP 2.7 — the Intelligent Assistant (chatbot) and the Coding Assistant (the Ansible VS Code extension). They do not support the same providers on the same timeline, which is a common source of confusion for teams planning their rollout.

ProviderIntelligent Assistant (chatbot)Coding Assistant (VS Code)
Red Hat AISupported (AAP 2.6+)Supported (AAP 2.6+)
OpenAISupported (AAP 2.6+)Coming Soon
Azure OpenAISupported (AAP 2.6+)Coming Soon
IBM watsonxNot supportedSupported (AAP 2.5+, first external provider)
Google Gemini / VertexComing SoonSupported (AAP 2.6+)
Two things stand out. First, Azure OpenAI has been supported for the Intelligent Assistant since AAP 2.6 — this isn't a brand-new 2.7 capability, but 2.7 is where BYOM configuration and the broader provider story matured enough for wide enterprise rollout. Second, if your team is hoping to use Azure OpenAI inside the VS Code Coding Assistant too, that's listed as Coming Soon — plan your Azure OpenAI adoption around the chatbot first.

Prerequisites Before You Connect Azure OpenAI

Before touching AAP configuration, make sure you have the Azure-side pieces in place:

  1. An Azure OpenAI resource provisioned in your Azure subscription, with a model deployment created (for example, a GPT-4-class deployment) and a deployment name you control.
  2. An API key or Azure AD/Entra ID credential with access to that resource, scoped following least-privilege principles.
  3. The resource endpoint URL, typically in the form https://.openai.azure.com/.
  4. The API version your deployment expects (Azure OpenAI versions its REST API independently of the underlying model).
  5. AAP 2.6 or later, since Azure OpenAI support for the Intelligent Assistant requires that baseline. AAP 2.7 is recommended for the most complete BYOM configuration experience.
  6. Network reachability from your AAP control plane to the Azure OpenAI endpoint — confirm firewall rules, proxy configuration, and any private endpoint / VNet integration requirements your security team enforces.

Configuring the Connection

The BYOM configuration lives in the AAP administration settings where AI provider credentials are managed. At a high level, the workflow is:

  1. Navigate to the platform-level AI/Intelligent Assistant configuration screen in the AAP UI.
  2. Select Azure OpenAI as the provider for the Intelligent Assistant.
  3. Supply the endpoint URL, deployment name, API version, and authentication credential.
  4. Save and validate the connection — AAP performs a test call to confirm the model responds before enabling it platform-wide.
  5. Optionally scope the configuration per organization if you need different Azure OpenAI resources (e.g., different regions or cost centers) for different teams.
If your organization automates the platform's own configuration via Ansible (a common pattern for AAP administrators who treat the control plane itself as code), the settings can be applied through the relevant platform gateway or settings modules once they support this configuration surface. A representative task, illustrating the shape of such a play, looks like this:
---
- name: Configure Intelligent Assistant to use Azure OpenAI
  hosts: localhost
  gather_facts: false
  vars:
    aap_hostname: "https://aap.example.com"
    azure_openai_endpoint: "https://my-org-openai.openai.azure.com/"
    azure_openai_deployment: "gpt4-automation-assistant"
    azure_openai_api_version: "2024-10-21"
  tasks:
    - name: Set Intelligent Assistant provider to Azure OpenAI
      ansible.builtin.uri:
        url: "{{ aap_hostname }}/api/gateway/v1/ai_settings/intelligent_assistant/"
        method: PATCH
        headers:
          Authorization: "Bearer {{ aap_admin_token }}"
        body_format: json
        body:
          provider: "azure_openai"
          endpoint: "{{ azure_openai_endpoint }}"
          deployment_name: "{{ azure_openai_deployment }}"
          api_version: "{{ azure_openai_api_version }}"
          credential_ref: "azure-openai-service-cred"
        status_code: 200
      register: assistant_config
      no_log: true

    - name: Confirm assistant configuration succeeded
      ansible.builtin.debug:
        msg: "Intelligent Assistant now routed to Azure OpenAI deployment {{ azure_openai_deployment }}"
      when: assistant_config.status == 200

Treat the endpoint names, API paths, and field names above as illustrative of the pattern — always confirm the exact API surface against your installed AAP 2.7 release documentation, since BYOM configuration screens and endpoints are still evolving as the feature matures.

See also: Connect the AAP Coding Assistant to Google Gemini: Setup Guide

Grounding Answers with BYOK

Once the Intelligent Assistant is talking to Azure OpenAI, the next natural question is: how do you make sure it answers with your organization's context instead of generic Ansible knowledge? That's where Bring Your Own Knowledge (BYOK) comes in — also announced at Red Hat Tech Day Netherlands 2026 as a Tech Preview feature.

BYOK lets you inject internal policies, best practices, and procedures into the Intelligent Assistant's retrieval-augmented generation (RAG) pipeline. Practically, that means the assistant can ground its answers in:

  • Your organization's change-management procedures
  • Internal network naming conventions
  • Compliance requirements such as PCI-DSS, HIPAA, or SOC2
  • Internal runbooks specific to your infrastructure
Combined with Azure OpenAI as the underlying model, BYOK turns the Intelligent Assistant from a generic Ansible help bot into an assistant that understands how your organization actually operates — while the model call itself still runs against the Azure OpenAI deployment you configured and control.

Key Takeaways

  • Azure OpenAI has been a supported provider for the AAP Intelligent Assistant since AAP 2.6, with BYOM configuration maturing further in AAP 2.7.
  • The Intelligent Assistant (chatbot) and Coding Assistant (VS Code extension) have different provider support timelines — Azure OpenAI is not yet available for the Coding Assistant, which is listed as Coming Soon.
  • IBM watsonx is not supported for the Intelligent Assistant at all, while it was the first external provider supported for the Coding Assistant back in AAP 2.5.
  • Before connecting Azure OpenAI, gather your resource endpoint, deployment name, API version, and a properly scoped credential.
  • BYOK (Tech Preview) lets you layer your organization's own policies and runbooks on top of whichever BYOM provider you choose, including Azure OpenAI.
  • Always validate exact configuration field names and API paths against your installed AAP 2.7 documentation, since BYOM settings are still evolving.

Category: installation

Browse all Ansible tutorials · AnsiblePilot Home